Denial

I understand. It's just that navigating d64 images and such to run some of these tests is exceedingly difficult without a working wedge, and having to open15,10,15,"cd:....":close 15... to try them out greatly increases the test cycle at times.

Jim

I'm happy to send you a copy of VIC JD to compare.

Jim

My regular/JD KERNAL mod switched back in some cases while powered. So, point to note, if you run the max.prg with JD installed, you get 128 bytes less. Not sure why.

Jim

OK, it does now. Looks like all is good.

Now, I need to write some apps to play with the expansion.

Jim

max.prg still gives the wrong number, That's strange. "All" that max.prg does is: moving the screen down to $0400, setting the BASIC start to $0601, and leaving BASIC end as is. Which *should* result in 31231 BYTES FREE, when the read out before was 28159 BYTES FREE (it simply adds the 30...

@cd:ramcheck.d64 Please disable any kind of OS extensions like JiffyDOS and re-run the RAM check with a standard KERNAL and BASIC ROM only. The RAM check reinitialises both BASIC and KERNAL vectors at $03xx, and it also utilises the tape buffer to hold machine code - this likely collides with works...

So, more probes to the rescue: https://i.postimg.cc/h4k64rX1/IMG-0205.jpg Along the way, I determined that the inverted clock from the VIC and the one at the VIC shift by ~ 21nS: https://i.postimg.cc/7YSc5278/la.png Anyway, I *FINALLY* traced the issue down to this statement: assign _we_mem = r_w_cp...

Debugging got harder, so I finally hooked the unit up to my 16702A logic analyzer: https://i.postimg.cc/3R66vjn7/IMG-0201.jpg I was able to get the VIC signals flowing through the "switch" daughtercard I installed, where the signals were simply being buffered by the CPLD from the VIC socke...

Jim, I think the fundamental misunderstanding on your side is, that VIC addresses on the VA bus somehow are translated to CPU addresses on the CA bus. The reverse is the case. VIC has its own 14 bit address space, and selects itself there (during PΘ2=1 or, equivalently on the VIC-20, during SΘ2=1) ...

Brian says, address lines are having some issue. Trying to track it down. You may want to check out the address buffers and VA13. The CA13 does match up with VA13 on the schematic, it uses BLK4 to pass CA13 to VA13. What are you trying to do with the CPLD? I've tried replacing the buffers, LS245's,...

Thanks for giving it some love. I always thought more people would want the extra RAM.

Jim

Last night and today saw some time to wire up the buffer board. https://scontent-ort2-2.xx.fbcdn.net/v/t1.0-9/94708000_1553319774827807_7962991906495922176_o.jpg?_nc_cat=107&_nc_sid=8024bb&_nc_oc=AQkSQA_YxA9sSdYr-1LLdmeO55Tf1-kYyTimt_IM9CGenCsj9dwoBHMMxI6_E6QYPFA&_nc_ht=scontent-ort2-2.x...

Looks more to me like Jim's project is in hibernation mode since mid-February, for whatever reasons. I wired up the new board, and quickly got the CPU RAM expansion working. But, when I tried to bridge over the VIC bus, it all went south. I have to take some time to redo my "buffer board"...

I have one (I think it needs a sound shield), and it works just like the 1525.

Jim

I use uIEC/SD, which is an sd2iec device.

I did:

@cd:ramcheck.d64
load"boot",10,1
(loads, but then no cursor)
/boot loads and I get a cursor back, but then nothing after I run.

Jim