3 ms·

The explanation of raster scanning in portrait mode reminded me of an interesting peculiarity in some other equipment. Some of the first HP test equipment with

by kw71 10y ago

The explanation of raster scanning in portrait mode reminded me of an interesting peculiarity in some other equipment. Some of the first HP test equipment with raster crt screens, had the displays oriented in a landscape position, but the rasters were vertcal. So they scanned from one side to the other instead of from top to bottom. I wonder what the reasoning behind that was and how they dealt with that in the framebuffer and character generator.

deleted 10y ago
[deleted]
CamperBob2 10y ago
The HP 3561A FFT analyzer did that: Display quality is further enhanced by scanning the raster vertically at a rate of 36,205 Hz with the vertical lines formed from left to right. Since most rapid trace variations occur vertically, this gives a smoother trace by reducing the jagged line appearance compared to a horizontally scanned raster. (from http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-12.pdf http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-12.pdf page 15) The frame buffer and character generator live in an earlier stage of the display block diagram, so they aren't really impacted by the choice of scan direction. You also tended to see a lot of vertically-oriented CRTs in arcade games back in the day, so the concept wasn't unique to the Alto. That's the first place I'd look for a replacement CRT.
- joezydeco 10y ago
  Arcade games simply rotated the (raster) tube 90 degrees. They were still scanned on the long axis.
rbanffy 10y ago
For a scope, it kind of makes sense. If the wave you are showing changes between scan lines, the display may get confusing. If you scan along the data acquisition, it'll look neater.
- kw71 10y ago
  Yes! They were early digital oscilloscopes and logic analyzers.
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 ago
  That'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 ago
    It sounds like a workaround for the RCA character generator patent.¹ ¹ http://www.google.com/patents/US3345458 http://www.google.com/patents/US3345458

by kw71 10y ago

deleted 10y ago

[deleted]

CamperBob2 10y ago

The HP 3561A FFT analyzer did that: Display quality is further enhanced by scanning the raster vertically at a rate of 36,205 Hz with the vertical lines formed from left to right. Since most rapid trace variations occur vertically, this gives a smoother trace by reducing the jagged line appearance compared to a horizontally scanned raster. (from http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-12.pdf http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1984-12.pdf page 15) The frame buffer and character generator live in an earlier stage of the display block diagram, so they aren't really impacted by the choice of scan direction. You also tended to see a lot of vertically-oriented CRTs in arcade games back in the day, so the concept wasn't unique to the Alto. That's the first place I'd look for a replacement CRT.

joezydeco 10y ago
Arcade games simply rotated the (raster) tube 90 degrees. They were still scanned on the long axis.

rbanffy 10y ago

For a scope, it kind of makes sense. If the wave you are showing changes between scan lines, the display may get confusing. If you scan along the data acquisition, it'll look neater.

kw71 10y ago
Yes! They were early digital oscilloscopes and logic analyzers.

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 ago
That'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 ago
  It sounds like a workaround for the RCA character generator patent.¹ ¹ http://www.google.com/patents/US3345458 http://www.google.com/patents/US3345458