Soliciting VIC-20 Internal memory expansion ideas

[brain]

So, more probes to the rescue:



Along the way, I determined that the inverted clock from the VIC and the one at the VIC shift by ~ 21nS:



Anyway, I *FINALLY* traced the issue down to this statement:

assign _we_mem = r_w_cpu;

Which is wrong. One a cycle where the CPU was writing data, the VIC cycle would also be a write, meaning that data would be corrupted with the address given. It should be:

assign _we_mem = (phi0_bus ? r_w_cpu : 1); // always read on VIC half of cycle

With that, things started improving, and I was able to pull off some of the extra logic. Which brings me to:



(Using a too long and too wide IDE cable for now...)

So, now, the VIC and CPU are completely bypassing the ROM and RAM on the motherboard. I still need to write the code to handle color mem (I'll just chop the VIC cycle in half and read the color RAM on the first part of that time period, since the RAM is fast enough).

Jim

[brain]

@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 workspace used by OS extensions.

Generally, you'd want to run such tests with as few unknowns as possible.

OK, I was finally able to debug the hardware last night and found the bug. I burned a new standard KERNAL image and tried ramcheck. Every test passes...

max.prg still gives the wrong number, and not sure what detect.prg should do. 3k.prg does as the name suggests.

Jim

[Mike]

OK, I was finally able to debug the hardware last night and found the bug. I burned a new standard KERNAL image and tried ramcheck. Every test passes...

Nice!

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 3072 bytes of $0400..$0FFF to BASIC memory).

and not sure what detect.prg should do.

You'd "normally" see a pattern of white vertical stripes on black that change from full black, thin white stripes, thick white stripes, white and back again to black within roughly 1/4 second.

This is a pattern sequence that is assumed to be fetched by VIC in the $0400..$0FFF address range, remaining on the data bus due to parasitic capacitance, and then read on the following half-cycle by the CPU, by accessing "open" address space in BLK4. If at any point the CPU doesn't see the data the VIC fetched on the preceding half-cycle, the test is aborted.

On my VFLI modded VIC-20 it works as supposed as I did not change the memory access architecture besides some careful repurposing of UC4 and U13. All signals still go over the mainboard and through the bus buffers.

As you've completely redesigned the VIC-20 mainboard in effect, with some extra barriers between VIC and CPU bus (and probably also reduced parasitic capacitance on the data bus signals - or even extra load because of the attached logic probes!) you get a false negative result. There's not much I can do here. Most important thing is - you get a display with the screen at $0400. That works, and that's great.

3k.prg does as the name suggests.

O.K.

Greetings,

Michael

[eslapion]

So, more probes to the rescue: ...

I bow before thee ! This is one massive bundle to manage.

I hope the results are worth the efforts.

[brain]

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 3072 bytes of $0400..$0FFF to BASIC memory).

Yep, mine gives 31103 bytes free.

[Mike]

[...] mine gives 31103 bytes free.

And you see 28159 BYTES FREE in the start-up message of BASIC before, right?

Those are exactly 128 bytes missing from the expected value.

Please do a PRINT PEEK(55)+256*PEEK(56) after you have run 'max.prg'.

If this is anything other than 32768 (provided you *had* those 28159 bytes free before), there is still something else operating in your VIC-20 before you run max.prg, which seems to lower the BASIC top address by 128 bytes (and then the PRINT statement above will print 32640 instead of the expected 32768). Could be function key definitions, or similar tools that keep/protect information at the end of BASIC memory.

[brain]

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

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

Jim

[Mike]

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

Do you have any idea what was the reason for the divergent behaviour?

[brain]

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

[Mike]

So, point to note, if you run the max.prg with JD installed, you get 128 bytes less. Not sure why.

Here's the disassembly of 'max.prg'. Changing ($0302) from the default is what autostarts max.prg when loaded with ",8,1":

Code: Select all

MAX.PRG

.02EB  A2 FF     LDX #$FF
.02ED  78        SEI
.02EE  9A        TXS
.02EF  D8        CLD
.02F0  20 9B FD  JSR $FD9B   ; enter RAMTAS at $FD9B instead of $FD8D (see below)
.02F3  A9 06     LDA #$06
.02F5  8D 82 02  STA $0282   ; force BASIC start to $06xx (i.e. $0601 under most circumstances)
.02F8  A9 04     LDA #$04
.02FA  8D 88 02  STA $0288   ; force screen start to $0400
.02FD  4C 32 FD  JMP $FD32   ; continue RESET routine

>0300  3A C4 EB 02

And here's an excerpt from the KERNAL RESET routine. If there are any differences in the JD KERNAL, then that's why it doesn't work as expected:

Code: Select all

VIC-20 KERNAL RESET routine

.FD22  A2 FF     LDX #$FF    \
.FD24  78        SEI          \  max.prg copies these
.FD25  9A        TXS          /  four instructions ...
.FD26  D8        CLD         /
.FD27  20 3F FD  JSR $FD3F   \
.FD2A  D0 03     BNE $FD2F    >  ... omits the cartridge check ...
.FD2C  6C 00 A0  JMP ($A000) /
.FD2F  20 8D FD  JSR $FD8D   >   ... enters RAMTAS at $FD9B (see below) ...
.FD32  20 52 FD  JSR $FD52   \
.FD35  20 F9 FD  JSR $FDF9    \
.FD38  20 18 E5  JSR $E518     > ... and continues the KERNAL reset routine here.
.FD3B  58        CLI          /
.FD3C  6C 00 C0  JMP ($C000) /


KERNAL RAMTAS

.FD8D  A9 00     LDA #$00    \
.FD8F  AA        TAX          \
.FD90  95 00     STA $00,X     \  clear zeropage,
.FD92  9D 00 02  STA $0200,X    > $02xx and
.FD95  9D 00 03  STA $0300,X   /  $03xx
.FD98  E8        INX          /
.FD99  D0 F5     BNE $FD90   /
.FD9B  A2 3C     LDX #$3C    <-- max.prg enters here
.FD9D  A0 03     LDY #$03
.FD9F  86 B2     STX $B2
.FDA1  84 B3     STY $B3
[... KERNAL RAMTAS continued ...]

[brain]

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

Jim

[Mike]

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

That shouldn't be necessary. IIRC, JD does have a somewhat changed reset routine - with a shortened RAM test for a faster startup with bigger RAM expansions - so things like this are bound to happen.

As I wrote in an earlier post: when testing new hardware, it's a good idea to reduce the number of unknowns. The unexpected behaviour of JD with 'max.prg' is just a point in case.

[brain]

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

[Mike]

Point taken. However, as you've already announced to -

[...] write some apps to play with the expansion.

- an adapted version of max.prg that interworks better with JD, or a version of the JD KERNAL that automatically includes the 3K extra RAM, should anyhow be on your to-do list.

[brain]

You may be underestimating my programming skills.

In any event, one hurdle remains. I need to timeslice the memory access system so that I can fit a pull of color memory during the VIC half cycle. I've put a fast oscillator into the board now (footprint was already there), and am working on that aspect. I suspect I'll break the board again for a bit while I fit this extra memory access into the mix.

Jim