Kuta said:
I think it was around March this year the site was hacked and had to be restored from backups. So basically we lost about 6 months worth of posts. I lost a lot of informative posts myself in other threads.
Ok I finally got ahold of Snake, heres what he said:
Well last time I talked to anyone about this, TascoDeluxe (the man who
seems to know everything about everything) was convinced that it
actually contains two BIOSES, and the reason it freezes is because it
switches to a different one (which doesn't exist) when you boot a
game.
Doesn't really make a lick of difference either way, because even if I
could somehow magically add support for this without a single game to
reverse engineer, that isn't going to help with dumping anyway.
Yes I would like to add support for this but since I have no hardware
to play with, no game code to look at, and no BIOS code responsible
for actually booting a game, there is no way for me to even begin to
look at it. Somebody with access to the system needs to get the ball
rolling. I have repeatedly offered my help in attempting to write some
code to do the dumping, but I need some info first.
Hopefully somebody is actually working on this.
I told him I dont think so, I think Kega crashes because its looking for the laserdisc
Heres TascoDxs thread he was referring to:
I should point out that the MegaLD uses one of two subcpu BIOS based on the disc type -- the usual CD BIOS and a special LD BIOS. The CD BIOS is basically the same as a normal one except for some code that probably sets up some sort of compatibility mode. The LD BIOS is different where disc access is involved including many of the CD-BIOS function calls (though some of the functions are apparently similar) but the CDC is unchanged.
If you wanted to run such code from a CD, you would have to completely reload the subcpu BIOS in the process. This should work unless a hardware reset is required, in which case you would have to do the same running from ROM.
As for the LD registers, they are at 0xFDFE40 at odd addresses, half host (r/w) and half device (r/o). I'd have to check my notes for details. It's basically just ram with a byte for the command and a sync is used to send it.
(EDIT: Sorry, I had the wrong address. Corrected.)
I should be getting some more free time in the near future so hopefully I'll be able to help out.
Mask of Destiny wrote:
How does the Main CPU know what the disc type is before it loads the BIOS on the Sub CPU?
It loads the LD BIOS by default. If it detects a CD (or not LD, perhaps) upon boot, it will reload with the CD BIOS. That means the system can transition from LD BIOS to CD BIOS without a hardware reset but I don't know if the opposite is true.
Mask of Destiny wrote:
How does the unit determine disc type?
It's based on a value returned from the LD device. So, I doubt it can be faked (without a hack, of course).
Mask of Destiny wrote:
TascoDLX wrote:
The LD BIOS is different where disc access is involved including many of the CD-BIOS function calls (though some of the functions are apparently similar) but the CDC is unchanged.
Have any notes on the differences?
As far as the CD-BIOS calls are concerned, all the functions numbers are different. They start from 0x0100 so there's no confusion with the original numbers. Some of the functions (like the CDC functions) are the same except for a different number, several of the functions appear to be equivalent to original functions except that they use the LD interface -- for example, there are DRVINIT and DRVOPEN equivalents -- and some functions are a bit of a mystery.
On the hardware level, the CDD registers (CDD comm, fader) are not used -- comm is handled via the LD interface (through the LD register array). Consequently, the level 4 CDD interrupt is also not used. Status is queried and received directly through the LD interface.
