Damn, I wanted to do that with my own //c, but the monitor has some capacitor problem. 
2 Likes
Back in the mid-90s, my brother and I used a parade of terminal devices to share a PC running Linux. Among them was an Apple //c running some sort of terminal emulation software that my brother found, either on the Internet or a bulletin board. I seem to recall that he found it as a code listing suitable for dumping into the Wozmon, which led to an interesting chicken and egg problem. In any event, we got it running and used it successfully for some time.
My memory suggests that, whatever software it was, we liked it because it was capable of quite fast serial operation (at least 19200 baud, which was faster than the TeleVideo 910 that was our most capable contender until a Wyse of some sort came along some time later), but its emulation was less than perfect. I believe it had problems with scrolling operations, probably due to the slow speed of the Apple text output modes when writing line ends.
3 Likes
For what it’s worth, the Apple IIc serial ports can handle 115,200 bps easily enough, as demonstrated by ADTPro. That’s 287 or more 40-character lines per second. The UART has only a one-character buffer, however, so you need to make sure you’re available to grab a character every 89 cycles or so.
However, there’s no hardware assist for screen scrolling, leaving the Apple IIc to do that in software. A well-optimized routine for this might be able to do this in about 11 cycles per byte (LDA base,Y; STA base+40,Y; INY) plus various bits of overhead every three lines, which works out to around 10 ms to scroll the screen, or around a hundred lines per second at best.
But there’s no need to produce a proper scroll for every line, especially not when it wouldn’t even be visible due to the 60 Hz (16.67 ms/frame) display refresh rate. Humans likely cannot make sense of anything faster than about ten frames per second, so if you limited your screen updates to no faster than that (scrolling multiple lines when necessary), a human user should find things just fine. with a full screen sent from the remote generallyi appearing in one to two tenths of a second.
All the above is based on using a 40-character; display. Double it and add a tiny bit more extra overhead for an 80-character display.
2 Likes
The speed of ADTPro versus other retrocomputer communications and disk imaging packages I’ve used is mind-boggling! It’s really a fantastic suite of software.
I am pretty sure we could never get whatever terminal app we used to go anything hear 115200, though; 19200 sticks in my mind, but perhaps 38400 or faster was possible.
Hmm … why scroll at all? Simply wrap output back to the top of the screen so long as data is still streaming in. This gives the appearance of page flipping, and it’s a great fit for MORE/LESS behavior (which displays one screen of info at a time).
When data stops streaming in, that’s when you correct the screen to scroll it to the correct degree.
In normal interactive use, there will be a weird visual effect of text appearing at the top of the screen briefly before the screen corrects the scroll. But I think that’s a small price to pay.
Hmm … to optimize for MORE/LESS paging behavior, the bottom line should be copied to the top line before moving on to the next line. That’s still perhaps 80 bytes copied at once, so you’ll have to interleave the UART fetching code with that…
I think the visual behaviour of that might be less than optimal, and it also seems harder to program. There seems to be enough CPU to handle the input and the scrolling, if one just limits the update rate to once every frame (or maybe two) and scrolls multiple lines at once when necessary, and that sounds as if it would be easier to program than the correction.
Actually, it what the Apple is missing here is a DMA engine, like the Commodore’s REU. With a bit of additional programmability (the ability to test an additional location for certain characteristics, such as a bit set) it should also be usable for reading from programmed I/O devices straight into memory at up to the full rate the bus can give you.
Now that I think about it, this is something it would be nice to include in all modern retrocomputing board designs. DMA to load RAM from “off-board” ROM (using a microcontroller such as an AVR) is a fairly common technique already (see, e.g., @drogon’s Ruby 6502 or Tadashi G. Takaoka’s RetroCyborg). There’s no reason it shouldn’t be tweaked to do other I/O as well, along with memory-to-memory DMA.
That said, without some extremely specially configured DMA, scrolling on an Apple II will never be as efficient as on other machines becuase of the peripheral card scratchpad RAM (which must be preserved) scattered throughout the display memory. If there’s any one design decision in the Apple II that was definitevely the wrong one, the non-linear video frame buffers was it. (Woz has said he did it just to save parts, and only a chip or two. There seems to be a myth going around that the layout had something to do with RAM refresh, but this not the case.)
That’s a neat idea @IsaacKuo! One can imagine a world where this was normal, and scrolling was felt to be disorientating.
It might be that there’s some way to amortise the cost of scrolling by doing some work as characters come in. There probably isn’t the RAM capacity for this, but one can imagine a bit of dynamic code, progressively built up as characters are printed, which will repaint the screen appropriately when executed. For example, the code loads a constant and stores to several absolute addresses, and so on for each constant that needs to be written. (It’s a tactic which works well for sprites.)
1 Like
Yes, it’s harder to program. It just happens to be the sort of programming challenge that I like.
If I wanted to go for the easiest thing to program, I’d have an off-screen buffer which is simply accepts text, along with a dumb screen update routine which copies text from the off-screen buffer to the screen - maybe 8 characters at a time interleaved with polling the serial input. This approach assumes you have adequate RAM available for a second buffer (which of course isn’t a problem for a typical Apple 2 system, but I also like to ponder unexpanded VIC-20 development).
“One can imagine a world where this was normal, and scrolling was felt to be disorientating.”
To me, the question is not so much a matter of whether it’s disorientating, but rather what is easiest to read at speed. When scrolling is slow, smooth scrolling is a wonderful way to preserve readability while also scrolling. But when scrolling is fast, it’s inevitably a “blur”. However, if you instead flash flip pages, there’s at least the possibility that you will be able to perceive some words you’re looking out for or something.
So, for example, consider flipping pages twice per second vs scrolling three lines 12 times per second. The overall rate is the same, but the latter is a hopeless blur. Even if you try to follow the scrolling with your eyes, the mismatch between the scrolling updates (12/sec) and the monitor’s refresh rate (60/sec) results in a jumpy blur. And on, say, an Apple /// Monitor with long persistence phosphors? Forget about it! In contrast, seeing new text scan downward across the screen twice per second could be somewhat readable - albeit still too fast for even a speed reader to truly take in.
1 Like
I personally would find it confusing if as I saw stuff flash by I saw patterns that were backwards, e.g., I saw a group of short lines just before a group of long lines, but actually the short lines were after the long lines and appeared before only because the display was sometimes placing the next group of lines above a group that had just come in.
So you’re talking about “scrolling” 24 lines at a go? That’s reasonable, if your text is coming in slowly. But even at a full 80 chars per line, that will nowhere near keep up with 115,200 bps, which has a minimum scroll rate of 144 lines/second, or 6 screenfulls. (If your average line length is 40 chars, which is probably more reasonable, you’re looking at 12 screenfuls per second.)
My feeling is that at those rates I’ll get a better sense of what’s gone by if it scrolls past very quickly but relatively smoothly, rather than if I simply see a flash of a full screen of new data 6-12 times or more per second. But I’ve never seen anybody do the latter.
1 Like
Hmm… you can simulate what it would look like to get a page of new data 6-12 times per second by using MORE to display a large document, and hold down the SPACE bar for key-repeat. Do this on a modern computer locally, and it’ll be fast enough to be a page at a time for each key-repeat SPACE press. Depending on how fast you are with manually pressing SPACE bar, you can get close to 6 times per second by mashing SPACE bar quickly.
I’m not sure of an easy way to simulate scrolling at 144 lines/second, but I’ve seen various scroll rates similar to that while doing large recursive rsync tasks on lots of small files. I think it’s a lot harder to read anything scrolling up so quickly.
1 Like
It’s really a matter of what you value in the conversation.
The solution the problem is handshaking, which will naturally constrain the download speed. Set the terminal on smooth scroll and that will rate the speed down even more.
115K baud is roughly 5-6 pages per second. Which is certainly fast. Without scrollback available it’s likely too fast for most people. Humans have a visual response time of 250ms (extensively researched by glancing at the first hit on google). By the time you see something at 115K and react to it (say, pressing a key to pause the screen), odds are what you were looking for just shot off the screen and is gone.
That’s why in the other thread I mentioned writing a simple more program for CP/M. 9600 baud is not an issue, ^S/^Q do the work. But I wanted to work within the 80x24 constraints of the day, vs just using my scrollback.
With scrollback, yea, speed away. My macOS terminal buffer is as big as free memory and swap space (i.e. GBs of space), so it’s wonderful. Let it run, then pore through it later.
Now, for transferring data (up/downloading files, etc.), things that are not constrained by human cognition, then, the more bits the better.
1 Like