Going on a VIC raid

[MiaM]

All the memory expansions I have sold are based on 32k and 8k static RAM chip because they are now cheap. They were quite expensive in the early 80s hence the incentive to develop DRAM based expansion.

Have you ever had any issues with timing? Using chips bigger than 8k for the block 1/2/3/5 and 1k for ram 1/2/3 will require you to be sure that the address line never flips while the chip is selected and write enable is active. I haven't studied the timing diagrams and the schematics (to see where various signals are delayed, and by what amount), but a kind of conclusion is that some revisions of the VIC 20 motherboard makes for example Final Expansion 3 to misbehave in a way that makes the 3k expansion and block 5 clash, while it works fine on other VIC 20 versions. One of the non-CR versions seems to trigger the clash while another non-CR version won't trigger it. Seems like a timing issue, probably due to that those who constructed the FE and wrote the code for the programmable logic didn't go through the tedious work of reading the schematics for all VIC 20 revisions (if everyone even is available) and read the data sheets for the relevant IC's and calculate max/min timins for each relevant signal.

Some time in the future I plan to generally have a look at how to handle timing issues with the help of modern software. I think it might be a good idea to use project planning software as afaik in those you can state that each task (which would be the delay through an IC) can take a min and a max time, and you can make various stuff dependant on other stuff, and see how much the resultant time can vary due to variations in the time for each "tast" (IC delay). That way it should be easier to visualize timing stuff. For the VIC 20 it might be easy enough to do it more or less by hand, but for the more complicated stuff like the complex timing generator for the CBM-II/B series something more advanced would really help.

In a thread in a swedish facebook group we have discussed the FE3 problem, and now there is a thread about a simpler ram expansion which might be something you could had sold (ebay seller in the UK iirc) and trouble running "Doom". Can't remember if there were any conclusion though.

I think that we need some kind of more through test program for ram expansions. Not something like a test cart but something you load from disk/tape and run with it's code and data in the internal ram (which should be known good to run the test), and tests stuff like filling all ram areas with a known value, checking that everything reads back correctly, and then performs a lot of writes to one expansion ram area (one of the blocks or one of the 1k ram areas), and then checks if something in the other areas of ram expansion contains the wrong contents. Repeat this but write to the next area until everything is tested.

I'd love to get my hands on an expansion like that as I have yet to find a good complete schematic for a functional DRAM based expansion for the VIC-20. Looking at the C64 schematics, you can understand what's necessary to access DRAM but the refresh part is all hidden in the VIC-II.

Yeah, it would be nice to know how those were made back in the days. Wish I still had some of the stuff I had a long time ago, which I sadly sold off thinking I'd never have a relapse at collecting Commodore 8-bit stuff

[eslapion]

All the memory expansions I have sold are based on 32k and 8k static RAM chip because they are now cheap. They were quite expensive in the early 80s hence the incentive to develop DRAM based expansion.

Have you ever had any issues with timing? Using chips bigger than 8k for the block 1/2/3/5 and 1k for ram 1/2/3 will require you to be sure that the address line never flips while the chip is selected and write enable is active.

Ha hum... even if you elect to limit yourself to using 8K SRAM ICs for BLK areas and 1K SRAM for RAM 1/2/3 areas, the proper operation of any and all RAM accessible by a 6502 is based on the notion that address line values will not shift while the chip is selected and write enable is active.

Why would there be a 'timing problem' because I re-encoded the BLK lines into higher address lines for a memory IC ? Modern Logic ICs have a response speed which allows them to be used as glue logic with CPUs that are tens of times faster than the good 'ole' VIC-20.

I haven't studied the timing diagrams and the schematics (to see where various signals are delayed, and by what amount), but a kind of conclusion is that some revisions of the VIC 20 motherboard makes for example Final Expansion 3 to misbehave in a way that makes the 3k expansion and block 5 clash, while it works fine on other VIC 20 versions. One of the non-CR versions seems to trigger the clash while another non-CR version won't trigger it. Seems like a timing issue, probably due to that those who constructed the FE and wrote the code for the programmable logic didn't go through the tedious work of reading the schematics for all VIC 20 revisions (if everyone even is available) and read the data sheets for the relevant IC's and calculate max/min timins for each relevant signal.

I can't answer to speculation. I have the schematics of all the VIC-20 revisions and my SRAM expansions work well on all of them.

I have not been involved in the design of the FE3 and know just about nothing of this cartridge.

[MiaM]

All the memory expansions I have sold are based on 32k and 8k static RAM chip because they are now cheap. They were quite expensive in the early 80s hence the incentive to develop DRAM based expansion.

Have you ever had any issues with timing? Using chips bigger than 8k for the block 1/2/3/5 and 1k for ram 1/2/3 will require you to be sure that the address line never flips while the chip is selected and write enable is active.

Ha hum... even if you elect to limit yourself to using 8K SRAM ICs for BLK areas and 1K SRAM for RAM 1/2/3 areas, the proper operation of any and all RAM accessible by a 6502 is based on the notion that address line values will not shift while the chip is selected and write enable is active.

Why would there be a 'timing problem' because I re-encoded the BLK lines into higher address lines for a memory IC ? Modern Logic ICs have a response speed which allows them to be used as glue logic with CPUs that are tens of times faster than the good 'ole' VIC-20.

I'm just asking if you have seen any problems. Afaik the only software available that would trigger the problem would be VIC DOOM as there afaik aren't any other software that uses both the 3k expansion area and the block 1/2/3 areas. All commercial and probably most home made software from back in the days either used the 3k expansion OR the larger expansions, but afaik never both.

When introducing another gate, you add a gate dealy and thus the risk of timings becoming a bit off.

Afaik noone has published a calculated timing graph for VIC 20. There are various more or less delayed clock signals (passing through different numbers of gates) and those signals are involved in the selection of the 138 decoders for both block0-7 and ram0-7.

I haven't studied the timing diagrams and the schematics (to see where various signals are delayed, and by what amount), but a kind of conclusion is that some revisions of the VIC 20 motherboard makes for example Final Expansion 3 to misbehave in a way that makes the 3k expansion and block 5 clash, while it works fine on other VIC 20 versions. One of the non-CR versions seems to trigger the clash while another non-CR version won't trigger it. Seems like a timing issue, probably due to that those who constructed the FE and wrote the code for the programmable logic didn't go through the tedious work of reading the schematics for all VIC 20 revisions (if everyone even is available) and read the data sheets for the relevant IC's and calculate max/min timins for each relevant signal.

I can't answer to speculation. I have the schematics of all the VIC-20 revisions and my SRAM expansions work well on all of them.

Have you specifically tested VIC DOOM (or any other software using both the 3k expansion and the block1/2/3 expansions at the same time) with all revisions?

I'm nog accusing you of seeling something that doesen't work. I'm nog even sure of correct usage by the person who has what seems like one of your expansions. I'm just trying to establish if there are any known problem with any VIC 20 revision and any other ram expansion than FE3.

I have not been involved in the design of the FE3 and know just about nothing of this cartridge.

Of ocurse. I'm just using that as an example of a well known product sold in a reasonable quantity that people keep buying not because it's flawless but because it's good enough, it's "only" when using the 3k expansion and block 5 as ram at the same time that it doesen't really work on some VIC 20's.

[Mike]

Afaik the only software available that would trigger the problem would be VIC DOOM as there afaik aren't any other software that uses both the 3k expansion area and the block 1/2/3 areas.

Of the top of my head you can include my CGA panning viewer into the list of programs that need +35K RAM.

320x200 - a CGA emulator for VIC-20! (+35K RAM req'd)

Also, a single program utilizing those +35K RAM all for itself isn't the only use case I could imagine. Quite as well people could want to use the +32K as "regular" maximum RAM expansion and run programs and utilities there - and use the +3K in $0400..$0FFF to "stow away" toolkits like a software drive speeder that operates independently of the main application.

[eslapion]

I'm just asking if you have seen any problems. Afaik the only software available that would trigger the problem would be VIC DOOM as there afaik aren't any other software that uses both the 3k expansion area and the block 1/2/3 areas. All commercial and probably most home made software from back in the days either used the 3k expansion OR the larger expansions, but afaik never both.

Commercial, probably not but expanders like the RAMAX did allow the presence of both BLK RAM area expansions and RAM in the 0400-0FFF$ areas at the same time. Never heard of any problems. Many 'hackers' or programmers back then did create custom software that used both areas without any technical issues.

When introducing another gate, you add a gate dealy and thus the risk of timings becoming a bit off.

All Commodore 8K and 16K RAM expansion include a 74LS139 decoder and there isn't any problem there.

AFAIK, all 74HCT and older 74LS logic ICs perform their operation in less than 20ns. They perform their job about twice as fast as the C64 PLA.

Afaik noone has published a calculated timing graph for VIC 20. There are various more or less delayed clock signals (passing through different numbers of gates) and those signals are involved in the selection of the 138 decoders for both block0-7 and ram0-7.

The MOS 6502 datasheet has graphs but of course, they only include information about the CPU, not the VIC-20 itself.

However, if your theory is correct, every single VIC-20 and PET computers should have such problems. Doesn't look like it.

In the C64, the PLA introduces glue logic delays that are even greater, at up to 40ns. The delay is even a critical component in the way DRAM is accessed. In the C64c and C128, faster glue logic components were introduced and the delay got back to about the same as those of 74LS logic ICs.

I must admit, I always made sure the SRAM ICs I put on every single memory expansion I have sold since 2006 is rated for 70ns or slower. The same is true for Ultimate Expanders sold around 2006-2007 which carried an EPROM - these were rated for 120ns or slower. The objective being a shift in timing on some lines caused by glue logic would therefore be inconsequential.

The EPROM used on the Behr-Bonz is rated for 90 or 100ns depending on the batches I get.

In the past, I clearly mentioned using SRAM normally destined for use as older PC cache may cause problems but some have ridiculed this notion. I think you may have found a potential problem.

I can't answer to speculation. I have the schematics of all the VIC-20 revisions and my SRAM expansions work well on all of them.

Have you specifically tested VIC DOOM (or any other software using both the 3k expansion and the block1/2/3 expansions at the same time) with all revisions?

I did not. Some of my clients did specifically note this software caused problems on other expansions (I didn't care to note which ones specifically) and not on the ones I sell. The architecture of both the Ultimate Expanders I sold a decade ago and the ones I sell presently present themselves to the VIC as if the BLK areas expansion and the RAM/IO were two completely separate RAM expansions built onto a single board. They have separate glue logic and separate RAM ICs. This may have something to do with it.

In fact, in the case of the Ultimate Expander, having RAM in the 0400-0FFF$ area was an optional add-on and having RAM in the IO areas was not available.

AFAIK, all the expansions which have problems with DOOM for VIC use a single glue logic architecture to decode both areas and they also use very fast SRAM ICs. I think the culprit is there.

... it's "only" when using the 3k expansion and block 5 as ram at the same time that it doesen't really work on some VIC 20's.

AFAIK, the FE3 and the other 'not gold plated' RAM expansion use the same logic IC to decode both the BLK5 and 3k RAM areas.

The expansions I sell do not.