Jump to content
Thomas Jentzsch

Legacy versus ARM-based 2600 Game Development

Recommended Posts

54 minutes ago, RevEng said:

Sooooo wrong, Omegamatrix. Soooo wrong.

 

Karl, Alex Herbert is the author of the very awesome and nearly complete 2600 "Man Goes Down" game, several Vectrex games, and the drivers and docs we use for the AtariVox. After posting about health issues back in 2005, he then disappeared for about a decade, during which several attempts were made to get in touch with him, including snail mail. Many people, myself included, feared the worst.

 

Then In 2014 he updated his site with a comment about cartridges being available for some of his vectrex games, and made a back-dated post about his projects being on hold, but otherwise has been completely silent.

 

[edit - we need an AA lore wikipedia page. Knight Rider 2600, Dead Sea Scrolls, backin89, tacos, ... so much history. :P]

Wow, that is interesting news. I guess Al had to run out of body parts from Alex B sooner or later, so poor Alex H was doomed. Sounds to me like all Alexes here need to start watching their backs...

  • Haha 1

Share this post


Link to post
Share on other sites

Yeah, Albert's founding partner in crime was Alex, and it's his picture that I notice is always on my milk carton when I sit down to enjoy the latest batch of AA boxed releases.

 

Realizing now that Alex H is also gone makes me think the situation might be much worse than we thought... Its gotta be someone flipping through the white pages to randomly pick out Alexes. Speaking of which, has anyone heard from alex_79 lately?

  • Haha 2

Share this post


Link to post
Share on other sites

Hah, I did learn about Alex B that at some point (Nexus) but my mind immediately went to Alex H. Silly me, to pick the wrong missing Alex. :dunce: :lolblue: :dunce:

Share this post


Link to post
Share on other sites
29 minutes ago, Omegamatrix said:

Yeah, Albert's founding partner in crime was Alex, and it's his picture that I notice is always on my milk carton when I sit down to enjoy the latest batch of AA boxed releases.

 

Realizing now that Alex H is also gone makes me think the situation might be much worse than we thought... Its gotta be someone flipping through the white pages to randomly pick out Alexes. Speaking of which, has anyone heard from alex_79 lately?

Hmm, sounds like a perfect script for a movie! I can already hear the famous tagline, "Al be back."

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites
4 hours ago, ZeroPage Homebrew said:

You're correct, this year we introduced the 'Atari 2600: Best ≤ 4K Homebrew' award to honour the overlooked smaller games. The 4K is a seemingly arbitrary cutoff point, but it just felt to be the right place. It's a fine balancing act between being able to honour the work that goes into the games vs. the votes from the average players' understanding of what went into it, and that will become more honed with each iteration of the event.

First of all im truly ecstatic about being nominated even though i know there is no chance whatsoever of getting an award. Just happy to be there.

 

Secondly i can't help but stress bB games need their own category IMHO. Im all good with the "all in best game category" and 4K ect however like i have said many times DPC+ kernel or not bB has many restraints of it's own. It's like there is no place of their own to shine and can be over shadowed easily (much like the concerns of 4k games).

 

As of the moment we only have a chance within those top dog categories with only 3/4 the power of assembler let alone ARM. I can not write in assembly although i have a fairly clear idea how the hardware works and what can and can't be done. The countless times reading through the Stella handbook it's easy to see without the DPC+ kernel, bB games wont even remotely stand a chance.

 

The extra limitations:

Even with the DPC+ we only have 3/4 of the actual playfield to work with, fixed kernels, only one of the sprites (player1) is used as virtual sprites (without editing the kernel.asm or using a trick). Unless editing the kernels.asm many changes written within the program code in assembly are obliterated when the drawscreen command is called. I could keep going on but you get the picture.

 

Anyway that's just my two cents about the awards and slightly off topic in this thread i guess.

  • Like 2

Share this post


Link to post
Share on other sites
38 minutes ago, TwentySixHundred said:

 

The extra limitations:

Even with the DPC+ we only have 3/4 of the actual playfield to work with, fixed kernels, only one of the sprites (player1) is used as virtual sprites (without editing the kernel.asm or using a trick). Unless editing the kernels.asm many changes written within the program code in assembly are obliterated when the drawscreen command is called. I could keep going on but you get the picture.

To get 100% of the playfield give SuperCharger BASIC a try for performance greater than regular asm due to the soft blitter and somewhat closer to the ARM, or the BoulderDash construction kit if you know asm.

 

The ZeroPage show will need to turn off merge frames and phosphor on their emu to properly display some SuperCharger games though - this setting gives the ARM games an unfair boost. In Gdansk, they used an authentic CRT for their show which can tilt the playing field in favor of legacy reto techniques like artifacting and low pass filters.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

To further more explain where i'm coming from to those who are interested yet do not know the technical side of things. I will use my bass fishing tournament game as an example along with a couple of classics. With bB game design it can be quite the struggle when playfield comes into play and strategic placement along with illusion are needed for simple tasks.

 

As you can see everything highlighted in purple is out-of-bounds territory when it comes to playfield. This can make some game concepts very challenging when you would think it's simple. If you look at the broken medium strip on the road, it's easy to assume this is playfield when it's really background colour banding. BKGRND can only be a one complete solid colour on the whole horizontal band. if i was to use playfield as lines there would be incomplete missing lines on the sides making the image look unrealistic. The effect of the broken line is made by adding playfield pixels of the same colour as the road when really it would have been easier to just draw the lines as playfield. See example below v

bB_playfield_restrictions.png.4d2beee1e623f88bedaabba1a4ca0f1d.png

 

Now lets compare this to something written using assembly you can clearly see those restrictions are lifted and they make a huge impact on game design. Games such as Adventure and Tunnel Runner for example can use playfield pixels the full width of the screen. Clearly you can see the advantages with having the ability to do so, it's still possible to create an adventure like game in bB however something like Tunnel Runner is near impossible. The way those playfield pixels scale down the aisle cannot be done, well atleast for the full screen and if using background colour banding it starts to look messy.

 

adventure_3.gif.194b27e2d029f6bdb7bbfc35c9d9dc76.gif

tr2600.thumb.png.10009acad06d7e902647c421df6e81bb.png

 

Edited by TwentySixHundred
  • Like 1

Share this post


Link to post
Share on other sites

Each kernel comes with compromises. Using Assembly doesn't change that (the bB kernels are done in Assembly too). The main differences is, that when using Assembly it is up to the developer to optimize CPU usage and to decide which compromises to take. That allows him to tailor the kernel to its needs. What is limiting you in bB are the currently available, predefined kernels.

 

Not using or changing PF0 in a symmetrical kernel is a frequent compromise in Assembler games. Examples are River Raid, Lady Bug, Miner 2049er, Centipede/Millipede and Mr. Do.

  • Like 5

Share this post


Link to post
Share on other sites
9 minutes ago, Thomas Jentzsch said:

Each kernel comes with compromises. Using Assembly doesn't change that (the bB kernels are done in Assembly too). The main differences is, that when using Assembly it is up to the developer to optimize CPU usage and to decide which compromises to take. That allows him to tailor the kernel to its needs. What is limiting you in bB are the currently available, predefined kernels.

 

Not using or changing PF0 in a symmetrical kernel is a frequent compromise in Assembler games. Examples are River Raid, Lady Bug, Miner 2049er, Centipede/Millipede and Mr. Do.

Well yeah exactly, so unless writing a custom kernel, when like you said needs asm knowledge to do so, bB users are constrained to the predefined kernels. Lets be honest anyone willing to write a custom kernel, would much rather just code the game in assembly anyway (then the only limit is the system).

 

It's no secret assembly has alot more power at the finger tips over using a cross-compiler method. Having the flexibility of changes no matter how small, they can either make or break the games concept. Especially in the 2600 world where every cycle, every bit and every restraint counts immensely.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, TwentySixHundred said:

It's no secret assembly has alot more power at the finger tips over using a cross-compiler method. Having the flexibility of changes no matter how small, they can either make or break the games concept. Especially in the 2600 world where every cycle, every bit and every restraint counts immensely.

Assembly code can translate your ideas a bit tighter, faster, and it's a bit easier to predict the number of cycles used. All of that is necessary for kernel code.

 

All of those same properties are less of an advantage in the rest of your game, especially if you don't care about keeping your game under 4K. Algorithmic choices trump language choices, and most non-kernel tasks aren't as speed dependant, to the point where they can be spread across multiple frames. In that way, the more advanced the hardware kernel assist gets, the smaller the divide gets between bB results and assembly results. On the 7800, which doesn't use a display kernel at all, you'd be hard pressed to tell if a game was made in 7800basic or assembly.

 

If the 1990s stella list guys could peer into the future and see the result of your bB program using the bB DPC+ stock kernel, I think they'd be rather impressed, and I'm sure they would assume it was a custom purpose kernel and that you were an advanced assembly coder.

 

8 hours ago, TwentySixHundred said:

Lets be honest anyone willing to write a custom kernel, would much rather just code the game in assembly anyway (then the only limit is the system).

I'm the counter example. I've written all kinds of 2600 kernels, but I choose to program games in a mixed mode, since bB and 7800basic allow for inline assembly and assembly modules. My hobby time is a limited 2600/7800 resource too, and I'll gladly trade a bit of rom for the ability to use higher-level language in areas where a lower-level language doesn't have pressing advantages.

 

Still a weirdo, I guess. :lol:

 

 

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, Thomas Jentzsch said:

...

Not using or changing PF0 in a symmetrical kernel is a frequent compromise in Assembler games. Examples are River Raid, Lady Bug, Miner 2049er, Centipede/Millipede and Mr. Do.

Also for asymmetrical kernels you can do without using PF0 (and gain some cycles), like I did in Tower of Rubble to display the rubble blocks.

The trick is to change the value of PF2 on cycle 48 exactly.

tor2600_2.thumb.png.215c161fbc302a9d2b2dee24ec22283b.png

  • Like 3

Share this post


Link to post
Share on other sites
12 hours ago, TwentySixHundred said:

Now lets compare this to something written using assembly you can clearly see those restrictions are lifted and they make a huge impact on game design.

 

As @Thomas Jentzsch says this occurs in assembly games as well.  The difference between Assembly and bB is with Assembly you get to chose the tradeoff, while with bB the tradeoff was chosen for you.

 

I cover that in Stay Frosty, Part 3, where the game originally looked like this:

 

sf.png

 

 

and Stay Frosty Part 4, where I made the tradeoff of dropping PF0 updates:

Quote

I decided to change to use a reflected playfield and drop the updating of PF0 for the upper platforms. PF0's still used to draw the horizon as well as the lowest platform.

Doing this means the snowman can always drop down on the left and right sides of the level. It also adds an additional constraint to the kernel in that you must update PF2 at cycle 48 in order for the left and right sides of the screen to be different; however, it frees up 12 cycles per scanline in the ice and platform kernels as well as 18 bytes of RAM.

 

sf.png

 

 

 

  • Like 5

Share this post


Link to post
Share on other sites

bB has its own advantages and disadvantages vs. assembly for sure. It's true that there are some options that are not available, but there are a lot of different kernels, kernel options, and minikernels to choose from to cover a wide variety of needs. The disadvantage of not having as much control over trade-offs is offset by the relative ease of making the game vs. making an assembly game: you can jump right in and start coding with a pretty good high-level language vs spending your initial time planning a kernel that works for your game concept within the timing constraints of the platform.

  • Like 4

Share this post


Link to post
Share on other sites

I fully agree and understand what you all have said, the ability to not be able to chose that trade off especially with DPC+ is the crippling part. For many concepts i have had, like for example the ability to use PF0 updates would have been nice as with Street Rod 2600 (WIP) i really wanted the car interior pov. However without the full width of playfield pixels it's extremely hard to make something that looked good (first person). So that idea was dropped for the lackluster aesthetics of 3rd person. I do believe that with assembly i would have the ability to add those much needed PF0 updates (depending on the trade off).

 

Then there is the other issue i mentioned a few posts back that only player1 can be used as virtual sprites, as far as my knowledge extends. There has been instances in the past id like to virtual sprite player0 to reduce flicker on the same scanline. Without the ability i have decided to abandon projects in the past. Although i'm hoping to find a trick to virtual sprite player0 without flicker if possible (i can but with terrible flicker).

 

I'm not complaining as i think bB is brilliant and slowly getting my head around 7800basic on the side. The speed of development and ability to concentrate on the logic rather then kernel is perfect for me. Although there is these little kernel restrictions i know that can be done with the flexibility of assembly.

 

I must say though, not on the level of tips and tricks assembler programmers discover, i'm finding myself having an interest in trying to push bB to do things i wouldn't think were possible. Half the fun is experimenting with small programs and playing around with algorithms/techniques to try and discover something new. So in a way we all share the same interests no matter the language used.

 

Thanks for the replies guys 👍

Edited by TwentySixHundred
  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, TwentySixHundred said:

First of all im truly ecstatic about being nominated even though i know there is no chance whatsoever of getting an award. Just happy to be there.

 

Secondly i can't help but stress bB games need their own category IMHO. Im all good with the "all in best game category" and 4K ect however like i have said many times DPC+ kernel or not bB has many restraints of it's own. It's like there is no place of their own to shine and can be over shadowed easily (much like the concerns of 4k games).

 

First, me too. I know I'm not going to win, but it feels pretty nice seeing my dumb little octopus game listed with all those amazing games.

 

Second, while I like the idea of leveling the playing field, I don't know that creating a separate bB category would necessarily do that, as it would pit 4k games against 32k DPC+ games, which is exactly the type of thing the 4k category was created to avoid (and, most likely, just net me another nomination for another award I wouldn't win). Not every game can be the best. That doesn't mean it isn't good.

  • Like 3

Share this post


Link to post
Share on other sites

All excellent points about the kernels and trade-off options present in bB and what can be done custom in Assembly - 

 

Also a great point that bB loses fine grain control of the scanlines, accessing the full width of the playfield or the drilldown to the individual scanlines that comprise the frame that you get with custom asm.

 

There is a third option with the Atari 400/800  where BASIC and Assembly programmers can use the ANTIC chip to marshall sections of the screen with display lists, which are lower level than the whole frame, but higher level than the individual scanline and give the BASIC or the assembly programmer a lot of extra functionality for making the cool A8 and 5200 games we have seen - the ANTIC chip is indeed much like an ARM from back in the day in this respect.

 

SuperCharger BASIC gives you the option to use Display lists like the ANTIC because the soft blitter chip has similar functionality, here's a simple BASIC example where the playfield is splitup into three different sized zones, each with it's own playfield CAM and display list calls, you can control the ship a bit with the joystick and it's influenced by the physics in the different zones in this demo:

 

http://javatari.org/?ROM=http://relationalframework.com/Flashback_BASIC_DLI_Demo.bin&SCREEN_FULLSCREEN_MODE=1

 

It's pretty cool because it gives BASIC and assembly programmers a way to go lower level and program variable sized sections of the frame still racing the beam necessarily because all sections are within one frame, but at a more abstract level marshalling variable sized blocks of scanlines at a time for bit blasting. And it's alot simpler and friendlier to the BASIC programmer than working with the more powerful display lists on the A8.

 

This is also an example where the SuperCharger BASIC program was cross compiled as CBS RAM+ format for the Atari Flashback Portable, with no changes to the BASIC program, I'm working on an A8 version of the cross compiler as someone pointed out CTIA/GTIA is similar enough and should be able to accomodate my soft antic to run "Atari 2600 games" on the A8 with no changes to the BASIC  code - what will we call them, SuperCharger games, CBS RAM+ games, soft antic games?

 

Interesting stuff... 

  • Like 1

Share this post


Link to post
Share on other sites

There is also the restriction within DPC+ i forgot to mention of storing graphics data. We are restricted to only being able to store 4k worth of data and haven't the ability to store any graphics data in other banks. That's for all the colour properties as well, so when using multiple hi-rez playfields with different colour bands the graphics bank fills up quickly. Im not 100% sure if assembly has full freedom to store this data where desired however i assume that's the case.

 

Then as SQL has mentioned the SuperCharger option is great with all the extra RAM. I looked into the SuperCharger many years ago although AFAIK it's not compatible with the DPC+ kernel. Maybe it's time i break open the DPC+.asm kernel and try to decipher the assembly language to see what or if i can make some sort of changes for something more custom.

 

I have a feeling it's a little out of my league though and a conversation between RevEng and Karl G springs to mind. Another topic awhile back IIRC, something along the lines of there isn't much room left in the DPC+ kernel for many alterations AFAIR. I could be wrong though, it may have been about custom score kernels (i struggle to remember).

Edited by TwentySixHundred

Share this post


Link to post
Share on other sites
2 hours ago, TwentySixHundred said:

There is also the restriction within DPC+ i forgot to mention of storing graphics data. We are restricted to only being able to store 4k worth of data and haven't the ability to store any graphics data in other banks.

 

Data must be in that 4K location for the DPC+, CDFJ, and even BUS "coprocessors" to access it for display.  It is RAM though, so its likely you could overwrite it.

 

I'm not that familiar with bB, but am willing to take a look.  Could you create a simple "game" that just moves a character around the screen with the joystick? Just use a single static multicolor image, I should be able to go from there to see if I can animate it using graphics stored in another bank.

Share this post


Link to post
Share on other sites
33 minutes ago, SpiceWare said:

 

Data must be in that 4K location for the DPC+, CDFJ, and even BUS "coprocessors" to access it for display.  It is RAM though, so its likely you could overwrite it.

 

I'm not that familiar with bB, but am willing to take a look.  Could you create a simple "game" that just moves a character around the screen with the joystick? Just use a single static multicolor image, I should be able to go from there to see if I can animate it using graphics stored in another bank.

No worries that makes complete sense now, thanks for taking the time to have a look into it. I have whipped up this test program quickly as requested to have a look at. Cheers

graphics_bank_test.zip

Share this post


Link to post
Share on other sites
1 hour ago, TwentySixHundred said:

No worries that makes complete sense now, thanks for taking the time to have a look into it. I have whipped up this test program quickly as requested to have a look at. Cheers

 

This did not turn out how I thought it would, but I was able to get player 0 to use graphics stored in other banks.

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Is it possible to unload the burden of paddle input checking to the ARM? If so, have there been any ARM assisted paddle games made?

Share this post


Link to post
Share on other sites
On 2/13/2020 at 12:48 PM, p1FqO3 said:

Is it possible to unload the burden of paddle input checking to the ARM? If so, have there been any ARM assisted paddle games made?

 

The ARM has no access to the 2600 hardware, everything must be read by the 6507 and passed to the ARM.  

For a regular one player game the 6507 code might look something like this:

        MAC READ_PADDLE_1
        lda INPT0         ; 3   - always 9
        bpl .save         ; 2 3
        .byte $2d         ; 4 0
.save   sty Paddle1       ; 0 3
        ENDM

 

That routine would be run on every, or every other scanline, during the kernel. How often depends on range of movement needed for your game.  

 

The ARM could be used help a little bit by doing this:

        MAC READ_PADDLE_1
        ldx INPT0         ; 3
        stx DSWRITE       ; 4 
        ENDM


which would defer the bpl/sty paddle1 logic for the ARM to handle.  That would saves 2 cycles per scanline. I'm not aware of anybody having done this yet.

  • Like 1

Share this post


Link to post
Share on other sites
31 minutes ago, SpiceWare said:

 

The ARM could be used help a little bit by doing this:

        MAC READ_PADDLE_1
        ldx INPT0         ; 3
        stx DSWRITE       ; 4 
        ENDM


which would differ the bpl/sty paddle1 logic for the ARM to handle.  That would saves 2 cycles per scanline. I'm not aware of anybody having done this yet.

 

I'm not familiar with ARM, of course, but couldn't you improve this by simply doing the "ldx INPT0" and having the ARM detect the address being the paddle and do everything from that point? 

 

  • Like 2

Share this post


Link to post
Share on other sites
2 minutes ago, Andrew Davie said:

 

I'm not familiar with ARM, of course, but couldn't you improve this by simply doing the "ldx INPT0" and having the ARM detect the address being the paddle and do everything from that point?

 

Possibly.  The coprocessor* drivers we currently have don't support that, so a new one would need to be designed and written. Getting the right people together for that isn't easy.

 

* BUS, CDFJ, DPC+

Share this post


Link to post
Share on other sites
1 hour ago, Andrew Davie said:

 

I'm not familiar with ARM, of course, but couldn't you improve this by simply doing the "ldx INPT0" and having the ARM detect the address being the paddle and do everything from that point? 

 

You could. It would have to be coded into the driver, but this could be done. No need for ldx, as you could do a NOP INPT0 and the ARM could still capture the value.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...