Sega Dreamcast HDMI Adapter coming soon ..

This is all extremely awesome.

I have been checking this thread patiently for ages, and it's great to see you've been getting up to all this quietly behind the scenes.

Can't wait to be able to buy a HDMI board!
Your hard work is much appreciated!

 

@madsheep - thanks.

I've had those datasheets for a few years though (since FamilyGuy or somebody mentioned the "Sega Packet Interface" one was floating around, I then stumbled on the exact same site while Googling. lol)

Keep the links coming though, as I know there must still be a shit-ton of other important documents we're missing, especially if anyone finds any details on the exact BIOS checksum / "security" algo that the Holly chip uses to unlock the G1 port.

@Providencial - Thanks.

 

@japanese_cake might know a fair bit about the Holly/bios stuff.

 

There's the guy who did the hard drive patch for the dreamshell bios too, as that now unlocks g1.

 

You mean MetalliC Demul co-coder or megavolt85
who modified the BIOS for dreamshell.

 

yep, it seems (based on) my mod of DC BIOS I gave to SWAT, which is bypass protection using NAOMI HotD2 proto BIOS bootstrap, as well as I've made in NAOMI 'multi' BIOS mods.

2ALL: afaik there is no one person in the world who work on this now, or during last year(s), so no miracle happens here - it wont crack/reverse engineere by itself

 

Yep - I saw the HDD patch a while ago, and that was cool and everything, but no details were ever released on how it was actually done.

If it was anything like SWATs original patch for his "bootloader" BIOS, I imagine it's just a pot-luck thing to modify the bytes in just the right combination to hit on a "valid" checksum for that block?

In SWAT's bootloader BIOS, I can see that he basically added a couple of bytes which then make the jump to his custom code that sits higher up near the BIOS Fonts section.

I guess a brute-force method could be used to pass that check there, but nobody has discovered the true algorithm yet (as @MetalliC said), which would of course allow us to completely re-write the BIOS with our own GD syscall -> HDD routines (or at least let us easily patch much larger chunks of the stock BIOS.)

It would be great to create a custom BIOS which properly redirects the GD syscalls to read from HDD instead - that would be the "ultimate" mod IMHO, as it would in theory bypass many of the issues with Dreamshell regarding the syscall "stub" to stay resident in RAM (I think?).

I'm not sure if there are many (or any?) games which actually try to access the GD drive / G1 port directly?
Or, is it only the WinCE games which use the standard BIOS GD syscalls?

I don't know enough about the Katana / WinCE differences to know the answer tbh.

OzOnE.

 

How did Dan Potter made his navi bios then?

 

Good question. lol

 

Oh, actually, you can get away with replacing most of the stock BIOS I think, it's just the fact that it locks you out from being able to read from the G1 port.

That's probably why he had the support for bITmASTER's IDE via the G2 port instead?...

http://cadcdev.sourceforge.net/hdwrprj/navi/

 

btw, another thing I never got around to doing is seeing which signals the HOLLY chip actually disables on the G1 bus to prevent access to the GD drive / HDD etc.

I seem to vaguely remember that it simply blocks the /Read and /Write signals for those accesses, and possibly the DMA signals too (although DMA would still require assertion of either the /Read or /Write signal I suppose).

Obviously it still allows the /Chip Select to be asserted for reading from the BIOS / Flash. It's just the "IDE" accesses that get blocked if the "stock BIOS checksum" thingy fails.

The checksum only seems to be done as the whole BIOS (or a large chunk of it, probably at least 1MB) is transferred from the ROM chip over to RAM.

Many of you will know that the solution (by MegaVolt85 and others?) for Dreamshell originally was to allow the stock BIOS to be transferred into RAM first, which unlocked the "IDE / G1 access" registers in Holly, then switched to the Flash BIOS chip to run the custom bootloader instead.

That was supposedly made redundant again when they got lucky with the usual patch of a few bytes, and made it pass the checksum again.

It was an obvious attempt by Sega to make it difficult to use a custom / patched BIOS for playing GD disks from different regions, and for stopping custom code from reading directly from the G1 port and ripping disks.

Although, as we all know, most of that went out the window once the MIL-CD blunder was discovered. lol

OzOnE.

 

here is summary known info about this protection functioning:
https://github.com/mamedev/mame/blob/master/src/mame/machine/dccons.cpp#L165
how it was bypassed ? in regular DC or NAOMI BIOS whole 2MB is summed, so we can't change anything there, in HotD2 proto BIOS I've found only bootstrap (NAOMI HAT) is summed (1KB in size)
so it can be injected at start of ROM, and after it we can put any code / data we want, and it works like this:
1. run HotD2 bootstrap
2. run original bootstrap code (which was replaced), modified and relocated to some upper part in ROM
3. continue normal execution

however, as you can guess, Dreamcast BIOS modded in this way will work with original GD-ROM games only.
any Mil-CD software will not, because in process of "G1 unlocking" they set size of checksummed data (5F74E4 register) 2MB, not 1KB

 

there no games accessing G1 ATA registers directly. Sega was secretive about this and do not included any libraries in Katana or WinCE SDK which may access them directly, so everything works using 'SysCalls'

 

blind luck. summ algo used in HOLLY seems very weak, so its quite possible to get 'good sum' randomly changing some bytes.

 

most funny thing is - Sega missed single line of code, which will made impossible to 're-unlock' G1 ATA bus.
right before jump into loaded/deshuffled Mil-CD binary, DC BIOS writes to 5f74e4h register some value (42FEh) in attempt to make impossible GD-ROM access.
what do homebrew/pirate software to bypass this ? write to that register 1fffff and do dummy read of whole 2MB BIOS - summ matched, G1 unlocked.
what missed Sega ? after write 42FEh to 5f74e4h reg was needed single read from 42FEh address, so security system becomes in 'checksumm failed' state, and can't be unlocked using anything but cold reset.

 

Nice info.

Do you think there is a way to spoof the proper checksum by writing a lower number to the register, then only reading a small part of the stock BIOS code?

There must be some other ways to bypass the checks so we can use a full custom BIOS?

I'm very glad to know that no games access the GD drive directly though.
That does make sense I guess, as Sega would probably have forced the devs to use the normal syscalls, as you say.

(the syscalls are fairly basic anyway, they just send the raw ATAPI / SPI command packets after they are called, IIRC.)

I think it would be straightforward to fully redirect the GD syscalls to read from HDD in that case. We just need to crack that damned BIOS check once and for all, and we probably wouldn't need an external GD emu ever again.

The NAOMI stuff is different though, as it does PIO / DMA commands directly to the G1 port.
But, that is probably just some BIOS routines doing that as well, so that could also be redirected to read the "cart" from an SDRAM chip on the G1 bus too.

OzOnE.

 

i will put this here
http://japanese-cake.livejournal.com/9885.html

 

Couldn't you build some kind of modchip that intercepts the bios check and always makes it pass?

It'd be impractical for dreamshell/custom bioses but since you're already building a complete motherboard...

 

that was a plan, but I haven't real DC, and SWAT haven't spare time for this tests.

sad but no, arcade games do everything on it's own, directly. there no any 'syscalls', or calls to BIOS routines.

interesting find, I hope J.C. will share info about how he did this

 

@OzOnE
unrelated question, did you do some more research on NAOMI CN1-3 pinouts ?
mainly I interested to know is some of HOLLY video sync signals (VSYNC, HSYNC, BLANK) routed to mentioned connectors ?