Sega Katana Devkit Issues

Heya, recently got my hands on a Katana devkit and had done some preliminary checks on it.

Ran the self-test and it all turned out OK (except the ACIA NGed since it needs the midi cable).
Was able to get it communicating to my PC on Windows 7 and ran DACheck and GDWorkshop. The DA passed all tests but the GD-M has been having issues.

Originally the HDD was failing to be read by the software, but turned out the partition was FAT16, formatting to FAT32 fixed that (there was no games other than what the previous owner had, so no worries!). DACheck is able to copy all it's memtest files over and start the program but fails with the error

"GD-M Test Error: ID Command Failed (EIDE interface suspect)"

Also GDWorkshop can switch between GD-ROM and Emulator modes properly. However no matter what mode, the OS keeps saying "Please wait disc is being checked". Opening/Closing the gd-drive does nothing, though the disc does spin up (but it doesn't sound like it's reading). The boot animation doesn't play either, only shows the DC logo (my assumption is it's trying to auto-start the disc). The OS isn't frozen or anything as the background is animating but the msg doesn't disappear.

Was hoping to start porting my engine to DC and using this as an aid. Any idea where to start looking?

DACheck and Self Test is attached.

Edit: Just noticed the firmware for both are not the latest version (2.9.1b). I wonder if reflashing would do some good? Would have to find a proper winxp machine as I don't trust the Win7 aspi drivers.

 

Also it seems to be able to debug code, but loading in QuickTest it halts on the line attached.

Update: Actually a lot of code runs, can't find where it crashes specifically but I get a crash at 0xA0000116 it seems. Callstack says gdfscurdir + 0x13f9e8c2. Seems to be matching the GDROM issues?

 

Nice progress so far getting it working.

Took the chance and reflashed the boot rom. GD-M was working after the fact! Even can see the boot animation now. However checked again an hour later and now the hdd isn't being recognized by win7. Ughhhhhhhh, did the hdd fail?

Also before I flashed I attempted to do another self-test with the rotery set to '9'. Now all self tests show "Critical Error 0x29E00000" on a red screen. Ughhhhhh. Wonder if that eprom is failing. Anyone got a rom of Set5 Checker v0.71?

 

symptoms sounds like bad BIOS flash ROM chip, in this case checksum protection will fail and access to IDE/ATA (GD-ROM drive or GD-M) will be blocked.
can you dump BIOS area (first 2Mbyte of address space, 0xA0000000 - 0xA01fffff) via debugger to check and compare ?

afaik there is no Checker v0.71 ROM dumps public available.

 

I had compared the two bins before reflashing and a single byte had flip from 0 to 1. Reflashing fixed that issue and now the boot rom matches the rom file in the R10.1 sdk. It also matches the same binary at 0xA0000000 (See last post).

Damn, that's too bad. I don't understand how the checker could've broken itself. Attached the error. It's not *too* bad as the emulator/debugger is the more important part and it's working now (sans hdd no longer being accessible) but ugh. Tested QuickTst.elf and it ran fine after skipping the GDFS code.

I dumped the (I assume) corrupted checker bin. Here it is. If I can get my hands on the 0.41 copy that supposedly is floating around, I can see if I can manually fix it.

Interesting: https://assemblergames.com/threads/katana-flashing.62647/#post-899697

This guy had the same issue. I did some stepping in Codescape and at least know that it's falling into an error handler and the code is a hardcoded number (which probably was to be looked up in a manual somewhere). Found a v0.41 rom but too many code changes have happened to just diff it.

Set 5 Checker V0.71 Rom Dump Attached for anyone who wants it. It is A-OK.

 

can you look at checker chip ? it is socketed EEPROM, at it's label usually printed "checksum" number (simple byte sum of whole ROM). your dump have it 7676h

ERROR:E2xxxxxx means "flash is incorrect", 128Kbyte data/settings flash ROM. error is shown if 1st 2 bytes in protected sector (@1A000h) contains not expected value.
you may dump it and check, at 0xA0200000 128Kbyte, in dev.box it should be empty 0xFF-filled.

 

Will do once I am done work. Interesting! So the ROM might be fine? If so we got a copy of the v0.71 dump . Will edit this msg after checking in 4h.

Edit: Haven't opened the devkit yet, but I attached the dc_flash. It is not all 0xFF (see 0x1C000). Reading some docs on the flash memory and it seems this is "partition 2".

PS: Any info on the different error codes? How do you know what 0xE2 means?

 

yes, checker ROM seems fine, at least bytesum match chip label photos I've seen in the net. and yes, much thanks for dumping it

from it's code disassembly. on my end, I've had error 0xE5 in emulator, which kind of "unexpected/wrong CPU type"

 

Yay . Hokay, so I've dumped the dc_flash, check the post above your's. There is some data in it.

Hmm, read in another post:

And at 0x1A000 of that rom it's just a bunch of 0s. Is the whole rom suppose to be 0xFF? Could this be the cause?

 

looks not good, there should be no 0-filled areas.
the important bytes is at 0x1A000-01 - if 2 bytes here will be not equal 0xFF 0xFF or "00" (ASCII) or "10" or "11" or "12" - you'll get "critical ERROR:E2".
you may try to reflash boot ROM (which is also erase data flash ROM) again and again, this may help.. or vice versa make it worse, if flash ROM ICs is nearly dead.

it is also worth to measure power voltages and check if they good and stable (for the case if flash ROMs is actually good, but all the problems because of low/unstable power, or dead capacitors or smth else like that)

 

Interesting. Is there a way to flash JUST the flash mem? Using codescape maybe?

 

I don't know, at least not "click here to erase" type.
but you may try to write code, which will send "Chip Erase" JEDEC command to this flash ROM, compile and run it via codescape.
see attached datasheet

 

Thanks. Tried reflashing and just remembered: The flash actually ends like 15s earlier than it says it would (with a Flash Complete!) message. I wonder if that 15s was for the flash memory and it's aborting for some reason?

 

basically code should be like:
*(volatile char*)0xa0200000 = 0xf0; // reset
big_delay();
*(volatile char*)0xa0200555 = 0xaa; // chip erase 6 cycle command
delay();
*(volatile char*)0xa02002aa = 0x55;
delay();
*(volatile char*)0xa0200555 = 0x80;
delay();
*(volatile char*)0xa0200555 = 0xaa;
delay();
*(volatile char*)0xa02002aa = 0x55;
delay();
*(volatile char*)0xa0200555 = 0x10;

PS: this will not work if some flash sectors was write protected (normally they are all R/W in dev.box). in this case ROM might be erased or programmed only if lift off /RESET pin and connect it to +12V

 

MetalliC you're a lifesaver!!!!

Code worked! Checker is working again! However yeah will see if I can find someone to look over the electronics to make sure nothing is failing. Also now that I am running the tester again, there is a "Flash Memory Read/Write Check". I wonder if I reset/powered down the devkit while it did that, causing corruption.

Only thing left is to test the HDD to see if it failed. I know it did work before.

 

glad to see it worked.
and yeah, I strongly recommend to find someone who can check PSU and electrolytic capacitors, it is cause of most of problems in >10 yr old electronic devices.

 

Well investigating what is causing the HDD to stop appearing. It seems there is a bus conflict on SCSI #0. GDWorkshop is detecting the drive but can't access it. Dunno why the drive is appearing on all IDs though. Before this I pulled the drive out and chkdsked it and it was fine.

I can't recall what happened to start this issue. After reflashing the GD-M started working (it was mountable, but elfs wouldn't run). Then some time later this bus conflict started.

 

Hello,

Which OS & ASPI drivers are you using ?
If Win7 & MekugiAspi v. 0.2, try with v0.1 I would say... you never know...

 

Tried with Win7 and MekugiAspi v0.2 as well as WinXP in a VM with adaptec aspi. However the latter always had weird bus conflicts so can't verify. Will give v0.1 a try.

Edit: No dice. I think it's internal to the devkit as when booting the PC, you'd hear the drive access at the bios as well as on Windows load. Now it only happens when the kit is booted, or when hitting the SCSI Bus window.

The HDD LED on the case flashes, but the HDD's own green LED does not (probably due to this internal conflict).

 

Some info from the help menu:

"The internal emulation drive is preset to SCSI ID 0 and the emulator’s initiator ID is set to SCSI ID 7 on the SCSI bus. Any additional devices you connect to the SCSI bus must be configured with SCSI IDs between 1 and 6. All devices on the SCSI bus must have different SCSI IDs."

"Additional Devices" would be the GD-Writer and and external HDDs. So the drive isn't being set to ID 0 or the initiator id is messed?

Idea: I could throw a jumper on A0 of the HDD to set the ID to #1. Might clear the bus conflict. This sounds like a termination issue TBH, but unsure what an improper termination looks like. I do have Active SCSI terminators attached.