WIP Atari ST ScummVM-lite

[exxos]

Speech and digital sound effects through the YM2149 :geek:

That is pretty sweet! :thumbup:

[terriblefire]

Can I get a copy?

[PhilC]

Can I get a copy?

Yeah, its rude not to share :lol: :dualthumbup:

[wietze]

This is very interesting and fun! How realistic is it to hope for a stock 4mb STE version?

[terriblefire]

This is very interesting and fun! How realistic is it to hope for a stock 4mb STE version?

It looks like its struggling in places @50 Mhz and 6Mb of RAM. I dont think its even worth trying for stock.

[agranlund]

Can I get a copy?

Absolutely. It's not really ready for github but I can for sure share some binaries for download in a day or so. With the usual caveat that it's far from done and expect issues etc etc..

I'm putting in some way of toggling some options at least, up until now I've just recompiled when testing different things.

[terriblefire]

Can I get a copy?

Absolutely. It's not really ready for github but I can for sure share some binaries for download in a day or so. With the usual caveat that it's far from done and expect issues etc etc..

I'm putting in some way of toggling some options at least, up until now I've just recompiled when testing different things.

Send me a PM.. Also interested in how to get the TF into the ST and shut the case. My STFM has the CPU right down the front by the keyboard.

[agranlund]

It looks like its struggling in places @50 Mhz and 6Mb of RAM. I dont think its even worth trying for stock.

If we're talking about a proper port to Atari, or Amiga for that matter, then I absolutely agree!
Official ports, or ports where you care about not diverging code too much from mainline ScummVM, will always struggle and I would agree it's impossible to get it running on anything but really fast machines.

This is not a fault of ScummVM. It's an incredible software and it's doing things in a very sensible way for something that needs to support a lot of very different game engines, as well as work on a lot of different platforms.

I am taking the mindset of porting a specific game (well, three specific games) to Atari and in a way similar to what we would have done at work a few console generations back if we were porting something to a vastly inferior platform compared to the baseline.
Anything that slows down is fixed no matter the cost in code-cleanliness, portability or if code diverges beyond recognition from mainline.
It becomes a clean break, and it's own thing, with no plan of merging back to main.
I picked version 0.6.0 as a start because the code is faster, but uglier, compared to the newer version. Most code not needed by my three target games were removed for speed and size reasons and some bits were changed to be more like 0.2.0 since that version is faster still.

This way there is a non-moving target in terms of code, a fixed platform, and a fixed input (ok, three, but they are very similar).


ScummVM likes to keep a fixed internal representation of graphics and sound, the different interpreters are responsible for outputting to this format, and the platform layer is responsible for converting to something the target machine understands.

The sound was a good example:

MI2/INDY4/DOTT outputs 11khz,8bit mono sound effects.
ScummVM converts everything to 22khz,16bit stereo at runtime during playback.
Platform layer converts this to something the machine understands.

So my first iteration was to make the atari platform layer, it accepts ~11khz,8bit mono.
Without any other changes this was extremely slow. It had to do this conversion at runtime:
11khz,8bit,mono -> 22khz,16bit,stereo -> 11 khz,8bit,mono (see the sillyness? :D)

With the freedom of being able to do whatever I want, and caring only for these three games, my second iteration was to "simply" make scummvm's internal representation 11khz,8bit,mono, got rid of a bunch of conversion code and we're ending up with just simply copying data instead (here is potential for further optimization to get rid of even that - as well as some mixing code)


But graphics will be the big one.
Similar to sound, it goes Game -> ScummVM common format -> Platform format
The plan is of course to rewrite the ScummVM layer to work with Atari bitplane graphics internally.
Right now, anything moving or animating is doing very costly chunky->planar conversions. As well as very costly game->scumm gfx conversion and chunky drawing in the first place.


But yeah, I wouldn't hold my breath. :)
The chance of success is still very low.


I am happy even if it ends up requiring a fast accelerator.
Even happier if works fine on stock TT.
Incredibly happy if it ends up working fine on stock Falcon.
Stock ST for Monkey2 only, possibly Indy4, is the target - working towards that puts me in a mindset of treating the code in a way that will help reach more of the above goals.

I don't see memory as a problem. 4MB has to be enough and that is what I test with when I run it on an emulator.
But yeah, I'm going to have to log memory usage to be sure.

[Atarian Computing]

Wow. My 260MB TT + Mach64 is volunteering to test.

[agranlund]

Does anyone here have a TT or stock Falcon?
I'd be interested in knowing if it runs on these machines... appears to work in Hatari but I'm not sure how accurate that emulator is.

(Sending you a PM Atarian Computing, but I'd be willing to bet it's not going to display on that Mach64.
It sets ST-Low resolution and grabs the screen pointer from TOS, and I assume that's a bad idea for machines with gfx card? I don't have any experience with gfx-card equipped Ataris)