Klax - STE DMA sound patch

[junosix]

Spent the last few days patching up the classic puzzler Klax with some DMA routines to play the arcade samples on the STE, plays a lot nicer with them! Don't think I've introduced any problems with the modifications but if there's anything egregious then let me know and I'll make the changes.

(Falcon users, see this post for a compatibility patch: http://atari-forum.com/viewtopic.php?f= ... 55#p334247)

https://youtu.be/H2RIa_VN39U

[junosix]

Ha! And I've just spotted something - no text when a new wave starts. I'll crack on with that this evening.

[Anima]

Thanks for the (ST)Enhancement.

[vebxenon]

Spent the last few days patching up the classic puzzler Klax with some DMA routines to play the arcade samples on the STE, plays a lot nicer with them! Don't think I've introduced any problems with the modifications but if there's anything egregious then let me know and I'll make the changes.

https://youtu.be/H2RIa_VN39U

Klax is one of my favorite games. Thanks very much!

[junosix]

Klax is one of my favorite games. Thanks very much!

Same! My favourite puzzle game of all. Happy memories of playing it at an arcade in the summer of 1990 then being so excited to see an ST copy for sale a few months later. Shame they never added these sounds back in the day, it wouldn't have taken much more effort, I'm sure I'm playing it better with the proper sounds in.

Don't know why Wave 02 in the YT video I posted had no graphics in it, I've just played it again and they're there. I'll keep an eye on it.

[junosix]

Have removed the original disk image and added two files - a .zip with the .TOS executable that ought to be able to be run from a hard disk, and a disk image that uses a bootsector loader meaning it can be loaded into lower memory and run on 520STEs (and of course machines with more memory). Nice thing about this one is it sets the screen to black as soon as it starts booting which I think is a bit nicer.

[bjkock]

Great Work, Thanks!

I have a problem loading the .TOS file on my STE (4MB) when my HD (SH204) is on.
Both the .ST and the .TOS version loads and runs perfectly from floppy if the HD is turned off, but as soon as I have booted the STE with the HD (with HDdriver 10.10) and try to run the .TOS file from the HD or the disk the file loads and the screen turns black and then the STE hangs.
I have disabled the Auto folder on the HD and no ACC or other programs are running in the background, so the STE is “clean”.
It seems that the Game somehow uses the same DMA routines as the HD and therefore it hangs when it tries to start the sound with the HD on.

Any clue to what the problem could be?
I know it´s not a faulty DMA chip since that is taken care of

[AtariZoll]

I have disabled the Auto folder on the HD and no ACC or other programs are running in the background, so the STE is “clean”.
It seems that the Game somehow uses the same DMA routines as the HD and therefore it hangs when it tries to start the sound with the HD on.
Any clue to what the problem could be? ...

Actually, it is not that clean. Hddriver takes lot of low RAM, especially when there is more RAM in machine. That affects many games, because they are not really 100% relocatable. Solution is to lower caches of Hddriver, or to use some other, not so RAM hungry one.

[junosix]

I have disabled the Auto folder on the HD and no ACC or other programs are running in the background, so the STE is “clean”.
It seems that the Game somehow uses the same DMA routines as the HD and therefore it hangs when it tries to start the sound with the HD on.
Any clue to what the problem could be? ...

Actually, it is not that clean. Hddriver takes lot of low RAM, especially when there is more RAM in machine. That affects many games, because they are not really 100% relocatable. Solution is to lower caches of Hddriver, or to use some other, not so RAM hungry one.

The game starts at memory address $400 which is where a lot of system variables live, so any hard disk driver that lives down that end of the RAM will have a problem. I tested it via the hard disk support in Hatari which worked, but I haven't got a hard disk for my ST so can't test it for real. The code is definitely not relocatable (at least my DMA sound routines use absolute addresses for the sample data, and I would assume more likely than not that the game's code does similar stuff). Not sure what alternative hard disk drivers are out there that might not sit in such low RAM.

[bjkock]

I have disabled the Auto folder on the HD and no ACC or other programs are running in the background, so the STE is “clean”.
It seems that the Game somehow uses the same DMA routines as the HD and therefore it hangs when it tries to start the sound with the HD on.
Any clue to what the problem could be? ...

Actually, it is not that clean. Hddriver takes lot of low RAM, especially when there is more RAM in machine. That affects many games, because they are not really 100% relocatable. Solution is to lower caches of Hddriver, or to use some other, not so RAM hungry one.

The game starts at memory address $400 which is where a lot of system variables live, so any hard disk driver that lives down that end of the RAM will have a problem. I tested it via the hard disk support in Hatari which worked, but I haven't got a hard disk for my ST so can't test it for real. The code is definitely not relocatable (at least my DMA sound routines use absolute addresses for the sample data, and I would assume more likely than not that the game's code does similar stuff). Not sure what alternative hard disk drivers are out there that might not sit in such low RAM.

Thank you for your replies guys!
Sounds like it´s HDdriver that´s the “bad guy” here.
I´ll will play around with some other Hard disk drivers and see if I can get it to run from HD.
In the mean time I´ll use an old fashion floppy to play this highly addictive game.

[AtariZoll]

...
The game starts at memory address $400 which is where a lot of system variables live, so any hard disk driver that lives down that end of the RAM will have a problem. I tested it via the hard disk support in Hatari which worked, but I haven't got a hard disk for my ST so can't test it for real. The code is definitely not relocatable (at least my DMA sound routines use absolute addresses for the sample data, and I would assume more likely than not that the game's code does similar stuff). Not sure what alternative hard disk drivers are out there that might not sit in such low RAM.

OK, things are clear now. Since I did lot of game fixes, reassembles, here are some things you need to know, care about:
Hard disk driver and his workspace, buffers, cache is normally placed in first free RAM area - in case of autoboot is is right after TOS workspace - actually it should go there, but it goes some 15 KB higher (depending from TOS version) , and those 15 KBs are lost, except some smart SW using them. Practically same is with AUTO start. So, in TOS 1.04 driver will load at address ~$A84E . If you load from Desktop, clean boot it will load even higher, after AES, Desktop workspace.
Hddriver will add lot of buffers on 4MB machine, over 100-150KB, and that's why it fails. With usage of some 50KB it would work most likely,

Now, considering concrete problem - not relocatable DMA sound sample addresses - that should be done relocatable. Yes, lot of games suffers from that problem - not being fully relocatable. I rearranged some - like Hard 'n' Heavy. Even if it is fully relocatable, like Uridium, some rearrangement is useful - they put large blocks of zeros in middle of code, for instance, instead using bss section after code, data for that.
Disassembling game can help - but that may be lot of work and time. In any case, you need to know memory usage, layout of it, to avoid conflicts, + then will know how mach RAM it needs. Ideal case is that game uses 1 contigous block of RAM only + screen buffer - and that is case of fully relocatable. Here to add that screen address must be not fixed too (error of Flight Simulator 2) - you use original address, what is top of RAM, or self set it there. So, on machines with more RAM, code can run at higher address, and still not reaching screen buffer space.

[junosix]

Think I may have cracked it, in the .TOS version I have a small bit of code that loads all the code+data in one go, disables interrupts, copies the game from wherever it is currently into memory starting at $400 (as that's where the original game expects it to be) then jumps to $400. I think it's more that my relocating code was being overwritten as I hadn't set it high enough in memory rather than any conflict as such with the hard disk driver. So assuming that the hard disk version will be run on a 1040 at least, I've just changed the address of the relocating code to run higher in memory. I've attached it to my first post (klax_dma_1040_executable_version.zip), see if that does the trick. I could be more fancy and check the amount of RAM in the system then put my relocating code at the top of RAM relevant to that but I won't have a chance until after the weekend, be interested to see if this version does the job first though.

[AtariZoll]

Think I may have cracked it, in the .TOS version I have a small bit of code that loads all the code+data in one go, disables interrupts, copies the game from wherever it is currently into memory starting at $400 (as that's where the original game expects it to be) then jumps to $400. I think it's more that my relocating code was being overwritten as I hadn't set it high enough in memory rather than any conflict as such with the hard disk driver. So assuming that the hard disk version will be run on a 1040 at least, I've just changed the address of the relocating code to run higher in memory. I've attached it to my first post (klax_dma_1040_executable_version.zip), see if that does the trick. I could be more fancy and check the amount of RAM in the system then put my relocating code at the top of RAM relevant to that but I won't have a chance until after the weekend, be interested to see if this version does the job first though.

Hmm. - it game runs at fixed address, + it is very low in RAM then it is single load - after that no more disk access possible via TOS filesystem.
With fixed final address you actually don't need relocation of code what works during gameplay - it will be always on same address. I think that it's best to do needed relocations for that final address once (not by end user, but by coder), and save final code+data with all addresses as final ones. So will start faster, you can even pack it - and after depacking need only to jump to start.
Will check that new v. later ...

[AtariZoll]

Checked that new exec (at top of DL in first post) - and it seems that is OK. Installed some 300KB RAMDISK before starting it, what should be even more than what Hddriver takes on 4MB machine - worked fine

[Sturm]

Does it work on Falcon too ?

[junosix]

Checked that new exec (at top of DL in first post) - and it seems that is OK. Installed some 300KB RAMDISK before starting it, what should be even more than what Hddriver takes on 4MB machine - worked fine

Hoorah! Thanks for testing it I take on-board the stuff you say about relocation and things but luckily it doesn't look like I need to worry about that for this one.

It ought to work on the Falcon in terms of not crashing or anything horrible like that, but the samples depend on the 6258Hz replay frequency in the STE, which as far as I'm aware is not supported on the Falcon (only the higher frequencies are). Should be okay on the Mega STE and TT though.

[bjkock]

....... I've attached it to my first post (klax_dma_1040_executable_version.zip), see if that does the trick. .....

Yes indeed, that did the trick!
Now it works perfectly from HD on my STE

Did not get it to work on my Falcon 030 though, but since it is a 1040 STE game that´s not to much to worry about

Great work!

[AtariZoll]

It will not work on Falcon - as said sample freq is not supported on it.
Maybe to do version with 12.5 KHz samples ? I can do other things necessary for Falcon run.

[junosix]

I'll have a go at sticking in 12.5kHz samples in sometime. Am I right in thinking the Falcon doesn't need to have the values written to the YM volume registers lowered because the balance between YM+DMA in the Falcon is correctly done?

Glad you're enjoying it bjkock!

[AtariZoll]

I'll have a go at sticking in 12.5kHz samples in sometime. Am I right in thinking the Falcon doesn't need to have the values written to the YM volume registers lowered because the balance between YM+DMA in the Falcon is correctly done?

Yes, Falcon has well balanced YM-DMA levels. I noticed that it is balanced on STE in your patch. So, you did same as me with Xenon2.
I think that best is to do v. with 12.5KHz samples, original YM volumes. It will be OK for Falcon, and for STE machines with mixer fix + for modded Steem 3.2 - where can set YM and DMA audio levels separately. RAM should be no problem - all STEs have min 1MB.

[junosix]

Okay - I think this is the final revision (unless there is anything else that needs to be done to make it totally Falcon compatible - do I need to set 8MHz and turn cache off or anything too?). Falcon version doubles the samples in RAM once they're loaded to create 12kHz versions. Going through things to make the Falcon version made me aware of a few corrections needed in the original STE version (couple of incorrect sample pointers and a fix to stop the PSG sound crunching occasionally). Let me know if the sound balance is right on the Falcon, if not I can make the necessary adjustments.

Have changed the .zip file in the first post to include three (hopefully final!) versions:

klax_dma_520ste.st - bootable disk for all STEs (including 520STE)
KLAX_DMA.TOS - hard disk version (requires 1040STE minimum)
KLAXFALC.TOS - hard disk version for all Falcons

[AtariZoll]

I will test it when day comes It may need activating STE bus emulation, caches off, 8 MHz. Depending from how will work,
But one thing is sure - it will need move of PMMU tables on different location - because game will kill original tables at adr. $700 .
And one more: need to perform proper XBIOS call for setting STE audio DMA mode before start too.

[AtariZoll]

OK, did some tests on real Falcon and in Hatari 2.0.0 .
Klaxfalc works on them via FSTE8CO or FSTE16C0 - small programs for setting Falcon in STE mode, PMMU, etc . One will run at 8, other at 16 MHz .
You need to copy them in game's DIR and drag & drop KLAXFALC.TOS in ... Then will work. Sound balance is good, it seems (hears) .

FSTES.ZIP

Now some opinion about how I think it would be better: If possible using some resample SW for getting 12.5 samples from 6,25 ones, instead doing that copy on fly - better sound, less RAM usage, faster start. Or even better - sources with higher samplerate.
Then, there is no real need for separated Falcon long executable - do STE version with 12.5 KHz samples, and use it for Falcon, just with setting proper mode for Falcon run. Best is to use only (packed) final binary content $400 - $70400 (more for 12.5 samples) instead doing some calculations, moving it down ... That will make shorter file, less problems with low RAM usage, faster start (depacking can be fast) .

[junosix]

Good one, nice work!!

Re: the samples. The original arcade sounds are only ~6750Hz anyway so there's not that much loss converting them to 6258Hz nor much gain in upsampling them to 12517Hz (I'm not really savouring the thought of cutting and resampling them again either! The original goal was to get a version of Klax with samples that could have conceivably run on a 520 STE back in the day and I'm pleased to have made that work). I'd be happy to try to see if interpolating the samples when doubling them has any effect though.

The ST version is only an approximation of the arcade game anyway so I think if any extra efforts should be made on a Falcon version it should be concentrated on a more accurate conversion of the arcade original

[AtariZoll]

Well, it was just using my old tools done in purpose to make Falcon more compatible with STE games. I planned to do it yesterday, but that day was a disaster. And it is luck that Klax does not need some special patches to work on 68030 .
Yes, more accurate conversion of arcade sounds nice. Time needed for it - less nice