The Apple II Applesoft BASIC editor had that horrid thing with like ESC D and you had to cursor to the end of the line before you hit return.

The TRS-80 Model I had something even worse, to wit:
EDLIN on the earliest MS-DOS machines was just awful. I can't remember what it was on CP/M (my Osborne 1 purchase for $7 at a garage sale in 1995 never saw much action, and I tended to play more with the Apple II and Apple III machines when I worked at ComputerLand in 1981)

During senior year of high school, 1979-1980, sometimes they would let me play on the Digital Equipment machine running TOPS-20 at Delta College in Saginaw. I actually liked TECO. The fastest I ever got with a code editor was on EDT on VAX/VMS circa late '80s. That thing was hooked up to the numeric keypad and it became second nature. Nowadays I use notepad clones (Geany) or vi, or rarely emacs.

But the Commodore 8-bits, they all have the coolest full screen editor! Also a graphics character set and lowercase. Move the cursor anywhere, hit return anywhere on the line and it parses the whole thing. A PET screen is exactly 1K consisting of 40x25 screen codes plus 24 bytes of 40/80 column "line wrap table". Rather than implement the Leo Brodie editor, I'm just going to marry Forth blocks to the Commodore screen editor. And today I got the STOP button to function as an ESC key. It isn't perfect yet, but I can tell it is going to work.

I'll stash piles of screens into a buffer that grows downward from the top of RAM until it bumps into the dictionary growing in the opposite direction. The entire buffer space will be stored in PRG files. That means it will work with a single magnetic storage device, either on cassette or disk. I'll bury the mass storage interface (just need "LOAD" and "SAVE" and maybe "VERIFY") inside the editor and I won't require FLUSH and SAVE-BUFFERS. BLOCK will merely uncompress one of the screens into a shadow video area ($7C00-7FFF). The lowest block number is 1. The highest block number is limited to how many buffers are currently in RAM. Attempting to access a block outside of that range will ABORT" BLOCK OUT OF RANGE"

The core of the editor is really simple. I hook the iRQ to trap the STOP key (my escape key) and dump out into a tight machine language loop to accept a line of text using the ROM editor, but don't process it. Once the user has filled the screen up with whatever, they just hit STOP followed by a single character editor command. The STOP key is trapped by an IRQ. It has to restore the IRQ vector to the factory value, replace the character underneath the cursor if it was winked on, and thrash its way out of the IRQ (drop the RTI address and the stashed register stuff off the machine stack) before transferring control to high level Forth. That's where the command is retrieved, things happen to the screen and buffers, and we are thrown back into the minimalist screen editor.

EDIT ( -- ; invoke the editor )

general
STOP STOP - nothing happens. The editor continues to wait for the second keypress
STOP any other key that isn't listed below - still nothing happens. The editor continues to wait for the second keypress
STOP SPACE - cancel editor command, return to edit mode
STOP Q - save the current screen to the buffer, drop out of the editor to the Forth command line
STOP CLR - reset linewrap table to all 40-char lines (not too sure about this one)

screen navigations
STOP HOME - first screen
STOP UP - previous screen (create one if necessary)
STOP DOWN - next screen (create one if necessary)
STOP INS - insert a blank screen in front of the current screen
STOP DEL - delete the current screen. Replace it with the next screen. If there's no next screen replace it with the previous screen. If there's no previous screen show a blank screen.
STOP I - index, displays top line (first 40 characters) of all active buffers (max 25). User can move the cursor to any index line and hit return to edit that screen.

mass storage
STOP S - save all screens to a named file to disk or tape
STOP L - load a named file of screens from disk or tape
STOP V - verify memory vs. a file on mass storage

line copy/paste buffer
STOP Z - zilch the paste buffer at PAD. Do or do not. There is no undo.
STOP X - cut the current logical line (40 or 80 characters), append to paste buffer. Move stuff up from the bottom of the screen. (like "dd" in vi)
STOP C - copy the current logical line, append to paste buffer
STOP V - paste (insert) the entire buffer (whole lines only) above the line the cursor is on (like "P" in vi)

There's a conflict with "V" for Verify and Paste. Nothing Verifies Bad Data In Z80 Computers (PETs had VERIFY and better cassette reliability. TRS-80s, not so much.) I'm calling for votes on this one. Am I missing anything here?

This word takes two arguments and toggles either the BRK vector or the IRQ vector between two addresses by applying XOR. Used for turning the STOP key IRQ hook on and off, and for switching between BRK to Sweet16 or BRK to TIM (Terminal Interface Monitor)

and wa-la, the editor (sans command key handlers) in its entirety! It references five ROM addresses, three of which are Kernel calls (CHRIN, CHROUT, UDTIM) and one (MAINIRQ) which can always be found by looking in the CINV irq vector contents at ($0090). The one ROM dependency for a 40-column PET is FIX_CHAR at $E606. There's something else here on 80-column PETs and all bets are off if anyone tries to port this thing to VIC-20 or C=64. This also might be the very first time I've ever used a stack frame on the 6502.

Nice reuse of existing code. The line wrap table seems like it would be less useful for Forth code, but I presume it would be more work to prevent the linewrap mechanism than just leave it in?



Just so you know, it's spelled "voila" (or more correctly "voilà"), a spelling often confused with the stringed instrument "viola".

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

99% of the reason I'm leaving 40/80 logical lines in is because the screen editor is all native PET, with some extra commands. There's no way to take it out without sacrificing the PET ROM editor. The screen memory starts at $8000, and the line wrap table at $e0 is a pointer to the high byte of the screen address, so when the screen clears it is initially $80 $80 $80 $80 $80 $80 $80 (0..240) $81 $81 $81 $81 $81 $81 (280..480) $82 $82 $82 $82 $82 $82 $82 (520..760) $83 $83 $83 $83 $83 (800..960). It's a little weird, 7 / 6 / 7 / 5 (25 bytes). The high bit indicates if this physical line is the start of a logical line (or $80) or if it's a continuation line (and $7F).

This is all 40-column PET and the ideas probably map to C=64. I'm not sure how 80-column PETs or 128s in 80-column mode would do, and I'm too lazy to simulate one in VICE.

I've noticed that the first byte is *always* $80 because logical lines (40 or 80 characters) scroll off the screen in their entirety, so the top/first line is *never* a continuation/extension of the previous line. That means the entire table can be stored in 24 bits. Each compressed screen will have the screen codes RLE-encoded, followed by the 3-byte line wrap table for physical lines 2-25, followed by a 2-byte size. I went with RLE encoding because it's fast and simple and better than no compression at all. I'm looking at Pucrunch to see if there's anything I can use from that scheme.

This might be easier with an example. Here's what an empty screen would look like.
20 20 00 20 20 00 20 20 00 20 20 E8 FF FF FF 11 00
Taken apart, that's three runs of 256 spaces (20 20 00) followed by 232 spaces (20 20 E8) followed by the line wrap table (lines 2-25 are all 40-column) followed by the packet length word (11 00 = 17 decimal)

I can't speak for the PET, but the C-128 uses a 160 character logical line length, regardless of which video mode is being used.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think the PET also used a maximum logical line length of 160 characters (4 screen lines) in the editor. But Basic didn't really care, it had a maximum line length of 255 characters. I remember reading about tricks where you would type two lines of Basic, and then used a couple of peeks/pokes to find the two lines (hoping that they would be adjacent in memory too), and merge them together by modifying the pointer in front of the first line. That way you could make really long lines that couldn't be edited because the editor would cut them off as soon as you tried. Good times

===Jac

Another easier but more limited trick was to use BASIC token shortcuts in the source code. When LISTed, the source tokens would have their fully expanded text and thus larger than the original input. Since it then wrapped across longer than what the screen editor supported, changing it was definitely not easy. Even pressing Return over the existing line replaced it with a truncated version.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Hmm... the PET logical line is 40/80. I'm implementing the copy/cut/paste thing and I came across this design conundrum. The bottom line (physical line 25) is a 40-character logical line. Physical lines 3&4 are an 80-character logical line. I hit STOP-Z to zilch the paste buffer. I move the cursor to line 3 (or 4, doesn't matter) and hit STOP-C, appending the 80 characters to the (empty) paste buffer. Now the paste buffer contains just the 80-character line. I move down to line 25 and hit STOP-P to paste it in. Should it:
a) replace line 25 with just the first 40 characters of the line (a copy of line 3 but not line 4)
b) do nothing, because there isn't room to insert 80 characters here
c) something else

I'm leaning towards "b"

"b" seems reasonable, with perhaps a beep or screen blink so the user doesn't start hammering the keyboard, thinking that the keys didn't register (I suppose that makes it "c" then). I seem to remember reading somewhere that you could crash the C64 by doing something quirky with the screen editor's insert function, but I never intentionally tried to crash my C64 or Apple ][ ... I did it enough times by accident!

Mike

The default behavior in the Commodore screen editor would be to scroll the screen up, but that doesn't seem part of a single-screen editor. I'd say 'b' makes the most sense as well.

One thing you didn't mention is how scrolling during line wrapping would happen. On the default screen editor, when you wrap around a line, it pushes everything below it down 1 line to make room, scrolling the bottom line of text off the screen. That would likely seem unwanted for a single screen editor. Does your code mitigate that?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

That brings up a point that you might consider: is it even necessary to have lines longer than 40 chars in a single screen editor? I know that it's important for a language like BASIC (thinking about long IF ... THENs), but is it necessary for a more free-form language like FORTH? The screen of code is pretty-much WYSIWYG, right? Or am I missing something?

Mike

My code is here to accommodate the boss, which is the PET built-into-ROM full screen editor. It's a total black box. Whatever silly rules it makes up, my code will just have to work with. The alternative would be to copy the screen editor into RAM and rewrite most of it, and have several different variants of it for the different editor ROM versions. Since I want it to feel exactly like a PET, leverage as much PET stuff as possible, and I'm really cheap with RAM, that is not the plan. I believe the technical term for this design pattern is bag on the side I'm using as few non-kernel ROM addresses as possible, so PETTIL can be more easily ported to other PETs and probably the C=64.

EDIT will repeatedly send the user off into the black forest of editor ROM la-la land to collect one line of input forever. The user pressing the STOP key (outside of quotes, not in insert mode) will airlift us out from this trip to the woods, and we have an opportunity to inspect and modify the model before sending them back in. These are the interesting parts of the model that the screen editor presents

Assumptions
$e0 *always* contains $80, so I can safely ignore that. The ROM will scroll only complete logical lines off the top of the screen.
the "a" bits should follow their text around when the line is moved.
the "bb" bits should remain right where they are
Moving the cursor to do anything in my add-on code is a Bad Idea(tm), and so is emitting screen control characters

I thought about doing select ranges with character pointers, but not for very long. When I use vi, I rarely venture beyond a few commands ( :q :wq i A dd p P J . ) and when I want to do something tricky, I usually have to look at the help page. I'm not proud of this, but it also seems to be just enough vi to get by on. This pidgin vi is sort of the inspiration for my editor. Without something like it, moving lines and chunks of code around in the PET screen editor would be impossible without a lot of retyping.

STOP-Z (zilch) erase the paste buffer
STOP-C (copy) nondestructively append the current logical line to the paste buffer
STOP-D (delete) append the current logical line to the paste buffer, deleting it from the screen. Scroll everything underneath up. Fill the bottom of the screen with blanks.
STOP-P (paste) insert as much of the paste buffer as will fit before the current logical line. Everything from the current logical line to the bottom of the screen moves down.

On further reflection, Paste really would have to replace physical line 25 with just the first-half-logical-line (approach A) if it's trying to insert an 80 character logical line but there's only 40 characters of room left at the bottom of the screen, for two reasons. First, if I am insertiing more paste buffer than will fit above some text already on the screen, it would look very strange to truncate the paste buffer at line 24 and show some original text on line 25. Second, approach B gives no indication to the user that something happened, unless I beep. And PETs don't have sound prior to the CRTC versions. Flashing the screen is a pain, it requires setting up IRQs.

Where I'm at today: I realized that having PASTEBUF return just the tail of the pastebuf isn't enough information. I can't do PASTEBUF PAD - and know the size, in bytes, so I can calculate how many lines I need to insert prior to the current line, because each PASTEBUF record is 41 or 81 characters, not 40 or 80. So I'm refactoring PASTEBUF to also return the size.


https://github.com/chitselb/pettil/blob ... editor.a65

I'm not sure if I'm getting on peoples' nerves with these long-winded soliloquies, but please weigh in if I am bugging you and I will just stick it on my tumblr project blog from now on. Trying to explain it really helps me to think things through. I call it "the brick wall approach," but I'd rather tell it to people who might be interested in the project than my mom, even though the results are similar.

My only issue is that you asked if you missed anything, and I still don't see addressing scrolling. What is the expectation, for a single-screen editor, for these situations?

• User hits cursor-down or Return in line 25
• User newly wraps a long line elsewhere when there is existing text in line 25 (via typing or INSerting)

Both of those situations are what the stock editor will do, and would mess up a single-screen editing session; a lesson sorely learned from using the screen editor to draw PETSCII screens.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Other than two-character STOP-command sequences, the user is living entirely in the ROM screen editor. It is possible in the screen editor to push things off the bottom, e.g. by hitting insert from column 39 of a 40 character line. It is possible to erase the entire screen with shift-CLR. It is possible to accidentally scroll things off the top by hitting RETURN or DOWN on line 25.

The undo facility is provided by the STOP-R (restore) command. Leaving a screen will automatically save it to a screen buffer area that grows downward from $7C00, and the STOP-R (restore) command will refresh the screen to its last known state if the user wants to undo a big mistake. STOP-UP (prev screen), STOP-DOWN (next screen) will save the state of the screen right now and come back to it.

I came up with a better way of performing paste

1. remember the position of the paste buffer tail
2. iteratively cut every line from currline to the bottom of screen, say, line 26 just to be safe. (reuse the EDITDEL word in a do loop)
3. get the wrap table above this line ( WRAPABOVE ) leaving a double on the stack with linewrap bits from line 1 to the line above the current logical line
4. copy lines from the start of the paste buffer from here to the end of the screen
5. and append their wraptable bits (1 or 1,0) to the double on the stack
6. until the linewrap table is full (24 bits)
7. write the 24-bit double to the linewrap table ( WRAP! )
8. restore the paste buffer tail to its original position

The way I'm handling line wrap is to first stuff it into a double consisting of a "1" bit
followed by 24 bits of $E1-$F8 bit7. This word seeds the double with all the linewrap
bits above the current logical line. Once this double has 25 bits in it, the word WRAP!
will put them back into the linewrap table.

Perhaps I'm over-simplifying this, but have you considered zapping all of the logical screen lines back to 40-columns every time STOP is pressed? That way, there won't be any confusion associated with 'invisible' line wraps. In a BASIC listing, there were line number cues to help you (although that wasn't fool-proof), but in Forth, it seems to me that wrapped lines are not worth the effort. What benefit would wrapped lines offer over unwrapped, with the possible exception of long string literals?

In other words, my idea would be for STOP to take whatever randomly-wrapped mess the ROM screen editor and user give it, and zap it into a 25-logical-line snapshot before copying, pasting, or saving.

Mike