CD32 - Minimum RAM + conversion options

[Muzza]

Hi,
I'm creating an official CD32 ISO for Turrican 2 AGA. I don't have a CD32 myself, and know little about the expansion options etc. but as the game requires at least 1 or 2MB of FAST RAM, some kind of expansion is required.

It seems I have 3 options for the CD32 version.
1. Rewrite it to be OS Friendly. Lots of hassle, and the docs seem to imply some graphical features things are not possible. (changing AA colours in the copper!?)

2. Convert the WHDLoad version, and make the CD boot WHDLoad. Easy to do, but in order to preload all files, it would require (at a guess) 6MB FAST RAM minimum.

3. Adapt the debug version, which I use quick testing but did not release. This version does a system takeover, but then returns to the OS during loading sequences. This method surprisingly worked without any code changes, but leaves some graphics corruption during loading scenes which will need looking at. It also means I can't play music during loading.

Option 3 would require less Fast RAM and would load the initial game quicker, and so is similar to the floppy version.
Option 2 would have longer initial load times, require more Fast RAM, but is a better experience afterwards, as there is no further CD activity or switching to the OS.

So my question is, what is the minimum amount of Fast RAM that a CD32 is likely to have (above zero)? Were 2MB expansions sold, or does everyone have 6MB+?

p.s. A feature that would have been really handy was if WHDLoad had the ability to do multiple file loads whilst only switching to the OS once. I really want to do SwitchToOS. Load File 1, Load File 2... SystemTakeover. This would allow a cleaner loading phase between levels when not using PRELOAD. Currently it flickers like crazy, and the music goes nuts because it goes in/out in/out in/out of the OS.

[Cobe]

First, I think that today most active cd32 usres have at least 8mb fast ram(tf328 etc)
Second, you should consider option 4 cd32load
https://github.com/jotd666/cd32load
And as a plus I believe jotd would chime in and help you add cd audio easily.
I know the prefered audio remastered tracks would be copyrighted but you dont have to supply them with your iso/cue. Anyone can put wav tracks whatever he wants...

[Muzza]

I got option 3 fully working now, and it only requires 1MB of Fast RAM. Whether it works on real hardware and not just WinUAE is another matter.
That CD32Load github repo contains cd32loader.asm code which looks interesting. Is this something that only works with WHDLoad? And does it work after a system takeover?

CD audio is another matter, and again I know almost nothing about how that works. Do you really just add wavs to the ISO? That doesn't sound right. Don't you have the same problem that you can't access the CD drive after a system takeover? If CD32Load solves this, how does it do it? Also does the CD music need to go through the normal Amiga audio system or is mixed in automatically?

[Cobe]

Those question are more for jotd.
But what I could say without being 100% percise is that cd32load works only with whdload slaves.
Cue file contains a list of you disc.
Track 1 your.iso
Track 2 yourlevel1.wav
Track 3 yourlelvel2.wav...
If you send a cd play command before taking over a system, cd will continue to play it after you take over the system. So I guess its done by going back and forth everytime you want to play/stop the audio. And cd music on cd32 is mixed internally with paula.

[Muzza]

The CD32Load readme starts with:
"cd32load is a program which understands whdload slaves and loads its data from CD32 drive (goodbye OS flashes!!)"

As I mentioned, I've no experience with the CD32, and I'm not clear on what this means exactly. I've seen ISOs that just boot direct to WHDLoad and load a slave to run a game (with preload on).
How is cd32load different from this?
And what are OS flashes?

[Cobe]

Os flashes are those annoying black screens that flash when game is loading if you cant have preload on which on stock cd32 you usally cant have on. Cd32load eliminates that and more. I suggested it also cause jotd knows how to add "hooks" in slaves for cd music to play.

But if your option 3 is working you could try playing cd music system friendly way.
Use cd.device
http://amigadev.elowar.com/read/ADCD.../node05E4.html
After loading, play cd, takeover system, cd will still play.

[Muzza]

ok thanks, the flashes are indeed what I'm trying to avoid.

[jotd]

CD32load is more intended for games that just require 2MB chip.

It needs at least 64k of 64k-aligned chip for CD buffer (the OS probably does too).

The easiest would be that your whdload slave should not go above $1E0000 (I adapted games which needed almost all memory by finding unused memory chunks or even swapping memory chunks (which means black screens again...) but it's better if the slave & the game collaborates!

If your slave needs fastmem, that means that cd32load would need to be upgraded as it currently doesn't support fastmem AFAIR. But it should be pretty easy to add.

With that you could make your game work without OS swaps and without bothering with DOS CD access with a CD32 with 2MB expansion. At 8MB, I suppose that whdload is good enough (don't use whdload_cd32 as it's the cut-down nofast free version (and full of os flashes) that Bert created so no keyfile was required, but now whdload is free so it's moot)

About the issues on real machines, if this is a CIA TOD level 6 interrupt, it's easy to fix too. Handle that level 6 interrupt by simply acknowledging it (John Twiddy games like Cool Spot, Global Gladiators, Putty Squad didn't expect level 6 interrupt and thus had a "handler" that created a color screen which locked up the machine).

It may also be an issue about CD drive operation not done, so on CD32 (at least from CD0:, I don't know how to detect that), wait 100ms after each disk access. Or ack level 2 interrupt from Akiko by writing to Akiko INTREQ register.

old discussion here: http://eab.abime.net/showthread.php?...e=35&styleid=4

Quoting Toni

Clearing all Akiko interrupt requests are more complex but just clearing $b80008 is enough to keep them off.
Another suggestion: After $B80008 clear, write zero to $B80020.W to clear possible still active transfer complete interrupt request. (It may be active if loader prefetches following sectors and prefetching is still active)

Doing so may cause trouble when returning to the OS as the OS could expect something from the CD drive... AFAIR $B80008 is longword. CD32load source code contains a lot of stuff like that. It was hell to make it work properly and test it with audio player, specially on real hardware. Even today, some games work perfect on emulated CD32 (Mortal Kombat 2) and fail on real hardware...

Of course I have a CD32 but each time you test you have to burn a CD-R (CD-RW doesn't work), and I found out now that only some brands work for me. Verbatim doesn't, when Sony does.

[jotd]

Maybe something to implement for your DOS lockup issue

If running on CD32 (poke $B80000 which contains $C0CACAFE), wait until $B800008 is zeroed (no more CD int requests). I think you can even test it on winuae since it respects those registers

Check this register value while loading (if possible) to see if it can be != 0 and become 0. It should be safe to re-engage OS-disable if $B80008 == 0

[Muzza]

Thanks for all the information, I will go over it all carefully, but yesterday I did implement cd32loader.asm on its own without using WHDLoad.

I got it working under emulation, and it means no more activating DOS, but I'm waiting on the results of a real CD32 test. I expect it will have problems with one of the gotchas you have mentioned.

I do have a level 6 interrupt already running, so hopefully that part is covered.
I did the large allocation (in Fast RAM - hoping that works!) using the AllocMem, FreeMem, AllocAbs method to keep it aligned without overallocating too much.
I'm not pausing, unless a read error is returned, when I pause before retrying. I did test pausing before every disc access, but it took load times from bad to atrocious, and that was just in WinUAE. I suspect I need to change the way files are loaded from lots of small files to one large file per level. I remember having to optimise disc layouts for the original xbox - but I'd forgotten how slow CDs/DVDs really are.
I'll have to look closer at the level 2 / akiko stuff you mention.
I was confused why the code in CD32Load went through direct_psygore_cdio. It seemed mostly a debug layer, with some code for retrying disc operations too, but I see it does have some pause stuff in there too.

[Muzza]

Possible bug in cd32load, in handle_78, you do:

    move.w    #$2000,intreq+$DFF000
    btst.b    #0,$BFDD00        ; acknowledge CIA-B Timer A interrupt

I've read that you should clear the CIA ICR *before* clearing the INTREQ write. (disclaimer: my interrupt/CIA knowledge is poor so I may be wrong)

[Muzza]

Originally Posted by jotd

It may also be an issue about CD drive operation not done, so on CD32 (at least from CD0:, I don't know how to detect that), wait 100ms after each disk access. Or ack level 2 interrupt from Akiko by writing to Akiko INTREQ register.

I have no level 2 interrupt handler at all. I changed my keyboard handler to use polling instead of interrupts as my network card generated level 2 interrupts and then crashed the system.
Are you saying here that I should install one and do a move.w #0,AKIKO_INTENA in it? (I'm looking at handle_68 in whd.asm from cd32load), or is this something only required if I was installing my own level 2 interrupt?

[jotd]

If the interrupts are masked then you don't need it. And not 0,AKIKO_INTENA but INTREQ !!!

Level 6 TOD interrupt should be handled (or masked), though. When booting a game using whdload on the CD32, level 6 interrupt is triggered at start. Games which don't expect level 6 interrupt, disable the OS but don't mask the level 6 interrupt, those can have issues.

[Muzza]

Originally Posted by jotd

If the interrupts are masked then you don't need it. And not 0,AKIKO_INTENA but INTREQ !!!

Level 6 TOD interrupt should be handled (or masked), though. When booting a game using whdload on the CD32, level 6 interrupt is triggered at start. Games which don't expect level 6 interrupt, disable the OS but don't mask the level 6 interrupt, those can have issues.

ok thanks, I was confused because you said AKIKO INTREQ initially. Then I found move.w #0,AKIKO_INTEN in the cd32load code and my brain mis-read it as AKIKO_INTREQ

All of my interrupt code seems fine. I don't set up level 2 interrupts anywhere, and level 6 interrupts always acknowledge with move.w #$2000,INTREQ

I've produced two versions that Apollon has kindly been testing on real CD32s. The first one enables DOS to do loading, then disables it. It works for a time, but will eventually fail after loading level after level.
The second one uses cd32loader.asm and stays in system takeover mode the entire time. This one worked on a CD32 with a newer laser (although waiting on confirmation for stress tests), but failed quickly on a CD32 with an older laser. The CD_READFILEOFFSET command returned an error. When this happens, I wait 200ms, retry, wait 400ms, retry, up to 16 times. But it seems it always returns an error.

I'm low on ideas now, but I was wondering about my keyboard code. It uses polling rather than interrupts (which is why I have no level 2 interrupt set up). The polling will clear the CIA-A ICR by reading it. I'm wondering if that could mess with the CD loader at all.

[jotd]

Originally Posted by Muzza

All of my interrupt code seems fine. I don't set up level 2 interrupts anywhere, and level 6 interrupts always acknowledge with move.w #$2000,INTREQ

Then it's okay for TOD CIA

I've produced two versions that Apollon has kindly been testing on real CD32s. The first one enables DOS to do loading, then disables it. It works for a time, but will eventually fail after loading level after level.
The second one uses cd32loader.asm and stays in system takeover mode the entire time. This one worked on a CD32 with a newer laser (although waiting on confirmation for stress tests), but failed quickly on a CD32 with an older laser. The CD_READFILEOFFSET command returned an error. When this happens, I wait 200ms, retry, wait 400ms, retry, up to 16 times. But it seems it always returns an error.

I had issues with READFILEOFFSET command too. Psygore added that (superb work, thanks) to RN loader that he reversed (without providing any source of any kind, no thanks), then Toni found a potential "CD grind" issue in the original RN loader and fixed it, which made CD loader way more reliable, specially on old lasers/burned CDs (the "CD grind" issue was present in original RN CD games like Chuck Rock & Lotus but noone ever complained)

But on one particular game (Mortal Kombat 2) the game works fine on emulation and fails on real CD32 for that reason (without the horrible "grind" sound). No matter how many times you retry, it fails. I never found why, and I gave it up. Now with my TF I could try to make it work again, by creating lots and lots of CD32load versions with debug/options without burning a CD each time. That's how I made CD audio / CD data work together without too many issues & also debugged Jim Power CD32.

If you have relatively small files, I'd suggest that you real the file fully each time if possible.

I'm low on ideas now, but I was wondering about my keyboard code. It uses polling rather than interrupts (which is why I have no level 2 interrupt set up). The polling will clear the CIA-A ICR by reading it. I'm wondering if that could mess with the CD loader at all.

CD loader uses level 2 interrupt extensively. But I don't think that CIA is involved. I always hated keyboard polling in games, in my experience this results in wrong keyboard reads. For instance if you ack interrupts using INTREQ this could cause issues, but there's also AKIKO_INTREQ to clear that would not be cleared so that seems safe.

For your issue, how many people are concerned? How many people use a RAM-expanded CD32 that doesn"t have a TF-card with a IDE CF card? At the time I fought to run AGA games for vanilla CD32 and won some fights (Chaos Engine 2, Jurassic Park, Body Blows Galactic are the ones I'm remembering). But the configuration was very widespread.

[alexh]

If you can't make it work with 2MB Chip + 0MB Fast that I imagine that eliminates most CD32 owners?

There were various CD32 hardware expansions (Promodule, SX1, SX32, SX32 MK2, SX32 Pro, TF328, TF360). Most took SIMMs but they were sold with at least 4MB of FastRAM. The most common RAM config for expanded CD32s today will be 8MB FastRAM.

The availability of the TF328 in recent years means there's no reason not to add FastRAM to your CD32. But expanded units will be the minority I imagine.

I imagine all CD32 owners with an expansion can already use WHDload version with Preload?

Are you looking into a release with CDDA? That's the exciting feature of CD32 games

[jotd]

^^

this

[Muzza]

Yes, my original question was what is the minimum non-zero fast RAM that a CD32 owner has?
If it is 4MB, well I do have it working in 4MB by compressing all the files into the exe so that everything is loaded once by the OS before the game starts. The WHDLoad version was still doing OS flashing without more than 4MB RAM.

The ideal scenario would have been to do it like cd32load, and be able to load files during system takeover, and play CD audio too, all with minimum RAM requirements. I just prefer the exact control that it gives. But it is not easy, especially with a multi-day turn around to test every change that I make.

It seems like my 4MB working version would be adequate. The question of CD audio is still out there, as a number of people have requested it. I don't have high hopes that CD audio would be any easier than CD data in this scenario, but I've not looked much into at all yet.

[jotd]

CD audio is super easy with CD32load The only question is about what to put on the tracks as remakes are often copyrighted. But some aren't and are super-good.

[Muzza]

Originally Posted by jotd

For your issue, how many people are concerned? How many people use a RAM-expanded CD32 that doesn"t have a TF-card with a IDE CF card?

I got 2 requests. And a few people tried to make their own CD versions and came up with less than perfect solutions, so I figured I'd try my own and hopefully make it a better user experience.

I mean... I'm making an Amiga game, so it's not really about the number of people.