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

Modding and Technical Issues

Moderator: Moderators

User avatar
orion70
VICtalian
Posts: 4337
Joined: Thu Feb 02, 2006 4:45 am
Location: Piacenza, Italy
Occupation: Biologist

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

Post by orion70 »

eslapion wrote:Can somebody be kind enough to add the above photo this this Wiki page: http://sleepingelephant.com/denial/wiki ... _Cartridge
Done :)
yogi
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

Re:

Post by 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:
lordbubsy wrote: 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
User avatar
Richardc64
Vic 20 Drifter
Posts: 33
Joined: Mon Feb 01, 2010 3:55 pm

Re: Re:

Post by Richardc64 »

yogi wrote: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:
lordbubsy wrote: 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
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler
yogi
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

Re: Re:

Post by yogi »

Richardc64 wrote: 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
User avatar
srowe
Vic 20 Scientist
Posts: 1325
Joined: Mon Jun 16, 2014 3:19 pm

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

Post by 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
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

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

Post by yogi »

srowe wrote:
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
User avatar
srowe
Vic 20 Scientist
Posts: 1325
Joined: Mon Jun 16, 2014 3:19 pm

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

Post by 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.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

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

Post by 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.
Be normal.
yogi
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

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

Post by yogi »

srowe wrote: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
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

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

Post by yogi »

eslapion wrote: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
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

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

Post by 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
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

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

Post by yogi »

tokra wrote: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
User avatar
srowe
Vic 20 Scientist
Posts: 1325
Joined: Mon Jun 16, 2014 3:19 pm

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

Post by srowe »

yogi wrote: 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
Vic 20 Drifter
Posts: 36
Joined: Wed Apr 08, 2015 9:49 am

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

Post by yogi »

srowe wrote: 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
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

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

Post by eslapion »

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