Denial

Update: I updated my FE3 firmware to REV 22E and the problem still exists.

Crosstalk reports blocks 1>0, 2>0, 3>0, 5>0 with either 22D OR 22E...

Probably best to downgrade to 22d again.

22e has issues with trying to flash programs to the firmware for the cart menu.
It doesn't work and the menu locks up.

I'll have to look into the crosstalk issue when I start my revision of the firmware. I'll look at the links in this thread but would appreciate any other links with information that might be helpful in regard to this issue.

Heather

See here: http://sleepingelephant.com/ipw-web/bul ... =45#p83337

To make this clear: the crosstalk is *not* a matter of the cartridge firmware that is executed on the VIC-20 for the FE3-Menu.

If anything, what is responsible for the cross-talk are the logic equations in the CPLD, which provides the FE3 registers and governs access to the RAM and Flash-EPROM corresponding to the register settings. No change in the FE3-Menu firmware is going to fix that behaviour.

What needs to be checked is the timing delay when RAM1..3 is accessed by VIC-20 vs the timing delay of BLK1..3 and BLK5. Two scenarios are possible: either the address of the 512K SRAM is changed during write, so the same data is written to two places. Or, during read, the address is changed between two places, so the CPU only gets to read from the last address.

It must be made sure, that:
- before /CS for the SRAM is activated, the correct address is put on the address pins of the SRAM, and latched for the entire time /CS is low,
- before /WE for the SRAM is set low, valid data must be put on the data pins of the SRAM, and latched for the entire time /WE is low.

If necessary, the CPLD firmware needs to employ an additional internal state machine to ensure this works. Just relying on several, essentially undocumented time delays within the CPLD, and for different VIC-20s, is not going to work reliably.


Similar effects are also seen with much simpler RAM Expansions for 32K, where different delays of BLK5 vs. BLK1..BLK3 in the 74LS08 signal path presumably lead to crosstalk between BLK5 and the other three blocks.

Neo-Rio wrote:Probably best to downgrade to 22d again.

22e has issues with trying to flash programs to the firmware for the cart menu.
It doesn't work and the menu locks up.

Thank you for posting this, I was about to start a new thread regarding this exact same issue. I'll try downgrading tonight.

Whoever maintains the FE3 page on Denial Wiki (link below), perhaps a section could be added for 'known issues' for this type of errata?
http://sleepingelephant.com/denial/wiki ... _Expansion

Thanks for the great explanation Mike. I do have the CPLD source code but I have never done CPLD programming so I wouldn't know where to start debugging this issue. Maybe someone else could help out?

Heather

Heather, I presumed the CPLD source was lost when Diddl shut down his ftp server (it had been hacked several times).

Is the source available on github or sourceforge? I *really* would like to take a sharp look at it.

Drop me a PM with your email address and I'll send it your way. It would be great if someone were to put it on github or sourceforge. I can put them out there eventually when I have a bit of time.

Heather

Bad news with the Ultimem: crashes after decrunsh on both VICE and real hardware (sd2iec).

Doom works perfectly fine for me on my UltiMem. Are you sure it is configured correctly?

Try
POKE 40945,3:POKE 40946,255:POKE 40944,64

before loading Doom. Worksforme

Nope. Breaks a second later in the init part now.

You are still talking about VICE-only, right? I found out why it does not work there. The Ultimem-emulation sets the default values for the registers incorrectly. This way if you activate expansion memory, it will sometimes use the same physical memory on the Ultimem, so there will be crosstalk (= memory corruption)

This was talked about before.

Before loading Doom try: Just tested this in VICE 3 - works for me. And I know I tested Doom earlier on the real machine.

Usually poke40944,64 should reset the Ultimem and the VIC, however in emulation this does not work as well, so I added the sys64802

On the real machine this should note be necessary, but the program should work there as well.

tokra wrote:You are still talking about VICE-only, right?

Oh nonono. Just set up the real machine again.

Just tried on my real machine again. Works perfectly fine. If you use the original UltiMem-image it may be possible that this screws up the original register-settings as well. I suggest you use my small BASIC-program to set them correctly before loading Doom. It should work then. You may want to make sure memory is set up correctly and run my crosstalk-checker beforehand:

crosstalk.prg

It should show which blocks are available (should be 0,1,2,3,5) and then after pressing Space some seconds later just display "READY."