vic-1110 8k ram cart upgrade (and other solutions)

[orion70]

Can somebody be kind enough to add the above photo this this Wiki page: http://sleepingelephant.com/denial/wiki ... _Cartridge

Done

[yogi]

Hi , new here but have been reading for a bit and for VIC this IS the place to be!
I had to jump in here. Last week decided to dig my VIC out of storage and get VIC Tracker running on it. So looking for a RAM Expansions, found Ruud's pages,
http://www.baltissen.org/newhtm/memv20.htm
also linked here:

I've found a schematic of a 35k expansion which confirms that.
http://www.baltissen.org/images/mem-exp.gif

I did the expansion internal, piggybacked. Had to make a few changes: Only had a 'LS20 on hand so added a 'LS14 for a couple Not gates. Picked up /RAM 3:1 and /BLK 5, 3:1 from the 'LS138s. For A13 and /WE, I tapped off the 6502 direct. (SO glad that the Sam's Photofacts were OL!).
It Lives, Basic showing 28,159! But really need to type in a mem test.
Just now found this post and had some questions. As I said, I pulled /WE from the CPU, but on the schema it shows expo pin 18, CR/W, (but should be pin 17, VR/W). CR/W = CPU R/W and VR/W = Vic2 R/W? What is the differences of these pins and the CPU R/W? Are they Anded with PH2? Buffered?
I also left out the DIP switch (didn't understand the 'odd' memory handling at the time). So I may add that to allow for the VIC's quirky memory mapping (or is there a software work around? Think I read about changing the Screen/Basic pointers). For VIC Tracker, 'more is better' right?
A write protect switch for /BLK5 would be simple enough with the 6264 as per the schema, to support cart dumps (?). Do all carts use BLK5 and/or do they all need to be read only?
To write protect BLK 3:1 would require more gates to deselect portions of the 62256 SRAM. So for cart dumps, would it be worth the extra effort? My main interest is music with VT but would like to keep options open to try other synthy prgs.
Yogi

[Richardc64]

Hi , new here but have been reading for a bit and for VIC this IS the place to be!
I had to jump in here. Last week decided to dig my VIC out of storage and get VIC Tracker running on it. So looking for a RAM Expansions, found Ruud's pages,
http://www.baltissen.org/newhtm/memv20.htm
also linked here:

I've found a schematic of a 35k expansion which confirms that.
http://www.baltissen.org/images/mem-exp.gif

I did the expansion internal, piggybacked. Had to make a few changes: Only had a 'LS20 on hand so added a 'LS14 for a couple Not gates. Picked up /RAM 3:1 and /BLK 5, 3:1 from the 'LS138s. For A13 and /WE, I tapped off the 6502 direct. (SO glad that the Sam's Photofacts were OL!).
It Lives, Basic showing 28,159! But really need to type in a mem test.

Congratulation. I know the good feeling that increased Bytes Free message brings.

Just now found this post and had some questions. As I said, I pulled /WE from the CPU, but on the schema it shows expo pin 18, CR/W, (but should be pin 17, VR/W). CR/W = CPU R/W and VR/W = Vic2 R/W? What is the differences of these pins and the CPU R/W? Are they Anded with PH2? Buffered?

Generally, VR/W is a better choice for RAM, but if yours is working with CR/W I wouldn't change it unless I began to see problems.
CR/W is not buffered. In the later, CR VIC-20 it gets NORed with PH1, inverted, then that is NORed with clock into the 6502 and inverted to create a /WE "narrower" than raw R/W from the cpu.

A write protect switch for /BLK5 would be simple enough with the 6264 as per the schema, to support cart dumps (?). Do all carts use BLK5 and/or do they all need to be read only?

Auto-starting cartridges had to be in BLK5. Others could be elsewhere. A form of copy protection was to have the program attempt to write to a location within BLK5. If the location changed from what it should contain, the program would know it was running in RAM and quit. A write protect disable switch defeats that anti-piracy method. HOWEVER, some cart programs were too big to fit in BLK5 and so they occupied BLK3 as well. I can't say whether or not the added complexity of a WRite enable/disable switch for BLK3 would be worth the effort.

To write protect BLK 3:1 would require more gates to deselect portions of the 62256 SRAM. So for cart dumps, would it be worth the extra effort? My main interest is music with VT but would like to keep options open to try other synthy prgs.
Yogi

[yogi]

Congratulation. I know the good feeling that increased Bytes Free message brings.

Thanks, yea it wasn't too complicated but had to dig up alt solder point for the expo pins. But always nervous flipping the switch the first time

Generally, VR/W is a better choice for RAM, but if yours is working with CR/W I wouldn't change it unless I began to see problems.
CR/W is not buffered. In the later, CR VIC-20 it gets NORed with PH1, inverted, then that is NORed with clock into the 6502 and inverted to create a /WE "narrower" than raw R/W from the cpu.

Thanks that explains much. After I posted, I went through the Sam's and saw that on the cost reduced version, all mobo ram is on VR/W (hope my first gen isn't too different) so I went ahead and moved it. Works the same but didn't want to temp fate and was thinking that the signal from the VIC's pin 35 had something to do with it's timing to screen ram. But reading your explanation reminds me allot of the 'delayed PHI2' issues on the Atari.

Auto-starting cartridges had to be in BLK5. Others could be elsewhere. A form of copy protection was to have the program attempt to write to a location within BLK 5. If the location changed from what it should contain, the program would know it was running in RAM and quit. A write protect disable switch defeats that anti-piracy method. HOWEVER, some cart programs were too big to fit in BLK5 and so they occupied BLK3 as well. I can't say whether or not the added complexity of a WRite enable/disable switch for BLK3 would be worth the effort.

Thanks again, this is the kind of info I was looking for. I'll go ahead and add a couple case switches for BLK 5 if that's the most common cart location. Think I'll wait and see if the added circuitry is needed for my use.
I don't feel like I'll be collecting a cart library, so most softs will be DLs and on my uIEC/SD. Boray's Disk Menu loader seems to handle non-expansion PRGs on a expanded system; so if I don't run into too many issues I'll leave well enough alone. Kind of feel like, homebrews and demos aren't going to be a copyright problem.
I have an OT question, were the I/O 2 or I/O 3 signals used by much/any carts or peripherals? Seems like that 2K could be interesting.
Anyway, thanks again Richardc64,
Yogi

[srowe]

I have an OT question, were the I/O 2 or I/O 3 signals used by much/any carts or peripherals? Seems like that 2K could be interesting.

Mainly for non-memory peripherals. I think the IEEE-488 cartridge uses both, the Maplin Talk-Back board I'm fiddling with uses just /IO3. It's annoying though that some boards (certainly the Talk-Back) don't bother to fully decode the address lines, they just use the IO line as a /CS.

[yogi]

I have an OT question, were the I/O 2 or I/O 3 signals used by much/any carts or peripherals? Seems like that 2K could be interesting.

Mainly for non-memory peripherals. I think the IEEE-488 cartridge uses both, the Maplin Talk-Back board I'm fiddling with uses just /IO3. It's annoying though that some boards (certainly the Talk-Back) don't bother to fully decode the address lines, they just use the IO line as a /CS.

OK, that's what I guessed. Thanks for the mention of the Talk Back, very cool little project. I've got a couple SPOs stashed that I've wanted to build with.
Had thought about one of the talk box projects for the Atari but this Malpin design has a novel approach with the V to F VCO. That's cool and gets around the weird Xtal for the SPO. Expanding on this, could even get more frequency control by latching a few bits from the data bus for a R2R DAC, covox style, to feed the FC in on the 'LS629. Hmmm have to explore this .
Yogi

[srowe]

It is a nice little board, but it has a couple of 'quirks'

1. the allophone is loaded from the address lines, not the data lines
2. the /LRQ line has to be connected to an external line, the paddle port

I'm just in the middle of designing an adapter board that will

1. fully decode the address lines
2. load the allophone from the data lines from a CPU write
3. read the /LRQ line from a CPU read

I'll post the schematic here once I have it working.

[eslapion]

Concerning the IO2 and IO3 lines; back in 2003, I made a version of Turbodisk that ran in this area. That's, of course, before I learned of the benefits of JiffyDOS.

There is also a version of the Rabbit tape accelerator designed to use this area.

[yogi]

It is a nice little board, but it has a couple of 'quirks'

1. the allophone is loaded from the address lines, not the data lines
2. the /LRQ line has to be connected to an external line, the paddle port

I'm just in the middle of designing an adapter board that will

1. fully decode the address lines
2. load the allophone from the data lines from a CPU write
3. read the /LRQ line from a CPU read

I'll post the schematic here once I have it working.

That sounds interesting. Will look forward to seeing
I'm curious, are you doing the decoding to allow other devices to share the I/Ox mem space? Malpin's design, though mem inefficient, is clever from a HW view. One of the things that come to mind for me, would be some ROM with allophone lookup tables and/or 'words'; mapped to the IO space. 1,2 or even 3 pages, or how about a bank switched flashROM organized as 512B banks for a HUGE vocab. The SPO did have a companion serial PROM but they're more scarce then the SPOs.
Looking forward,
Yogi

[yogi]

Concerning the IO2 and IO3 lines; back in 2003, I made a version of Turbodisk that ran in this area. That's, of course, before I learned of the benefits of JiffyDOS.

There is also a version of the Rabbit tape accelerator designed to use this area.

Cool. I gather, from Basic the only access to these 2K of addresses is through Peek and Poke and the Kernel really doesn't tread here? So it would be 'safe' for total user control?
The more I discover about this little computer the better I like it. It's basic straight forward system design just begs for hardware projects.
Yogi

[tokra]

Yep, the 2K from $9800-$9fff are under your total control if you put RAM there. I did this for fun by modding a Commodore 3K expansion some months back. You can put any tool there you like, e.g. SJLOAD hides there nicely and other things like a machine-language monitor or BASIC-extensions would do nicely as well.

[yogi]

Yep, the 2K from $9800-$9fff are under your total control if you put RAM there. I did this for fun by modding a Commodore 3K expansion some months back. You can put any tool there you like, e.g. SJLOAD hides there nicely and other things like a machine-language monitor or BASIC-extensions would do nicely as well.

YES, very nice. I see I'm reinventing the wheel
So for a GP hardware dev cart: some battery backed ram for holding the ML driver routines. HW control registers in 1k and a 1K banked window of a larger NVram. I gather the MegaCart does something similar, will have to research it.
Yogi

[srowe]

That sounds interesting. Will look forward to seeing
I'm curious, are you doing the decoding to allow other devices to share the I/Ox mem space? Malpin's design, though mem inefficient, is clever from a HW view. One of the things that come to mind for me, would be some ROM with allophone lookup tables and/or 'words'; mapped to the IO space. 1,2 or even 3 pages, or how about a bank switched flashROM organized as 512B banks for a HUGE vocab. The SPO did have a companion serial PROM but they're more scarce then the SPOs.

Yes, with only two I/O lines it's rather greedy to use a whole 1K block to access a single byte. I've also got a design for an I2C interface (using a 6522) that needs an I/O line. The Talk-Back board exposes the lines for the PROM but I've not seen anything that connects to them.

[yogi]

Yes, with only two I/O lines it's rather greedy to use a whole 1K block to access a single byte. I've also got a design for an I2C interface (using a 6522) that needs an I/O line. The Talk-Back board exposes the lines for the PROM but I've not seen anything that connects to them.

Well I'm sure they were going for the most cost efficient design and as presented there isn't a need to add more decoding.

BUT as it stands, there isn't any room for expansion. Which for an unexpanded VIC, it would be little more then a novelty. Having to include all of the allophone vocab data in the prg RAM would eat a lot bytes up for anything more then a few words.

Looking forward to seeing your project.
Yogi

[eslapion]

@Yogi
The Behr-Bonz uses IO2 to control the selected bank in a 16Mbit EPROM to 127 games plus a 16k menu.