Open snickerbockers opened 7 years ago
I found an internet forum post which seemingly confirms that this is a known failure case for the Dreamcast when something is wrong with its GD-ROM drive (link)
hello i know this is and old thread but he ho i have a dc and it does boot up but no animation at the start and the dc logo stays on for about a minute or 2 after that it boots in to the normal dash menu with or without a disc and not loading anything the disc is spinning but nothing is loading as like giving me the big bird with a thanks for waiting but f u with a smile the fan keeps blowing like no tomorrow by the way
When I direct-boot a kallistios program with no disc inserted on real hardware (which I do by loading up dc-load-ip and taking the disc out before I send the elf over), it hangs after the maple scan. It does not do this when I start the same program on WashingtonDC with no disc image mounted.
Ergo, there is definitely an observable difference between what WashingtonDC does when no disc is inserted and what a real Dreamcast does when there is no disc inserted.
When I direct-boot a kallistios program with no disc inserted on real hardware (which I do by loading up dc-load-ip and taking the disc out before I send the elf over), it hangs after the maple scan. It does not do this when I start the same program on WashingtonDC with no disc image mounted.
nvm, that appears to be a consequence of a patch I put in my KallistiOS installation to make it use DMA instead of PIO. When I removed the change, KallistiOS was able to boot on hardware without a disc inserted.
Of course, it is concerning that this patch broke KallistiOS on hardware but not on WashingtonDC, however it is not necessarily the same problem.
Unfortunately I no longer have the patch because it didn't occur to me to save it before I removed it, but it was only one line and all it did was change a parameter to some function from PIO to DMA. I must remember to investigate this in the future.
Observations:
on real hardware, the DSC bit seems to be almost always set. Setting this in WashingtonDC did not fix anything, unfortunately.
When the TEST_UNIT command is sent with the disc removed, it sets the CHECK bit in the status reg.
When the TEST_UNIT command is sent with the disc removed, it sets the CHECK bit in the status reg.
Adding this to WashingtonDC makes the bios send the error info packet command (0x13). This packet is not yet implemented.
The response the GD-ROM sends after it receives the REQ_ERROR code is as follows:
0xf0
0x00
0x02
0x00
0x00
0x00
0x00
0x00
0x3a
0x00
This means the sense key is 2 ("not ready") and the additional sense code is 0x3a ("no media inserted"). This does seem like the logical response.
That did not fix it.
One observation I have made is that the bios appears to be using the same GD-ROM system calls it provides to games. It may be helpful to implement some sort of deep-inspection for this so I can see what the individual system calls are returning, so I can see where it's going wrong. This could be helpful for any problems I may run into with certain games in the future as well.
It could be some sort of problem with the GD-ROM's state transitions.
If I replace the GDROM_STATE_NODISC with GDROM_STATE_STANDBY, then it does actually do the spiral swirl animation before it gets caught in some sort of REQ_ERROR-related infinite loop.
Oops, it looks like f273ecd83739f939092ff8a5d07dd55476b7843e only appeared to help because I screwed up and hardcoded the drive state to GDROM_STATE_PAUSE...
The spiral-swirl animation doesn't work when the boot-rom is started without a disc image mounted (ie with no -m option supplied to the emulator). Instead, it immediately displays the full Dreamcast logo.
The Dreamcast logo eventually fades away and WashingtonDC crashes with the same error message as it does with a disc image mounted (that error being an unimplemented Channel 2 DMA destination). It is possible that the boot rom detects something wrong with my GD-ROM implementation and this is its way of subtly signaling the error.