DreamCart: for new games a new kind of cart support is now possible!

[MCes]

Cart games were originally organized to use cart ROM for SW, and only native VIC20 RAM for variable bytes, and for those games it was enough.

Many recent games use RAM resources more heavily making the old cart structure not applicable, so this games has to be externally loaded over a RAM expansion, it's imply that the programmers can't obtain a simply cart with own game inside...

why not?

My idea is a "simple & cheap" new cart structure that integrate a 24k RAM expansion and a ROM, at startup the auto start routine load the ROM datas on RAM (as a "LOAD" can do) , consequently a "RUN" is performed...
This solution implies that all games that don't need more than +24k RAM expansion can fit on this cart,
and the game on ROM is .PRG version for expanded VIC20: no specific game version is needed!

Common .PRG source:
In case of games are using less BLOCKs this cart can be filled with 2 or 3 games (cheap ROM of gross 8BLKs capacity).

Source created for this cart-structure:
If game need also the BLK5 it can be done if that datas are not variable (ROM),
in this case the BLK5 can be also paged (for different game levels...)

Is it interesting?

[Vic20-Ian]

Interesting idea.

Would it be possible to make it +35k so e.g. Doom and others could be on it?

It would make a nice way to make modern cart releases without needing to have a multi slot board.

If you made it end user flashable then it could be a very nice solution.

I can imaging myself buying half a dozen blanks if they were circa £10 each to flash some favourites and make myself some custom cartridge labels.

[MCes]

Would it be possible to make it +35k so e.g. Doom and others could be on it?

MMMmmm......
A possible "NEW CART" format can be:
1) RAM expansion on RAM1,2,3 and BLK1,2,3,5 for a total of +35K
2) BLK5: 8pages of 8k ROM can appear (in this case you read the ROM and write on covered RAM...)
3) a 4 bit "writable only" register is on I/O: 1 bit is for choosing (only on BLK 5) "RAM" or "ROM over RAM", 3 bits are for selecting which one of the 8 ROM pages (total ROM of 64k) has to appear on BLK5

On HW reset the register is "0----000"b that means, b7="L": ROM over RAM, b2.1.0="L": lowest ROM segment.
Into ROM segment "0" the VIC20 has to find the autostart routine that load, from the current segment, the VIC20 native RAM, the +3k lower ram, and a little SW that will manage the next steps (into cassette buffer, or screen memory...).
A different ROM page will be selected and copied in BLK1, repeat this for BLK2, BLK3, BLK5, then set the bit "RAM"on BLK5 and start the game....

The ROM is a 64K rom (8 BLOCKs) and if the games doesn't use all space another game can be fit inside the free ROM area (the starting routine will have to manage the game selection).

This HW format work if the game doesn't load other files during execution, and need that a "standard" self-loading routin has to be write (the self-copy activity that I described before). The simple "PRG" version of the game could be sufficient: a specific game coding is not required!

If a game will be coded for this specific HW format than also the free ROM space could be used for storing pages of datas (example: different game level screen datas..).

This is a cost-effective approach that performs enormous flexibility.

Could this be a good "cart-standard" definition for a new 2nd generation cartridge format?

[Vic20-Ian]

What is your target price for such a cartridge?

[MCes]

What is your target price for such a cartridge?

It dramatically depend by the lot dimension....
Also developing a wellworking prototype has a cost.

So I think that the "narrow way" couldn't be practicable without the definition of a "standard" that is the base for using this project also for future games/by others programmers/and so on....

Only making it an "evergreen" might be convenient for starting a batch production, I suppose.

So,
how many of this new cart are needed?

[MCes]

OK, last edition of the new "DreamCart" standard is:

1) RAM expansion on RAM1,2,3 BLK1,2,3,5 I/O2,3 for a total of +37K
2) BLK5: 8pages of 8k ROM can appear (in this case you read the ROM and write on covered RAM...)
3) a 4 bit "writable only" register is on I/O: 1 bit is for choosing (only on BLK 5) "RAM" or "ROM over RAM", 3 bits are for selecting which one of the 8 ROM pages (total ROM of 64k) has to appear on BLK5

Also I/O2 and I/O3 are filled with RAM, under I/O2 (or I/O3, we have to quickly decide wich one) there is the "only-write" register, it's mirrored into all 1k bytes area.
Careful for using this ram area (any time you will write on it the BLK5 configuration will be modified), but if always the same address is used for writing the register (and the RAM byte that is overlapped to him), than when you will read this specific (RAM) address you will return the last value wrote on the register making it a read/write register.

Target cost for the project: not more than 10..15€/cart for 10pcs lot (no plastic case, PCB gold fingers finished)

Now I need a little feedback from who will be the possible users of this new kind of physical cart for new high performing software/games: the people that make high performing software/games!

I need to know if the register is preferred to be accessible by I/O2 or I/O3, because I would start the prototype development.

I need to know if this project is considered a good way for realizing a physical support to the new SW generation, or not, or else....

[orion70]

For what I know hardware-wise, it's a very good dream indeed

I am asking here to people in the forum currently co-operating in the VICE emu team - wouldn't it be possible to implement the emulation of this cart in VICE, in order for anyone who wants to use this cart to produce a small batch of his own game, to test it in emulation before ordering?

You know, once you're sure of the final result, you begin dreaming of the real thing

[Noizer]

Great!

[Mike]

I am asking here to people in the forum currently co-operating in the VICE emu team - wouldn't it be possible to implement the emulation of this cart in VICE, in order for anyone who wants to use this cart to produce a small batch of his own game, to test it in emulation before ordering?

Note: I am no VICE developer.

It would surely be possible to implement such a cart in VICE. However, if the VICE developers would start emulating non-existing hardware, that'd turn the whole thing quickly into a shifting sands scenario. The hardware has there to be first.

That anyway does not pose a problem in practice. Most programs later to be put into cartridge ROMs are normally tested by activating RAM in those areas in VICE, and softloading the code/data. Programs that employ a banked RAM/ROM configuration are probably best served with an existing (and already emulated!) cartridge solution, like Ultimem is.

...

My suggestion for a "univeral" non-banked cartridge would be one that supplies 5 IC slots that could be populated with either 8Kx8 RAMs or EPROMs for BLK1..3, BLK5 and combined RAMx/I/Ox. That'd cover most conceivable combinations of RAM or ROM (or unused) in those memory areas and could also be done with minimal glue logic - mostly, a single 74HCT1G00 NAND gate with /OE = !(CR/W & SPhi2) for all memory chips to prevent data bus contention, especially with the non-qualified I/Ox select signals. The combined RAMx/I/Ox chip select can probably do with a wired-AND, with 5 Schottky diodes and a pull-up. For tests, VICE already emulates all possible combinations of that cartridge design out-of-the-box.

[Noizer]

What’s about Flashrom instead of EPROM. Could be more user friendly IMHO

[groepaz]

It would surely be possible to implement such a cart in VICE. However, if the VICE developers would start emulating non-existing hardware, that'd turn the whole thing quickly into a shifting sands scenario. The hardware has there to be first

yes, totally.

that said, IF somewhat final specs exist, i can assist in making a patch that changes one of the existing cartridge emulations into whatever you have there (this is how i usually start when adding a new cartridge type)

[MCes]

My suggestion for a "univeral" (....)

If you want make a physical cartridge with an old game/software you can easily download its .BIN image from Zimmers and put it inside an (E)EPROM that has to be fitted on a simple PCB, no other HW resorces are needed, and it's possible because those SW was written to be stored into a ROM and for using only the native RAM inside the VIC20.

Many new games/SWs are written to be loaded on the expanded VIC 20, so these new .PRG SWs cannot be stored in ROMs because they are developed to be fitted into RAM (they use for "variables" some areas whose positions are not predictable), this imply that a new kind of cartridge has to implement the ram expansion into each block that SW could use, over it the SW has to be loaded (as some not cheap multi cart do).

This concept obviously cut out the old-style cartridge (only ROM), but also the cartridge that are composed by "RAMs BLOCKs for variables " + "ROMs BLOCKs for SW".

To obtain the standard cartridge behaviour (you "switch on" the VIC20 with cartridge fitted, and the game/SW start), inside the cart there must be the RAM expansion + a ROM memory that will auto-start a small routine that will fill the RAM by loading the .PRG file stored into the ROM, at the end of this memory copying activity the ROM can disappear and the SW on the RAM will be started.

The behavior generated is the same as the old cartridge, but this new one can support the new high-performance SW also without writing a special version: normally you can use its standard .PRG file!

If we want make a tentative for a "second generation" cartridge it is necessary to converge on a definition of its (standard) characteristics which they must satisfy the SW developers but not to be too high, because it's realization has to remain cheap enough to be phisically adopted.

Anciently for demonstrate what an architecture is able to do a prototype had to be realized and sent to the SW developers, into 3th millennium a prototype has to be realized (for demonstrating the correctness of the system) and than its behaviour can be SIMULATED (VICE...) permitting to all SW developers to test their old SW on it, and also develop new SW that use also the new peculiarities of this system.

All SW developers will be able to obtain a physical cartridge with their high performance SW inside!

I ask for help from all SW developers to define a good cost/architecture compromise for this new cart, and the hypothesis of a VICE implementation is to help developers to know/test its potential without having it physically, obviously I will ask to implement it in VICE only after the well-functioning demonstration of the prototype.


The goal is a new standard architecture for physical cartridge that can implement the new SWs: suggestions?

[Mike]

Many new games/SWs are written to be loaded on the expanded VIC 20, so these new .PRG SWs cannot be stored in ROMs because they are developed to be fitted into RAM (they use for "variables" some areas whose positions are not predictable), this imply that a new kind of cartridge has to implement the ram expansion into each block that SW could use, over it the SW has to be loaded (as some not cheap multi cart do). [...] The behavior generated is the same as the old cartridge, but this new one can support the new high-performance SW also without writing a special version: normally you can use its standard .PRG file!

Programs/Games that are ultimately intended to run on a cartridge should strive for a clear separation of code and constant tables on one side, so these are ROMable; and variable workspace on the other side that goes into (extra) RAM. Especially, cartridge programs should avoid self-modifying code! The use of self-modifying code in this case implies, that a template of it is kept in ROM space, and first copied to RAM before that copy is then 'tailored' to the current needs of the program. That is about the only case where code needs to be duplicated, otherwise code already is at its final place, in ROM.

If we want make a tentative for a "second generation" cartridge it is necessary to converge on a definition of its (standard) characteristics which they must satisfy the SW developers but not to be too high, because it's realization has to remain cheap enough to be ph[y]sically adopted.

Above I wrote my suggestion for an 'unmapped' yet still flexible cartridge design. It conforms nicely to the program design principles I stated above.

If you want to design a new cartridge with flexible memory mapping, go ahead. But it should be clear to you that any new design will just enter a continuum of complexity and cost where other existing designs like Mega-Cart, FE3 and Ultimem have already zoned out large parts of the map. Do we really need yet another 'standard' of registers in I/Ox for RAM/ROM mapping?

[MCes]

Programs/Games that are ultimately intended to run on a cartridge should......

That's exactly what I don't want: a SW version expressly written for fitting a cartridge.... At the opposite side I want a cartridge expressly developed to be fitted by a common .PRG files (+ a little standard firmware: a routine that auto load the RAM from the ROM).

In a "new cartridges" scenario the "DreamCart" (a cheap plug & play single game/SW cartridge) is conceptually at the opposite side of the more expensive multicarts, they won't be in competition.

I'm thinking to a minimum HW cheap enough to be used as single (or dual) game/SW cartridge, that permit to SW developers to have in their hand a cart with own SW inside...

For example, in this page you can find 2 different games: "Vic Nibbler" and "PumpKid"
https://www.hewco.uk/
The first .PRG game can be loaded into a VIC20 without RAM expansion, so the SW developer can realize a simple old style cart (with a very good result!) :https://www.thefuturewas8bit.com/shop/g ... bbler.html

But a simple old style cart cannot be done with the second game because probably its standard .PRG program use RAM areas as variable that is bigger than RAM inside the VIC and that we can't predict.

"DreamCart" architecture permit to be fitted with a standard version of .PRG files and the cart will work "plug & play".
"DreamCart" architecture accept to work with all .PRG file (not multiloading) that can be intended for to be loaded into an expanded VIC20 +0k, +3k, +8k, +16k,+24k RAM, but with a simple work the SW developers can also fit the .PRG files for VIC20 +32k RAM.

If I think at Mike's cart suggestion, if I extend both RAM and ROM at 100% of the decoded areas and put on it a minimum of glue logic to manage all, than we are thinking to the "DreamCart" architecture, with the benefit of using a not specific SW version (SW on ROM, variables on RAM) but the simple .PRG version for an expanded VIC20.....

why not?

[Mike]

O.K. then - as per the diagram of the OP, there are two main options I would consider:

1. is BLK5 dedicated to the cartridge firmware, i.e. can the content of BLK5 remain largely 'fixed' and thus easily serve to transfer data to the internal RAM and cartridge RAM BLK1..3?

2. or should BLK5 also be available for the cartridge data, i.e. the firmware is replaced by the 'final' cartridge data of BLK5 during startup? That would be necessary for programs that otherwise require a +32K RAM expansion.

In any case, you would use part of I/O x to hold paged ROM data (say, I/O 2 to transfer 1K pages in one go), from which BLK1..3 (and eventually BLK5) are filled, some BASIC pointers are initialised and the loaded RAM data then is started.

If BLK5 is also supposed to be loaded, then the later part of the startup process then needs to page out the BLK5 ROM and transfer control to another place, an auxiliary routine located somewhere in $0000..$03FF which transfers the final data from the paged ROM to BLK5 RAM before starting up the game.

This setup would require something around a 32Kx8 SRAM (minimum, see edit regarding the inclusion of RAMx), a 64Kx8 (E)EPROM (at least 32K to hold the entire cartridge data for BLK1..3 and BLK5, plus x KB for whatever fills the internal RAM beginning at $1201, plus another y KB for the cartridge firmware that acts as loader. Plus another 3 KB if RAMx is also supposed to be initialised). You'd need an 8 bit latch register for the upper address lines of the (E)EPROM, the register which would be located in I/O 3. 6 bit would map in one of the 1K pages of the (E)EPROM into I/O 2 (used for the startup procedure), at least 1 bit selects between ROM or RAM in BLK5. Plus some glue logic.

Is this more like what you're up to?


Edit: the cartridge firmware might include a service menu that is invoked upon holding C= on power-on/reset and which allows to reprogram the EEPROM from files on disk. That would prepare the "BASIC memory" ($1201..$7FFF) from one file and BLK5 ($A000..$BFFF) from another file (so the BLK5 RAM option is realized). In case RAMx is also included for a ROM->RAM transfer, a third file would be used (that would require a larger SRAM chip, though).