VRT file format

nojoopa · Post by **nojoopa** » Fri May 04, 2012 10:00 am

Due to the usability issues with VIC-20 cartridge files (especially in the two-part case), I created a new file format for VIC-20 carts: VRT. The format is heavily based on the CRT format used by C64 emulators and some modern hardware such as 1541 Ultimate. Initial VRT support and a converter have been implemented in this VICE fork.

The "generic cartridge" type is supposed to handle all the old (pre-2000) cartridges that don't use the I/O areas. The current VRT format (version 1) assumes that BLK 1-3 & 5 only contain one chip (RAM or ROM) of either 8kB or 4kB in size; in the latter case, the data is mirrored to the other 4kB of the range.

Are there any "generic" carts that don't fit in the above description? If so, please point them out. Of course, feedback on other flaws is welcome. Let's work out to quirks before suggesting this for VICE inclusion.

Note: I still haven't owned a working VIC-20 or even used one so I'm certainly not the right person for this project. Besides, it's 15 years too late.

Bonus: vrtfe3, a proof-of-concept VRT loader for the Final Expansion 3 cart. Contains fe3.vrt for testing loading a VRT using an emulated FE3 attached as a VRT.

tlr · Post by **tlr** » Fri May 04, 2012 10:40 am

Sorry for not giving any feedback on this yet. I think it looks very good.

One thing though. There should probably be some way of handling wrapping and/or partial decoding within memory areas in the generic cart type.

4KiB of ROM in a 8KiB bank or perhaps even 4KiB of RAM in an 8KiB bank.

At least the ROM case is common. Perhaps there even was 2KiB ROMs?

These are the "generic" examples I collected (but never really solved) when looking at a cart format a long while ago:

Code: Select all

      The first example is "Pharaoh's Curse", a  16KiB cartridge
    populating the full BLK3 and BLK5 lines.

    Generic cartridge

    Size - 16KiB
    Load address - $6000-7FFF, $A000-$BFFF

Code: Select all

      The second example is "Vicmon", a  4KiB cartridge
    populating the upper half of the BLK5 line.

    Generic cartridge

    Size - 4KiB
    Load address - $B000-BFFF

Code: Select all

      The third example is "Super Expander", a  4KiB cartridge
    with 3KiB of RAM populating the lower half of the BLK5 line and
    all RAM1-3 lines.

    Generic cartridge

    Size - 4KiB + 3KiB (RAM)
    Load address - $0400-$0FFF (RAM), $A000-AFFF

Code: Select all

      The fourth example is "Rabbit Tape", a  2KiB cartridge
    populating the I/O2 and I/O3 lines.

    Generic cartridge

    Size - 2KiB
    Load address - $9800-$9BFF, $9C00-9FFF

Code: Select all

      The fifth example is "Mikro Assembler", a 2 * 4KiB cartridge
    with 3KiB RAM populating the BLK3, BLK5 and RAM1-3 lines.

   Generic cartridge

    Size - 4KiB + 4KiB + 3KiB (RAM)
    Load address - $0400-$0FFF (RAM), $6000-$6FFF, $A000-AFFF

nojoopa · Post by **nojoopa** » Sat May 05, 2012 7:29 am

Seems like the format (and xvic) is woefully inadequate to handle all of these cases. Should have guessed.

tlr wrote:There should probably be some way of handling wrapping and/or partial decoding within memory areas in the generic cart type.

Unfortunately. Since the generic type is fine for a large bunch of cartridges and is simple enough to be "supported" by FE3 (and maybe Mega-Cart / Vic Flash Plugin too), I'm tempted to shove the problematic cases under an another type under the working title "tricky" (naming suggestions welcome).

In any case, the format needs to specify the new fields so an update is pending.

4KiB of ROM in a 8KiB bank or perhaps even 4KiB of RAM in an 8KiB bank.

At least the ROM case is common. Perhaps there even was 2KiB ROMs?

If mirroring the smaller ROMs to the whole range is close enough, then the 4kB case should already work on the current VRT version; I'll add 2kB too if such a cart (using BLK1-3/5) is pointed out.

These are the "generic" examples I collected (but never really solved) when looking at a cart format a long while ago:

Thanks, this is just the kind of info I was looking for. Some comments on them:

Code: Select all

"Pharaoh's Curse"

This should work already.

Code: Select all

"Vicmon"

If it appears as mirrored on $Axxx, it works.

Code: Select all

"Super Expander"

Ouch! A truly nasty case.

Code: Select all

"Rabbit Tape"

While support for ROM/RAM-on-I/O could be added to the generic type, I'd shove this under "tricky" to keep the generic type FE3-supportable.

Code: Select all

"Mikro Assembler"

Hmm. If the ROMs are mirrored to the other 4kB of their respective ranges then this works already. Can anyone confirm if this is the case?

nojoopa · Post by **nojoopa** » Sun May 06, 2012 6:44 am

After a closer look...

Code: Select all

      The third example is "Super Expander", a  4KiB cartridge
    with 3KiB of RAM populating the lower half of the BLK5 line and
    all RAM1-3 lines.

    Generic cartridge

    Size - 4KiB + 3KiB (RAM)
    Load address - $0400-$0FFF (RAM), $A000-AFFF

I parsed part of that as:

Code: Select all

    3KiB of RAM populating the lower half of the BLK5 line and
    all RAM1-3 lines.

...in the sense that the same RAM is visible in both places. Fortunately the load address line disagrees. As such, this should already work, assuming $Bxxx is a mirror of $Axxx.

Before realizing this I updated the specs (and converter) to include the "tricky" type that can handle such oddities. Update coming in about two weeks.

Depending on the mirroring, these examples should be doable with the "generic" type. Any more corner cases?

Mike · Post by **Mike** » Sun May 06, 2012 7:01 am

nojoopa wrote:I parsed part of that as: [...]

No, that's not how the SE appears in the CPU address range. Rather:

- 3 KB additional RAM in the range $0400 .. $0FFF (corresponding to the /RAM1, /RAM2 and /RAM3 signals on the expansion port),
- 4 KB additional ROM in the range $A000 .. $AFFF (lower half of BLK5, possibly mirrored to upper half - could someone else confirm?)

Greetings,

Michael

buzbard · Post by **buzbard** » Sun May 06, 2012 10:36 am

Mike wrote:
nojoopa wrote:I parsed part of that as: [...]
No, that's not how the SE appears in the CPU address range. Rather:

- 3 KB additional RAM in the range $0400 .. $0FFF (corresponding to the /RAM1, /RAM2 and /RAM3 signals on the expansion port),
- 4 KB additional ROM in the range $A000 .. $AFFF (lower half of BLK5, possibly mirrored to upper half - could someone else confirm?)

Greetings,

Michael

I have 2 SE carts, and Mike is correct, but 4k rom is not mirrored, $B000-$BFFF are random bytes.

Mike · Post by **Mike** » Sun May 06, 2012 10:56 am

buzbard wrote:$B000-$BFFF are random bytes.

Ah... I should have known that: it wasn't for no reason, that I relocated Programmer's Aid to $B000 some time ago.

What you see actually is bus noise, i.e. SE only maps into the lower 4K of BLK5, and is deselected in the upper half. This enables to map in yet another expansion cart in the upper half. The relocation of PA to $B000 frees BLK3, so BLK1..3 could be completely filled with RAM.

nojoopa · Post by **nojoopa** » Sun May 06, 2012 3:01 pm

Thanks for confirming the SE case.

Meanwhile, I added RAM/ROM-on-I/O support for the generic cart and specified/implemented the "tricky" cart. Updated VRT docs here. The adventurous may check out the code from the git repo [1] and give it a spin.

SE should work now by using

Code: Select all

vrtconv -o se.vrt new tr se.prg r0

and attaching the .vrt. The other mentioned cases have similar "solutions". So far the testing has been minimal as I'm not familiar with the carts.

The current tricky cart specs should allow any sane RAM/ROM cartridge to be represented. Things such as "every other byte is RAM, every other is ROM" falls outside the vague definition of sanity. I really hope no such abomination exists...

More corner cases? Other feedback?

--
[1]

Code: Select all

git clone git://viceminus.git.sourceforge.net/gitroot/viceminus/viceminus

nojoopa · Post by **nojoopa** » Sun May 13, 2012 10:36 am

Added some checks and minimal documentation (see git repo linked earlier). Haven't got the time or talent for proper tests. Someone may want to backport this to VICE.

That's my take on VIC-20 cartridge format matters. The ball is on not-me's court. Thanks for the feedback!

groepaz · Post by **groepaz** » Fri Jun 08, 2012 6:55 pm

Someone may want to backport this to VICE.

someone throw a few such cartridge dumps into my direction please :)

groepaz · Post by **groepaz** » Mon Aug 13, 2012 5:23 pm

noone cares?

tlr · Post by **tlr** » Tue Aug 14, 2012 4:48 am

groepaz wrote:
Someone may want to backport this to VICE.
someone throw a few such cartridge dumps into my direction please

Somehow missed your request here.

What type of dumps do you want?
There are a lot of dumps here: http://www.zimmers.net/anonftp/pub/cbm/ ... index.html

buzbard · Post by **buzbard** » Tue Aug 14, 2012 10:37 am

Here's a couple I whipped together in a hex editor:

Avenger.vrt

Battlezone.vrt

I think these conform to nojoopa's specifications.

Ray...

buzbard · Post by **buzbard** » Tue Aug 14, 2012 11:00 am

And here's an attempt at the Super Expander, hope I got that one right.

Super Expander.vrt

Ray...

Pedro Lambrini · Post by **Pedro Lambrini** » Wed Aug 15, 2012 12:10 pm

So, is the hope that this will be a future standard for Vic cart images? Will that mean that emulation will have to support both old and new formats? Does this affect the future of GB20 at all?

Just curious.