Multipurpose PM engine for use in Basic

[analmux]

Hi all,

 

Someone asked me if it is possible to have a multipurpose PM engine for use in Basic or Turbobasic.

So, I started thinking: Of course it is. So, I'm considering to write one.

 

These are the main features planned for the engine

-it can be binary loaded

-it is relocatable to any point in user RAM

-it should be possible to select if one wants 5th player or 4 missiles

-arbitrary length of players (as long as total length is not too much)

-multicolour PM supported (AFAIK, many PM engines have no support for flicker-free multicolour PM, so maybe it's time to write one)

 

It will be a two-part engine: The main part is a Vertical Blank interrupt which moves all the data around.

The second part is the 'connection' between the interrupt and basic.

 

In basic one just needs something like:

Q=USR(PMENGINE,X1,Y1,SHAPE2,X2,Y2,SHAPE2,...)

Before loading, one needs to specify the address where the code can be installed, and the address of PM-base, whether coarse or fine resolution is needed, and if one wants 5th player or 4 missiles.

 

One idea is to make a flexible USR operation:

Q=USR(PMENGINE,M,....)

where M is a bit-mask which specifies which players/missiles must change. Then the '....' will only contain the needed extra data.

 

I know it should be easy to use this in Turbobasic, just BLOAD "D:PMENGINE.OBX" or something.

I'm still not sure how to do it in ordinary basic.

 

 

Any others interested? Any other suggestions or questions?

[+Philsan]

We already have many PMG ML routines.

 

For example

http://www.atarimaga...ics_Toolkit.php (not the faster but the best all-around PMG ML routine I've found so far)

http://www.page6.org..._13/page_32.htm

http://atariwiki.str...e/PlayerMissile

 

These routines have many limitations (flicker, players height, number, resolution, not compilable with TBXL).

Furthermore with those limitations it's impossible to have multicolor players or bigger sprites because they are drawn on screen in different moments.

 

I agree it's time to have a routine so TBXL programmers could develop games without having to learn ML.

 

Regarding multicolor players, here is something perhaps useful

http://atariwiki.strotmann.de/xwiki/bin/view/APG/Multi+Player+Animator

 

Thanks in advance!

Edited August 24, 2009 by Philsan

[atariksi]

>I know it should be easy to use this in Turbobasic, just BLOAD "D:PMENGINE.OBX" or something.

 

What's the header for this OBX format (assuming it has one)?

[Synthpopalooza]

Another idea for your engine:

 

Supports usage of DLI's so you can split your players into several different players on each horizontal line.

 

I do have a BASIC program which will convert any disk file (including a binary file) into string assignments or DATA statements and generate the necessary code to move it anywhere in memory. The string assignments use the variable name table offset so that movement into memory is instantaneous. Oh, and for binary files, the first six bytes are stripped out.

[Heaven/TQA]

>I know it should be easy to use this in Turbobasic, just BLOAD "D:PMENGINE.OBX" or something.

 

What's the header for this OBX format (assuming it has one)?

 

it is the standard atari binary dos format... we only renamed the .exe output of some assemblers to .xex and the .obj or .com output to .obx to avoid confusion with Windows... only .asx remained as text xasm assembler file which is audio streaming on windows but well...

[analmux]

Supports usage of DLI's so you can split your players into several different players on each horizontal line.

You mean some kind of multiplexer? I have been thinking about it, but maybe it's still a bit too early for this. To handle this correctly we would need to handle the moving objects as virtual sprites. But maybe Heaven has some more ideas on this, remembering his PM multiplexer hobby some years ago.

[analmux]

Regarding multicolor players, here is something perhaps useful

http://atariwiki.strotmann.de/xwiki/bin/view/APG/Multi+Player+Animator

Looks like a useful PM routine, except that it doesn't seem to depend on a Vertical Blank interrupt. It is based on a USR call. So I think it will show some flicker now and then.

[analmux]

OK, here's first try. Source code included.

 

http://www.phys.uu.nl/~bpos/PMTBB/

 

The .atr file is the one to play with. When booting it, press L (in the dos screen) and then TURBOBAS.SYS

 

Then first do BLOAD "D:MAIN.OBX"

 

Then do LOAD "D:TEST2.TBB"

[+Philsan]

Exactly what I need. Thank you very much.

Would it be possible to increase speed and smoothness? Perhaps decreasing players height?

Would it be possible to also move a fifth player or the 4 missiles?

 

 

[analmux]

Would it be possible to increase speed and smoothness?

Yes, but that's up to the user. Smoothness can be ensured by using the 'PAUSE 0' command inbetween (supported by turbobasic). Then the new USR call will be executed one frame later. Speed depends on which x parameters you attach. It's possible to do STEP N in the X loop.

 

 

Perhaps decreasing players height?

It's up to the user, you can read in next post how to 'control' the routine.

 

 

Would it be possible to also move a fifth player or the 4 missiles?

Of course. See the new test files. However, only 5th player is supported. Dealing with 4 separate missiles would need new (somewhat more complex) code.

[analmux]

OK, final version is ready for download: http://www.phys.uu.nl/~bpos/PMTBB/pmtbb2.zip

 

For a demo: Boot the .atr and do L, TURBOBAS.SYS in the dos menu.

Under turbobasic, do RUN "D:INSTALL.BAT", and then RUN. The new demo has 2 multicolour players + a 5th player.

This installs the routine (at its default addresses) and then loads a demonstration program.

 

 

Now I should give an explanation of its usage.

 

The routine is relocatable to any page boundary. The INSTALL.BAT program deals with that.

The routine uses 6 zeropage registers, by default 203-208. This can be changed.

The routine, when just doing a BLOAD "D:MAIN.OBX", is loaded to page 128 & 129 by default.

384 bytes are needed for everything: routine and parameter space.

 

 

So, how to install the routine?

 

1) One should select a desired page in memory, where one needs to locate the routine and its registers, say page# A (default: A=128).

2) One should select a desired area of 6 bytes in the zeropage, say address# B (default: B=203)

3) Type LOAD "D:INSTALL.BAT" (or LOAD "D:INSTALL.TBB")

4) Insert choices for A in line 10 and for B in line 20

5) Type RUN

 

Now the PM routine is installed.

 

 

So, how to use the routine?

 

The registers of interest are at page A, thus, define PM=A*256

PM+0 --> PM+7 : start address shapedata [object 0-7] : low byte (only used by the ML routine itself)

PM+8 --> PM+15 : start address shapedata [object 0-7] : high byte (only used by the ML routine itself)

PM+16 --> PM+23 : start address PM base [object 0-7] : low byte (must be defined before usage)

PM+24 --> PM+31 : start address PM base [object 0-7] : high byte (must be defined before usage)

PM+32 --> PM+39 : length of each sprite shape [object 0-7] : (must be value from 1 to 128!...must be defined before usage)

PM+40 --> PM+47 : old y coordinate of each sprite [object 0-7] : (only used by the ML routine itself)

PM+48 --> PM+55 : new y coordinate of each sprite [object 0-7] : (only used by the ML routine itself)

PM+56 --> PM+63 : x coordinate of each PM [object 0-7] : shadow registers of GTIA 53248-53255 (used by ML routine, or used directly by user)

 

TRIGGER = PM+128 : Start address of the USR-call routine

INIT = TRIGGER+48 : Start address of the routine which activates the VBlank interrupt

 

It's best to clear all 128 bytes from PM to PM+127 at the start of your program, and BEFORE doing Q=USR(INIT) one should define the start addresses of the PM bases (PM+16 --> PM+31), and the lengths (PM+32 --> PM+39). Then do Q=USR(INIT). To clear the PMBase itself is up to the user.

 

Examples of defining the PM(n)-base addresses:

 

Fine resolution PM uses 256 bytes per P/M.

The PM-base starts at a 2kB boundary: say, f.e. at page 128. Then player 0,1,2,3 use page 132,133,134,135 and the missiles use page 131

These are (low/hi bytes): (0,132,0,133,0,134,0,135,0,133)

Write (0,0,0,0,0) to PM+16 --> PM+20

Write (132,133,134,135,133) to PM+24 --> PM+28

 

Coarse resolution PM uses 128 bytes per P/M.

The PM-base starts at a 1kB boundary: say, f.e. at page 132. Then player 0,1,2,3 start at (0,134),(128,134),(0,135),(128,135) and the missiles start at (128,133).

These are (low/hi bytes): (0,134,128,134,0,135,128,135,128,133)

Write (0,128,0,128,128) to PM+16 --> PM+20

Write (134,134,135,135,133) to PM+24 --> PM+28

 

Examples of defining the lengths of each PM:

Say, player 0 = 20 bytes, player 1 = 30 bytes, player 2,3 = 10 bytes. 5th player = 40 bytes

Then: (20,30,10,10,40) should be written to PM+32 --> PM+36

 

 

Usage of the USR-call:

 

Q=USR(TRIGGER,M,.....}

 

This should be used during your (TBB) program, whenever a (big) change is needed.

 

Here TRIGGER is the address of the 'trigger' code: this code communicates between (turbo)basic and the VBlank interrupt.

 

M is a mask, which points out which PMs need to change. There are 32 possibilities:

 

M = FP0 + 2 * FP1 + 4 * FP2 + 8 * FP3 + 16 * FP5

 

Here FP0,FP1,FP2,FP3,FP5 are 0 or 1: 0 if it doesn't need to be changed, or 1 if it needs to be changed.

If f.e. only player 1 and 3 need to change, then M = 2 + 8 = 10

 

The ..... are the parameters. The number of parameters is always a multiple of 3. The parameters are the new X coordinate (0-255), new Y coordinate (0-255), new Shape address (0-65535)

 

Some examples:

Q=USR(TRIGGER,0): Is just a void operation, shouldn't be used.

Q=USR(TRIGGER,1,X,Y,S): Relocates Player 0 at position X,Y with shape S.

Q=USR(TRIGGER,2,X,Y,S): Relocates Player 1 at position X,Y with shape S.

Q=USR(TRIGGER,4,X,Y,S): Relocates Player 2 at position X,Y with shape S.

Q=USR(TRIGGER,8,X,Y,S): Relocates Player 3 at position X,Y with shape S.

Q=USR(TRIGGER,16,X,Y,S): Relocates 5th player at position X,Y with shape S.

Q=USR(TRIGGER,3,X,Y,S0,X,Y,S1): Relocates PM0&1 at position X,Y with shape S0 for PM0, shape S1 for PM1.

Q=USR(TRIGGER,12,X,Y,S2,X,Y,S3): Relocates PM2&3 at position X,Y with shape S2 for PM2, shape S3 for PM3.

Q=USR(TRIGGER,31,X0,Y0,S0,X1,Y1,S1,X2,Y2,S2,X3,Y3,S3,X5,Y5,S5): Relocates all players + 5th player.

...

etc.

 

 

REMARKS:

 

1) The INSTALL.BAT program is intended to be executed before all your other stuff.

 

2) It's up to the user how to manage his shape data. These may be anywhere in memory. The USR-call will tell the VBlank interrupt how to deal with it, just by passing the address of the shape data.

 

3) The GTIA registers (53248-53255) are now overwritten by the VBlank interrupt. Now there are shadow registers, PM+56 --> PM+63.

These can also be used instead of the USR-call. When one only needs to reposition a player with same shape and y-coordinate, then just POKE to one of these.

 

4) To support double/quad width, one needs to set a number (2 = single width, 4 = double width, 8 = quad width) into a zeropage address. This value is needed for the correct positioning of the 5th player (DEFAULT: write 2,4 or 8 to address 208). If the PM routine is installed to a different zeropage addres B, then do POKE B+5,WIDTH (WIDTH=2,4 or 8 ).

 

5) The USR-call can be somewhat slower when changing more objects. F.e. M=31 will change all PM, and will be the slowest.

 

6) I'm not sure if I'll extend this routine to usage for 4 players + 4 missiles, only 5th player for now.

 

7) The registers offer space for 8 'objects', so when the 4 players + 5th player use 5 of them, there are still 3 left. When cleverly defining PM(n)-base for these 3, one can use one player to display multiple 'objects', displayed at different regions. This should however be used with great care, as the x-position won't have any effect. It's not a real multiplexer. For this to work one can add 32, 64 or 128 to M.

 

8 ) I included source, thus anyone may modify the routines to their desire (as long as it's not for commercial purposes ).

Edited September 10, 2009 by analmux

[+Philsan]

Thank you very much for the routine and for the long explanaition.

I will try to insert your routine in my educational game Cookie Monster to improve the movement of the character made of 3 players.

 

 

[peteym5]

Has someone considered having the players being updated during the VBI? That is how my multiplexers work and eliminates any flicker. It reads where to put the sprites from a table. You can have the USR routine just update a table containing source lo, source high, color, & length. A VBI routine is harder to relocate if you start getting into self modifying code, so you probably have to put it somewhere like page 6 or the top of memory if you do the poke 106,peek(106)-8:graphics 0 to reserve room for the player/missile graphics. You can put a routine + table right at PMBASE. Since thats wasting 768 bytes anyway.

Edited September 10, 2009 by peteym5

[+Philsan]

Ladies and gentlemen,

after 30 years we have the perfect multi-purpose PMG engine for Turbo-Basic XL (and Atari Basic).

I have tried many important routines (from magazines and books) but, as I have already written, they all have problems or limitations (flicker, players height, number, resolution, no multicolor, not compilable with TBXL).

I have tested Analmux's routine: I confirm that it works perfectly, it is easy to understand and it is also compilable.

I want to thank him publicly because he has written this routine for me and other Basic coders and not for himself (he doesn't need this routine for Super Mario Bros ).

Edited September 22, 2009 by Philsan

[analmux]

Here are the main files:

 

I removed the files from my ftp space. I temporarily put them there as on PC I couldn't attach the files to a post. On laptop I can attach them.

 

Have fun.

[w1k]

404 not found

[adam242]

Just came across this from a Google search... is this still available to download somewhere? I'd like to check it out...

 

Here are the main files:

 

I removed the files from my ftp space. I temporarily put them there as on PC I couldn't attach the files to a post. On laptop I can attach them.

 

Have fun.

[analmux]

Is this what you were looking for?...

[+Philsan]

I found that the original download link doesn't work.

 

If someone wants this awesome PMG machine language routine for Basic or Turbo-Basic XL I can send it.

 

BTW, I think this topic should be in the programming section.

[erichenneke]

Hi Philsan,

Could you please send the PMG ML routine for Turbo Basic XL?

 

Thank you so much.

 

You could email it to erichennekeATgmailDOTcom

 

thanks!!

[gobo]

Hi

 

Sorry to bump an old thread.

 

Can anyone tell me where I can download the pmtbb2.zip file or maybe share it with me if anyone still has it. The link above is dead.

 

Thanks

[+MrFish]

Here you go.

 

The text file is just a copy of his post about the final version.

 

Multipurpose PM Engine.atr

 

Multipurpose PM Engine.txt

 

[+Philsan]

Unfortunately Bernhard (analmux) passed away in 2016.

 

He removed the file from AtariAge but granted me the permission to give it to any person who wants it.

 

Not to betray the will of Bernhard but to remind forever the work he made for Atari community I attach original file.

 

Some flicker happens on NTSC machines, as the vblank period is much shorter.

pmtbb2.zip

[+MrFish]

Unfortunately Bernhard (analmux) passed away in 2016.

 

He removed the file from AtariAge but granted me the permission to give it to any person who wants it.

 

Not to betray the will of Bernhard but to remind forever the work he made for Atari community I attach original file.

 

I think it's OK to share them.

 

Thanks to Bernhard for creating the routine. It can be very helpful to some programmers.

 

I also posted with the greatest of respect towards him.

 

BTW, thanks for posting the original ZIP file. I think I just retained the ATR only, since the other files weren't needed to use the routine.

But, some may find at least the ASX file -- which is the source file for the machine language routine itself -- useful for understanding the

routine or possibly modifying it for their own use.

 

[Just a note for people downloading these files: the ATR I posted is the same as the ATR in the ZIP file posted by Philsan.]

 

 

Some flicker happens on NTSC machines, as the vblank period is much shorter.

 

Thanks for the info. I hadn't tried using the routine myself yet. So, I didn't realise it was that PAL-centric.

Edited January 19, 2019 by MrFish