#9895 - duncanentwisle - Thu Aug 21, 2003 12:26 pm
Hi,
I'm developing a cartridge for the GBA that needs to be fed with 16-bit words at regular intervals. The overhead involved in context switching means I can't use interrupts because of the rate that my cartridge needs data - I was therefore thinking about using DMA...
CowBite's Virtual Hardware specification states "that it is not possible to DMA transfer from or to SRAM (Cart RAM) or BIOS, and (obviously) it is not possible to transfer to ROM". I assume the "obviously" refers to writing to read-only memory rather than writing to the catridge ROM's address space? (The destination register for DMA3 suggests that it can write to that region.)
Does anyone know how DREQ from the cartridge works? I assume that the catridge asserts it whenever it's either (1) ready for the next DMA transfer to it, or (2) ready to transfer the next word from it? If this is the case, does the DMA transfer have to complete in it's entirety, or is it non-blocking, allowing the CPU to continue - only pausing the CPU when it has to send a word?
Also, is DREQ edge or level triggered? If it's level triggered, what happens if it's removed before the GBA has written to the location, or, alternatively, not removed after the GBA has done its writing?
I hope I've read enough background material to not be asking silly questions, almost as much as I hope someone will already have the answers, rather than having to develop the board only to discover whether it works / doesn't work!
Thanks for any help you can provide,
Duncan.
#9923 - tepples - Thu Aug 21, 2003 11:42 pm
DMA channel 3 can indeed write to ROM address space (0x08000000-0x0dffffff). This is how serial-EEPROM save games work.
There are two ways a cart can signal whether it's ready to receive data. You can configure the cart to allow for interrupts, or you can place a pollable register in the cart's address space. (You may want to put registers in SRAM space to allow for cheaper decoding hardware.) Then the CPU either sets up a DMA channel 3 transfer from RAM to the cart or just executes an LDMIA/STMIA loop. Or you can set DMA to trigger on vblank or on hblank, hog the CPU during the transfer, and then let the CPU go until it's time for the next transfer. (Unlike hblank interrupts, hblank DMA won't trigger during vblank.)
"The overhead involved in context switching means I can't use interrupts because of the rate that my cartridge needs data"
A DMA transfer can be larger than 1 KB, you know. Using larger DMA transfers, it's possible to move up to 10 MB or more per second over the cart interface. By "rate" do you mean "throughput" or "sub-17ms latency"? How often is this "regular interval"?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#9924 - duncanentwisle - Fri Aug 22, 2003 12:04 am
| tepples wrote: |
"The overhead involved in context switching means I can't use interrupts because of the rate that my cartridge needs data"
A DMA transfer can be larger than 1 KB, you know. Using larger DMA transfers, it's possible to move up to 10 MB or more per second over the cart interface. By "rate" do you mean "throughput" or "sub-17ms latency"? How often is this "regular interval"? |
My device needs one 16-bit word every 3.84us (there's a one word deep FIFO so it can move around a little within its timeslot). Inbetween, the processor can be doing what-ever it wants to. (I do realise that this may take up to 25% of the processor's time - this is still at the feasibility stage - hence the questions :-)
I'm building an interface to a Kopin 320M CyberDisplay - and I want the resulting design to be as cheap and accessible as possible - I could use a CPLD with more macrocells and pins, and use an external memory (so I don't have to provide a regular stream of data - I just grab it from local memory) - but that would add cost.
(Thanks for the reply.)
#9937 - tepples - Fri Aug 22, 2003 3:32 am
There is no DREQ line on the cart edge. DMA channel 3 can be triggered now, on vblank, or on hblank after lines 0-159. DMA channels 1 and 2 can also trigger on the sound FIFO, but they can't transfer to ROM space, so you can't just fool the HW that way.
Let's see... 3.84 microseconds per u16 times 16.78 cycles per microsecond is about 64.4 cycles per u16. You'll prob-ab-ly need a bigger FIFO.
The Game Boy and Super NES have vastly different scan rates. Thus, the various accessories used for displaying (such as Wide Boy, Demo Boy, Super Game Boy, Game Boy Player, and third-party GBA TV adapters) use a full-frame FIFO streamed with pixels from the Game Boy side of the accessory to the side that holds the frame buffer.
Right now, I'd suggest a FIFO deep enough to hold what can be transferred within one hblank: 1232 cycles/hblank / 16.78 cycles/us / 3.84 us/u16 = 19.1 words, rounded up to a nice round 32. Would a FIFO 32 u16s deep be too big to implement cheaply?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#9941 - duncanentwisle - Fri Aug 22, 2003 8:37 am
| tepples wrote: |
| Right now, I'd suggest a FIFO deep enough to hold what can be transferred within one hblank: 1232 cycles/hblank / 16.78 cycles/us / 3.84 us/u16 = 19.1 words, rounded up to a nice round 32. Would a FIFO 32 u16s deep be too big to implement cheaply? |
If I have to go a different route, then I'd go with a larger CPLD (in terms of both macrocells and pins) and have a framebuffer, and arbitrate between writes from the GBA and reads from the display controller. That way the GBA would write when it needed to, rather than having to write a continous stream of data. (If I was using an FPGA, I could use more registers, and probably set up a FIFO internally to the FPGA, however FPGAs tend to be SRAM based and need programming after power-up.) The additional cost of the larger CPLD / SRAM probably works out the same as an external FIFO.
| tepples wrote: |
| Let's see... 3.84 microseconds per u16 times 16.78 cycles per microsecond is about 64.4 cycles per u16. You'll prob-ab-ly need a bigger FIFO. |
It's one of those things where it might just work - it's always easier when you know something definately one way or the other :-)
I do think it's on the edge of what's possible, so I might do a little more research, if only to discover more about the GBA's DMA system.
| tepples wrote: |
| There is no DREQ line on the cart edge. DMA channel 3 can be triggered now, on vblank, or on hblank after lines 0-159. DMA channels 1 and 2 can also trigger on the sound FIFO, but they can't transfer to ROM space, so you can't just fool the HW that way. |
I'm a little confused about this...I thought pin 31 was the shared /IREQ_L and /DREQ pin?
According to GBAtek...
| Quote: |
Game Pak DMA
Only DMA 4 may be used to transfer data to/from Game Pak ROM or Flash ROM - it cannot access Game Pak SRAM though (as SRAM data bus is limited to 8bit units). In normal mode, DMA is requested as long until Word Count becomes zero. When setting the 'Game Pack DRQ' bit, then the cartridge must contain an external circuit which outputs a /DREQ signal. Note that there is only one pin for /DREQ and /IREQ, thus the cartridge may not supply /IREQs while using DRQ mode. |
Presumably the reference to DMA 4 is a typing mistake, but this hints that this mode of operation is handled differently from the other modes. It is a little ambiguous - it may act like I hoped - or (unfortunately) more likley - the assertion of /DREQ tells the GBA to initiate the entire DMA transfern (i.e. it would operate like it does in all other operations, except it would start on a different event).
Anyway, I shall put this to bed for a while - pending any further revelations :-)
#10015 - ampz - Sun Aug 24, 2003 7:12 pm
It should be possible to trigger a DMA transfer on pin 31... The main reason for this pin's existence is after all stuff like GBA cameras and TV-tuners. Stuff that requires DMA transfers.
#10021 - tepples - Sun Aug 24, 2003 9:08 pm
The Game Boy Camera did not use a DMA channel. Heck, the Game Boy didn't even have a DMA channel that could read from the cart and write to VRAM; like the NES's OAM DMA, it was a fixed-function DMA that could read from RAM and write to OAM. (Generalized DMA didn't enter the Game Boy platform until the Game Boy Color system was introduced.) There was almost definitely a full-frame FIFO involved.
Likewise, the GBA camera and TV tuners might just be operating off an hblank DMA, with a large enough FIFO on the cart side.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#10025 - Cyberman - Sun Aug 24, 2003 10:20 pm
| tepples wrote: |
The Game Boy Camera did not use a DMA channel. Heck, the Game Boy didn't even have a DMA channel that could read from the cart and write to VRAM; like the NES's OAM DMA, it was a fixed-function DMA that could read from RAM and write to OAM. (Generalized DMA didn't enter the Game Boy platform until the Game Boy Color system was introduced.) There was almost definitely a full-frame FIFO involved.
Likewise, the GBA camera and TV tuners might just be operating off an hblank DMA, with a large enough FIFO on the cart side. |
Yes but I believe Ampz said GBA camera.
And yes /DREQ /IREQ is both dma and interrupt input. It all depends on how it's configured.
As for the original persons concern/worry about cost etc. Ummm.. to be honest it's not going to be cheap no matter what you do, an FPGA may be the only thing that has enough 'macro cells' to interface into an LCD, depending on what type of LCD you are trying to interface into.
I believe you might be better off using epsons LCD controlers, it's silly to try to do this using a CPLD or FPGA unless you specifically need to have extra logic. Epson and toshiba make decent controlers, for the specific toy you are planing to use though it appears that it's interface timing is kind of interesting.
I suggest reading this for there embeded controllers with memory (epson).
Heck just look here and here then get what you want from epsons site. Unless it has really weird interface demands, those will serve you much better than trying to do so with a CPLD (too few cells) and DMA (you won't have enough time to do anything most would be spent refreshing the display). The devices for cameras are less likely to be useful namely because you will need to be able to mount BGA devices as well as have fun trying to get a sample part (they are mostly for things that are in 100K volumes).
Have fun.. all things are possible, just not all things are practical ;)
Cyb
#10031 - duncanentwisle - Sun Aug 24, 2003 11:43 pm
| Cyberman wrote: |
| I believe you might be better off using epsons LCD controlers, it's silly to try to do this using a CPLD or FPGA unless you specifically need to have extra logic. Epson and toshiba make decent controlers, for the specific toy you are planing to use though it appears that it's interface timing is kind of interesting. |
The Kopin CyberDisplay's interface is interesting - I could have done something to translate between the output of a semi-standard LCD controller, but it would probably have ended up using just as many gates. (In case you haven't heard about Kopin, they produce micro displays [very, very, tiny] 'LCD' displays - I'm trying to make a cheap wearable computer.)
| Cyberman wrote: |
| As for the original persons concern/worry about cost etc. Ummm.. to be honest it's not going to be cheap no matter what you do, an FPGA may be the only thing that has enough 'macro cells' to interface into an LCD, depending on what type of LCD you are trying to interface into. |
It uses 64 register macrocells, and (if my memory serves me right - it was yesterday :-) 17 logic macrocells according to Xilinx WebPack. So it fits into a 128 macrocell CoolRunner XPLA3 CPLD - they only cost $8-$10 in 1-off quantites, so that's not too bad - admittedly I'll need to spend another $3-4 on an SRAM, but its still not massively over-budget. (This is the USB version - I've put the GBA version on hold for the time being -sorry about that).
| Cyberman wrote: |
| Have fun.. all things are possible, just not all things are practical ;) |
True - that's why I had to go with the separate frame-buffer in the end - but it was good to learn a little more about the GBA's DMA handling on the way.
#10035 - Cyberman - Mon Aug 25, 2003 3:48 am
I take it you are using it for 3d glasses or something :)
Well have fun as I said, looks like you've got it under control..
Speaking of which does anyone know what the LCD connections are on the GBA?
#10049 - ampz - Mon Aug 25, 2003 8:07 pm
| Cyberman wrote: |
I take it you are using it for 3d glasses or something :)
Well have fun as I said, looks like you've got it under control..
Speaking of which does anyone know what the LCD connections are on the GBA? |
Yes, the LCD connector is very well documented. By Nintendo (!!!)
The name of every single LCD signal is right there on the GBA PCB.
#10102 - Cyberman - Wed Aug 27, 2003 2:37 am
Ok .. thanks now I shall sing 'If I only had a brain".
LOL!
Cyb - <wanders off with the big box of screwdrivers>