Jump to content

Photo

Abstract Assembly Development Kit


50 replies to this topic

#1 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,944 posts

Posted Sun Sep 30, 2012 10:58 AM

tronbit2large.jpg

The Abstract Assembly Development kit

Is an Assembly Language Programming Framework for the Atari2600 that provides the equivelent of Hardware based horizontal scrolling and a screen buffer! It also abstracts and/or eliminates Racing The Beam (scanlines) and timing/cycle counting and flipping the portions of the screen backwards and forwards (large WYSIWYG bitmaps are supported) so the developer can focus just on the logic for their Assembly games and leverage high level calls to the phantom hardware.

This framework is an excellent resource for advanced bB developers to rapidly gain a working knowledge of Assembly language programming; you just have to start writing code to learn Assembly but it's daunting and near impossible to learn the chipset and concepts such as programming without a screen buffer let alone horizontal scrolling without hardware support (when I learned Assembly in the 80's I had these things all available in hardware, the 2600 is quite a unique beast!)

Anyone may use the kit however they wish (no strings attached), please enjoy!

Examples to try:

ScrollOut: Attached File  Scrollout2.bin   12KB   286 downloads

This has a demo and an unfinished breakout style game; the demo scrolls horizontally and diagonally a few times and then starts breaking out, pressing the fire button will scroll a "Eady Player One!" banner and then start the game; the camera initially follows the paddle but once you launch the ball it follows the ball, making it very difficult to hit the ball with the paddle when it scrolls diagonally/vertically and you have to find it - this game will be changed so that it only scrolls horizontally (no vertical/diagonal scrolling), so that it will be fun :)

ScrollDraw: Attached File  Scrolldraw.bin   12KB   266 downloads

This is the traditional "draw on the screen" demo only it scrolls and the camera follows the cursor, source code to show how simple this assembly program is follows!

Sample Code from ScrollDraw:

Here is a short simple Assembly example from ScrollDraw.bin, drawing on a large scrolling virtual world; try the demo's and take a look at the code and let's discuss it! I'll be posting the source for the framework shortly, it already works with the version of DASM that comes with bB so you have everything you need:

; ---------------------------------------------------------
; ------ Your Assembly code goes here:

;----------------------------------------------------------
;-----SCROLL Draw:
;-----Simple Demo for the Abstract Assembly Development Kit
; Hold the Button Down to Draw or Erase
;-------------------------------------------------------

; bity, bitx - x and y vars for the large virtual world
; BITindex, x value for horizontaly scrolling anywhere in the large virtual world
; BYTErowoffset, calculated from YIndex for vertical scrolling (hardware support already exists)

; moved joystick? Then Move the Draw Cursor
lda #$10 ; #16 or %00001111
bit SWCHA ; like AND but we drop the result in the bit bucket behind the CPU
bne skipup
lda bity
beq skipup ; don't decrement bitx further if it is at zero
dec bity
skipup

lda #$20 ; 26 or 00011010
bit SWCHA
bne skipdown
lda bity
cmp #19
beq skipdown ; don't increment it past 19
inc bity
skipdown

bit SWCHA
BVS skipleft
lda bitx
beq skipleft ; don't decrement the x position value past zero
dec bitx
skipleft

bit SWCHA
BMI skipright
lda bitx
cmp #96
beq skipright ; virtual world is 96 pixels wide
inc bitx
skipright
; ---------------End Drawing Routine

;-----------------------------------
;Follow the Cursor with the Camera:

; Camera X Axis: -----------
lda bitx
cmp #10
bcs followXaxis ; >=10
lda #0
sta BITIndex ; (X position for camera is 0 - nothing to scroll to yet)
jmp donefollowXaxis
followXaxis
sec ; set carry for subtracts, clear it for additions
sbc #10

cmp #72
bcc dontadjustxaxis ; <72
lda #72 ; adjust x axis so code to the right of the virtual world is not shown on screen
dontadjustxaxis

sta BITIndex
donefollowXaxis

; Camera Y Axis: -----------
lda bity
cmp #6
bcs followYaxis ; if >=6
lda #0 ; keep Y pos for virtual world at the top for the top 6 pixels
sta YIndex ; superfluous
jmp offsetdone


followYaxis
lda bity
sec ;set carry for subtracts, clear for additions
sbc #6
sta YIndex
donefollowYaxis

cmp #10
bcc dontadjust ; <10
lda #10
sta YIndex ; don't show the code below the virtual world; this sets the bottom border
dontadjust

; Now turn Y Index into a Row Offset for the bitmap (it's 12 bytes across)
lda #0
ldy YIndex
offsetcalc sec ; set carry before additions
clc
adc #12
dey
beq offsetdone
jmp offsetcalc
offsetdone
sta BYTErowoffset

;-----------------------------------------------------
;----- Done Following the draw cursor with the camera

;--- Turn on the target bit in the virtual world:
lda #1 ; argument to turn pixel on always
jsr getbitstatus ; call subroutine, passing argument
;---- Done Turning on the target bit

;---------Erase the target bit under the cursor?
;--- if button is pressed, erase it:
bit INPT4
bmi skiperase
lda #0 ; argument to invert bit, since it was just set it will be turned off
jsr getbitstatus ; call subroutine, passing argument
skiperase
; note: The getbitstatus subroutine can get, set, invert or clear a bit
;-----------------

;-- Now Call the Twin Engines that emulate hardware level
;-- Horizontal Scrolling and Scaling
;----------------------------------------slide view window along bitmapped panorama currently loaded into CBS RAM:

jsr pushabstractextendedplayfield
;--------- expand and flip 30 bytes of system RAM buffer into 60 Bytes for display:
jsr AbstractPlayfieldBuilder
;-------------------------------------------

;----------End Scrolling Draw Demo

; ---- Resume Framework...

#2 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Sun Sep 30, 2012 1:18 PM

Thanks for this! Very interesting! :thumbsup:

Scrolldraw.bin_1.png Scrollout2.bin_1.png

I am not an advanced bB developer yet, but I can imagine a lot of possiblities with this.

So if I understand correctly, the Abstract Assembly Development Kit (AADK) is combined with your asm code before you create a binary file using DASM? (i.e. you write batariBasic code with assembly routines mixed, in, compile it all into an asm file, then apply the AADK to it?)

I'm just confused about the order the process will be.

Note: I used Alt-P in Stella for the phosophor effect because otherwise the picture is an empty black screen.

#3 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Sun Sep 30, 2012 6:42 PM

Thanks for this! Very interesting! :thumbsup:

Scrolldraw.bin_1.png Scrollout2.bin_1.png

I am not an advanced bB developer yet, but I can imagine a lot of possiblities with this.

So if I understand correctly, the Abstract Assembly Development Kit (AADK) is combined with your asm code before you create a binary file using DASM? (i.e. you write batariBasic code with assembly routines mixed, in, compile it all into an asm file, then apply the AADK to it?)

I'm just confused about the order the process will be.

Note: I used Alt-P in Stella for the phosophor effect because otherwise the picture is an empty black screen.


You're welcome Gateway, great screenshots!

The scrolldraw.asm example, or any Assembly program you build with the AADK (nice acronym) just gets dropped right into the Framework file (it's all one Assembly file) right between:

; ---------------------------------------------------------
; ------ Your Assembly code goes here:

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

and

; ---- Resume Framework...

I'm writing the manual right now and will post it soon and the AADK source with the ScrollDraw.asm example inline.

btw, I think you just imagined an interesting possiblity I hadn't thought of:

You could probably use bB to write your game loop and game logic - and then paste the resultant assembly code it generates (just for your loops and logic, no part of the bB framework code would work) into the AADK; the AADK even offers the variables a-j which you could use directly in your program with no changes (Pretty cool idea, I will add it to the manual!). You would still have to edit your bB Assembly output to hook up the abstract calls for the phantom hardware but the api's are very straight forward/high level and editing the large virtual world bitmaps is very similar to the playfield screens in bB - all WYSIWYG, same for the musical score table.

#4 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Mon Oct 1, 2012 1:27 PM

Here is the ASDK Manual and the full Framework source code with the inline example ScrollDraw :)

Attached File  ASDKManual.pdf   155.79KB   268 downloadsAttached File  ScrollDraw.asm   65.28KB   200 downloads

#5 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Mon Oct 1, 2012 7:39 PM

Thanks for the manual, etc. I will try to give you some feedback in a few days after I play around with it in my free time. 8)

#6 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,029 posts

Posted Wed Oct 3, 2012 8:06 AM

pushabstractextendedplayfield and AbstractPlayfieldBuilder are the equivalent of DrawScreen in bB


If these are one to one equivalents then why the different function names? Couldn't there be one, say, "aa_drawscreen" routine?

I'm using the newb mentality when posing these questions. Obviously. :)

#7 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Wed Oct 3, 2012 9:28 AM

If these are one to one equivalents then why the different function names? Couldn't there be one, say, "aa_drawscreen" routine?

I'm using the newb mentality when posing these questions. Obviously. :)

loon,
excellent question! You could wrap them with an aa_drawscreen function that calls them both in order, agree that would be even more abstract. But I've left them as two seperate functions because one of the engines could potentially be used independantly, depending upon the kind of game you are building:

pushabstractextendedplayfield pans a 20x10 pixel playfield out of your 92x20 pixel virtual world and maps it to 30 of the 60 bytes of the 2600's RAM set aside for screen memory, still storing it in WYSIWYG format.

AbstractPlayfieldBuilder takes no arguments and simply upsizes the 30 bytes to 60 bytes, doubling the size of the pixels and also flipping them to and fro to suit the 2600's unique playfield architecture; for building games that don't scroll it is possible to load the bottom 30 bytes of reserved screen memory with a WYSIWYG 20x10 bitmap (from any 3 byte wide x 10 row table) and just call this routine to upsize and flip the bits around.

#8 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Wed Oct 3, 2012 9:29 AM

Thanks for the manual, etc. I will try to give you some feedback in a few days after I play around with it in my free time. 8)

Fantastic Gateway! I'm looking forward to hearing about your experience :)

#9 Gateway OFFLINE  

Gateway

    River Patroller

  • 2,165 posts
  • Trotter Atari Globetrotter now on Facebook!
  • Location:St. Joseph area, Missouri

Posted Tue Oct 16, 2012 6:39 PM

Okay, so am I trying to compile your scrolldraw.asm example into a bin file (I changed the colors for the playfield as a test). It wants vcs.h and macro.h.

So I found a vcs.h file that seems to work and I found a macro.h file, however it just shows a blank screen in Stella.

Are you using an updated macro file? The macro file I have here came with DASM I believe, that was included with batariBasic.

If you have a newer macro.h file you are using, let me know where I can access it. Thanks. :)

EDIT: To clarify, I am using your scrolldraw.asm file that includes the whole framework and the only thing I changed was the color early in the framework file (I haven't changed anything yet in the scrolldraw game file itself)

Edited by Gateway, Tue Oct 16, 2012 6:43 PM.


#10 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Tue Oct 16, 2012 8:50 PM

Gateway,
no Macro's are actually used, I just included the reference in case anyone wants to use them (you could actually comment it out or remove the reference just in case there is something wrong with your macro.h file).

You mentioned you had to turn on phosphor before with alt-p or the screen was blank; that is interesting, I'm curious what version of Stella you are using?

Also, installing the open GL drivers for windows improves the look making it considerably closer to the real hardware with smoother scrolling (no pixels breaking rank).

#11 Tjoppen OFFLINE  

Tjoppen

    Chopper Commander

  • 215 posts

Posted Thu Oct 18, 2012 3:13 AM

You should store the data transposed in RAM, so you can access each column of playfield with the same Y value.

I did a little analysis of your kernel:

	 LDY $8E
LF29C: STX COLUPF
	 LDA $00A0,Y ;why
	 STA PF0
	 INY	 ;are
	 LDA $00A0,Y ;you
	 STA PF1
	 INY	 ;wasting
	 LDA $00A0,Y ;cycles
	 STA PF2
	 INY ;on
	 LDA $00A0,Y ;these
	 STA PF0
	 INY ;instructions
	 LDA $00A0,Y ;you
	 STA PF1
	 INY ;could
	 LDA $00A0,Y ;probably
	 STA PF2
	 INY ;fit this in one scanline
	 INX
	 STA WSYNC ;why?
	 LDA #$00
	 STA PF0
	 STA PF1
	 STA PF2
	 DEC $8F
	 BEQ LF2D9
	 TYA ;this would be completely unnecessary
	 SEC
	 SBC #$06
	 TAY
	 JMP LF2DE
LF2D9: LDA #$0A
	 STA $8F
	 NOP ;wut
	 STA WSYNC
	 CPX #$C0
	 BNE LF29C

Instead you should do something like:
    ldy #YRES-1
LoopY
    ldx #10	 ;stretch factor
LoopX
   sta WSYNC
   lda PF0DataL,Y
   sta PF0
   lda PF1DataL,Y
   sta PF1
   lda PF2DataL,Y
   sta PF2

   ;do useful things, like set COLUPF

   lda PF0DataR,Y
   sta PF0
   lda PF1DataR,Y
   sta PF1
   lda PF2DataR,Y
   sta PF2

   ;20-25-ish cycles to spare here
   dex
   bne LoopX
   dey
   bpl LoopY
Something like the above should fit in one scanline.

edit: OK, these forums could stand to suck less. DON'T REFORMAT MY CODE DAMNIT!

Edited by Tjoppen, Thu Oct 18, 2012 3:23 AM.


#12 Tjoppen OFFLINE  

Tjoppen

    Chopper Commander

  • 215 posts

Posted Thu Oct 18, 2012 3:25 AM

I pastebin'd the bastard instead: http://pastebin.com/yLGwc623

Edited by Tjoppen, Thu Oct 18, 2012 3:27 AM.


#13 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Fri Oct 19, 2012 9:25 AM

You should store the data transposed in RAM, so you can access each column of playfield with the same Y value.

Tjoppen,
yes this is an excellent idea (and I like your code comments!) but it would require either modifications of the rendering engines or more RAM to play with.

Via Modication of the Engines:

The engine that pulls a 20x10 pixel screen from the panoramic 96x20 pixel WYSIWG bitmap (which is fully malleable and stored in 240 bytes of CBS RAM) deposits it in the bottom 30 bytes of the 60 bytes of the Atari's RAM reserved as a screen buffer.

The upsizer engine then expands that bottom 30 bytes into the full 60 bytes creating phatter pixels (and flipping it so it is no longer WYSIWIG but ready for rendering).

If I remove the latter engine I could have the first one perform both functions and so render it as six tables, reading with the same Y value via the optimised code you have shown, I may do something like this so I don't have to use an entire frame for the engines but I like having both of them because the latter engine can also be used independently depending upon the game design (scrolling or non-scrolling).

Via more RAM:

Without modifying the engines I would need an additional 30 bytes of RAM and I'm already only leaving 78 for the stack and variables; here's why:

Transposition.jpg

I usually sketch something on paper to explore an idea; as you can see from the illustrations, transposing the bottom half of the screen buffer (30 of 60 bytes) to six tables in 60 bytes breaks the same memory space (I haven't illustrated that the images on the right are not WYSIWYG) while contiguous transposition does not.

#14 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,029 posts

Posted Fri Oct 19, 2012 9:54 AM

Can there be a no flicker mode? I'd be willing to sacrifice resolution for a stable picture.

Also, the idea of using this as a new screen drawing kernel in bB has obvious appeal to me. It also seems to defeat some of Mr. SQLs intentions with this :) I feel selfish even endorsing the idea :P

#15 Tjoppen OFFLINE  

Tjoppen

    Chopper Commander

  • 215 posts

Posted Mon Oct 22, 2012 3:15 AM

The engine that pulls a 20x10 pixel screen from the panoramic 96x20 pixel WYSIWG bitmap (which is fully malleable and stored in 240 bytes of CBS RAM) deposits it in the bottom 30 bytes of the 60 bytes of the Atari's RAM reserved as a screen buffer.

The upsizer engine then expands that bottom 30 bytes into the full 60 bytes creating phatter pixels (and flipping it so it is no longer WYSIWIG but ready for rendering).

Do the upscaling inside the kernel. There should be enough time to process one byte per scanline, so you compute the next block line while the current one is being drawn (6+6 byte buffer). Then you only need to shift and copy 30 bytes during VBLANK. Ah, and always keep the data flipped IMO - it just means that Y runs up instead of down.

#16 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Fri Nov 9, 2012 8:30 AM

Can there be a no flicker mode? I'd be willing to sacrifice resolution for a stable picture.

Also, the idea of using this as a new screen drawing kernel in bB has obvious appeal to me. It also seems to defeat some of Mr. SQLs intentions with this :) I feel selfish even endorsing the idea :P

LOL loon! Fine to use bB to build your game logic if you prefer, IMO bB is not too different beyond semantics. I sure wish DASM supported a concatenation character so I could code horizontally in asm too (linefeed almost works but it reverts to CR+LF after I save the file).

A no flicker mode may happen sometime in the future, it would "DVD" the picture down to a strip to get the cycles though and I really like using the full screen :)

Edited by Mr SQL, Fri Nov 9, 2012 8:30 AM.


#17 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Fri Nov 9, 2012 8:32 AM

Do the upscaling inside the kernel. There should be enough time to process one byte per scanline, so you compute the next block line while the current one is being drawn (6+6 byte buffer). Then you only need to shift and copy 30 bytes during VBLANK. Ah, and always keep the data flipped IMO - it just means that Y runs up instead of down.

Tjoppen,
upscaling in the kernel would have to entail processing 3 bytes (into 6) per scanline; don't think there is enough time. If I create a non flicker mode I would probably drop the upsizing engine and have the panning engine do that job as well - creating six tables wouldn't be an issue since then there would be no RAM buffer overwrite.

I am working on adding phat pixel sprites next :)

#18 Tjoppen OFFLINE  

Tjoppen

    Chopper Commander

  • 215 posts

Posted Sat Nov 10, 2012 11:13 AM

Tjoppen,
upscaling in the kernel would have to entail processing 3 bytes (into 6) per scanline

No, it entails processing 3 -> 6 bytes in ten scanlines (or however many times the lines are duplicated)...

#19 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Sun Nov 11, 2012 12:38 PM

No, it entails processing 3 -> 6 bytes in ten scanlines (or however many times the lines are duplicated)...

Tjoppen you're right :) There are plenty of free cycles in the physical block of scanlines for each row of phat pixels to expand three bytes into six for the next row.

#20 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Tue Mar 26, 2013 10:58 AM

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:

Attached File  drawsprt2.asm   77.42KB   110 downloads
Attached File  drawsprt2.bin   12KB   182 downloads
Attached File  ASDK_Manual.pdf   278.9KB   156 downloads

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.

#21 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,029 posts

Posted Tue Mar 26, 2013 11:33 AM

I'm entirely missing the point here, but I hope your project swings in one of two directions:

Something like the NESHLA
http://neshla.sourceforge.net/

Or a replacement kernel for bB :)

I'd definitely settle for a tutorial on how to migrate bB output into the user code section of ASDK.

I'm actually less interested in what you can pull off with support hardware like DPC+ and what more you can pull off with classic constraints.

Thanks again for continuing this project and the excellent documentation and comments in the code!

#22 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Tue Mar 26, 2013 11:55 AM

loon,
NESHLA looks really cool, the ASDK is more simplified but definitely along those lines :)

That's a great idea! I was planning to start a tutorial on learning Assembly fast with the ASDK and will include examples of how to migrate bB Assembly output into the user code section of the ASDK as well as the similarites in how both frameworks abstract the hardware; Assembly can be nearly as RAD as bB with the abstract calls.

#23 Cybearg OFFLINE  

Cybearg

    Dragonstomper

  • 950 posts

Posted Tue Mar 26, 2013 12:01 PM

I would love that. I was planning to move on to another system because I just find Assembly on the 2600 too exhausting with all the cycle-counting and such, but if it can be made simpler or more abstract, I'd love to learn to use it and keep on at least for a while longer!

#24 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • Topic Starter
  • 1,944 posts

Posted Tue Mar 26, 2013 1:22 PM

I would love that. I was planning to move on to another system because I just find Assembly on the 2600 too exhausting with all the cycle-counting and such, but if it can be made simpler or more abstract, I'd love to learn to use it and keep on at least for a while longer!


Awesome Cybearg! Programming Assembly on the 2600 with the ASDK should feel more like that.

This will be fun, I'll get that thread started soon! :)

#25 Atarius Maximus OFFLINE  

Atarius Maximus

    Stargunner

  • 1,880 posts
  • 10 PRINT CHR$(205.5+RND(1));
  • Location:St. Louis, Missouri USA

Posted Tue Mar 26, 2013 5:10 PM

I would love that. I was planning to move on to another system because I just find Assembly on the 2600 too exhausting with all the cycle-counting and such, but if it can be made simpler or more abstract, I'd love to learn to use it and keep on at least for a while longer!

Hang in there! I'm really impressed with your demos and your creative talent is very impressive. I hope you stick around, I'd love to see your future projects. :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users