Anyone think Ballblazer is possible on the 2600?

[GroovyBee]

No it only handles the bankswitching. It does not feed any instructions or whatsoever.

 

My mistake. I thought it was a "standard" Melody PCB.

[+SpiceWare]

Not that my opinion matters much but once it runs on ARM its not 2600 game/project IMHO.

I cringe whan I read about SRAM and 32 KB ROMS already. The only excuse I accept is BoulderDash

 

The techniques of putting extra ROM, RAM, and coprocessors in Atari cartridges were all developed back in the day. I don't know of anybody who considers those games to "not be Atari games". Harmony/Melody is just a continuation of that - instead of homebrew software, it's homebrew hardware . Other systems use it as well - the NES Mappers add the same types of abilities to their cartridges.

 

The various turn your Atari into a Computer options put extra CPUs in there as well. The Graduate system even uses a more advanced technique, bus stuffing, than we use with DPC+. Bus stuffing lets you update TIA registers in 3 cycles, in DPC+ it takes 5.

Edited January 7, 2013 by SpiceWare

[Thomas Jentzsch]

My mistake. I thought it was a "standard" Melody PCB.

It (almost) is, so it could do what you described. But it doesn't.

[GroovyBee]

So the there is an EPROM on the PCB as well as the ARM?

[Thomas Jentzsch]

So the there is an EPROM on the PCB as well as the ARM?

No idea. Did you mean that with "feeding the instructions"? Then I got you wrong.

[roland p]

You get less if you're using DPC+ as there's some overhead for the DPC+ driver. The 32K ROM is broken up like this:

3K - DPC+ driver

24K - 6507 accessible (6 banks)

4K - Display Data (data storage for graphics/etc, contents of which are only accessible to the 6507 via DPC+ data fetchers).

1K - Frequency Data. (can be used to store other ARM accessible data as well)

 

The 8K of RAM is broken up like this:

3K - DPC+ driver (copied over from ROM during boot, run from RAM for speed).

4K - Display Data (copied over from ROM during boot, contents can be changed at run time)

1K - Frequency Data - when using ARM code this changes to just 512 bytes, the later 512 bytes are used for C runtime variables.

 

 

 

 

My time's a little constrained, but if roland p's serious about this I'll see what I can do to come up with a "Hello World" this week. One thing that'll most likely change is your sprite data will be flipped, it's stored right-side-up when using DPC+ data fetchers.

 

Thanks,

 

I first want to tinker around with the non ARM version. When I'm serious about going the ARM route, I'll be happy with a hello world . By the way, the current kernel uses almost 24 Kb, I hope that's not a problem. I could imagine that all non-kernel code (the gamelogic) can be ARM code? So 6502 code is mostly used for visual things.

 

 

Not that my opinion matters much but once it runs on ARM its not 2600 game/project IMHO.

I cringe whan I read about SRAM and 32 KB ROMS already. The only excuse I accept is BoulderDash

True, but the SARA/Superchip is something that's used in original games too. Edit: I just saw Darrell eleborated post about this

Edited January 7, 2013 by roland p

[+SpiceWare]

Thanks,

 

I first want to tinker around with the non ARM version. When I'm serious about going the ARM route, I'll be happy with a hello world . By the way, the current kernel uses almost 24 Kb, I hope that's not a problem. I could imagine that all non-kernel code (the gamelogic) can be ARM code? So 6502 code is mostly used for visual things.

 

I'll hold off until later then to set up a Hello World project.

 

The ARM code seems to take up more space than 6507 code, but it does streamline the kernels. I tend to use bank 5 for 6507 code and banks 0-4 for the ARM code. The Melody board can have more resources if needed:

Melody boards can be built with a 128K Flash chip, replacing the Melody's standard 32K of Flash memory. And if 8K of RAM isn't enough for you, up to 64K of RAM can be added instead. This allows for a Melody board containing 128K of Flash memory and 64K of RAM. And if that's not enough, the Melody can be fitted with an optional EEPROM chip up to 4MB in size!

[GroovyBee]

No idea. Did you mean that with "feeding the instructions"? Then I got you wrong.

 

To be clear I meant that the ARM provides instructions and data for the 6507's address bus. Not "feeding" as in supplying a continuous stream of instructions or data regardless of 6507 address supplied.

[+Gemintronic]

Someone should break down and attach a Raspberry Pi to the 2600 for the ultimate Compumate!

 

In the meantime Ballblazer 2600 should be finished and solidcorp needs to start S.T.U.N. Runner 2600!

[enthusi]

As actually posted first, what matters is what rocks your boat

If ARM code motivates you, go for it! Its your baby anyway!

[djmips]

The techniques of putting extra ROM, RAM, and coprocessors in Atari cartridges were all developed back in the day. I don't know of anybody who considers those games to "not be Atari games". Harmony/Melody is just a continuation of that - instead of homebrew software, it's homebrew hardware . Other systems use it as well - the NES Mappers add the same types of abilities to their cartridges.

 

The various turn your Atari into a Computer options put extra CPUs in there as well. The Graduate system even uses a more advanced technique, bus stuffing, than we use with DPC+. Bus stuffing lets you update TIA registers in 3 cycles, in DPC+ it takes 5.

 

True all this is but the ARM is almost like alien sci fi tech that didn't exist back in the day. Maybe if you had a time machine. It is very cool and I love it but at the same time even you know that it isn't as pure as a 4K single bank game. From there you start to get foggier because even as soon as go to large ROM sizes you are starting to venture into uncommon (for a 2600 cart) areas. There is a dial and it's based on personal preferences but I say that the dial is at 0 for the 4K single bank game and then you could easily includes all the common banking schemes and extra RAM that was actually shipped in games in the original era. As far as the other end of the dial? Where does it stop... An ARM + FPGA? At some extreme point you slip into only using the 2600 for the joystick inputs and the video is coming directly out of a HDMI port on the cartridge...

[Keatah]

Then maybe we can play Doom as it was meant to be played!

[Thomas Jentzsch]

I think there is no objective answer to the question how long a game is a "true" Atari 2600 game.

 

A few people even have problems with bank switching, which didn't exist when the console was released. Others consider extra RAM to be not legit. Then there are some who draw the line between a small amount of extra RAM and a large one (with various definitions of small and large). Then there are some who argue that Pitfall 2 used a DPC, so using that one is legit too. And others say, if a DPC is legit, then other co-processors are legit too. And finally some say that anything that outputs graphics and sound via the TIA is a "true" Atari 2600 game (so besides that, anything goes).

 

Where you personally draw the line is pretty subjective. The lower you go, the more people will agree. The higher you go the more arguing will happen.

 

And for the developer, the various definitions provide different challenges.

Edited January 8, 2013 by Thomas Jentzsch

[Keatah]

The VCS has a cartridge port and two controller ports. These are meant to be used in whatever way we can. Co-processors, extra memory, HDD, quantum computing, if it fits in the cart its fair game. With the only requirement being that the 3 main chips are used in some capacity - otherwise you could effectively unplug the VCS and put it aside while you play with whatever it is you're playing with.

 

Nowhere in the original VCS specification does it say you can or can't use the slot for anything except a 4K ROM chip. Nowhere does it say you have to use period-style hardware of the era. To me, the ARM & other trick hardware is simply an expansion module. It's also curious to note that game systems with expansion slots didn't use them effectively. The 5200 had one and I don't recall anything connecting to it. Same thing with the Bally Astrocade. Rather the trend has been to stuff it all in the cart slot.

 

*Why not get a micro projector and put that in the cart? Then you'd have a videogame that doesn't require a TV set! The cart sits at a good angle, and high above the ground as it is. So it's in an optimal position.

 

*Why not do up FPGA that is good for processing 3D transformations? Program it on the fly as you progress through the game.

 

*What about a cart that has some form of wi-fi going?

 

*Perhaps a cart with infrared sensors. Or some sort of camera inside to do gesture or facial recognition or something.

 

My point being that there are endless possibilities. And I'm sure the original designers are quite amused at seeing what's being done today.

[roland p]

I started with 4K. A small but nice pseudo 3d checkerboard was possible. Then I started to use 32K so I could create a bigger checkerboard and speed up calculations by using square tables (they are 2K, for multiplications.).

 

The 32K constraint was set by the fact that it was easy to manufacture (PAL + 32K ROM).

 

Then the melody/harmony arived and made more RAM possible (by emulating Superchip). I made another kernel that used more RAM, and the checkerboard was even better (this is the current version).

 

By using a Melody it might even be possible (not high on my priority list) to create highres rotofoils if I could get the timing of HMOVE right...

 

Point is, extra resources are addictive.

 

 

 

I could make a 4K 2D Ballblazer to stay pure. But Ballblazer is 'high-tech', if it doesn't look cool it isn't ballblazer. The extra hardware (RAM, Melody board) suits ballblazer very good because it makes ballblazer look cooler, but it is less pure...

[Keatah]

I really don't give a frakking rat's ass about "purity" and all that shit. If you think you can make good use of extra resources, well then, use them! If you're really hamstrung over purity, well, just make two versions. But anyways..

 

Early ROM chips in 1978 were at X level of development. As time went on the bar was raised in density and die-size. They evolved and advanced. The same thing happens to most every bit of technology. Back then co-processors were limited I'm sure. And by today they have evolved. The Supercharger added some new things, DPC was added, more bank switch schemes came into play, bus stuffing. All sorts of things that the designers never intended happened. All sorts of non-purity things happened. And nowhere was a limit placed on how far one could go with advancing tech. And no-one complained then. Why bitch today? What's being done today with the 2600 and DPC/ARM is something I wished happened back on the Apple II. I so much wanted a cartridge slot for that system. But alas there was no interest.. And that's a topic for another thread.

 

The TIA and RIOT and CPU are still processing, making noise, drawing pictures, and inputting switch and joystick commands, talking to the cartridge slot.. It's still very much "VCS". We're still getting rock-solid framerates, and the same 1978 sound quality. Right?

 

I see no problem with you using extra memory and a co-processor. I'm here to play games, not count CPU cycles. And I tend to think of the Harmony and Melody board as a modern-day Supercharger. I've seen some pretty amazing stuff recently and I vote that developers continue the trend of doing cool things with better hardware. The level of detail and game rules and depth of content really shines when enhanced with modern hardware.

 

The old school way of doing things still exists for those that want this to travel that road, and you've mostly proven already that BB can be done. So why not go advanced? Why not enhance BB even further. Put smoke around the Rotofoil's ground hover mechanism. Use electric sparks to gussy-up the visuals. Make the 3D grid move up and down in areas, like real hilly terrain. Drop an obstacle here and there. Make vapor trails like LightCycles. Allow for rotation in the Rotofoils. Allow for grid tilting and shaking. Make a racecourse, with time trials, like a first-person MarbleMadness. Make a classic version like the original, and an enhanced version featuring my suggestions. Make good use of that game variation chart games were so "fond" of using back then. It's something we seem to have gotten away from these days. But hey! I ain't complain'n.

[Keatah]

Generally every game back then pushed the limits of the VCS 1 step at a time. Why shouldn't we continue that trend?

[raindog]

I look forward to Android2600 with its quad-core 2GHz ARM chip and flickery 160x200 display

 

But when it comes to "see? the Atari can do what more expensive consoles of the time could do", I prefer it to be using the kind of hardware available for the 2600 at the time. I'd be trying to jam it into 16k, maybe at most using the Harmony to do what the original DPC could do, but then, my own Ballblazer demo with its orthogonal grid and pre-calculated forward/back animations was really, really cheesy compared to what Roland has accomplished. Even then, I "calculated" them by doing renders in some 3D program of a grid at the appropriate perspective, scaling down to something like 160x60 and counting pixels. Even our write-test-debug loop is far tighter than just about any actual developer's back in the day. But even so, I can't help but think that if you somehow found a way to capture the video of a PS3 and bit-blast it into a 2600 game, you'd be playing a PS3, not a 2600.

 

It's like a guitarist who replicates a difficult classical piece by using modern recording technology to play it at half-speed and have it sound as though he played it at full speed. If it sounds as good, who cares if it couldn't have been done at the time? By and large, it's other guitarists and musical purists who see it as less of an accomplishment. Someone who just likes listening to music will just say "huh huh, that's pretty".

[Thomas Jentzsch]

Someone who just likes listening to music will just say "huh huh, that's pretty".

True. It depends on who you want to impress, the consumer (player/collector) or the producer (developer) side.

[GroovyBee]

At the end of the day it doesn't matter what anybody thinks apart from the game's developer. The developer is the one juggling their real life, family and hobby commitments to spend time on a project. Hobbies should always be fun. After all they are supposed to be a relaxing pastime. If fun means using the ARM in a Melody cart to offload work to, then so be it. If its use results in a good game that is all that matters at the end of the project. I'm pretty sure that if developers back in the heyday of the VCS could have added "coprocessors" to carts cheap enough for mass production they would have. All you have to do is look at what appeared in NES carts during its commercial lifetime for a potential comparison.

 

If you don't like the fact that somebody uses extra hardware or solved problems differently than you would have feel free to go off and code Ballblazer on the VCS setting whatever constraints you feel like. It worked for Star Castle . The more the merrier!

[Rybags]

Personally I think it'd be a great accomplishment if the game could be done with what would have been available in the day - the sole exception being bigger Ram/Rom space if required.

 

I'm a fan of accelerators and the like - being one of the few who've developed for VBXE on the computer is proof there.

 

A few sacrifices in quality or accuracy might be needed, but I think the satisfaction of having it on bare bones would be greater than relying on a coprocessor.

[RevEng]

True all this is but the ARM is almost like alien sci fi tech that didn't exist back in the day.

It depends on the scheme it implements. Stuff like custom bank-switching would have been possible back in the day. Even something like DPC+ would have been possible around the Pitfall 2 era. ARM just makes it affordable at hobby-production scales.

 

but at the same time even you know that it isn't as pure as a 4K single bank game...but I say that the dial is at 0 for the 4K single bank game and then you could easily includes all the common banking schemes

 

If we view "purity" as being akin to early 2600 games, I'd rank a single 4k bank game using modern techniques as a 5 on the scale.

 

0 would be a 2k game (like the original games) developed using only combat-era techniques (no illegal opcodes), without any info outside of the Stella guide, without using the Stella emulator or Harmony/Ram carts, and no borrowed code.

 

Even then, just knowing that certain techniques exist gives you a tremendous edge in implementing them, compared to the first devs who we base the purity scale on.

[raindog]

True all this is but the ARM is almost like alien sci fi tech that didn't exist back in the day. Maybe if you had a time machine.

 

Well, ARM chips (and micros based on them) were around years before Atari stopped releasing 2600 games. It's just that an ARM CPU cost far more than an Atari console, much less a cartridge.

 

Of course, the same could also have been said of the 6K of RAM in the Supercharger, or the DPC... in 1977.

 

I'll be happy to buy Ballblazer even on a Melody cart (or play the ROM on my Harmony). It'll be an amazing demo of the Atari for the rare occurrences that I have someone over who would understand what a big deal it is. But all this talk about it makes me wonder if my old "pre-render as much as I can" strategy would make a more smoothly-animated version of my original playfield-based demo workable as, say, a Supercharger game. It could never be as nice as Roland's, but it'd give the purists something to play.

Edited January 9, 2013 by raindog

[roland p]

A few sacrifices in quality or accuracy might be needed, but I think the satisfaction of having it on bare bones would be greater than relying on a coprocessor.

I think those sacrifices give a unique character to the game. Like the horizontal lines in the kernel. They are made in an as cheap as possible way, by just dividing a part of the rotofoils distance by 2, and again, and again, until you reach zero (at the horizon). I borrowed this from cd-w's Juno First, who got it from Supercat if I remember correctly. And I improved it, so it made a smoother movement up/down (it was too linear). Also the rest value is used for the antialiassing. Indeed these 'innovations' give satisfaction.

There are also other parts, like the scaling of the rotofoils, where just having different graphics of a rotofoil wins over trying to calculate it (the graphics are tweaked so they look good instead of having a correct size relative to the checkerboard).

[Keatah]

The greater the challenge the greater the reward as they say. I have to admit that "pure" games have an ineffable quality to them. Just "knowing" the 3-chips in the VCS are chomping at the bit adds a coolness factor missing from so many games made today.

 

Well I'm all for calculating and synthesizing images through procedures. You get unlimited sizes and they feel more life-like and alive as opposed to just blitting-in the correct size sprite. Procedural textures rock too.

Edited January 9, 2013 by Keatah