Abstract Assembly Development Kit

[+Atarius Maximus]

Here is the latest version of the Abstract Assembly Development Kit with source and inline demo's to illustrate using the new enhancements, and an updated manual:

 

drawsprt2.asm

drawsprt2.bin

ASDK_Manual.pdf

 

The first sprite demo example is flipping through different sprite animations, the second is more complex where as you scroll around and draw on the playfield scrolling the playfield through the large virtual world, you are also able to scroll it through the moving sprite and draw on it too.

 

The sprite objects, the playfield and the large virtual world are all abstract objects that are x and y coordinate addressable and can be used for RAD development in Assembly in a very similar manner to bB. Sprite definitions are stored in intuitive WYSIWYG format like the large virtual worlds.

 

In the back of the manual there are also some ideas on directly integrating a flicker free version of the scrolling engines into the bB DPC+ kernel at higher resolutions.

Fantastic work! I'm looking forward to diving in to this more when I have a bit more time.

[Mr SQL]

Fantastic work! I'm looking forward to diving in to this more when I have a bit more time.

Thanks Atarius Maximus! I like your new game with the pitfall theme, great animation on the sprite

 

I got started on the tutorial last night using bB with the ASDK, I will post some of it soon!

[Mr SQL]

I've added a flicker-free mode to the ASDK that works like parttime 4WD

 

It takes advantage of double buffering to disengage the primary kernel whenever the playfield is not scrolling across the large virtual world.

 

This works out quite well because the flicker effect is far less noticeable when scrolling than when the playfield is static, and it gives a sense of motion when scrolling (you can still tell you're scrolling even if you're scrolling along continuous or uniform content).

 

Here's the source with slightly different demo's from my Assembly tutorial thread:

 

ASDK_pt4wd.asmASDK_PT4WD.bin

 

The scrolling still looks better on the real hardware than windows stella unless you enable phospor and get the OpenGL glide drivers.

 

Couple of minor changes - the game loop has been relocated and you don't need to call the "drawscreen" routines anymore, instead a toggle variable is set whenever the playfield scrolls across the virtual world.

 

Note the Assembly example that draws the playfield on the sprite is still placed between the two rendering engines. Also the gameloop has less time than before (still plenty) and an additional gameloop can be declared in the header if more time for game logic is needed.

[+Gemintronic]

I've been hoping for a flicker-free mode. Thanks again Mr SQL!

 

Stella thinks it goes over cycles when you constantly press the joystick to scroll. Hmmn..

[Mr SQL]

I've been hoping for a flicker-free mode. Thanks again Mr SQL!

 

Stella thinks it goes over cycles when you constantly press the joystick to scroll. Hmmn..

You're welcome Loon! I thought you would like that

 

Yes I'm not sure where that is comming from but fortunately it's only one scanline variance; the flicker version did that too and even stranger, depending upon where in the virtual world you stopped scrolling it would either say 262 solid or 262/263 fluctuating.

[Omegamatrix]

Mr SQL, You can stabilize your line count by changing some of the values you write into TIM64T:

 

Change this (in both places):

 

ldx #34 ; originally 35

stx TIM64T ;

 

And also change this:

 

ldx #254 ; originally 255

stx TIM64T ; big block of time now! Can put the kitchen sink here if you want

 

 

One of the reasons you were getting a scanline bounce is that your timer was running out towards the end of a scanline, and depending on when you entered the loop to check INTIM you could be doing a STA WSYNC beginning on cycle 74, which will skip the whole next line instead of just halting on the current one. I've had this happen to me many times, so that is the first thing I looked for.

 

 

Another way to fix this is to move your loading of TIM64T a few cycles earlier, and keep the value you load as 35. That would squeeze you a few more cycles, but in this case I think you don't need them.

[Mr SQL]

Mr SQL, You can stabilize your line count by changing some of the values you write into TIM64T:

 

Change this (in both places):

 

ldx #34 ; originally 35

stx TIM64T ;

 

And also change this:

 

ldx #254 ; originally 255

stx TIM64T ; big block of time now! Can put the kitchen sink here if you want

 

 

One of the reasons you were getting a scanline bounce is that your timer was running out towards the end of a scanline, and depending on when you entered the loop to check INTIM you could be doing a STA WSYNC beginning on cycle 74, which will skip the whole next line instead of just halting on the current one. I've had this happen to me many times, so that is the first thing I looked for.

 

 

Another way to fix this is to move your loading of TIM64T a few cycles earlier, and keep the value you load as 35. That would squeeze you a few more cycles, but in this case I think you don't need them.

Omegamatrix,

thanks I gave this a try and changed those three spots but still see it alternating between 262/263 whenever you scroll and then going back to 262 solid when not scrolling; did this fix make it 262 solid when scrolling on your version of Stella??

[Omegamatrix]

Omegamatrix,

thanks I gave this a try and changed those three spots but still see it alternating between 262/263 whenever you scroll and then going back to 262 solid when not scrolling; did this fix make it 262 solid when scrolling on your version of Stella??

Yes, it made it a solid 262 when scrolling. I've attached the rom and assembly file that I modified. I put the constants at the top of the file. I'm also using Sella 3.8 on my desktop. However, I think the scanlines should be consistent between different versions of Stella.

 

 

ASDK_pt4wd(mod).zip

[Mr SQL]

Yes, it made it a solid 262 when scrolling. I've attached the rom and assembly file that I modified. I put the constants at the top of the file. I'm also using Sella 3.8 on my desktop. However, I think the scanlines should be consistent between different versions of Stella.

 

 

ASDK_pt4wd(mod).zip

Awesome Omegamatrix! Thank you

 

I think you must have optimised for a few cycles somewhere or possibly started one of the timing blocks earlier - very curious as to where and trying to find it now - I spent lots of time trying to stabalise this at a solid 262 so that PAL 262 users would not lose colour.

 

I like the friendly names for the constants too!

 

TIME_OVERSCAN1 = 35-1 ; $D38A

TIME_OVERSCAN2 = 35-1 ; $DA0D

TIME_VBLANK1 = 43 ; $D2B1

TIME_VBLANK2 = 17 ; $D9D5

TIME_BIG = 255-1 ; $D9DF

[Omegamatrix]

I'm using the assembly file you added in post #28, if that helps.

 

 

I downloaded it again, and made the changes again to verify. It looks like that is all that is needed. Are you running Stella, or Z26? Here is the file. I get a rock solid 262, and I don't know why yours would be different unless we are using different files.

 

 

ASDK_pt4wd(new).zip

[Mr SQL]

I'm using the assembly file you added in post #28, if that helps.

 

 

I downloaded it again, and made the changes again to verify. It looks like that is all that is needed. Are you running Stella, or Z26? Here is the file. I get a rock solid 262, and I don't know why yours would be different unless we are using different files.

 

LOL! I didn't realise I had initialised the stack to 254 instead of the large timing loop

 

Thanks again Omegamatrix!

[Mr SQL]

Here is the latest version of the ASDK with the following updates:

 

asdk.asm

 

;----------------------------------------------------------

;-- Updates: ----

;-- 20130408 PT4WD: Primary Kernel can now be disengaged when not scrolling

;-- 20130409 Solid 262 scanline timing fix from Omegamatrix:

;-- Scanlines previously kept spiking to 263 when scrolling; see friendly name timing constants.

;-- 20130412 playfield pixel updates are now visible with or without the primary kernel

;-- 20130415 pixel setting routines optimised for better perf since they are heavier

;-- 20130415 rendering engines moved to bank1 to free up more room for game code here in bank 0.

;----------------------------------------------------------

 

I used this version for SCROLLOUT (the game version, not the demo):

 

http://atariage.com/...all-atari-2600/

[Mr SQL]

ASDK MANUAL.pdf

 

Here is the latest version of the ASDK eBook manual

 

Includes updates and details on utilising Flicker Free Mode with tie-in's to Chapter 7, Getting the Most out of the ASDK in the Assembly tutorial.

[Mr SQL]

New release of the ASDK!

 

More variables and more graphics and sound functions

 

Here is the updated Manual:

 

ASDK MANUAL.pdf

 

And here is the latest build with the Beta for the game Dodge It Panoramic Adventure included to help illustrate how to use the new functions:

 

ASDK_DodgeIt_PA.asm

 

The game is currently 2K and resides entirely in the Game Loop. Here is what the ROM memory map now looks like for the ASDK; there's a total of about 7.5K free for development out of 10.5K (3.5K per bank for three banks):

 

Many of these latest enhancements to the ASDK came about as a result of writing this game

 

Edited November 1, 2013 by Mr SQL

[+Gemintronic]

I'm not up on all your changes but I had a brain sliver: Instead of the extra memory you're using that makes cart production a little harder maybe look into SuperCharger support? That means homebrewers can make Starpath SuperCharger games and use cassette tapes again

[Mr SQL]

I'm not up on all your changes but I had a brain sliver: Instead of the extra memory you're using that makes cart production a little harder maybe look into SuperCharger support? That means homebrewers can make Starpath SuperCharger games and use cassette tapes again

Loon,

excellent idea! I've thought about making a SuperCharger version

 

There would only be 2.5K free for game code though; 3K if you pulled back some of the graphics and sound memory.

 

I wonder if the multiload functionality of the SC could be used to just reload part of the RAM to pull in additional virtual worlds and musical scores as they are needed in lieu of storing them in the game code.

[+Gemintronic]

I'm really ignorant when it comes to the Supercharger. I think it has 6k in 3 2k banks. Does that mean your framework code takes up about 4k? Not a complaint

[Mr SQL]

I'm really ignorant when it comes to the Supercharger. I think it has 6k in 3 2k banks. Does that mean your framework code takes up about 4k? Not a complaint

Loon,

excellent question! Does a SuperCharger version make sense? I think it does:

 

The Framework weighs in at just under 3K which leaves 7.5K free for the CBS format but only 3K free for the SuperCharger and that 3K includes the space for virtual worlds and musical scores.

 

Using the DodgeIt Beta as an example it's got 2K of game code, and uses one virtual world (240 bytes) and about 256 bytes worth of musical scores (a total of about 1/2 K for graphics and sound) so there would only be 1/2K left on the SuperCharger.

 

The remaining 512 bytes could be enough to finish it so it looks like a SuperCharger version of the Framework could be pretty interesting for building games. Wish the SC had just a little more RAM though!

 

But 3K free, even if you use 1/2K for graphics and sound, is a fairly large amount of memory for writing an Assembly game with a Framework (high level objects and a kernel).

[Mr SQL]

Detecting Collisions in the Virtual World

Binding Sprites to the GameGrid

The new graphic functions in the ASDK allow sprites to travel off the screen into the virtual world, and provide off screen collision detection.

 

This is a lot of fun to play with and you can readily see the effects in the Release Version of Dodge It Panoramic Adventure where multiple sprite based characters travel off screen and interact with the fixed and moving objects they encounter.

 

Off-screen virtual world interaction can add interesting game depth over "computer catch-up", limited algorithms or virtual worlds that remain static and frozen off screen!

 

Thoughts and ideas?

 

[+Gemintronic]

Forgive me if I seem like I'm pushing my own ideas: because I am

 

I think a static collision map is just fine. I think an additional list of changed map objects would enhance that. Say, the player can break a mud brick on the map. using his magic wand he breaks the mud brick and it remains so even after he has left the screen. This is due to a list in memory of objects and their location in the world. In this case the object list overrides the static world data that included the original mud brick.

[Mr SQL]

Forgive me if I seem like I'm pushing my own ideas: because I am

 

I think a static collision map is just fine. I think an additional list of changed map objects would enhance that. Say, the player can break a mud brick on the map. using his magic wand he breaks the mud brick and it remains so even after he has left the screen. This is due to a list in memory of objects and their location in the world. In this case the object list overrides the static world data that included the original mud brick.

No problem Loon, you have some great ideas!

 

Agree a dynamic object map is a great technique for rendering elements of a game world malleable; advantages of dynamic interaction and the ad-hoc offscreen collisions here stem from putting the world in RAM.

[+Gemintronic]

Maybe each enemy gets it's own 3x3 tile cached area that it interacts with regardless of distance to player. That coupled with the link list of changed map objects. Then the enemies could collide and even interact with objects close to it without having the whole map in memory.. right? (That's actually a question )

 

[##][ ][##]

[ ][][##]

[##][##][##]

[Mr SQL]

Maybe each enemy gets it's own 3x3 tile cached area that it interacts with regardless of distance to player. That coupled with the link list of changed map objects. Then the enemies could collide and even interact with objects close to it without having the whole map in memory.. right? (That's actually a question )

 

[##][ ][##]

[ ][][##]

[##][##][##]

If I understand correctly that tile cached area then automatically moves with the character since it is already positioned relative to the virtual world, kind of a character properties bag

 

If each character has it's own surrounding volatile area thats much less RAM than the whole map, but also requires more ROM for the algorithms which is not a bad tradeoff with only 128 bytes of RAM.

[Mr SQL]

The ASDK SuperCharger Edition is here!

 

Make games on Tape!

 

Tape games are 80's retro cool, 70's cool even. Most Atari gamers and collectors have a Starpath SuperCharger; if you don't have one you should get one too!

 

The Kroc and the Cuttle Cart have this fun analogue input capability built in as well and the next edition of the Harmony cart may sport this retro feature too (hint for Batari again ).

 

 

 

The StarPath SuperCharger Edition of the ASDK has been condensed and

feature packed to fit into the spare memory bank of the 6K SuperCharger! This

leaves nearly 4K available which is quite a lot of room for game development.

 

Feels like 32K of free RAM!

 

The SuperCharger Edition makes 4K of free memory feel roomy, more like 16k or

32k because of the high level Framework objects you are marshalling and the

space saving features of SuperCharger static RAM!

 

More info in the manual and the comments in the source:

 

The updated Manual, and the source code for the ASDK_SuperCharger demo is attached with a scrolling demo in the Game Loop.

 

Hope everyone enjoys! I'm busy making a SuperCharger game that feels bigger than 6K

 

 

ASDK_SuperCharger.asm

ASDK MANUAL.pdf

[Mr SQL]

Incoming. . .