The SCELBI PROM board is working fine and I was able to create a small program in the editor and execute pass one of the assembler with MEA. I can’t completely assemble a program and run it until I get the cassette interface built and operating. Pass two of the assembler writes the output to cassette tape. I’ll have to hold up doing a video until I can get the complete package going. My impressions of the MEA package are quite positive. It’s not as elegant as later software you might be more used to. However, considering the time frame it was made and the platform is the 8008, it’s a pretty nice package.
SCELBI PROM and extra SRAM boards cost $50 each and are available now. This recent work also confirms that the TTY board is working fine and those are available for $30.
I’ve been using an Apple IIe in 80 column mode with a bit-banged serial serial card to act as TTY emulator. However there are a couple of fairly significant issues that need to be solved before publishing this teletype replacement solution. It’s usable for me, but there are some problems. The two issues with my current Apple II TTY emulation solution are:
This image shows the Apple IIe acting as a TTY for the SCLEBI 8B on the left. The screen contains a small program entered with the MEA editor. The listing of the program at the top of the screen has two extra lines at the end. The “D 000 006,000 007” is an editor command that deletes lines 6 and 7. The “L” command lists the text buffer. The last two commands “P1” and “P2” are pass 1 and pass 2 of the assembler. Pass 1 shows no errors. Pass 2 writes results to cassette tape. Since the cassette isn’t installed in my system it actually does nothing. If I had a tape, pass 3 would read the object back into the system so it could be executed.
The “E”s on the left side of the screen should be the first character of the next line, but the Apple IIe can’t scroll fast enough to be ready to receive the first character of the new line, so it receives a partial character.
Try making the Apple II text window shorter by two lines and see if you still lose data.
Nice idea, reducing the window size, will reduce amount of data to scroll, speeding up the system.
Yeah, Woz wrote the scroll routine for compactness and flexibility, not speed. If you find that you can avoid dropping characters by narrowing or shortening your text window, you could wedge your own COUT with a custom quick-scroll routine using a BLOAD, two POKES and a CALL. I did something similar back in the day with a Hi-Res COUT for my ][+ that allowed bold-face, italic, and underlining, inspired by Bob Bishop’s AppleVision code. My Hi-Res scroll routine was naturally kind of slow, because I was moving almost 8K at a time, but for the text screen you could do something like:
SCROLL:
ldy #$27
SCR2:
lda $480,y
sta $400,y
lda $500,y
sta $480,y
lda $580,y
sta $500,y
…
lda $7d0,y
sta $750,y
lda #$a0
sta $7d0,y
dey
bpl SCR2
…
This method is hard-coded for a 40 by 24 screen, but is significantly faster than the monitor ROM routine because it doesn’t check for window boundaries or make any calls to VTAB.
Mike
Pingback: Improved Apple Teletype Emulation « Mike's Hobby Blog