New Release: Doom

Discussion, Reviews & High-scores

Moderator: Moderators

User avatar
fuzzybad
Vic 20 Drifter
Posts: 37
Joined: Wed May 20, 2015 8:48 am
Location: Chicago
Occupation: Developer

Re: WIP: Doom

Post by fuzzybad »

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...
Neo-Rio
Vic 20 Amateur
Posts: 45
Joined: Sun Jun 07, 2015 5:57 pm
Location: Oz

Re: WIP: Doom

Post by Neo-Rio »

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.
SkydivinGirl
Vic 20 Devotee
Posts: 204
Joined: Thu Jan 28, 2010 9:19 am

Re: WIP: Doom

Post by SkydivinGirl »

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
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: Doom

Post by tokra »

User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: WIP: Doom

Post by Mike »

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.
User avatar
fuzzybad
Vic 20 Drifter
Posts: 37
Joined: Wed May 20, 2015 8:48 am
Location: Chicago
Occupation: Developer

Re: WIP: Doom

Post by fuzzybad »

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
SkydivinGirl
Vic 20 Devotee
Posts: 204
Joined: Thu Jan 28, 2010 9:19 am

Re: WIP: Doom

Post by SkydivinGirl »

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
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: WIP: Doom

Post by Mike »

:shock:

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.
SkydivinGirl
Vic 20 Devotee
Posts: 204
Joined: Thu Jan 28, 2010 9:19 am

Re: WIP: Doom

Post by SkydivinGirl »

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
User avatar
pixel
Vic 20 Scientist
Posts: 1330
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: WIP: Doom

Post by pixel »

Bad news with the Ultimem: crashes after decrunsh on both VICE and real hardware (sd2iec). :(
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: Doom

Post by tokra »

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
User avatar
pixel
Vic 20 Scientist
Posts: 1330
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: WIP: Doom

Post by pixel »

Nope. Breaks a second later in the init part now. :(
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: Doom

Post by tokra »

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:

Code: Select all

0 fori=40945to40959:reada:pokei,a:next
1 poke40944,64:sys64802
2 data63,255,18,1,0,2,0,3,0,4,0,5,0,6,0
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.
Last edited by tokra on Fri Mar 03, 2017 3:49 pm, edited 1 time in total.
User avatar
pixel
Vic 20 Scientist
Posts: 1330
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: WIP: Doom

Post by pixel »

tokra wrote:You are still talking about VICE-only, right?
Oh nonono. Just set up the real machine again. :D
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: Doom

Post by tokra »

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."
Post Reply