The X68000 games porting experiment

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Wed Mar 25, 2015 2:36 pm

8O

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* :)

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Wed Mar 25, 2015 2:56 pm

calimero wrote: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.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Wed Mar 25, 2015 3:50 pm

dml wrote: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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Wed Mar 25, 2015 4:03 pm

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.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1562
Joined: Sun Jul 31, 2011 1:11 pm

Re: The X68000 games porting experiment

Postby Eero Tamminen » Wed Mar 25, 2015 7:53 pm

Anima wrote:
Eero Tamminen wrote: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. :wink:


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/

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Wed Mar 25, 2015 8:05 pm

Eero Tamminen wrote: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...

User avatar
Strider
Atari Super Hero
Atari Super Hero
Posts: 866
Joined: Tue Jun 18, 2002 5:16 pm
Location: Grenoble, France
Contact:

Re: The X68000 games porting experiment

Postby Strider » Wed Mar 25, 2015 8:37 pm

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

Keep up the good work!
Strider from MJJ Prod
May the TOS be with you!

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Wed Mar 25, 2015 9:52 pm

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

Keep up the good work!

:cheers:
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?

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Wed Mar 25, 2015 9:57 pm

Eero Tamminen wrote: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.

User avatar
Strider
Atari Super Hero
Atari Super Hero
Posts: 866
Joined: Tue Jun 18, 2002 5:16 pm
Location: Grenoble, France
Contact:

Re: The X68000 games porting experiment

Postby Strider » Wed Mar 25, 2015 10:28 pm

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

Keep up the good work!

:cheers:
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 :D but I didn't notice too many frame drops.
The initial detection works fine.
Strider from MJJ Prod
May the TOS be with you!

anodyne
Atari freak
Atari freak
Posts: 67
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: The X68000 games porting experiment

Postby anodyne » Sat Mar 28, 2015 3:22 am

Anima wrote:
Eero Tamminen wrote: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?

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sat Mar 28, 2015 7:57 am

anodyne wrote: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
Atari freak
Atari freak
Posts: 67
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: The X68000 games porting experiment

Postby anodyne » Sat Mar 28, 2015 2:38 pm

Anima wrote:
anodyne wrote: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?

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sat Mar 28, 2015 4:06 pm

anodyne wrote: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 ;) ).

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1562
Joined: Sun Jul 31, 2011 1:11 pm

Re: The X68000 games porting experiment

Postby Eero Tamminen » Sat Mar 28, 2015 5:15 pm

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
Atari freak
Atari freak
Posts: 67
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: The X68000 games porting experiment

Postby anodyne » Sat Mar 28, 2015 7:38 pm

Anima wrote:
anodyne wrote: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
Atari freak
Atari freak
Posts: 67
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: The X68000 games porting experiment

Postby anodyne » Sat Mar 28, 2015 7:40 pm

Eero Tamminen wrote: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 ...

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Mar 29, 2015 9:14 am

anodyne wrote: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.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Mar 29, 2015 9:43 am

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).

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1562
Joined: Sun Jul 31, 2011 1:11 pm

Re: The X68000 games porting experiment

Postby Eero Tamminen » Sun Mar 29, 2015 10:32 am

Anima wrote: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?


Anima wrote:@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. :-)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: The X68000 games porting experiment

Postby dml » Sun Mar 29, 2015 10:37 am

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.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: The X68000 games porting experiment

Postby shoggoth » Sun Mar 29, 2015 11:02 am

Works on the CT60+SuperVidel.

Socks flew off.
Ain't no space like PeP-space.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Mar 29, 2015 11:13 am

Eero Tamminen wrote: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!? :shrug:

Eero Tamminen wrote:
Anima wrote:@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.

Eero Tamminen wrote: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.

Eero Tamminen wrote: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.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 655
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: The X68000 games porting experiment

Postby Anima » Sun Mar 29, 2015 11:23 am

shoggoth wrote:Works on the CT60+SuperVidel.

Socks flew off.

:cheers:

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

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: The X68000 games porting experiment

Postby shoggoth » Sun Mar 29, 2015 11:54 am

Anima wrote: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.
Ain't no space like PeP-space.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests

cron