DVD Drive IO voltage

[emu_kidid]

Nice, work with me to get actual support into Swiss so that you don't need those ugly buttons

[pyroholic]

Thank. Swiss support sounds really nice, and I guess that it could be used to control any of the features using custom commands on the drive bus. Although I think some button support is necessary to switch iso file on multudisc games, or are there any other neat ways of doing that?

I will not be selling this as a product but I do plan on releasing the source. But I want to get it to a more complete state first and also add proper documentation and instructions on how to get it running so that it will be usable and easy for other enthusiasts to add features etc.

[novenary]

You could actually switch the discs from software with some trickery (a Swiss patch to detect a button combo on the gamepad for example).

[emu_kidid]

It depends on how much room you have for logic on there. I was thinking, there'd be some pre-setup by Swiss or whatever via a custom drive command where the "next disc offset" is given as well as the current disc offset. Then, to switch discs, just have it so that if the "next disc offset" isn't empty, it will know when a 0xE3 is given by a game, it will simulate a lid open/close and then use the alternative disc offset.

[pyroholic]

That sounds like a good idea, and I think it should be possible to implement it on the software software. The hardware does not consume much logic either so there should be no problems if any modifications are needed.

[pyroholic]

I have started working on the DMA engine for the drive and are pretty close to get it working. The DMA engine seem to transfer data correctly but something else is causing issues, my guess is that it is related to timing when finishing a transaction. But it shouldn't be too hard to figure it out.

[emu_kidid]

Nice work on the DMA engine, should be great when it's done

It's also probably best to try to get the interrupt handling perfect too like when a command with DISR=0x7E is issued to the drive to clear the interrupt too, the WKF/WASP does a bad job at this.

[pyroholic]

I got the DMA engine working now, it was a bug in my driver code that made the driver freeze after triggering a DMA transfer. I started tweaking the size of the DMA transfer sizes and ran into another snag though, when the DMA queue is large enough the cube freezes at boot time. My guess is that i transfer bytes to fast on the drive bus resulting in that the receive buffer overflows. Currently the transfers run at 12.5 MHz which seems to be too fast, or at least the throughput is too high since the real drive seems to be outputting at ~13.5 MHz but when i looked at the transfers with the logic analyzer it seemed like there were "pauses" every now and then which limits the throughput.

Currently I have no handling at all of interrupt requests and I'm not completely sure how it works either. From what I understand the CPU requests an interrupt by pulling the interrupt signal high, and then waits for the drive to break the current transfer and acknowledge the request. But I'm unsure of how the drive actually responds to acknowledge it and I'm not sure how to handshake it either.
My guess is that the interrupt signal is pulled low by the drive to acknowledge the interrupt, at least to judge by DISR bit0 (value 0 means interrupt has completed).
I'm also guessing that the interrupt signal is tri-stated with a pull-up and driven low by the CPU during normal operations, and then the CPU "releases" the output on the pin which is then pulled high by the pull-up, and after that the drive responds by pulling the pin to 0. But when would the drive release the pin? Immediately or when the next command is issued? Implementation should be simple if I know how it should work, but for now I have left it as it is.

[pyroholic]

I have done some improvements for the DMA engine, i rewrote the device driver to support splicing so that data can be transferred without doing copies by the CPU between kernel buffers and userspace buffers, so now it should function by DMA->dma-buffer->DMA instead of DMA->dma-buffer->user-buffer->dma-buffer->DMA. It is still pretty basic since it only transfers one page at a time, but the plan is to configure the DMA engine in scatter-gather mode so that larger chunks can be transferred at a time and reduce setup time and transfer all pages at once. I also plan on using two buffers to alternate between so that the next block of data can be transferred to the second buffer while the first buffer is transfered to the drive interface. That should reduce overhead for setting up transfers. I have also changed the DMA transfers to be interrupt-driven so that the CPU can do other stuff while waiting for the current DMA-transfer to finish.

[emu_kidid]

When you say "so that the CPU can do other stuff", you're talking about the CPU on the DVD replacement?

[pyroholic]

That is correct, I'm currently not sure what could be useful to do, but having the possibility is nice. Memory card emulation will most probably not need the CPU much either except during writes.

[pyroholic]

I finally got the scatter-gather DMA working, so now it's just some cleanup of the driver code so that it's a bit more readable and efficient. The DMA specific functions in the kernel was a bit tricky to figure out, so it took some time going through some of the kernel source code but at least I know enough for this purpose. I'm currently trying to decide what to implement next, audio streaming sounds like fun, but I need to read a bit to figure out how it works. I have only found very lite information about it so far, but I have pretty low confidence in my Google skills, so if any one has some documentation on this it would be nice. Btw, can the drive process regular read requests while streaming audio? Or is it limited to only streaming audio or reading data?

[tueidj]

Streaming audio is started by sending an offset and length (specifying the range of audio data) to the drive. Then while it's playing another offset and length can be sent to specify the next range that will be played when the current range reaches the end, otherwise it loops. If the new length is 0 it will stop playing instead of looping. The drive is expected to be able to perform regular reads without disturbing audio playback, although game makers are meant to try to minimize seeking to avoid buffer underruns.
There are also a few commands to get the status of audio playback (playback status, current offset, current range begin, current range length).

[emu_kidid]

Also pyroholic, Wave Race (any region) is perfect to test when implementing this, it reads data and plays audio as soon as it boots up.

CrazyNation had documented the various 0xEx commands, I have that backed up if you need it.

[tueidj]

Eternal Darkness is better, not only does it play audio on startup but it will freeze if you don't get the status command right.

[megalomaniac]

immediately, eternal darkness is better for initial testing...
but after that, waverace would be better for long term stability testing..

[pyroholic]

Thanks for all the input. It should be fairly simple to add a channel to the DMA controller that transfers the audio stream. Then also add a decoder for stream in the fpga plus a thread in the application to control audio streaming. Time to get back to the drawing board and plan

[pyroholic]

It's been a while since posting in this thread, I have had a lot of other stuff going on preventing me from doing any work in this.

Anyway, I have been working with audio streaming the last couple of days and have a working decoder with a separate DMA engine feeding it samples. I spent some time verifying the implementation in simulation using a test bench and seem to have gotten it right. The decoder is implemented completely in the FPGA fabric and is basically a FIFO buffer being fed by a DMA controller, the samples are then decoded and fed to a second smaller buffer before being transmitted to the serial interface.

I wrote a quick kernel driver and tested it out by sending dummy status responses to the cube on audio status commands while manually streaming a track using test program. It seems to be working quite nicely with streaming music in the speakers without any distortions. So far so good, so now it's time to start working on the software side to start streaming correct data from the iso file. I plan on letting the main thread keep processing all drive commands and send audio commands to a separate thread that transmits the data and keeps track of current position in the stream etc. It's starting to get quite fun again

[meneerbeer]

Awesome to hear this!

I rewrote most of my stuff according to your suggestions. It is not working yet, but the design is a lot more simple. I see a lot of similar problems compared to the previous implementation, such as Wind Waker booting and then only issuing a 0x12 command after which it hangs. I think I will have time to work on it in about a week again.

[pyroholic]

Hope you get it sorted out, nothing beats the satisfaction when you get your stuff working after hors of frustration

I have gotten the audio streaming mostly working I think. Eternal Darkness boots and the poem sounds nice, and background music seems correct as well.

I tested wave race as well and it seems to be mostly working. Background music works for a while but stops at some point and after that it's silent, so maybe reloading after finishing a track is broken. I'll see if I can sort it out tomorrow.

[emu_kidid]

You've been teasing us long enough, time for a video

[pyroholic]

You've been teasing us long enough, time for a video

I'll see what I can do about that

Anyway I think i have figured out why the streaming audio stops working in waverace. It seems that my audio thread sleeps while waiting for transfer complete interrupt from the DMA controller after the stream has been cancelled. I reply directly on the command and my guess is that the game turns off the left/right channel select signal on the audio interface and then my streaming interface stops clocking out data, causing the DMA controller to wait for the buffer to empty which never happens. And thus the status of the stream will continue to be "playing" while it is actually just chillin' waiting for the rest of the buffer to empty.

Does the drive wait for the current buffer to finish before responding to the command? Or does it simply cancel the stream? I have two options to fix it i guess, either wait for the buffer to drain before responding to the command or simply kill the DMA controller. Anybody that has any input?

[tueidj]

Cancel should stop the stream immediately. The only thing you should wait for before completing a cancel request is for any in-progress reads of the raw ADPCM data from the disk/iso to finish.

[pyroholic]

Cancel should stop the stream immediately. The only thing you should wait for before completing a cancel request is for any in-progress reads of the raw ADPCM data from the disk/iso to finish.

That seems to have done the trick, i took the simple approach by flushing all DMA transfers and the ADPCM buffer and then respond to the drive. Now waverace works pretty decently and switching songs works as expected and the music does not stop anymore. I have a new irritating issue though, when browsing through the menus at some times the sound gets distorted after switching song. My guess is that the DMA engine is not fully done when I'm turning the decoder back on causing misalignment in the sample stream. I probably need to sync this between threads somehow without causing deadlock, but I'm getting there.

Edit: I took a look at the debug terminal while the noise appears and it was as I suspected, waverace sends the stop audio command and as soon as I respond the start stream command is sent. But I think I have figured out how to synchronize without any risk of deadlock between the threads so I will give a try later this week.

[meneerbeer]

Congrats! You seem to be adding new features and tackling bugs at the speed of light!

Really interested in seeing the loading speed of this thing.