Xanadu I/II and other SCD translations

[Necromancer]

Couldn't you use the Turbo Everdrive? Syscards work fine on it...

You sure about that?  I don't have one and haven't tested it, but I'd bet it's like all other syscards: you can use a different syscard rom to change regions or use a 2.0 card on a Duo, but you can't use a syscard rom on a system that doesn't have the ram built-in, like using a super system card rom on a base cd add-on or an arcade card on any system.

[esteban]

Couldn't you use the Turbo Everdrive? Syscards work fine on it...

You sure about that?  I don't have one and haven't tested it, but I'd bet it's like all other syscards: you can use a different syscard rom to change regions or use a 2.0 card on a Duo, but you can't use a syscard rom on a system that doesn't have the ram built-in, like using a super system card rom on a base cd add-on or an arcade card on any system.

Correct.

[Bonknuts]

The Turbo Everdrive has no ram on the card for the PCE to use. Krizz, the creator, has said as much. Though a new card from him could have lots of ram; we'll just have to wait and see.

[Bonknuts]

I don't have my SCD setup at my temporary place I'm at now. Would anyone mind testing something out for me, with the TE card and the SCD unit (Duo or SuperCDROM setup only)?


Just some info:
 I'm looking into Xanadu I and documenting stuff. This game is bizarre. I've only started stepping through the game code, but it appears to treat the setup as a small file system (SCD RAM). The text appears to be compressed only with single byte stuffs for common used SJIS, else the rest is SJIS. No LZSS or such. But the game seems to treat all these assets as 'files' to load into a large work area. It's very strange. I mean, considering most games treat the SCD as a rom setup with variable amount of work ram. I wonder if they were emulating or simulating a different work environment (japanese PC ?). Either way, it's fairly wasteful so far. It's not just for text, but a lot of assets. The 'files' appear to have a header/entry of 7-16 bytes in length (not located next to the file that I can tell, but possibly a file system table). I'm not exactly sure how it all works yet, but it's definitely something I haven't seen in a PCE CD game before.

 Anyway, Xanadu I is a nice project to work on as a translation because the game is segmented by chapters, instead of a world that opens up like a traditional RPG. This makes things somewhat simpler, and be able to translation in sequential fashion.

 I haven't worked out pointers and anything like that; still working through it and documenting it.

[SamIAm]

Great work so far, Bonknuts! I am totally psyched to get a script for this game.

[trapexit]

The Turbo Everdrive has no ram on the card for the PCE to use. Krizz, the creator, has said as much. Though a new card from him could have lots of ram; we'll just have to wait and see.

If you could write to the flash from the PCE side directly it'd be at least possible to store some data in it temporarily but you'd not want to write to it as often as RAM. Some SPI code to interact with the SD card was released which could also be used but the same issues apply.

I was casually researching the idea of using a highend microcontroller to simulate a PCE HuCard. The issue is having one fast enough to do the simulation and enough GPIO pins. I read an article recently where a guy used am ARM Cortex-M4 based 168 MHz STM32F4 to simulate an original Gameboy's. The problem with the PCE is that it has too many pins and none of the commonly available boards I've looked at so far have enough GPIO pins and all the ways to expand them utilize I2C which I suspect would greatly slow their effective rates.

If we could get something like a Raspberry Pi with enough GPIO pins... it wouldn't require *too* much effort to create a rather badass all in one card which could be a ROM cart, emulate the ArcadeCard, emulate the system cards, the Games Express card, more RAM, etc.

But at that point... may as well modify an emulator to provide virtual hardware you need and just run it off to your TV.

[elmer]

I'm looking into Xanadu I and documenting stuff. This game is bizarre. I've only started stepping through the game code, but it appears to treat the setup as a small file system (SCD RAM). The text appears to be compressed only with single byte stuffs for common used SJIS, else the rest is SJIS. No LZSS or such. But the game seems to treat all these assets as 'files' to load into a large work area. It's very strange. I mean, considering most games treat the SCD as a rom setup with variable amount of work ram. I wonder if they were emulating or simulating a different work environment (japanese PC ?).

Here's my 2c ...

A mini-filesystem in rom/ram was common with Western developers in the the 80's/90s.

a) For cartridge-based systems, writing an emulated cartridge was usual SLOW ... so it made sense to keep the data (which changed less frequently) in the same place, and only write code changes.

If you were doing that, you either chose the Japanese-developer route and hard-coded locations (which was a pain when files changed in size), or you chose the Western-developer route and had a custom mini-filesytem somewhere in the rom.

This was even more useful in the 90s when cartridges weren't directly memory-mapped.

b) For CD-based systems ... both seeking and loading speed are killers. Burst-loading a block of data into RAM and then loading the files from that could also save time ... and/or give you flexibility.

Sounds like you've hit one of the variants of (b) ... a way to  get the startup code to load both the initial code and data.

[SamIAm]

I've been replaying this one a little bit, and again I have to say that it really would be a lot of fun to translate.

Any updates, Bonknuts? On this or anything else?