DC-SWAT
Region Changer does not work correctly on VA0
Over the past month I have been trying to fix a Japanese VA0 Dreamcast that could not boot GD-ROM discs, nor could DreamShell read the disc in GD-Play.
I went through a bunch of troubleshooting steps such as recapping the main board and GD-ROM drive board, Confirming capacitor and resistor values throughout the G1 and G2 bus, replacing the BIOS chip and trying several different BIOS images, and replacing the PSU.
None of the above made a difference at all.
What did make a difference was removing the Flash ROM off another Japanese VA0 Dreamcast, dumping it, and then writing it to the non-working Dreamcasts Flash ROM. This made the games boot again. However DreamShell still could not read the discs in GD-Play. It seems that the FlashROM has some sort of setting to enable this ability to boot GD-ROM games. And that there is per console settings for things such as GD-Play. GD-Play worked on the other Dreamcast perfectly fine.
To get GD-Play working on this Dreamcast, I had to use the Region Changer to clear the flash and write the region. However this does not solve the problem on its own. Now with the current Region Changer version, there is the setting to enable a black swirl. This setting does not stick after writing, and reading again resets it to its previous value.
You can make it stick, by randomly changing region settings and making sure the option to enable black swirl is ticked, and then spamming the write button. If it hasn't stuck when reading, then you repeat this again. It could take up to 15 minutes to get it to stick. This should be fixed.
Now that the black swirl is enabled, consequently, for reasons I am not sure, after a reboot, GD-Play can finally read the discs! But now we are stuck with that black swirl. To fix this you have to repeat the steps to enable the black swirl, but to disable it.
I believe that the Region Changer app needs fixing to:
- Fix the ability to boot GD-ROM discs from the stock BIOS
- Fix GD-Play compatibility
- Be able to enable the black swirl and other options without having to repeatedly write
I would be happy to figure out how to help fix the Region Changer app and test fixes. Not entirely sure where to look since I haven't delved into this kind of stuff before but given it revived this Dreamcast - despite many failed attempts, it is quite a useful utility.
For reference, the Flash ROM chip is the MB8581-90.
I completely agree that the app needs some improvement, as it hasn't been updated in 15 years. I'll take your suggestions into account when I work on it. However, I don't think its instability is due to the fact that it hasn't been updated in a while. It's more likely that your FlashROM chip is having issues. I'll certainly double-check everything when I work on it, but I can't say when that will be yet. Thank you for the detailed description!
No worries. Definitely do not think its an issue with the Flash ROM. I have completed some more testing, which is outlined below.
There is definitely a problem/bug with the Region Changer app and enabling the black swirl. You do have to repeatedly change settings and write to enable/disable it as mentioned before. And there is a possibility that it can fix GD Play, although that was not the case when I did some extra testing today.
GD-Play will not work when hotswapping the disc (when the disc tray closed switch is pushed back) and then changing the disc from the DreamShell bootloader disc to a real GD-ROM disc and opening GD-Play. I swapped the disc when the disc was no longer spinning at the DreamShell main menu, before opening GD-Play. You have to most of the time simulate opening the disc tray and closing it again. The game should be detected then. Sometimes it will work after mucking around with the flash settings as mentioned before.
I have noticed that DreamShell can be incompatible with the stock BIOS which in my case is v1.004, resulting in a date/time reset whenever you boot DreamShell and then go back into the BIOS. This does not occur if you don't boot DreamShell. The incompatibility happens when you use the Region Changer to clear the flash whilst running the stock BIOS. In order to fix the date/time loop, you need to flash the Japanese Cake v1.032 BIOS, clear the flash using Region Changer, and then reboot. After that you can then flash the stock BIOS and there will be no more reboot loops. Unless you use the Region Changer to clear the flash again.
I still do not know why the Flash ROM initially became corrupt to the point that you could no longer boot the real games regardless of whether they were detected in GD-Play. I am planning to get a dump of my Flash ROM in this non working state, and a working state to compare the differences and hopefully find what is required in order to restore the ability to write these games. Hopefully Region Changer could be updated with this fix.
More interestingly the stock Flash ROM (MB8581-90), can become writeable without pulling RESET to 12V. It seems after I wrote a good dump to it using a SuperPro 6100N this became possible. All I did after taking the chip off the board and putting it in the programmer was using the SuperPro 6100N software to disable sector protection. Then erase and reprogram the chip using the good backup. I selected MBM29F002TC as the device. After resoldering the chip on the board and testing the Region Changer, I found I no longer needed the RESET to be pulled to 12V in order to enable write support.
I will post back here once I have found the differences in the FlashROM that enable/disable the ability to boot games.
The black swirl isn't a feature at all. It's a vulnerability in the BIOS code that allows you to bypass the specified conditions and use a neutral, black color for the swirl. It's just an experiment; it's best not to use it at all. I wanted to remove this feature altogether because I'm afraid it could cause harm. Regarding some flash ROMs being flashed without unlocking, yes, this happens sometimes; I have one like that too. But most often, you need to unlock the flash ROM partition with factory settings to write to it, because by default, that partition is write-protected, while all the others are unprotected. However, unlocking must be done temporarily, i.e., with a switch, since leaving 12V on all the time is not an option, as the chip could be damaged.
For what its worth, I have been running with the black swirl setting for quite a while now and I have had no issues. I don't believe a flag in the FlashROM would cause any problem. I mean you can actually boot the console without a FlashROM soldered to the console.
I have repeated the sector unlock process on another Dreamcast using the SuperPro 6100N and it was successful. No longer had to have the switch to enable/disable write by pulling RESET to 12V. So thats awesome.
Also have soldered a socket to this Dreamcast so I can further test FlashROM modifications, in order to determine what exactly is needed to boot GDROM games.
I might try and add some features into the Region Changer app myself, such as enabling/disabling the sector write protection, which is the first 3 sectors of the chip from what I can tell.
I might try and add some features into the Region Changer app myself, such as enabling/disabling the sector write protection, which is the first 3 sectors of the chip from what I can tell.
It would be great, because I’m very busy with the port on NAOMI at the moment. Come to DreamShell Discord and I will help you if you have any questions while making changes. There is very old code there, I don’t even remember what’s what :)
No problem. I will have a look at joining the Discord soon.
I have tested a bunch of configurations with the FlashROM. Based on my testing, all of the FlashROM can be cleared except for the factory settings sector. The other sectors will be recreated by the console on setting the time for the first time, and running a game for the first time.
I can reproduce the issue with the console not booting GDROM games successfully, by modifying the first two bytes of the factory settings sector to anything but 0x30. So it seems that Region Changer should be updated to also set these two bytes to 0x30 as well in order to properly restore booting GDROM games if those are corrupted.
Is there any more information on the factory settings sector? I understand bytes 3, 4 and 5 are to do with the region, broadcast and language settings, the first two bytes are required for booting GD-ROM games. But the rest of the top section maybe a console ID, but not sure. Then there is a section that from what I can tell lists all the developers of the Dreamcast. And finally some 3.4KB section of binary to which I am not sure what it does.
In fact the console can boot fine and run GDROM games with a factory sector that is filled with random data except for the first 5 bytes as mentioned before. Has anyone tried to disassemble that binary section? I have attached my factory sector (renamed as .txt so it uploads), so you can have a look at it in a hex editor.
flashrom_factory_sector.bin.txt
Yes, after the regional information there's an 8-byte ID. I don't know what else it is. Not all games will work with a clean FlashROM or one that's full of junk. Try Crazy Taxi 2, for example; it crashes on my NAOMI without FlashROM, so I'll have to add emulation from file to ISO Loader for NAOMI. Also PSO v2 won't work without an ID. You need to test different games.
Do you know the offset for that 8-byte ID? I can't see to find information on it anywhere.
I did some extra testing and its definitely dependent on the game being played. There are games such as Power Stones 2 that run without any FlashROM installed.
Both Crazy Taxi and Virtua Fighter 3tb will not boot unless the first two bytes on the factory settings sector are 0x30, 0x30 - they did not care that the rest of the factory sector was junk.
Crazy Taxi 2 did boot to an initial loading sign but crashed. It did however boot just fine when the factory settings sector was full of junk. Regardless of an existing FlashROM with junk or no FlashROM, it always asked if to run in either 50 Hz or 60 Hz due to no region or broadcast flags.
Obviously there is no point in having the FlashROM full of junk, but at least from my testing, I have been able to boot every game with a clean FlashROM except for the first 5 bytes of the factory settings sector. That being 0x30, 0x30, then the region flag, broadcast flag and language flag. So in my case for the defaults of the Japanese VA0, it would be 0x30, 0x30, 0x30, 0x30, 0x30.
Of course that excludes the console ID required for PSO v2, however I'm pretty much convinced that even if you were to emulate the first 100 bytes of the factory settings sector, all games will work.
The rest of the FlashROM gets initialised and setup when either the BIOS boots and you set the time, or a game is ran for the first time.
Yes, but you need to keep in mind that not everyone uses the standard BIOS, so it’s important that all the necessary data is there initially.
About FlashROM offsets: https://github.com/DC-SWAT/DreamShell/blob/master/firmware/isoldr/loader/include/main.h#L32
Yeah that is true. I haven't tested on all BIOS yet, however I have tested it on the stock BIOSs and the Japanese Cake v1.032 BIOS. I am pretty sure it also works on the DreamShell BIOS but haven't fully tested.
Thanks for the links to the offset. What exactly is the FLASH_ROM_ICON_ADDR? Is it possible to open this binary section and view the data on Linux?
Yeah that is true. I haven't tested on all BIOS yet, however I have tested it on the stock BIOSs and the Japanese Cake v1.032 BIOS. I am pretty sure it also works on the DreamShell BIOS but haven't fully tested.
I'm talking specifically about the BIOS with DreamShell bootloader. There's no traditional menu for time settings and such.
Thanks for the links to the offset. What exactly is the FLASH_ROM_ICON_ADDR? Is it possible to open this binary section and view the data on Linux?
You can see all flashrom dump, of course ICON data also in it. I honestly don't remember what this is for, but I'm emulating a system call that uses them: https://github.com/DC-SWAT/DreamShell/blob/master/firmware/isoldr/loader/syscalls.c#L1502
I tested again with the BIOS with DreamShell bootloader, and loaded Virtua Fighter 3tb. After dumping the FlashROM I could see the partitions are correctly initialised from a blank FlashROM with only the factory settings sector existing. So I am pretty confident that to reset the FlashROM you could blank those sectors (not the factory settings sector), and the system will pretty much start from scratch.
It seems like the FLASH_ROM_ICON_ADDR offset is wrong as in the FlashROM the binary data starts at 0x1B240 rather than 0x1A480. 0x1A480 would put you in the middle of the developers credit text. Bit of a strange system call in my opinion.
After analyzing the binary, I cannot determine what format it is in, and if it is indeed split up into 10 different icon files with each being 704 bytes, then it is in some unknown format or encoding. I wonder what software actually reads from this. Not important anyway, and from testing factory settings sector could be blank except for the first 100 bytes which include the region information, production date/time and console ID information.
There might be a bug here. I don't remember which games actually use this call or whether they actually need anything there.
Just found this from Metallic code:
struct factory_sector
{
struct factory_record {
// everything 'char' below is decimal numbers in ASCII, unless noted else
char machine_code1; // '0' - Dreamcast, 0xFF - dev.box
char machine_code2; // '0' - Dreamcast, 0xFF - dev.box
char country_code; // 0 - Japan, 1 - America, 2 - Europe
char language; // 0 - Japanese, 1 - English, etc
char broadcast_format; // 0 - NTSC, 1 - PAL, 2 - PAL-M, 3 - PAL-N
char machine_name[32]; // ASCII text 'Dreamcast', trail is 0x20 filled
char tool_number[4]; // software tool #
char tool_version[2]; // software tool version
char tool_type[2]; // software tool type: 0 - for MP(mass production?), 1 - for Repair, 2 - for PP
char year[4];
char month[2];
char day[2];
char hour[2];
char min[2];
char serial_number[8];
char factory_code[4];
char total_number[16];
uint8_t sum; // byte sum of above
uint8_t machine_id[8]; // 64bit UID
uint8_t machine_type; // FF - Dreamcast
uint8_t machine_version;// FF - VA0, FE - VA1, FD - VA2, NOTE: present in 1st factory record only, in 2nd always FF
uint8_t unused[0x40]; // FF filled
} factory_records[2]; // 2 copies
uint8_t unused_0[0x36]; // FF filled
uint8_t unk_version; // not clear if hardware or bios version, A0 - VA0, 9F - VA1, 9E - VA2
uint8_t unused_1[9]; // FF filled
char staff_roll[0xca0]; // list of creators
uint8_t unused_2[0x420]; // FF filled
uint8_t random[0xdc0]; // output of RNG {static u32 seed; seed=(seed*0x83d+0x2439)&0x7fff; return (u16)(seed+0xc000);}, where initial seed value is serial_number[7] & 0xf
};
Need update Region Changer with it.
Awesome, that clears some stuff up. I will go through that hopefully this weekend and see what I can make of it all.
Looks like though that the data at the end is just random data. So I do not think that sys_icon syscall and offset would be used at all - or even exist?