RAM expansion cross-talk issues (split from: Bitshifter's Z-code interpreter)

[ral-clan]

Hmmm....I'm wondering what's the theory on why it would not work with this particular VIC-20 and the Mega-Cart, but the same VIC-20 will run it with the UltiMEM?

Would that tend to put the suspicion in the VIC-20 or the memory expander territory?

[Mike]

Hmmm....I'm wondering what's the theory on why it would not work with this particular VIC-20 and the Mega-Cart, but the same VIC-20 will run it with the UltiMEM? Would that tend to put the suspicion in the VIC-20 or the memory expander territory?

... and you have your Mega-Cart working with another VIC-20. That means, there are four test cases:

1. your initial VIC-20 + Mega-Cart + Bit Shifter's interpreter => fails
2. your initial VIC-20 + Ultimem => works
3. your second VIC-20 + Mega-Cart => works
4. ... you didn't announce the results for the combo second VIC-20 + Ultimem, but we can assume for the moment, that this one also works.

As error testing involves exchanging components and looking where the fault goes with the component (here: either VIC-20 or Mega-Cart), this analysis in inconclusive. It is the special combination of your initial VIC-20 and that Mega-Cart that doesn't work.

This situation in not unknown in electrical engineering. These are called timing faults. When a RAM cartridge is accessed, several select signals are sent to the cart, and the select logic in the cart has to process them within a tight time limit. DIfferent VIC-20s will differ in the exact timing of those signals (though their sequence always remains the same), but in some cases the time difference between two signals might be too small to be correctly recognized by the circuitry in a certain cartridge. Likewise, different cartridges (especially of different design) might be more tolerant to that given small time difference. Such timing errors can also spuriously disappear or reappear with changing room (and thus, component) temperature.

Obviously, the hardware makers can't check their cartridges with each and every VIC-20 in existence. They can make sure though, that their design follows some well established rules to cope with most situations that could lead to timing faults. And, from what I remember, Brian did check the design of Mega-Cart with several VIC-20's (mostly NTSC), and Carlsson did the same with PAL VIC-20 on our side of the pond.

You have bad luck with having a VIC-20 as an outlier, yes. For itself, your VIC-20 functions, your Mega-Cart functions, just those two don't get together.

[ral-clan]

You have bad luck with having a VIC-20 as an outlier, yes. For itself, your VIC-20 functions, your Mega-Cart functions, just those two don't get together.

I should mention one interesting observation: When testing your theory regarding trying the Mega-Cart in another VIC-20, I pulled out several VIC-20s I had in storage. Most hadn't been used in years, and so contact with the Mega-Cart edge connector was intermittent. In trying to remedy this, I had to clean as much of the cartridge slot on the second VIC-20 as I could, and I of course also cleaned the male edge connector on the Mega-Cart. This allowed it to to work with the spare VIC-20, and I was successfully able to load and play ZORK.

I then re-connected my original VIC-20. I tried Zork again on that, and for a moment it played! I received the initial room description (standing in front of a mailbox, outside a house) AND a command prompt in Zork, which I had never been able to get as far as before (it always ERRORED out just before this), as shown in pictures on the previous pages of this thread.

So, I thought, perhaps all the problem had only been an improper contact on the Mega-Cart, which was remedied by cleaning. However, I then typed the first command: LOOK, in order to have Zork describe the location, only to then get an ERROR 01.

Subsequent attempts to load Zork with this configuration reverted to the original problem, ERROR 01 or ERROR 04 right after the initial ZORK welcome screen, but before the first location description appears.

Still, strange behaviour....maybe a clue to something, that one it was successful in getting a little further.

[orion70]

[OT]It's incredible how "analog" the VIC problems can be. In other threads throughout several years, I described many inexplicable issues, from intermittent and different faults with the same game/program, to color glitches which seemed to depend on the weather (well, I am the Meteo VIC after all ), to another VIC which passed OK all memory and ports and everything else's tests, but presented with problems of false notes, just like an off-key vocalist!

I learned that sometimes our small and apparently simple friend just loves to be unpredictable.

[ral-clan]

Hi Bit Shifter,

I can confirm that your new "almost final" trilogy release doesn't work the my Mega-Cart expansion (not a surprise).
I just wanted to say, though, that your port is a very beautiful presentation. The font and 32 column choice is very nice looking. I like the way you can now remove the track status. I even love the default white on blue. It's a very nice interface.

[Bit Shifter]

Hi Bit Shifter,

I can confirm that your new "almost final" trilogy release doesn't work the my Mega-Cart expansion (not a surprise).
I just wanted to say, though, that your port is a very beautiful presentation. The font and 32 column choice is very nice looking. I like the way you can now remove the track status. I even love the default white on blue. It's a very nice interface.

Hi ral-clan,

thanks for testing and your compliments.
I'm still curious, why the program doesn't run on your Mega-Cart.
Someone guessed, it could be memory corruption in the 3K area, located at addresses $0400-$0fff.
Unfortunately the VIC has no ML-monitor and the available cartridge occupies an address range, needed by the interpreter.
But the reset routine doesn't clear this area. So after running into the internal error you can just hit a key and the program will perform a warm start of the VIC. After the reboot we can inspect the area with BASIC peeks.
The range $0400-$05ff is the track table of the sequential file. PEEK(1024) and following...
The range $0600-$07ff is the sector table of the sequential file. PEEK(1536) and following...
With ZORK-I the values should be:

Code: Select all

>C:0400  0e 0e 0e 0e  0e 0d 0d 0d  0d 0d 0d 0d  0d 0d 0d 0d   ................
>C:0410  0d 0d 0d 0d  0d 0d 0d 0d  0d 0d 0c 0c  0c 0c 0c 0c   ................
>C:0420  0c 0c 0c 0c  0c 0c 0c 0c  0c 0c 0c 0c  0c 0c 0c 0b   ................
>C:0430  0b 0b 0b 0b  0b 0b 0b 0b  0b 0b 0b 0b  0b 0b 0b 0b   ................
>C:0440  0b 0b 0b 0a  0a 0a 0a 0a  0a 0a 0a 0a  0a 0a 0a 0a   ................
>C:0450  0a 0a 0a 0a  0a 0a 0a 0a  09 09 09 09  09 09 09 09   ................
>C:0460  09 09 09 09  09 09 09 09  09 09 09 09  09 08 08 08   ................
>C:0470  08 08 08 08  08 08 08 08  08 08 08 08  08 08 08 08   ................
>C:0480  08 08 07 07  07 07 07 07  07 07 07 07  07 07 07 07   ................

>C:0600  0f 07 11 09  13 00 0a 14  08 12 06 10  04 0e 02 0c   ................
>C:0610  01 0b 03 0d  05 0f 07 11  09 13 00 0a  14 08 12 06   ................
>C:0620  10 04 0e 02  0c 01 0b 03  0d 05 0f 07  11 09 13 00   ................
>C:0630  14 08 12 06  10 04 0e 02  0c 01 0b 03  0d 05 0f 07   ................
>C:0640  11 09 13 00  0a 14 08 12  06 10 04 0e  02 0c 01 0b   ................
>C:0650  03 0d 05 0f  07 11 09 13  00 0a 14 08  12 06 10 04   ................
>C:0660  0e 02 0c 01  0b 03 0d 05  0f 07 11 09  13 00 0a 14   ................
>C:0670  08 12 06 10  04 0e 02 0c  01 0b 03 0d  05 0f 07 11   ................
>C:0680  09 13 00 0a  14 08 12 06  10 04 0e 02  0c 01 0b 03   ................

Would be interesting to see, if the tables are still there and have the correct values.

[ral-clan]

Hi Bit Shifter,

I can PEEK those locations using a for-next loop and have them print to screen as decimal values. Beyond that, I'm not sure how I could get you the results. My programming skills are limited. Maybe have the output save as a sequential file?

From what I see, for instance, I should PEEK $0400 (1024) to $05ff (1535) for the track table, and see values 14, 14, 14, 14, 14, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13.

I did that much manually and got:

14,14,14,14,170,170,86,87,88,13,85,85,85,85,13,170

[Mike]

I did that much manually and got:

14,14,14,14,170,170,86,87,88,13,85,85,85,85,13,170

Oh! That looks like timing is on the brink indeed!

For some bytes (notably those with 14 and 13) it looks like you get the original/intended data (or the original data is retained), and the values 170 and those around 85 have a regular binary pattern and thus resemble graphical data from another address range.

If you repeatedly execute the line to PEEK out those address 1024..1039, you can see if that pattern changes. In that case the read accesses are unstable. Otherwise, the crosstalk happened during write access.

[Bit Shifter]

I did that much manually and got:

14,14,14,14,170,170,86,87,88,13,85,85,85,85,13,170

Oh! That looks like timing is on the brink indeed!

For some bytes (notably those with 14 and 13) it looks like you get the original/intended data (or the original data is retained), and the values 170 and those around 85 have a regular binary pattern and thus resemble graphical data from another address range.

If you repeatedly execute the line to PEEK out those address 1024..1039, you can see if that pattern changes. In that case the read accesses are unstable. Otherwise, the crosstalk happened during write access.

The numbers 170 ($AA) and 85 ($55) are the values, that are used from the RAM test routine during cold start.
These should have been overwritten by the interpreter with the track values.
So my guess is, that writing to that area fails randomly (read access may fail too).

I agree with Mike, that this issue looks like a hardware problem with timing issues.

[Mike]

The numbers 170 ($AA) and 85 ($55) are the values, that are used from the RAM test routine during cold start.
These should have been overwritten by the interpreter with the track values.
So my guess is, that writing to that area fails randomly (read access may fail too).

I agree with Mike, that this issue looks like a hardware problem with timing issues.

Normally, the $55 and $AA patterns get restored to the original value found in RAM, when their writes succeed and return the same value after write.

Problem with this simple kind of RAM test is, it only checks that a RAM cell is writable and returns the same value after being written. But it doesn't check that the value ends up in the correct (and only this one) RAM cell at all! All address lines to RAM could be "short-circuited" and only write to one and the same RAM cell, and this test would still succeed. Same can happen with faultly chip select logic. In theory, with a microcontroller that fetches its program from internal ROM and only 'consults' the busses for RAM accesses, that test can even succeed with a entirely *missing* RAM chip due to the parasitic capacitance of the data bus: the CPU re-reads the charges it had put on the data bus just a few hundreds of ns before ...

That's the reason I once devised the crosstalk checks. As first measure, the single bytes of the test range are checked to be writable as above. But then, all bytes in the address range are cleared to a certain known value. Then, only one byte is set to another value (which is, of course, also checked after with read). But this value must not appear anywhere else in the test range! If that happens, though, you have crosstalk.

...

In any case, this thread here has somewhat been de-railed by ral-clans specific hardware problem, which do not strictly relate to a certain program, rather the program class using the RAMx alongside the BLKx address range.

Thread split pending ... done.

[Kakemoms]

Hi Bit Shifter,

I can PEEK those locations using a for-next loop and have them print to screen as decimal values. Beyond that, I'm not sure how I could get you the results. My programming skills are limited. Maybe have the output save as a sequential file?

From what I see, for instance, I should PEEK $0400 (1024) to $05ff (1535) for the track table, and see values 14, 14, 14, 14, 14, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13.

I did that much manually and got:

14,14,14,14,170,170,86,87,88,13,85,85,85,85,13,170

Auch. Looks like what I got when timings were off on an earlier expansios that I tested. Specifically I was trying to run a WDC65C02 at x times the frequency of Vic-20 and shorten the Vic-20's time to access external memory. E.g. if the clock is a little off, it gives you such random readings.

At a later point I examined the problem more throughly, and I found that the Vic-20 clock is not 50% high and 50% low. It vary alot, even if the frequency is fairly stable. So I would look at the clock output of your vic-20 using an oscilloscope to see if its somewhat unstable. If that is not the problem, I would look at any logical component that can affect access timing, especially the 74LS138N (UC5).

[ral-clan]

So I would look at the clock output of your vic-20 using an oscilloscope to see if its somewhat unstable. If that is not the problem, I would look at any logical component that can affect access timing, especially the 74LS138N (UC5).

Would this have anything to do with the 555 chip in the VIC-20? I have a momentary reset button soldered to it. I wonder if this could have some effect.

[eslapion]

I note that back in 2008-2009, 6502dude never published the complete schematics for the MegaCart. I suspect Mike or other qualified people would have noted the memory crosstalk if these schematics had been published.

Also, please note the Ultimate Expander made between 2006 and 2009 only carried 32k RAM by default but some were fitted with the extra 3k RAM as an additional option. Those fitted with the extra 3k RAM capability will not suffer from the crosstalk problem because the extra 3k RAM comes in the form of a 8k Static RAM chip piggybacked on top of the 32k SRAM chip.

Also, the newly released 37k RAM expander I have been offering since early 2018 (here: http://sleepingelephant.com/ipw-web/bul ... f=3&t=8867 ) uses 2 independent SRAM ICs so there is no crosstalk problem.

[eslapion]

So I would look at the clock output of your vic-20 using an oscilloscope to see if its somewhat unstable. If that is not the problem, I would look at any logical component that can affect access timing, especially the 74LS138N (UC5).

Would this have anything to do with the 555 chip in the VIC-20? I have a momentary reset button soldered to it. I wonder if this could have some effect.

For the love of god!! Where did you guys get such nonsense?

The 555 is only responsible for generating the startup reset pulse and the 74LS138 divides the VIC-20 memory areas in various sections. Neither of them has anything to do with the VIC-20's timing!

Anyways, I couldn't find Kakemoms original post to know exactly what this is about...

The clock signal can be found on pin 38 of the 6560/6561.

[ral-clan]

So I would look at the clock output of your vic-20 using an oscilloscope to see if its somewhat unstable. If that is not the problem, I would look at any logical component that can affect access timing, especially the 74LS138N (UC5).

Would this have anything to do with the 555 chip in the VIC-20? I have a momentary reset button soldered to it. I wonder if this could have some effect.

For the love of god!! Where did you guys get such nonsense?

Likely from my dire lack of understanding of how the VIC works internally. The only timing related device I am aware of in the VIC was the 555, so I thought I'd ask.