Putting tokra's reply to Aleksi's post first:
tokra wrote: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.