Soliciting VIC-20 Internal memory expansion ideas

[brain]

I think v2 proto has everything I need to continue the research:

Jim

[cobracon]

Looking good. Are you going to offer it up in your store once its completed? How much ram will be avaliable to basic with this installed?

[brain]

If I can master the arcane memory map of the VIC-I, I will see about a production run.

As for RAM, like UltiMEM, it can have access to 512kB+ of RAM, both from the VIC-I and the CPU. But, it depends on how much RAM is of actual use. UltiMEM has seen limited use beyond just being a 35k expander, so that's a bit disappointing.

Jim

[Mike]

If I can master the arcane memory map of the VIC-I, [...]

Well, $0000..$1FFF(VIC) <-> $8000..$9FFF(CPU) and $2000..$3FFF(VIC) <-> $0000..$1FFF(CPU), except for the external +3K RAM expansion, because that one sits on the wrong side of the bus buffers with stock hardware.

How much ram will be avaliable to basic with this installed?

The yet unnamed project discussed here should allow for the screen RAM being put at $0400 (because here it's on the VIC side) with BASIC RAM starting at $0601, furthermore, the BASIC RAM could extend beyond $7FFF - 'under' the character ROM, up to $8FFF actually. This should give 35327 BYTES FREE for BASIC.

In a similar fashion, my VFLI mod also allows to put screen RAM and BASIC start at $0400 and $0601, respectively, just there's no RAM under character ROM. Which already gives 31231 BYTES FREE.

UltiMEM has seen limited use beyond just being a 35k expander, so that's a bit disappointing.

Having MINIMON softloaded and write-protected in $9800..$9FFF is one of the nicer things one can do with UltiMEM.

Neither Mega-Cart nor FE3 would have allowed for this feat as they permanently map in their registers in said I/O area and wouldn't allow them to be made transparent/invisible.

[brain]

Yep, grabbed the map from your previous posts. But, it's still unclear how I should make the 16kB relocatable across the 64kB. the default is 8,9,0,1 so should the other configs be a,b,2,3, c,d,4,5 and e,f,6,7 or Should I do something a bit more sane for the other options...

New board is held up due to DHL taking a breather due to the virus, but the current board should have everything but color RAM in possible action across all 64kB. Any interest in some demo apps to try out some ideas? (Color RAM support is coming with the new board rev).

Jim

[Mike]

Note VIC has no dedicated chip select, rather it selects by itself when it senses the address $10xx on the VA bus, ...

[...] how I should make the 16kB relocatable across the 64kB. the default is 8,9,0,1 [...]

... so any idea that amounts to moving the I/O area (at least VIC, but possibly also the VIAs) to another place than $9xxx will just break each and every program for the VIC-20, including the ROM firmware.

Any interest in some demo apps to try out some ideas? (Color RAM support is coming with the new board rev).

Well, I've pointed you to my VFLI mod at least twice here in this thread.

You find the VFLI display routines over there for both PAL and NTSC, but you will have to work out for yourself how to adapt them to your hardware. This mainly concerns any alternative mapping mechanism/register of the extra Colour RAM address lines (a.k.a. Colour RAM bank).

You could also try the detect program, whether it detects an additional 3K at $0400..$0FFF as accessible for VIC with your hardware - my guess would be "no" (i.e. false negative) at the moment though, as the function of the routine ultimately depends on the parasitic capacities of the BD bus signal lines which will be much less if they are realised as wire bundle from VIC daughter board to CPU daughter board (instead of the original traces on the mainboard).

Other than that, and feature-wise: the ability to have RAM below all ROMs (with the already mentioned extra flexibility for $8000..$8FFF to be either RAM or ROM for VIC or CPU independently) is nice for sure. Having an essentially randomized address layout over the whole 64K, not so much.

[brain]

I noticed (and have dloaded the relevant data) your VFLI stuff, and thanks for providing that and the link. I worry that the VFLI mod (which I can't try yet, as I suspect it needs working color ram, and I don't have it working as yet) will be a bridge too far for initial testing. IN other words, if it doesn't work, I wouldn't have any idea where to start debugging.

I was thinking there might be a set of stepping stone demos that would help with debugging. Screens in alternate locations, color RAM test, etc. and then VFLI.

I will try the detect app and see what it does.

Still, I understand. It's essentiall stock or VFLI. It just appears a large canyon exists between those two spots.

Jim

[Mike]

I was thinking there might be a set of stepping stone demos that would help with debugging. Screens in alternate locations, ...

That's an easy one: just enable RAM in RAMx ($0400..$0FFF), hopefully accessible by VIC and then do a LOAD"MAX.PRG",8,1 from said thread. If you get a working display with an extra 3K free (like 27.5K -> 30.5K), then that capability works, i.e. $0400..$0FFF is visible by VIC.

color RAM test,

The VFLI display mode requires 16 colour RAM banks selectable by a register, and important, that register needs to be both readable and writable as an RMW instruction of the 6502 (INC, to be exact) is used to update it.

The VIC-20 will start up with whatever bank is in that register upon power on or reset and the KERNAL thus will initialise only that bank. When you select another bank, with a POKE in direct mode, all characters on screen except the new "READY." and the cursor will change colours randomly. When you then clear the screen you'll see you can still define all colours as usual, just in another bank.

That is a kind of test that wouldn't require any test suite. Just a handful of register POKEs.

etc. and then VFLI.

If you have conducted the aforementioned tests, and they produce the desired result, then all that's necessary is you tell me the address of the colour RAM bank register (and, if present, the data direction register of the associated port) - and then I'll assemble an NTSC version of the VFLI display routine for your hardware. Deal?

I will try the detect app and see what it does.

We'll see.

Still, I understand. It's essentiall stock or VFLI. It just appears a large canyon exists between those two spots.

... and the RAM under ROM capability for BASIC, KERNAL, CHAR is orthogonal to that: VFLI doesn't require banked ROMs and banked ROMs don't imply VFLI but of course you can have both in a VIC.

[brain]

Unit boots to 28159 bytes free

detect.prg blinks and returns.
max.prg resets with 31103 bytes free
3k.prg resets with 3711 bytes free

Can't go any further until I have working COLOR RAM.

Jim

[Mike]

detect.prg blinks and returns.

As I had suspected. This is a false negative.

max.prg resets with 31103 bytes free, 3k.prg resets with 3711 bytes free

Those figures come rather unexpected. "max.prg" with an upper 24K RAM expansion should give 31231 BYTES FREE, and "3k.prg" should give the number for an unexpanded VIC-20, 3583 BYTES FREE.

At least the working display with "max.prg" suggests the internal RAM expansion is visible to VIC, but the KERNAL RAM test is not quite convinced about the total amount of available RAM.

You should also try out my more extensive RAM check I released in another thread. It also checks for crosstalk: http://sleepingelephant.com/ipw-web/bul ... 0&start=30

Can't go any further until I have working COLOR RAM.

As said, you should first sort out aforementioned obscurities, before tackling the colour RAM.

[brain]

Sadly, (https://dateipfa.de/.Public/denial/tools/ram_check.zip) runs and then locks up. No text printed on screen. Not sure what is going on.

Jim

[Mike]

This RAM check expects fully working internal RAM as present on an unmodified VIC-20, in the ranges $0000..$03FF and $1000..$1FFF. The first thing the boot program does is, temporarily reduce the RAM available to BASIC to said unexpanded configuration. The RAM check itself then runs in unexpanded RAM and tests only those memory ranges normally supplied by an external RAM expansion cartridge.

As you even replace the internal RAM by your own setup, that 'save harbour' cannot be guaranteed anymore. Some of the memory select logic you devised must be fundamentally wrong. Simple byte-wise tests (as the KERNAL does) succeed, but there might be cross-talk, or other issues even over the formerly unexpanded RAM. I doubt you'd get anything non-trivial running under these circumstances.

Can you try to run just MINIPAINT? It runs with at least +16K RAM.

[brain]

Yep, loads and seems to run fine. Played around with it for a bit, making pics on the screen.

Jim

[Mike]

O.K.

MINIPAINT only wants functioning RAM in the original unexpanded range, plus BLK1 and BLK2.

When you tried to run the RAM check, did you actually do LOAD"BOOT",8,1 on the start-up prompt? How did you use the *.d64 image? From a SD2IEC device, or did you transfer the *.d64 contents to a disk and then ran it from a real CBM drive? Either method should work.

What is *not* supposed to work is a file based transfer not honouring the CBM file types. The main program has to be of SEQ file type. If that is not the case, that is one possible reason you got a blank screen on startup.

[brain]

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