Doneeslapion wrote:Can somebody be kind enough to add the above photo this this Wiki page: http://sleepingelephant.com/denial/wiki ... _Cartridge
vic-1110 8k ram cart upgrade (and other solutions)
Moderator: Moderators
- orion70
- VICtalian
- Posts: 4343
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: vic-1110 8k ram cart upgrade (and other solutions)
Re:
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:
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
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 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!).lordbubsy wrote: I've found a schematic of a 35k expansion which confirms that.
http://www.baltissen.org/images/mem-exp.gif
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
- Vic 20 Drifter
- Posts: 33
- Joined: Mon Feb 01, 2010 3:55 pm
Re: Re:
Congratulation. I know the good feeling that increased Bytes Free message brings.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: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!).lordbubsy wrote: I've found a schematic of a 35k expansion which confirms that.
http://www.baltissen.org/images/mem-exp.gif
It Lives, Basic showing 28,159! But really need to type in a mem test.
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.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?
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.
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.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
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler
Re: Re:
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 timeRichardc64 wrote: Congratulation. I know the good feeling that increased Bytes Free message brings.
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.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 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.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.
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
Re: vic-1110 8k ram cart upgrade (and other solutions)
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.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.
Re: vic-1110 8k ram cart upgrade (and other solutions)
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.srowe wrote: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.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.
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
Re: vic-1110 8k ram cart upgrade (and other solutions)
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.
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
- 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)
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.
There is also a version of the Rabbit tape accelerator designed to use this area.
Be normal.
Re: vic-1110 8k ram cart upgrade (and other solutions)
That sounds interesting. Will look forward to seeingsrowe 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.
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
Re: vic-1110 8k ram cart upgrade (and other solutions)
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?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.
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
Re: vic-1110 8k ram cart upgrade (and other solutions)
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.
Re: vic-1110 8k ram cart upgrade (and other solutions)
YES, very nice. I see I'm reinventing the wheeltokra 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.
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
Re: vic-1110 8k ram cart upgrade (and other solutions)
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 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.
Re: vic-1110 8k ram cart upgrade (and other solutions)
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.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.
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
- 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)
@Yogi
The Behr-Bonz uses IO2 to control the selected bank in a 16Mbit EPROM to 127 games plus a 16k menu.
The Behr-Bonz uses IO2 to control the selected bank in a 16Mbit EPROM to 127 games plus a 16k menu.
Be normal.