Denial

Hi, Folks. I'm working on a little game that sits in the 3K RAM expansion space ("Block 0") to start getting back into the VIC-20 and 6502 programming, and I'm having a terrible time with integrating a MG-format splash screen for the initial display. I can verify that the initial loading program (attached as ZIP) only occupies 2,769 bytes, so is below the $1000 threshold. The loader works, to a point (see pictures, last one from Minipaint - how it's supposed to look), but obviously something has gone wrong in getting the MG image to the screen memory. The only "clever" (haha!) thing I'm doing with the screen is moving the vertical position up so I can have a scrolling up effect of the picture as the theme music plays. The color data position is spot on where it should be. In addition, when the music has finished, the screen does not clear and the custom characters for my BASIC pseudo-sprites are being written into screen memory. OOF!

The program works perfectly for my PETSCII graphics set up in the original version, but I wanted something a little more fancy, as well as learning Minipaint. I think I'm missing something with memory protection, as well as data block transfer. It's been four days on just this splash screen issue, and I'm stumped. Any ideas or thoughts? Thanks, Dave/Fishhack

Hi, Dave,

first of all, welcome to Denial!

I see you tried to adapt my View3K program for the use with a +3K RAM expansion. View3K had been written with the tight space available on a unexpanded VIC-20 in mind, consequently it goes through quite some hoops, which are not necessary with extra RAM (even if 'just' +3K). Especially its placement in the stack area ($01xx) makes it somewhat unfit for any application beyond just viewing MG pictures, as it can easily be overwritten there.

A more robust version of a MG displayer for +3K RAM expansions would still load the MG file to $1001, but then use own routines to: write the colour RAM, move the bitmap up in memory, set up the text RAM and then write the VIC registers. That can be done in machine code or - even if somewhat slower - in BASIC:

• $1001..$100F: BASIC stub ($100E: upper 4 bits of $900E, $100F: $900F contents)
• $1010..$1F0F: bitmap (move to $1100 after the compressed colour RAM has been expanded)
• $1F10..$1F87: compressed colour RAM
• $1F88..$1FFF: display routine (not used here)

(aside: with only +3K RAM, we can't afford to load the file to its original, intended position, at $10F1, which would otherwise save us the copying step on the bitmap. The tail of the file, i.e. the compressed colour RAM (and the display routine) extends beyond $1FFF and thus would be loaded to non-existent memory.)

...

Please note the POKE to address 52 is cargo cult (more details here). You should instead POKE the whole pointer in 55/56 and do CLR afterwards. The pointer in 51/52 is then automatically set by the BASIC interpreter to follow suit. To protect the whole area of $1000..$1FFF, you use POKE55,0:POKE56,16:CLR as first commands of the loader.

fishback66 wrote:In addition, when the music has finished, the screen does not clear and the custom characters for my BASIC pseudo-sprites are being written into screen memory. OOF!

No wonders. You have to return to text mode first by re-initialising the VIC registers - SYS58648 easily does the job -, and then POKE36869,255 to activate the changed character set.

You should raise the memory limit to 7168 (this still keeps the redefined character set protected) before loading the main program, with POKE55,0:POKE56,28:CLR - otherwise you'll be left with just 3 KB for the main program.

Greetings,

Michael


P.S. with +8K RAM or more, MINIGRAFIK could take care of all that, by virtue of its @LOAD command. The handling of user defined graphics in conjunction with a bigger RAM expansion has been discussed in Denial quite recently - in essence, you have the UDGs still at $1E00 and use POKE36869,207 to activate the UDGs yet still keep the text screen at $1000. You'd also forgo all those POKEs to 55/56 as the memory for the UDGs already has been protected by MINIGRAFIK.

Hi, Micheal.

WOW - a lot to think about, explore, and learn. Thanks for the info, clues, and such wonderful tools to make graphics, all of which should keep me occupied for the weekend (as long as "my other half" says I can! ) The @LOAD of MG would, indeed, be perfect in +8K, but one of the challenges I set for myself is to hold the game solely in the 6.5K space, so...

As an aside, I wonder why more things weren't written with the 6.5K RAM configuration... maybe it's likely no one bought the 3K RAM expansion cart (?) Will send an update after a few days of tinkering. Cheers!

fishhack66 wrote:[...] I set for myself is to hold the game solely in the 6.5K space, [...]

Fair enough.

[...] I wonder why more things weren't written with the 6.5K RAM configuration ... maybe it's likely no one bought the 3K RAM expansion cart(?)

The +3K RAM expansion for sure had its share of buyers and users, but that little extra RAM probably soon was seen as stopgap compared to the offerings of the +8K or +16K RAM expansions. Nonetheless, having screen and colour RAM still at the same place and having the VIC registers work the same way for user defined characters as with an unexpanded VIC-20 had (and still has) its own charme.

Will send an update after a few days of tinkering.

<fx="thumbs up!"></fx>

fishhack66 wrote: ↑Sat Aug 31, 2024 9:50 am As an aside, I wonder why more things weren't written with the 6.5K RAM configuration... maybe it's likely no one bought the 3K RAM expansion cart (?) Will send an update after a few days of tinkering. Cheers!

Welcome!

In a parallel universe where the cost of RAM was perhaps a little cheaper at the time, I wonder what the Vic 20 software library would have looked like if the Vic 20 had come with that extra 3k of RAM out of the box. That said, we might not have see some of the inventive unexpanded games as a result.

Good luck on your project.

After four days of "tinkering," I am no farther along than where I was last week. Sometimes the color map is right, sometimes the bitmap, but never both at the same time. This is with images generated from both minipaint and multipaint, and tested on my real VIC-20 and four different versions of VICE. Despite the instructions in the manuals, I'm at a dead end. At least for me (only a hobbyist), getting this to work in a 6.5K configuration is not going to happen, currently. The best part of the journey, so far, has been discovering the book "Mapping the VIC": why didn't I have this book 40 years ago??? OK ... onward!

fishhack66 wrote:I am no farther along than where I was last week. Sometimes the color map is right, sometimes the bitmap, but never both at the same time.

If you proceed by first loading the original picture file to $1001 - as I laid out in my preceding post - you need to: write the colour RAM from the data located in the range $1F10..$1F87, then copying the bitmap from the range $1010..$1F0F to the range $1100..$1FFF, and finally, prepare the text screen at $1000..$10EF with the characters $10..$FF in column-major arrangement - in exactly that sequence.

Any deviation from that sequence will lead to either parts of the bitmap being overwritten, or the compressed colour data being thrashed before it is expanded into colour RAM. The initialisation of most VIC registers can happen at any time; however the values for $900E and $900F - placed at $100E and $100F - will be overwritten when you put the text map into place, which means you want to set those VIC registers before writing the text map.

This is no peculiarity of the MG picture format; when you move data around in restricted memory space you need to proceed in Sokoban-like fashion so you do not accidently overwrite things while doing so.

This is with images generated from both minipaint and multipaint, [...]

Please note MINIPAINT is not related in any way to Multipaint.

The only currently supported native VIC-20 graphics format of Multipaint originated from another paint program, Aleksi Eeben's "Picasso". Besides having a slightly different resolution (88 x 176, multicolour only), it is necessary to overwrite large parts of OS workspace to display these picture files, which makes them particularly unfit for your purpose. You find more information here.

[...] and tested on my real VIC-20 and four different versions of VICE.

The actual version of VICE is largely irrelevant here. It is only an issue of doing things in the right sequence, given the restricted memory space.

Despite the instructions in the manuals, I'm at a dead end.

The manual of MINIPAINT gives very exact information on the memory layout while a MG picture is on display (in Appendix C), and how the picture file format is defined (in Appendix D). I am at no obligation to supply support code for each and any conceivable application of these files ...

At least for me (only a hobbyist), [...]

... as - you guess what? - doing things on the VIC-20 also only is a spare-time activity for me, indeed.

Just to put things into perspective: I certainly put more hours into MINIPAINT and its eco-system than you thus far spent trying to use the picture as splash screen. Your application, using a MG picture as splash screen with a +3K RAM expansion, can certainly be implemented. If anything, see this assertion as challenge to actually get it implemented - on your own.

...

On that part:

The best part of the journey, so far, has been discovering the book "Mapping the VIC": why didn't I have this book 40 years ago??? OK ... onward!

These books count as tertiary sources at best, and also have their known shares of errors and omissions. The body of knowledge in programming, of the VIC-20 in particular, has advanced well beyond their covered content in the last decades.

Hi Folks. I finally finished Borg Attack! for VIC-20 with 3K RAM expansion. It's essentially a search-the-grid-for-the-target game, but in this case the "target" is an erratically moving, cloaked Borg cube with three levels of play, and It's my homage to the old "type-in" games we got out of the home computer magazines in the early/mid '80s.

99% BASIC, with the exception of a joystick read routine. Scrolling title screen, lots of 'beeps and boops," etc. My good friend from YouTube, Masterhit1, did all of the art for the box design and the little manual booklet; these are in PDF form, not actual boxes and paper, etc. In the archive is a .D64, documentation, and I included TAP files for what would have been the two sides of a cassette (joystick and keyboard versions of the game) in case anyone wants to *really* relive the early '80s.

One little word of warning, though. During a turn, the screen will flash rapidly at one point for about 2 seconds. If flashing screens are an issue for you, it's easy enough to disable it before playing. Just strip off the last poke of line 410 of files BK and BJ on the disk image before playing.
i.e.; 410 fori=1to15:pokev1,i:pokes1,128+i*8:poken1,128+i*8:poke36879,249-i*16 <-- ditch the bold code.

Please let me know if you find any bugs. Enjoy!

I was watching your video on this earlier, like it a lot.

Thanks, Andy. It was a lot of fun to make, and I learned a few things in the process, so win-win!