3 ms·
I can top that. Back in 1973-4 I was running Fortran programs on a CDC 6400 via a remote batch terminal. It consisted of a card reader, a line printer, and a
by ScottBurson 10y ago
I can top that. Back in 1973-4 I was running Fortran programs on a CDC 6400 via a remote batch terminal. It consisted of a card reader, a line printer, and a console with CRT and keyboard. It was connected via a 9600bps modem -- a rare device that I'm sure cost thousands of dollars back then.
Anyway, the CRT had a scan pattern I've never seen since. Instead of two levels -- a fast horizontal scan nested inside a slower vertical scan -- it had three: there was a slow vertical scan (presumably 60Hz), a medium-speed horizontal scan that happened once, not for each pixel row, but for each character row, and then a fast character-height vertical scan to draw the character rows. So it drew each character row from left to right one pixel column at a time.
The whole thing must have cost well into six figures. Nonetheless it was a little flaky. Sometimes the video on the console would go out -- I found a particular spot on the case where I could whack it with my hand and the video would come back.
- userbinator 10y agoThat's interesting and an example of what tricks can be accomplished if your hardware is far more integrated --- I'd guess that the scan order was designed specifically to require the least amount of buffering/auxillary RAM, and also keep the character framebuffer in a linear order. Constraints on character ROM access probably played a part in this too --- the more common pattern of scanning one row of each character in a line requires changing the addresses of the framebuffer and character ROM far more often, while this "character-at-a-time" scan probably means they could pipeline accesses to the framebuffer and ROM.
- kps 10y agoIt sounds like a workaround for the RCA character generator patent.¹ ¹ http://www.google.com/patents/US3345458 http://www.google.com/patents/US3345458