Maxi-/Uber-Edit

[eslapion]

Thanks! I was actually wondering why this has not been done before. Basically I only re-directed the vectors for CHROUT and CHRIN to RAM and copied all the necessary parts of the screen-editor from ROM to RAM. Then armed with a ROM-listing I just needed to change all fixed values of columns and rows to the new numbers and move the screen-line-link-table from zero-page to higher RAM.

If you have carefully studied the display routines to alter the number of rows/columns, perhaps you could take a look at the miserably sluggish routines of the Protecto-80.

Scrolling is so slow with this cart, it could use a serious improvement.

[Mike]

Putting tokra's reply to Aleksi's post first:

I was actually wondering why this has not been done before. [...]

A tool like this surely would have been a perfect candidate for the "Tips & Tricks" section of the contemporary computer magazines. Maybe an extensive search could turn up with an equivalent solution printed somewhere as listing, it just hasn't happened yet.

However for today - at least for the last 10+ years with Denial on-line - the "target audience" has been diminished somewhat: cross-developing on PCs gives a much bigger screen estate to edit the programs, and programmers who don't solely rely upon BASIC always can do direct access on the overscan screen without any speed losses or handling problems.

Great work Tokra! I was actually a bit surprised that all this could be done without hacking the ROM Of course, people have done 40-wide screen routines before, but this one is much more useful, because it's fast!

I wouldn't have expected otherwise. As tokra wrote, he threw out the entire old screen editor code, and replaced it with a re-parametrized version as wedge. Thus you get a speed equivalent to the original routines - except in cases where they truly have to manage more data, as for example when the screen is scrolled. And even there, the speed difference is marginal.

In contrast, if one goes to replicate the editor functionality with a software based 40 column screen - in a bitmap - much more data needs to be handled: the entire bitmap is affected on scrolls, and a "shadow" text screen. That can get *very* slow, if all actions on the shadow text screen only get reflected on the bitmap in character-wise fashion. Some performance improvements can be had when certain operations, like copying a character line (for scrolling), "opening" a new line (with 40 spaces) and shifting part of a line to the left/right (during insert/delete) get specialized routines that operate on the bitmap without the necessity to reflect changes of the text buffer character per character. However, there's only so much speed increase to be had as you could expect from a single character API.

That was one of the reasons I just didn't bother to include a BASIC editor functionality with the routines I wrote for MG Browse. I identified the single character API as the biggest bottleneck for a fast software 40 column scheme. Instead, only *whole* text lines are written to screen - and the inner loop always processes 2 characters at once (it's just wasteful to first write the left nibble, carefully retaining the right nibble, and then write the right nibble, carefully retaining the left nibble, right?). Likewise, I dispensed with the "graphic" PETSCII characters, and went for the ASCII code page instead (the text "lives" on a bitmap anyway, so I can add any graphic decoration to the side of the text that I want).

And these routines *are* fast - even when scripted by a BASIC program.

[tokra]

However for today - at least for the last 10+ years with Denial on-line - the "target audience" has been diminished somewhat: cross-developing on PCs gives a much bigger screen estate to edit the programs, and programmers who don't solely rely upon BASIC always can do direct access on the overscan screen without any speed losses or handling problems.

I got the idea for this specifically while creating my ColorRun-game. It was very difficult to get the PRINT-commands in that one exactly right for the overscan area this game needs to use.

With Maxi-/Uber-Edit you can easily create "fullscreen"-games using BASIC's PRINT-commands and don't have to worry about strange line-breaks.

[Boray]

Is there an easy way to automatically load and start Maxi-Edit from a basic game that uses it?

[tokra]

Is there an easy way to automatically load and start Maxi-Edit from a basic game that uses it?

Not really, since the video-memory at $1000 has to be increased to accomodate for the larger screen-area and as such the BASIC-start itself moves upward in memory.

So, you will need some kind of boot-loader to include MAXIEDIT. Let me get back to you on this...

[tokra]

Ok, here we go. Try the attached file for a bootloader for your BASIC-programs.

Code: Select all

10 d=peek(186):n$="program"
20 sys57809"maxiedit-ba00.prg",d,1:poke780,0:sys65493
30 print"{clr}load"chr$(34)n$chr$(34)","d
40 poke44,19:poke43,65:poke4928,0
50 poke631,19:poke632,131:poke198,2:new

What this code does:

- load maxiedit-extension into memory (here $ba00)
- clear the screen and print the load-command for the program named n n$ from last used device d
- set the basic-pointers higher (since the screen-area is larger it needs some parts of BASIC-memory)
- fill the keyboard buffer with HOME and LOAD/RUN - this will load and execute the main-program

Code: Select all

10 sys47616+21:sys47616+116
20 print"your program starts here"

All the main-program then needs to do is to activate the larger screen. For this you need two SYS-commands into the Maxiedit-code, so it circumvents the reset-routine. If you use other versions make sure to adjust the start-address accordingly. For my example I used $ba00 (= 47616 decimal).

[Boray]

This looks great! Thank you so much!

[Mike]

One question: is there an equivalent call to set the cursor X,Y-position directly?

Unfortunately, the KERNAL PLOT routine at $FFF0 is not vectored and calls the original editor routines.

(There's also the other call at $FFED which returns the screen size in X and Y, and which might be nice to have - but to my knowledge no program ever used that and instead relied on fixed 22x23 on the VIC-20 and 40x25 on the C64 ...)

[srowe]

SCREEN ($FFED) isn't vectored either.

[sjgray]

This would be nice as a replacement kernal, installed with a dual kernal switcher. Instant selection!

Steve

[Mike]

SCREEN ($FFED) isn't vectored either.

I can assure you, that I had been fully aware of this at the time I made my former posting.

Just replace "which might be nice to have" with "which might have been nice to have" for any amount of semantic nitpicking.

...

In any case it shows that this extension either needs to expose some internal entry points, so it is possible for a client application to replicate some extra functions other than BSOUT and BASIN (with all their side effects on screen content); or - as sjgray already pointed out - retro-fit this into the KERNAL itself.

Then the open question remains how many "old" programs will actually be able to cope with this. As soon as direct access via POKE comes into play, all bets are probably off again. Even the start-up prompt shows up slightly different, as the original relies on a line overflow to add an extra line between "**** CBM BASIC V2 ****" and "XXXXX BYTES FREE" ...

One reason I asked for the the equivalent of PLOT was, that Ghislain would like to use KERNAL I/O in a 24x26 text screen. The editor wedge of tokra would be a good candidate for this - in case Ghislain is able to spare the 1.5 K necessary for the wedge. However, Ghislain would also like to use direct positioning of the cursor - and this is one point that doesn't anymore work out-of-the-box now with the standard KERNAL entry point. Hence, my question.

[tokra]

Apart from copying and adapting the screen-editor code I did not copy any other functionality from the kernal. Source code attached if anyone would like to expand this. I use the VIC20PrgGen by ajordison.

[Mike]

@tokra: PM sent

[sjgray]

I did a little investigating, and there is a potential problem putting this in ROM:

The VIC-20 has a screen line-link table in zero page ($D9-$F1), that tracks when you print to the last character on the line, and if so updates the table to "link" the line to the next. That's how it knows if you cursor up to edit a line, how many lines it must read off the screen to re-enter the line. The problem is this table is only 25 bytes. So any screen with more than 25 lines would be problematic because it would overwrite important data from $F2 and above.

We would need to relocate this table somewhere else just like Tokra did (LAB_D9). I suppose since we'd need to move start of basic anyway to accommodate the bigger screen, it could be placed there, but then the problem is, the table is no longer in zero page so we'd end up needing more bytes in the kernal to handle the longer instruction code...

Steve

[Mike]

Steve,

those are not the only worms in the can you opened:

1. Regardless whether the replacement editor is provided as wedge or within the KERNAL, the changed BASIC start will break practically each and every BASIC stub of programs in machine language.

2. To rephrase a point of an earlier post of mine: programs which would use some kind of screen size abstraction are found like a needle in a haystack - the only example that comes to my mind is TNT's Z-Code Interpreter. There, the line break routine explicitly takes the number of columns into account.

3. Many other programs will show up with a confused screen layout. For example, BASIC games quite often use PRINT statements, which print two or three rows at once, without a carriage return in-between. Those rows will now be sheared, as the line breaks are at another place, messing up the screen layout.

3a. related, and also already mentioned by me: direct access with POKE and PEEK by "unaware" programs not is going to work - they'll then just access the wrong screen data (except for the first screen line).

Edit: 4. Even if the aforementioned points could somehow be disregarded: putting the code in the KERNAL would only make it easier for the programmer, but will render the application useless for anyone else without that patched KERNAL! You can be sure that people won't be too eager to replace the KERNAL in their VIC-20 just for some client application...


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.