PDA

View Full Version : Makaron WIP - It beeps, IT BEEPS!



JKKDARK
May 5th, 2008, 21:09
Progress on the Sega Dreamcast emulator (http://dknute.livejournal.com/) for PC.


I've got good news and bad news.
Bad is I've not touched Makaron sources for weeks now. Guess it needs to ripen some more :) I got to the point where I have two or three ways to solve a problem, and each has it's pros and cons - and I just can't decide which one to pick. But I will get to it, eventually.

The good news is Yuki bought some VMUs with games on them and it got me pretty interested. I'm going to try and emulate standalone VMU now. Just think, since it's rather simple and low-spec I could easily use SDL to make it work. Hell, ScummVM uses SDL. I'm somewhat familiar with the API too (my old MOD player used SDL for both sound output and visualisation).
That would make a VMU-on-PC emulator. But guess what, there are SDL ports to Dreamcast available too! So the project could be made to compile and run on DC as well. And at this point it would run under Makaron of course. I mean, how do you say no to VMU-on-DC-on-PC emulator? :]

The main problem right now is VMU BIOS. Apparently it's not possible to access ROM memory directly while running from FLASH, so no easy way to dump it. KATANA dev kit comes with VMU BIOS but I'd rather not rely on it. You know, copyright stuff and all. Also, I'd like to have an English one from one of my own VMUs.
Just yesterday I've came up with a plan to hijack one of the system calls to read the BIOS area for me. This is a fragment of BIOS disassembly:

1966- 61 00 | L1966: PUSH ACC
1968- c1 | LDC
1969- 13 66 | ST VTRBF ;write to work RAM
196b- 71 00 | POP ACC
196d- 73 00 | DEC ACC
196f- 61 00 | PUSH ACC
1971- c1 | LDC
1972- 13 66 | ST VTRBF ;write to work RAM
1974- 71 00 | POP ACC
1976- 73 00 | DEC ACC
1978- 61 00 | PUSH ACC
197a- c1 | LDC
197b- 13 66 | ST VTRBF ;write to work RAM
197d- 71 00 | POP ACC
197f- 73 00 | DEC ACC
1981- 61 00 | PUSH ACC
1983- c1 | LDC
1984- 13 66 | ST VTRBF ;write to work RAM
1986- 71 00 | POP ACC
1988- 81 07 | ADD #$07
198a- 53 02 d9 | DBNZ B,L1966
198d- a1 03 | SUB #$03
198f- a0 | RET



See, by calling 0x1966 with my own TRL, TRH, B and ACC I could use it to LDC any BIOS area into work RAM. The only problem here is I'm assuming the BIOS that is going to be dumped has this procedure at this very address. Seeing how listing comes from 1.004 version and my VMUs are 1.005, it might not be that simple...
By the way - calling into any arbitrary place in ROM is easy, the hard part is getting out :) But that can arranged as well. Included below (may not be so obvious at first glance) is a public syscall entry for FLASH write routine. It's unused, as it does exactly the same as 0x0100 syscall:

0108- 20 2e c5 | writeFlash2: CALLF L2EC5
010b- b8 0d | NOT1 EXT, 0 ;execute code in other bank
010d- 21 01 0b | L010D: JMPF L010B



What I need is to push 0x010b address on stack and JMPF to 0x1966 while switching banks to ROM. The BIOS procedure will then read ROM memory, store it in RAM and RET to this NOT1 above, effectively switching back to 0x010b in FLASH, where I'll be waiting for it :) It's brilliant! IT'S SCIENCE :)

The other way to do things is to go HLE. There are only several public entry points in BIOS code, so it's rather easy. Calling anywhere else is pretty risky so I'm betting no game will ever try that.

So far I've determined that Yuki FLASH dumps are good and working, so I can start with that right away.

NeverGoingBack
May 7th, 2008, 00:01
Uh thats cool, I guess. Except there is already a VMU emulator for PC, and DC that works considerably well.

How about programming a VMU game? The Ben 10 Deluxe Omnitrix would be a awesome project. You Might have to build it from scratch though, aside from the lcd pics would practically be premade for you considering you own a original Deluxe Omnitrix. Though I doubt many people members here do, it is likely a younger relative does though.

Just something I would like to see come to life. I've had the idea for a while now. I just dont have any prior experiance with VMU developement, nor the time, or patience.