Get the first program to automatically load the next part

[Mayhem]

I know it must be here on Denial somewhere, but I can't find it. How can you set up so that a command in the first BASIC program then automatically loads the second part on tape/disk?

[Mike]

It's here:

http://sleepingelephant.com/ipw-web/bul ... 82&start=9

Greetings,

Michael

[Mayhem]

Cheers

However it's not working for the program in question I want to apply it to, so may need some closer examination.

[pallas]

I've seen tape programs auto-running themselves, I suppose they fiddle with the start address or something.

[johncl]

Actually wouldnt mind having a ML routine that can load an optional 3kb of data whenever there is a 3kb expansion in the Vic20. Obviously the data should be loaded into 0400-0FFF, but I guess if I call ROM routines to do the loading its automatically placed based on address on the two first bytes of the file?).

[Mike]

[...] the data should be loaded into 0400-0FFF, but I guess if I call ROM routines to do the loading its automatically placed based on address on the two first bytes of the file?

You can very much load a program file to another address range than that it was saved from, with KERNAL calls.

It's just a matter of supplying the routines of the KERNAL with the correct parameters (link).

[johncl]

Great, I was able to load a file into memory easily with the LOAD KERNAL call (after setting up those two others).

But I also realized I had misunderstood that when a 3kb cartridge is plugged in the program is loaded into $0400 and onwards, haha talk about silly mistake. So my optional load cannot really work unless I make short basic routine that first loads main part into $1000-$1dff, start that and detect 3kb and load the optional at $0400-$0fff. I guess I can detect this by actually checking $0400 for bytes from the initial basic program (or is there an easier way?).

Is it very common for Vic20 games back in the 80s to only support one memory setup? It surely seems like that would be the case. So if a game supported optional memory it would have two versions on the tape or something due to the odd location at load stuff?

I also see that the 8kb expansion is in a completely different place and programs are then supposed to reside in a different position ($1200) as well as screen relocation (I knew about this, but was unaware of the starting address moving as well).

[Mike]

Is it very common for Vic20 games back in the 80s to only support one memory setup? It surely seems like that would be the case. So if a game supported optional memory it would have two versions on the tape or something due to the odd location at load stuff?

Very much this, yes. In most cases, the memory requirements were printed on the box.

I also see that the 8kb expansion is in a completely different place and programs are then supposed to reside in a different position ($1200) as well as screen relocation (I knew about this, but was unaware of the starting address moving as well).

That had been a constant source of confusion, indeed. Especially because putting *more* RAM into the VIC-20 just didn't simply extend the set of runnable programs. Rather, many programs written for unexpanded memory just would refuse to work if an 8K or bigger RAM expansion was installed.

The main hardware reason for this is to provide the maximum contiguous memory range. The screen normally is located at $1E00, with a +3K RAM expansion the BASIC start is lowered to $0400. As soon as +8K or more are installed, the screen is moved to the bottom of internal RAM, so BASIC programs start at $1200 and can extend all the way to the top. When +3K RAM and a bigger RAM expansion are used simultaneously, it is not possible to put the screen at $0400 - rather the screen still ends up at $1000, blocking the +3K RAM from BASIC use.

(Aside: it is possible though to provide +3K as internal RAM expansion and get 31231 BYTES FREE - besides other things ... see here. )

...

In principle, you had to know the exact amount of (extra) RAM which was necessary to run the program. Two exceptions to this rule:

• Most BASIC programs written for the unexpanded VIC-20 (even those using user defined graphics) could successfully be run with a +3K RAM expander (not that this would buy you much, though), and
• Nearly all programs written for +8K RAM would also run with +16K and +24K (and +16K ones would also run with +24K).

There's also the possibility to install RAM in BLK5. As this RAM is not contiguous with the other RAM, it doesn't have any influence to the position of screen and colour memory, and also isn't added to the display of available RAM.

One can restrict the amount of RAM available for BASIC though and also relocate (read: "force") the screen base to the address the program requires, as long as RAM is there for the new range. That for example means, one can always "simulate" an unexpanded VIC-20 even though RAM is expanded. I already pointed you to my type-in game collection. Here, the first program on disk ("BOOT") first unexpands the VIC-20, regardless what extra RAM is present, and then it chains to title screen and menu.

[johncl]

Sounds to me they were rushing the architecture of the Vic20 in many areas.

Still, I guess I should be able to do a small boot loader thing first that puts the main part always into "unexpanded" area and then the program itself loads some stuff into $0400 if 3k is present. I can also make this work fine on 8kb too giving the game extra bells and whistles like a custom charset ingame too (the optional bits are then ofc loaded at $2000 and on instead). Hmm I see now that the charset must reside at one of these: $1000, $1400, $1800, $1c00. Is that correct? Even when memory is added? I guess screen memory can be set to point anywhere right or is that also limited to the built in RAM?

[Mike]

Hmm I see now that the charset must reside at one of these: $1000, $1400, $1800, $1c00. Is that correct?

In principle, yes. $0000 also works.

Even when memory is added?

Yes.

I guess screen memory can be set to point anywhere right or is that also limited to the built in RAM?

The latter, yes.

Do you now understand that there's near to nothing gained on the VIC-20 regarding graphics capabilities when RAM is added?

When you pull a lot of rabbits out of the hat, you can use the CPU to shuffle bitmap data from expansion memory to the internal RAM, synchroneous to the raster beam to increase the pixel resolution or colour resolution, but that goes at the expense of the CPU time available for the main program - up to the point that those techniques are only suitable for displaying still images.

I already gave you quite a few links in other threads for further information. You'd have a better understanding, when you'd actually read those threads and try out the programs.

[johncl]

I am sorry if I have offended your intelligence or something. I am new to the Vic20 architecture, and I have read a bit here and there, figuring out things as I go when developing this game. I also did run each and every one of those type-ins you linked to check out the capabilities although I did not have the time to list them and read the code. I see through this chat that I over-estimated the capabilities of the Vic20 and will naturally try to work around them as best as I can for the game. I think I have figured out a way to at least support an optional 3kb expansion although it will be a while until I really need that - more than enough challenges getting the game going first.

[Mike]

I mainly resorted to these clear words, because I was under the impression that you really didn't follow my hints given, and also seemed to take things for granted on the VIC-20 which really aren't. But O.K. then - let's cool down a bit.

I also did run each and every one of those type-ins you linked to check out the capabilities although I did not have the time to list them and read the code.

Maybe you should take the time for this, reading the code of at least some of the programs. Most of them are in BASIC, so no big issues here.

I see through this chat that I over-estimated the capabilities of the Vic20 and will naturally try to work around them as best as I can for the game.

Those games in my collection are more representive to what was being done in the 80ies with the VIC-20, and in BASIC. I put them together on disk mostly for nostalgic reasons. Today, the programmers know a little more about the VIC-20.

Hardware-wise, compared to C64's VIC-II, the VIC "only" features a (multicolour) text mode - bitmapped graphics are done by 'painting' the text screen with unique chars, you have no sprites (but can 'bitmap' small parts of the text screen for pixel-wise shifted software shapes), there's no extra sound chip (the VIC provides 3 square wave and 1 noise generator), the memory arrangement is fixed (there's no PLA), etc.

It just happens that the hardware of VIC-20 and C64 is similar enough that both can run nearly identical implementations of CBM BASIC (and use the same peripherals on the IEC bus - just the 1540 makes some trouble with the C64).

With some effort, you can get some surprising results from the VIC-20, though. It is possible to do a 104x256 resolution with 8x1 pixel colour attributes (like FLI - Flexible Line Interpretation - on the C64) and global colour registers (background, border - a colour source in multicolour! -, and auxiliary colour) being changed on every raster - with an unmodded VIC-20, just an external RAM expansion is necessary! OTOH, if you can compromise on colour resolution, it is even possible to show a fully bitmapped display of 224x280 pixels.

It is also possible to emulate the SID chip on the VIC-20 to a good degree.

I think I have figured out a way to at least support an optional 3kb expansion although it will be a while until I really need that - more than enough challenges getting the game going first.

The easiest way probably would be just to provide two versions and a boot loader that loads the appropriate version. Still fits on one disk.

[johncl]

Well I did understand most if it but I sort of missed the part (even checking the reference manual) that say that the VIC chip only can see system memory and never the expanded memory. Perhaps its there in the books, but I missed it - although I had an inkling due to any address beyond $2000 was missing in the tables of possible positions.

I am sure the Vic20 has many nice and unique capabilities, and I am fully aware of the software-sprites thing, I will likely experiment a bit with that in a project after this RPG thing is done. Atm I am happy using petscii for it though, and if I see any way of fitting some custom chars, your tip about the charset wrapping over in ROM at the end will likely be attempted. (I guess this point should have given me the idea that the VIC chip cannot see beyond it, although at first I thought it would see beyond it if you plugged an 8kb expansion in there).

I am checking out the sound as well and its interesting to note the staggering octaves thing, and I partially find it odd that the byte ranges are in the middle, and you need to modulate to play some of the notes pure - no doubt a reason why many Vic20 games sound like sour grapes. No doubt a hardware limit due to the components chosen, but I guess some different components and they could have used the full byte range for frequency to at least avoid this modulation thing. Ofc I see you can do arpeggios and all that stuff. Have looked some into interrupts (which incidentally lie at $0314, $0315 - same as the C64 when the Kernal is on). But from what I understand it doesnt have a raster trigger like the C64 but have to use a timer, I guess it should be good enough for a music routine which doesnt really have to happen on any particular raster line. Need to look some more into this.

Is there a similar resource like codebase.org for the Vic20?

[Mike]

I am checking out the sound as well and its interesting to note the staggering octaves thing, and I partially find it odd that the byte ranges are in the middle, and you need to modulate to play some of the notes pure - no doubt a reason why many Vic20 games sound like sour grapes.

Possibly those people making the tunes took the table of notes in the PRM like god-given, and not to be changed or disputable. You can recalculate the values from the equal-tempered scale and the formula for frequencies though, making a compromise for PAL (one quarter-tone too high) and NTSC (one quarter-tone too low), and then arrive at this table:

Code: Select all

C     255    191    223
C#    134    195    225
D     141    198    226
D#    147    201    228
E     153    204    230
F     159    207    231
F#    164    210    232
G     170    212    234
G#    174    215    235
A     179    217    236
A#    183    219    237
H     187    221    238
C     191    223    239

The 255 in the top left is no oversight. The upper two thirds of the third octave still sound heavily detuned, though.

It's only using the values 128..255, as bit 7 acts as 'gate on' bit. If it weren't for the fact, that fast toggling of that bit can be used to produce non-square wave forms, it would appear as unnecessary restriction of the available range (say, 0 as silent, and 1..255 as frequency setting would be much better).

Is there a similar resource like codebase.org for the Vic20?

A valid point.

Denial has a somewhat small collection of code snippets placed in the sticky thread 'ROM calls and other tricks', but it's nowhere near being a comprehensive resource.

Examples from codebase.org of course translate very well to the VIC-20, as long as no chip register I/O is involved - like program structure templates, math routines, etc. 6502.org is a good resource. When it comes to interworking with BASIC and KERNAL, I often reference to AAY64 and then check against the VIC-20 ROM - the equivalent routines are just offset by a few bytes for the most time. VIC and the VIAs are simple enough you can mostly 'go by the book' - many of the recent discoverings were not really found as strange side effects but rather were 'constructed'.

Of course, when you come up here with a code snippet you deem non-optimal, and that snippet is placed within a small example application, there are good chances that two or three Denial fellows will throw themselves at it and optimize the hell out of it.

Cheers,

Michael

[johncl]

Thanks, the Reference Manual actually mentions modulation is needed to get pure tones - no doubt, many just ditched that and went with a simple lookup table yes. Will be interesting to play with the sound chip as well some day, looking forward to that.

As for code yes that "ROM calls and other tricks" thread is a nice one I have read a bit. Sad its only 2 pages even though it started in 2005. - And yes no doubt a lot of the pure assembly stuff goes for both C64 and Vic20 (it even has a bit about stable rasters for the Vic20). I noticed that while I know its easy to code a lot myself, perhaps its wise to do a mix ROM calls where speed isnt necessary so important. So I was actually looking for a good summary when to use decent ROM functions instead.

An example of this was a random number generator, where I have previously used a simple code snippet from codebase65 which ofc works for the Vic20. But the RND function at $e094 might work as well even though its slower as it generates a full set of random bytes ($61-$66). But when I then tested the randomness of those numbers by plotting them onto the screen, I noticed several weren't very random at all - and even had gaps, certain numbers never rolled in certain positions. After some testing I found $63 and $64 to at least cover all 256 byte values. Stuff like this is nice to get info about as no doubt its a frequent problem. Perhaps there is a better way too, although one jsr is nice to get some pseudo-random numbers to work with. The fact that its seed based too should mean its possible to recreate certain sets of numbers which is nice if one want to recreate certain "levels" or setups identical based on this seed (and indeed of essence to games like Sentinel or Elite on the C64).

Another one I saw immediately was "jsr $e55f" to clear the screen, but I noticed it didn't touch the color memory (tried $e912 for setting color code) or there is something I have not figured out yet. There might be some print routines I could benefit from although I often code my own to save bytes and add screen skip features to it. Also its nice to have those things going fast even if its just text I output.