The Video Game Homebrew Crash of 2016

[+DrVenkman]

Well, in the immortal words of that great modern American poet T. Swift, "Haters gonna hate, hate, hate ..."

 

Me, I'm waiting on the boxed Space Rocks on the way from Al as we speak. Hope the fancy new-fangled ARM inside the case doesn't send me to GamerHell. Oops, too late. Already have a Harmony Cart.

[roland p]

Well, in the immortal words of that great modern American poet T. Swift, "Haters gonna hate, hate, hate ..."

 

Me, I'm waiting on the boxed Space Rocks on the way from Al as we speak. Hope the fancy new-fangled ARM inside the case doesn't send me to GamerHell. Oops, too late. Already have a Harmony Cart.

No one is going to hate. These are just personal preferences. Again, there is no right or wrong in this hobby, as long as others aren't hurt in the process Enjoy your game.

[Mr SQL]

Well, in the immortal words of that great modern American poet T. Swift, "Haters gonna hate, hate, hate ..."

 

Me, I'm waiting on the boxed Space Rocks on the way from Al as we speak. Hope the fancy new-fangled ARM inside the case doesn't send me to GamerHell. Oops, too late. Already have a Harmony Cart.

SpaceRocks is an incredible game, better even than the arcade version of Asteroids.

 

The game runs on the ARM and while that doesn't mean it's not an Atari game, the Video Game Critic has used it to set the bar for future reviews; he no longer considers 8-bit games and only wants to review 32-bit Atari ARM games.

 

Dave's definition of what constitutes an acceptable Atari game now excludes the 6502

 

The VGC isn't hating on the 6502, he's just jaded by the ARM chip; no doubt if he was as open minded as myself and the Atari Indie Pong Developer Challenge programmers who understand that just thinking Atari can make any game on any platform an Atari game he would only consider PS4 Atari games acceptable.

 

Someone will be along shortly to insist that Atari must only be on cartridges or set equally ridiculous qualifications that can apply ownly to their own perspectives.

 

Collector perspectives are perhaps among the most interesting on what constitutes an Atari game because a rock taped to the inside of a sealed box sitting on a shelf may receive greater merit as an Atari game; they're not hating either, that's pure love of collecting.

 

And Collecting, is also an Atari game if you want it to be

[Keatah]

I really don't give a rat's ass what processor VCS games run on. *I* run all of them through emulation on an i7. So the point is moot!!!!!

 

 

And Collecting, is also an Atari game if you want it to be

 

Maybe someone will make a game about collecting games? There could be thrift shops and proto labs to enter and exit like a room in Adventure. Other evil collectors. Regular retail shops. Random bonus auctions where you buy and sell. And retail outfits like GameGo.

 

Hidden easter eggs like AirRaid or any other artificially inflated game. Even a game within a game like some sort of speed run where you have to catch carts like bombs in kaboom. And let's not forget the Elusive Emulator that gives you special powers.

 

Then you have evil parents and burglars and acts of nature that destroy your collection. Or simply random and rare electronic failures that remove an item.

 

And a doodle mode like in I Robot, except instead of free drawing with polygon shapes, you re-arrange shelves and CRT's and consoles.

 

And an educational level where you are taught how to collect both in the game and real life.

 

Naturally this would come in a limited edition, with gold foil tips on a 200 page instruction book that can be a real (or fake) rarity guide and tip book.

 

It c

Edited January 8, 2016 by Keatah

[Thomas Jentzsch]

The game runs on the ARM and while that doesn't mean it's not an Atari game, the Video Game Critic has used it to set the bar for future reviews; he no longer considers 8-bit games and only wants to review 32-bit Atari ARM games.

 

Dave's definition of what constitutes an acceptable Atari game now excludes the 6502

 

The VGC isn't hating on the 6502, he's just jaded by the ARM chip; no doubt if he was as open minded as myself and the Atari Indie Pong Developer Challenge programmers who understand that just thinking Atari can make any game on any platform an Atari game he would only consider PS4 Atari games acceptable.

Where did he say so?

[Thomas Jentzsch]

Personally, I prefer the more pragmatic one where we say "We can all agree that X is, Y isn't, and everything in between is a matter for discussion."

Hm, even that might be not so easy. Some people will not accept anything beyond the original specs of the first run of cartridges (2K!) and some people may even consider a game which mimics the Atari 2600 on a PC an "Atari" game.

[maiki]

Those DPC+ games always make me think what a great modern retro console the Harmony Cartridge might be if it had its own joystick, power and AV socket. I mean the potential is certainly there.

[Thomas Jentzsch]

You still would need e.g. video and sound chips. And then you would have something pretty similar to a Raspberry Pi.

[roland p]

Those DPC+ games always make me think what a great modern retro console the Harmony Cartridge might be if it had its own joystick, power and AV socket. I mean the potential is certainly there.

This could be the hardware of the Coleco Chameleon!

[Mr SQL]

Where did he say so?

 

When I sent him KC Monster Maze to review - Dave liked the gameplay action but wanted me to add option menus and bells and whistle polish like SpaceRocks, and explained SpaceRocks had set the bar for what kind of games could be achieved on the Atari and going forward he would only review games like that or just give bad reviews.

 

He made a good point about the number of low quality Atari games he recieved to review, but didn't take into account memory (6K vs big memory) or CPU (6502 vs ARM) while unknowingly using those same attributes to set the bar for all Atari games.

 

I was glad to see Dave compare the gameplay in KCMM to an ARM game, but did not wish to expand it with big memory to add features; the label on the side of the game says it all:

 

Some draw imaginary lines in the sand where video-out in the cart or some other factor means it's not an Atari game but these viewpoints are as equally arbitrary as the VGC's view that new Atari games must have big memory and run on the ARM; you could trick him though with BoulderDash

[Thomas Jentzsch]

I don't think an ARM game is required to meet Dave's standards. Or a even a larger ROM and RAM game like Boulder Dash.

 

I am pretty sure a well executed 4K game (like the 1980s classics) will still get his attention. If not, someone should explain him the difference.

[Mr SQL]

I don't think an ARM game is required to meet Dave's standards. Or a even a larger ROM and RAM game like Boulder Dash.

 

I am pretty sure a well executed 4K game (like the 1980s classics) will still get his attention. If not, someone should explain him the difference.

I did try to explain it and Dave to his credit encouraged me to start a thread on his forum, however it's difficult to dissuade someone from their opinion when it's as valid as anyone elses.

 

Some emphatically state that adding a modern processor is no different than adding a contemporary co-processor bitd and some draw imaginary lines in the sand.

 

I like to draw real lines in the sand and play hop-scotch.

 

Do you imagine you can convince any of us otherwise?

[+SpiceWare]

And yet he's still reviewing 2600 games (Bridge and Xevious back in November). Did your interaction with Dave result in a vendetta against DPC+ w/ARM? It sure seems like it.

 

Based on prior comments, such as these, you don't understand what's involved with DPC+ w/ARM:

 

To many programmers Atari games are written in 8-bit code - 6502 Assembly or vintage BASIC while ARM games are written in 32-bit code which is generally C or C++. And not only is the 6502 bypassed but largely so is the TIA a la bus stuffing.

 

Your technical example is flawed; the ARM is driving the TIA and enslaving the 6502 which literally just runs a program to follow the ARM's instructions; it is only that program that need by cycle aware - the ARM doesn't generally have to race the beam and runs 1,000 times faster than the 6502 (relatively, pay no attention to the clock speed).

The 6507 is not bypassed, it's the only thing that can update TIA. There's no bus stuffing involved with DPC+. The ARM is not generating 6507 code on the fly. In all of my DPC+ ARM games the program flow is controlled by the 6507 - it tells the ARM code what functions to run, not the other way around.

With DPC+ w/ARM games code is written for the 6507, as well as for the ARM, and done in such a way that they work together. Its a lot to wrap your head around, which is probably why until recently nobody else has done it. And John needed my help to get started, which is why I began this blog series.

[Andromeda Stardust]

First sensible post for this thread in a while Spicewire.

 

If you could somehow separate the display kernel from game logic, the 6507 still drives the display but the ARM handles logic. The ARM cannot generate any output without the executive function of the 6507.

 

 

= = = = = = =

 

 

Back to the Model T analogy, the car itself hasn't changed. The VCS is the model T, the player is the driver, and the game is the road. Back in 19-whatevers most roads consisted of dirt or gravel. Asphalt or cement was a luxury not afforded back then. So the games of 70s and 80s had a roughfeel to them. You could feel it in the rickety suspension. The ARM is built like the autobahn. So smooth, with banked turns. To be fair, you'll get more mileage out of the model T driving on paved roads rather than the dirt and gravel of yesteryear. You won't hit speed or handling of 100+ like with modern sprotscars (PS2 generation and up), but the ride will improve considerably.

 

I see it in the level of refinement of new homebrews, not all of which use the ARM assist. Some are nothing more than 128 bytes memory with a lot of 4kbyte pages swappable in ROM.

[+KaeruYojimbo]

 

When I sent him KC Monster Maze to review - Dave liked the gameplay action but wanted me to add option menus and bells and whistle polish like SpaceRocks, and explained SpaceRocks had set the bar for what kind of games could be achieved on the Atari and going forward he would only review games like that or just give bad reviews.

 

If he was being serious, that's just another reason not to give any of his reviews any credence.

 

The obvious result of this will be a homebrew market flooded with ARM games, leading to the ARM crash of 2017.

 

As for a Model T still being a model T, just like this, it depends on who you ask. There are car guys who insist that a classic car be as close to original as possible and there are car guys who live to tinker, modify and improve. The thing is that people have been modifying cars as long as there have been cars. Is a car hot-rodded in the 1930's more of a Model T than one modified today? Where do you draw the line?

 

If the car (or game) is a museum piece, there to preserve the history of the way things were, then it makes sense to keep it original. If it's going to be driven (played), then it makes sense to go beyond original and make something the best it can be.

 

Collecting, whatever it is, is fun for different people for different reasons, and there's room for everyone. Just don't get mad at me when I remove the seal and actually play my games and we'll be fine.

[+Propane13]

Re: Video Game Critic, I have mixed feelings.

I was disappointed that he didn't like Mean Santa. If I remember right, I got a D+.

 

The game is not perfect, I know that, but the constraints were tough-- make a game with some levels for kids, and some for adults.

If he just played on the kids levels, they were probably boring. If he tried the harder ones though-- they're pretty brutal (in a fun way). At the end of a game, even I'm sweating trying to make it to the end on just 6 lives. It's even more difficult if you realize that beating levels within certain times unlock other more levels that are even tougher. There were a few other reviews that felt that way, whereas a bunch played the Easy mode only and thought it was awful. If you gave it a cursory glance, the game may have seemed unpolished, but I tried to spice it up a bit from the inside.

 

At the time, the graphics at the time were the best that I could do, and cart size was limited to 8K with no extra hardware. And, I'll grant again that it's not perfect, but I was proud of it. I worry now that if the bar is going to be set that high, it'll just discourage new programmers who are using the base hardware and raw assembly programming, which is a challenge all to itself. I'm not bad at 6502 assembly programming, so why force me to be an expert at C (i.e. ARM programming)? Why force everyone to have to be at this level in order to be well-received? If the bar is set to a level I can't ever achieve, I wonder... why bother?

 

-John

[BigO]

You can make a car go around a track faster by modifying the car.

You can make a car go around a track faster by putting a better driver behind the wheel.

The co-processor games are just a more skilled driver for the same car.

[+Propane13]

Not sure I buy that argument 100%. Extra time for computation is fine, and can make for better gameplay. But, if the extra hardware allows you to be able to do things on-screen that you legitimately cannot do in regular hardware, then it's different. I really have a problem if people are saying that the default behavior that was available is now not acceptable enough.

 

-John

[Thomas Jentzsch]

You can make a car go around a track faster by modifying the car.

You can make a car go around a track faster by putting a better driver behind the wheel.

I prefer to be the better driver, who needs no car modifications.

[+SpiceWare]

First sensible post for this thread in a while Spicewire.

I wouldn't call it the first sensible post. I have no problem with someone wanting to draw real lines in the sand that are different than mine; just believe they should use real information, not invalid assumptions, when deciding where those lines should be drawn.

[Mr SQL]

And yet he's still reviewing 2600 games (Bridge and Xevious back in November). Did your interaction with Dave result in a vendetta against DPC+ w/ARM? It sure seems like it.

 

Based on prior comments, such as these, you don't understand what's involved with DPC+ w/ARM:

The 6507 is not bypassed, it's the only thing that can update TIA. There's no bus stuffing involved with DPC+. The ARM is not generating 6507 code on the fly. In all of my DPC+ ARM games the program flow is controlled by the 6507 - it tells the ARM code what functions to run, not the other way around.

 

With DPC+ w/ARM games code is written for the 6507, as well as for the ARM, and done in such a way that they work together. Its a lot to wrap your head around, which is probably why until recently nobody else has done it. And John needed my help to get started, which is why I began this blog series.

 

Spice don't take any of this too seriously, AtariAge itself is a big RPG and of course, an Atari RPG which makes it a lot of fun

 

"In all of my DPC+ ARM games the program flow is controlled by the 6507"

 

Well, you previously explained to me the game logic is running all on the ARM which is the other way around; the game loop is always the program, and the rest is just the framework or subsystems.

 

And the TIA cannot be driven to output the volume of content you are displaying in SpaceRocks by the 6502 - only the ARM can do that by using the 6502 as a dumb terminal to pump the TIA since the 6502 can't move that fast; you've changed the rules the way Neo moves in the Matrix!

 

SpaceRocks and Draconian are 32-bit games that could not be done as easily with the 6502; there's no viable C compiler to use because the 6502 can't handle bloated slow compiled C well at 1 mhz.

 

Your games are awesome and I really like playing them on Harmony - controlling the TIA with the ARM still gives the games the Atari feel, a lot more of it actually. I should try building one too, it definitely looks tremendous fun but standard 6502 games are at a distinct disadvantage when the end user cannot tell the difference which we clearly see with both the VGC and some of the opinions here:

 

IMO It's interesting to see different approaches on development and the different viewpoints on this thread; ideas to the effect that a PS2 on the Atari is like the SuperCharger, that anything goes, that video-out is bad/good and that StarDust is probably ready to put an ARM processor board into an Altair so that you can build Altair games for him

[BigO]

Not sure I buy that argument 100%. Extra time for computation is fine, and can make for better gameplay. But, if the extra hardware allows you to be able to do things on-screen that you legitimately cannot do in regular hardware, then it's different. I really have a problem if people are saying that the default behavior that was available is now not acceptable enough.

 

-John

I wasn't directly responding to your post, btw. I was just weighing in on the car analogy and in my mind was just drawing a line between modifying the console or not modifying the console. I had already started writing a post when yours came in.

 

On the subject of co-processor vs. not: I respect the achievements of both categories.

[+SpiceWare]

"In all of my DPC+ ARM games the program flow is controlled by the 6507"

 

Well, you previously explained to me the game logic is running all on the ARM which is the other way around; the game loop is always the program, and the rest is just the framework or subsystems.

 

The game logic is run on the ARM, but when that logic runs (the program flow) is controlled by the 6507. From Part 8 of that blog series:

 

The code has been revised so the 6507 can now request specific functions for the ARM code to run:

• Initialize() - Run when Atari is first powered up.
• Overscan() - Run during the game screen's overscan. Will eventually update the game state (player movement, sound effects, etc).
• VerticalBlank() - Run during the game screen's vertical blank. Will eventually update the datastreams used to draw the game screen.
• MenuOverscan() - Run during the menu screen's overscan. Will eventually use the joystick to update the options (players 1 or 2; TV Type of NTSC, PAL or SECAM; etc).
• MenuVerticalBlank() - Run during the menu screen's vertical blank. Will eventually manipulate the menu's datastreams in order to display the selected options.

And the TIA cannot be driven to output the volume of content you are displaying in SpaceRocks by the 6502 - only the ARM can do that by using the 6502 as a dumb terminal to pump the TIA since the 6502 can't move that fast; you've changed the rules the way Neo moves in the Matrix!

A ROM could be built to display a screen full of objects like seen in Space Rocks or Draconian, they'd just be stationary as there wouldn't be enough time left over to move anything. That's where the ARM comes in as a coprocessor, it manipulates the data fast enough that such a display becomes useful.

 

Your games are awesome and I really like playing them on Harmony

Thanks.

 

standard 6502 games are at a distinct disadvantage when the end user cannot tell the difference which we clearly see with both the VGC and some of the opinions here:

There's a long history of using coprocessors in game cartridges to achieve results that aren't possible with the stock hardware. It probably starting with Pitfall II and its DPC chip. The NES saw a number of different coprocessors with varying capabilities which resulted in improved sound and/or graphics. The SNES had them. Apparently Virtua Racing is the only Genesis cartridge to use one, the Sega Virtua Processor which rendered polygons in real time.

[+Propane13]

I wasn't directly responding to your post, btw. I was just weighing in on the car analogy and in my mind was just drawing a line between modifying the console or not modifying the console. I had already started writing a post when yours came in.

 

On the subject of co-processor vs. not: I respect the achievements of both categories.

 

Cool beans. Thanks for clarifying!

 

-John

[Mr SQL]

 

 

The game logic is run on the ARM, but when that logic runs (the program flow) is controlled by the 6507. From Part 8 of that blog series:

 

The code has been revised so the 6507 can now request specific functions for the ARM code to run:

• Initialize() - Run when Atari is first powered up.
• Overscan() - Run during the game screen's overscan. Will eventually update the game state (player movement, sound effects, etc).
• VerticalBlank() - Run during the game screen's vertical blank. Will eventually update the datastreams used to draw the game screen.
• MenuOverscan() - Run during the menu screen's overscan. Will eventually use the joystick to update the options (players 1 or 2; TV Type of NTSC, PAL or SECAM; etc).
• MenuVerticalBlank() - Run during the menu screen's vertical blank. Will eventually manipulate the menu's datastreams in order to display the selected options.

A ROM could be built to display a screen full of objects like seen in Space Rocks or Draconian, they'd just be stationary as there wouldn't be enough time left over to move anything. That's where the ARM comes in as a coprocessor, it manipulates the data fast enough that such a display becomes useful.

 

Thanks.

 

 

There's a long history of using coprocessors in game cartridges to achieve results that aren't possible with the stock hardware. It probably starting with Pitfall II and its DPC chip. The NES saw a number of different coprocessors with varying capabilities which resulted in improved sound and/or graphics. The SNES had them. Apparently Virtua Racing is the only Genesis cartridge to use one, the Sega Virtua Processor which rendered polygons in real time.

 

 

 

Yes but even the SVP for Virtua Racing realistically shared the load with the powerhouse 68000 (the 680X0 series later got dubbed "mainframe on a chip" for good reason). But the 1 mhz 6502 coupled with a 100 mhz 32-bit ARM gets driven like a dumb terminal by the ARM as you described above:

 

The "static display" running on the 6502 comprises the dumb terminal, the ARM animates it thus it drives everything. It is running the game logic and pushing all the data.