The X68000 games porting experiment

[bear]

Tried it on my stock Falcon, absolutely stunning! Any plans for joypad support?

[Eero Tamminen]

Joystick (directions) didn't work originally with that EmuTOS version (0.9.4). As I've seen similar issue also in other games (mainly STOS ones), I'm very curious what you changed in Chorensa to get joystick working with EmuTOS?

Actually I changed nothing except using the newest EmuTOS so now I am a little bit confused when you say that the joystick doesn't work originally!?

I'm pretty sure I tested this version with v0.9.4:
http://atari-forum.com/viewtopic.php?f= ... 50#p270895

And you mentioned later on that you did some changes to fix IKBD handling?

[Anima]

What does SuperVidel support mean? You render directly into the snoop-area? It runs completely fluid.

Yes. When a SuperVidel is detected the screen memory is allocated within the ST-RAM area and $a0000000 is simply added to the returned and aligned address. So this was AFAIK the only change needed to support the SuperVidel. That's really a great solution.

Tried it on my stock Falcon, absolutely stunning! Any plans for joypad support?

Yes, I'll add it later on.

I'm pretty sure I tested this version with v0.9.4:
http://atari-forum.com/viewtopic.php?f= ... 50#p270895

And you mentioned later on that you did some changes to fix IKBD handling?

I fixed a bug which affected the joystick handling but it wasn't the IKBD interrupt routine itself. So does the current test release work on your side as well using the latest Hatari version in combination with EmuTOS 0.9.4?

[Anima]

I have updated the lastest test archive with various demo replay files which I've found on the internet. The files are stored in the "ETC_DAT" subdirectory ("DEMO2.REP" - "DEMO7.REP") and can be used by renaming them to "DEMO.REP". As an obvious rule of thumb: the bigger the replay file is the better the player was playing the game and the more enemies will be displayed on screen.

Fun fact: your gameplay is being recorded as well and when you're good enough to get an entry in the high score table it will be saved as a new "DEMO.REP" on the disk and will be used for the demonstration mode later on.

[Eero Tamminen]

I fixed a bug which affected the joystick handling but it wasn't the IKBD interrupt routine itself. So does the current test release work on your side as well using the latest Hatari version in combination with EmuTOS 0.9.4?

Yes, it works (thanks!). Maybe I had earlier used old EmuTOS version after all... <sigh>

[Dal]

Works on the CT60+SuperVidel.

Socks flew off.

Yes, Supervidel is supported. Can you please tell me if the initial text says that a Supervidel has been detected?

Yes, it does:

image.jpg

[Anima]

Yes, it does:

image.jpg

¡sʞuɐɥʇ ɥ∀

Note: while the Fast-RAM and the SuperVidel are fully supported - the FPU has nothing to do so the detection is just to complete the machine feature list. In fact on the X68000 some tables are being precalculated at the program start using the floating point library but that data has been moved into an included binary file.

[evil]

I have updated the lastest test archive with various demo replay files which I've found on the internet. The files are stored in the "ETC_DAT" subdirectory ("DEMO2.REP" - "DEMO7.REP") and can be used by renaming them to "DEMO.REP". As an obvious rule of thumb: the bigger the replay file is the better the player was playing the game and the more enemies will be displayed on screen.

Fun fact: your gameplay is being recorded as well and when you're good enough to get an entry in the high score table it will be saved as a new "DEMO.REP" on the disk and will be used for the demonstration mode later on.

A quick and badly filmed snap of this from a CT60/SV from this weekends Slaskhack in Falköping:
https://www.youtube.com/watch?v=gsbZXMmJynU

It seems that no matter what the game throws at it, it will say thanks and put it on screen without a sweat.

[dml]

It looks *ridiculously* good.

[Anima]

A quick and badly filmed snap of this from a CT60/SV from this weekends Slaskhack in Falköping:
https://www.youtube.com/watch?v=gsbZXMmJynU

It seems that no matter what the game throws at it, it will say thanks and put it on screen without a sweat.

Thanks for sharing the video! Yes, that hardware really smokes even the X68000 version.

[Scarlettkitten]

Wow that looks amazing on that hardware setup

[EvilFranky]

Still not had a chance to try this myself yet

But it's looking awesome. Can't wait to see the DSP sprite routine in action

[CiH]

A quick and badly filmed snap of this from a CT60/SV from this weekends Slaskhack in Falköping:
https://www.youtube.com/watch?v=gsbZXMmJynU

It seems that no matter what the game throws at it, it will say thanks and put it on screen without a sweat.

Time for a new bumper sticker,

"My retro hardware is arcade quality!"

[Anima]

Short update on the DSP optimising routine. A first test version is working quite well.

The following short video shows how the DSP internal screen for the mask positioning works. The screen data is simply transferred to the host and copied to the first bitplane. Note that the DSP draws all visible masks twice (inverted + normal mask) for each frame and also generates the RLE clearing data. So the CPU is drawing nothing except for copying the DSP internal screen.

DSP internal sprite masking.

Alas, doing bit manipulations like shifting with the DSP is quite challenging but after such a long time it's really fun again to work with the DSP.

Still some things to do but I still hope that this helps to finally have a playable version of ChoRenSha 68k on the stock Falcon030.

Edit: direct YouTube link: https://www.youtube.com/watch?v=fHs1WZlbkh4

[EvilFranky]

Not sure why but you're link isn't working mate. Or it could just be that I'm hammered.

[Anima]

Not sure why but you're link isn't working mate. Or it could just be that I'm hammered.

Probably it may take a while for the video to be visible for everyone!?

[Scarlettkitten]

Fantastic, having this running well on a stock 030 will be amazing

[EvilFranky]

Not sure why but you're link isn't working mate. Or it could just be that I'm hammered.

Probably it may take a while for the video to be visible for everyone!?

The direct link worked! Looking great!

[Anima]

Fantastic, having this running well on a stock 030 will be amazing

It won't run at full speed for sure but I hope that the game experience will be quite good. However, the DSP optimisation is helpful for other X68000 ports as well.

[dml]

Looks great!

Will be interesting to see how it compares with the earlier version. I suppose the host port is always a problem for small stuff like bullets but a major win for the big sprites with RLE & occlusion.

[Anima]

Looks great!

Will be interesting to see how it compares with the earlier version. I suppose the host port is always a problem for small stuff like bullets but a major win for the big sprites with RLE & occlusion.

That's right. ChoRenSha occasionally shows a massive sprite overdraw. This is quite exclusive to that particular game because it has a special powerful sprite engine and it makes a good use of it. Yeah, I hope the approach will benefit at least from the slow relative movement of the bigger sprites. The goal is to have an acceptable framerate on heavy sprite usage.

[dml]

BTW - I guess you know it, but transferring bytes over HOST is cheaper than words, and with a 256-wide screen its probably helpful for the RLE commands etc.... I suppose it depends on what you actually need to do with it though.

[BoNuS]

Very nice indeed, looks and play great from where i'm standing

[Anima]

BTW - I guess you know it, but transferring bytes over HOST is cheaper than words, and with a 256-wide screen its probably helpful for the RLE commands etc.... I suppose it depends on what you actually need to do with it though.

Ah, ok, that's new to me. Thanks for the hint. Actually the sprites are drawn over the left and right border so the values can be higher than 256 but those areas can be masked out. It's due to the fact that the internal screen is 16+256+16 pixels wide (which fits better into 24 bit words).

[Anima]

Quick update: the DSP RLE clearing functionality has been integrated into the true colour mode sprite routine. I think the framerate is now acceptable.

Here's a short video about the second DSP optimisation sprite test on a stock Falcon (16 MHz, 14 MB RAM)

ChoRenSha 68k second DSP sprite test

Direct YouTube link: http://youtu.be/iDfhkuvkAzg