Ex-Activision Designers Launch Retro Game Publisher Audacity Games™

[+DrVenkman]

21 minutes ago, batari said:

Come on now, at least post the namesake cart for this:

I’m somewhat embarrassed to admit it, but I don’t actually own a copy of that one. ? 

[fiddlepaddle]

Well, that was fun...

I just dug up my cart and played Plaque Attack. Must've played it when I first got it, maybe 2004, but I don't remember. Good game, actually.

Edit: PS. I guess getting older has its advantages: as your mind goes, game novelty improves.

Edited March 17, 2021 by fiddlepaddle

[Mr SQL]

22 hours ago, AtariLeaf said:

Exactly but if I'm being honest, audacity has a way to go to beat Champ or spiceware for the best homebrew games ?

It's generally Apples to Oranges comparing 8-bit games to 32-bit games, even 4K games compared to 16K games with the same processor are a different paradigm. 

 

When an 8-bit game does compare to a 32-bit game through innovation the reviewer just holds up signs  

 

I think it might be more sensible to put signs on the 32-bit releases indicating they are "32-bit productions on 8-bit hardware". 

 

[+TwentySixHundred]

38 minutes ago, Mr SQL said:

It's generally Apples to Oranges comparing 8-bit games to 32-bit games, even 4K games compared to 16K games with the same processor are a different paradigm. 

 

When an 8-bit game does compare to a 32-bit game through innovation the reviewer just holds up signs  

 

I think it might be more sensible to put signs on the 32-bit releases indicating they are "32-bit productions on 8-bit hardware". 

 

I don't know if you can really call them 32-bit games when the same code needs to run through an 8-bit BUS. Im not exactly sure how CDFJ works however from my understanding i always assumed it would pre-calculate instruction code, to then be executed by the 6507. I always looked at it like prepping food before cooking, it just makes the actual cook/throw together time quicker. Although the stove top and time in the pan is still running the same heat.

 

AFAIK there is no way to directly bypass the 6507's BUS and tap directly into the TIA. Probably why BUS stuffing gets attention and desired. Although i could be completely wrong about this... So from what i have been told about bit architecture of computers, is the systems bits are usually determined by the BUS rather than how many bits the CPU may have. Basically why the Genesis is classed an 16-bit system even though it uses the debatable 68000.

Edited March 17, 2021 by TwentySixHundred

[+splendidnut]

1 hour ago, Mr SQL said:

It's generally Apples to Oranges comparing 8-bit games to 32-bit games, even 4K games compared to 16K games with the same processor are a different paradigm. 

 

When an 8-bit game does compare to a 32-bit game through innovation the reviewer just holds up signs  

 

I think it might be more sensible to put signs on the 32-bit releases indicating they are "32-bit productions on 8-bit hardware". 

 

Running old DOS 16-bit games on a 386 (32-bit processor), does not magically make those games 32-bit.

 

So, some of that depends on whether the games/releases use 32-bit instructions or not.  Ex:  Chaotic Grill uses DPC+, but only for the extra RAM accessed via data fetchers and fast-fetch mode.  Outside of that, it's purely running with just 8-bit 6502 code (display kernel AND game logic).

 

Also, I believe any DPC+ games that utilize ARM code can only utilize the Thumb (16-bit) instructions due to a bug/design flaw.  I believe I heard this has since been corrected with the CDF, CDFJ drivers.   BUT, that would make any DPC+ game only technically 16-bit, if that.  Sorry, that was based on my faulty knowledge...so it's been struck out.

 

Are we really going to have this discussion AGAIN on how to DIVIDE up the community into little niches of games based on specs?

 

OR can we ALL agree to enjoy these games that we like for what they are?

[Mr SQL]

23 minutes ago, TwentySixHundred said:

I don't know if you can really call them 32-bit games when the same code needs to run through an 8-bit BUS. Im not exactly sure how CDFJ works however from my understanding i always assumed it would pre-calculate instruction code, to then be executed by the 6507. I always looked at it like prepping food before cooking, it just makes the actual cook/throw together time quicker. Although the stove top and time in the pan is still running the same heat.

 

AFAIK there is no way to directly bypass the 6507's BUS and tap directly into the TIA. Probably why BUS stuffing gets attention and desired. Although i could be completely wrong about this... So from what i have been told about bit architecture of computers, is the systems bits are usually determined by the BUS rather than how many bits the CPU may have. Basically why the Genesis is classed an 16-bit system even though it uses the debatable 68000.

It's independent of the bus architecture, a modern processor takes this even further by providing onboard RAM that allows us to run the games right on the CPU. 

 

There are ways to directly bypass the 6507's BUS and the rest of the hardware to tap directly into the TIA through clever programming; this technique is one example.

 

1 minute ago, splendidnut said:

 

OR can we ALL agree to enjoy these games that we like for what they are?

 

If the games run on the CPU they are 32-bit so a sign would be helpful; I think signs on games are cool just not on people  

 

 

[+splendidnut]

3 minutes ago, Mr SQL said:

 

If the games run on the CPU they are 32-bit so a sign would be helpful; I think signs on games are cool just not on people  

So you don't like T-shirts with words on them?  Or name tags?

[Thomas Jentzsch]

19 minutes ago, splendidnut said:

Also, I believe any DPC+ games that utilize ARM code can only utilize the Thumb (16-bit) instructions due to a bug/design flaw.  I believe I heard this has since been corrected with the CDF, CDFJ drivers.   BUT, that would make any DPC+ game only technically 16-bit, if that.

Thumb instructions are 16 bit, but they process 32 bit data.

[+splendidnut]

2 minutes ago, Thomas Jentzsch said:

Thumb instructions are 16 bit, but they process 32 bit data.

Ah.  Crap.  Now I remember the previous discussion on this.  I've edited my previous post.

[Mr SQL]

1 hour ago, splendidnut said:

So you don't like T-shirts with words on them?  Or name tags?

Sure  

 

Edited March 17, 2021 by Mr SQL
Which T-shirt do you prefer?

[Crazy Climber]

21 hours ago, Jstick said:

Champ games & Spiceware are mainly doing ports of well-loved classic games, whereas Audacity seems to be continuing the Activision philosophy of original games tailored to the platform.  Both of these approaches are valid, and in my opinion necessary for keeping the 2600 scene alive.

 

The Champ / Spiceware stuff is totally fantastic, but I'm also looking forward to seeing more unique AAA games for the 2600.

True, but I "think" I remember seeing a little blurb about Champ games making a sports/baseball game. "Champ Games baseball?" Can't remember, it was awhile ago and not sure if it's still a thing...but that would be a unique non-port if I'm not mistaken. Champ is definitely "slaying it" with the arcade ports though, wizard of wor blew my mind. Really looking forward to Zoo Keeper and Robotron (Robot war?)

[+johnnywc]

32 minutes ago, Crazy Climber said:

True, but I "think" I remember seeing a little blurb about Champ games making a sports/baseball game. "Champ Games baseball?" Can't remember, it was awhile ago and not sure if it's still a thing...but that would be a unique non-port if I'm not mistaken.

You are correct, the game is called Champ Sports Baseball and it's an original title (well, as original as you can get since baseball has been around for 150 years or so  ).  We also have numerous other original games that we are considering (including some other sports games depending on how CS Baseball is received).  

32 minutes ago, Crazy Climber said:

Champ is definitely "slaying it" with the arcade ports though, wizard of wor blew my mind. Really looking forward to Zoo Keeper and Robotron (Robot war?)

Thanks!  Robotron has gone through a few name changes, and last fall we decided on RobotWar:2684.  David Exton is working on the artwork (manual/label/box) and we are planning on releasing it sometime in May.

[+Andrew Davie]

2 hours ago, TwentySixHundred said:

I don't know if you can really call them 32-bit games when the same code needs to run through an 8-bit BUS. Im not exactly sure how CDFJ works however from my understanding i always assumed it would pre-calculate instruction code, to then be executed by the 6507. I always looked at it like prepping food before cooking, it just makes the actual cook/throw together time quicker. Although the stove top and time in the pan is still running the same heat.

 

AFAIK there is no way to directly bypass the 6507's BUS and tap directly into the TIA. Probably why BUS stuffing gets attention and desired. Although i could be completely wrong about this... So from what i have been told about bit architecture of computers, is the systems bits are usually determined by the BUS rather than how many bits the CPU may have. Basically why the Genesis is classed an 16-bit system even though it uses the debatable 68000.

Last time I commented on this I got some fundamentals wrong. So I hope my factual errors below are corrected quickly by anyone who knows better.

My view on this is that the ARM co-processor, if you want to call it that, is mostly tightly coupled to servicing the address bus and making sure the data bus contains the correct data based on what the address bus is "looking at".  In current implementations, this is performed in a tight loop on the ARM that doesn't really leave a lot of cycles to do anything else. There's some room - not a lot. You don't benefit here from any extra ARM'ness.

But separate to that is the bankswitching scheme actually being used; and CDFJ (which I now have had minimal experience with) provides some "assists" to the 6507 via "data streams" which effectively feed data onto the data bus that is accessible via the quickest-possible 6502 addressing mode (lda #) which takes 2 cycles. It opens up methods for writing TIA registers (via lda/sta pairs) which are able to move "larger" amounts of data more quickly to the TIA without requiring indexed or indirect addressing modes. Typically, in 5 cycles (lda #/sta) instead of worst-case 10 cycles (lda (zp),y/iny/sta). These streams, as I think of them, are useful for writing sprite and playfield data, for example, and somewhat transmogrify kernel writing. You get to do more stuff on a scanline, for instance, than you could dynamically do in other bankswitching schemes. They can remove the need for managing indexes, and mitigate issues of accessing blocks of data in accessible banks. But "assist" it's not something that hasn't been done before (DPC, for example).
In my use-case (where I tried a ChronoColour(TM) Chessboard display engine), I was able to use an idle part of the screen (the 6507 was in the vertical blank and thus not needing to service the address/data bus) to draw an entire screen of data in about 22 scanlines (which were all blank anyway).  When you use the ARM like this, it is no longer servicing the address bus, so the 6507 still goes about its stuff -- fetching an instruction, executing it, moving on to the next address while the ARM is busy doing your "super stuff". If you're not servicing the bus via the ARM (in that tight loop) then the 6507 gets whatever data is already on the bus, and treats that as an instruction. So, the trick (so far) seems to be to put a "nop" on the data bus, so that the 6507 will execute a (long) sequence of NOP instructions while the data bus is not being serviced by the ARM, meanwhile incrementing the PC counter while it's doing so. And you hope that it doesn't wander into an area where the address points to hardware on the '2600 itself (i.e., TIA, PIA, RIOT) which could/would change the data bus and thus ruin that EA (NOP) on the bus for the idle time. It's a glorious hack, but works.  When you've finished your ARM subroutine, then you "hook back in" to the bus-servicing phase, gently redirect the 6507 back to "normal operations" and continue on your merry way.

In this way you can get the full power of the ARM to work on something processor-intensive - albeit for a short number of scanlines. And your 6507 is (effectively) blinded, so it does not really do anything of significance while your ARM code is running. It's clever, but very limited in how much time you have available. I had enough to draw an entire playfield chessboard, as I noted, every single frame. I was able, for example, to go from drawing one square per frame (6507 version) to 64 squares (the entire board) every frame. This in turn allowed me to change and simplify the data format of the pieces, and the logic needed to draw them, which in turn improved the speed. But this doesn't mean that the ARM version is 64 times quicker; it just means that using the ARM this way allowed me to modify the way the system worked, and get consequent improvements in speed. Used like this, the whole thing is like a toggle - 6507 *or* ARM, not both. But again, the 6507 must either be running code from RAM (and not accessing addresses requiring the ARM's support) or in that NOP idle state for this to work.

I think the recent ARM-based games are remarkable. They show just what the TIA can do. There is still considerable skill required to make something that works - yet alone something that looks good. For example, many of the ARM games use sophisticated sprite multiplexing algorithms/engines to get HEAPS of stuff on the screen at the same time. It requires skill to program. Comparing these things is what I so dislike about where we're at now. A 4K game has its own unique challenges, and limitations. An ARM-supported CDFJ game has its own unique challenges. It is possible to produce fantastic games with either. But comparing one to the other and saying one is the "best" is basically misunderstanding (in my view, at least - and I've been bitten by my views on this) the very nature of what they are. You can do a lot more (dynamically) with an ARM bankswitch scheme such as CDFJ than you can with plain 4K. You can do a lot more with a non-ARM bankswitch scheme such as 3E+ than you can with plain 4K, too. Comparing them is pointless and in my world "unfair" to the developers. I refuse to be a part of it.
I am against any sort of push to label games with some sort of "32-bit" or "unassisted" or whatever. They are all '2600 games and all require skill to develop. If any good has come out of this whole Audacity thing, it is perhaps that good game design seems to be more the discussion point than the bankswitching scheme used. Even so, we're still seeing ridiculous comments with people still insisting on using terms like "best game ever", "best graphics", "best Atari programmers", etc. I think most people aren't going to be aware or care about any of this.
Anyone who finishes a game no matter what the medium (from bBasic to ARM-based) is a winner in my book. I consider programming a game an artistic endeavour, more than a technical one. To me, categorising and claiming one is the "best game", for example, is like comparing two great artists to decide who was the "best".  Do you try to level the playfield when making that judgement by deciding who had the better quality canvas, paints and paintbrushes? No. There's just no way to compare; they are both great artists who must be evaluated in their own context.
Unfortunately, some great artists never sell a painting in their entire lifetime - and some get rich selling stuff based on who they are.

 

 

 

 

 

 

[+sramirez2008]

Its all about the gameplay.  My most recent AA Store order includes Dare Devil and Zoo Keeper, but also Avalanche (4K) and Robot City (4K) because of their gameplay. Last year @Karl Gdecided to make a 2K version of his 32K game 'Space Game'.  I liked the 2K version so much that I asked for permission to have a cart made.  Gameplay.  I thank all of you for continuing to allow your creativity to birth so many great games. 

[+TwentySixHundred]

Thanks @Andrew Davie for clearing up the technical side of how ARM chip works, in an easy to understand way. Makes a lot more sense now as i had no idea about "blinding" the 6507 along with many other technicalities you pointed out. Very impressive stuff indeed and i fully agree with your last statement about categorizing the art form we all enjoy as developers. Really couldn't have said it any better, as we all have limitations and hurdles to overcome, no matter what artistic endeavor we choose. To say one is better then the other is ridiculous imo. I guess most GP just see the final product and judge based off what they see rather then actually understanding the inner workings or methods used. Probably the most well written comment of this entire thread to be honest ?

Edited March 17, 2021 by TwentySixHundred

[+SpiceWare]

4 hours ago, TwentySixHundred said:

i always assumed it would pre-calculate instruction code, to then be executed by the 6507.

 

With DPC+* and CDFJ the ARM chip is used to calculate data that is saved into RAM. The RAM is divided up into data streams. These data streams are used for many things, such as one of them might hold the ~200 bytes of graphics that will be put into the GRP0 register(player0, or sprite0 in modern nomenclature) on every scanline. Part 2 of the CDFJ tutorial covers Data Streams.

 

The 6507 instructions are prewritten by the programmer.

* custom ARM code is actually optional for DPC+. Chaotic Grill uses DPC+, but updates all the data streams using 6507 code, not ARM code.

 

3 hours ago, splendidnut said:

ARM code can only utilize the Thumb (16-bit) instructions due to a bug/design flaw.

 

It's done by design - 16-bit instructions take up half the space of 32 bit instructions, which is crucial when you have limited ROM space. As Thomas mentions, they still process 32 bit data - in fact, they're converted to the equivalent 32 bit instruction to be executed, from Introduction to ARM thumb:

 

Quote

At this point, you may ask why have two instruction sets in the same CPU? But really the ARM contains only one instruction set: the 32-bit set. When it's operating in the Thumb state, the processor simply expands the smaller shorthand instructions fetched from memory into their 32-bit equivalents.

 

The difference between two equivalent instructions lies in how the instructions are fetched and interpreted prior to execution, not in how they function. Since the expansion from 16-bit to 32-bit instruction is accomplished via dedicated hardware within the chip, it doesn't slow execution even a bit. But the narrower 16-bit instructions do offer memory advantages.

 

1 hour ago, Andrew Davie said:

My view on this is that the ARM co-processor...

 

You got it! ?

[Mr SQL]

12 minutes ago, TwentySixHundred said:

Thanks @Andrew Davie for clearing up the technical side of how ARM assist works, in an easy to understand way. Makes a lot more sense now as i had no idea about "blinding" the 6507 along with many other technicalities you pointed out. Very impressive stuff indeed and i fully agree with your last statement about categorizing the art form we all enjoy as developers. Really couldn't have said it any better, as we all have limitations and hurdles to overcome, no matter what artistic endeavor we choose. To say one is better then the other is ridiculous imo. I guess most GP just see the final product and judge based off what they see rather then actually understanding the inner workings or methods used. Probably the most well written comment of this entire thread to be honest ?

X2 @Andrew Davie's description is excellent but it sounds like a description of a category to avoid comparing them.

 

The example I posted was from SuperCharger BASIC which has a different design goal than batari BASIC in that it's not meant to be a stepping stone to Assembly.

 

With this BASIC you can "blind the 6507" as described for multiple frames or via Display Lists like the Atari 400/800.

 

 Even a script kittens can make awesome modular games like the Activision OG's

or scrolling games like the ARM chip and demo scene.

 

[+TwentySixHundred]

The thing about bB is it's easy to throw a sprite on the screen and move it around. Not so easy to make something fun, which i think goes in conjunction to what Andrew was saying. The limitations of the system itself and bB has limitations of it's own that become apparent very quickly. So there still is a lot of thought process and strategy in game design. Isn't that the underlining factor that comes into play? We are all artist just using different methods to paint the picture. Some more advanced then others however if the gameplay is lacking then all the fancy technology means nothing right? That's why i agree, labeling a game 32bit, CDFJ, DPC+, SuperBank, Superchager BASIC or even bB is irrelevant.

Edited March 17, 2021 by TwentySixHundred

[fultonbot]

11 hours ago, fiddlepaddle said:

Well, that was fun...

I just dug up my cart and played Plaque Attack. Must've played it when I first got it, maybe 2004, but I don't remember. Good game, actually.

Edit: PS. I guess getting older has its advantages: as your mind goes, game novelty improves.

Too true.

[fultonbot]

21 minutes ago, TwentySixHundred said:

The thing about bB is it's easy to throw a sprite on the screen and move it around. Not so easy to make something fun, which i think goes in conjunction to what Andrew was saying. The limitations of the system itself and bB has limitations of it's own that become apparent very quickly. So there still is a lot of thought process and strategy in game design. Isn't that the underlining factor that comes into play? We are all artist just using different methods to paint the picture. Some more advanced then others however if the gameplay is lacking then all the fancy technology means nothing right? That's why i agree, labeling a game 32bit, CDFJ, DPC+, SuperBank, Superchager BASIC or even bB is irrelevant.

It totally agree with this as I see tools like bAtari and 7800 Basic and democratizers of creativity.  However, I'm sure there are people who just want to see/prove technical feats of strength, and that's fine too.   

[Mr SQL]

11 minutes ago, TwentySixHundred said:

The thing about bB is it's easy to throw a sprite on the screen and move it around. Not so easy to make something fun, which i think goes in conjunction to what Andrew was saying. The limitations of the system itself and bB has limitations of it's own that become apparent very quickly. So there still is a lot of thought process and strategy in game design. Isn't that the underlining factor that comes into play? We are all artist just using different methods to paint the picture. Some more advanced then others however if the gameplay is lacking then all the fancy technology means nothing right? 

^Agree with this

21 minutes ago, TwentySixHundred said:

That's why i agree, labeling a game 32bit, CDFJ, DPC+, SuperBank, Superchager BASIC or even bB is irrelevant.

 

7 minutes ago, fultonbot said:

It totally agree with this as I see tools like bAtari and 7800 Basic and democratizers of creativity.  However, I'm sure there are people who just want to see/prove technical feats of strength, and that's fine too.   

 

^Disagree with the last sentence only as I designed SuperCharger BASIC to be very abstract for Script Kittens  

 

The idea is the opposite @fultonbot 

Because how else could we tell artists what the tools can do? Activision was clear they write their own exclusive OG tools so we don't know what their kit is like.

 

I had an interesting discussion with @batari on the homebrew development forum regarding the creation of a new mode of "codeless programming tools" for everyone. 

 

SuperCharger BASIC has a codeless mode where everybody is an Artist and everyone is a programmer even the Idea Guy in this special mode you can create AUDIO VISUALS on the Atari even if you think you don't know how to code.

 

This mode is interesting, leveraging hidden coding talents non programmers have, and I think we may see some incredibly talented artists harness this mode with raw talent that inspires other programmers at different levels, including even the ARM chip artists!     

 

[+splendidnut]

I think Mr SQL is broken.  He's not making a lot of sense. Could somebody fix him? 

 

[Mr SQL]

2 minutes ago, splendidnut said:

I think Mr SQL is broken.  He's not making a lot of sense. Could somebody fix him? 

 

The idea is everyone can be an artist, I designed a development tool around that idea. I think you're idea is to throw insults at me for labeling the development tool, correct?  

[+splendidnut]

3 hours ago, Andrew Davie said:

I think the recent ARM-based games are remarkable. They show just what the TIA can do. There is still considerable skill required to make something that works - yet alone something that looks good. For example, many of the ARM games use sophisticated sprite multiplexing algorithms/engines to get HEAPS of stuff on the screen at the same time. It requires skill to program. Comparing these things is what I so dislike about where we're at now. A 4K game has its own unique challenges, and limitations. An ARM-supported CDFJ game has its own unique challenges. It is possible to produce fantastic games with either. But comparing one to the other and saying one is the "best" is basically misunderstanding (in my view, at least - and I've been bitten by my views on this) the very nature of what they are. You can do a lot more (dynamically) with an ARM bankswitch scheme such as CDFJ than you can with plain 4K. You can do a lot more with a non-ARM bankswitch scheme such as 3E+ than you can with plain 4K, too. Comparing them is pointless and in my world "unfair" to the developers. I refuse to be a part of it.
I am against any sort of push to label games with some sort of "32-bit" or "unassisted" or whatever. They are all '2600 games and all require skill to develop. If any good has come out of this whole Audacity thing, it is perhaps that good game design seems to be more the discussion point than the bankswitching scheme used. Even so, we're still seeing ridiculous comments with people still insisting on using terms like "best game ever", "best graphics", "best Atari programmers", etc. I think most people aren't going to be aware or care about any of this.
Anyone who finishes a game no matter what the medium (from bBasic to ARM-based) is a winner in my book. I consider programming a game an artistic endeavour, more than a technical one. To me, categorising and claiming one is the "best game", for example, is like comparing two great artists to decide who was the "best".  Do you try to level the playfield when making that judgement by deciding who had the better quality canvas, paints and paintbrushes? No. There's just no way to compare; they are both great artists who must be evaluated in their own context.
Unfortunately, some great artists never sell a painting in their entire lifetime - and some get rich selling stuff based on who they are.

 

Well said Andrew!

[+splendidnut]

Just now, Mr SQL said:

The idea is everyone can be an artist, I designed a development tool around that idea. I think you're idea is to throw insults at me for labeling the development tool, correct?  

Insult?  What insult?   Aren't we just joking around?  Or do I need to apologize for hurting your feelings?