Private WIP 0.032.04 - need testing

[byuu]

Okay, so I really need all the testing I can get here.

Recently, there's been work on the SPC7110, as I'm sure most here know. It's still not cracked, and it may not be, so please don't get your hopes up on that.

But just to be prepared, I went ahead and emulated the rest of the chip.

---

I'm sure it's far from perfect, but good enough to start all the SPC7110 games, at least. MDH shows a black screen ... but if I rig the decompression port to feed random data, I can see it's supposed to be some sort of message. Will have to wait to see what it says to figure out what's wrong.

Now, the part I need testing for: the FEoEZ test program sets the time to 1999-12-31 23:59:59, then tells the timer to tick by one second and expects to read back 2000-01-01 00:00:00.

The way I handled the RTC in Daikaijuu Monogatari 2 was to return the current system time and ignore writes. I'm sure you can see the problem.

I wanted consistency, so I re-implemented DKJM2's RTC as well. What I do now, is store a new file in the save folder, <gamename>.rtc. This contains the RTC chip data, as well as the system timestamp that corresponded to the last RTC timer update.

Whenever the game asks the chip to update, I check the system timestamp, subtract it from the last saved one, add that much time, and save the updated timestamp. This means it counts your real-world time even when the emulator is closed.

Since DKJM2 supported dates as low as 1900 on the chip itself, and localtime() / mktime() functions fail before the PC epoch ~1970 or so, I had to write my own time functions. Learn something new every day, who here knew that if a leap year is divisible by 100, but not 400, then it's not a leap year anymore? Get that wrong and you can't figure out that 1900-01-01 is a Monday.

So, what I need is someone who can figure out how to save in DKJM2, and then screw with the timer. Set it to any time you can think of, and try and watch the time wrap around days, months, years, leap year months, etc etc and look for any errors. Try starting, closing, end tasking, etc the emulator to screw with the RTC clock.

The good things about doing things this way, is the "round minute up or down" function in the original game now works, and if you want to BS an earlier time (eg 1996), you can now do so. Going to be important for FEoEZ, that game only goes up to 2015. Heh, I guess they figured nobody would be playing it by then.

The bad part about doing things this way -- daylight savings time is no longer recognized. It wasn't on the original RTC chips either. Maybe Japan doesn't have that, I don't know.

The 30-second round function is the only way to update the clock in-game, so as you can imagine it'll be extremely painful to sync the clock to real-world time, which is why I wanted to avoid emulating the chip this way before.

Maybe I can make a time editor for the RTC files or something, who knows.

One last complication: other emulators. Right now, ZSNES uses the local system time. No idea how it passes the SPC7110 RTC test that way. So it would simply ignore my RTC files, but otherwise work. SNES9x appends the RTC data to the end of save RAM files, which I think is a terrible idea. So you'll end up getting different times in every emulator now. That kind of sucks.

Oh yeah, and neither method allows emulator fast forward and slow down to show up in game. The clock still ticks based on real seconds. While I could work around that, it would probably annoy people more that hitting fast forward one time means they have to resync the clock time. And luckily I avoid timeshift issues with savestates by not supporting savestates at all! Hah :P

Good news is the epoch is the same for Windows and Linux, so you won't notice any crazy time jumps when switching OSes.

[creaothceann]

Maybe I can make a time editor for the RTC files or something, who knows.

The time can't be stored in text format?

(What kind of data is in these files anyway?)

[byuu]

Alright, Super Power League 4 is now playable.



Well, mostly playable. Just not very pretty :)

The time can't be stored in text format?

(What kind of data is in these files anyway?)

One is the timestamp of the system upon the last counter refresh. An end user won't be able to generate their own by hand, so editing a text file wouldn't go very well. If they leave it alone, then when they start the emulator, the time they specified will jump forward a good deal.

The other part is the raw SPC counter data, which yes, that could easily be stored in text format.

I like it in binary format, though. I can use the memory device directly, just as I do with save RAM and ROM now. With a text format, I'd have to add another file conversion system on, and the Cartridge class is bloated enough already.

[Verdauga Greeneyes]

Is mode 0 decompression enabled in those latest screenshots? Pretty nifty result Watching the SPC7110 discussion progress is pretty exciting, I'm glad neviksti posted the link over here.

PS: Might have some time for testing tomorrow after I get home.

[byuu]

Nope. I'm feeding out rand() from the decompression read port. You can make out the sprites because they're cut out cleanly from 8x8/16x16 tiles. And obviously the palette data is not compressed.

Unfortunately, no graphics are stored in mode 0.