GP2X Gp2x Demo Development

[Dzz]

okay, then I gonna use this for part 4. As I don't have FW 2.0 I don't now if part 1-3 has similar issues to fix. Can somebody test that?

The menu restarting mechanism was broken in all episodes. The Vsync appeard in episode 2 and never until now handled firmware 2.0 correctly.

ah fuck! thanks for the quick answer, hopefully I can revise the last parts and start at part 4.

Sorry about that. One thing I could do is produce a "consolidated" article containing corrected versions of all of the text and code for parts 1-4 that you could then edit further and pdf-ify and release to the archive, hopefully never to be touched again. I could get to that in the next week or so, I would want to make sure that all the information and code was as correct as possible given the discussions that came after each article. I was imagining that I would do that after I was done with the whole series but maybe now is a good time to clean up and release the "first half" as one unit.

I'd also expand episode 1 to include a description of the change made to the way the menu is restarted; the code itself is pretty cryptic. I also did away with using "entry" as the entry point -- as long as I had to put an assembly language header on the program I decided to just call the entry point _start like gcc expects.

Somewhat to my surprise, the versions on the archive are quite popular; I don't know if it's because some people just download everything whether it's of interest or not, or whether there are really 300+ people interested in demo development for the gp2x. But this cleanup/archival task you are doing certainly seems to have a lot of value.

 

[synkro]

okay, then I gonna use this for part 4. As I don't have FW 2.0 I don't now if part 1-3 has similar issues to fix. Can somebody test that?

The menu restarting mechanism was broken in all episodes. The Vsync appeard in episode 2 and never until now handled firmware 2.0 correctly.

ah fuck! thanks for the quick answer, hopefully I can revise the last parts and start at part 4.

Sorry about that. One thing I could do is produce a "consolidated" article containing corrected versions of all of the text and code for parts 1-4 that you could then edit further and pdf-ify and release to the archive, hopefully never to be touched again. I could get to that in the next week or so, I would want to make sure that all the information and code was as correct as possible given the discussions that came after each article. I was imagining that I would do that after I was done with the whole series but maybe now is a good time to clean up and release the "first half" as one unit.

I'd also expand episode 1 to include a description of the change made to the way the menu is restarted; the code itself is pretty cryptic. I also did away with using "entry" as the entry point -- as long as I had to put an assembly language header on the program I decided to just call the entry point _start like gcc expects.

Somewhat to my surprise, the versions on the archive are quite popular; I don't know if it's because some people just download everything whether it's of interest or not, or whether there are really 300+ people interested in demo development for the gp2x. But this cleanup/archival task you are doing certainly seems to have a lot of value.

no problem, I am just short of time atm as my thesis eats a lot of time lately. If you willing to clean up the the "first half" I gonna PDF'fy it ASAP. I am also quiet surprised how popular it is, I got already some nice comments for it. So I am going to wait till cleaned up everything and then continues with the newer ones.

 

[Dzz]

no problem, I am just short of time atm as my thesis eats a lot of time lately. If you willing to clean up the the "first half" I gonna PDF'fy it ASAP. I am also quiet surprised how popular it is, I got already some nice comments for it. So I am going to wait till cleaned up everything and then continues with the newer ones.

Ok, within a week I'll consolidate and clean up 1-4. You may end up wanting to clean up even more, but it'll be clean to me

 

[kraft]

Why not just wait until the entire series is complete - that way you can collate and combine with all mid-flow erratas. Both you guys can work together, correcting and editing the final PDF before releasing it as a single, tidy document (or arch of docs, if that tickles your fancy) This way there wont be half a dozen or so redundant versions floating around cyberspace. People who just cannot wait for the final PDF can simply follow this thread. Patience is a virtue

 

[synkro]

Why not just wait until the entire series is complete - that way you can collate and combine with all mid-flow erratas. Both you guys can work together, correcting and editing the final PDF before releasing it as a single, tidy document (or arch of docs, if that tickles your fancy) This way there wont be half a dozen or so redundant versions floating around cyberspace. People who just cannot wait for the final PDF can simply follow this thread. Patience is a virtue

uhm, no...

1) I never saw this as some kind of complete "black book" of gp2x hacking. I think Dzz sees that in a similar way: reach as much people as possible and let them participate on the demo dev series even if the cost is to spread "false information"

2) the number of downloads proofs that it is a perfect way to reach a huge audience, and those articles are what I always wanted for the GP32 when I got one. People want this and they want it now, even with some mistakes and errors.

3) The up2date versions are ALWAYS here in the archive and mirrored at my blog; all PDFs have a revision date.

4) Again, I don't see this as kind of course or text book, this is more an open discussion where I try to archive the milestones.

That's my opinion but as I am not in charge here, Dzz has the final word.

 

[Dzz]

Why not just wait until the entire series is complete - that way you can collate and combine with all mid-flow erratas. Both you guys can work together, correcting and editing the final PDF before releasing it as a single, tidy document (or arch of docs, if that tickles your fancy) This way there wont be half a dozen or so redundant versions floating around cyberspace. People who just cannot wait for the final PDF can simply follow this thread. Patience is a virtue

The idea is that it seems there are a bunch of people following this from the archive.gp2x.de releases that synkro has been doing. So something with these bug fixes should go up on that site to save people from having to discover the problems.

Also, I'm not sure when it will be "done"... after the dual processor miniseries there will probably be some other topic (at least one of "miscellaneous topics" like setting the CPU speed).

 

[MadDog]

Is there a reason you've used a .c file and not a cpp file? I've been doing some code that i've been hoping to run on the second chip, for now I call it at the end of the frame. But its in cpp files as i've used name spaces and a few classes. Would not be too hard to move it to c if there is an issue with the resulting code.

As I type this mail i'm thinking that instantiation of any static classes would be bust. The code is suposed to be a 'virtual' GPU and 'should' do no allocaton.

The short question is, can I use cpp files instead?

 

[Dzz]

Is there a reason you've used a .c file and not a cpp file? I've been doing some code that i've been hoping to run on the second chip, for now I call it at the end of the frame. But its in cpp files as i've used name spaces and a few classes. Would not be too hard to move it to c if there is an issue with the resulting code.

As I type this mail i'm thinking that instantiation of any static classes would be bust. The code is suposed to be a 'virtual' GPU and 'should' do no allocaton.

The short question is, can I use cpp files instead?

The short answer is: I don't know, but I think it's likely to be a problem. In particular, features such as the 'new' handler are almost certainly implemented in some support library and there may well be other c++ language features implemented in support libraries. That's why I chose C instead of C++ as the language to use. I'll play with it a bit and see how it looks.

Edit: Oops, i see you are trying to be careful not to do allocation, so there's a chance.

 

[Dzz]

With a minimum of effort I was able to get the code in "framework.zip" to compile by renaming the .c files to .cpp and dealing with the C++ name-mangling issues and a couple of new casting things revealed by the stricter type checking of C++. But it did build.

Unfortunately, as soon as I added a simple class and started trying to use it, I started getting link errors for functions like

__cxa_atexit (presumably something that tries to call destructors on static classes)
_Unwind_SjLj_Register
__gxx_personality_sJ0

and so on.

That doesn't mean that you can't use C++ code on the 940. You could start with a generic ARM compiler where including the libraries should be possible. I have not done that though and do not have any specific advice about which compiler to start with or how to configure it properly for use in this environment.

 

[MadDog]

Sounds like its a pain, I may just go for C now as for what I want c++ classes are not that important. Does mean I can't use my fixed point math classes. (matrix and vector) But i'm not looking to do much of that.

BTW, i've just created a rule for 2005 peaple, add the following to your rules file. As with the link make sure the arm-940-link is after the Librarian tool. To trigger add a .940 file to your project. i've not run the code yet, i'm going to do that now. But the output is the same as 6a tut. I've been a bit cheeky and used the pipe operator to run the objcopy phase, this is because I could not get a seperate rule for that to run after this rule.

<CustomBuildRule
Name="arm-940-link"
DisplayName="GCC 940 Linker"
CommandLine="ld.exe $(IntDir)\*.o -Ttext 0x0 -o &quot;$(TargetPath)&quot; [AllOptions] [AdditionalOptions] 2&gt;&amp;1 | arm-linux-objcopy.exe -O binary $(TargetPath) $(TargetDir)$(TargetName).bin"
Outputs="never-exists"
FileExtensions="*.940"
ExecutionDescription="Linking 940 $(TargetFileName)..."
>
<Properties>
<StringProperty
Name="LibPaths"
DisplayName="Additional Library Paths"
Description="Specifies one or more directories to add to the lib path; use semi-colon delimited list if more than one."
Switch="-L&quot;[value]&quot;"
Delimited="true"
Inheritable="true"
/>
<StringProperty
Name="Libraries"
DisplayName="Additional Dependencies"
Description="Specifies one or more libraries to link to; use semi-colon delimited list if more than one."
Switch="-l[value]"
DefaultValue="pthread"
Delimited="true"
Delimiters=";, "
Inheritable="true"
/>
<StringProperty
Name="EntryPoint"
DisplayName="Entry point for 940 cpu"
Description="Specifies where the execution starts"
Switch="-e&quot;[value]&quot;"
Delimited="true"
Inheritable="true"
/>
</Properties>
</CustomBuildRule>

 

[MadDog]

I've been putting this code into my engine and I had an idea of a simple way to make the 940 code a bit more robust using the protection unit. You say you've marked the first meg as code, vars and stack. But there is the possibility of the stack dropping down into your vars and if its a real bad bug code. I've been reading about the protection unit and how the regions can be overlapped and the higher the number the greater its priority will be. If you access a memory location where region one is set to no access but region two is set to read/write it will not fault.

Would it be worth while, at least in debug only, marking the top and bottom of the stack to catch stack overflow and underflow? Its one of them things that cause 'random' bugs. Just an idea whilst your putting the code in. Although then your stack is fixed in size.

 

[Squidge]

Well, if you stick with C, as long as you don't use recursive functions or do silly things like trying to allocate huge local arrays, you shouldn't need to worry about the stack, and a few kB should be more than adequate.

I do a lot of embedded stuff for my main day job; the ARM processors we use only have 64kB of RAM. We allocate the last 1kB for the stack and never had a problem yet.

 

[slygamer]

BTW, i've just created a rule for 2005 peaple, add the following to your rules file. As with the link make sure the arm-940-link is after the Librarian tool. To trigger add a .940 file to your project. i've not run the code yet, i'm going to do that now. But the output is the same as 6a tut.

Sweet. Looks good.

I've been a bit cheeky and used the pipe operator to run the objcopy phase, this is because I could not get a seperate rule for that to run after this rule.

That is one of the documented shortcomings of the custom build rule system in VS2005. It cannot use the output of one custom build rule to trigger another custom build rule.

 

[MadDog]

Episode 4
The first issue to think about is memory speed. On the gp2x, the lower 32MB of memory are managed by linux. That memory is marked as "cached", which means that reads and writes go to the 16kb cache on the arm 920 chip, which is usually a lot faster. The upper 32mb of memory is uncached. That uncached memory is the only memory I can get physical addresses for, so I need to have my display buffer in that memory. Linux uses some particular address ranges for the frame buffers in that upper memory range; in episode 1 I allocated some different "upper" memory for this purpose. This is a problem though. If I'm going to be messing around with the screen memory it will be pretty slow to read it from the uncached memory.

So I'd like a temporary memory buffer in cached memory that I can just zap to the screen memory at the end of each frame. There's certainly some overhead involved in that, but it's probably worth it.

I'm going to be using the 940 to do my rendering, so I was wondering if for that chip it would be better to have the FB cached and flush the cache no the vsync when you change the displayed FB's? I'm not a ARM guru, so I was wondering what issues there maybe? Would there be time?

 

[Dzz]

I'm going to be using the 940 to do my rendering, so I was wondering if for that chip it would be better to have the FB cached and flush the cache no the vsync when you change the displayed FB's? I'm not a ARM guru, so I was wondering what issues there maybe? Would there be time?

I think it sounds like a reasonable idea and I can't think of a reason why it would not work. As to not being an ARM guru -- since you're trying stuff beyond what the rest of us have actually done there's no alternative but to become one, at least a little. You'll need to get the memory regions set up so that the frame buffer areas are in cached memory (either because you decide to use addresses in the cached region or because you make the default screen buffer areas cached. Then you'll have to figure out how to flush the cache. There's a coprocessor 15 instruction to do this I believe. I am intending to research this further for episode 6c but that will be a couple weeks probably.

 

[Squidge]

There's CP15 operation to flush the data and instruction caches, but the data cache flush doesn't work that well when asked to clear the entire buffer, so you would be better of using something that will flush each cache line manually, like the following:

_dcache_flush:
	  MOV R4, #0
 
.dcache_flush_loop2:
	  MOV R5, #0
 
.dcache_flush_loop1:
	  MOV R3, R5, LSL #5
	  ORR R3, R3, R4, LSL #26
	  MCR P15, 0, R3, C7, C14, 2
	  ADD R5, R5, #1				   @ 4 sets
	  CMP R5, #4
	  BNE .dcache_flush_loop1
	  ADD R4, R4, #1				   @ 64 indices
	  CMP R4, #64
	  BNE .dcache_flush_loop2
 
	  MOV PC, LR

Or perhaps drain the buffer, rather than flushing it, as you just want to make sure the data is in memory:

_dbuffer_drain:
	MOV R0, #0
	MCR P15, 0, R0, C7, C10, 4	
	MOV PC, LR

 

[MadDog]

Whats the difference between 'flushing' and 'draining' the cache?


(I need to read my books a bit more)

 

[Squidge]

Flush writes all unsaved data to ram, and clears the caches.
Drain writes all unsaved data to ram and nothing else (data stays in the cache).

Since the frame buffer will only ever be modified by yourself, a drain may be more efficient than a flush in this case. If it was possible for the buffer to be modified externally (ie, by the 920 or by the 2d accelerator), then you would have to flush it, as otherwise the data may then become stale.

 

[nickspoon]

<--- is having trouble reading bitmaps with this framework

 

[Dzz]

<--- is having trouble reading bitmaps with this framework

Please elaborate on your difficulties, so we may ease them.