Soliciting VIC-20 Internal memory expansion ideas
Moderator: Moderators
Re: Soliciting VIC-20 Internal memory expansion ideas
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
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
Re: Soliciting VIC-20 Internal memory expansion ideas
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...Mike wrote: ↑Mon Feb 10, 2020 6:33 amPlease disable any kind of OS extensions like JiffyDOS and re-run the RAM check with a standard KERNAL and BASIC ROM only.brain wrote:@cd:ramcheck.d64
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.
max.prg still gives the wrong number, and not sure what detect.prg should do. 3k.prg does as the name suggests.
Jim
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
Nice!brain wrote: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...
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).max.prg still gives the wrong number,
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.and not sure what detect.prg should do.
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.
O.K.3k.prg does as the name suggests.
Greetings,
Michael
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Soliciting VIC-20 Internal memory expansion ideas
I bow before thee ! This is one massive bundle to manage.
I hope the results are worth the efforts.
Be normal.
Re: Soliciting VIC-20 Internal memory expansion ideas
Yep, mine gives 31103 bytes free.Mike wrote: ↑Tue May 12, 2020 3:28 amThat'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).max.prg still gives the wrong number,
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
And you see 28159 BYTES FREE in the start-up message of BASIC before, right?brain wrote:[...] mine gives 31103 bytes free.
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.
Re: Soliciting VIC-20 Internal memory expansion ideas
OK, it does now. Looks like all is good.
Now, I need to write some apps to play with the expansion.
Jim
Now, I need to write some apps to play with the expansion.
Jim
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
brain wrote:OK, it does now. Looks like all is good.
Do you have any idea what was the reason for the divergent behaviour?
Re: Soliciting VIC-20 Internal memory expansion ideas
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
Jim
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
Here's the disassembly of 'max.prg'. Changing ($0302) from the default is what autostarts max.prg when loaded with ",8,1":brain wrote:So, point to note, if you run the max.prg with JD installed, you get 128 bytes less. Not sure why.
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
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 ...]
Re: Soliciting VIC-20 Internal memory expansion ideas
I'm happy to send you a copy of VIC JD to compare.
Jim
Jim
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
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.brain wrote:I'm happy to send you a copy of VIC JD to compare.
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.
Re: Soliciting VIC-20 Internal memory expansion ideas
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
Jim
- Mike
- Herr VC
- Posts: 4842
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Soliciting VIC-20 Internal memory expansion ideas
Point taken. However, as you've already announced to -
- 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.Jim wrote:[...] write some apps to play with the expansion.
Re: Soliciting VIC-20 Internal memory expansion ideas
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
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