WIP VIC32 - 32-column 'pet loader' style program

[Mike]

32col.prg needs to be loaded as a program with ',8,1' at the end or it won't load into the correct memory location. Then sys 40960 to start..

Alternatively you might combine this with a BASIC stub ("2021 SYS xxxx") that loads to the BASIC start at $1201 with ",8" and which already implies there is RAM at $2000. The copy routine could first check the presence of RAM at $A000 (and bail out with "sorry", if there is no RAM), copy the 32-column routine to BLK5, and then start the routine. This would be somewhat more user friendly.

Finally, if you could provide a "warm start" entry (say, at base+3) that only re-initialises the screen editor to its 32 columns but does not reconfigure the BASIC RAM limits and reset to the start-up prompt, that would be very nice: MINIMON for example runs happily in the 32 column display but imposes its own idea of what has to be in the BRK and NMI vectors. A STOP/RESTORE will thus revert to 22 columns, with a "@@@@@@" prompt. The VIC chip cannot access the screen 'RAM' in high memory, but the normal screen editor still can. A warm start entry, entered blind, could help reviving the 32 column display in such cases.

Greetings,

Michael

[Victragic]

Alternatively you might combine this with a BASIC stub ("2021 SYS xxxx") that loads to the BASIC start at $1201 with ",8" and which already implies there is RAM at $2000. The copy routine could first check the presence of RAM at $A000 (and bail out with "sorry", if there is no RAM), copy the 32-column routine to BLK5, and then start the routine. This would be somewhat more user friendly.

Greetings,

Michael

Bingo! I like that, surprised I hadn't thought of it. Thank you.

Warm start option, originally I didn't think it would be useful, as by necessity we are moving the start of memory rendering most programs useless. I had forgotten about the array of other utilities out there that might work with it. Will have a look at that, but I have a feeling 'compatibility' may turn into a Pandora's box..

I have a few things on my list for this project now, will keep updating as I make progress.

[mingle]

That would be great, as being part-time WinVICE user (or perhaps, just a total cabbage-head), getting a .prg to loads as a disk file has me stumped.

Cheers,

Mike.

[Victragic]

That would be great, as being part-time WinVICE user (or perhaps, just a total cabbage-head), getting a .prg to loads as a disk file has me stumped.

Cheers,

Mike.

Yeah, sorry I'm not exactly a VICE power user myself. I usually just associate my .prg files with the Vic executable in Vice (in my old version, xvic.exe). Then if I click on the file, it will attempt to autoload into the Vic (and treat whatever folder you have the file in as a disk..). All you'd have to do then is type SYS40960 -- You'd have to ensure you had saved settings in Vice first with RAM at $2000 and $a000.

Don't know if this helps, a friendlier version is forthcoming though

[Victragic]

New version uploaded with .d64 as per Mike and Mingle's suggestion.

Just load and RUN..

I've managed to successfully test this with Programmer's Aid cartridge at $7000, and Vicmon at $6000 - but not at the same time.
(I can't seem get them to work together with just a normal Vic configuration, so I'm not sure that's something I can fix here.)

Rewriting the scroll routine is still on my wish list for this.

[Mike]

Thank you for this.

This updated version does not address my other suggestion regarding a warmstart capability though. It shouldn't be that hard to implement either - just a clear distinction/sequence of: memory (re-)allocation (for the bitmap), set-up of the new editor and calling the start-up banner would be needed. The editor warmstart then only comprises the second of the three parts (set-up) and this foremostly gives the user the option to restart the editor with an "emergency" SYS, without clearing the current BASIC program in memory.

[...] Vicmon [...]

There's some other issue with VICMON which will prevent fully successful operation of it with your 32 column editor, regardless where VICMON is located: its bi-directional scrolling routine for D and M dumps does direct screen accesses and is hard-coded for a screen at $1E00 (which already causes trouble, if VICMON is used alongside a +8K or bigger RAM expansion. See here).

That being said, it's no big problem to get Programmer's Aid and VICMON (and Super Expander and IEEE-488, for that matter) run together: just combine the ROM dumps for one BLK into one. That's what I did for my "Super VIC" package: (link).

[Victragic]

This updated version does not address my other suggestion regarding a warmstart capability though. It shouldn't be that hard to implement either - just a clear distinction/sequence of: memory (re-)allocation (for the bitmap), set-up of the new editor and calling the start-up banner would be needed. The editor warmstart then only comprises the second of the three parts (set-up) and this foremostly gives the user the option to restart the editor with an "emergency" SYS, without clearing the current BASIC program in memory.

Ah, I think the penny has dropped. In fact, the Vicmon scrolling bug (or 'limitation') highlights perfectly the need to reset the screen (and other locations) in the event $1000-$1fff is inadvertently written over. At the moment, it has no way to recover.

My thinking is to build this into the NMI handler/BRK routine, creating this as a subroutine that the user could also call. An easy to remember indirect jump would help. Say a 'full reset' at $a000, and a 'restore' at $a003. (Pretty sure I'm just paraphrasing what you already suggested, sometimes I have to see the catastrophic failure before I see the problem!)

[mingle]

Fantastic! Looks great... It is almost like a VZ-200 (my 1st computer too!), but with LOWER-CASE as well and better colour-modes and better sound, etc. etc!

What would be the maximum theoretical (text) screen size you could manage on a Vic?

Cheers,

Mike.

[Victragic]

What would be the maximum theoretical (text) screen size you could manage on a Vic?

Cheers,

Mike.

Hi Mike,

short answer is it depends what you are able/ willing to sacrifice.. I once had a project called 'Sentoria' that could display up to 56 character glyphs per line on a Pal screen, but it was slow and didn't allow complete freedom over the screen as it recycled characters.

For six points wide, the only 'sensible' way to get more rows (and without some open heart surgery on your Vic to add more internal RAM, which requires more courage than I possess) would be to reduce the number of lines per character. 6x8 would give a 32x20 display, halfway between the VZ and the Sinclair machines.. but doesn't look as nice in my opinion. This project was all about readability.

In total, this uses 12k to gain 6 screen locations. Is that some kind of record for inefficiency?

[mingle]

Would a 20-line screen affect readability?

Isn't it just 'extending' the vertical screen-height by 4 more rows? (and obviously using-up more RAM)

I remember, back in the day, POKEing around in BASIC to get the VIC screen as big as possible. It was a bit like good-old Amiga overscan and I often wondered why not many games took advantage of it...

Maybe it's not as simple as that - I apologise, my programming Ability never went much beyond typing in magazine-listings!

Cheers,

Mike.

[Victragic]

Would a 20-line screen affect readability?

Isn't it just 'extending' the vertical screen-height by 4 more rows? (and obviously using-up more RAM)

I remember, back in the day, POKEing around in BASIC to get the VIC screen as big as possible. It was a bit like good-old Amiga overscan and I often wondered why not many games took advantage of it...

Maybe it's not as simple as that - I apologise, my programming Ability never went much beyond typing in magazine-listings!

Cheers,

Mike.

Others may be able to explain it better, but the Vic chip can only read the 5k internal RAM, and not add-on memory through the cartridge port, as the required lines back to the Vic chip physically just aren't there. The first 1K of internal memory is not really suitable as it is used by BASIC, the stack for the 6502 and other 'hard-coded' vectors.

So as it stands, nearly all the 4k memory is already used - 240 bytes for the screen, and 3840 bytes for the character definition. That leaves 16 bytes.

To add four more lines (assuming 6x8 characters) would require 24*32=768 more bytes for character definition, plus 48 more bytes for screen, plus an IRQ raster split to display it all on the screen at the same time. You'd have to flip memory out, or write code to bypass the stack and the vectors from $0314 on, and that would be ugly.

I'm not saying it's impossible, but it would chew up quite a lot more processing power than I am prepared to give it

[Mike]

Mike,

any request to increase the number of rows has to honour the available size of the display bitmap. With 160 pixels height, you can have either 16 rows with 10 pixels each or 20 rows with 8 pixels each, and it's the former design Victragic wanted to use.

You can't have 20 rows with 10 pixels each that easily: the display bitmap needs to fit into the internal RAM of the VIC-20 because only the internal RAM (and the character ROM) can be accessed by VIC-I for display data! If we keep the lower 1 KB at $0000..$03FF out of this - we have a screen editor and running BASIC here, so it's no good idea to thrash the OS workspace -, only the 4 KB from $1000..$1FFF are available for our purpose.

The graphics are displayed by redefined characters. Double-height characters are used so one 'normal' character accesses 16 bytes of character definition. In all, you need 16+1=17 bytes to display a small 8x16 pixel 'tile' of the whole bitmap. Now, 4096/17 ~= 240.9 - we can't display partial characters, but 24x10 characters can be nicely arranged in a grid to give a display of 192x160 pixels, and that's exactly what Victragic uses. There's no room for adding another 4 text rows of 10 pixels each and keeping 32 characters per line!

There are techniques to expand upon the number of displayable pixels, as freely definable bitmap(!) - they have been demonstrated by tokra and me several years ago. However, they all come at the expense of sacrificing OS interoperability (they use either the lower 1 KB or interrupts or both, and soak up CPU power to provide VIC-I on the fly with data transferred from external memory) up to the point that you can have either that display shown or have your own program running, but not both. Those graphics modes thus are out of question for being used for the application at hand here.

Greetings,

Michael

[Victragic]

I've made a few updates, as indicated in the initial post for this thread.

The project is fairly close to completion now - save for the endless tinkering to try to gain efficiency. Source code is in no way presentable, so I'll tidy it up in case anyone wants to tinker further. (This may take some time, as I am extremely sparse with commentary in my source code at the best of times).

There are a few programs I want to convert to 32 columns, and I have some ideas for some new fonts.. I think I will just add these to the disk image over time.

[tokra]

I noticed some *very* strange behaviour with this. I load and start VIC32 by mounting the D64 as usual. Then as first command I type LOAD"$",8 followed by LIST. Then the second directory entry is not displayed fully, however if I list again it works. Sometimes it displays the V of the second filename, other times not. Any idea what might cause this?

[Mike]

Any idea what might cause this?

I can reproduce this error also on my setup. That seems to be a race condition, where the screen update is 'caught' during a scroll and when the new line has been opened but not yet been written fully.

The algorithm takes the original screen data of the editor and compares it with a shadow copy; where the shadow copy differs, the character position in the graphics bitmap is updated and the shadow copy also assumes the new value.

The original screen data is still 'there' and can be recovered (i.e. made visible again) by hovering over the blank positions with the cursor.