UltiMem
Moderator: Moderators
Re: UltiMem
I doubt it. I know Marko submitted the patches, but I doubt they have been merged as yet.
I'd reach out to Marko for the most recent patches if interested.
I'd reach out to Marko for the most recent patches if interested.
Re: UltiMem
Just wondering if the UltiMem prototype has been tested against crosstalk? See here:
http://sleepingelephant.com/ipw-web/bul ... 976#p75976
The Final Expansion has an issue that writes to the $a400-area are sometimes (about 20% of the time) are mirrored to $0400-area and vice-versa. The problem happens on NTSC regularly, but has been seen on some PAL-machines as well. The MegaCart does not have this problem, just trying to make sure the UltiMem becomes the best product possible
Also, I was wondering: VICMIDI is basically an UltiMem with MIDI support? While you are at it, would it be possible to add an uIEC to the UltiMem instead or as well? I suppose anyone using and UltiMem would most likely use some SD2IEC-device as well.
http://sleepingelephant.com/ipw-web/bul ... 976#p75976
The Final Expansion has an issue that writes to the $a400-area are sometimes (about 20% of the time) are mirrored to $0400-area and vice-versa. The problem happens on NTSC regularly, but has been seen on some PAL-machines as well. The MegaCart does not have this problem, just trying to make sure the UltiMem becomes the best product possible
Also, I was wondering: VICMIDI is basically an UltiMem with MIDI support? While you are at it, would it be possible to add an uIEC to the UltiMem instead or as well? I suppose anyone using and UltiMem would most likely use some SD2IEC-device as well.
- majikeyric
- Vic 20 Afficionado
- Posts: 351
- Joined: Fri Oct 24, 2014 2:08 pm
- Website: http://majikeyric.free.fr
- Location: France
Re: UltiMem
With the Final expansion 3 writing to $2400-$2fff is also mirrored to $0400-$0fff... (PAL)
Re: UltiMem
How do you guard against it? It seems like, that thread, the culprit was using a 65C02. Alternatively, why is the MegaCart immune? I have a bit of extra space in the CPLD, though not much, and can add stuff if needed. But, first I have to understand the situation.tokra wrote:Just wondering if the UltiMem prototype has been tested against crosstalk? See here:
http://sleepingelephant.com/ipw-web/bul ... 976#p75976
The Final Expansion has an issue that writes to the $a400-area are sometimes (about 20% of the time) are mirrored to $0400-area and vice-versa. The problem happens on NTSC regularly, but has been seen on some PAL-machines as well. The MegaCart does not have this problem, just trying to make sure the UltiMem becomes the best product possible
There's no more room on the current PCB for uIEC. However, another PCB could be created that contains the uIEC. I like the idea, though, but I have a slightly different product idea in mind. Let me stew on it for a bit and get these out the door.Also, I was wondering: VICMIDI is basically an UltiMem with MIDI support? While you are at it, would it be possible to add an uIEC to the UltiMem instead or as well? I suppose anyone using and UltiMem would most likely use some SD2IEC-device as well.
JIm
Re: UltiMem
The issue has nothing to do with 65C02. This was another issue in that thread. Doom uses illegal opcodes and these won't run on the 65C02. It is unknown why the Final Expansion has crosstalk-issue and MegaCart does not. I suggest you just let the test-program run for some time on the prototype to check this:brain wrote:How do you guard against it? It seems like, that thread, the culprit was using a 65C02. Alternatively, why is the MegaCart immune? I have a bit of extra space in the CPLD, though not much, and can add stuff if needed. But, first I have to understand the situation.
http://www.tokra.de/vic/doom/crosstalk.prg
If you want this to run endlessly, just delete line 17 and change line 30 to
Code: Select all
30 run
Re: UltiMem
Proving the negative is always sketchy.
I think I see the issue, but it would be easier to prove my theory if I could find a schematic of MegaCart and FE3 to compare. FE3 web site appears down, and can't find a MegaCart schematic.
Jim
I think I see the issue, but it would be easier to prove my theory if I could find a schematic of MegaCart and FE3 to compare. FE3 web site appears down, and can't find a MegaCart schematic.
Jim
Re: UltiMem
For Final Expansion see this thread: http://sleepingelephant.com/ipw-web/bul ... =11&t=7061
Re: UltiMem
OK, got the schematic, now it looks like I need the CPLD equations for the Atmel 1504. Any ideas?tokra wrote:For Final Expansion see this thread: http://sleepingelephant.com/ipw-web/bul ... =11&t=7061
Re: UltiMem
OK, ran the test (thanks tokra):
Run 1: Forgot that the defaults for the bank registers are all 0 Program registered lots of errors
Run 2: I had issues, not with RAM, but with BLK0 getting bleed from the other blocks
Made change I thought would fix
Run 3: It is still running, but no issues as yet
The fix: WE on the RAM needs to be gated with clock
***EDIT: Mike notes this is not true, as I didn't see VR/W on the R/W pin: That is why the schematic on the linked topic had issues. the 7408 does not have PHI2 as an input.
***EDIT: It however, may explain why FE3 has an issue...
tl;dr: UltiMem had an issue, but it seems to be fixed now.
Jim
Run 1: Forgot that the defaults for the bank registers are all 0 Program registered lots of errors
Run 2: I had issues, not with RAM, but with BLK0 getting bleed from the other blocks
Made change I thought would fix
Run 3: It is still running, but no issues as yet
The fix: WE on the RAM needs to be gated with clock
***EDIT: Mike notes this is not true, as I didn't see VR/W on the R/W pin: That is why the schematic on the linked topic had issues. the 7408 does not have PHI2 as an input.
***EDIT: It however, may explain why FE3 has an issue...
tl;dr: UltiMem had an issue, but it seems to be fixed now.
Jim
Last edited by brain on Mon Nov 16, 2015 12:54 pm, edited 1 time in total.
Re: UltiMem
Glad I brought the issue up then Would have been a shame if the UltiMem wasn't able to play Doom.
Regarding the fix, do you think it is possible to apply to existing Final Expansions?
Regarding the fix, do you think it is possible to apply to existing Final Expansions?
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: UltiMem
As tokra already pointed out, in said thread not the RAM expansion was the culprit, it was the use of a 65C02 (Hint: Imperious didn't find any error with crosstalk.prg).brain wrote:That is why the schematic on the linked topic had issues. the 7408 does not have PHI2 as an input.
Most RAM expansions take the VR/W signal to drive the WE pin of the RAM chips, and this signal is already gated with Phi2. The shown schematic with the 74LS08 to recover A13, A14 and a single /CS for the 32K SRAM chip is perfectly legit.
Only when you use CR/W you need to take Phi2 into account. Otherwise "invalid" chip selects (put onto the expansion port /RAMx signals by VIC(!) during Phi1) can thrash the RAM.
Re: UltiMem
Yeah, I missed the VR/W. I was responding quickly and should have been more careful. It may, though, explain why FE3 has an issue.Mike wrote: Most RAM expansions take the VR/W signal to drive the WE pin of the RAM chips, and this signal is already gated with Phi2. The shown schematic with the 74LS08 to recover A13, A14 and a single /CS for the 32K SRAM chip is perfectly legit.
Only when you use CR/W you need to take Phi2 into account. Otherwise "invalid" chip selects (put onto the expansion port /RAMx signals by VIC(!) during Phi1) can thrash the RAM.
So, I am using CR/W, so should I switch my code to use VR/W?
Jim
Re: UltiMem
I think it is possible.tokra wrote:Glad I brought the issue up then Would have been a shame if the UltiMem wasn't able to play Doom.
Regarding the fix, do you think it is possible to apply to existing Final Expansions?
My first thought would be to to cut the CR/W trace to the FE3 and wire VR/W to that same trace.
ALternatively, one could "gate" the CR/W signal with a gate (WE = CR/W & PHI2), but it sounds like VR/W is basically that. (it has PHI1 in there, but not sure that needs to be in scope)
Jim
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: UltiMem
A look at the schematic of the VIC-20 shows, that the only two uses of CR/W are the generation of VR/W (obviously), and otherwise it goes directly to the R/W pin (pin 22) of the 2 VIAs. Those two, however, have also an Phi2 input (pin 25) and use that to qualify their register selects and data bus pins:brain wrote:So, I am using CR/W, so should I switch my code to use VR/W?
Consequently, the IEEE-488 interface cartridge also uses CR/W and Phi2 to control its two VIAs.MCS6522 data sheet wrote:1. PHASE TWO CLOCK (Phi2)
Data transfers between the MCS6522 and the system processor take place only while two Phase Two Clock is high. In addition, Phi2 acts as the time base for the various timers, shift registers, etc. on the chip.
If you have consistent logic equations, that use CR/W together with Phi2 regardless what access takes place (to the own control registers, cartridge RAM and cartridge ROM (Flash?)), and everything works, you can leave it as is.
Re: UltiMem
I do:Mike wrote:brain wrote:If you have consistent logic equations, that use CR/W together with Phi2 regardless what access takes place (to the own control registers, cartridge RAM and cartridge ROM (Flash?)), and everything works, you can leave it as is.
RAM and ROM is:
assign we = !(clock &
!r_w &
((ram_write_en & ram_sel) |
(io2_write_en & !io[2]) |
(io3_write_en & !io[3]) |
(blk1_write_en & !blk1) |
(blk2_write_en & !blk2) |
(blk3_write_en & !blk3) |
(blk5_write_en & !blk5)
)
); // active low
And registers are:
assign reg0_we = clock & reg_ce & !r_w & (address[3:0] == 0);