VRT file format

You need an actual VIC.

Moderator: Moderators

nojoopa
Vic 20 Drifter
Posts: 20
Joined: Wed Dec 02, 2009 9:17 am

VRT file format

Post by nojoopa »

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
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

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
Vic 20 Drifter
Posts: 20
Joined: Wed Dec 02, 2009 9:17 am

Post by nojoopa »

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
Vic 20 Drifter
Posts: 20
Joined: Wed Dec 02, 2009 9:17 am

Post by nojoopa »

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?
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

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
User avatar
buzbard
Vic 20 Devotee
Posts: 213
Joined: Sun Jul 03, 2005 9:10 am

Post by buzbard »

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.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

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
Vic 20 Drifter
Posts: 20
Joined: Wed Dec 02, 2009 9:17 am

Post by nojoopa »

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
Vic 20 Drifter
Posts: 20
Joined: Wed Dec 02, 2009 9:17 am

Post by nojoopa »

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
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Post by groepaz »

Someone may want to backport this to VICE.
someone throw a few such cartridge dumps into my direction please :)
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Post by groepaz »

noone cares?
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Post by tlr »

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
User avatar
buzbard
Vic 20 Devotee
Posts: 213
Joined: Sun Jul 03, 2005 9:10 am

Post by buzbard »

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

Avenger.vrt

Battlezone.vrt

I think these conform to nojoopa's specifications.

Ray...
Last edited by buzbard on Tue Feb 26, 2013 1:58 pm, edited 1 time in total.
User avatar
buzbard
Vic 20 Devotee
Posts: 213
Joined: Sun Jul 03, 2005 9:10 am

Post by buzbard »

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

Super Expander.vrt

Ray...
Last edited by buzbard on Tue Feb 26, 2013 1:59 pm, edited 1 time in total.
User avatar
Pedro Lambrini
Vic 20 Scientist
Posts: 1132
Joined: Mon Dec 01, 2008 11:36 am

Post by Pedro Lambrini »

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. :)
"...That of the Eastern tribe being like a multitude of colours as if a rainbow had settled upon its brow..." Daniels 1:3
Post Reply