#88184 - xproductions - Sat Jun 17, 2006 11:34 pm
I'm thinking of a technique that might be useful for demo coders: copying code into VRAM and executing it there. Martin's docs say that:
http://nocash.emubase.de/gbatek.htm#memorymap
the only faster memory locations than VRAM are Internal Work RAM and OAM.
Is this feasible/practical?
_________________
If you would not be forgotten
as soon as you are dead and rotten,
either write things worth reading
or do things worth writing.
-- Benjamin Franklin
#88201 - keldon - Sun Jun 18, 2006 1:08 am
Considering you will be needing a portion of VRAM for your display, and it taking an extra cycle to access VRAM when the GBA is accessing VRAM you would probably prefer your fast code to be in WRAM. If you look at the lcd timings you will notice that vram is being accessed 54% of the time.
#88207 - Dwedit - Sun Jun 18, 2006 2:24 am
Executing code from vram is most useful if you have a very large multiboot program, and need more space for code. Use decompression to load code which is bigger than 256k.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#88221 - tepples - Sun Jun 18, 2006 5:09 am
| keldon wrote: |
| taking an extra cycle to access VRAM when the GBA is accessing VRAM [...] you will notice that vram is being accessed 54% of the time. |
Dwedit is right. 0.5/0.5 waits for Thumb code in VRAM is much better than 2/2 for EWRAM or 3/1 for ROM, especially if not all your code will fit into IWRAM. I'm certain that acNES (Nintendo's own NES emulator on GBA) uses this technique, and given Dwedit's familiarity with the technique, recent PocketNES probably does too.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#88249 - keldon - Sun Jun 18, 2006 9:54 am
Not that I'm disagreeing, but doesn't gbatek say:
| Quote: |
| Work RAM 32K -- 32 --- 8/16/32 --- 8/16/32 --- 1/1/1 |
Am I missing something with this?
#88301 - xproductions - Sun Jun 18, 2006 5:39 pm
| Quote: |
| Am I missing something with this? |
There's more VRAM than IWRAM. This might be more useful on the DS (assuming timing is the same), since there is much more VRAM there.
_________________
If you would not be forgotten
as soon as you are dead and rotten,
either write things worth reading
or do things worth writing.
-- Benjamin Franklin
#88310 - tepples - Sun Jun 18, 2006 6:50 pm
But then the DS has extensive caching on its EWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#88314 - DekuTree64 - Sun Jun 18, 2006 7:08 pm
DS can cache VRAM too, not just EWRAM. The ARM9 has no knowledge of the different memory areas, it's just that the libnds crt0 only turns caching on for that range.
According to the speed tests I did a long time ago on GBA, sprite and BG VRAM are accessed seperately from eachother. So if you're doing a demo effect that doesn't use any sprites, there won't be any access stalls from putting code in sprite VRAM.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#88315 - tepples - Sun Jun 18, 2006 7:13 pm
| DekuTree64 wrote: |
| DS can cache VRAM too, not just EWRAM. The ARM9 has no knowledge of the different memory areas |
Then why do people keep saying that GBA ROM space is impossible to cache on the DS?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#88318 - DekuTree64 - Sun Jun 18, 2006 7:20 pm
| tepples wrote: |
| DekuTree64 wrote: | | DS can cache VRAM too, not just EWRAM. The ARM9 has no knowledge of the different memory areas |
Then why do people keep saying that GBA ROM space is impossible to cache on the DS? |
Huh, I haven't heard anything about that. I'll give it a try tonight and see if it's true.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#88337 - keldon - Sun Jun 18, 2006 9:42 pm
| xproductions wrote: |
| Quote: | | Am I missing something with this? |
There's more VRAM than IWRAM. This might be more useful on the DS (assuming timing is the same), since there is much more VRAM there. |
Okay I knew that; I just thought it was for some other reason that I was completely unaware of. (Thinks to self) need to get back into coding.
#88448 - wintermute - Mon Jun 19, 2006 4:26 pm
| DekuTree64 wrote: |
| tepples wrote: | | DekuTree64 wrote: | | DS can cache VRAM too, not just EWRAM. The ARM9 has no knowledge of the different memory areas |
Then why do people keep saying that GBA ROM space is impossible to cache on the DS? |
Huh, I haven't heard anything about that. I'll give it a try tonight and see if it's true. |
DS can cache anywhere it's just a matter of marking the memory as cacheable.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#88534 - chishm - Tue Jun 20, 2006 1:15 am
You don't want to have the standard ARM9 crt0 mark the GBA cart as cachable, since that would interfere with the many flash memory interfaces being used by homebrew.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#116134 - HyperHacker - Mon Jan 22, 2007 7:31 am
Mind the bump but could GBA ROM area caching not be useful for virtualization? EG you could throw some small code into cache and reboot into GBA mode to execute it, without there being a GBA cart at all. Or if you wanted to try running GBA games in DS mode, you could "edit" the ROM by just exploiting the cache, so that a given chunk of ROM is read from cache instead of the actual data on the cartridge.
_________________
I'm a PSP hacker now, but I still <3 DS.
#116185 - Firon - Tue Jan 23, 2007 12:58 am
All memory is cleared when rebooting into GBA mode, iirc.
#116202 - chishm - Tue Jan 23, 2007 3:17 am
The ARM9 has the cache, not the overall system. Since GBA mode is exclusive to the ARM7, there's no cache involved.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#116205 - Miked0801 - Tue Jan 23, 2007 4:26 am
GBA does have a cache, but it's very limited...
#116219 - tepples - Tue Jan 23, 2007 7:29 am
If you're referring to the ROM instruction prefetch, the execution of the BIOS probably clears it anyway.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116221 - chishm - Tue Jan 23, 2007 10:23 am
| Miked0801 wrote: |
| GBA does have a cache, but it's very limited... |
I knew someone would mention that, but a 3 instruction pipeline isn't really a cache.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#116224 - keldon - Tue Jan 23, 2007 10:48 am
| chishm wrote: |
| Miked0801 wrote: | | GBA does have a cache, but it's very limited... |
I knew someone would mention that, but a 3 instruction pipeline isn't really a cache. |
Thank you! Well it is 'technically' cache, but cache needs to be redefined. The expected norm of cache [now] is for a set of memory to be copied. A prefetch buffer does not fit into the expected norm of what cache means, so it becomes a communication issue when the word cache is used against its expected meaning.
#116232 - gmiller - Tue Jan 23, 2007 3:41 pm
A pipeline is not cache ... cache has the ability to pull data from it (in cache blocks/lines) where as a pipeline you can only deal with the data when it comes out the end. You can implement pipelines in software where you can access data within the pipeline but the data is not complete till it hits the end of the "pipe". With a pipeline in a CPU the instruction is not ready to execute till the last step in the pipeline (some pipelines have other stages after the execution stage but I am simplifying here). So for the ARM 7 in this case you have to do three steps when the pipeline is empty to execute 1 instruction. Every executed branch (or direct modification of the 'pc') in your code flushes the pipeline (which means the pipeline has to be filled again) so there will be a performance hit.
Cache does not need to be full to operate, it has random access capabilities (direct, full associative, set associative) and it has a replacement algorithm. This is not how a pipeline operates.
#119956 - werty - Tue Feb 27, 2007 10:13 pm
| keldon wrote: |
| Considering you will be needing a portion of VRAM for your display, and it taking an extra cycle to access VRAM when the GBA is accessing VRAM you would probably prefer your fast code to be in WRAM. If you look at the lcd timings you will notice that vram is being accessed 54% of the time. |
Some apps will need LCD 1% ( All LCD's store pixels , CRT's
dont store ) .
If you are in a bind , simply reprogram .
Oh ! I see you use C , sorry , C cant reprogram !
#119958 - werty - Tue Feb 27, 2007 10:20 pm
| keldon wrote: |
| chishm wrote: | | Miked0801 wrote: | | GBA does have a cache, but it's very limited... |
I knew someone would mention that, but a 3 instruction pipeline isn't really a cache. |
Thank you! Well it is 'technically' cache, but cache needs to be redefined. The expected norm of cache [now] is for a set of memory to be copied. A prefetch buffer does not fit into the expected norm of what cache means, so it becomes a communication issue when the word cache is used against its expected meaning. |
Cache is Cache ,unless its in Windows , then its malware.
I disable Windows Vcache .
Cache must be faster .
Pipeline is to prevent stalls ONLY , the bottleneck
is still in the ALU . ARM cpus execute one instruction
at a time . Branch is 3 clocks . ?? Thats what my ARM
paper reads ! So wheres the advantage of the "pipe" ?!!
New ARM is faster ...
A new way to program will obsolete C/C++ and
allow ppl to create faster and thus Linux will be history .
Symbolic programming , uses NO text ,no modern language .
Go figure ......
#119962 - werty - Tue Feb 27, 2007 10:57 pm
| HyperHacker wrote: |
| Mind the bump but could GBA ROM area caching not be useful for virtualization? EG you could throw some small code into cache and reboot into GBA mode to execute it, without there being a GBA cart at all. Or if you wanted to try running GBA games in DS mode, you could "edit" the ROM by just exploiting the cache, so that a given chunk of ROM is read from cache instead of the actual data on the cartridge. |
Virtualization is an unneeded translation , something
no kernel needs to do .
It slows the kernel , and makes a job
for hungry programmers .
ALL Virtualization , not just some cases !
It was something Intel did after M$ wasted too much
RAM for its Vcache !! ha ha ha
I will create a symbolic , non-text, non-English
kernel , using the DS BIOS .
#119991 - Miked0801 - Wed Feb 28, 2007 3:10 am
zzzzzzz