Jump to content
IGNORED

Legacy versus ARM-based 2600 Game Development


Thomas Jentzsch

Recommended Posts

38 minutes ago, orange808 said:

Meh.  I'll gladly concede if you say it wasn't you or I'm mistaken.

 

Regardless, the $18 million dollar Cray thing is complete rubbish.  

 

Rather I'm mistaken or not, the Cray thing was a smear.  Nice touch with the dollar value as well.  :)

 

 

Did you catch the part where he said he has contributed to code supporting ARM hardware assistance in batari Basic? Wouldn't it be a little odd for him to make smears against the same now?  The Cray comparison is interesting and useful for perspective, but explaining how some modern Atari carts use modern technology isn't a smear. 

  • Like 5
Link to comment
Share on other sites

I'm just grumpy.

 

Didn't like the dollar figure and the mention of a supercomputer.  It's a loaded comparison.  Guess it just hits a nerve every time I stumble onto it. 

 

Intentional or not, it provides ammo to snipe stuff like Robotron and Galaga--and I'm absolutely humbled by new titles.  They are jaw dropping.

Link to comment
Share on other sites

2 hours ago, splendidnut said:

@orange808  What is with the attacks?

@splendidnut it looks like Orange808 was just called a weasel for expressing his opinion. I only saw a discussion prior to that, where were the attacks?

 

1 hour ago, orange808 said:

I'm just grumpy.

 

Didn't like the dollar figure and the mention of a supercomputer.  It's a loaded comparison.  Guess it just hits a nerve every time I stumble onto it. 

 

Intentional or not, it provides ammo to snipe stuff like Robotron and Galaga--and I'm absolutely humbled by new titles.  They are jaw dropping.

 

I made a comment comparing the ARM to the Cray-XMP, but I don't think that's a loaded comparison or that it should get you upset;  consider John's related comment to the effect  "It's much easier to code the gameloop in c on the ARM than coding to the 6502"  

 

These are excellent games but being modern 32-bit code they simply can't be compared to advanced 6502 releases like BoulderDash, Arkanoid and KCMM that push the old 8-bit hardware to new limits.

 

SillyVenture shares this perspective and doesn't allow any ARM games or demos to compete in their 8-bit programming contests.

 

There's an interesting discussion on the Chess thread with Batari and Andrew about ideas for writing newer ARM games and also an advanced 32-bit interpreted BASIC that could connect through the USB on the Harmony for full featured debugging with Edit-and-Continue functionality as has recently been created for the Vectrex.

 

The new code creations are fun to appreciate but it is also a lot of fun to work with the old hardware simply because it is more challenging.

 

When reviewers compare the 32-bit Atari games to 8-bit Atari games like with Super Cobra and Super Cobra Arcade they aren't intentionally sniping but it's disappointing because reviewers aren't programmers and simply cannot tell the difference; John made the comment on the VGC's forum to try to explain the difference but Super Cobra still got an F and Super Cobra Arcade an A; I would give both games an A, and they are both a lot of fun to play but cannot be compared; it's really apples to oranges comparing modern 32-bit c code to retro 6502 code.

 

Beyond one game being 32-bit and one 8-bit game there is also a considerable memory size difference; Whirly Bird Run was an impressive 16K clone of Super Cobra in the 80's but back then reviewers knew not to compare the 16K port to a 32K or 64K version running on the same processor. Even this is lost on many reviewers today.

 

  • Like 1
Link to comment
Share on other sites

@Mr SQL  I believe RevEng quoted the things he had issues with.  His reaction seems to give me the impression that he felt attacked.

 

Being as you called them discussions... Would you prefer that I use the word accusations?  Because there were a lot of them without facts or links to back them up.  Sorry if my word choice was not the best.  I was just trying to get to the root of the issue.  I would have corrected/elaborated on my post, but @Karl G beat me to it and handled things much better than I did. :)

 

@ All

 

Are Atari 2600 ARM games really 32-bit?  Being as most/all of them run in Stella and Stella only has Thumb emulation... and the Thumb instruction set is only 16-bit, right?

  • Like 2
Link to comment
Share on other sites

4 minutes ago, splendidnut said:

Are Atari 2600 ARM games really 32-bit?  Being as most/all of them run in Stella and Stella only has Thumb emulation... and the Thumb instruction set is only 16-bit, right?

Nope. The thumb instruction set is mostly(!) 16 bit (to save space), but the instructions are fully equivalent to the 32 bit instructions.

Link to comment
Share on other sites

22 minutes ago, splendidnut said:

@Mr SQL  I believe RevEng quoted the things he had issues with.  His reaction seems to give me the impression that he felt attacked.

 

Being as you called them discussions... Would you prefer that I use the word accusations?  Because there were a lot of them without facts or links to back them up.  Sorry if my word choice was not the best.  I was just trying to get to the root of the issue.  I would have corrected/elaborated on my post, but @Karl G beat me to it and handled things much better than I did. :)

 

I follow what you are saying but I think it may be more a matter of perception.

 

On the thread I linked there was an observation of a "gazillion bytes" being made available to ARM games but that should not be taken out of context; in the 80's there was such a world of difference illustrated between 4K and 16K games and again between 16K and 32K and 32K and 64K games that different comparison categories were created just on the memory footprint alone. 

 

Link to comment
Share on other sites

2 hours ago, Thomas Jentzsch said:

Nope. The thumb instruction set is mostly(!) 16 bit (to save space), but the instructions are fully equivalent to the 32 bit instructions.

 

2 hours ago, splendidnut said:

Ah, ok.... that makes sense.  I once designed a CPU architecture like that (16-bit instructions with 8/16/32-bit registers) for a college project.

I’m a little confused here. Aren’t processors/co-processors defined by the width of their registers. So since the Atari 2600 has an 8-bit accumulator (and x/y registers) it is referred to as an 8-bit system. Even though the program counter is a 16-bit register.

https://en.m.wikipedia.org/wiki/Processor_register

 

If the ARMs computational registers are 32-bit, wouldn’t that make it a 32-bit co-processor, regardless of the width of the instruction set the processor uses?

 

PS (The Atari Jaguar used some strange math to try to claim they were a 64-bit System, and had an ad campaign around that 64-bits is more than Sony/Sega 32-bit offerings PSX/Saturn.)

 

Edited by CapitanClassic
Link to comment
Share on other sites

On 6/20/2020 at 10:03 AM, CapitanClassic said:

 

I’m a little confused here. Aren’t processors/co-processors defined by the width of their registers. So since the Atari 2600 has an 8-bit accumulator (and x/y registers) it is referred to as an 8-bit system. Even though the program counter is a 16-bit register.

https://en.m.wikipedia.org/wiki/Processor_register

 

If the ARMs computational registers are 32-bit, wouldn’t that make it a 32-bit co-processor, regardless of the width of the instruction set the processor uses?

 

PS (The Atari Jaguar used some strange math to try to claim they were a 64-bit System, and had an ad campaign around that 64-bits is more than Sony/Sega 32-bit offerings PSX/Saturn.)

 

Yes, a processer's bit-width is generally determined by the size of the registers.  Instruction set width doesn't really matter... Ex:  eventhough an Intel 80386 still used 8-bit opcodes, it's a 32-bit processor (32-bit registers and 32-bit ALU).

 

Things can start to get a bit murky though.  Consider the Pentium MMX chip - for the most part, it's designed to execute 32-bit software... but also has a subset of instructions that access the MMX registers which are 64-bit.  You can argue whether it's a 32-bit or 64-bit processor depending on whether you consider MMX as part of the main CPU or as an add-on like the FPU that just happens to be built-in.

 

So, with that in mind, if a 64-bit processor is only ever used to run 32-bit programs, are you really gaining anything with a 64-bit processor vs. a 32-bit processor?  (assume same clock speed)....  I'd say you really aren't since the programs aren't taking advantage of the 64-bit registers.

 

I asked the question about the ARM's Thumb mode because it can make a difference with performance.  IF the Thumb instructions were only allowed to run 16-bit code (code that worked only on 16-bits at a time), I would argue that eventhough the ARM itself is 32-bit, if it's running ONLY in a 16-bit mode, we shouldn't keep saying 32-bit ARM vs 8-bit 6502 since it would really be 16-bit vs 8-bit code.

 

BUT as Thomas has answered, that is NOT the case since the ARM is running 32-bit code in Thumb mode.   So it is 32-bit ARM vs. 8-bit 6502.

 

 

 

  • Thanks 1
Link to comment
Share on other sites

Yes, Thumb code works as normal 32 bit code, only with a few limitations (e.g. less registers) so that all instructions fit with into 16 bit.

 

So the power of 32 bit is there, but I am not sure how much an e.g. 32K game really profits from it. It obviously doesn't need any 32 bit addresses and probably not much 32 bit data. For such a game, I suppose effectively the ARM code is much closer to 16 bit than 32 bit code. This only changes with 64K (+RAM!) or larger games.

 

Maybe others have more details?

Link to comment
Share on other sites

  • 10 months later...

People are probably going to be annoyed with me for bringing up a contentious thread, but... sorry :-D I was trying research SpiceC and some other things.

I'm a both-sideser here. There is something so beautiful about a game that stays within the old 4K hardware limits, that we need to foster recognition for that as well as we can. 

But I get that "enhanced" carts have been around well within the original lifespan of the system, and they open up new vistas of gameplay, brilliant new wine in a very old bottle.

(I wish we had cleaner vocabulary for both "vanilla 4Ks" and "hardware boosted" carts!)

I think the best example in this old thread was how people treated "NES carts as a framebuffer running DOOM offa rasberry pi". I think that's the concern for me, like making the technical problem just the visual bottleneck... 


I do see both sides but my heart is a bit more w/ the Thomas / "purity of the legacy limitations" camp but I don't want this to get mean spirited

It raises a question: why the Atari, then, for people who are firmly in the "lets push what we can cram into carts" camp? Like there's lots of interesting platforms for making games (I've done a lot more in "p5" and then I get to share it via browser - see https://toys.alienbill.com/ ) "back in the day" for homebrew, the answer was "to see something run on a TV" (before HDMI was standard that wasn't neccesarily easy!) or "to explore the possibilities of the old constraints"... but what is the core of the appeal of enhanced games, both coding and playing?

A. that there's at least a bit of a guaranteed audience who like everything Atari?
B. the more esoteric concern of... well what CAN we cram down into a TIA w/ unlimited hardware besides that
C. pushing the limitations that are still there... like one (or two) joystick, one button...  some of the remaining display limitations
D. Just the retroappeal / funk of it?  Either for personal growing up reasons or a kind of hipster fun vibe

 

Link to comment
Share on other sites

There's room in this hobby for everything ranging from 2K original size to ARM-enhanced, and more. It doesn't have to be one or the other. It's as simple as what flavour do you like?

 

Do you want to play something made in 2021? With 2021-style hardware? Or simply revel and reminisce in the aura of 1979 replete with all the limitations of that period?

 

1 hour ago, kisrael said:

(I wish we had cleaner vocabulary for both "vanilla 4Ks" and "hardware boosted" carts!)

Just call them what they are. By the bank. 2K, 4K, 8K, 16K, DPC, or Arm-enhanced. The bank-switching terminology is self-explanatory and hasn't changed in years, decades even.

 

1 hour ago, kisrael said:

..but what is the core of the appeal of enhanced games, both coding and playing?

At this instant in time I lean a little toward ARM-enhanced games because we don't have a lot of them in comparison to 2K - 16K titles.

 

But there's more. I also like those arcade ports from Champ Games and SpiceWare. It's interesting and amusing to see the old arcade games done up in VCS flavor using TIA sound & graphics. Not too different from what we (as kids of the 70's & 80's) imagined an S-VCS would be. Super Video Computer System.

 

It's pretty obvious we've long ago reached the limits of what the 6507 can do. We are getting x amount of computing power and that's it. But there's still headroom left in the TIA. And these enhanced games explore that built-in untapped potential. Something the 6507 will never do.

 

Quote

I think the best example in this old thread was how people treated "NES carts as a framebuffer running DOOM offa rasberry pi". I think that's the concern for me, like making the technical problem just the visual bottleneck...

Today I won't critique Doom on the NES. At the same time you won't see me chasing after it or making my own cartridge. Nor would I play it (on NES) beyond a moment of curiosity. For me Doom is a 486-era PC game and that is the best way to play it. Not on NES, not on PS5, and definitely not on the Jaguar. And that is OK!

 

Edited by Keatah
Link to comment
Share on other sites

5 hours ago, kisrael said:

... but what is the core of the appeal of enhanced games, both coding and playing?

For me, it's wish-fulfillment.

 

As a non-programmer, it's still amazing to me that I get asked by homebrew developers to work on their games (both ARM and non-ARM) and create graphics for them. I wanted to do that since I was a kid, but math and I never got along very well, so I went down the art path instead.

 

I really enjoy the challenge of making something recognizable out of so few pixels, and my goal is to push those graphics to look as good as they possibly can. To me, the underlying technology driving the cart matters very little, but if I'm able to get single line resolution, more colors, or extra ROM to store more frames, then that gives me more crayons in the box to play with. :) 

 

As to why I don't work on games for other systems, I don't have any nostalgic connection to them. The 2600 was *my* system, and the one I wanted to make games for back in the day. I got a 7800 when they were finally released, but the game library was anemic and I played more 2600 games on it than 7800 ones. Even though the 7800 has an amazing homebrew library now and I get pretty-much every homebrew for it, developing for it doesn't have the same appeal.

  • Like 3
Link to comment
Share on other sites

15 minutes ago, Nathan Strum said:

As to why I don't work on games for other systems, I don't have any nostalgic connection to them. The 2600 was *my* system, and the one I wanted to make games for back in the day.

 

That part is the same for me. I was still in school when I got my Atari 2600 on March 27, 1982. I was out of school and working by the time I got an Atari 7800, so it wasn't as special. Another thing against the Atari 7800 was that the NES had new games that were interesting and exciting while the Atari 7800 kind of seemed behind the times. The NES was almost like having the excitement of the Atari 2600 back again (although I wasn't a fan of big boss fights, static action puzzle games, die and remember games, and punchy/kicky games).

 

I hoped someone would eventually create a BASIC-like language for making Atari 2600 games and someone did (batari Basic). I'm a non-programmer game player who can barely use BASIC, so I mostly copy and paste from the bB page since a lot of what I learn crumbles away.

 

My goal is to make at least one Atari 2600 adventure game that has Activision/Imagic quality graphics. I hope to have enough variables to have smart enemies and enough variables to remember things like dropped objects that will stay there even if you run 12 rooms away. If that requires an affordable supercomputer in a cartridge and somebody can make it happen, I'll be one of the first people in line.

 

Assembly language programmers with big brains and memories that don't leak can challenge themselves by making the best 4K games ever created, but since I have to use something like batari Basic that already eats up resources before I can even get one sprite up on the screen, I need all of the big beefy extreme "cheating" I can get. I'd like to have so much RAM, ROM, and extra variables that they'd choke a gigantic hungry dinosaur.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Nathan Strum said:

As to why I don't work on games for other systems, I don't have any nostalgic connection to them. The 2600 was *my* system, and the one I wanted to make games for back in the day.

That's a huge factor for me, the three systems that have always meant something to me would be the VCS, Apple II, and PC. And Intellivision as the runner up if I had to pick a 4th system. They're what I had the best of times with.

 

But on a more on-topic note, is it me or have devs figured out how to increase the resolution of the VCS? Especially with ARM games. The first releases like COMBAT and SURROUND and MINIATURE GOLF are pretty low-res. Compare that against material being made today.

 

I do understand that technically the TIA has a single-line of vertical resolution.

Link to comment
Share on other sites

48 minutes ago, Keatah said:

But on a more on-topic note, is it me or have devs figured out how to increase the resolution of the VCS? Especially with ARM games. The first releases like COMBAT and SURROUND and MINIATURE GOLF are pretty low-res. Compare that against material being made today.

Many early games did use two-line kernels, but single-line kernels are nothing new. Home Run's sprites are single-line. They don't have any color changes so they appear to lack detail, but the sprites in Champ Sports Baseball won't be any higher resolution, they'll just have more color changes and more frames of animation. The playfield-based scoreboard in Home Run (and other early games) also lent to that low-resolution look.

 

We're still limited to the same resolution the 2600 has always had. The ARM just lets us throw more sprites on screen at one time, at single-line resolution, and with color changes. But we're not making it draw anything at an increased resolution. We're just able to make more use of the higher resolution capabilities already there.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Thanks for the thoughtful responses and lets continue to keep this friendly... glad I'm not regretting a can-of-worms-opening :-D

8 hours ago, Nathan Strum said:

I really enjoy the challenge of making something recognizable out of so few pixels, and my goal is to push those graphics to look as good as they possibly can. To me, the underlying technology driving the cart matters very little, but if I'm able to get single line resolution, more colors, or extra ROM to store more frames, then that gives me more crayons in the box to play with. :) 

So, more crayons in the box, but not like... an "airbrush" (or even fancy clip art collection) that a totally different platform with even fewer limitations might offer. 

I guess it is this interesting middle ground, without TOO much fear of a "slippery slope". Like, just because some smart folks are cramming ENTIRE 90 minute MOVIES onto a cart - and in theory that means the atari can be used as arbitrary video screen - doesn't mean that's the inevitable endgame for the move towards enhanced carts.

I talk about some "p5" work I do which has some parallels ... (and I'd encourage people who like to dabble in programming to check it out! https://openprocessing.org/ for some examples. It lacks the nostalgia factor of retrogames, but you get to exercise programming chops a little closer to mainstream modern programming, and share on the web).  Anyway, I think about why I chose p5 over Unity and stuff, and some of it was laziness in learning but also there's something lovely about building from scratch - instead of pixels, its building blocks for me was basic 2D shapes (which reached its culmination when I realised i was using the same technique Ed Emberley's books taught me as a kid - see https://animals.alienbill.com/ 

Link to comment
Share on other sites

8 hours ago, Nathan Strum said:

As to why I don't work on games for other systems, I don't have any nostalgic connection to them.

This! Besides an Atari 2600 I only owned a C64 back then. And the Atari provides some very special challenges I really like to master.

Link to comment
Share on other sites

15 hours ago, kisrael said:

It raises a question: why the Atari, then, for people who are firmly in the "lets push what we can cram into carts" camp?

I actually never owned an Atari 2600 back in the day (I had a C64 which I loved) so I have no nostalgic connection to the '2600 itself, but only to the 65xx microprocessor inside.

 

In the beginning of 2018, I decided to try to fulfil one of my childhood dreams: to create a game for the Commodore 64, so I started to learn 6502 assembly and the inner workings of the C64. During that process, I came across a video by @SvOlli called The Atari 2600 Video Computer System: The Ultimate Talk. I was intrigued/amazed by the limitations of the '2600 (mostly the TIA) and the fact that you have to count all your program-cycles to be able to draw stuff on the screen. The fact that the Atari 2600 only works with cartridges, made it even more interesting. Then I discovered the amazing Stella debugger, and decided that -instead of the C64- I wanted to make a game for the Atari 2600. And I didn't look back at programming the C64 since ?

 

While I understand why people strictly want to create games that are within the original 4K limits (I actually used these self-imposed limits for my first game), I think it becomes a sliding scale when you start to consider hardware-based improvements like bank-switching, additional RAM (SARA) or co-processors (DPC, ARM). Any line that you draw here is arbitrary.

 

To me, the only limitation of a cartridge is that it has to fit into the cartridge port.

And I bet no-one complained that the DPC co-processor in Pitfall II was 'cheating' when this game hit the market in 1984 ?

 

 

Edited by Dionoid
  • Like 1
Link to comment
Share on other sites

9 hours ago, kisrael said:

So, more crayons in the box, but not like... an "airbrush" (or even fancy clip art collection) that a totally different platform with even fewer limitations might offer. 

I guess it is this interesting middle ground, without TOO much fear of a "slippery slope". Like, just because some smart folks are cramming ENTIRE 90 minute MOVIES onto a cart - and in theory that means the atari can be used as arbitrary video screen - doesn't mean that's the inevitable endgame for the move towards enhanced carts.

Compared to the 6502 the ARM is a modern platform for having onboard cache and niceties that can run Linux so a programmer running an Atari 2600 gameloop on the ARM is like a ballplayer with Tommy Jones Surgery. The ballplayers ARM still looks normal, but the added tendon really changes the game.

 

imo there's still room to explore the flexible architecture with contemporary expansion that was available during the lifetime of the system; it takes more time, but that's part of the fun!

 

9 hours ago, Karl G said:

Or this one?  :D

 

5a4q3m.thumb.jpg.c062669cb806cf78d5c3983ff9911f0c.jpg

 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...