CRT V3 working draft v0.0
-------------------------

WARNING: this is unfinished WOK IN PROGRESS


why?
----

After adding support for all the CBM machines to the format (and creating
v2 in the process) it was obvious we also should solve some other long
standing problems.

TODO: identify problems other than the ones listed below


support "extra ICs"
-------------------

So far the CRT format has only supported one "type" of memory (*). IE even
when the physical cartridge contained several ROM chips, the CRT file would
typically contain multiple "chip" chunks to represent logical banks instead
of physical chips. This becomes a problem with cartridges that contain
more than one type of memory, which have to be treated differently (eg ROM
and EEPROM).

(*) this is indeed questionable, and one could argue different types were
always supported by the specs. But the specs were (ab)used in different ways
in practise, which we need to deal with now.

GOAL: define a way to include "extra ICs" in the format cleanly

This should be as generic as possible, work for any amount of extra ICs (and
of various types), without inventing special cases for each cartridge type.

    * support any (reasonable) number of "extra ICs"
    * "extra ICs" can be any of the memory types
    * deviate as little as possible from how the format was used before

TODO: identify and document all the already existing hacks in the wild (eg
1541U supports some Gmod2 with embedded EEPROM). We might gather some ideas
and/or need it for future workarounds

TODO: list missing, not yet implemented, cartridges (or better yet, implement
them :))

TODO: come up with a format extension

TODO: try to define an artificial scheme that breaks the new format :)

Comment: It might indeed be questionable to save the RAM of certain (or even
most) cartridges into the CRT file - however, that does not mean it shouldn't
be a valid option that we need to consider. It is also one of the reasons for
why we must support multiple "extra ICs".


Already defined cartridges that we need to consider:

Name                        CRTID

* C64

Action Replay V5            1       RAM
KCS Power                   2       RAM
Atomic Power                9       RAM
Magic Formel                14      RAM
Super Snapshot v5           20      RAM
Easy Flash                  32      RAM
Capture                     34      RAM
Retro Replay                36      RAM
MMC Replay                  38      RAM     EEPROM
Super Snapshot V4           40      RAM
Pagefox                     53      RAM
Gmod2                       60              EEPROM
MAX BASIC                   61      RAM
REX RAM-Floppy              67      RAM
SD Box                      69      RAM
MultiMAX                    70      RAM
LT Kernal                   72      RAM
CMD Ramlink                 73      RAM
Partner 64                  78      RAM
Universal Cartridge 1       80      RAM
Universal Cartridge 1.5     81      RAM
Universal Cartridge 2       82      RAM
Magic Desk Plus             87      RAM     EEPROM


* C128

Gmod C128                   5               EEPROM


* VIC20

Mega Cart                   1       RAM     NVRAM
VIC Flash Plugin            3       RAM
Ultimem                     4       RAM
Final Expansion             5       RAM
Super Expander              7       RAM
Mikro Assembler             8       RAM


Proposal:

- define position $08 in the CHIP header as "IC number" (that limits $09,
ie "IC type" to 256 cases, but we only use 4 anyway :))

- make $08 and $09 being filled in correctly mandatory



"legalize" RAM-Only Cartridges
------------------------------

So far we have refrained from assigning CRT IDs to cartridges which do not
contain some kind of ROM.

Well, with one exception, which was kind of an oversight in the old days :)

Expert Cartridge            6       RAM

Comment: It totally makes sense to assign CRT IDs also for some of the
cartridges in this category (REU, GeoRAM etc). However, doing so requires
no changes to the format, other than assigning new CRT IDs (Memory size can
be implemented as sub-IDs). BUT this also means that RAM is a totally legit
type for the primary image in a CRT file, and any extension created for the
"extra IC" case above can not violate this (eg assume RAM is always extra).



"no memory" Cartridges
----------------------

Another ongoing discussion was about being able to create .crt files for
cartridges that do not even contain a memory image (Example: an RS232 interface).

Comment: While this is entirely doable, the benefit seems low - in particular
this would only increase the amount of work for everyone IMHO, so i am not
considering it right now. In any case, this would not require changes to the
format either.