Xanadu I/II and other SCD translations

[TurboXray]

Is it possible this can be made into a sticky?




Sub-topic: What this, and other translations need, is an sys 3.0 card with expanded ram:

Also, does anyone have circuit files they are willing to share? Or even better, willing to make or modify one for two 512k rom/ram chips (1megabyte)? That one guy in France made a few boards, but they only have one chip on them. If this translation (and others) are gonna get finished, we need a card that can hold a rom (for SCD 3.0 bios) and a 256k ram chip (preferably 512k). If anyone is willing to help out, that would be great. Again, these are for SCD translations. Yes, you would need this card to play them. But it's a simple card with no mapper and two memory chips (the layout of the one made in France would work fine). I can start the projects in emulation, but at some point I'll need to test on the real hardware.

[SamIAm]

I've had it with the lack of translations coming out on this system. Let's get this card made. I am ready to get some serious stuff done on the J-E side. If this card makes to hacking side go way more smoothly, it will make a huge difference. So if you can help out with this, please do so.

[jtucci31]

Unfortunately I can't provide any help, but I'm very much so looking forward to a Xanadu I translation. In the meantime I'll use guides to get through it.

But obviously an English translation would make playing through the game easier and more enjoyable

[SamIAm]

How much easier would it be to do the hacking for a translation of a PCE-CD game if there were 512k of RAM instead of 192k?

[SephirothTNH]

I'm curious about that as well.  Also would the 3.0 bios be able to recognize the additional ram or would that need to be hacked as well?

[TurboXray]

Technically, even just 64k of ram would make it easier. I remember seeing 512k sram chips, and they weren't really any more expensive than 256k sram chips. For a few dollars more, why not double it? Anyone can use it for homebrew too.

 The problem is that new code needs to be written into areas of the game. But you can't just write this new code anywhere, because things aren't just replaceable/moveable like that. Not in a banked memory typed system like this. The second thing is, what if there's not enough free room, or worst - no free room at some later point in the game (this has happened to me).
 
 A CD game only expects so much ram to be there, and only in a certain area. CD 2.0 games don't expect or use SCD 192k of ram, SCD games don't expect or use AC 2megabyte of ram, etc. So the expanded ram is essentially 'protected' from game use. This makes it ideal for hacking purposes. Not just replacement code, but also replacement print fonts as well. You could even load in an alt system card bank #0 to MPR #7 (which is always fixed for CD game setups) and replace bios calls directly like that (which would map in your own routines sitting in expanded ram). It just makes things sooo much cleaner, easier, and faster for hacking.

[FraGMarE]

Technically, even just 64k of ram would make it easier. I remember seeing 512k sram chips, and they weren't really any more expensive than 256k sram chips. For a few dollars more, why not double it? Anyone can use it for homebrew too.

 The problem is that new code needs to be written into areas of the game. But you can't just write this new code anywhere, because things aren't just replaceable/moveable like that. Not in a banked memory typed system like this. The second thing is, what if there's not enough free room, or worst - no free room at some later point in the game (this has happened to me).
 
 A CD game only expects so much ram to be there, and only in a certain area. CD 2.0 games don't expect or use SCD 192k of ram, SCD games don't expect or use AC 2megabyte of ram, etc. So the expanded ram is essentially 'protected' from game use. This makes it ideal for hacking purposes. Not just replacement code, but also replacement print fonts as well. You could even load in an alt system card bank #0 to MPR #7 (which is always fixed for CD game setups) and replace bios calls directly like that (which would map in your own routines sitting in expanded ram). It just makes things sooo much cleaner, easier, and faster for hacking.

Would you need the expanded System Card 3.0 RAM to play the game, or merely to hack the game?

[Lochlan]

Would you need the expanded System Card 3.0 RAM to play the game, or merely to hack the game?

Yes, you would need this card to play them.

[SephirothTNH]

Technically, even just 64k of ram would make it easier. I remember seeing 512k sram chips, and they weren't really any more expensive than 256k sram chips. For a few dollars more, why not double it? Anyone can use it for homebrew too.

 The problem is that new code needs to be written into areas of the game. But you can't just write this new code anywhere, because things aren't just replaceable/moveable like that. Not in a banked memory typed system like this. The second thing is, what if there's not enough free room, or worst - no free room at some later point in the game (this has happened to me).
 
 A CD game only expects so much ram to be there, and only in a certain area. CD 2.0 games don't expect or use SCD 192k of ram, SCD games don't expect or use AC 2megabyte of ram, etc. So the expanded ram is essentially 'protected' from game use. This makes it ideal for hacking purposes. Not just replacement code, but also replacement print fonts as well. You could even load in an alt system card bank #0 to MPR #7 (which is always fixed for CD game setups) and replace bios calls directly like that (which would map in your own routines sitting in expanded ram). It just makes things sooo much cleaner, easier, and faster for hacking.

Ok I follow you.  So could you use the extra ram in a arcade card with a SCD hack? 

So the bios in the cards doesn't need to be hacked?  Anyone got a spare 3.0 card to mess around with? Or any pics of an opened 3.0 card? I suppose we could add this ram internally to a duo?

[Psycho Punch]

If RAM is needed why not use an Arcade card?

[NecroPhile]

I don't remember the specifics, but the Arcade Card can't be used for such purposes because its ram is too slow and/or has access limitations that mean it can't be used like the 'normal' memory of a Super System Card.

[BigusSchmuck]

If RAM is needed why not use an Arcade card?

I believe its more like video memory. This post pretty much sums it up:
https://www.pcengine-fx.com/forums/index.php?topic=18069.0

[TurboXray]

Would you need the expanded System Card 3.0 RAM to play the game, or merely to hack the game?

To play the hacked game. It's not strictly for development, but a place for the hack/new code to reside.

So the bios in the cards doesn't need to be hacked?  Anyone got a spare 3.0 card to mess around with? Or any pics of an opened 3.0 card? I suppose we could add this ram internally to a duo?

The bios doesn't need to be hacked, no. But if you did need a main bank change (the bios function call list), you simply substitute your own with a bank of ram and replace code where it would normally be used for something else. It's safe because games don't map out the last bank - they leave it fixed. So technically, you can put your hooks in the main bios call list in the fixed bank (it alleviates some possible situations for bugs/errors to occur; a little but advanced to explain here).

 But as far as opening up the card and adding ram that way? That shouldn't be doable. I've taken the card apart (I have one) and it's setup in a way to make the ram fit into certain address banks of the external memory interface. AFAIK, it's not just simply mirrored and replacing a ram chip will increase the ram size (they are just regular surface mount ram chips though).

If RAM is needed why not use an Arcade card?

AC memory is indirect access only (port based), which is perfect for all kinds of data - but doesn't work for code (real time code). So that might attend the issue of storing a new print font per se (graphic data), but doesn't do anything for the new hack code. So CD 2.0 -> SCD 3.0 hack works, but SCD 3.0 -> ACD doesn't. I did this for Dshadoff's Cosmic Fantasy I translation project: the game got upgraded to SCD 3.0 requirement for the hacked code and font, but the game's original code doesn't touch the SCD memory because it doesn't know about it. This is when I realized that we really need a new 'system' card, in some way or form that has extra memory outside the original game's scope.

[pixeljunkie]

I couldn't be farther from being a programmer, but I love reading this stuff. Hope something comes of this!

[deubeul]

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

[NecroPhile]

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.

[TurboXray]

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.

[TurboXray]

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?