When would 32KB cartridges have first been feasible?

[Michael Malak]

Yesterday, John Hancock compared the 1983 Parker Brothers Q*Bert to the 2021 rubyQ. 

...wherein he states:

 

"it just shows just the capabilities of what the original 2600 was capable of"

 

But could have a 32KB cartridge have been made back in 1983?

 

According to a forum post, the first 32KB cartridge made by Atari itself was Fatal Run in 1989.

But could a 32KB cartridge have been made earlier than 1989?

 

One way to look at the cost is by considering the so-called "Special Edition" cartridges from 1979: Video Chess, Superman, etc. It is said "Special Edition" means it had 4KB ROM, as opposed to the earliest cartridges that were mostly 2KB. Looking for a price for a 2KB EPROM, the 2716, we see on page 291 of the October 1979 a price of $20. https://archive.org/details/byte-magazine-1979-10/page/n285/mode/2up Now, ROMs are cheaper than EPROMs. So the $40 retail price of a Video Chess cartridge just happens to correspond to the $40 retail price for a corresponding set of EPROMs (two such 2716 EPROMs would be needed to make 4KB). So probably the cost of parts was only $10 using ROMs, assuming a 4x ratio between BOM (bill of materials) and retail price. But it's convenient for our purposes that we have a 1:1 ratio between EPROM cost and cartridge retail price.

 

So the question becomes what would the price in 1983 be of a 27128 (16KB) EPROM? In the March 1983 issue of BYTE magazine, we see on page 526 the price is $26.95. https://archive.org/details/eu_BYTE-1983-03_OCR/page/n543/mode/2up We would need two such EPROMs, coming to $54. And using our 1:1 ratio of EPROM cost to cartridge retail price, a 32KB cartridge might have sold for $54 (which in today's dollars would be $160).

 

So was it technically feasible to produce a 32KB cartridge in 1983? Maybe. Would it have been profitable? Almost certainly not. We can conclude that it wasn't merely a matter of programmers being lazy or not creative enough to push the 2600 limits at that time.

 

[Thomas Jentzsch]

Lots of things which were far from being profitable were possible back then. IMO this is where to draw the line.

[+SpiceWare]

On 10/20/2022 at 8:00 AM, Michael Malak said:

But could have a 32KB cartridge have been made back in 1983?

 

I have quite a few 32K ROMs for ColecoVision from 1983, like Buck Rogers and Cosmic Crisis, so it could have been done.  The 2600 was probably not seen as being worth it at that time.

 

Ruby Q is using CDFJ though, so it is an ARM assisted game. Using something like the DPC coprocessor in 1984's Pitfall II would have likely made most of Ruby Q possible.

 

[Michael Malak]

28 minutes ago, SpiceWare said:

 

I have quite a few 32K ROMs for ColecoVision from 1983, like Buck Rogers and Cosmic Crisis, so it could have been done.  The 2600 was probably not seen as being worth it at that time.

 

Ruby Q is using CDFJ though, so it is an ARM assisted game. Using something like the DPC coprocessor in 1984's Pitfall II would have likely made most of Ruby Q possible.

 

Thanks for the tip about 32K ColecoVision cartridges.

 

But isn't CDFJ "just" bank-switching? Wasn't mere bank-switching simply accomplished back then with discrete logic chips? Isn't the ARM part of CDFJ simply because it emulates all the various bank-switching schemes from the various manufacturers?

[+Pat Brady]

56 minutes ago, SpiceWare said:

I have quite a few 32K ROMs for ColecoVision from 1983, like Buck Rogers and Cosmic Crisis, so it could have been done.  The 2600 was probably not seen as being worth it at that time.

 

Ruby Q is using CDFJ though, so it is an ARM assisted game. Using something like the DPC coprocessor in 1984's Pitfall II would have likely made most of Ruby Q possible.

 

To elaborate a bit, the question wasn't whether it was technically feasible, or even whether it was profitable. The question was whether management believed it would maximize profit. Parker Brothers Q*Bert is pretty good as-is, and I think it is extremely unlikely that any company's management would have approved a bigger ROM, or certainly any sort of coprocessor chip, at the time.

 

The people that did Q*Bert did a smashing job, given the 4K limit in addition to the 2600's inherent limitations.

 

25 minutes ago, Michael Malak said:

But isn't CDFJ "just" bank-switching? Wasn't mere bank-switching simply accomplished back then with discrete logic chips? Isn't the ARM part of CDFJ simply because it emulates all the various bank-switching schemes from the various manufacturers?

 

I think you're confusing Harmony with CDFJ. What you described (ARM emulates various bankswitching schemes) is what Harmony does. CDFJ lets the game use the ARM directly.

[+SpiceWare]

1 hour ago, Michael Malak said:

But isn't CDFJ "just" bank-switching?

 

No.  The Harmony Cart and Melody board, for stand-alone games, emulates all of the hardware inside a cartridge: the ROM, bank-switching hardware if beyond 4K of ROM, optional RAM, and the DPC coprocessor used in Pitfall II.

 

DPC supports a 10K game, with two 4K banks plus an additional 2K for graphics. The coprocessor allows the 6507 to quickly access the 2K graphics during the kernel, making it possible to update TIA more frequently on each scanline than can usually be done. This makes for more detailed graphics.

 

March 2010 I experimented with DPC sprites. Likewise @cd-w experimented with DPC Music. I approached the Harmony development group about using the extra resources to create Expanded DPC, basically increasing the number of banks and size of graphic data storage.

 

At the end of May 2010 we released DPC+, which went way beyond what I'd originally asked for.  One of the extras was the ability to run custom code on the ARM itself. 

 

With DPC+ the use of custom ARM code was optional.  We later tried writing a driver using BUS Stuffing, which yielded great results but didn't work on about 6% of the consoles.  

 

RPG Bus Stuffing demo

 

We took what we learned creating BUS Stuffing driver, and applied it to DPC+ and came up with CDF (later derivatives are CDFJ and CDFJ+).  CDF was first used for Draconian.

 

One of the key changes between DPC+ and CDF was custom ARM code is now required. This simplified the driver, shrinking it from DCP+'s 3K to 2K.  This is a double bonus for the game as that 1K of ROM savings is also 1K of RAM savings because the driver must be copied to, and run from RAM, for performance reasons.

[+SpiceWare]

2 minutes ago, Pat Brady said:

The question was whether management believed it would maximize profit.

 

I'm pretty sure I covered that with "The 2600 was probably not seen as being worth it at that time."

[+Pat Brady]

1 minute ago, SpiceWare said:

 

I'm pretty sure I covered that with "The 2600 was probably not seen as being worth it at that time."

Not sure this is worth debating, but I initially wrote my response (multiplexing with work) before I saw yours, then I updated it slightly when I saw your post and @Michael Malak's response.