Re: final cartridge for vic 20

From: Marko Mäkelä <>
Date: Sun, 6 Sep 2015 22:24:21 +0300
Message-ID: <20150906192421.GA1734@x220>
On Sun, Sep 06, 2015 at 01:50:06AM -0500, Jim Brain wrote:
>It does.  Though I have not set the register map in stone, the config 
>is as follows:
>    Config 1:
>    0-1: RAM Config (00 = absent, 01 = ROM, 10 = RAM R/W, 11 = RAM RO)
>    3:2: RAM high bank

I do not get these.

>    Config 2:
>    1-0: BLK1 Config (00 = absent, 01 = ROM, 10 = RAM R/W, 11 = RAM 
>RO) $2000
>    3-2: BLK2 Config (00 = absent, 01 = ROM, 10 = RAM R/W, 11 = RAM 
>RO) $4000
>    5-4: BLK3 Config (00 = absent, 01 = ROM, 10 = RAM R/W, 11 = RAM 
>RO) $6000
>    7-6: BLK5 Config (00 = absent, 01 = ROM, 10 = RAM R/W, 11 = RAM 
>RO) $a000 // default is BLK5 ROM enabled.
>    Bank Hi Reg:
>    1-0: BLK1 high order bank bits
>    3-2: BLK2 high order bank bits
>    5-4: BLK3 high order bank bits
>    7-6: BLK5 high order bank bits

If you want to directly map ROM at BLK[123], the allocation of the ROM 
images could become interesting. It might work in practice if you used 
FAT with a logical sector size of 8kB, but in that case your image files 
would have to lack any header.

I think it would be simplest to let the processor copy the data from 
flash to RAM, mapping the flash only at BLK5. If you have spare capacity 
on the chip, implement a DMA controller that does the copying. :)

>    RAM1/2/3 Bank Reg 7:0
>    BLK1
>    BLk2
>    BLK3
>    BLK5

I see, you are using the bank register for both RAM and flash bank. With 
RAM, the high-order bit of each register would be unused.

>Well, I might be able to support this register mapping, but it does 
>differ somewhat from the current one I am using.

I am OK with any register mapping, as long as the existing functionality 
can be implemented with it. And it seems it can.

>I have had a request to offer a way to map RAM into IO2 and IO3 for 
>extra capability, so I am considering how I might do that in the same 

Sounds good, it could be used by some KERNAL extensions, such as the 
file system driver that I proposed.

>I'm happy to obtain help.  Well, since I have the prototype right here 
>and I can test with the real hardware, VICE is not as much a need for 
>me.  As you can see, still trying to decide what register layout makes 
>the most sense from a programming point of view.

The register layout would be easy to change by patching the VICE source 
code as well. I think I would prefer to do that.

>Thomas Giesel's (sp?) EasyFlash already contains a 6502 FLASH ROM 
>programming code, so it should be easy to adapt.

I also wrote a 6502 flash programmer for the Am29F032B. See flash4.s in 
the archive. On the Vic Flash Plugin it is a little tricky, 
because I deliberately swapped the address lines A0 and A1 to obtain a 
cleaner board layout. On the first version (with 512k flash) it was even 
more obfuscated, swapping more address line and data lines.

>Hppy to send a unit for development.  It is a Xilinx XC95144XL, 
>MX29LV640 and AS6C8008 on the card.  ISE WebPack would be useful to 
>modify the CPLD.

Thanks, but I think it is most convenient for me to work with emulated 
hardware, because I am afraid that working with CPLDs requires 
proprietary software. Once we have the register mapping, it should be 
easy to implement in VICE.


       Message was sent through the cbm-hackers mailing list
Received on 2015-09-06 20:00:07

Archive generated by hypermail 2.2.0.