The comments about memory adderssing make sense for the horizontal size, but not necessarily for the vertical. That said, it is definitely easier to get a 4040-like counter to reset every 1024 ticks than every 960 ticks - but this is trivial.
I think the reason may be that older systems actually used 24-bit color, often with no underlay/overlay/alpha channel. This gives 3 bytes per pixel, for a total of 3.75 Meg for the display. This fits comfortably within a 4M framebuffer. The next higher multiple of 128 for the horizontal is 1408, with a 1056 vertical (for 4:3), and that is too much for a 4M framebuffer.
I know that back in 1987 (and probably before), the SGI Iris (with a whopping 25MHz R3000 and 32M RAM!) had a 1280x1024x24bpp display. (of course, that was 24 bits color, 24 bits z-buffer, 2 bits overlay, 2 bits underlay, and another 24bit+24bit rendering buffer, for a total of 100 bits/pixel!)
This may be another one of those "They're doing it, so we might as well, too" kind of things.
Actually, I would think that a removable hard drive scheme would be better.
You may need some custom software to allow you to easily mount / unmount / keep track of the photos on a disk, but a hot swap SCSI (or IDE - yuck:) bay and some relatively high capacity drives would probably fit the bill. The hassles with tape (sequential access, slow transfer speed, relatively flimsy media, expensive drives, etc) are probably not worth the reduction in cost. With the cost of hard drives plummeting and capacities skyrocketing, you'll be able to get similar capacities to tapes, with much faster and easier access.
Of course, the alternative, for non-portable storage, would be to get a big rack enclosure, and just add hard drives as necessary to accomodate new pictures.
Slashdot Mirror
The comments about memory adderssing make sense for the horizontal size, but not necessarily for the vertical. That said, it is definitely easier to get a 4040-like counter to reset every 1024 ticks than every 960 ticks - but this is trivial.
I think the reason may be that older systems actually used 24-bit color, often with no underlay/overlay/alpha channel. This gives 3 bytes per pixel, for a total of 3.75 Meg for the display. This fits comfortably within a 4M framebuffer. The next higher multiple of 128 for the horizontal is 1408, with a 1056 vertical (for 4:3), and that is too much for a 4M framebuffer.
I know that back in 1987 (and probably before), the SGI Iris (with a whopping 25MHz R3000 and 32M RAM!) had a 1280x1024x24bpp display. (of course, that was 24 bits color, 24 bits z-buffer, 2 bits overlay, 2 bits underlay, and another 24bit+24bit rendering buffer, for a total of 100 bits/pixel!)
This may be another one of those "They're doing it, so we might as well, too" kind of things.
You mention tape as an alternative.
Actually, I would think that a removable hard drive scheme would be better.
You may need some custom software to allow you to easily mount / unmount / keep track of the photos on a disk, but a hot swap SCSI (or IDE - yuck :) bay and some relatively high capacity drives would probably fit the bill. The hassles with tape (sequential access, slow transfer speed, relatively flimsy media, expensive drives, etc) are probably not worth the reduction in cost. With the cost of hard drives plummeting and capacities skyrocketing, you'll be able to get similar capacities to tapes, with much faster and easier access.
Of course, the alternative, for non-portable storage, would be to get a big rack enclosure, and just add hard drives as necessary to accomodate new pictures.