Extremely large games

[MayDay]

I've been thinking about the HomeStar RPG game that Paul is working on. Back in the day, they put the 32 in 1 on a 64K cartridge. I've noticed that 32K is the largest boards being sold now, so what is the largest game a homebrew author could go about making and still make cartridges for at a reasonable cost (say, $50 or under)? Could enough of a rarity 3 cartridge (32 in 1) be scavenged to produce a limited release, and would this work? What is the largest cartridge game that could be made at a more unreasonable cost (say up to 100, 150 bucks)? How much could a supercharger tape hold? I believe it holds more ROM space, but does that come at the cost of anything else? What is Paul's plan when he finishes his game?

 

Thanks for any help in this matter.

 

-JD

[vdub_bobby]

AFIAK, the HS RPG was planned for a 64K cart.

 

An SC tape can be as big as you want; but the actual SC only holds 6K at a time, you can have multiple loads for bigger total space.

 

You might look at the specs for the Krocodile cart for more info about giant 2600 games; I think that supports some huge binaries.

[Albert]

AFIAK, the HS RPG was planned for a 64K cart. 

1002113[/snapback]

Yes, this is correct, and we have a 64K board design (and some prototypes) but never put them into production since Homestar Runner RPG went into limbo.

 

..Al

[vdub_bobby]

AFIAK, the HS RPG was planned for a 64K cart. 

1002113[/snapback]

Yes, this is correct, and we have a 64K board design (and some prototypes) but never put them into production since Homestar Runner RPG went into limbo.

 

..Al

1002123[/snapback]

Hmmm...now that's very interesting. What was planned for the retail price of a 64K cart? And would you put them into production if someone wrote a game for them?

[Bruce Tomlin]

I'm looking at a schematic I made for the current board, and the bad news is that GAL outputs were used as inputs, so there aren't any outputs left. And there are two unused inputs. I suppose it's possible to rewire a Pixels Past bankswitch board to hook up pin 1 on the EPROM to a GAL output. With a 22V10 chip, it would only need one wire, to GAL pin 14. Sticking with a 20V8 would need either A8, A9, or A11 to be wired to GAL pin 11 so as to free up an output. So cut one or two traces, add one or two wires, and come up with a new set of equations for a GAL.

 

And then of course you'd have to decide what select addresses to use for the eight new banks. This is why the 3E style bank switching is popular for large carts, because there's only one select address to worry about, and you use the data bits to select banks.

[supercat]

And then of course you'd have to decide what select addresses to use for the eight new banks.  This is why the 3E style bank switching is popular for large carts, because there's only one select address to worry about, and you use the data bits to select banks.

1002148[/snapback]

 

The 3E bankswitching style is the only one, other than the Supercharger my own 4A50, which supports >2K of RAM. That might have something to do with its popularity. Otherwise, though, I don't really care for it; it is not well-designed at all from a programming standpoint.

 

If one didn't care about matching existing bankswitch methods, one could forgo many of the address pins on the GAL and make any address of the form $08xx trigger a bank switch (to the address specified in A0-A3). Using this approach, it would probably be possible to adapt the existing cart design to even bigger EPROMs, though one would have to flying-lead the VDD supply as well as the new address pins.

 

BTW, I think an 8K cart could be constructed using just the EPROM and two 7400's if $08xx were used for bank switching. Wonder why nobody did it?

[Bruce Tomlin]

BTW, I think an 8K cart could be constructed using just the EPROM and two 7400's if $08xx were used for bank switching.  Wonder why nobody did it?

Because nobody ever thought of it, duh. :-)

 

Almost everybody used Atari's 1FF8/1FF9 switching, with exceptions of companies that had been making games for a while. Activision had their own method which they only used for two games before using the Atari switching, Parker Brothers and M Network did quite well with their own, and Tigervision came up with their own for a couple of games.

 

So basically, the companies with resources to come up with their own did so, and the rest did it Atari's way. They could probably get a chip with Atari bank switching as a "standard" option from the ROM fabs.

[+batari]

BTW, I think an 8K cart could be constructed using just the EPROM and two 7400's if $08xx were used for bank switching.  Wonder why nobody did it?

1002221[/snapback]

I've seen an F8 circuit with two chips, if I remember right. There was a 74133, and I can't recall the other chip - could have been a 7400, but that doesn't seem to fit - I wonder if a 7428 (quad 2-in NOR) would work?

 

I recall that two gates from the other chip were tied together to make an SR latch. Another must have been to invert A12, and the last gate must have combined A1 and A2 before feeding into the 74133.

 

It could have been a NAND gate I suppose, but I can't see how this could work (one gate short, by my analysis.) It might have been another chip. Either way, I do remember the SR latch made with two gates.

Edited January 18, 2006 by batari

[supercat]

BTW, I think an 8K cart could be constructed using just the EPROM and two 7400's if $08xx were used for bank switching.  Wonder why nobody did it?

1002221[/snapback]

I've seen an F8 circuit with two chips, if I remember right.

1002258[/snapback]

 

I'd be curious to see such a design. The $080x bankswitching would fit very nicely in two 7400's, which were about the cheapest chips one could buy. Some other chips were more expensive; don't know about the '133.

 

BTW, the $080x bankswitching could also be done with four transistors, about ten resistors, and two caps. Or add another transistor or two and reduce the number of passives.

 

I think the minimum number of transistors for a bankswitching cart that uses no chips other than the ROM is two, but that design is so nasty anyone proposing actually using it in a production cart would have to be admitted to the loony bin.

[+batari]

BTW, I think an 8K cart could be constructed using just the EPROM and two 7400's if $08xx were used for bank switching.  Wonder why nobody did it?

1002221[/snapback]

I've seen an F8 circuit with two chips, if I remember right.

1002258[/snapback]

 

I'd be curious to see such a design. The $080x bankswitching would fit very nicely in two 7400's, which were about the cheapest chips one could buy. Some other chips were more expensive; don't know about the '133.

 

BTW, the $080x bankswitching could also be done with four transistors, about ten resistors, and two caps. Or add another transistor or two and reduce the number of passives.

 

I think the minimum number of transistors for a bankswitching cart that uses no chips other than the ROM is two, but that design is so nasty anyone proposing actually using it in a production cart would have to be admitted to the loony bin.

1002318[/snapback]

I've been searching AA, [stella] and the USENET, but I can't find it.

 

I did some more thinking, and I think it can be done with a 74133 and a 7428, two diodes, a resistor and a capacitor. I don't remember seeing these extra components (except for the cap) but then again, my memory is very fuzzy.

[Tom]

You mean probably this design:

 

http://www94.pair.com/jsoper/bankswitch_f8.html

[Kroko]

And then of course you'd have to decide what select addresses to use for the eight new banks.

1002148[/snapback]

For 64K Atari style bankswitching, the hotspots have already been defined. They are $1FE0 - $1FEF. Thats why Paul (or somebody else ?) called it EF Bankswitching. I think Alberts prototypes use the same hotspots, or ?

[fabventure2600]

Ive been talking about with one guy that lives in my town(Vila Velha,Brazil),he is a Atari Enthusiast and Eletronic technician,and he stores 512 games banked in one cartridge,He says that is 2mB storage,that is correct?is it possible?

 

This is not a Mock,see it:

http://www.tabajara-labs.com.br/multicarts/2600.htm

[supercat]

Ive been talking about with one guy that lives in my town(Vila Velha,Brazil),he is a Atari Enthusiast and Eletronic technician,and he stores 512 games banked in one cartridge,He says that is 2mB storage,that is correct?is it possible?

1002781[/snapback]

 

Sure. Using DIP switches it's pretty trivial, but IMHO rather ugly. Who wants to try to search for their favorite game using DIP switches? It's also limited to 4K game carts; a lot of good games were 8K.

 

A much nicer approach would probably be to make a couple mods, including the addition of whatever the 74LS273 with inverted outputs is, along with three resistors and three caps, to an 8K banked cart. This would allow the use of a menu to select among about 125 8K carts and 256 4K carts (375 games). Additionally, a push button could be added to allow a return to the main menu without power-cycling the unit.

 

In case anyone finds the idea intriguing, here's how I'd do it:

 

The /reset input of the latch would have a resistor to VDD and cap to ground, to ensure a clean reset on powerup. The data inputs of the latch would connect to the data bus, and the address outputs would connect to 8 address pins on the ROM device.

 

The A12 input of the bank-switch logic would be disconnected from A12 and wired, via resistor, to the most significant bit output of the latch; it would also have a cap to ground. The RC time constant should be about 20us-1ms.

 

The output of the bank-switch logic would be connected to the input of the latch through a resistor; the latch input would also be tied to ground. This RC time constant should be about 400ns, but may depend upon the prop delay of the bank-switch circuitry.

 

An alternative implementation, if the bank-switch logic happens to generate a high-going pulse somewhere for any $1FF8/$1FF9 access, would be to feed that to the input of the latch (still using an RC circuit). In this case, the RC circuit feeding the A12 input could be eliminated.

 

The memory space would be divided into 256 pairs of 4K banks. The first 128 pairs would hold 256 4K-bankswitched games; once one of these was selected, further bankswitching would be disabled.

 

Otherwise, any access to $xFF9 when the first bank of a pair was selected would select the second bank AND cause 255 minus the value on the data bus to be latched into the big bank latch. To avoid an errant bank-switch, the ROM value at $1FF9 within each bank should be 255 minus the bank number (most games don't care what's put there, so making that be so shouldn't be a problem).

 

The last pair of banks would have to be largely filled with a "capture pattern". Not sure what exactly would be best, but it should be a harmless opcode with bit 4 set.

 

The menu program would switch to a game by being in the first bank of a pair and doing a store to $0FF9. If the desired game is a 4K cart that's in the first bank of its pair, that would be followed immediately by a store to $0FF8.

 

All nice and easy.

[supercat]

You mean probably this design:

http://www94.pair.com/jsoper/bankswitch_f8.html

1002379[/snapback]

 

That's three chips plus the ROM. I was wondering if it could be done in two common-in-the-80's chips and a ROM. I offered an alternative to F8 bankswitching which could be done with two 7400's (most dirtball TTL logic chip on the planet) but I don't know if F8 can be done in two chips.

[fabventure2600]

So,is this a possibility for us,play real Blockbuster Homebrews for new cartridges?

 

that´s what ill hope to see,and play of course,

 

i think Atari could pass thru a New era,and entire game with MBs?(who knows,Dragon´s Lair?,or Another World port?)

[fabventure2600]

The big trouble is........Bankswitch modules....separated.........

 

a lot of bankswitch........

[brpocock]

The big trouble is........Bankswitch modules....separated.........

 

a lot of bankswitch........

1008400[/snapback]

 

Yeah, there is. But not as much as you might think.

 

Since the game lends itself to having several discrete screens: conversation, combat, travel (map view), attraction, stats, save/load game, &c. -- the major screens each get their own bank(s). Major meaning "requires tons of data" -- e.g. travel views require fast access to map data, tile data (what colour is it? is it a wall? does it trigger a script to step here?), and tile bitmaps, which collectively suck down a lot of ROM space. Likewise, the script engine needs access to script data as well as string tables (for displaying conversations) and font bitmaps. Combat engine needs monster stats and bitmaps as well as scenery bitmap data.

 

The minor screens get packed in where they fit: the attraction sequence, the player stats, the new game, enter code/load game, get code/save game, and so forth.

 

The downside is that some code has to be duplicated in multiple banks, giving a painfully large overhead. Every bank containing travel (map) data, for example, needs a copy of the travel kernel. There's no way I can see to bankswitch fast enough and often enough to fetch data for multiple tiles per row, and no way to cache enough of it in 128B of RAM that has to be shared with player stats, game progress flags, and other "persistent" data.

 

In a perfect universe where one could bankswitch 1k or 2k boundaries a more complex set-up with the kernel code packed into a certain 1k bank and the other 3k switched might work, but it's an edge case for custom elecronics for a niche product as it is. Plus, the emulators would hate it. No need to introduce that much complexity, it's complex enough as it is.

 

Incidentally, the various kernels all share an overlapped area of RAM that's wiped by a common bankswitching subroutine. To go to another map or run a certain script or enter a certain combat mode, the registers get loaded with a bank ID and a "function ID" and the program does a

jmp bank_switch

. The identified bank gets swapped in and a common entry point there reads the function ID, which might select a map, a combat set-up, a script ID, or a specific screen (attraction, stats, ...) depending on which bank is selected. It's kinda like how CP/M & DOS use their registers to select a subfunction in INT handlers, if that makes sense to anyone. The shared RAM area gets zeroed during the switch (which happens during vblank interval) and in some cases (short scripts) a second switch could happen almost immediately, without the player seeing anything at all. (e.g. -- map triggers script which jumps to other map, say, a "tunnel" or similar ... the switch, script execution, switch again all happens during vblank so all player sees is map A in one refresh and map B in another.)

 

So, from a certain perspective, the "64k game" will really only have like 48k or so of unique data, with some of the code ... and even some data (e.g. player bitmaps) duplicated in multiple banks just to avoid bankswitching too often.

[Tom]

In a perfect universe where one could bankswitch 1k or 2k boundaries a more complex set-up with the kernel code packed into a certain 1k bank and the other 3k switched might work, but it's an edge case for custom elecronics for a niche product as it is.

 

There were commercial games that used such bankswitching schemes.

 

Plus, the emulators would hate it. No need to introduce that much complexity, it's complex enough as it is.

 

Nonsense. Last time I checked the z26 source looked as if it was fairly trivial to add new bankswitching schemes.