Final Expansion :: 512KB SRAM + 512KB EEPROM + SD Card (2GB)

[srowe]

Thanks for that, that helps to get me started.

I'm still interested in more detailed docs, for example, there's an RTC chip but I can't find anything that explains how to access it.

[Vic20-Ian]

I have the clock notes somewhere. I will look for them. It is accessed with an @ command like the SD card. I can't remember it right now.

Sent from my D6503 using Tapatalk

[Vic20-Ian]

I have the clock notes somewhere. I will look for them. It is accessed with an @ command like the SD card. I can't remember it right now.

Sent from my D6503 using Tapatalk

Here they are...

http://www.forum64.de/wbb3/board65-neue ... cartridge/

Sent from my D6503 using Tapatalk

[srowe]

Thanks, that's a useful link.

[Bigby]

https://sleepingelephant.com/ipw-web/bu ... 0&start=62

dload crosstalk.,prg from the other thread
turn on FE3 and select max memory
run prg
verify errors occur
take out cart
find CR/W pin
Look where trace goes to Atmel CPLD
Find VR/W pin
See if there is a nice way or inconspicuous way to cut the CR/W trace and wire the VR/W pad to that pin of the CPLD
rerun test
See if error persists

Jim

I'm sorry, I may just be a few years too late on this. But I recently noticed that the FE3 I built for myself seems to have RAM problems when connected to my VIC-20. It took me a while and a few detours to figure out that the FE3 would work properly with another VIC-20 board.

Both are PAL boards, but the first one produces massive crosstalk between the RAM blocks on the FE3:

So I followed Jim's suggestions above and rewired the CR/W and VR/W signals:

Unfortunately, this didn't get my anywhere. When using VR/W from the expansion port instead of CR/W, the FE3 stops working. When I switch on the VIC-20 I only get the standard Basic screen with the internal RAM.

Has anyone found a way to fix this problem for the FE3 in the last 8 years? Or can you point me in the right direction, please?



See also this post on Forum64 (in German, though):
https://www.forum64.de/index.php?thread ... ost2148840

[Mike]

Has anyone found a way to fix this problem for the FE3 in the last 8 years? Or can you point me in the right direction, please?

The issue has never been fixed, but the reason is known: the timing of CPU R/W accesses is derived from CR/W with some delay states in the FE3 CPLD. This is and had always been wrong, the timing of memory access on the cartridge port is determined by VR/W. The sole exception are I/O chip register accesses, which are supposed to be gated by CR/W and SPhi2.

A fix would require a change of the logic equations in the CPLD and board layout fixes to take all 3 signals (CR/W, SPhi2 and VR/W) into account.

The issue is mostly apparent with NTSC VIC-20s, unfortunately also some PAL VIC-20s (like one of yours) are affected.

Jim Brain's modding instructions that you followed were mostly a shot in the dark, at a time where the reasons for that behaviour were not yet clearly understood.

[Bigby]

Jim Brain's modding instructions that you followed were mostly a shot in the dark, at a time where the reasons for that behaviour were not yet clearly understood.

I suspected as much, so I wasn't too surprised when it didn't work. But it didn't take much effort, so I thought I'd give it a try.

The issue has never been fixed, but the reason is known: the timing of CPU R/W accesses is derived from CR/W with some delay states in the FE3 CPLD. This is and had always been wrong, the timing of memory access on the cartridge port is determined by VR/W. The sole exception are I/O chip register accesses, which are supposed to be gated by CR/W and SPhi2.

A fix would require a change of the logic equations in the CPLD and board layout fixes to take all 3 signals (CR/W, SPhi2 and VR/W) into account.

Thank you very much for the clarification and for taking the trouble to answer my questions in all three threads! It's a bit of a pity that there is no real fix for this and that this issue has not been addressed in a later revision of the FE.

[Diddl]

Hi

We have made a bugfix working for the PAL board from @Bigby


The CPLD has two free IO (Pin 40 and Pin 5).
So it possible to wire the missing signal V R/W to the CPLD.
With a new JEDEC file for the CPLD the V R/W signal will used to improve timing for SRAM writing.


Fix:

• Take a wire and connect "V R/W" to Pin 40
• With this wire your FE-3 should work exactly same as bevore
• Now take out the CPLD, reprogram it with new JEDEC and insert it again

You can download CPLD files from my homepage:
https://oe7twj.at/index.php?title=Final_Expansion_3



For Bigby's PAL VC-20 this fix works fine.

It would be very interesting if this fix work also for problems with NTSC devices.
Here in europe a NTSC VC-20 is very rare.
So it is difficult to test the new JEDEC files.

[srowe]

Thanks for doing this. Is there any chance you can produce an SVF file that is compatible with OpenOCD?

[elwee]

In behalf of Diddl

[srowe]

Thank you very much.

[Bigby]

I can indeed confirm that the modified FE3 cartridge is now working flawlessly (RAM-Check, Doom, and all) on both of my PAL VIC-20. Including the one that was producing the cross-talk issues described above!

For those who'd like to play along, here's what I did:

1. Solder a bodge wire between pin 17 (VR/W) of the expansion port and pin 40 of the ATF1504. (Diddle mentioned pin 20 in his post above. That might have been a mistake, for me it was pin 40.) That would be the yellow one here:

2. Program the AFT1504 with the newly released version 3.3.2. using OpenOCD and my homemade programmer.

After installing the bodge wire, the FE3 will still work with the old CPLD version. But the new CPLD version does require the connection to pin 40.

I'd be very interested to hear if this fix also solves the issues the FE3 was having on NTSC VIC-20.

[Bigby]

This week, I modified tokra's Final Expansion cartridge in the same way as described above.

He was using it on his NTSC VIC-20 and has reported RAM issues before. See here, for example:

viewtopic.php?p=75976#p75976
viewtopic.php?p=83357#p83357
viewtopic.php?p=92160#p92160

I returned the updated FE3 to him and received feedback today: all checks are green now and it finally runs Doom! Looks like the bodge wire together with the updated CPLD might indeed solve the cross-talk problems on NTSC machines!

[srowe]

This week, I modified tokra's Final Expansion cartridge in the same way as described above.

I'm having problems reprogramming my CPLDs with the SVF file given above. It looks like it was built for a slightly different version of the chip, ATF1504ASV perhaps? In the file I see TDO (0151403f) vs TDO (0150403f). Do you have a different file? Or can this file be just edited to fix this?

Edit: yes, it seems the ATF1504ASV (which is the 3.3v variant?) has a different ID to the ATF1504AS (5v variant). I've regenerated the files for the four different devices that ATMISP supports

Code: Select all

[srowe@gilraen cpld]$ grep 0150403f test*
test-asl.svf:   TDO (0150403f)
test-as.svf:    TDO (0150403f)
[srowe@gilraen cpld]$ grep 0151403f test*
test-asvl.svf:  TDO (0151403f)
test-asv.svf:   TDO (0151403f)

[Bigby]

Edit: yes, it seems the ATF1504ASV (which is the 3.3v variant?) has a different ID to the ATF1504AS (5v variant).

Yes, indeed. I've had both the 3.3V and the 5V variant on the cartridges that I built and patched. The resulting SVF files differed in the device id, only. I'll attach both files here in addition to the archive provided by Diddl above.