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 listReceived on 2015-09-06 07:00:07
Archive generated by hypermail 2.2.0.