SpritesMind.Net

When 68K is stalled, the 80 continues to run until it accesses 16bit area, then Z80 will get stalled aswell. The bus is locked when stall is in progress (either FIFO overflow attempt or DMA).

Thanks for the information Nemesis. I implemented it as you have said and it seems to be functioning fine. I guess that explains why there is an EMPTY flag on the VDP, it means you can check it before you do a ctrl write and know whether the 68K will be locked.

I did a quick test and Outrunners, Legend of galahad and Chaos Engine/Soldiers of Fortune all use VDP code 2 with writes. I tried putting this code into CRAM/VSRAM/VRAM and none seem to be correct (ie the games have graphical issues with them). They don't DMA with them just normal writes. Besides the possibility they do nothing, the other alternative is maybe it's a way to access other internal RAM, like possibly the SAT ram?

In regards to 1100b writes (8 bit VRAM) do you know any games which use this? If you have any test roms which you used in regards to testing FIFO reads (and the bits which aren't changed, etc) it would be nice to test my implementation in RetroCopy.

I did a quick test and Outrunners, Legend of galahad and Chaos Engine/Soldiers of Fortune all use VDP code 2 with writes. I tried putting this code into CRAM/VSRAM/VRAM and none seem to be correct (ie the games have graphical issues with them). They don't DMA with them just normal writes. Besides the possibility they do nothing, the other alternative is maybe it's a way to access other internal RAM, like possibly the SAT ram?

Well I tested performing writes to every VDP code value, and confirmed that only 0001 for VRAM, 0011 for CRAM, and 0101 for VSRAM, cause any visible effect on either VRAM, CRAM, or VSRAM. I know that attempting a write with a code value of 0010 doesn't make any change to VRAM, CRAM, or VSRAM, but I can't rule out that there may be some other side-effects which I failed to notice.

I think it's most likely just a programming bug to attempt a write with a VDP code value of 2 though. Note that in order to set the VDP code value to 2, it means the lower 2 bits of the command code need to be set to 10, which is what triggers a register write. In other words, it looks like the programmer forgot to set the write target and write address before performing the data port write, or accidentally performed a register write after setting up the write target, but before writing to the data port. It's easy to do, I've done it many times in my own testing. It's also easy to have happen if interrupts aren't being masked when the VDP is being accessed, and interrupt routines alter the VDP state. Since writes to invalid targets don't appear to have any effect, the only way a programmer could notice this bug is to see that a write that was supposed to occur, didn't. It's quite likely invalid writes like this have crept into a lot of mega drive games and never been picked up in development.

In regards to 1100b writes (8 bit VRAM) do you know any games which use this?

I don't know of any games which use the 1100 read target, I only found it through hardware tests on undocumented code values.

If you have any test roms which you used in regards to testing FIFO reads (and the bits which aren't changed, etc) it would be nice to test my implementation in RetroCopy.

I don't have any test roms saved which would be useful. Mostly I just start with some code, run it, observe and record the results, tweak it, rebuilt it, run it again, observe and record the results, etc. When looking for undocumented behaviour like this, it's mostly just asking myself all the "I wonder what would happen if..." questions, and testing them in the hardware as I go. I have my testing notes and results, as well as the last version of the source I used to perform the testing with lots of different tests, most of them commented out, but I haven't built a test rom which you can just run and will report what is and isn't done correctly. It's a good idea though, I probably should make a test rom to validate all kinds of port access behaviour and quirks, since there are a lot of them. I still have a lot of questions myself though. I still need to do a lot more testing on DMA copy in particular. Maybe once I'm finished with port access testing, I'll build some comprehensive test roms to validate port access behaviour.

Indeed you would think VDP code of 2 is likely a bug by programmers. Chaos Engine seems to write a lot using code 2 just before the character select screen, but then does complete CRAM/VRAM writes to setup the screen after that. Sort of like whatever is happening with code 2 is a mistake. Interestingly enough if you force those code 2 writes to CRAM you get this sort of inverted "fade in" before the proper fade in. I can just imagine the programmers comments going "run this CRAM loop twice, doesn't work if you do it once".

I guess however it might be worth finding out if it's another internal RAM. The major one we know of is the SAT. The test for that may be more difficult, would be more a visual test. ie Placing all sprites on the screen then writing some data with code 2 to see if anything changes.

Your homebrew programming sounds a bit like mine, so I understand that. More test roms are always welcome by emulator programmers though, your CRAM ones (and videos) were used a lot over here.

Eke wrote:Out of topic, but still regarding Soft-Reset, it's not completely clear what happen exactly: an example with the game Defender in Williams Arcade Classic that was discussed some time ago on another topic. In all emulators (that supports soft-reset off course), if you do a soft reset after this game starts then select it again, the start menu will be corrupted as if VRAM was not setup correctly. I verified this does not happen on real hardware.

Maybe it has something to do with memory refresh during RESET ?

About that, I recently figured that, after a soft-reset, this game was writing a wrong value to the VDP CTRL port as 2nd part of CTRL port setup. This ends up triggering a DMA Fill operation with an invalid code value.

Most emulators would still perform the DMA fill without checking the code, resulting in a corrupted screen. On real hardware, the DMA writes are ignored and the screen is fine. The game also tries to write the DATA & CTRL port (with the same invalid code value) during the DMA operation but they also get ignored (and this does not seem to crash anything on real hardware) so maybe the whole DMA operation is ignored when the code is invalid.