Suggestions for GP cart

[brain]

I am putting the finishing touches on an RS232 VIC-20 cart, and I am using a PLD to realize the addressing logic. As an aid, the cart also contains some FLASH ROM and a bank register to access all of it from the VIC-20. The FLASH is seen in BLK5

The requirements thus far have pushed me to a 64 pin CPLD, and I don't need all of those pins. So, before I button up this design, does the community have any suggestions on things to add in the footprint (the PCB has to be a certain size, so you pay for that copper whether you use it or not. I figured I could lay out IC footprints for other stuff if there is interest, and deal with the rest later.

I know there is FE3 and MegaCart, so there's little need for all of those features. Yet, I did want to add RAM1,2,3 and BLK 1,2,3,5 RAM to this device, since one of the targets is a Terminal Emulator, and I suspect it'll need as much RAM as I can provide it. As well, I suspect it'll need 16kB of ROM, so I'll need a way to map the FLASH into more than 1 bank.

I can add these features to the CPLD, but is there a Mega-Cart or FE3-approved location for these features?

Jim

[Mike]

I can add these features to the CPLD, but is there a Mega-Cart or FE3-approved location for these features?

Mega-Cart or FE3 use a set of registers in the I/O2 ($9800 .. $9BFF) or I/O3 ($9C00 .. $9FFF) range of addresses. Of course the exact mapping of these registers is only relevant for their respective firmware.

Some cartridge images (and maybe also a few other programs/games) take the initialisation of the colour RAM (located at $9400 .. $97FF) a little bit too seriously, and overwrite some bytes at the beginning of I/O2. Therefore, using I/O3 for control registers might be a better choice.

If you would provide 2 MB RAM on the cartridge, and allow for four registers to assign BLK1..3 and BLK5 freely to any of the 256 possible 8K blocks (with the option to make any of the BLK read/write or read only) that would give your cartridge an interesting feature set. Even better would be a RAM-link like access to SD cards.

Greetings,

Michael

[brain]

I can add these features to the CPLD, but is there a Mega-Cart or FE3-approved location for these features?

Mega-Cart or FE3 use a set of registers in the I/O2 ($9800 .. $9BFF) or I/O3 ($9C00 .. $9FFF) range of addresses. Of course the exact mapping of these registers is only relevant for their respective firmware.

Some cartridge images (and maybe also a few other programs/games) take the initialisation of the colour RAM (located at $9400 .. $97FF) a little bit too seriously, and overwrite some bytes at the beginning of I/O2. Therefore, using I/O3 for control registers might be a better choice.

If you would provide 2 MB RAM on the cartridge, and allow for four registers to assign BLK1..3 and BLK5 freely to any of the 256 possible 8K blocks (with the option to make any of the BLK read/write or read only) that would give your cartridge an interesting feature set. Even better would be a RAM-link like access to SD cards.

Greetings,

Michael

My plan thus far is to devote a register to:

enable RAM1,2,3
enable BLK1
enable BLK2
enable BLK3
enable BLK5
.
.
.

and another register for:

RAM1,2,3 is RAM or ROM (0 is ROM, 1 is RAM)
BLK1
BLK2
BLK3
BLK5
.
.
.

and then 5 registers:

RAM1,2,3 BANK (8 bits)
BLK1 BANK (8 bits)
BLK2 BANK (8 bits)
BLK3 BANK (8 bits)
BLK5 BANK (8 bits)

Thus, BLK3 access would point to an 8kB "page" of the larger ROM, and multiple banks could point to the same page.

ROM is a 39F0X0. RAM could be anything. Is 2MB needed?

As you can see, I have 6 open bits, and an entire extra register I can create (the UART takes 8 bytes, and I can stuff 8 registers in the other half of the memory map. If I implement the above, I am only using 7 registers.

Jim

[Mike]

You could interpret the bit pairs of the two enable/RAM/ROM registers as follows:

%00: no access (BLK appears like unconnected space to the CPU)
%01: BLK points to ROM chip
%10: BLK points to RAM chip, read only
%11: BLK points to RAM chip, read/write

The five page registers for RAM1..3, BLK1..3 and BLK5 go exactly in the right direction.

Is 2MB needed?

There are a lot of cool ideas that could be done with 2 MB and that set of page registers. For the time being, I could easily imagine a port of Kananga's RAM Disk to your design, where it wasn't necessary to circumvent some idiosyncrasies of the FE3 in Super-RAM mode.

The very same RAM Disk could also serve as foundament for the RAM-link like access to SD Cards. Especially on the VIC-20, a DOS-level 'emulation' of the drive would be sufficient, giving mostly the same compatibility level as disabling the true drive emulation in VICE or using a SD2IEC on real hardware. But the data wouldn't need to go over the serial bus anymore, the data could be 'pumped' into the RAM with some sort of CPU emulated DMA.

[brain]

You could interpret the bit pairs of the two enable/RAM/ROM registers as follows:

%00: no access (BLK appears like unconnected space to the CPU)
%01: BLK points to ROM chip
%10: BLK points to RAM chip, read only
%11: BLK points to RAM chip, read/write

I like that. I implemented the other last night, but I'll change it

The five page registers for RAM1..3, BLK1..3 and BLK5 go exactly in the right direction.

Is 2MB needed?

There are a lot of cool ideas that could be done with 2 MB and that set of page registers. For the time being, I could easily imagine a port of Kananga's RAM Disk to your design, where it wasn't necessary to circumvent some idiosyncrasies of the FE3 in Super-RAM mode.

Can you point to a link or document that explains the idiosyncrasies?

Jim

[brain]

Some notes:

* I found 8Mb (1MB) RAM and FLASH for not a ton of coin, but nothing larger unless you do 3V3, and I'd rather no get into level shifters for this project. So, is 1MB of each sufficient to design for?
* I redid the registers as you noted.
* Does ROM need to be visible in RAM1/RAM2/RAM3?
* Does RAM1/RAM2/RAM3 need to have a bank register, or would it be best to tie those locations to bank 0?
* Except for a way to read SD card, did I miss anything?

I ask because I see a great deal on xc9572xl parts online, and thus I'd like to use them if I can on this. But, that sets an upper bound on the number of things that can be done in a cart. Is some sort of reset circuitry needed?

Jim

[Mike]

Can you point to a link or document that explains the idiosyncrasies?

Main issue was, that in Super-RAM mode, the RAM could only be switched in whole 32K blocks, which made the implemenation of the RAM Disk (or any other use) difficult to say the least.

* I found 8Mb (1MB) RAM and FLASH for not a ton of coin, but nothing larger unless you do 3V3, and I'd rather no get into level shifters for this project.

There are the LY62W20488 (Lyontek) and BS62LV1605 (BSI), both of which are 5V compatible.

* Does ROM need to be visible in RAM1/RAM2/RAM3?
* Does RAM1/RAM2/RAM3 need to have a bank register, or would it be best to tie those locations to bank 0?

I could made up some uses for ROM in RAMx (for ready-made banking routines, or the like), likewise question the need for a banking register ...

Aside: as the full address appears on CAx, you can simplify the logic a bit by combining /RAM1, /RAM2 and /RAM3 into one /RAM signal and using the $0400 .. $0FFF range of a given 8K block - in case you already hadn't done this.

... but then at least my opinion for this is not quite neutral as my VFLI mod needs to block external expansions in that range anyway.

Is some sort of reset circuitry needed?

There should be an external reset switch, which restores the paging registers, so the firmware gets activated with the necessary amount of RAM, and an internal reset which then can then be used to start cartridge images.

[brain]

There are the LY62W20488 (Lyontek) and BS62LV1605 (BSI), both of which are 5V compatible.

Can you share your source? Newark quotes $22.19 for LY62W20488 in singles, which is farr too expensive to even consider.

I could made up some uses for ROM in RAMx (for ready-made banking routines, or the like), likewise question the need for a banking register ...

Is it worth moving to the next larger PLD? Right now, unless I can simplify the logic a bit, I am at 64 equations, and ISE is having fits synthesizing anything more into the '72

Aside: as the full address appears on CAx, you can simplify the logic a bit by combining /RAM1, /RAM2 and /RAM3 into one /RAM signal and using the $0400 .. $0FFF range of a given 8K block - in case you already hadn't done this.

Yep, did that:

assign ram_sel = (!RAM1 | !RAM2 | !RAM3);

There should be an external reset switch, which restores the paging registers, so the firmware gets activated with the necessary amount of RAM, and an internal reset which then can then be used to start cartridge images.

So, a jump to the $(fffx) vector from SW is not good enough? A true "sta x" that will trigger a reset required?

Jim

[brain]

Bump. Need to understand the need for a software "reset" as opposed to simply calling the init code in the VIC.

I *might* have 1 bit left over for this, but I also think I need a "lock out" feature, to preserve the registers until reset. Trying to fit this into the CPLD and try it out.

Jim

[brain]

I thank everyone for the sugegstions. I've tried to incorporate as many as possible. The CPLD, at present, implements the following:

• bank registers in IO3, at the top of the address space.
• a 6 bit bank register for each BLK segment in the memory map, as well as a 6 bank register for RAM1/2/3
• a register that will select either nothing, ROM, read only RAM, or RW RAM in each of the 4 BLK segments and the RAM/1/2/3 segment (using 2 bits per segment)
• a register bit to software reset the device, without changing the bank registers
• a register bit to turn off write accesses to the bank registers,

It looks like 512kB (4Mb) SRAM is available (5 address bits) and 1MB (8Mb) FLASH is available for this solution at reasonable prices. At present, the CPLD is full, but I wanted to see if I am missing a critical item for a RAM expansion option before I floorplan the CPLD and layout a board.

Jim

[Mike]

Sorry, I must have missed the last bump:

Need to understand the need for a software "reset" as opposed to simply calling the init code in the VIC.

Some cartridge games require the timer values in the VIAs be reset just like after a power on. Simply calling the init code does not suffice in this case. That had been discussed with Moon Patrol and Ms. Pacman in this thread (link), and IIRC there was also a racing game with the same issue.

a register bit to turn off write accesses to the bank registers,

So this one would one-way 'remove' the CPLD registers from the memory map, turning the cart into a 'pure' memory expansion until the next power cycle or external hard reset (similar as the MMU in the C128 does when changing to C64 mode)?

Greetings,

Michael

[brain]

Some cartridge games require the timer values in the VIAs be reset just like after a power on. Simply calling the init code does not suffice in this case. That had been discussed with Moon Patrol and Ms. Pacman in this thread (link), and IIRC there was also a racing game with the same issue.

In that thread, it sounded at the end like a RAM expansion setting. Am I wrong?

So this one would one-way 'remove' the CPLD registers from the memory map, turning the cart into a 'pure' memory expansion until the next power cycle or external hard reset (similar as the MMU in the C128 does when changing to C64 mode)?

Yep. Thoughts?

jim

[Mike]

In that thread, it sounded at the end like a RAM expansion setting. Am I wrong?

Hmm, not quite sure. Ms. Pacman and Moon Patrol got mentioned again in a later thread, the post also by nbla000, where he describes a so-called 'clean reset' (link). The POKEs featured there also reset the VIA timers and disable interrupts before entering into the reset routine, so this is slightly more elaborated. A reset initiated by the CPLD on your cart would at least save some typing here.

So this one would one-way 'remove' the CPLD registers from the memory map, [...]?

Yep. Thoughts?

This is Good Thing™ for 100% compatibility with standard RAM expansions or with the unexpanded VIC-20.

[brain]

OK, well, two things:

1) Any chance someone could look over my Verilog and see if I have missed anything? I am running right at the edge of the 9572XL space, and I would really prefer to use that, as I got a good deal on 500 of them.
2) Where should I put the registers and how should I organize them? Right now, they are:

IO3, last 8 bytes in the 1024 byte bank.
BASE:
7 = RESET
6
5
4
3
2 = LOCK REGISTERS
1:0 (RAM1/2/3 config: 00= off, 01= ROM, 10= RAM RW, 11 = RAM RO)

(Not sure if this is the right layout. I think the LOCk REGISTERs bit should go in bit 6, but I can't seem to get the Verilog to compile when I do that. *MAYBE*, I should put them at BASE+2, but that is even harder to synthesize into the CPLD)

BASE+1:
7:6 (BLK5 config)
5:4 (BLK3)
3:2 (BLK2)
1:0) BLK1)

BASE+2 nothing
BASE+3: RAM bank
BASE+4: BLK1 bank
BASE+5: BLK2 bank
BASE+6: BLK3 bank
BASE+7: BLK5 bank

The UART is at either IO2 or IO2, $00-$07, and can be user selectable for IO
The entire cart is enabled via a switch.

I'm planning two versions of the cart PCB. One will not include the UART and just be the RAM expansion, while the other will maybe have less RAM/ROM and the UART onboard.

[metalfoot76]

Jim, would this cartridge theoretically be able to be used as a printer interface and a switchable RAM expansion?