Vic20 5k memory

Basic and Machine Language

Moderator: Moderators

User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Vic20 5k memory

Post by beamrider »

Great!

..so have you come to a definitive list of what can be used in the bottom 1K yet with/without keyboard support?

Which brings me to a second question, how do you populate the bottom 1K on an unexpanded VIC, since you need the kernel and zero page/tape buffer etc during loading and presumably BASIC afterwards to call your start-up code?
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: Vic20 5k memory

Post by tlr »

beamrider wrote:Which brings me to a second question, how do you populate the bottom 1K on an unexpanded VIC, since you need the kernel and zero page/tape buffer etc during loading and presumably BASIC afterwards to call your start-up code?
You will need to have a small amount of code that sets up the last bit.

1:
The memory can be used for something tables/data that can be generated at startup or for buffers required during execution. I use this approach in datapop.

2:
In most real programs there is going to be a short run of the same byte somewhere. This can be used to house the final loading or decrunching code. The equal byte run is then written over the loader/decruncher using a very small loop.
eg:

Code: Select all

lp: sta addr,x
    dex
    bne lp
    jmp entry
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Vic20 5k memory

Post by beamrider »

Perhaps, you could also load the program in two parts. In the first part you could put 512 bytes into the lower nybbles of the two colour RAM areas (where you don't need it whilst loading - if you don't mind multicolured text) and then relocate it to the first four pages after the main program has loaded?
Last edited by beamrider on Fri Nov 21, 2014 10:05 am, edited 1 time in total.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: Vic20 5k memory

Post by tlr »

Absolutely, if you don't need arbitrary contents in the color ram that is a good strategy. 256 bytes is plenty of space for a loader/decruncher so you can keep the colors for at least one full screen arbitrary if you like.

The clean up loop is going to be slightly larger though as you need to shift half of the data into high nybbles.
johncl
Vic 20 Amateur
Posts: 58
Joined: Sat Dec 22, 2007 3:17 am

Re: Vic20 5k memory

Post by johncl »

Yes, I use for example the tape buffer now for the map, and had planned to use the stack for objects tables (things monsters drop and is found around the map). I might relocate some of these though if I can have a longer contiguous block although my objects structure can be easily adapted to have "holes" in the table for memory area I should not touch. If I can fit the custom charset things (which I really will aim for now), its possible to copy in char-data to that a needed between e.g. levels. Or flipflop chardata for example to have a separate set for an intro/attract/story screen.

When loading the main program you can fill the area you had planned to use for the screen and just relocate that data somewhere else.

I have used exomizer on the C64 so that might also be used to unpack as needed, although I guess some simple RLE thing is easier and the unpacker code certainly takes less space. I was surprised however how good exomizer was even on general code.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic20 5k memory

Post by Mike »

beamrider wrote:Which brings me to a second question, how do you populate the bottom 1K on an unexpanded VIC, since you need the kernel and zero page/tape buffer etc during loading and presumably BASIC afterwards to call your start-up code?
:lol:

This reminds me of something:

Some 'fun' was the result, when I wrote a viewer for MG pictures, where the viewer was supposed to run on an unexpanded VIC-20. Normally, the pictures can be loaded into MINIPAINT, with the @LOAD command of MINIGRAFIK or stand-alone with LOAD and RUN. But these three methods require at least a +8K RAM expansion (and MP needs +16K). My three design aims were:

- re-use (most of) the display routine built into each picture,
- it should be possible to load a picture from tape (which prohibited using the tape buffer for the viewer code), and
- make only one pass to load all of the picture data.

The third point also was a necessity for sensible tape usage. With two passes, the program logic might have worked out somewhat simpler but that would have required a rewind in-between for tape - very user un-friendly. When loaded, the picture fills the entire memory of $1000..$1FFF.

For this to work, the viewer resides in the lower 1K, in the stack; it patches and relocates absolute addresses within the original display routine. Two routines, that one setting up the 'text' screen and the other one moving the bitmap to the correct position had to be replicated. At least I could re-use a routine in the BASIC interpreter for the block move.

If you take a look at the code, you'll maybe reenact what knots I had to make in my brain to implement it. Here's the result: link.

I later used an updated version of this viewer to show the title screen of my type-in collection and then chain to the menu. :)
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: Vic20 5k memory

Post by tlr »

johncl wrote:I have used exomizer on the C64 so that might also be used to unpack as needed, although I guess some simple RLE thing is easier and the unpacker code certainly takes less space. I was surprised however how good exomizer was even on general code.
Exomizer compresses very well but due to it's fairly large runtime footprint it might not be the best cruncher for an unexpanded application on the vic. For instance it supports 64 Kb lengths and offsets which is just a waste of space on a 5Kb machine.

RLE on the other hand might be too bad at compressing the data.

My guess is that something like byteboozer would be a better compromize here.

Are you trying to decompress only once at start up or will you decompress during the game in some way?
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: Vic20 5k memory

Post by darkatx »

Mike wrote:...
For this to work, the viewer resides in the lower 1K, in the stack; it patches and relocates absolute addresses within the original display routine. Two routines, that one setting up the 'text' screen and the other one moving the bitmap to the correct position had to be replicated. At least I could re-use a routine in the BASIC interpreter for the block move.
Ahhh, so that's what was going on there...nice!
Learning all the time... :)
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Re: Vic20 5k memory

Post by rhurst »

Since RAMTAS was mentioned in this thread: if all RAM blocks are occupied, I know the 3K expansion and 8K game cartridge space are incongruent with BASIC, so it is not reported as part of the BYTES FREE. But, is there any system startup evidence left behind that it detected either/both of those "unused" RAM blocks? Something to quickly reference instead of a memory "poke/peek" later in my app to see if there's RAM there.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: Vic20 5k memory

Post by tlr »

rhurst wrote:Since RAMTAS was mentioned in this thread: if all RAM blocks are occupied, I know the 3K expansion and 8K game cartridge space are incongruent with BASIC, so it is not reported as part of the BYTES FREE. But, is there any system startup evidence left behind that it detected either/both of those "unused" RAM blocks? Something to quickly reference instead of a memory "poke/peek" later in my app to see if there's RAM there.
Probably not. Anyway I think in program detection should be preferred. It isn't too complicated and then the program will work even if someone software disabled expansions previously.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic20 5k memory

Post by Mike »

If a program has "specialist" requirements regarding the RAM layout, one idea could be to unexpand the VIC-20 during boot and run a program in that configuration - the internal RAM is effectively guaranteed to be there - and let it check all available memory. If the requirements are met, "re-expand" and run the client; otherwise refuse to continue, say "sorry" and point the requirements out to the user. Much better than a crash.

The "habit" of VICE to autostart with ",8,1" as standard behaviour makes the implementation a little more complex. For my type-in collection, I recently revised the boot loader to load to $02A1, extending into the tape buffer and overwriting the warm start vector during load, causing an auto start. The code then restores the warm start vector, initialises I/O, unexpands the VIC-20 and chains to an arbitrary program - here: the splash screen which itself then chains to the menu.

Now someone could try to load the boot loader with ",8" to the standard BASIC start. In that case, he is presented with a BASIC stub. 8) When RUN, the SYS and the following code are crafted to run at any conceivable address (not only those leaving a remainder of 1, when divided by 256), a small routine then copies the boot loader down to $02A1 and re-enters the code in its intended location. :mrgreen:
johncl
Vic 20 Amateur
Posts: 58
Joined: Sat Dec 22, 2007 3:17 am

Re: Vic20 5k memory

Post by johncl »

Reached the limit of the unexpanded Vic20 with my VICRPG (working title), and there is still quite a bit to add to the game. Been optimizing a bit here and there (which is great fun), trying to find smart ways of arranging the code saving space, better use of registers, etc. Also moved all variables down to zero page, and I guess I got some 400-500 bytes left in the first 1K of memory ($0000-$3ff) although that is somewhat fragmented due to some being reserved to kernal (irq table, keyboard stuff, and possibly some more I dont know about yet).

I know I can load much of my data into screen memory area at $1e00-$1fff and just relocate that down to the free areas in the first 1K. I have tried exomizer and it packs the whole game down to 3114 bytes which works fine to unpack into main last 4K area (including screen). About 512 bytes of the first 1K is used for vars, tables, maps, etc, all generated - 32 bytes reserved for stack.

It would be fun to get it all running on unexpanded, but 400 bytes might not be enough, I feel its very close though. :) - Atm I am "plugging in" a 3kb expansion in Vice, although my intention was to have that optional and load a more beefed up intro screen + story + music if you had that. :)
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Vic20 5k memory

Post by beamrider »

It is indeed admirable attempting to squeeze an impressive program into a standard Vic-20, mainly on account of the intellectual challenge.

Having said this, it is reasonable to assume that anyone still actively involved with the Vic-20 will have at least 16K expansion (as was shown by a recent poll on here) and even more people will be using emulation. So IMO if you can't fit your vision onto an unexpanded machine, then you might as well move to a second challenge of making it as great as possible in 16K.

Just my thoughts...
johncl
Vic 20 Amateur
Posts: 58
Joined: Sat Dec 22, 2007 3:17 am

Re: Vic20 5k memory

Post by johncl »

Well, anything is possible with endless amounts of memory. This discussion comes up very often, and personally I feel a large portion of my own motivation comes from limited hardware resources, and not to create another Bards Tale. When memory becomes abundant, it becomes much more about how much graphics you can stuff into the game and the level of skill pixelling all of it. Just look at the average console game today. My aim is really a barebones RPG, almost Rogue-like in a way and its coming together nicely. Admittedly there are a few graphical improvements I need that will require some more memory for graphics so we'll see.

And it's also a telling sign when my wife asks me when I will finish coding it (after all I have been at it every evening for a couple of weeks now), and so far I have basically filled 4k of memory. :) - Compressed thats now 3114 carefully crafted bytes over several evenings of coding, haha. You have to be a geek to understand the motivation and feeling of achievement for these kind of projects. :)

I will likely end up requiring 3kb expansion for this one, but perhaps I can do a followup game that is built on the same engine but greatly improved for 16kb memory configuration or something, although I know it will likely take some time to do that unless I just fill it up with a large map, lots of monsters and lots of graphics. :) - I mean just a decent full screen bitmap eats quite a bit of memory (actually more than the full game binary does at this point).
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Vic20 5k memory

Post by Mike »

johncl wrote:And it's also a telling sign when my wife asks me when I will finish coding it [...]
As long as it doesn't take 10+ years like the still unfinished port of Gauntlet by exitof99, also for the unexpanded VIC-20... :lol:
Post Reply