Converting a "system-takeover" game to OS friendly

[alpine9000]

Hi,

I have been working on a new option for an up-coming game to provide an OS friendly configuration (as opposed to system-takeover) for those with a bit of extra CPU and external devices that can cause problems for "system-takeover" games and demos (I'm looking at you TCP/IP and USB stacks!). Note: I will still be supporting the "system-takeover" versions for lower spec machines or those that don't care about running a TCP stack behind a game.

I took my info mainly from "howtocode7" as well as the gloom source code and some EAB posts on various things like keyboard input.

I have made a bunch of changes and so-far with the exception of a small performance hit on slower CPUs it seems to be working. But I thought I would outline what I did in case anyone can make any suggestions or see's something I have missed.

So this is what I did:

1. Replaced the standard "demo startup code" with new code I wrote. This actually does less than what most demo startup code does. So far all I do is:
   • Handle the workbench messages etc (this is unchanged)
   • Save the current view
   • Save the copper pointers
   • Load a null view
   • Own the blitter
   • Disable sprite DMA (my game doesn't use sprites as it stands)
   • Set the task priority to 20 (anything higher than this seems to prevent input.device from sending me events)
2. Replace my VBLANK vector hijacking with AddIntServer calls with appropriate system compatible changes to the handler routine.
3. Replace my direct hardware keyboard routines (including PORTS vector hijacking) with an input.device handler that looks for keyboard events and swallows them preventing keyboard events reaching workbench (my game has no window).
4. Run P6112 player in "system friendly" mode.
5. Only change DMA for copper/raster/audio and leave it as I found it.
6. Restore view/copper/dma/disown blitter on exit with appropriate system clean up

So far from the testing I have done, it seems to be working well both in emulation and on real hardware, however I don't have any hardware that creates unwanted interrupts (not sure if my PCMCIA card generates PORTS interrupts).

Any suggestions would be greatly appreciated

[meynaf]

To be 100% sure you do not have to worry at all about unwanted interrupts, TCP/USB stacks, special keyboard drivers, etc, you can :
- Open an Intuition screen and a backdrop/borderless window on it.
- Use IDCMP messages rather than input.device.
- Allocate audio with audio.device (then you can touch audio HW).
- Own blitter only when you use it, not for the whole program's duration. Or better, not use the blitter at all if you know the machine has a fast CPU.
- Do not touch task priority (no real positive impact on accelerated machines and it could block an important task).
- Use system calls like WaitTOF() rather than empty polling loops, for timing.

I also humbly suggest you isolate everything that is accessing hardware or OS into some kind of system framework, so that you can reuse it at will for all future projects.

[alpine9000]

Originally Posted by meynaf

To be 100% sure you do not have to worry at all about unwanted interrupts, TCP/USB stacks, special keyboard drivers, etc, you can :
- Open an Intuition screen and a backdrop/borderless window on it.
- Use IDCMP messages rather than input.device.
- Allocate audio with audio.device (then you can touch audio HW).
- Own blitter only when you use it, not for the whole program's duration. Or better, not use the blitter at all if you know the machine has a fast CPU.
- Do not touch task priority (no real positive impact on accelerated machines and it could block an important task).
- Use system calls like WaitTOF() rather than empty polling loops, for timing.

I also humbly suggest you isolate everything that is accessing hardware or OS into some kind of system framework, so that you can reuse it at will for all future projects.

What’s the reason for using a screen/window versus input.device?

I’ll look into allocating the audio, seems the polite thing to do.

Thanks for the pointers.

[meynaf]

Originally Posted by alpine9000

What’s the reason for using a screen/window versus input.device?

Well i am not sure that else, all special keyboard drivers would work (for people not using true Amiga keyboards, like usb or serial).
It is also a lot easier to use the mouse.

And anyway it allows your program to multitask happily.
You can then use Amiga-M to return to OS (for whatever task you want to do) without quitting the game, grab the screen with any Amiga screen grabber, use tools such as Snoopdos/Enforcer, etc.
I haven't done it myself, but you could add support for gfx cards as well.

[alpine9000]

Originally Posted by meynaf

Well i am not sure that else, all special keyboard drivers would work (for people not using true Amiga keyboards, like usb or serial).
It is also a lot easier to use the mouse.

And anyway it allows your program to multitask happily.
You can then use Amiga-M to return to OS (for whatever task you want to do) without quitting the game, grab the screen with any Amiga screen grabber, use tools such as Snoopdos/Enforcer, etc.
I haven't done it myself, but you could add support for gfx cards as well.

Interesting points, thanks again. I think step 1 is “OS friendly/compatible”, maybe next time around I will try for fully multitasking compatible

It’s a little bit complicated by the fact that the same code base does the trackloaded A500 version.

[jotd]

why not writing a whdload slave for your OS friendly game?

[alpine9000]

Originally Posted by jotd

why not writing a whdload slave for your OS friendly game?

I’ll admit I don’t know much about whdload (other than how to run it), but from what I can see whdload suffers from this same limitations as my “system takeover” games. i.e needing to shut down tcp stacks etc? Correct me if I’m wrong?

[meynaf]

Right, whdload indeed takes over the system.

[alpine9000]

Originally Posted by meynaf

Right, whdload indeed takes over the system.

How does whdload do disk io? Or does it just load everything into ram?

[meynaf]

Originally Posted by alpine9000

How does whdload do disk io? Or does it just load everything into ram?

It loads everything into ram if you use the PRELOAD option (usually the case).
Else it switches to/from OS, like when saving a game. Makes black screen and stopped sound while performing disk accesses.

[alpine9000]

Originally Posted by meynaf

It loads everything into ram if you use the PRELOAD option (usually the case).
Else it switches to/from OS, like when saving a game. Makes black screen and stopped sound while performing disk accesses.

Right that’s how my system takeover version works. One big advantage of leaving the OS running is the ability to do disk io nicely.

[alpine9000]

So it seems that the P6112 player allocates the audio.device when in system friendly mode.

During my testing however it seems some apps don't correctly respect the allocation protocol (either they don't allocate audio, or don't correctly respond to a channel being "stolen").

[jotd]

whdload main advantage is that it does everything properly AND supports MMU (on some machines there's remapping of the zero page, which crashes the games if you don't cancel it because VBR is there )

Black screen is annoying only if there's a lot of data to load. For hiscore saving, if the original file is full of zeroes but saving scores doesn't change the file size, you won't even have black/flash screen. Scores will be saved when exiting the program.

of course, all TCP stacks are killed (but whdload provides ability to execute startup & end scripts to handle external hardware if needed, well, the user must adapt to his config)

[alpine9000]

Originally Posted by jotd

whdload main advantage is that it does everything properly AND supports MMU (on some machines there's remapping of the zero page, which crashes the games if you don't cancel it because VBR is there )

Black screen is annoying only if there's a lot of data to load. For hiscore saving, if the original file is full of zeroes but saving scores doesn't change the file size, you won't even have black/flash screen. Scores will be saved when exiting the program.

Yeah, my games have supported non zero VBR since someone picked up that I missed it with Blocky Skies!

I always test on MMU so I can use Enforcer.