Soliciting VIC-20 Internal memory expansion ideas

[brain]

Considering an internal VIC-20 memory expansion project for my own use, but thought I'd see if there's any external interest... My personal goal is to allow all the memory to be RAM, like on the C64, and also offer some KERNAL replacement options, via banking. Looks like the cheapest SRAM is essentially 256kB, and the 128kB FLASH ROM looks to be my cheapest option, but not sure the extra space is of any use.

In any case, would love to hear what others think...

Jim

[MCes]

In the past I try this:
http://sleepingelephant.com/ipw-web/bul ... vic#p98909

that was derived from:
http://sleepingelephant.com/ipw-web/bul ... f=3&t=7675

[Mike]

Hi, Jim,

one of my projects specifically aimed to make the $0400..$0FFF 'hole' accessible to VIC (this wouldn't be possible with an external cartridge). In doing so, I also extended the colour RAM from 1K nibbles to 16K nibbles with my VFLI mod.

One other project was intended to provide RAM under BASIC, KERNAL and character ROM. In case of the character ROM, CPU and VIC chip were supposed to be switched between RAM and ROM independently. I derived the necessary equations some time ago and there also exists a hand-drawn schematic with a bunch of TTLs, but the project didn't progress much beyond that stage. Actually, one of its intended uses was instead realised by just exchanging the BASIC ROM.

IMO, any other type of internal expansion has to weigh its functionality against what could likewise be provided by an external cartridge. A proper demultiplexer for all involved cartridge select signals would also be a requirement.

Michael

[Richardc64]

My personal goal is to allow all the memory to be RAM, like on the C64...

Jim

To bank ALL memory of a 64K range the banking has to be done from a location that does not and cannot get banked. The C64 accomplishes this with a 6-bit I/O port at locations 0000h and 0001h on the 6510 mpu. To add decoding for one of those locations for a R/W register (the 6510's Data Direction Register being unnecessary,) for VIC would require an inordinate amount of logic and would conflict with Basic's USR instruction. (Does anyone actually use that?)

The Configuration Register for my internal memory expansion lives at 914x in a more thoroughly decoded I/O space 9000h-9fffh. Aside from banking ROM or RAM for Character definitons, the remainder of BLocK4 is unbankable.

In case of the character ROM, CPU and VIC chip were supposed to be switched between RAM and ROM independently.

That sounds familiar

Edited spelling and clarity

[brain]

To bank ALL memory of a 64K range the banking has to be done from a location that does not and cannot get banked. The C64 accomplishes this with a 6-bit I/O port at locations 0000h and 0001h on the 6510 mpu. To add decoding for one of those locations for a R/W register (the 6510's Data Direction Register being unnecessary,) for VIC would require an inordinate amount of logic and would conflict with Basic's USR instruction. (Does anyone actually use that?)

Well, I think you're assuming facts not in evidence. I didn't say I wanted to use the same exact banking mechanism, just that I wanted to be able to swap in RAM across the address space. ONe cna select any set of locations for such a register, and allow it to be always banked in. I do it on lots of other projects.

Jim

[MCes]

For banking registers, read this: http://sleepingelephant.com/ipw-web/bul ... 216#p87216

because there are the VIAs area that can be better decoded for found others free registers address inside it.


Another example of possible solution that can be done inside the VIC: http://sleepingelephant.com/ipw-web/bul ... f=3&t=7706

[Richardc64]

I cited the C64 mechanism only as an example of a register that can't get banked out, regardless of where it might be located or the configuration it sets up.

(Obviously, my edit for "clarity" was lacking.)

[Mike]

Slightly off-topic, but anyway:

(Does anyone actually use [USR]?)

Yes. Me. Here.

[eslapion]

In any case, would love to hear what others think...

In the past I did consider the possibility of making an equivalent of GeoRAM for the VIC-20 with an added benefit.

While GeoRAM for the C64 is divided into cells of 256 bytes, the VIC-20 version would also use the IO regions to have cells of 1kByte. Poking a specific value at a specific address in the IO2 region would allow 65536 cells of 1kB or 64 Mbytes in all. The selected cell being visible in the IO3 region.

Don't think that's what you had in mind, however.

[brain]

In any case, would love to hear what others think...

In the past I did consider the possibility of making an equivalent of GeoRAM for the VIC-20 with an added benefit.

While GeoRAM for the C64 is divided into cells of 256 bytes, the VIC-20 version would also use the IO regions to have cells of 1kByte. Poking a specific value at a specific address in the IO2 region would allow 65536 cells of 1kB or 64 Mbytes in all. The selected cell being visible in the IO3 region.

Don't think that's what you had in mind, however.

In a word, no, but the idea is workable. However, if the 64 had offered a larger R/W space in the expansion port, Berkely Softworks would have used it. Thus, if you're trying to replicate the same thing on the VIC-20, I'd recommend using the BLK5 space for the "window". However, UltiMem currently offers the functionality you're describing. You simply set the page address in UltiMem registers and the respective 1kB page of data will show up in IO3.

Jim

[brain]

Hi, Jim,

one of my projects specifically aimed to make the $0400..$0FFF 'hole' accessible to VIC (this wouldn't be possible with an external cartridge). In doing so, I also extended the colour RAM from 1K nibbles to 16K nibbles with my VFLI mod.

One other project was intended to provide RAM under BASIC, KERNAL and character ROM. In case of the character ROM, CPU and VIC chip were supposed to be switched between RAM and ROM independently. I derived the necessary equations some time ago and there also exists a hand-drawn schematic with a bunch of TTLs, but the project didn't progress much beyond that stage. Actually, one of its intended uses was instead realised by just exchanging the BASIC ROM.

IMO, any other type of internal expansion has to weigh its functionality against what could likewise be provided by an external cartridge. A proper demultiplexer for all involved cartridge select signals would also be a requirement.

Michael

My original thought was to support banking in RAM or ROM at any of the BLKX spaces (BLK0,1,2,3,4,5,6,7), by sitting in the CPU socket. But, as you note, that helps the VIC-I not at all.

But, I *think* I have an idea that would allow CA0-13 at the expansion port to mirror VA0-13 and CD0-7 to mirror BD0-7. I doubt Color RAM (isn't that the 4 bit RAM that is attached to D8-D11?) could be exposed outside the VIC-20, but the rest looks like it can. I wonder if that would of any benefit.

Jim

[brain]

TO do some testing, I made up a small test board with 512kB RAM and 512kB FLASH ROM.

[eslapion]

TO do some testing, I made up a small test board with 512kB RAM and 512kB FLASH ROM.

I see both memory chips are Through-hole. I suggest you be careful this board can fit on all 3 types of VIC-20 mainboards and using surface mount can help you with that.

I also see your design uses a XC95xxXL CPLD along with a 3.3V regulator. Since a lot of careless people use 74HC (correct CMOS replacement is 74HCT or 74AHCT) ICs in VIC-20 cartridges and even sometimes repair VIC-20s with them, I suggest you raise the voltage to 3.6V to ensure full compatibility.

Then again, you specified this is just a test board... for the future, I suppose.

[brain]

As you note, it's a test board, so I chose test ability over compactness. As a result, it will not fit in the first rev motherboard, due to the placement of the CPU relative to heat shields, I believe. (Well, it will fit for testing, with a riser, but not with the KB closed).

Jim

[brain]

Sorry for the delay, but finally was able to get some concerted time to play around with my ideas:

Initial efforts:

Wire City!

After a bit of cleanup:


Current situation is as follows:

• I have bypassed all ROMs on the CPU side (BASIC, KERNAL) and replaced with 512kB FLASH ROM
• I have bypassed almost* all SRAM on the CPU side (RAM0,4,5,6,7) with 512kB SRAM (can be mapped into all RAM and BLK locations, including under ROMs)
• I have bypassed all ROMs on the VIC-I side (CHAR)
• I have bypassed almost* all SRAM on VIC-I side (ROM0,4,5,6,7) with 512kB SRAM (can be mapped across all 16kB VIC-I address space, including instead of ROM)

*Since I was not sure my full idea had any merit, I didn't implement the color RAM functionality, so color RAM is hardcoded in my last picture to be $5

Essentially, the wires going from the VIC-I daughterboard to the main PCB stack carry the 26 important lines from the VIC-I (A13:0,D11:0) over to the CPU. Therefore, I've bypassed the "dual bus" issues in the VIC-20.

The triple PCB stack is an accidental re-use of my main PCB. I had address lines on the main PCB shared with the CPU, which won't allow the VIC-I to work, so I used the 26 line IO header to pipe the A:D lines to a second copy of the board, where I put all memory. The third PCB is due to some funkiness in the needs of the VIC-I address bus timing, so I mainly just use that PCB as a carrier for a third CPLD to address (no pun intended) the issues.

I'd like to test out some of the RAM options, but need some test apps to do so. Any quick "puts some simple VIC-I data in the 3kB expansion RAM" code lying around I can run to test out the workings?

I'm wiring up a new PCB with the information I've learned from this set of tests, so I'll be trying out a new board soon.

Jim