Re: final cartridge for vic 20

Hi Jim,

On Thu, Sep 03, 2015 at 10:11:40PM -0500, Jim Brain wrote:
>On 7/11/2015 6:13 AM, didier derny wrote:
>>I was thinking to something simple, a small flash / eprom with a 
>>menu to load a cartridge image to a ram
>>mapped at the cartridge location and write protected
>>
>>the vic20 is quite far for me :) I've not really use one since 1985...
>>(except to repair and play a little bit with the board I just repaired
>>
>>so I'll have to check that I'm not totally wrong :) about this machine
>If you are still interested in this, I am putting the finishing 
>touches on a small 3 IC design I have working on the bench:
>
>8MB FLASH
>1MB SRAM
>CPLD
>It supports a bank register for each of 5 memory banks:
>
>RAM1/2/3
>BANK1
>BANK2
>BANK3
>BANK5

This sounds very much like my 3-chip Vic Flash Plugin 
http://www.iki.fi/~msmakela/8bit/vfp/ which never went beyond the 
prototype stage, with the exception that we only used a 4MB flash and 
32kB SRAM. With more flash and SRAM, you would probably not want to 
bother with any compression at all (which I did bother with, because the 
original version only had 512k flash).

I would love to contribute to this.

The default configuration of the CPLD should map one 8kB page of the 
flash to BLK5 when the system is reset. The menu software (or the 
bootloader of it) would live there.

I guess, ideally the firmware (running on the Vic-20) could implement a 
flash-friendly file system that allows the same file operations as a 
1541 does, but with different internal layout (VFAT?). There could even 
be a "BASIC extender" mode that overrides the KERNAL vectors and allows 
BASIC to access the file system. There could also be a magic file name 
that can be loaded by the firmware at startup. This could be where the 
actual boot-up menu software resides. In this way, it would be more 
convenient to develop and update the menu software.

>Each bank can be in any 8kB spot of RAM or ROM, and either RAM, ROM, RO 
>RAM, or nothing can appear in each VIC-20 memory bank. Obviously, 
>someone needs to write a menu and programmer app...

That part is already basically done by me, at least for an initial part.  
What is critical at this point is that the registers implemented in the 
CPLD support all the features that the Vic Flash Plugin CPLD did.

This would be basically a simple port of the Vic Flash Plugin to your 
new hardware, just a proof-of-concept that it works. The initial port 
would only use 4MB flash and 32kB SRAM.

I found the Vic Flash Plugin register map in the source code.

bankreg = $9800 ; ROM bank switching register (A20..A13, default value $00)
cfgreg  = $9801 ; configuration register (default value $40)
	;; b7 == 1 => I/O2 disabled until RESET
	;; b6 == 1 => BLK5 write protect (default)
	;; b5 == 1 => RAM at BLK5 (instead of ROM)
	;; b4 => 0=3k (RAM1-3), 1=8k (BLK1)
	;; b3 == 1 => master RAM enable (BLK2,BLK3 is always enabled)
	;; b0 => A21

The flash is always mapped in BLK5; you can select the mapped 8kB page 
by $9800 and $9801.b1 above. In the Vic Flash Plugin, you can also 
choose to have RAM at BLK5. The menu software would decompress (using 
Pasi Ojala’s code) the images from flash to SRAM. This takes some 
seconds. It would be much faster to just copy the data from flash to 
SRAM, uncompressed.

As you can see, the two high-order bits of $9801 are trying to make the 
cartridge look like a normal fixed-banking cartridge. If you have spare 
capacity on the CPLD, I would propose individual "enable/disable RAM" 
bits for each of BLK1,BLK2,BLK3,BLK5 and RAM1..3. Maybe also "write 
protect" for BLK1,BLK2,BLK3,BLK5 individually. I guess you would also 
have a bank switching register for the SRAM.

While I have not spent any time on C= stuff in the past, I would love to 
participate in this project. I think that the first step would be that 
you modify VICE so that it emulates the new hardware.

The Vic Flash Plugin emulation is already there; you can download 
http://www.iki.fi/~msmakela/8bit/vfp/menu-s.bin.gz and then invoke VICE 
on it: xvic -cartfp menu-s.bin.gz

The next step would be that you give the VICE patch to me (with some 
comments in the source code that explain the register layout), and I 
will do the crude port of the Vic Flash Plugin to it. This should not 
take more than a couple of nights my time; I can promise to do it.

Further development is another question, because I generally get enough 
programming exercise in my day job. But, I guess that it should be 
doable in manageable steps, such as:

1. Remove the compression in both the image generator and the menu 
software.

2. (someone else) Write a file system driver that can be attached to the 
Vic-20 KERNAL LOAD and SAVE vectors.

3. Make the bootloader simply install the file system driver and then 
auto-start a magic file name, such as "menu".

4. Extract the menu software from the original firmware, and make it a 
stand-alone loadable program that will use the file system vectors for 
accessing the contents. At this step, we would define a format for the 
images. It could be some simple tag(parameter)-length-value scheme, such 
as, tag=copy($a000), length=$2000, value=[8192 bytes to be copied]. A 
single file could contain multiple such operations.

5. Improve the menu software.

I hope someone has usable 6502 file system code. Given that the flash is 
only 8MB, it could be mapped to something like 128 tracks with 256 
sectors each, in a 1541-style layout.

I think that the bootloader (with file system driver) should easily fit 
in the first 8KiB page that is mapped in BLK5 on system reset. The rest 
of the flash ROM would be in the format defined by the file system.

In the bootloader, just like in the Vic Flash Plugin, there could be 
short-circuits for some memory configurations. For example, hold one of 
the keys STOP, 3, 8 while releasing RESET, and you will exit directly 
into BASIC with unexpanded, 3k or 8k+ (24k) RAM expansion. A variant of 
that (e.g., SHIFT+STOP, SHIFT+3, SHIFT+8) would do the same, but 
completely hiding the extensions (the CPLD registers and the file system 
driver).

Maybe I could do some of this as a programming exercise with my now 
12-year-old son. He has recently shown some interest to programming, 
also on the 6502. The only thing that would be beyond my resources is 
the file system driver.

If the file system layout is (V)FAT, and the bootloader page is at the 
top end (last 8kB page) of the 8MB flash image, then I suppose that 
standard tools could be used for generating and manipulating the images 
during development.

	Marko

       Message was sent through the cbm-hackers mailing list