The X68000 games porting experiment

[dml]

Yep, it is completely impressively nuts. Already playable!

It will be interesting to see what kind of benefit you get out of managing spans or tile coverage with DSP but it's already looking close without that. If it gets faster still then *bonus*

[Anima]

Is it wireframe version of game available for download? It runs in full speed on stock Falcon, right?

Well, no, it's too old and buggy. in fact, that's a nice idea! Probably a good tradeoff having a playable game with simple graphics but running at full speed.

[Anima]

It will be interesting to see what kind of benefit you get out of managing spans or tile coverage with DSP but it's already looking close without that. If it gets faster still then *bonus*

The idea is having a DSP program which keeps track of the pixels to be restored. So there are two bitmaps for both buffers and all the sprites as bitmapped masks stored in the DSP RAM.

As an example: a circular sprite object mask looks like this (16 bits per line, 16 lines, 1 = visible pixel, 0 = transparent pixel):

Code: Select all

0000000000000000
0000011111100000
0001111111111000
0011111111111100
0011111111111100
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0011111111111100
0011111111111100
0001111111111000
0000011111100000
0000000000000000


And it would work like this for each frame:

• Receive new sprite coordinates and infos from host.
• Mask out areas on the bitmap on each new sprite coordinate with "AND NOT MASK" operator.
• Create RLE restoration data by collecting all the 1 bits and their offsets (clear the bitmap in the process).
• Send RLE restoration data to the host.
• Write all sprite masks on the bitmap with "OR MASK" operator on their actual coordinate.

This should give a huge performance boost on big sprites, sprites with a slow movement and when sprite overdraw happens.

Hope this explains it quite well...

So adding the aforementioned optimisations in combination with an automatic frameskip this may result in a very good playable game.

[dml]

Yes this makes sense. Look forward to seeing how this develops.

Certainly my own use of the DSP has mostly focused on figuring out / limiting what the CPU needs to do, and of course overlapping them as much as possible. It's one of the most interesting and exploitable features of the machine.

[Eero Tamminen]

It works otherwise fine also with EmuTOS (v0.9.4), except for joystick directions. Are you reading joystick data in some non-standard / TOS version specific way?

Ahhhh... thanks for your report! The joystick should work now. So when you want to play it please download the latest version again.

Did you test the new version with EmuTOS [1] or did you just make the game more compatible with different TOS versions? Only joystick fire works still when using EmuTOS...

[1] Latest Falcon compatible version is the 512k one from here:
http://sourceforge.net/projects/emutos/ ... tos/0.9.4/

[Anima]

Did you test the new version with EmuTOS [1] or did you just make the game more compatible with different TOS versions? Only joystick fire works still when using EmuTOS...

[1] Latest Falcon compatible version is the 512k one from here:
http://sourceforge.net/projects/emutos/ ... tos/0.9.4/

Sorry. I actually fixed a joystick problem after reading your post and tested it on a real Falcon. So I thought this would fix the Hatari problem as well.

I'll have a look on it and report back...

[Strider]

Impressive! The game runs fast on 060. It is slower on 030 (although easier) but still playable.

Keep up the good work!

[Anima]

Impressive! The game runs fast on 060. It is slower on 030 (although easier) but still playable.

Keep up the good work!

Did you notice frame drops on higher sprite count or is it stable? I would like to know if the sprite restoration code for faster CPUs needs an optimisation as well. Does the initial detection of the machine features work properly?

[Anima]

Only joystick fire works still when using EmuTOS...

It seems that EmuTOS doesn't activate the IKBD joystick event reporting feature (IKBD $14)!? The fire button works because it is handled via the mouse button data packet.

[Strider]

Impressive! The game runs fast on 060. It is slower on 030 (although easier) but still playable.

Keep up the good work!

Did you notice frame drops on higher sprite count or is it stable? I would like to know if the sprite restoration code for faster CPUs needs an optimisation as well. Does the initial detection of the machine features work properly?

It is stable on 060 (running at 66 MHz, Falcon bus still at 16 MHz).
Well, I just played the first minutes of the game because it is quite hard but I didn't notice too many frame drops.
The initial detection works fine.

[anodyne]

Only joystick fire works still when using EmuTOS...

It seems that EmuTOS doesn't activate the IKBD joystick event reporting feature (IKBD $14)!? The fire button works because it is handled via the mouse button data packet.

Hi, thanks for your investigation! I'm an EmuTOS developer and I'd like to fix this. Which keyboard packets are you expecting that you don't get? And is this on Joystick 1 or Joystick 0?

[Anima]

Hi, thanks for your investigation! I'm an EmuTOS developer and I'd like to fix this. Which keyboard packets are you expecting that you don't get? And is this on Joystick 1 or Joystick 0?

Hi anodyne,

please have a look at this IKBD document: https://freeshell.de/~monokrom/monochro ... s/ikbd.txt

The expected packet:

Code: Select all

5.1 Joystick Event Reporting

In this mode, the ikbd generates a record whever the joystick position is
changed (i.e. for each opening or closing of a joystick switch or trigger).

The joystick event record is two bytes of the form:
    %1111111x           ; Joystick event marker
                        ; where x is Joystick 0 or 1
    %x000yyyy           ; where yyyy is the stick position
                        ; and x is the trigger


The "joystick event reporting" mode can be activated via command $14:

Code: Select all

9.15 SET JOYSTICK EVENT REPORTING

    0x14

Enter JOYSTICK EVENT REPORTING mode (DEFAULT). Each opening or closure of a
joystick switch or trigger causes a joystick event record to be generated.


Hope this helps.

[anodyne]

Hi, thanks for your investigation! I'm an EmuTOS developer and I'd like to fix this. Which keyboard packets are you expecting that you don't get? And is this on Joystick 1 or Joystick 0?

Hi anodyne,

please have a look at this IKBD document: https://freeshell.de/~monokrom/monochro ... s/ikbd.txt

...

Hope this helps.

Thanks for the fast response! I have that document in hardcopy from a long time back and I looked at it before posting my question. Over many years, I have learned never to assume anything when debugging, that's why I tried to ask very specific questions.Two more questions:
1. is the joystick connected to port 0 or port 1?
2. are you sending any commands to the IKBD during e.g. program startup?

[Anima]

1. is the joystick connected to port 0 or port 1?
2. are you sending any commands to the IKBD during e.g. program startup?

I tested it so far only with joystick #1 but both are supported by the interrupt handler. I'm sending no command to the IKBD. So in fact I am assuming that the TOS "default" IKBD settings are active (I know: never assume anything ).

[Eero Tamminen]

Hm. So normal TOS enables joystick reporting at boot although there's nothing using joystick. Similarly to how it enables at boot the Falcon sound matrix sound output... (EmuTOS doesn't seem to by default enable things unused by its own desktop, like normal TOS does)

[anodyne]

1. is the joystick connected to port 0 or port 1?
2. are you sending any commands to the IKBD during e.g. program startup?

I tested it so far only with joystick #1 but both are supported by the interrupt handler. I'm sending no command to the IKBD. So in fact I am assuming that the TOS "default" IKBD settings are active (I know: never assume anything ).

OK, I wrote a small test program that grabs the joystick vector (address gotten by Kbdvbase()) and reports the packets it sees. I ran Hatari 1.7 (old core) with the latest EmuTOS. I set Hatari to use an emulated joystick 1, and pressed up, down, left, right. The packets seen were:
FF 00 01
FF 00 00
FF 00 02
FF 00 00
FF 00 04
FF 00 00
FF 00 08
FF 00 00
This looks OK, as far as I can see. Or am I missing something?

[anodyne]

Hm. So normal TOS enables joystick reporting at boot although there's nothing using joystick. Similarly to how it enables at boot the Falcon sound matrix sound output... (EmuTOS doesn't seem to by default enable things unused by its own desktop, like normal TOS does)

I believe that a reset of the IKBD enables joystick reporting, so TOS / EmuTOS don't have to do anything. At least, that's how it seems to work on Hatari 1.7 ...

[Anima]

This looks OK, as far as I can see. Or am I missing something?

Yes, the results are reasonable. That's what I expect as well.

I've made another test by setting a breakpoint on the IKBD interrupt routine and checking the incoming events after a clean boot. Actually there's no reaction while using the joystick. Tested on Ubuntu, Hatari 1.8.0 and EmuTOS 0.9.3.

Update: it works using EmuTOS 0.9.4! So I strongly recommend to use the latest version if you want to play it using Hatari.

@Eero: I'll prepare a special Hatari version to remove the flicker.

[Anima]

A short update for Hatari users: here's a new build of ChoRenSha 68k which includes a special Hatari version showing less flicker. If you're using EmuTOS and you want to play the game with a joystick please get the latest version (0.9.4).

[Eero Tamminen]

I've made another test by setting a breakpoint on the IKBD interrupt routine and checking the incoming events after a clean boot. Actually there's no reaction while using the joystick. Tested on Ubuntu, Hatari 1.8.0 and EmuTOS 0.9.3.

Update: it works using EmuTOS 0.9.4! So I strongly recommend to use the latest version if you want to play it using Hatari.

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?

@Eero: I'll prepare a special Hatari version to remove the flicker.

How that version differs from the other version?

At least with latest Hatari (WinUAE CPU core) version from Mercurial, the "sz2_hatari.tos" flickers a lot more than "sz2.tos". Flickering happens only when there are more explosions, but then it's very visible, one can see it e.g. right at start by shooting at the depris (stuff that flies upwards in the beginning).

Also, would it be possible to get debug symbols included to the program:
http://hg.tuxfamily.org/mercurialroot/h ... _emulation
?

With those the program could be profiled. And if there are specific symbol for:

• an address / subroutine that gets called (first time) when the actual game play starts
• an address that gets called only once per each frame
• an address that gets called (only) when player dies / game play ends

profiles could be automatically generated for slowest frame in the game (I could write shell / Hatari debugger scripting for that).

With the already existing demo mode, this would very easily tell you largest bottlenecks in your code, you just run a script for this, and view the produced profiles.

[dml]

Dunno if it's relevant, but I found that setting the physbase address on the VBL interrupt (however early or late) doesn't work in Hatari because it commits that register before (or while initiating) the VBL event - and it presents the wrong framebuffer.

Real HW doesn't read the physbase until the display hardware wakes up sometime after the VBL.

This is a source of flicker for any project that tries to do that.

[shoggoth]

Works on the CT60+SuperVidel.

Socks flew off.

[Anima]

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!?

@Eero: I'll prepare a special Hatari version to remove the flicker.

How that version differs from the other version?

I am writing the screen address to $ffff8201/3/d within the VBL handler (like Doug already has noted in the other post) so I simply exchange the screen addresses for work and display buffers and it works "kind of" well so far as a workaround for Hatari.

At least with latest Hatari (WinUAE CPU core) version from Mercurial, the "sz2_hatari.tos" flickers a lot more than "sz2.tos". Flickering happens only when there are more explosions, but then it's very visible, one can see it e.g. right at start by shooting at the depris (stuff that flies upwards in the beginning).

Well, generally it should show less flicker from what I see here using Hatari 1.8.0 so I am wondering if the above mentioned screen address register emulation has already been added!? If so you can safely use the original version.

Keep in mind that the current version is mainly targeted at faster machines for some performance test and the current sprite emulation hook is not quite at the right place. So you will experience flickering with Hatari at scenes with heavy sprite usage. I hope to reduce this with the upcoming DSP optimisation but I guess that the game will also need a frame skip algorithm to keep up with the speed.

Also, would it be possible to get debug symbols included to the program:

Yes, there's a debug version which is not included in the public archive and I already played around with the Hatari profiling options. Those are great and I'll use them when I have found the right places for the Atari graphic routines.

[Anima]

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?

[shoggoth]

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

It does

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