Jentzsch/Davie '2600 tile/character graphics engine

[+Andrew Davie]

I buried a release of the tile engine, that Thomas and I wrote from 2003-2011, in the Sokoban forum. I am re-posting the source code here, so that I have a logical place to explain how it all works, how to use it, and answer any questions. Basically, this is a generic character-graphics display for the '2600 using characters 4 PF pixels wide x 21 scanlines in height, with each group of 3 scanlines being a triad of colours and the pixel on/off status in each scanline forming one of 8 'colours' given that colour triad being used in combinations. It's a tad more complex that that, but that's the gist of it.

The tile engine was used to develop Boulder Dash(TM). Thomas and I retained copyright on the engine itself, with a view to eventually releasing it. Well, here it is. If you have any questions about how it works, here is the place to ask.

The engine uses the $3E bankswitching scheme.

sokoboo_SOURCE_CODE_20190728.zip

[+Andrew Davie]

The first thing to say is that this is a character graphics engine.

That means that there is a character set, referenced by character numbers and there is a board which is an MxN array of character numbers. The board is configurable in code, but for this example it is set to 40 characters wide x 22 characters deep. The tile engine displays a 10 x 8 'window' into this board, and by moving the origin of this window you effectively get scrolling of what is seen on the screen.  The system is completely automatic, in that all the programmer needs to do is to write characters into the board, and they will appear in the right place on the screen.

 

For historical reasons, the code uses a quite limiting bank-switching scheme (3E)
 

To keep everything running as far as displaying a screen goes, all of the necessary logic required to automate the tile engine display is broken into small processes that can be run during the available idle times on a standard '2600 display. Vertical blank, etc. The system maintains a complex array of stacks and buffers to enable this subdivision into small tasks to be achieved.

[+Andrew Davie]

Here's the basic operation of the system.


First, there is a 10x8 array which holds the character number for each character on the 10x8 screen, as currently displayed.

This is 'ScreenBuffer'. This not only holds the character number, but also has embedded "hints" for the draw system to speed up drawing. That's getting deep into the system, but basically if two adjacent characters occupy the same byte, and there is a character definition for both of them, then the system avoids masking anding and oring and just does a 'direct draw' for that character. Complex, so let's move on....
So, once per game-frame, the system compares the contents of ScreenBuffer with the contents of the board at the same position. So, if the screen was positioned at 10,2 in the board, then the ScreenBuffer should have the same contents as the board in the 10x8 area located at 10x2 in the board. There are 80 characters in the ScreenBuffer. All 80 of these are compared with all 80 characters in the board. If they are the same - nothing to do - we know that the characters displayed on the screen are the same as the characters on the board.

BUT... if the board has changed (for example, you have put something different in the board memory - more specifically, a different character number than was there last time)... then this will be picked up by the scan/compare of ScreenBuffer and the underlying board area. We will have information saying, basically... ScreenBuffer[x,y] has changed to character Z. So, this information is pushed onto a 'Draw stack', which is a LIFO array indicating X,y position (on the visible screen) and character number that should be there. This character has to be drawn into the screen ram to reflect the new shape data there.

Now, there are many ways of drawing a 'character'. But what is 'drawing'?  It's the process of physically copying/masking the 21 scanlines of character 'shape' into the RAM representing the bitmap for the screen. There are different types of draw based on whatever optimisations we could find. For example, if two adjacent characters are the same, then we can avoid masking and do a 'directDraw' which is super quick. Or if the character is blank, then we don't need to "OR" in new data, we can just zap the old data so it's zeroes. We do things as efficiently as we can, and that's one of the reasons for the hint mentioned earlier in the ScreenBuffer.

 

Each one of these different types of 'character drawing' takes a known amount of CPU cycles. Because we counted them. Very carefully. So before any character data copy happens, we first determine if there is sufficient available time in the 'time slot' to do the work that is required. If there isn't, then we simply don't do it. Next time slot that comes along, same thing... is there sufficient time?  Eventually we get a time slot which DOES have sufficient time, and we do the draw. And continue.  Eventually the 'draw stack' is emptied, at which point we have now copied the character shapes for all of the characters on the visible screen that have changed... into the RAM representing the screen bitmap.

 

This copy process is called "StealCharDraw", and again - it copies a character # and position from the draw stack (which holds all of the changed characters on the screen), and copies the character shape data for that character number into the screen bitmap at the correct position.

That's about it. There's a lot of timing issues and complications, but that is the fundamentals of the operation. To repeat - a board, a ScreenBuffer, a DrawStack, and StealCharDraw to do the bitmap copying. Next I'll talk about the character set and character data format. It's very limiting!

 

[+Karl G]

Thanks for making this available!

 

I understand that you can't do another release of the game itself due to the agreement you negotiated, but I was wondering if you have ever considered using your engine for a similar game with a different name that wouldn't have these restrictions?

[+Andrew Davie]

8 minutes ago, Karl G said:

Thanks for making this available!

 

I understand that you can't do another release of the game itself due to the agreement you negotiated, but I was wondering if you have ever considered using your engine for a similar game with a different name that wouldn't have these restrictions?

I am using it right now for the Sokoban I am developing.

As to similar BD-like games - I am not interested in circumventing not only a legal, but a gentlemens' agreement that I had with FSS.
Having said that, we are working in the background to see what we can do to make BD accessible to the masses.

[+Gemintronic]

For those in the Windows 10 camp here is (what I interpreted as) the equivalent of Makefile

It assumes you have dasm and stella in your PATH.  It also assumes you are running this batch file from where the Makefile for this project resides.

 

taskkill /F /IM "stella.exe" /T 
dasm ./sokoboo.asm -l./sokoboo.txt -f3 -s./sokoboo.sym -o./sokoboo.bin
echo y| cacls ./sokoboo.bin /g everyone:f 
start stella ./sokoboo.bin

 

[Mr SQL]

On 7/30/2019 at 7:01 AM, Andrew Davie said:

Here's the basic operation of the system.


First, there is a 10x8 array which holds the character number for each character on the 10x8 screen, as currently displayed.

This is 'ScreenBuffer'. This not only holds the character number, but also has embedded "hints" for the draw system to speed up drawing. That's getting deep into the system, but basically if two adjacent characters occupy the same byte, and there is a character definition for both of them, then the system avoids masking anding and oring and just does a 'direct draw' for that character. Complex, so let's move on....
So, once per game-frame, the system compares the contents of ScreenBuffer with the contents of the board at the same position. So, if the screen was positioned at 10,2 in the board, then the ScreenBuffer should have the same contents as the board in the 10x8 area located at 10x2 in the board. There are 80 characters in the ScreenBuffer. All 80 of these are compared with all 80 characters in the board. If they are the same - nothing to do - we know that the characters displayed on the screen are the same as the characters on the board.

BUT... if the board has changed (for example, you have put something different in the board memory - more specifically, a different character number than was there last time)... then this will be picked up by the scan/compare of ScreenBuffer and the underlying board area. We will have information saying, basically... ScreenBuffer[x,y] has changed to character Z. So, this information is pushed onto a 'Draw stack', which is a LIFO array indicating X,y position (on the visible screen) and character number that should be there. This character has to be drawn into the screen ram to reflect the new shape data there.

Now, there are many ways of drawing a 'character'. But what is 'drawing'?  It's the process of physically copying/masking the 21 scanlines of character 'shape' into the RAM representing the bitmap for the screen. There are different types of draw based on whatever optimisations we could find. For example, if two adjacent characters are the same, then we can avoid masking and do a 'directDraw' which is super quick. Or if the character is blank, then we don't need to "OR" in new data, we can just zap the old data so it's zeroes. We do things as efficiently as we can, and that's one of the reasons for the hint mentioned earlier in the ScreenBuffer.

 

Each one of these different types of 'character drawing' takes a known amount of CPU cycles. Because we counted them. Very carefully. So before any character data copy happens, we first determine if there is sufficient available time in the 'time slot' to do the work that is required. If there isn't, then we simply don't do it. Next time slot that comes along, same thing... is there sufficient time?  Eventually we get a time slot which DOES have sufficient time, and we do the draw. And continue.  Eventually the 'draw stack' is emptied, at which point we have now copied the character shapes for all of the characters on the visible screen that have changed... into the RAM representing the screen bitmap.

 

This copy process is called "StealCharDraw", and again - it copies a character # and position from the draw stack (which holds all of the changed characters on the screen), and copies the character shape data for that character number into the screen bitmap at the correct position.

That's about it. There's a lot of timing issues and complications, but that is the fundamentals of the operation. To repeat - a board, a ScreenBuffer, a DrawStack, and StealCharDraw to do the bitmap copying. Next I'll talk about the character set and character data format. It's very limiting!

 

Awesome tile engine, very cool you've released it!

 

Some ideas to consider for sharing this with BASIC programmers:

 

Add new commands for the engine and the graphics objects to batari BASIC, or create a BASIC game maker kit for the engine.

 

Tracker - Sokoban looks awesome and the Aussie soundtrack linked on the thread sounds great - maybe the music player for Sokoban could be wrapped as a sequencer.

Platform adaptation ideas for the engine:

 

Larger grid tile games have adaption challenges to fit the scrolling action in the 10x8 camera view where it can be hard to see what's about to happen to the characters.
It will be interesting to see what variety of platform adaptation techniques programmers will apply.
 
Equally interesting, some tile games that were not initially scrolling games could become very fun scrolling games with this engine; imagine a Dig-Dug or Pengo clone scrolling to see the whole arcade screen, we could see some pretty cool effects with the right adaptation techniques!

 

[Dionoid]

This is great stuff, Andrew!

 

With the Windows version of dasm, I could not get it to compile. Is returns errors:

BANK_INITBANK.asm (44): error: Unknown Mnemonic '+'.
BANK_INITBANK.asm (52): error: EQU: Value mismatch.

It looks like the board calculation dasm code (lines 779-791 in sokoboo.asm and lines 42-52 in BANK_INITBANK.asm) is clashing somewhere.

 

Anyway, the code looks very interesting; I just started digging into it.

It seems that each character has an R, G and B component, but on the screen the colors of the PF lines look more like Red, Yellow and Blue. Is that correct?

Edited August 3, 2019 by Dionoid

[+Andrew Davie]

6 hours ago, Dionoid said:

This is great stuff, Andrew!

 

With the Windows version of dasm, I could not get it to compile. Is returns errors:

BANK_INITBANK.asm (44): error: Unknown Mnemonic '+'.
BANK_INITBANK.asm (52): error: EQU: Value mismatch.

It looks like the board calculation dasm code (lines 779-791 in sokoboo.asm and lines 42-52 in BANK_INITBANK.asm) is clashing somewhere.

 

Anyway, the code looks very interesting; I just started digging into it.

It seems that each character has an R, G and B component, but on the screen the colors of the PF lines look more like Red, Yellow and Blue. Is that correct?

 

It should compile. I can post a more up-to-date version of Sokoban later today, which is a bit cleaner and with improvements.

Could be your version of DASM is having some issues, so I'd be trying the latest version too.

The characters do indeed have three lines/components (they are 21 pixels deep, consisting of 7 "RGB" pixels, each pixel being 3 scanlines high).

However, those 3 colours (RGB) can actually be ANY three colours - so you will see these varying from screen to screen as required.

This 3-colour triplet has been referred to by me in the past as "Interleaved Chronocolour(TM)"

 

Edited August 4, 2019 by Andrew Davie

[+Andrew Davie]

7 hours ago, Dionoid said:

This is great stuff, Andrew!

 

With the Windows version of dasm, I could not get it to compile. Is returns errors:

BANK_INITBANK.asm (44): error: Unknown Mnemonic '+'.
BANK_INITBANK.asm (52): error: EQU: Value mismatch.

It looks like the board calculation dasm code (lines 779-791 in sokoboo.asm and lines 42-52 in BANK_INITBANK.asm) is clashing somewhere.

 

Anyway, the code looks very interesting; I just started digging into it.

It seems that each character has an R, G and B component, but on the screen the colors of the PF lines look more like Red, Yellow and Blue. Is that correct?

 

I had a further look into this issue. I was surprised to see the calculations in BOTH INITBANK and sokoboo.asm

I have tried removing lines 779-791 of sokoboo.asm and it compiles and runs OK in my current source, so next version will have that change.

 

[Dionoid]

17 hours ago, Andrew Davie said:

 

I had a further look into this issue. I was surprised to see the calculations in BOTH INITBANK and sokoboo.asm

I have tried removing lines 779-791 of sokoboo.asm and it compiles and runs OK in my current source, so next version will have that change.

 

Unfortunately I still cannot get it to compile on dasm for Windows (version 2.20.11-2014.03.04)

It looks like label 'Board' is never initialized; if I wildcard search for that label, it is never set, but only used in lines like this:

.BOARD_LOCATION SET Board

 

[+Andrew Davie]

Strange. Here is the very latest "Sokoboo" source code, which definitely builds and runs for me.

If you're on MacOS you can just type "make" from the build directory for a full build/run. Otherwise, look at the Makefile for the dasm call.

 

Sokoboo_SOURCE_20190804.zip

[+Gemintronic]

On 8/3/2019 at 12:48 PM, Mr SQL said:

Awesome tile engine, very cool you've released it!

 

Some ideas to consider for sharing this with BASIC programmers:

 

Add new commands for the engine and the graphics objects to batari BASIC, or create a BASIC game maker kit for the engine.

 

Tracker - Sokoban looks awesome and the Aussie soundtrack linked on the thread sounds great - maybe the music player for Sokoban could be wrapped as a sequencer.

Platform adaptation ideas for the engine:

 

Larger grid tile games have adaption challenges to fit the scrolling action in the 10x8 camera view where it can be hard to see what's about to happen to the characters.
It will be interesting to see what variety of platform adaptation techniques programmers will apply.
 
Equally interesting, some tile games that were not initially scrolling games could become very fun scrolling games with this engine; imagine a Dig-Dug or Pengo clone scrolling to see the whole arcade screen, we could see some pretty cool effects with the right adaptation techniques!

 

BASIC might be out of scope for Andrew.  But, if you ever do a write up on the ins and outs of incorporating assembly functions, I'd be geeked!  I think finding which memory areas to avoid stepping on and playing nice with the graphic kernel must be complicated issues - something only you (as a BASIC compiler developer), Fred and RevEng could have a hope of sorting out  

 

[+Karl G]

15 minutes ago, Gemintronic said:

 

BASIC might be out of scope for Andrew.  But, if you ever do a write up on the ins and outs of incorporating assembly functions, I'd be geeked!  I think finding which memory areas to avoid stepping on and playing nice with the graphic kernel must be complicated issues - something only you (as a BASIC compiler developer), Fred and RevEng could have a hope of sorting out  

 

Since he provided source, anyone who has the time and ambition to tackle it is free to do so. I must say that it sounds like a fun project, though I'm probably unlikely to be the one to take it on.

[RevEng]

On 8/4/2019 at 3:29 PM, Dionoid said:

Unfortunately I still cannot get it to compile on dasm for Windows (version 2.20.11-2014.03.04)

Some of the assembly files here have Unix-style line endings. Older versions of dasm on Windows have extreme problems with Unix line endings. (due to dasm fopen'ing the source files in text-mode, and Windows incorrectly calculating fseek/ftell offsets with these kind of files in text-mode)

 

Grab a fixed copy of dasm from the 7800 Asm Dev Kit.

 

[+Andrew Davie]

1 minute ago, RevEng said:

Some of the assembly files here have Unix-style line endings. Older versions of dasm on Windows have extreme problems with Unix line endings. (due to fopen'ing the source files with text-mode, and Windows incorrectly calculating fseek/ftell offsets with these files)

 

Grab a fixed copy of dasm from the 7800 Asm Dev Kit.

 

Well spotted. Alas, though, that DASM has "yet another" home/location. The whole point of going to GitHub was to localise changes and ensure that there was a single point where the latest and greatest version could be retrieved from.

[RevEng]

Yeah, for sure. I wish there was one official home too.

 

The thing is, the official dasm repository was updated for quite a while, but nobody updated any of the official zip or tarball releases. As a result I (and I imagine a lot of the community) assumed it hadn't been updated at all, so we took on updates and fixes based on the last source zip release. This is why our last attempt at a merge clobbered the official source tree.

 

Now we have this "AA" version that differs quite a bit from the official release. To merge the two versions, someone would need to be familiar enough with both trees, and I don't have the time or interest to put into it, TBH. Since the AA version has been thoroughly tested (Asm programmers here have been using it, and it's distributed with bB, 7800basic, and the 7800AsmDevKit) and since it doesn't have open bugs that I'm aware of, I usually point people toward it.

 

[+Andrew Davie]

I promised to talk a bit about character sets/shapes.

The visible screen is divided into M rows of 10 characters, where M is usually 8.

Consequently, each character is 4 pixels wide (40 PF pixels across the screen / 10 characters).

Given the weird-ass playfield layout of the '2600, there are actually two possibilities for each character - it needs to be defined in mirrored and no-mirrored forms (or, big-endian and little-endian, if you like). Furthermore, each character needs to be able to live in the low-4 bits of a PF register write, or the high 4 bits of the register write. Given all of these constraints, a "character" is defined as..

a) A character definition using the "DEFINE_CHARACTER" macro. See BANK_ROM_SHADOW_RAMBANK.asm..>

    DEFINE_CHARACTER BLANK
    DEFINE_CHARACTER SOIL
    DEFINE_CHARACTER BOX

 

  so, just add a new define when you create a new character, and the define will give it a unique character number. From hereon in, the ordering of the defines above is also the order of entries in various character-related tables...

b) An pair of entries (for each character) in the 'CharacterDataVectorLO/HI' tables... these tables define the low and high addresses of...
 1) The un-mirrored definition of the character, and 
 2) The mirrored definition of the character.

Note that as there is no bank information for the character data, the characters MUST live in either the FIXED bank (always switched in), OR the bank containing the draw code (again, BANK_ROM_SHADOW_RAMBANK.asm)
 

c) The character shape data, as pointed to by (b) above.  A typical character might look like this...

 

    ;--------------------------------------------------------------------------
    OPTIONAL_PAGEBREAK "CHARACTERSHAPE_STEEL", LINES_PER_CHAR
CHARACTERSHAPE_STEEL
  .byte %00000000,%10001000,%00000000,%00000000,%00100010,%00000000,%00000000 ;R
  .byte %11111111,%11111111,%01110111,%11111111,%11111111,%11011101,%11111111 ;G
  .byte %11111111,%11111111,%01110111,%11111111,%11111111,%11011101,%11111111 ;B

    ;--------------------------------------------------------------------------
    OPTIONAL_PAGEBREAK "CHARACTERSHAPE_STEEL_MIRRORED", LINES_PER_CHAR
CHARACTERSHAPE_STEEL_MIRRORED
  .byte %00000000,%00010001,%00000000,%00000000,%01000100,%00000000,%00000000 ;R
  .byte %11111111,%11111111,%11101110,%11111111,%11111111,%10111011,%11111111 ;G
  .byte %11111111,%11111111,%11101110,%11111111,%11111111,%10111011,%11111111 ;B

Above, we can see both normal and mirrored form of a character being defined. It is optional as to if you want a mirrored character, but if you do not include it, then the shape will flip onscreen when it passes between PF0/1/2 depending on the weird-ass (again) screwy PF organisation. When you include mirrored shapes, then you don't get the flipping - but of course it costs you twice the memory to define a character.

The "OPTIONAL_PAGEBREAK" forces the character definition to NOT cross a page boundary. This is because indexed accessing across page boundaries incurs time penalties which would screw up the carefully crafted/timed code, but also - get this - YOU CANNOT (zp),y INDEX ACROSS PAGE BOUNDARIES USING 3E BANKSWITCH FORMAT (!!!)

Now, the characters are defined as 21 bytes, consiting of 3 'planes' of 7 scanlines. Each plane corresponds to one colour (7 scanlines) of the RGB triplets used in the cut-down (i.e., non-cycling) interleaved chronocolour(TM) graphics format. Also, they're vertically mirrored - but I need to double-check that

SO, scanline numbers instead of data... we have

0,3,6,9,12,15,18 . ; colour plane "red"

1,4,7,10,13,16,19 ; colour plane "green"

2,5,8,11,14,17,20 ; colour plane "blue"

Of course "red" doesn't have to be "red" - it can be any colour onscreen. But the scanlines are interleaved vertically such that we see (RGB)(RGB)(RGB)... with each (RGB) group being three consecutive scanlines onscreen. Furthermore, the eye might actually SEE (R)(GBR)(GBR)(GB) it really does depend on the shape being drawn and colours being used. It can get tricky.

So, that's about it for characters in the characterset. Each must live in the FIXED bank or in the BANK_ROM_SHADOW_RAMBANK bank. There's not really much available space there at all, so large charactersets are out of the question. Each character consists of 7 lines of RGB triplets, defined on a per-plane basis. That's 21 lines (=bytes) for a character, and doubled if you define a mirrored character.

d) The character shape data defines both left and right nybbles as duplicates of the 4-byte character data. This allows the drawing code to 
 i) mask out the unwanted part and draw really quickly
 ii) use the whole byte and speed-draw two characters at the same time if they're the same character occupying two character positions in a single PF register.


Well, that's about it for characters shapes/definitions. Quite a lot to wrap your head around. But it's not really THAT complex. Just DEFINE_CHARACTER, add the pointers to the character data, define the character data and you're done.

To actually use and see it onscreen, can be as simple as the following...
 

   lda #CHARACTER_SOIL
   sta POS_Type
   lda #7

   sta POS_Y
   lda #9
   sta POS_X
   jsr PutBoardCharacter

In the above example, a SOIL character is put at the bottom right of the screen in it's original homed position (home @0,0) - that is, the character at position [9,7] becomes a soil character.  Nearly all action on the screen uses PutBoardCharacter and GetBoardCharacter - so it's really quite simple in actual usage. The display systems automatically take care of the rest - your game code just uses GET and PUT to interact with the board/screen.
 

Edited August 5, 2019 by Andrew Davie

[Mr SQL]

9 hours ago, Gemintronic said:

 

BASIC might be out of scope for Andrew.  But, if you ever do a write up on the ins and outs of incorporating assembly functions, I'd be geeked!  I think finding which memory areas to avoid stepping on and playing nice with the graphic kernel must be complicated issues - something only you (as a BASIC compiler developer), Fred and RevEng could have a hope of sorting out  

 

 

8 hours ago, Karl G said:

Since he provided source, anyone who has the time and ambition to tackle it is free to do so. I must say that it sounds like a fun project, though I'm probably unlikely to be the one to take it on.

 

All Great ideas!

 

A BASIC compiler might wrap Andrews's PUT Chartacter API as an intrinsic command such that  "y=7:PUT(1,y,9)" would generate a similar block of asm like a macro.

 

I think the harder part would be getting the kernels and subsystems to play nice with each other as Gemintronic observed.

 

Another interesting option for the engine as a Platform could be to create a Framework to handle racing the beam, timing and house keeping, leaving the Assembly progammer to focus on just the gameloop and graphics definitions.

[Dionoid]

7 hours ago, RevEng said:

Yeah, for sure. I wish there was one official home too.

 

The thing is, the official dasm repository was updated for quite a while, but nobody updated any of the official zip or tarball releases. As a result I (and I imagine a lot of the community) assumed it hadn't been updated at all, so we took on updates and fixes based on the last source zip release. This is why our last attempt at a merge clobbered the official source tree.

 

Now we have this "AA" version that differs quite a bit from the official release. To merge the two versions, someone would need to be familiar enough with both trees, and I don't have the time or interest to put into it, TBH. Since the AA version has been thoroughly tested (Asm programmers here have been using it, and it's distributed with bB, 7800basic, and the 7800AsmDevKit) and since it doesn't have open bugs that I'm aware of, I usually point people toward it.

 

Thanks for pointing me to this build of dasm!

The weird thing is that this is also version 2.20.11, but with a newer timestamp. I'm not sure why the version number didn't get updated for this build?

 

On my local machine I now have these 4 different versions of dasm:

• dasm 2.20.11 build 2014.03.04 - from http://dasm-dillon.sourceforge.net/, which I wrongly assumed was the latest version
• dasm 2.20.11 build 20171206 - from the Batari Basic distribution page here: http://7800.8bitdev.org/index.php/Batari_basic
• dasm 2.20.07 - from another batari Basic distribution page: http://bataribasic.com/download.html (I got the 2.20.07 information when typing 'dasm -version')
• dasm 2.20.11 unofficial build 20140202a - from an older bB distribution I downloaded around March 2019: http://7800.8bitdev.org/images/1/18/BB.1.1d.reveng40.zip

Are the sources of the dasm-version that you are using available somewhere in GitHub?

[+Andrew Davie]

1 hour ago, Dionoid said:

On my local machine I now have these 4 different versions of dasm:

• dasm 2.20.11 build 2014.03.04 - from http://dasm-dillon.sourceforge.net/, which I wrongly assumed was the latest version
• dasm 2.20.11 build 20171206 - from the Batari Basic distribution page here: http://7800.8bitdev.org/index.php/Batari_basic
• dasm 2.20.07 - from another batari Basic distribution page: http://bataribasic.com/download.html (I got the 2.20.07 information when typing 'dasm -version')
• dasm 2.20.11 unofficial build 20140202a - from an older bB distribution I downloaded around March 2019: http://7800.8bitdev.org/images/1/18/BB.1.1d.reveng40.zip

 

An almost textbook example of why where we are at, regarding multiple DASM sources, is a bad thing.

 

[RevEng]

Differing online sources+versions is a problem, but the example is hardly textbook. One of those is the official dillon dasm (which is missing fixes), and the three others are bundled within historic versions of bB. (batari's abandoned version, and two of mine) 

 

The current version of packages that include dasm at 7800.8bitdev.org (bB, 7800basic, 7800AsmDevKit) all contain my latest "2.20.11 build 20171206" version of dasm. If one goes fishing for historic versions of bB in the 7800.8bitdev.org wiki, unsurprisingly you'll find the older bB versions with older dasm, as was done with the hotlinked "revenge40" example. 

 

bataribasic.com appears to have been domain-hijacked somewhere along the way, so there's not a lot of hope for taking down the old bB version with old dasm hosted there. But if you download an older bB, there should be little surprise you'll get the older bundled dasm version that it was originally tested with.

 

Which is the point - bB (and the other packages) don't claim to be the authoritative source of dasm, or even the latest source of dasm. The dasm package is bundled with them for convenience and assured compatibility with the rest of the included tools. The fact that my bundled dasm has become a somewhat authoritative source of fixed dasm binaries is a statement on the state of the official dillon tree, rather than a statement on anything I'm doing.

 

Complaining that various downloaded releases of bB have delivered various updated releases of dasm as being evidence of "a bad thing"... I'm really at a bit of a loss for words on that. No good deed goes unpunished, I guess? In retrospect it was a mistake to point to one of the recent bundles in my response to this thread, since it's another non-official source of dasm that you guys are taking issue with.

 

I provide all source code with my stuff. My dasm versioning includes the original dillon dasm tree it was based on, so changes are trivial to find. (which is why the base version doesn't change, Dionoid, but the date part of the version does) If anybody finds my bundled dasm objectionable, harmful, or bad, they're more than welcome to take on the dillon source and merge in fixes to reestablish the authority of that tree. I have very little hobby time these days, and I already have a large share of active projects encouraging programming on 6502-based platforms.

 

[+Gemintronic]

As a bB user I get to enjoy a lovingly maintained DASM version.  I always know where to get it and what to expect of its output.  So, bB -> ASM is as painless as possible.

 

I guess I'm not refuting or defending anything: just very appreciative Andrew has provided source that's easy to build and inspect.  Also, RevEng for his work on bB and 7800BAS.  It's efforts like these that keep our consoles going with new developers and thus new games.

[Dionoid]

(Note: I don't want to hijack this topic, so this will be my last reply with questions about dasm)

 

Hi @RevEng, maybe we got off on the wrong foot here; I really appreciate that you have made these fixes in dasm and the things you're doing to keep the tool alive! 

And your 'AA' version of dasm allowed me to successfully assemble Andrew's code, so thanks again for that!

 

I'm fairly new to AtariAge (I joined early 2018), so I didn't know about the history of dasm and it's various maintainers over the years.

From the information I found in the forums, it looks like the dasm-dillon version on SourceForge wasn't updated since 2015, and the last release is from 2014.

 

It surprises me that an open source tool like dasm isn't on GitHub, which is the 'de facto' platform to maintain and grow open source projects.

Btw I did find a old copy of dasm by Dennis Munsie on GitHub, but after the initial commit in 2011 nothing has changed there, and Dennis hasn't visited AtariAge for almost a year now.

 

Would you mind if I put your current version + your base version of dasm into a GitHub repository?

If you like I can add you as member, so you can create branches and merge in new changes, etc.  If you rather want to send me the updates now and then, that's okay too.

Having things in GitHub makes it easy for other people to do pull requests to get their changes in. As an example: the changes that Darrell Spice Jr. has done in Feb/March 2018 (see this thread) in GitHub he could have done this himself with a pull-request which you could have then reviewed and merged back in.

 

So the idea is that after the initial commits (i.e. base version + your current version) in the new GitHub repo, I can see if it makes sense to pull in changes that were done by Peter H. Fröhlich in the SourceForge repo. But I will be reluctant with that, as keeping a stable version of dasm is what we need. Maybe I should ask Peter himself to create a pull request for his changes from 2014 and 2015, if he is still interested.

 

My ambition is that this new repo is going to be the single source for dasm, for which anyone can file issues, create forks and have changes pulled back in, etc.
I wouldn't want any big rewrites; the goal is to stabilize the tool as much as possible so it can live on.

And the repository won't be under my name, but under the organization named "dasm-assembler". IMO this makes it more professional and 'official': 
https://github.com/dasm-assembler

 

Hope to hear from you. Please PM me on AtariAge if you like the plan (or not).

 

Cheers!

 

[Omegamatrix]

On 8/5/2019 at 9:41 AM, RevEng said:

Complaining that various downloaded releases of bB have delivered various updated releases of dasm as being evidence of "a bad thing"... I'm really at a bit of a loss for words on that. No good deed goes unpunished, I guess? In retrospect it was a mistake to point to one of the recent bundles in my response to this thread, since it's another non-official source of dasm that you guys are taking issue with.

 

I provide all source code with my stuff. My dasm versioning includes the original dillon dasm tree it was based on, so changes are trivial to find. (which is why the base version doesn't change, Dionoid, but the date part of the version does) If anybody finds my bundled dasm objectionable, harmful, or bad, they're more than welcome to take on the dillon source and merge in fixes to reestablish the authority of that tree. I have very little hobby time these days, and I already have a large share of active projects encouraging programming on 6502-based platforms.

 

 

I appreciate your efforts! If you hadn't made the fixes then probably nobody would have...