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.eslapion wrote: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.
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.
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 stuffeslapion wrote: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.