Atari 2600 Boulder Dash (R) Announced!

[mkiker2089]

Is it dead though? Can't we agree that a new game based on the engine would work well? We haven't even really scratched the surface on that idea.

 

The demo is there for people to taste the original then with a new game people could have a great cartridge release. Add it to the Atari Age store and all would be well.

[HatNJ]

Is it dead though? Can't we agree that a new game based on the engine would work well? We haven't even really scratched the surface on that idea.

 

The demo is there for people to taste the original then with a new game people could have a great cartridge release. Add it to the Atari Age store and all would be well.

 

Easier said than done

[Andromeda Stardust]

Is it dead though? Can't we agree that a new game based on the engine would work well? We haven't even really scratched the surface on that idea.

I wasn't referring to discussion of using the engine, but the whiners who want this rereleased. Begging for a second run like half of the posters in this thread are asking is basically akin to kicking a dead horse. Yes there's a demo available but it won't work on Harmony and it's only one eighth of the whole game. Using the display engine for another game like a Bomberman clone or something else would be awesome though. I hope the engine get recycled into new games. Boulderdash is still perhaps the most amazing homebrew to date as far as pushing what can be done on Atari hardware. More coders need to find creative ways to exploit the ARM coprocessor in homebrew games. The capabilities of the ARM processor make the 6507 look like a peanut, and pretty soon someone will figure out a way to bypass the 6507 entirely and control the TIA directly from the Melody board, either by "bus stuffing" or other means, and things we once thought were impossible will be child's play.

[Cambouis de l'Atari]

More coders need to find creative ways to exploit the ARM coprocessor in homebrew games. The capabilities of the ARM processor make the 6507 look like a peanut, and pretty soon someone will figure out a way to bypass the 6507 entirely and control the TIA directly from the Melody board, either by "bus stuffing" or other means, and things we once thought were impossible will be child's play.

 

Hi,

Just for my information, do you mean this is the case for Boulder Dash ? That this is not pure vcs coding, but uses a specific cartridge hardware ?

[+Andrew Davie]

 

Hi,

Just for my information, do you mean this is the case for Boulder Dash ? That this is not pure vcs coding, but uses a specific cartridge hardware ?

 

Boulder Dash is made from absolutely pure virgin peanut oil with no support whatsoever from the cartridge hardware.

All the cartridge does is implement the bankswitch scheme (which is also supported via Krokodile Cartridge), and provide a bit of RAM.

To be absolutely clear -- no ARM or any other coprocessor whatsoever. As far as peanuts go, it's a rather impressive one!

Pure 6507, my friends!

Cheers

A

[Cambouis de l'Atari]

Great, glad to read that

Thanks for your answer (and your talented programming) !

[Thomas Jentzsch]

Pure 6507, my friends!

I wonder if I should put that into my signature.

[Andromeda Stardust]

 

Boulder Dash is made from absolutely pure virgin peanut oil with no support whatsoever from the cartridge hardware.

All the cartridge does is implement the bankswitch scheme (which is also supported via Krokodile Cartridge), and provide a bit of RAM.

To be absolutely clear -- no ARM or any other coprocessor whatsoever. As far as peanuts go, it's a rather impressive one!

Pure 6507, my friends!

Cheers

A

Technically, the bank switching is not discrete. An ARM or some other microprocessor inside the melody board regulates the bankswitching, so technically, the bankswitch scheme is handled by a coprocessor. Boulderdash probably uses the most sophisticated bank-switching scheme of any Atari game ever made, so to say it's pure 6507 or even a vanilla read-based bankswitch scheme like the run of the mill 8, 16, or 32k carts, is a misnomer.

[Thomas Jentzsch]

Agreed, the bank switching is not original. And we are using Krokodile Cart or ARM logic. But only because it is there for free. The bank switching is simple enough to be done back then with discrete logic, it is just a slight variation of the Tigervision 3F bank switching.

 

The main difference is the extra RAM we use. It was definitely not available in 1977, but in the early 1980ies it became affordable.

[Andromeda Stardust]

Agreed, the bank switching is not original. And we are using Krokodile Cart or ARM logic. But only because it is there for free. The bank switching is simple enough to be done back then with discrete logic, it is just a slight variation of the Tigervision 3F bank switching.

 

The main difference is the extra RAM we use. It was definitely not available in 1977, but in the early 1980ies it became affordable.

Yeah kinda like the NES had 2kb of program RAM, but later NES carts had their own 8kb block of RAM. Nevermind Boulderdash expanded the TIA memory from 128 bytes to 16kb of on cart RAM. Geeze, really what is all that memory even used for? The 16k memory that Boulderdash uses is larger than the entire 6507 address space.

 

Imagine what today's disc games would be like if manufacturers just stuff some cell coprocessors and an extra Gig or two of RAM onto a game disc whenever the extra "boost" was needed?

 

Of course, that's why old school systems are so great (besides not having mechanical drives that fail or flash memory to get corrupted) - the cartridge ports allow endless hardware upgrades to the console!

Edited September 18, 2013 by stardust4ever

[Thomas Jentzsch]

Not all 16K RAM are used (8-10k IIRC). And from the used RAM a quite big part is "wasted" just because of the very limited bank switching. E.g. we have to copy some ROM data into RAM to be able to access it from RAM.

 

So with a more flexible bank switching I am sure we could get well below 8K.

[+Gemintronic]

I'm surprised Andrew Davies comment about the cart already being ripped didn't get any attention. Is there anything the community can do? I mean, any illegal copies are probably going to be targeted at us since we are the market for them.

[+FujiSkunk]

Imagine what today's disc games would be like if manufacturers just stuff some cell coprocessors and an extra Gig or two of RAM onto a game disc whenever the extra "boost" was needed?

 

It's called "cloud computing" and it's now a thing, particularly on the Xbone. At least that's what Microsoft wants you to believe.

 

I'm surprised Andrew Davies comment about the cart already being ripped didn't get any attention. Is there anything the community can do? I mean, any illegal copies are probably going to be targeted at us since we are the market for them.

 

Easy. Don't buy them. Report any attempts to sell them in places that don't allow that sort of thing, such as eBay.

[+Andrew Davie]

Geeze, really what is all that memory even used for? The 16k memory that Boulderdash uses is larger than the entire 6507 address space.

 

 

Each character-line of the display (21 scanlines deep) uses a single RAM bank. The RAM bank holds the 'bitmap' data for that line of screen; so, 6 bytes/line * 21 lines = 126 bytes. The character shapes are also stored in that RAM bank. Each character is 1 byte * 21 lines = 21 bytes. There are quite a few characters and animations thereof. And also, due to the mirrored nature of some playfield bytes the characters are stored in normal and mirrored form. I forget how many characters, but say 20... so that's 20 * 2 * 21 bytes for character shapes = roughly 800 bytes. In each bank (yes, they're duplicated across banks because there's no room in the fixed bank for them all). So that accounts for 800+126 bytes of RAM = 926 of the 1024. Then there's the actual draw code which places the bitmap onto the screen and switches to the next character line bank. That uses the rest of the bank. Each character line's RAM bank is therefore chokka. And there are 8 lines on the screen, so that's 8K right there. The other major RAM requirement is the board itself, holding the cave and telling us which character goes where. That's 40 x 22 or something like that. Say, 1K total. Add to that a few draw buffers for moving things about and figuring out which characters actually need to be drawn into the RAM banks and you add another 1K. So let's say about 10K used. Could be reduced significantly if the character shapes didn't have to be duplicated and live in the same bank as the draw code -- but that would require a different bankswitching scheme, which Thomas and I are contemplating anyway.

[+Andrew Davie]

Technically, the bank switching is not discrete. An ARM or some other microprocessor inside the melody board regulates the bankswitching, so technically, the bankswitch scheme is handled by a coprocessor. Boulderdash probably uses the most sophisticated bank-switching scheme of any Atari game ever made, so to say it's pure 6507 or even a vanilla read-based bankswitch scheme like the run of the mill 8, 16, or 32k carts, is a misnomer.

 

Totally disagree with the above opinion. The bankswitching is a fairly simple scheme, and is a variant of Tigervision 3F. The most sophisticated scheme I'm aware of is 4a50, and 3E is nothing even approcaing that in sophistication. All 3E involves is switching in 1K RAM or 2K ROM banks into a couple of different address spaces. That's it, full-stop. As to the ARM implementing the bankswitching - this is not a requirement of Boulder Dash, and the game will run on any cartridge that implements 3E bankswitching logic. This is simple enough to be done in discrete logic and does not require any sort of ARM or sophisticated chip. The ARM is *not* providing any coprocessing support to the game. Before you proclaim Boulder Dash to be using "the most sophisticated bank-switching scheme of any Atari game ever made", perhaps you should read about the 3E format.

[Andromeda Stardust]

 

It's called "cloud computing" and it's now a thing, particularly on the Xbone. At least that's what Microsoft wants you to believe.

 

Yes, but how are you going to play these games 20 years from now when the plug has long been pulled on the servers? Put the extra hardware into a cartridge and it will still be there for people to enjoy 30 years later. The Atari that existed in the 1980s is gone, but we are still making games for it. Nintendo discontinued support for the NES and SNES, but the games still work. With cloud computing, you are tethered to a network, whether by wires, fiber optic, or radio waves. People think the "cloud" is so wonderful because you can access data or resources from anywhere, but it is a mistake to think that "cloud" will remain or still be accessible 20 years from now. The very idea of "cloud" is that the data is like gas molecules in that they are everywhere, but gas will dissipate and eventually become lost to time with no former remnants left. With the inevitable death of physical media and endless product cycles, games of tomorrow will be vaporize and be lost forever, while their consoles will be useless e-junk to be buried in landfills or recycled into the new game consoles of "after tomorrow". Games are as much a part of pop culture as music and movies, but in the digital "cloud" era, there will be no ways to preserve these future "classics" which will be lost forever, yet antique dealers will continue to peddle old game carts from times long forgotten.

[+Gemintronic]

 

Each character-line of the display (21 scanlines deep) uses a single RAM bank. The RAM bank holds the 'bitmap' data for that line of screen; so, 6 bytes/line * 21 lines = 126 bytes. The character shapes are also stored in that RAM bank. Each character is 1 byte * 21 lines = 21 bytes. There are quite a few characters and animations thereof. And also, due to the mirrored nature of some playfield bytes the characters are stored in normal and mirrored form. I forget how many characters, but say 20... so that's 20 * 2 * 21 bytes for character shapes = roughly 800 bytes. In each bank (yes, they're duplicated across banks because there's no room in the fixed bank for them all). So that accounts for 800+126 bytes of RAM = 926 of the 1024. Then there's the actual draw code which places the bitmap onto the screen and switches to the next character line bank. That uses the rest of the bank. Each character line's RAM bank is therefore chokka. And there are 8 lines on the screen, so that's 8K right there. The other major RAM requirement is the board itself, holding the cave and telling us which character goes where. That's 40 x 22 or something like that. Say, 1K total. Add to that a few draw buffers for moving things about and figuring out which characters actually need to be drawn into the RAM banks and you add another 1K. So let's say about 10K used. Could be reduced significantly if the character shapes didn't have to be duplicated and live in the same bank as the draw code -- but that would require a different bankswitching scheme, which Thomas and I are contemplating anyway.

 

What about planning the next kernel around the Harmony boards? Your next game could be something along the lines of an Adventure Creator. People could supply their own levels with different tiles, layout and such on SD card.

[enthusi]

theloon, I dont see the point actually. Why not code for emulators alltogether then? Assume 'phosphor', harddrive and god-knows-what and there you go

[+Gemintronic]

theloon, I dont see the point actually. Why not code for emulators alltogether then? Assume 'phosphor', harddrive and god-knows-what and there you go

 

I think we might not be understanding eachother. Are you saying there's nothing fun about games like Adventure Creator, Pinball Construction Set, etc..?

 

I think having a harmony exclusive game would be wonderful. The advanced features (even if the ARM is just used for bankswitching) would complement the advanced kernels these guys come up with. I don't understand the correlation with sharing hand constructed levels via SD card and emulation either.

 

For example: if team Davie/Jentzsch made a Lode Runner type game next it would be rad to construct levels and then simply download them to a friends SD card and play at their house.

[enthusi]

There are funny games for C64, Atari XL, Amiga, PC, Playstation as well. They are just noch Atari 2600 games :-)

But this is a highly subjective point of view of mine and this here would be the wrong place to discuss it.

[Thomas Jentzsch]

 

What about planning the next kernel around the Harmony boards? Your next game could be something along the lines of an Adventure Creator. People could supply their own levels with different tiles, layout and such on SD card.

The idea is good, but I don't think Harmony can do that. At least not now.

[Thomas Jentzsch]

For example: if team Davie/Jentzsch made a Lode Runner type game next it would be rad to construct levels and then simply download them to a friends SD card and play at their house.

Even if we would do that game, who would do the construction kit?

[+Gemintronic]

Even if we would do that game, who would do the construction kit?

 

Either built-in like most "construction kit" games of the 80s or make the data format easy enough that someone on the PC side could make an editor around it. Even I could do that.

[Brian R.]

I don't know if any comments about begging and whining were directed at me among others. I only offered a comment, my thought.

 

I couldn't buy the game when it was available.

 

If it was available now, would I buy it? Maybe. The price was pretty high to me.

 

Is it a big deal to me that I can't buy it? Not really. I never had much attachment to this game. I just like having good new stuff to play on my Atari systems.

[+FujiSkunk]

Yes, but how are you going to play these games 20 years from now when the plug has long been pulled on the servers?

 

You won't.

 

The topic was how a modern disc-based systems can supplement the existing hardware. Cloud computing is the solution Microsoft has chosen to run with. What will happen when the network dies is an entirely different problem.