CRT format for the VIC-20

[eslapion]

Back in 1981, almost all the VIC-20 cartridge images were turned into single filers that worked really well when using 16k RAM expansions to run them. This was done using a simple trick created by a member of a VIC-20 user's club in eastern Quebec.

I think it's possible to take advantage of this old trick to create a simple .CRT file format for the VIC-20

The trick was really simple and was based on the following facts:
1. All autostart cartridges of 8k or 4k only use BLK5
2. All autostart cartridges of 16k use BLK5 along with BLK1 or BLK3 - they NEVER use BLK2
3. All Scott Adams games use BLK2 and BLK3 - they never use BLK1 or BLK5
4. VICMON did not allow saving data above $7FFF

The trick involved adding a switch to a 16k RAM expansion for the VIC-20 which would toggle an 8k block of RAM between BLK2 and BLK5 with the VIC-20 turned on. The same switch would turn the expansion to read-only when set to BLK5.

For autostart cartridges of 8k or less, the content of the ROM would be first copied into BLK2 and saved from this address. When loading back the game, the expansion would be set to have normal RAM at BLK2 then the switch would be toggled to BLK5/read only and pressing the reset button would start the game.

For autostart cartridges of 16k, the content of the BLK5 ROM would be copied into BLK2 and this would make the data present either at BLK1 and BLK2 (for games like Donkey Kong or Lunar Leeper) or BLK2 and BLK3. Either way, the data you saved was now a single block of 16kBytes. When loading back the game, the expansion would be set to have normal RAM at BLK2 then the switch would be toggled to BLK5/read only and pressing the reset button would start the game. The only difference was you had to make sure the 'other' block of 8k RAM was present in BLK1 or BLK3 depending on the requirements of the specific game you're trying to play.

For Scott Adams games, you had to set your 16k expansion to offer RAM in BLK2 and BLK3 only. The RAM would be invisible to BASIC and Scott Adams games don't self modify to protect against copying. Just load the file and start with the usual SYS32592.

I think this can be used as a template for .CRT files for the VIC-20. I even think it's possible to use this unified format 'as is'.

When using these only 'unified' files, it's possible in software to determine:
1. The 2 first bytes indicating the LOAD address - a loading address of $6000 could indicate you're dealing with a utility such as VICMON or Programmer's Aid.
2. Finding where in the data is the CBMA0 signature in files of 8k or less - the presence of the signature indicates the data normally loaded in BLK2 has to be moved to BLK5 and the BLK areas used are to be made read-only.
3. Finding where in the data is the CBMA0 signature in a 16k file with a loading address of $4000 - the absence of such a signature is an indicator you're dealing with a Scott Adams game - the presence of the signature indicates the data normally loaded in BLK2 has to be moved to BLK5 and the BLK areas used are to be made read-only with the rest of the data loaded in BLK3
4. A loading address of $2000 along with the presence of the CBMA0 signature should indicate the file contains a 16k games requiring the first part of the data to be loaded in BLK1 and the rest is destined to BLK5.

I think that sums all the possible cases. The way cartridge images are stored in the Behr-Bonz ROM is based on the above.

[Mike]

The method you outlined was probably the best available given the resources at the time, but if the VICE team would base a file format on this, that would limit its use to the range of contemporary cartridges. In the meantime, cartridges with full 32K non-paged ROM have appeared; and with cartridge hardware like Ultimem, dedicated paged ROM games with more than 32K size appear feasible.

If I understand you correctly, that special hardware involved an 8K RAM expansion mapped in at either BLK1 or BLK3, and an additional 8K RAM expansion which could be toggled between BLK2 (read/write) and BLK5 (read only).

Most of those files could be reused on standard hardware (and in VICE) with a 32K RAM expansion by utilizing a small program that simply swaps the contents of BLK2 and BLK5:

Code: Select all

1 FORT=0TO37:READA:POKE673+T,A:NEXT
2 :
3 DATA 169,64,133,252,169,160,133,254,169,0,133,251,133,253,168,162,32,177,251,72
4 DATA 177,253,145,251,104,145,253,200,208,243,230,252,230,254,202,208,236,96

Code: Select all

.02A1  A9 40     LDA #$40
.02A3  85 FC     STA $FC
.02A5  A9 A0     LDA #$A0
.02A7  85 FE     STA $FE
.02A9  A9 00     LDA #$00
.02AB  85 FB     STA $FB
.02AD  85 FD     STA $FD
.02AF  A8        TAY
.02B0  A2 20     LDX #$20
.02B2  B1 FB     LDA ($FB),Y
.02B4  48        PHA
.02B5  B1 FD     LDA ($FD),Y
.02B7  91 FB     STA ($FB),Y
.02B9  68        PLA
.02BA  91 FD     STA ($FD),Y
.02BC  C8        INY
.02BD  D0 F3     BNE $02B2
.02BF  E6 FC     INC $FC
.02C1  E6 FE     INC $FE
.02C3  CA        DEX
.02C4  D0 EC     BNE $02B2
.02C6  60        RTS

Start with SYS673. I wrote "most" because this small tool wouldn't write-protect BLK5, and thus would rely on fixed cart dumps in case this is an issue.

Greetings,

Michael

P.S. regards: "4. VICMON did not allow saving data above $7FFF" - this is a limitation of the KERNAL tape routines. Not of VICMON.

P.P.S. (just nitpicking:) VIC-20 cartridges use "A0CBM" as signature at $A004.

P.P.P.S. Another thread here in Denial highlighted a proposed VRT format. I wonder what came out of this ...

[eslapion]

The method you outlined was probably the best available given the resources at the time, but if the VICE team would base a file format on this, that would limit its use to the range of contemporary cartridges. In the meantime, cartridges with full 32K non-paged ROM have appeared; and with cartridge hardware like Ultimem, dedicated paged ROM games with more than 32K size appear feasible.

I see this old structure as a template you can expand on. Not as a complete file format model. The 3 keys indicating how to parse the file being the location of the CBMA0 signature, the loading address and the size of the file.

If you're dealing with a file of 24k (24578 bytes) with a loading address of $2000 and the CBMA0 signature is starting at byte 8195 then you have a 24k cart loading into BLK 1, Blk3 and BLK 5. With the data virtually loaded in BLK2 needing to be transferred to BLK5. This file you could still actually load with a VIC-20 fitted with a 24k RAM expansion and a switch to toggle a 8k block between BLK2 and BLK5.

If you're dealing with a file of 32k (32770 bytes) with a loading address of $2000 and the CBMA0 signature is starting at byte 24579 then you have a 32k cart loading into BLK 1,2,3 and 5.

... and plenty of other possible combinations.

If I understand you correctly, that special hardware involved an 8K RAM expansion mapped in at either BLK1 or BLK3, and an additional 8K RAM expansion which could be toggled between BLK2 (read/write) and BLK5 (read only).

Back in 1981-1983, RAM expansions of more than 16k were extremely rare so the most popular expansion to use to pirate cartridges were the VIC-1111 16k RAM expansion. Internally, it has switches to manage where you place the two 8k RAM blocks it contains. These switches only allow changing the BLK areas when you open up the cart's casing.

People would drill 2 small holes in the case in the rear corners and install a pair of DPDT switches which were the smallest kind available at Radio Shack so they could toggle the blocks while the VIC-20 was still on. The first one would toggle one block between BLK 1 and BLK3 and the other one would toggle the second block between BLK2 and BLK 5 and turn the cart read-only when switched to BLK5.

Most of those files could be reused on standard hardware (and in VICE) with a 32K RAM expansion by utilizing a small program that simply swaps the contents of BLK2 and BLK5:

Yeah but that doesn't work when you have cartridges that have self modifying code. That's why the second switch also made the expansion read-only.

[Mike]

I see you still "insist" on calling the cartridge signature by "CBMA0". The VIC-20 KERNAL checks for "A0CBM", really. On the C64, it's "CBM80" instead - maybe this is the reason you confuse this.

[...] this old structure [is] a template you can expand on. Not as a complete file format model. The 3 keys indicating how to parse the file being the location of the [A0CBM] signature, the loading address and the size of the file. [...] People would drill 2 small holes in the case in the rear corners and install a pair of DPDT switches which were the smallest kind available at Radio Shack so they could toggle the blocks while the VIC-20 was still on. The first one would toggle one block between BLK 1 and BLK3 and the other one would toggle the second block between BLK2 and BLK 5 and turn the cart read-only when switched to BLK5.

One way to implement this is VICE would be a dedicated "cartridge", that provided those two switches by key shortcuts, Alt-R is the reset anyway.

The handling would still be different compared to real hardware: on the VIC-20, you'd simply load the file, perform the necessary switch actions (before and after load) and then do the reset. In VICE though, you'd still have to go over a dedicated menu, as VICE otherwise has no way to tell that the file format you described is somehow different than a normal *.prg file - even not by file extension. In Unix (and that is what the majority of VICE developers use, and many users) programs generally ignore file extensions and only use the contents of files to determine what they're about.

At some point you'll have to weigh this against other, already working, solutions: a database like GB20, which already contains "off-line" information and attaches cartridges with command line switches. Alternatively, a boot loader which loads the cartridge dump parts to RAM and issues SYS64802. As you note, the latter method fails with self-modifying code. Then the other fall back method still works.

...

Personally, I see no big hurdle in using the multi-file cartridge dumps. True, it's a recurring question here on Denial, but then it's also easily answered most of the time. Sometimes, cartridges need extra handling, like "Buck Rogers" did recently, because it doesn't like extra RAM in BLK1.

And if someone is in "cartridge exploring mode", but doesn't want to install GB20, he can also attach one of the Mega-Cart cartridge dumps floating around.

[eslapion]

I see you still "insist" on calling the cartridge signature by "CBMA0". The VIC-20 KERNAL checks for "A0CBM", really. On the C64, it's "CBM80" instead - maybe this is the reason you confuse this.

I insist that my brain is made up of neurons, not digital circuits so accuracy becomes relative with age. The explanation you provide for my confusion seems perfectly acceptable.

One way to implement this is VICE would be a dedicated "cartridge", that provided those two switches by key shortcuts, Alt-R is the reset anyway.

Switches ? If the VIC-20 mode of VICE offered the option to load 'cartridges' in the menus, why bother with switches ?

A .PRG or .CRT file which happens to load the A0CBM signature at $4000 exactly should automatically be parsed as requiring the transfer of the data destined to BLK2 into BLK5 and setting all BLK areas to read only then performing a hard reset.

The handling would still be different compared to real hardware: on the VIC-20, you'd simply load the file, perform the necessary switch actions (before and after load) and then do the reset. In VICE though, you'd still have to go over a dedicated menu, as VICE otherwise has no way to tell that the file format you described is somehow different than a normal *.prg file - even not by file extension. In Unix (and that is what the majority of VICE developers use, and many users) programs generally ignore file extensions and only use the contents of files to determine what they're about.

Desperately looking for the most complicated way to do things. The parsing I indicated in my previous post avoids everything you just mentioned here. A normal .PRG file will never happen to load the A0CBM signature exactly at $4000. Also, what good is a 'LOAD CARTRIDGE' function in a pull down menu if it's not to tell the software this specific file should be treated differently ?

Everything I posted above is a step by step guide precisely to avoid the problem you indicate here. Here's how you should parse the file to know exactly what to do...

At some point you'll have to weigh this against other, already working, solutions: a database like GB20, which already contains "off-line" information and attaches cartridges with command line switches. Alternatively, a boot loader which loads the cartridge dump parts to RAM and issues SYS64802. As you note, the latter method fails with self-modifying code. Then the other fall back method still works.

Well, GB20 doesn't work correctly with cartridge images. The point of having a .CRT file format is that it works fine with cartridge images.

Personally, I see no big hurdle in using the multi-file cartridge dumps. True, it's a recurring question here on Denial, but then it's also easily answered most of the time. Sometimes, cartridges need extra handling, like "Buck Rogers" did recently, because it doesn't like extra RAM in BLK1.

The problem is, it's not up to you at all... multi-file fails...

If a user instead opens a specific file, or saves to a new file, the system makes the specified file, and that file alone, available to your app.

As per https://developer.apple.com/library/arc ... 3-CH3-SW17

And if someone is in "cartridge exploring mode", but doesn't want to install GB20, he can also attach one of the Mega-Cart cartridge dumps floating around.

I'm sorry to say this but not every cartridge image is present in the Mega-Cart, old or new.

[Mike]

All fine by then ...

Everything I posted above is a step by step guide precisely to avoid the problem you indicate here. Here's how you should parse the file to know exactly what to do...

... but maybe you should file a feature request on the VICE sourceforge page. The step-by-step procedure you give should be detailed enough to refine the "smart-attach cartridge" feature of VICE.

Well, GB20 doesn't work correctly with cartridge images.

Oh, hum? Maybe that's something Mayhem should know about?

The problem is, it's not up to you at all... multi-file fails... [...]

I see this has also been discussed in another thread here in Denial. For me, that's a restriction unnecessarily imposed by people who have a somewhat skewed view on how to build a secure VM sandbox. Doesn't matter they're from Apple. If one provides a directory share, of course it shouldn't be possible to 'escape' into the host file system by repeatedly prepending "../" to a file path.

I'm sorry to say this but not every cartridge image is present in the Mega-Cart, old or new.

But it's a good start for >95% of all cartridges, or isn't it?

[eslapion]

All fine by then ...

... but maybe you should file a feature request on the VICE sourceforge page. The step-by-step procedure you give should be detailed enough to refine the "smart-attach cartridge" feature of VICE.

I feel very old all of a sudden. Does this involve using a soldering iron and putting chips on a PCB using drag soldering or perhaps through hole components ?

If not, I have to admit my obsolescence is massively catching up with me.

Can some kind soul take up on the challenge ?

[groepaz]

we'll likely use a very similar approach as with C64 .crt files.... actually the existing .crt format already provides pretty much all that is needed (minus some details that can be added easily). ie the idea is to reuse as much of the specs and the code as possible - which reduces the amount of work, and bugs

that said, a format like suggested above wont cut it, like mike explained... a .crt format must work for all and everything. vice already emulated behr bonz and some other "modern" cartridges - how would those be represented in the above scheme?

[eslapion]

we'll likely use a very similar approach as with C64 .crt files.... actually the existing .crt format already provides pretty much all that is needed (minus some details that can be added easily). ie the idea is to reuse as much of the specs and the code as possible - which reduces the amount of work, and bugs

Why do simple when you can do (needlessly) complicated ?

that said, a format like suggested above wont cut it, like mike explained... a .crt format must work for all and everything. vice already emulated behr bonz and some other "modern" cartridges - how would those be represented in the above scheme?

It already works as is for everything up to 16k. For anything larger, you really just have to look for the A0CBM signatures.

The content of the Behr-Bonz is a daisy chain of 16k images that follow exactly what was described above.

If you feel like it then by all means, please reinvent the wheel...

[Mike]

Why do simple when you can do (needlessly) complicated?

People do have different judgments what is simple and what is complicated.

Your proposed format is mostly motivated by ease of use on real hardware, with a good deal (but not all!) ROM contents of existing cards.

It does, however, not generalize well upon cartridges that don't conform to the layout you propose. If you only take the four 8K blocks: there are in principle 16 possible ways to populate them with memory. If you differentiate between RAM and ROM, that would be 3^4 = 81 ways. Then there are also the RAMx blocks, and finally the I/O area, which needs extra handling.

And then, your format just doesn't deliver anymore. If there is already code in x64, etc. to handle cartridge images within a container format, it is much easier for the VICE team to adapt this code to the xvic. Adapt, rather than writing new code for your format which then anyhow would only be capable to handle a subset of all conceivable cartridges.

Files of such a container format then of course wouldn't work directly on a real VIC-20 anymore. It needs a conversion program which takes the current ROM dumps (*.prg, or *.bin without load address) and produces a *.crt (or *.vrt) from these, but which ideally should also be capable of extracting the ROM dumps from the *.crt file once again.

[groepaz]

Why do simple when you can do (needlessly) complicated ?

it not more compicated. its more generic and simpler.

It already works as is for everything up to 16k. For anything larger, you really just have to look for the A0CBM signatures. The content of the Behr-Bonz is a daisy chain of 16k images that follow exactly what was described above.

doh. and now think about a cartridge that doesnt just contain a bunch of images from other cartridges. how does it deal with RAM in I/O for example? how does it deal with multiple ROM banks that contain no startup signatures?

If you feel like it then by all means, please reinvent the wheel...

the whole point is to not reinvent anything - the .crt format and the code dealing with it exists already.

Files of such a container format then of course wouldn't work directly on a real VIC-20 anymore. It needs a conversion program which takes the current ROM dumps (*.prg, or *.bin without load address) and produces a *.crt (or *.vrt) from these, but which ideally should also be capable of extracting the ROM dumps from the *.crt file once again.

thats hardly a problem. of course you cant take .crt files and burn them on eproms 1:1 - but loading them and dealing with them on the real thing is no problem at all. and yes, cartconv obviously also already exists

[eslapion]

Your proposed format is mostly motivated by ease of use on real hardware, with a good deal (but not all!) ROM contents of existing cards.

There you have the 2 advantages summed up. If you're dealing with something larger than 16k then it's worth doing a form of encapsulation resembling what's done with the C64 .CRT files.

As I said, the above is only a template to work from because it then works with both the emulators and the real hardware.

You could have an impossible load address (the first 2 bytes) point to something like $FFFF to indicate what follows is in a different structure altogether and then... do as Groepaz suggests.

[groepaz]

its no problem at all to deal with .crt like files on real hardware, if you really wanted.

[eslapion]

its no problem at all to deal with .crt like files on real hardware, if you really wanted.

Yeah... all you need is a bit of software and a 37k expansion...

Just a little detail here... the file structure suggested in the OP would work with just about 100% of cartridge images coming from carts made prior to 1986, the year the VIC-20 vanished from store shelves.

You prefer .CRT (a container similar to the C64 version) because it would also support cartridges made afterwards which have exotic capabilities.

How much trouble would be it to add support for the old combined format ? I am absolutely convinced it would be little peanuts. it would also allow anyone with a VIC-20 and only 8k of RAM or 16k of RAM expansions to directly use these files.

... but I was the one who suggested it so it's no good.

May I at least suggest you take a look at the attached .D64 content before you close the coffin shut ?

VIC16L-T.zip

A small group of 16k VIC carts images in 1981 format.

(84.38 KiB) Downloaded 73 times

[groepaz]

all you need is a bit of software and a 37k expansion

no, just a small loader - which you will need anyway, also for your format

You prefer .CRT (a container similar to the C64 version) because it would also support cartridges made afterwards which have exotic capabilities.

indeed. a format that is limited for no apparent reason makes no sense for VICE - we need a format that covers everything (hopefully capable of covering even stuff that does not yet exist)

How much trouble would be it to add support for the old combined format ? I am absolutely convinced it would be little peanuts.

VICE can (and always could) *already* load combined files. it just makes no assumptions and loads into subsequent blocks always - so you might have to fill some block with zeros for some of those carts. no, we will certainly add no magic guessing.

it would also allow anyone with a VIC-20 and only 8k of RAM or 16k of RAM expansions to directly use these files.

as said, no problem with a .crt like format either. actually .crt wont be much different from your proposal - except a little bit more well defined and with some chunk headers - no problem at all, since you need a loader anyway.

but I was the one who suggested it so it's no good.

you really are obsessed with this are you? no - it'd be a bad idea no matter who suggested it.

May I at least suggest you take a look at the attached .D64 content before you close the coffin shut ?

what should i look for? i have all those old vic20 cart images right here