Welcome, Guest!

Here are some links you may find helpful

Need help reviving a hkt-0120 (on various levels): GD-M, OS mode, Jumper settings?

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
Hi dear peeps,

this is my first time posting and I heard good things about this forum, and I hope I’ll find some advice here.

I recently purchased a Dreamcast Katana hkt-0120 and I ran into a few problems setting it properly and getting it to work.

Apologize the lengthiness of the post, but I have several problems and hopefully this community can help me.
I also should mention that I also have a (mostly) running Set4.

Here are the main problems:
  • I can flash the DA and GD-M, but when I want to flash the boot.rom, the process goes through but in the end tells me “re-flash timed out, turn slider switch to the right” even though the switch is in the right position.
  • When I set the system to OS mode, the screen on the TV stays all black (even though the dip switches on the hkt are set correctly)
  • When I boot the system, the DA and the GD-M light start lighting up, the GD-M LED on the hkt recognizes the disk but then the hdd "clicks" once and will not let me write on it under windows or format it (even though it shows in windows as removable drive). It acts as if there was no disk in the removable drive. I should mention that the HDD works flawlessly when I attach it to my Set4, so I know it is correctly formatted and terminated and working.
So what does actually work?
  • When the GD-M is recognized (but not writeable),
  • I can compile run sample elf files in Codescape, for example the Dragonfly sample, and it runs flawlessly on the computer screen attached to the hkt.
  • In Codescape, some samples work, sadly others do not such as k2quicktest (It shows the SEGA logo screen and then crashes codescape)

My boot.rom says 1.011 by the way in DBFlash Utility

Another thing where I need help:
- Even though my unit says 524 in it’s serial number on the outer case, the DA mainboard is a bit different to the 5.24 boards I can find info on.
It actually says 516 and has a few jumpers on the mainboard which the 5.24 board do not seem to have.

So I am also looking for info on all the jumper settings of the DA as I hope maybe this might be the source of the problems.

I will post a few pictures of the board and the jumpers.

Tl;dr:
  • Can someone help me flash my boot.rom somehow even with my slider switch problem, e.g. by giving me an .elf file which I run via Codescape and flash by this?
  • Can someone maybe shed some light on the DA board jumpers?
  • Anyone have an idea on how to get the GD-M going? (As mentioned the HDD works fine in my Set4)
  • Any other ideas on how I can get the system up and running?
Highly appreciate any support.
 
Last edited:

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
  • bootrom/slider switch: you might want to try with dispwitch 4 up (the one for the selftest normally) instead of the horizontal slider. On older devkits, it was dipswitch 4 in up position that disabled the flash rom protection. (Note: I never tried this, so apply at your own risk :) )
  • Codescape that crashes with SDK samples: be sure to include a GD-ROM of a game in the drive tray, the Shinobi lib checks this at the start of some sample programs (most ?), and exits the program if there is no GD-ROM.
  • JP101-109 seem normal as far as I remember. No idea what they do however, never found info on them.
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
Hi T_chan, thanks for your reply, and I think you are onto something.
So here is what happened: When I received the kit, it had a running OS mode, but it was a simple Japanese BIOS - I couldn't change regions with the rotational switch and the boot sequence also didn't have the dev bios 3D animation, so I thought it was wrong. I tried flashing the system up to the recent version in SDK R10 (1.011) but the slider Switch didn't let me flash it.

Just toying around I moved the most right dip switch up to the top position, and then the BIOS actually flashed to 1.011.

But ever since OS system now stays black, and all I want to do is flash it back down again.

Sadly now neither the left slider nor the right dip switch allow me to flash (doesn't matter what i do, I always get a flash timeout on the BIOS)

So please, if you have any Idea on how to flash the BIOS without the damn switch, e.g. by loading a flash tool as an elf file in codescape, any advice is more than welcome. It seems to me the hardware is ok, but the system just won't run on 1.011 and I can't get i down again (e.g. I have 0.976 bin file here, DAFlash would actually use it, but I ust can't get past the write protection since the dips/switch do not work)

Any idea? Any tools out there available in elf form which I could sideload via Codescape?
 

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
This might help - also never tried personally:

Brief Instructions to install Bios:
1. Make sure DIP SWITCH 4 is in UP position (this disables protection of flash-ROM)
2. Run utility/DACHECK.EXE. Exit the program and select OS Debug Configuration.
3. Run CodeScape
4. Hard-Reset Target, and Stop All Processes
5. Select File/Load Binary
6. Select the bootrom file, and load to address 0x0c010000
7. Configure a BreakPoint in order to confirm that the write ended :
Select Configure BreakPoint
Select ADD CODE
Enter address 0xac000000 in the "Location Expression" field, and then select "Assembly."
Select "Hardware" option
Click OK
8. Enable All BreakPoints
9. Set PC register to 0x0c010000 (in a new Window - set the region type to "Register")
10. Run All (F9)

You may need to wait 30 seconds for it to finish. The screen should change colour.
You will know that it is finished when Codescape reports breakpoint being hit.
If this fails to do so - please retry sequence - or call technical support.

The results can be confirmed through the color of the screen and the contents of 0x0c00000c - f.
0x0001****SuccessScreen color is white0x00c0c0c0
0xFFFF****Sector delete errorScreen color is non-white0x000000c0
0xFFFE****Write errorScreen color is non-white0x004040c0
0xFFFD****Verify errorScreen color is non-white0x008080c0
("****" represents undefined digits)

Shutdown the machine & wait for 2 minutes.
Reset machine - Dreamcast sequence should start.
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
Sadly I don't get that far.

When I run the DAcheck, the DA passes all tests fine (not the GD-M), but when I reset to OS mode and then run Codescape, I get this:

I tried to continue anyway, but I get the same error at the end when I execute (and one or two other on my way there)


16043621795821723810538382838901.jpg
 

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
Hmmm... There's another way, by renaming the bootrom to 1st_read.bin, put it in a GDWorkshop project & switching the GD-M to emulation mode, but for that you would need to have the GD-M working of course...
  • The write-only of the GD-M is very strange... which OS are you using ? Not using a VM I suppose ?
  • What the checksum of your 0.976 bin file ? (CRC-32, MD5 or other)
Via Codescape, there is also this way, but normally it's for 5.2* devkits, so not sure it will work on your "hybrid" system:
  • set dip switch 4 to UP, and boot the devkit
  • boot your windows pc
  • launch DACheck & switch to CPU mode
  • press the reset button on the devkit
  • launch codescape
  • move the slide switch to the right, and put the dip switch 4 DOWN
  • execute the Codescape steps mentioned in one of the previous posts, starting from step 5)
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
First of all, super-grateful for your support, and I honestly hope we'll get there...

As for the questions:

  • I am running on a Win 98 SE setup, not VM but actual system.
  • I'll check the checksum as soon as I can

On the proposed Codescape solution, I can set it up, but I do get an error when I load my 0.976 file (but I also have another flash call hkt-0120_flash.bin which loads as binary without an error into codescape).

Question 1 on "6. Select the bootrom file, and load to address 0x0c010000"
This means "whole file" and editing the start adress, correct? (as I can also choose things like "end address" or "length")

So I tried this solution, but the first time I do a "run all" it feels like nothing happens. If I retry, it give me the same "write error" as before.
Hope I am doing it all correctly, one question on the guide above:

Question 2) "9. Set PC register to 0x0c010000 (in a new Window - set the region type to "Register")"
Please see the picture, I can't add the 0x, as I can only enter 8 digits in the new window.
So is this the correct entry I am doing? The rest of the guide is all clear, but this one confused me:

register.jpg
 

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
HDD -> & what is the FAT system ? FAT32 or NTFS ?

On the proposed Codescape solution, I can set it up, but I do get an error when I load my 0.976 file

What error do you get when loading the 0.976 file ?

Question 1 on "6. Select the bootrom file, and load to address 0x0c010000"
This means "whole file" and editing the start adress, correct? (as I can also choose things like "end address" or "length")
Yes, you specify 0x0c010000 as Start Address, and choose "Whole file".
I think it should show a pop-up saying smt. like "Please confirm requested transfer lenght of xxx bytes", on which you should click OK.

Please see the picture, I can't add the 0x, as I can only enter 8 digits in the new window.
So is this the correct entry I am doing?

Yes, it's correct, no need to fill in 0x, it's just an indication that the address is in hexadecimal format, like the other values you can see on your screen with the registers.
 
Last edited:

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
HDD -> & what is the FAT system ? FAT32 or NTFS ?
FAT32 (both on my hdd and the scsi2sd, both work fine in my Set4.)
They also behave the same faulty way when attached to the Set5, same termination setup.
What error do you get when loading the 0.976 file ?
DBFlash recognizes it as 0.976.
Error before loading it: "Please confirm requested transfer length of 0x00200000 bytes. Error: S007M031-36629"

Some more insights:
- Running the Set5 again on DA-Firmware 3.40a (but I can upgrade it to SDK9, 10 and 11 Firmwares if needed, it's just that I am currently running on SDK4). GD-M FW is 2.3.9k (same as above, I can upgrade, but it doesn't help, so I am keeping it on SDK4 FW)

- DA-Test on DA-Check 1.3 goes to green light

- GD-Test on DA-Check 1.3 goes to red, error:
"Creating Directories for GD-M test...
Failed to create directory e:\MemTest
Deleting created files.
Removing created directories.
Emulator Switch set to GD-Rom.
Failed Test."

Thus I can't launch into GD-Workshop, as it always tells me:
"The following drives report themselves as removable but are unrecognized
E: A device attached to the system is not functioning."
And always shows as weird gibberish in the SCSI menu of GD-Workshop

1604529908640.png

- ASPI Drivers are 4.71.1 on Win98SE edition and seem ok (as I can run DACheck on the Set5)

- Don't know if it's important, but when I exit DA check and set to CPU Mode, I leave Post-Reset option on defualt (Debug Stub in cacheable memory disabled, Enable Persistant Suspend enabled)
 
Last edited:

HI_RICKY

Donator
Donator
Registered
Mar 21, 2019
379
247
43
AGName
HI_Ricky
AG Join Date
Jun 7, 2007
it look cap issue, try replace all
fast way test ~ try unplug all cross emu board cable
let it stand alone SH board boot up , so let check it a 3D boot up or fix dreamcast logo
dev kit near 80% cap issue , 15% powersupply .......
 
  • Like
Reactions: MetalliC

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
it look cap issue, try replace all
fast way test ~ try unplug all cross emu board cable
let it stand alone SH board boot up , so let check it a 3D boot up or fix dreamcast logo
dev kit near 80% cap issue , 15% powersupply .......
Sadly no luck, unplugged all cross emu board cables, booted up only the top part (pretty much only kept the cable to the video ports attached). Screen of TV stays black, dip switches set correctly though.
 

HI_RICKY

Donator
Donator
Registered
Mar 21, 2019
379
247
43
AGName
HI_Ricky
AG Join Date
Jun 7, 2007
Sadly no luck, unplugged all cross emu board cables, booted up only the top part (pretty much only kept the cable to the video ports attached). Screen of TV stays black, dip switches set correctly though.
try use AV, don't use VGA
if no cross board still no screen , every setup is right , than should be few issue
1. bad bios
2. bad powersupply
3. bad cap
4. bad SH board
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
try use AV, don't use VGA
if no cross board still no screen , every setup is right , than should be few issue
1. bad bios
2. bad powersupply
3. bad cap
4. bad SH board
Of course I am using AV

Bad Bios - yes, I feel this is the case, I hope T_Chan will come back with a miracle advice :) on how I can flash it with the given write access error and switches not working. Is there no way to build an elf file I can load in codescape which will then allow me to flash the bios? Just a thought from a tech-naive person...

Bad power supply - doubt it
Bad cap, bad SH board, hmm - after all I can run quite a lot of sample in Codescape with no problems, so the hardware itself seems ok
 
Last edited:

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
DBFlash recognizes it as 0.976.
Error before loading it: "Please confirm requested transfer length of 0x00200000 bytes

What's the exact size in bytes of your 0.976 file ? Where did you get it from ?

If it's exactly 2 MB ( 2.097.152 = 0x00200000 bytes), then you will not be able to use the Codescape procedure I described above, because that procedure requires that you use an original bootrom file from the SDKs, which is more than just the 2MB.
(eg. for the SDK 11b, the bootrom file btrf5011.bin is 2.185.216 bytes)
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
What's the exact size in bytes of your 0.976 file ? Where did you get it from ?

If it's exactly 2 MB ( 2.097.152 = 0x00200000 bytes), then you will not be able to use the Codescape procedure I described above, because that procedure requires that you use an original bootrom file from the SDKs, which is more than just the 2MB.
(eg. for the SDK 11b, the bootrom file btrf5011.bin is 2.185.216 bytes)
It's called set50.976.ic507 (recognized in DBFlash as 0.976), filesize is 2.097.152 bytes). I renamed it to .bin so I can load it in Codescape

Sadly only SDK 9, 10 and 11 seem to include a real btrf*,bin file (1.011) - I hae SDK 4 and earlier, but they only come with GD-M and DA Firmwares. I looked everywhere to find a "real" 0.976 bin file, but couldn't find any.

From the DBFlash Log (Switch to the right, DIP 4 up position, but in any setup, it`s the same)


Selected DA HOST 3 : SCSI ID 3 OK.
Reading Boot ROM Flash File.
Sending Boot ROM Flash File
Failed To Read Flash Status.
SALSA error report <CON: Command not available>
Failed To Read Flash Status.
SALSA error report <CON: Command not available>
.
(repeated about 30 times)
.
.
Error : Timed out whilst flashing Boot ROM.
Please make sure the Boot ROM Write Protect Switch is OFF ( over to the right ).
The Boot ROM Write Protect Switch marked "Slide SW" is located on the front pannel of the Dev.Box.
 

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
Then that's most probably the reason you cannot run it via Codescape / DBFlash.
Those btrf* files are program files, similar to .elf files (but not in the elf format), and are loaded on the devkit & executed from there.
What you have is only the end result, the 2MB part that ends up in the bios chip.

The fact that DBFlash "recognizes" it, is probably just because it searches for a version string in the file (Kabuto*), which would be present in the 2MB version. (this could easily be checked if you would make a file just with the Kabuto part, and see if DBFlash "recognizes" it... I would guess it would...)
 

Nolaw

Donator
Original poster
Donator
Registered
Sep 23, 2020
28
3
3
Ok, i doubt I have the technical skills to do this. i know it may be an out of bound question, but do you have any lead where I might acquire the correct bin file?
 

T_chan

Well-known member
Registered
Jun 6, 2019
85
65
18
AGName
T_chan
AG Join Date
Apr 13, 2008
I would see the following options:
  • ask to a person where you got set50.976.ic507 from
  • maybe somebody on this forum has it
  • more complicated - it could probably be reconstructed by investigating how such a file is built, and use eg the program part of the bootrom of SDK 11 & add that to the .ic507 you have.
 

MetalliC

Well-known member
Registered
Jun 28, 2019
75
71
18
AGName
MetalliC
AG Join Date
23.04.2014
It's called set50.976.ic507 (recognized in DBFlash as 0.976), filesize is 2.097.152 bytes). I renamed it to .bin so I can load it in Codescape

Sadly only SDK 9, 10 and 11 seem to include a real btrf*,bin file (1.011) - I hae SDK 4 and earlier, but they only come with GD-M and DA Firmwares. I looked everywhere to find a "real" 0.976 bin file, but couldn't find any.

From the DBFlash Log (Switch to the right, DIP 4 up position, but in any setup, it`s the same)


Selected DA HOST 3 : SCSI ID 3 OK.
Reading Boot ROM Flash File.
Sending Boot ROM Flash File
Failed To Read Flash Status.
SALSA error report <CON: Command not available>
Failed To Read Flash Status.
SALSA error report <CON: Command not available>
.
(repeated about 30 times)
.
.
Error : Timed out whilst flashing Boot ROM.
Please make sure the Boot ROM Write Protect Switch is OFF ( over to the right ).
The Boot ROM Write Protect Switch marked "Slide SW" is located on the front pannel of the Dev.Box.

for sure you can not use set50.976.ic507, it is bare BIOS ROM binary extracted from updater by me ;)
you need btrf0976.bin 2185216 bytes, it is part of Japanese Katana SDK 1.20J, which is floating in the webs, lmk if you'll had troubles to google one.
 

Make a donation