Maxi-/Uber-Edit

Basic and Machine Language

Moderator: Moderators

sjgray
Vic 20 Hobbyist
Posts: 115
Joined: Thu May 03, 2007 6:46 pm
Location: Markham, ON, Canada

Re: Maxi-/Uber-Edit

Post by sjgray »

Mike wrote:Steve,
In short: this tool is great as wedge, not so as KERNAL patch. A program that uses this tool needs to be fully aware of it anyway. In principle, it gains its merits just like any of the known BASIC extensions - you invest some memory into the wedge to simplify some other aspects in your own code.
As you pointed out, you really are talking of a few programs that would benefit from this, so it really doesn't matter what you break. Luckily BASIC programs will relocate automatically, so that doesn't matter. I think the main benefit of such a program would be simply to have a larger screen to make listing/editing nicer. So, with a kernal switcher you would select this, do your editing etc, save and switch back to normal kernal. If it became a "standard" then perhaps people would develop some specialized software for it. Hard to say. In any case, it's an interesting concept.

Steve
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Maxi-/Uber-Edit

Post by Mike »

sjgray wrote:[...] you really are talking of a few programs that would benefit from this, [...]
Programs will need to be specially *crafted* for the extended screen, they won't benefit by a happy coincidence.
so it really doesn't matter what you break.
That would be just most other, unaware programs.
I think the main benefit of such a program would be simply to have a larger screen to make listing/editing nicer. So, with a kernal switcher you would select this, do your editing etc, save and switch back to normal kernal.
You make use of a strong premise, namely that people still use the VIC-20 to actually write and edit programs on it. ;)
If it became a "standard" then perhaps people would develop some specialized software for it. Hard to say. In any case, it's an interesting concept.
For me, that is the intended main use of the tool; as wedge, not as KERNAL replacement.

As I wrote in the edit of my preceding post, incorporating this tool into the KERNAL would make its use only easier for the programmer, not for the user. Without the patched screen editor, the client application doesn't work. Loading a wedge into RAM is far easier to do (and much more acceptable for most people) than requiring a hardware change by exchanging the KERNAL ROM.
User avatar
pixel
Vic 20 Scientist
Posts: 1330
Joined: Fri Feb 28, 2014 3:56 am
Website: http://hugbox.org/
Location: Berlin, Germany
Occupation: Pan–galactic shaman

Re: Maxi-/Uber-Edit

Post by pixel »

Oh, dude! What a relief! Same first thought like Boray: .oO( 30 years too late). ;)

BTW: Am using NTSC for a PAL telly and that's already clipping the corners.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Maxi-/Uber-Edit

Post by Mike »

pixel wrote:BTW: Am using NTSC for a PAL telly and that's already clipping the corners.
That's because the default register values for the horizontal and vertical position are already different for PAL and NTSC. If you program PAL values into an NTSC VIC, the display window is out of center, likewise the other way round. This is of course more severe for overscan display windows.

In principle, the values for these two registers could be derived as (signed) offsets from the default values in the KERNAL ROM. This is for example how MINIGRAFIK (re-)centers the display for its underlying 20x12 (double-height chars) text mode. Obviously tokra didn't do this for Maxi-Edit. ;)

Actually, the 24x26 mode would be quite useful as least common denominator for both TV systems. :)
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: Maxi-/Uber-Edit

Post by tokra »

Following a suggestion by Mike, I amended the source-code, so that is is possible to compile to whatever geometry you like:

Download source

This works with CBM prg Studio. However in Tools-Option-Assembler you need to set the "Operator Precedence (Hi/Lo byte operations) to "Calc address first, then hi/lo byte".

At the start of the source-code you can set if you want to compile for PAL or NTSC. The image is centered accordingly upon compile automatically.

Then you can set the columns and rows. BASIC-line-length is also adjusted automatically, but can be a maximum of 88 characters. So, if for example you choose a mode with just 17 columns, your BASIC-line may use 5 physical line (5*17 =85).

After that you can change the load-address and compile away.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: Maxi-/Uber-Edit

Post by tokra »

I've found a small bug that would strangely only show on real VIC-20. If you pressed STOP/RESTORE the VIC-20 would sometimes crash and sometimes go back to normal display mode. I've cleared up the vector-setup-routine and this seems to fix it. I've updated the files on my webpage to the most recent version (see first post). I also amended the post on how to include MAXIEDIT in your own programs, since the SYS-calls need to go to different addresses now because of the changes.

So please re-download if you are using this.
User avatar
Victragic
Frogger '07
Posts: 605
Joined: Tue Nov 14, 2006 5:56 pm
Location: South Australia

Re: Maxi-/Uber-Edit

Post by Victragic »

This is excellent work, Tokra. (Apologies for basically doing the same thing 3 years later, I should have searched more thoroughly first!)

I can only think the reason this wasn't done back in 'the day' was the fact it is quite an expensive solution in regards to memory, when memory was at an absolute premium. Plus the only 'sensible' screen sizes out there were 32 column, 40 column and 80 column, so the efforts were put into 40 column adaptions to align with other Commodore machines.

Still, it becomes obvious when you look at the source code Commodore could easily have done this out of the box without very much modification!
3^4 is 81.0000001
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Maxi-/Uber-Edit

Post by Mike »

Victragic wrote:I can only think the reason this wasn't done back in 'the day' was the fact it is quite an expensive solution in regards to memory, [...]
This is mainly the result when vital constants (number of columns and rows) are hardwired in the code. At least the number of columns could easily have been made flexible at nearly no cost by reading it from a zeropage byte instead of supplying it as immediate operand. Main issue (and what I've seen you also had to address with an 'out-sourced' buffer at $0B00) is keeping track of the line links, which requires a buffer growing with the number of rows.

Of course the bigger screen then also needs more memory, but that goes without saying. NTSC won't allow for much more than 22 columns anyway, and 22x23 actually provides the most screen estate with an even(!) number of columns that just barely fit into 512 (=2^9) bytes, and this is simply what we got: a working text display/editor.

The CBM machines could use different editor ROMs with 40 or 80 column support. Even though the editor of the C128 also supported both 40 and 80 columns, with windowing, they didn't 'think it out' to the end: as an example - even though built-in TEDMON inquired the columns to switch the memory display between 8 or 16 bytes per line, it did not take the actual number of columns (as given by a window) into account, and thus would still overflow the memory display when the user specified a smaller window.

A long way to go from just a flexible screen layout to have programs that take this into account and can adapt. Tell me a single program that used JSR $FFED to read the current screen (or window?) dimensions. :wink:
User avatar
Victragic
Frogger '07
Posts: 605
Joined: Tue Nov 14, 2006 5:56 pm
Location: South Australia

Re: Maxi-/Uber-Edit

Post by Victragic »

Mike wrote: Wed Apr 29, 2020 2:42 am A long way to go from just a flexible screen layout to have programs that take this into account and can adapt. Tell me a single program that used JSR $FFED to read the current screen (or window?) dimensions. :wink:
Case in point - Pet Loader cartridge. Was there *anything* written that was compatible with it?? (I think I saw a version of the 'Lemonade' game, that's about it.)

I'm not sure programs that try to adapt to different screen sizes is sensible, apart from a few select applications (Speedscript would be nice..) and I agree that $ffed kernal routine is like an appendix - no-one knows for certain why it's there. But it is nice as a 'programmer' to choose a different screen layout at times, for various reasons. And that's what this does.
3^4 is 81.0000001
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Re: Maxi-/Uber-Edit

Post by Boray »

I just noticed, the 26x32 mode actually is 26x31.
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Maxi-/Uber-Edit

Post by Mike »

Boray wrote:I just noticed, the 26x32 mode actually is 26x31.
The mode *has* 32 rows. But of course, from the home position you can only do 31 cursor downs before the cursor ends up in the last line.

This is a classical fencepost error on your side.
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Re: Maxi-/Uber-Edit

Post by Boray »

You are right. I must have made an error when counting. Sorry, I blame it on the heat ;)
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Maxi-/Uber-Edit

Post by Mike »

No worries. If we happen to meet up someday, let's drink a beer (or any other preferred beverage) on it! :mrgreen:
Boray
Musical Smurf
Posts: 4064
Joined: Mon May 03, 2004 10:47 am

Re: Maxi-/Uber-Edit

Post by Boray »

I just had to find out what I did wrong. The picture explains it. It was because of screen wrap.
Attachments
maxi.jpg
PRG Starter - a VICE helper / Vic Software (Boray Gammon, SD2IEC music player, Vic Disk Menu, Tribbles, Mega Omega, How Many 8K etc.)
User avatar
MrSterlingBS
Vic 20 Enthusiast
Posts: 167
Joined: Tue Jan 31, 2023 2:56 am
Location: Germany,Braunschweig

Re: Maxi-/Uber-Edit

Post by MrSterlingBS »

Hello tokra,

do you have a sloution for this question from Mike?
Is it possible to move the screen to $0400?

And how can I physically imagine the extension I/O-2 RAM ($9800-$9BFF)?
How does the I/O-3 RAM ($9C00-$FBFF) expansion work? Isn't that where the Basic and Kernal are located?
See Mastering the VIC from A.J.Jones et alia on page 45.


BR
Sven

Mike wrote: Sat Jan 28, 2017 12:26 pm :mrgreen:

Any chance for a custom version with the text screen located at $0400, the screen editor code directly behind that, and the BASIC start as low as possible? :)

Cheers,

Michael
Post Reply