56 replies to this topic

[matthew180]

Well, with all the talk lately of the old "super cart" and the VIC20's "mega cart", on top of my involvement with the latest batch of 64K boards, I've been giving serious thought to designing an updated version of such a cart for the 99/4A.

The super cart seems to have coupled an 8K RAM at the cart address with the E/A's GROM, so you could load the RAM with a program and run it. Plus is was battery backed, so you could essentially make your own carts without the need to have or burn EPROMs or other programmable chips.

This is pretty cool, but it has a few draw backs:

1. You can't bank switch. Currently our bank switching technique is triggered by the write-enable (we*) signal, but when you are using a RAM you need to have the we* work like normal.

2. Your programs have to run from disk or from the 8K RAM itself.


The VIC20 Mega Cart looks pretty neat and couples a few things together. It has all the VIC20 carts in ROM and you can select them. It also offers extra RAM which uses a nonvolatile SRAM (nvSRAM) which removes the need for a battery backup and still allows the RAM to survive when power is removed. This is pretty cool!


My initial thoughts were more in the area of the 99/4A's old super cart, but add some bank switching, plus the nvSRAM like the Mega Cart is using, as well as a programmable GROM to provide the original E/A code, or our own new loader and such. I was not initially thinking of trying to offer a cart that would cram all the existing 99/4A carts into one mega-cart, but maybe that *is* what people want (hence the discussion here.)

Ultimately I'd also like to work in some sort of USB interface or miniSD card options so the cart could be loaded / programmed from a PC (personal computer, not necessarily a *Windows* "PC"). At this point the cart would enter the realm of a mega-cart I suppose. Maybe you put this cart into the 99/4A and leave it there, then instead of changing "cartridges" you would change miniSD cards.

Keep in mind however, I'm *not* talking about making this like a disk subsystem. The cartridge address space needs to function like a memory, i.e. RAM or ROM, and thus needs to respond in the time-frame of a real memory IC, which is about 200ns or faster. However, there could be some sort of process that copies data from USB or miniSD into a real RAM or something like that. These are some of the details I'd like to kick around here.

The other problem to hash out would be how to bank-switch RAM. The cart port has two CRU lines, so I was thinking that maybe use a CRU trigger to enable bank-switching vs. normal write operations, or something like that. There could also be something like a specific "write sequence" to a particular address to get different functionality. Anything is possible.

Thoughts, comments, questions, concerns?

Matthew

[InsaneMultitasker]

Maybe the new cart could grab a CRU line or two from the cassette port for control purposes.

[adamantyr]

A fantastic idea, Matt! That would really open up possibilities for development in a cartridge format. I'd totally buy in on one.

You should investigate the old Superspace II cartridge, which provided up to 4 banks of 8k bank-switched RAM. I believe they did the bank-switching as one of the following:
- The first address in the RAM space (>6000) contained the active page, and writing to that address would trigger a bank-switch
- The first four address spaces were used to track each individual page

From a personal standpoint, I'd really prefer the first technique.

I don't own one of these, so I don't know for certain how it worked. They're hard to procure these days; I've been keeping an eye on eBay for over a year with no luck.

Adamantyr

[Opry99er]

This is the closest thing ive seen to a large super-multi-cart is this thing Jon built and I bought as a prototype. 512k of 8K games. Not RAM though and it's not re-loadable. It's an EPROM which tursi added his multicart software to. I'm proud to own it, anyway.

[matthew180]

adamantyr, on Mon Sep 20, 2010 3:48 PM, said:

- The first address in the RAM space (>6000) contained the active page, and writing to that address would trigger a bank-switch
- The first four address spaces were used to track each individual page

From a personal standpoint, I'd really prefer the first technique.

The problem with either of these is, how would you "write" data to address >6000 (or the other 3 address)? A cartridge needs to contain a standard header to show up in the 99/4A menu...

I suppose if everyone conceded that address >6000 would *always* return a value of 0xAA then the first technique could work. However, that would make the cart incompatible with existing bank switching code that expects to write to a specific address to get a bank, i.e. >6000 selects bank 0, >6002 selects bank 1, >6004 selects bank 2, etc.

Some sort of compatibility would be required I think. That or a few "modes" that determine what kind of bank switching technique should be used.

Matthew

[adamantyr]

matthew180, on Mon Sep 20, 2010 4:16 PM, said:

The problem with either of these is, how would you "write" data to address >6000 (or the other 3 address)? A cartridge needs to contain a standard header to show up in the 99/4A menu...

I suppose if everyone conceded that address >6000 would *always* return a value of 0xAA then the first technique could work. However, that would make the cart incompatible with existing bank switching code that expects to write to a specific address to get a bank, i.e. >6000 selects bank 0, >6002 selects bank 1, >6004 selects bank 2, etc.

Some sort of compatibility would be required I think. That or a few "modes" that determine what kind of bank switching technique should be used.

Well, the best starting point would be to look at how other cartridges handled it. Extended BASIC has two 8k pages. The Asgard Super XB3 cartridge had four 8k pages. And the Superspace II cart did something...

How did Jon squeeze 512k, or 64 pages, into his cart I wonder? 128 bytes of header dedicated solely to that?

Adamantyr

[matthew180]

Well, the XB cart and the 64K board are designed for *ROM*. They use the write-enable signal to trigger the bank-switch. The Super Cart was totally RAM and did not bank switch. I'll have to see what the Super Cart II did.

Matthew

[Opry99er]

Hey Adam... It's (4) 64k banks. Big freakin EPROMs. At least that's how I understand it. So--- if you're interested in Jon's method, check out www.hexbus.com. He caralogues it there. But again, it's all ROM

[matthew180]

I could not find any info on the SuperSpace II cartridge other than descriptions of what it was, (E/A GROM with 32K battery backed RAM.) Since I could not find any pictures, I have to believe the bank switching was via manual external switches like the project on the MainByte project page:

http://www.mainbyte....cart_4bank.html

Can anyone confirm if the original SuperSpace II cart used switches, or if it actually had a scheme to bank-switch the RAM?

Matthew

[retroclouds]

Interesting stuff

I actually see 2 different projects here:

1) A mega-cart (perhaps with SD-card or USB interface).
Perhaps something similar to the "Ultimate SD" http://www.atarimax..../documentation/
or 128-in-1 FLASH Multi-Cart http://www.atarimax..../documentation/

2) A low-cost PCB for a bank-switched card having some additional RAM (1K - 4K), suited for
selling in homebrew games. Dunno how important GROM support would be.
Would be cool if it had some GROM header so that it could run on V2.2 consoles.

On a sidenote, I still have my first alpha of "Time Pilot" sitting around.
But I stopped development due to several reasons. One of them is because it should run on a TI-99/4A
without 32K memory expansion. For doing this in a decent quality, 256 bytes of scratch-pad are just not enough.

So, I'm really hoping both projects will happen someday

[sometimes99er]

Something like the Vic-20 Mega-Cart or the 128-in-1 Flash MultiCart would be very cool. Something combining the two and supporting some, or all for that matter, of different hardware add ons thru time.

There were some game cartridges which used the expansion port (instead of the cartridge port). These cartridges had better or different access to memory spaces and facilities. I guess you can't have both worlds at the expansion port, so maybe some sort of ugly cable between the two. A demand for "pass thru" to speech (if not onboard) and to the CF7/nanoPEB (assuming it is almost impossible to have onboard - but maybe it could fit "in the box").

[matthew180]

retroclouds, on Tue Sep 21, 2010 12:06 AM, said:

2) A low-cost PCB for a bank-switched card having some additional RAM (1K - 4K), suited for
selling in homebrew games. Dunno how important GROM support would be.
Would be cool if it had some GROM header so that it could run on V2.2 consoles.

How about 8K to 32K of RAM? :-) The chips I'm looking at go all the way up to 512K, but the price is prohibitive at that point ($60 USD each). These are the nvSRAM chips that can retain their nonvolatile data for up to 100 years (not sure how they tested that) and do not require a battery. Pretty neat chips made by Cypress Semiconductor, and the same chips being used in the VIC20's mega-cart.

There absolutely needs to be GROM support in such a "super" cart. I was thinking that the programmer could designate one of the 8K banks as the GROM "shadow", i.e. that would be the data used for the GROM. That way it would be fully programmable, and changeable on the fly. :-)

I ordered a TQFP to DIP adapter for my CPLD last night, so I'll be able to start prototyping the GROM replacement.

Matthew

[JamesD]

I'm not sure how the existing cartridge paging works, but maybe writes on consecutive addresses or pages could alter the mode of the write line to enable it as a write. Reading from the cart again would revert to page switching. Simple but it should work.
Worst case, the mode switch state machine is only active for a few cycles so writes must take place one after he other to activate the mode.

Edited by JamesD, Tue Sep 21, 2010 6:31 PM.

[Mad Hatter]

I have the 128-in-1 cart for the ColecoVision; the one which Retroclouds supplied a link to. Amazing product, no cartridge switching and you can play the public domain homebrew games on the actual equipment, even if you don't own the cart. Even more amazing would be having something similar for the TI!

[retroclouds]

Mad Hatter, on Tue Sep 21, 2010 9:48 PM, said:

I have the 128-in-1 cart for the ColecoVision; the one which Retroclouds supplied a link to. Amazing product, no cartridge switching and you can play the public domain homebrew games on the actual equipment, even if you don't own the cart. Even more amazing would be having something similar for the TI!

Yeah, I have one too. It's a slick product and its menu system is real nice.

[intvnut]

matthew180, on Tue Sep 21, 2010 7:00 AM, said:

retroclouds, on Tue Sep 21, 2010 12:06 AM, said:

2) A low-cost PCB for a bank-switched card having some additional RAM (1K - 4K), suited for
selling in homebrew games. Dunno how important GROM support would be.
Would be cool if it had some GROM header so that it could run on V2.2 consoles.

How about 8K to 32K of RAM? :-) The chips I'm looking at go all the way up to 512K, but the price is prohibitive at that point ($60 USD each). These are the nvSRAM chips that can retain their nonvolatile data for up to 100 years (not sure how they tested that) and do not require a battery. Pretty neat chips made by Cypress Semiconductor, and the same chips being used in the VIC20's mega-cart.

There absolutely needs to be GROM support in such a "super" cart. I was thinking that the programmer could designate one of the 8K banks as the GROM "shadow", i.e. that would be the data used for the GROM. That way it would be fully programmable, and changeable on the fly. :-)

I ordered a TQFP to DIP adapter for my CPLD last night, so I'll be able to start prototyping the GROM replacement.

Out of curiosity, have you considered using a microcontroller and its onboard RAM/flash? For the Intellivision, I've designed a board that makes 256K of flash storage (minus space for the firmware) and 16K bytes of RAM available to the Intellivision. And, since it does support in-system erasure/reprogramming of the flash, you can use a portion of the flash storage for non-volatile data, such as high scores, game-save states, etc. You just have to be sure to wear-level since their flash technology doesn't support a ton of erase/reprogram cycles.

I used Microchip's PIC24 / dsPIC33 for my design. At 40MHz, it's more than fast enough for the Intellivision. I'm less certain about the TI-99/4A, since its bus isn't time-multiplexed like the Intellivision's, and Thierry's page seems to suggest you need a 125ns or faster memory for zero wait-state. But, you do have wait-states by the time you get to the cartridge port, correct?

(Edited above from 100ns to 125ns based on: Assume 4MHz mod applied to system, so 250ns clock. You have from leading edge of phi2 to next leading edge of phi1 plus 30ns setup, which is .75*250 = 157ns. You could lose another 30ns of time on MEMEN and related signals, dropping you to 127ns. Rounding down, I get 125ns. A 40MHz MCU (25ns cycle time) might not be able to meet that since you only get 5 cycles. But, if the console's inserting wait states, that adds multiples of 250ns to your budget. If it's true that 1 cycle gets stretched to 4, as it says elsewhere on Thierry's page, then you have almost 1000ns to play with, which is plenty for an MCU.)

Microchip also has an 80MHz MIPS part. They go for something like $5/$6 in volume. Look up the PIC32 for that baby. You can get even larger amounts of on board flash and RAM there, under $10.

If you can make such an microcontroller work, you could support a wide variety of bankswitching schemes fairly easily as a Small Matter of Software.

Edited by intvnut, Wed Sep 22, 2010 11:26 AM.

[theloon]

I've seen original playstation memory cards that have a left-right toggle and an LCD 2 digit display. You would "bank switch" between memory by pressing left or right and the current memory bank would be displayed.

Might this be a viable solution?

[Gary from OPA]

Regarding the CRU lines, they are full, it is only two, because that is all you need.

One is the clock and the other the data in, and you use the address bus to grab your CRU space.

The cartridge port is designed to run in the pre >1000 under the >1000 space, like >0000 to >0F00.

I personally used the >0B00 space for my POP-CART design, it allowed me to control the features on,off,special,page-switching.

Plus you can use the RML (Review Module Library) already designed into the OS, to allow multi-banks of GROM memory, and I used
that feature to also bring in matching blocks of >6000 space along with the 64K of GROM.

The POP-CART allowed in it's original design up to 16 blocks of 64K of GROM for 1024meg, and up to 4 pages of ROM (6000) of 512K
and ontop of that I designed a CART DSR DEVICE (much like "text-to-speech in TEII) called "CART." to make a ROM-Disk of normal
files of the remaining 512K not available to modules.

It used 2 1024megabyte EEPROMs one for the ROM side, and one for the GROM side.

I also designed a writable version using FLASH on the GROM side, but at the time (early 90's) it was too costly for flash.

Anyhow just my 2 cents on what is possible.

P.S. - Regarding CRU on CART port, the later models of TI99, the 99/4qi one with v2.2 GROM's, also removed the CRU lines going to the CART port!

[acadiel]

There's something in the works. It's based on my original design, and there are two fine gentlemen enhancing it. I'm not stealing their thunder, because it's still in prototype mode, and hasn't even been tried yet. :-)

I'll show ya the circuit board, but I'm not commenting any further than I'm going to solder the ROM socket on it, and try out the ROM part of it to make sure it works.

Attached Files

•  V6_cart.jpg   115.59K   40 downloads

[akator]

I love the VIC-20 MegaCart. It is one of the most awesome things ever. The games and software are already there with no need to mess around with flash cards or USB transfers.

For the same reasons, I also love the 72-in-1 Vectrex Multicart and the Bally Astrocade Multicart, although the latter uses DIP switches instead of an onscreen menu.

Don't get me wrong... the AtariMax carts, CC3, Harmony, uIEC SD, CF7+, SIO2SD, Everdrive, etc., are all awesome. However, the computer carts/drive emulators can be a lot more complicated to deal with. For example, when I just want to fire up some TI-99 games with the CF7+, it's frustrating when I can't remember if I need the Editor Assembler or Extended Basic. It also makes me nervous to power cycle the CPU so many times when trying to figure out the correct combination to get things working. I've found it's a lot easier just to use an original game cart, at least that works every time the first time.

The advantage of the MegaCart is that it is truly plug-and-play. To me, that is part of the point of a multicart. Even if I have to load a cart with software, I want to do that once, plug it into the system, and not have to take it out again. IMO a multicart should stay in the system, prolonging the hardware by eliminating cart swapping and keeping my original carts out of harm's way. Plus, it's so convenient that I find myself using the original hardware much more often, which is of course part of the reason for collecting in the first place

[retroclouds]

acadiel, on Thu Sep 23, 2010 6:28 PM, said:

There's something in the works. It's based on my original design, and there are two fine gentlemen enhancing it. I'm not stealing their thunder, because it's still in prototype mode, and hasn't even been tried yet. :-)

I'll show ya the circuit board, but I'm not commenting any further than I'm going to solder the ROM socket on it, and try out the ROM part of it to make sure it works.

That sure looks beautyful

I've heard rumors about this baby. I didn't know development was that far already though.
Will this be a 2010 release? It would be nice for Xmas

EDIT:
Looking at the picture, I see there is space for an ATmega1284.
The ATmega1284 has 16KB of SRAM, so I'm hoping that some of it will be available in the cartridge space

[InsaneMultitasker]

Very nice looking board I've not used the 49F040 but have used the 29C040 and variants with the Geneve. I seem to recall the difference is in how/what you can reprogram.

[Opry99er]

Quote

Ultimately I'd also like to work in some sort of USB interface or miniSD card options so the cart could be loaded / programmed from a PC (personal computer, not necessarily a *Windows* "PC"). At this point the cart would enter the realm of a mega-cart I suppose. Maybe you put this cart into the 99/4A and leave it there, then instead of changing "cartridges" you would change miniSD cards.

Man, I can only dream of the day this is possible. Looking forward to your progress man. It's a very cool topic, really...

[matthew180]

intvnut, on Wed Sep 22, 2010 11:10 AM, said:

Out of curiosity, have you considered using a microcontroller and its onboard RAM/flash?

I looked at microcontrollers, but I'm shying away from them for a few reasons:

1. There are already people working on a microcontroller based solution, so I figure I'll try something different so we can see how each method works out.

2. I could not figure out if the flash in the various microcontrollers I was looking at could be used as a form of RAM. From the datasheets is seemed like the flash memory was programmed with code and data, then placed in a circuit. It was not clear if the executing code could modify that memory directly, and if so, use it for any purpose.

3. I'm really kind of partial to the programmable logic now that I have had a taste of it. I don't have to worry about clock speed so much, or how long a program takes to execute, etc. I only have to worry about propagation delays, which are pretty much always going to be faster than the classic hardware.

I used to approach a problem in terms of how I could solve it using a CPU and code. Lately I tend to think about how I would solve the problem with a circuit via a PLD of some sort. And, in cases like the GAL I used in the Bank Switch Mini, the PLD was a *lot* easier and cheaper than using a microcontroller of some sort.

Matthew

[matthew180]

Gary from OPA, on Wed Sep 22, 2010 11:57 AM, said:

The POP-CART allowed in it's original design up to 16 blocks of 64K of GROM for 1024meg, and up to 4 pages of ROM (6000) of 512K
and ontop of that I designed a CART DSR DEVICE (much like "text-to-speech in TEII) called "CART." to make a ROM-Disk of normal
files of the remaining 512K not available to modules.

I sure would like to see this POP-CART. I have never even heard of it!

Gary from OPA, on Wed Sep 22, 2010 11:57 AM, said:

P.S. - Regarding CRU on CART port, the later models of TI99, the 99/4qi one with v2.2 GROM's, also removed the CRU lines going to the CART port!

!@#$% Grrrr! That just sucks! So they added the requirement for a GROM in a cart and removed the CRU lines. WTF? That almost makes me simply want to write off worrying about supporting the QI consoles all together. I thought is was only the firmware that was changed, but actually modifying the hardware, that makes things a whole lot harder to keep track of.

I wonder how many QI consoles were actually produced?

Matthew