sikthehedgehog commented 6 years ago

The Tera Drive is a Mega Drive + PC hybrid, albeit unlike the other 2-in-1 computers that were released, in this particular case the two systems are actually merged rather than being separate things in the same shell. More specifically, the two sides can talk to each other (somehow), and the specs on the Mega Drive side have changed to include more memory. So far this hasn't been emulated yet.

There are several issues here:

1) Mega Drive emulation itself is a whole mess on its own, and you probably want it to be accurate. The effort to include it would be unreasonable, which leaves me seriously wondering if there's some way to somehow be able to get DOSBox-X and a separate Mega Drive emulator working in tandem. That's probably a whole excerise in itself, especially if you intend to keep performance.

2) We still aren't sure what the Tera Drive specs are. We can glance some information from Sega's own page on it but no idea how accurate is this. Video and Z80 memory have been doubled (and we have figured out how to get the VDP to use the doubled memory - Overdrive II relies on it, even), but doesn't say anything about the 68000 work RAM... is it shared with the PC? Also, 68000 apparently can be overclocked to 10MHz. The page also mentions specs from the PC side, like the use of VGA and DOS/V.

3) Even if we have an idea of the hardware in it, we still don't know how they communicate with each other. That's going to need to be reverse engineered I guess. There's one piece of software that (supposedly) can take advantage of it called Puzzle Construction, which thankfully happened to show up in a hard disk dump so at least we can poke it. It seems to be made out of multiple executables and some run off VGA video output, no idea how it's supposed to work since of course it's not gonna work properly as-is with current emulation.

This... doesn't look easy, no idea how this would start being tackled at all. Having the machine completely undocumented as it is right now though seems like a shame.

joncampbell123 commented 6 years ago

This sounds like a project that would be better done as a fork of DOSBox-X to develop on it's own. I suggest you fork DOSBox-X and then add the code to talk to the other emulator somehow. On Linux, this may be accomplished using unix domain sockets, and on Windows NT, named pipes. You may call it DOSBox-X-Tetra if you like.

joncampbell123 commented 6 years ago

You may also want to fork the megadrive emulator as a sister project to talk to your DOSBox-X-Tetra emulator.

joncampbell123 commented 6 years ago

Since you mentioned DOS/V you may want to take a look at this document as well, if you can read Japanese.

http://www.hackipedia.org/browse/Computer/Platform/PC,%20IBM%20compatible/MS-DOS/DOS%E2%88%95V/DOSV%20%E3%83%86%E3%82%AF%E3%83%8B%E3%82%AB%E3%83%AB%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9%E3%83%9E%E3%83%8B%E3%83%A5%E3%82%A2%E3%83%AB%20%E5%AE%89%E9%81%94%E5%89%9B%20(1993).pdf

joncampbell123 commented 6 years ago

Since you're dealing with unknown hardware and software, you might also want to add loads of debugging tools and output.

joncampbell123 commented 6 years ago

No offense but I think it would be a grave disservice to DOSBox-X to throw a whole combined megadrive + DOS/V emulation package into the source code at this time, especially when there's plenty of code cleanup to do, feature fixes to add, and PC-98 mode is still missing a LOT of emulation.

joncampbell123 commented 6 years ago

If I had to guess by the way, perhaps the video system may combine VGA and the VDP through color keying. Or perhaps the VGA is a High Sierra DAC that puts out "16-bit" ARGB (5 bit R, G, and B and 1 bit A) where the A bit may define which pixels are "see through" and the standard mode may be a 640x480 16-bit RGB mode.

I've heard that the Sega 32X does a similar combination of video outputs to overlay 32X graphics over the Genesis video (that's why the extra video cable).

sikthehedgehog commented 6 years ago

No offense but I think it would be a grave disservice to DOSBox-X to throw a whole combined megadrive + DOS/V emulation package into the source code at this time, especially when there's plenty of code cleanup to do, feature fixes to add, and PC-98 mode is still missing a LOT of emulation.

That's why I brought up point 1, it'd be ridiculous. Rusty comes with a DOS/V TSR though, so maybe it could be argued that DOS/V could be installed separately meanwhile (in fact, I'm not sure if it's even required).

I wonder how byuu handled Super Game Boy emulation (since I believe Higan actually emulates the two discrete systems instead of just faking the SGB BIOS).

If I had to guess by the way, perhaps the video system may combine VGA and the VDP through color keying. Or perhaps the VGA is a High Sierra DAC that puts out "16-bit" ARGB (5 bit R, G, and B and 1 bit A) where the A bit may define which pixels are "see through" and the standard mode may be a 640x480 16-bit RGB mode.

I think it's more like 3DFX where it just switches between two video signals. The VDP and VGA outputs don't seem compatible (and the TV output can only output properly the VDP signal, no the VGA one - the monitor can handle both).

I've heard that the Sega 32X does a similar combination of video outputs to overlay 32X graphics over the Genesis video (that's why the extra video cable).

Yeah, it genlocks with the VDP then overlays its own framebuffer onto the VDP signal. Completely unrelated though.

sikthehedgehog commented 6 years ago

I'm wondering that even if it isn't emulated, at least figuring out how it works would be useful.

I have no experience disassembling x86 code let alone DOS stuff in particular so I'm not hopeful about this :P (also just remembered the BIOS is around too)

joncampbell123 commented 6 years ago

Don't worry, DOSBox-X has a built-in debugger (if you compile with it enabled). x86 opcodes aren't really THAT hard to work with. Segments in the x86 architecture are fairly simple to understand. To figure out the final memory address, you take the segment and convert it to a linear address, then add the offset. In real mode, the linear address is just segment * 16. In protected mode, the linear address of a segment is defined by the global descriptor table.

joncampbell123 commented 6 years ago

There is an "INT" instruction to call a software interrupt by number. In the DOS world, the BIOS takes one range and DOS takes another. So on the IBM PC system, INT 10h would call into the part of the BIOS related to video functions, and INT 21h would call into the DOS kernel.

Torinde commented 1 year ago

About the similar Amstrad MegaPC: 86Box/86Box/issues/238

sikthehedgehog commented 1 year ago

They aren't similar at all, the Mega PC is basically two separate machines inside the same case (they can't communicate with each other at all). There's nothing that can be emulated there in that respect.

Incidentally more stuff about the Teradrive's programming is known since then and uh… it's a lot more shared than you'd expect. The boot process goes through both the 80286 and 68000, the RAM itself (well, the entire memory space) is shared between them (though it's slow for the 68000), the 68000 can also access the I/O ports on its own (meaning it has access to all the PC hardware as well). We also found out several DOS programs run the Z80 on its own (without the 68000) to make use of the YM3438.

Incidentally in hindsight, it's probably easier in the long term to add Teradrive emulation to a Mega Drive emulator than to a PC emulator. The reason being that the Magistr16 exists, which is another Mega Drive-based computer, albeit in that case it's a Mega Drive with PC parts inside (in particular, a whole Super I/O chip was added to control all the extra stuff). If the Magistr16 is emulated, when going for a Teradrive becomes less of a stretch (it'd need 80286 and hard disk emulation, but it'd be still easier to get it booting).