DVD Drive IO voltage

[pyroholic]

Yeah, it has been going pretty smoothly. I got the noise issue sorted out. I did manage to get the audio driver to lock up, but then by some chance it worked after I reversed the changes and changed the order that it sends the stop signal to the audio processing thread and disabled the decoder. So for now it will have to do.

Edit: The joy was short so I gave the handshaking another go and got it sorted out. I accidentally cleared a synchronization flag in the driver code for the DMA transfer handshaking when I waited for an aborted transfer to complete, so the transfer stopped correctly but it caused the next buffer to be played to never actually start. But now that is solved and no more lockup or noise for the past minutes So maybe it's time to move on to memory card emulation

[pyroholic]

I have started looking at the memory card emulation, what I have so far is a simple spi-decoder that receives commands and puts the command data in registers. I have looked a bit at the transfers using the logic analyzer and it seems pretty straight forward. There seems to be some kind of starting sequence where the cube sends the same command over and over, while the memory card responds the same command over and over until it seems to be satisfied, then the read commands are being issued. The first set of repeating commands are also written at a lower clock frequency, is this some kind of initialization like with SD-card being initalized at max 400kHz?

My general thought on implementation is to map a memory card file from sd-card to a chunk of continuous physical memory at boot and let the hardware read and write to that memory space independently, and after finished write transfers trigger an interrupt and transfer address and data length so that the software can write it back to the file on the sd-card. That way the latency for reading blocks of data will be predictably and independent of the software so I think it should work out. I will also use the sense-pin to tristate the output so that if a real memory card is connected it is used instead of the fpga.

There are some stuff that I am unsure about, are the read transactions always 512 bytes? And can the start address be aligned at any byte offset? I've looked through some code for a memory card manager (ctr-gcs) and from what i can tell this is the case, but it would be nice to have it verified.

[tueidj]

Minor details first:
- sectors are always 8192 bytes. Technically they can vary, but in practice that is the only value ever used.
- the EXI bus should always be 16MHz for talking to memcards
- different cards can have different "latencies", which allows them to specify an amount of dummy reads that will be done (i.e. bus clocking) before actual data is expected to be returned.
- sectors have to be erased before they can be written (technically not true, you can write to NAND without erasing but it won't be reliable...)
- reads and writes don't have to be sector-aligned, erases do
- writes are always small amounts of data (128 or 256 bytes?) so you can buffer them until you have received a whole sector's worth
- reads are always byte-aligned to 512 bytes but I'm not sure if they use a fixed-length
- later cards support a "fast mode" which is implemented in the SDK used for later games, support is determined based on the card's vendor ID. It enables large writes without erasing beforehand. Up to you if you want to support it, it does cut down the number of EXI transfers but can increase the complexity a bit.

You might be seeing either the unlocking sequence (performed exactly once after a card is inserted or console is first booted) or "latency" reads, most likely the latter.
The unlocking sequence goes something like this - the host sends a read command for a random address (possibly non-existent?), the card returns some random-looking data, the host permutes that data (using the card's unique ID as a seed) and tries to read again using the permuted data as the read offset. This happens a few times, if the host sends the right requests the card will say it's unlocked when its status is queried and will now accept regular read/write/erase commands.
For non-genuine cards, they don't implement this properly and will just accept any requests the host sends and then unlock successfully.

For the latency reads, a card can specify a latency index as the third byte of its EXI ID (request x0000). This makes the host perform between 4 to 512 "junk" reads after a read request is sent but before valid data is expected to be returned, presumably to clock the card so it can prepare/fetch the data from onboard NAND. Writes are handled differently; once a write/erase is issued the card is expected to clock itself internally (most NAND chips do this) and raise the external interrupt line when it's finished (the software will run a timeout handler if it takes too long).

[emu_kidid]

^^ Probably the best explanation of how memory cards work that I've ever read

[pyroholic]

Thanks a lot for the info tueidj! I have to agree with emu_kidid, very good explanation and very thorough. I think I have all the information that I need for a prototype implementation.

My general thoughts to implement the controller is to allocate a RAM region that can fit the entire memory card data, to which the memory card file will be uploaded at boot time.
The memory card controller will have direct access to the RAM through the axi bus and doesn't need to rely on the cpu to execute reads or writes.
The reads will be completely transparent since the RAM will always contain the memory card data.
Writes will have to be signaled to the cpu after completion to initiate write-back to the memory card data file on the SD-card. I have two options on the interrupt line, either signal interrupt to the cube as soon as the data has been transferred to RAM or when the data has been written to the memory card file. How long would the cube wait for a timeout? Is it game dependent?

A sector erase command will just be memset to 0xff for the RAM sector and corresponding offset in the file so probably nothing tricky there.

The axi bus is pretty fast, I'm clocking it at 125 MHz and transfers are 4 bytes wide so the throughput should be 500 MByte/s, but there is some latency setting up the transactions so I probably need some small fifo buffers in between. I'm not sure how predictable the access latency is but to initiate a transaction but to initiate a transfer to/from ram the initial handshake with the bus master is probably around 10-20 cycles@125 MHz, the RAM access latency is probably around 15-25 cycles@533MHz if i remember correctly. Depending on how many other controllers are trying to access RAM at the same the latency can be quite a bit longer depending on the arbitration. With a bus clock@125 MHz that would mean about 250 cycles to get the first burst transfer going which i think should be enough. Most of the burst accesses are 16 or 32 cycle beats so it should not be a problem. After the first access has started filling the FIFO there will be an ocean of time to get the next one going, but I guess it will be a bit trial and error to figure out if I can go with minimum latency.

Btw, i pushed the the clocking of the dvd data bus to ~21 MHz and it seems to be running stable. Are there any games that are known for slow loading times that I can test it out with? It would be fun to see how it holds up in transfer speed.

[tueidj]

I have a feeling the write/erase timeout is 10ms but I'm not positive. It's a fixed value in the SDK.
It's generally not a good idea to signal interrupts immediately, some poorly written code expects a delay to be present e.g. setting up callback parameters after sending the request that will trigger the callback...
For that reason it's also probably not a good idea to play with the DVD bus speed, I know for sure that Ultimate Spider-man will eventually freeze if it loads too fast. Otherwise try Rogue Squadron 3, it pretty much loads constantly from the disc.

[pyroholic]

I'll try out Ultimate Spide-man and Rogue Squadron some day to see how it works. There is some overhead for the linux kernel to set up DMA buffers and calculate which blocks to transfer from the USB stick before my driver can setup the DMA engine and start streaming to the dvd interface, maybe that delay is enough. It will be interesting to try it out at least.

I have gotten most of the axi-master for the memory card done as well as a small driver to map the ram buffer into userspace plus reading and writing control registers. Writing data from the application to the ram buffer and trigger a burst transaction nicely transfers the correct data so it seems pretty well so far. The latency from requesting a read until the axi burst starts seems to be very consistent, 32 clock cycles from the read request until the data is ready on the bus. With the axi bus@125 MHz and the EXI clock @ 16 MHz that is about 4 EXI clocks of latency, and it is also while streaming game data to the dvd-interface so I guess that going for the lowest card latency should not be a problem at all.

I'll probably just need two packet buffers to buffer the data for each burst transaction and keep track of the start address for each burst. That combined with an EXI command interpreter should suffice from the hardware perspective and then it's just some software to execute the read/write commands to the save file and handle the status bits/interrupt line for the memory card. It really is quite convenient to have a linux kernel taking care of most of the low level stuff

[tueidj]

The board you're using has ethernet right? You could definitely add modem support (using PPPoE) or proper BBA support if you're up for a real challenge...

[pyroholic]

Yes, it is quite loaded with interfaces, ethernet, can, spi, i2c, usb, sd, etc. It would definitely be pretty cool to implement a BBA on it, don't know how much work it would be but my guess is that it won't be worth the effort.

I have gotten both burst writes and reads working properly and fixed a fifo to buffer data for burst transfers. I'm just about to start implementing the exi-controller and saw some things that seem a bit strange to me. I hooked the logic analyzer to the input signals from the exi-bus to the memory card, from the looks of it the gamecube latches data on falling edges and the memory card on rising edges, so it looks as regular spi communication. What is strange though is when the memory card transmits the exi-id on command 0x0000, the card responds with 4 bytes of data, first three bytes are 0x00, and the last byte 0x20. The card is a memory card 251 and should respond with 0x10 in that byte according to all sources of information that I have read, and 0x20 is the id for memory card 507. I just played with the thought that the gamecube latches input data on rising edge, but then the response would be 0x80000010 which is not correct either...

I took a sample of the startup sequence as well to have something more to verify against and it doesn't look right either from what i can see. I recorded all status requests that was done after inserting the memory card and in the first response I receive 0x3 and the second one that happens after the unlock sequence is 0x83. After that there are no more status requests and loading save files works as expected. But it doesn't seem to match the status bit for unlocked card from what I can tell. Shouldn't the unlocked bit be bit6?

[tueidj]

What is strange though is when the memory card transmits the exi-id on command 0x0000, the card responds with 4 bytes of data, first three bytes are 0x00, and the last byte 0x20. The card is a memory card 251 and should respond with 0x10 in that byte according to all sources of information that I have read, and 0x20 is the id for memory card 507. I just played with the thought that the gamecube latches input data on rising edge, but then the response would be 0x80000010 which is not correct either...

Definitely sounds like the first bit is being missed... although it should be 0.
For reference, the 32-bit ID is decoded like this (starting at MSB):
- 18 bits = 0
- 3 bits sector size index (always 0/8192 bytes for all known cards)
- 3 bits latency index (4 / 8 / 16 / 32 / 48 / 128 / 256 dummy read cycles)
- 6 bits card size bitmask (only one bit should be set)
- 2 bits = 0

I took a sample of the startup sequence as well to have something more to verify against and it doesn't look right either from what i can see. I recorded all status requests that was done after inserting the memory card and in the first response I receive 0x3 and the second one that happens after the unlock sequence is 0x83. After that there are no more status requests and loading save files works as expected. But it doesn't seem to match the status bit for unlocked card from what I can tell. Shouldn't the unlocked bit be bit6?

Yes, because the first bit/cycle is being dropped. The first bit (0x80) means programming is in progress (writing or erase), the second bit (0x40) signals the card is unlocked.

[pyroholic]

That's what i think as well, but it is that incorrect one in the msb that get me wondering. I forgot to write it in the previous post but if I move the sample point and get the card status bits are correct with 0x40 an 0x1 (ready and unlocked) but the first bot is then also set so the response looks like 0xc1.

Edit: double checked the ouput data from the card, when aligning reads to the rising edge the card responds with 0x00000010 which is correct, I miscalculated the response bytes so the first 0x80 byte that i saw was not an incorrect byte 0. I noticed something else as well, after getting the status byte 0xc1 the cube sends irq command to the card so i guess that it really is busy and the response is correct. So I think I have cleared out all the interface information i need to start implementing.

[capzlk]

anything to report? this sounds like an exciting project

[pyroholic]

I have had some other stuff going on the last couple of weeks but I have not been slacking entirely.
I drew up and ordered a PCB for a HDMI expansion card for my development board, that took a couple of weeks to get here from china but it looked fine and works with no issues. So I started by porting my old VGA code, but ended up rewriting it from scratch. The expansion board has an HDMI transceiver from Analog Devices which takes care of color space conversion and transmits audio along with the video. It was the first board I've ever made so it's probably full of mistakes, but it works so I'm satisfied.

I have not done anything more on the memory card emulation, but I finally recorded a couple of videos to demo the audio streaming and HDMI output. The TV is a bit slow syncing when the video mode switches but otherwise it runs fine. Audio quality on my phone is awful so you will have to bear with it. The sound quality out of the speakers is fine though.

edit: The youtube tags does not seem to be working so I'm changing to regular urls.
https://www.youtube.com/watch?v=k-NYbWtE6bU
https://www.youtube.com/watch?v=_eD5aY0CL_s

[tesla246]

AMAZING

[pyroholic]

Thanks!

I updated the sync generation so that it is configurable from software, so each time the video mode changes it generates an interrupt. The software driver then determines which video mode that is active and configures the sync generator so that sync pulses are generated with correct placement and centers the image if it does not fill the active video. So now it is only software setup to add more video modes which is a lot faster than synthesizing with vivado.

I also added automatic disc swapping for multi disc games following the suggestion from emu_kidid so it swaps iso file and simulates lid open/close when the stop motor command is received. Seems to be working perfectly so far.

Next up will be finishing the memory card emulation and then a bit och cleanup before publishing the source.

[meneerbeer]

Sounds good.

Then I can also have a look at what you are doing different than me to see why mine does not work.