Digitizing video frame for printing

[Lawrence Wilkinson via cctalk]

Sorry I accidentally deleted this message from Dag Spicer, so here it is
for cctalk. Reply to him or the list, not me!

Lawrence


 Forwarded Message 
Subject:Digitizing video frame for printing
Date:   Mon, 28 Sep 2020 06:00:21 +
From:   Dag Spicer via cctech 
Reply-To:   Dag Spicer , General Discussion:
On-Topic Posts 
To: cctalk@classiccmp.org 



Hi there,
Trying to help a former operator of a digital portrait scanning booth
‘back in the day…’ He writes:


IN 1976, I worked at "get your portrait by computer" store.

The heart of the system was a 16 bit, Data General, Nova II computer.

A black and white, analog, standard definition CCTV camera was tethered
to a "digitizer" box that was connected to the computer.

The photographer hit the ‘Capture’ button on the "Digitizer" box to
instantaneously freeze the image and "digitize" it.

The image was then sent to a Centronics, 102AL, 7 pin, dot matrix
printer to print. A perceived grey scale of 26 shades was created by
numbers and letters.

What I am trying to find out is what the "Digitizer" box was and how it
worked. Ram? Tape loop? I DO know that it said 'Digital Image Systems'
on the outside but have not been able to learn more.

Can anyone help with more information about DIS or generically about
these systems? They were popular in shopping malls for a few years in
the mid-70s…

Thanks for any tips!

Dag
——
Dag Spicer
Senior Curator
Computer History Museum

1401 N. Shoreline Blvd.
Mountain View, CA 94043
dspi...@computerhistory.org

5.25" analog alignment floppy disk

[Tom Hunter via cctalk]

I have two poorly aligned 5.25" floppy drives. They read/write disks
formatted by themselves but are marginal on disks formatted by other
drives. Rather than using a crude "good enough" alignment I would like to
do this properly. Is there still a supplier for 5.25" analog alignment
floppy disks?

Thanks
Tom Hunter

Re: Digitizing video frame for printing

[Peter Corlett via cctalk]

On Mon, Sep 28, 2020 at 03:12:50PM +0200, Lawrence Wilkinson via cctalk wrote:
> Sorry I accidentally deleted this message from Dag Spicer, so here it is
> for cctalk. Reply to him or the list, not me!

[I'm not going to attempt to clean-up the top-quoted mess; check your archive
if you can't remember what it said.]

I don't know anything about the unit described, but we can make an educated
guess based on the known facts.

A quick search tells me that the printer has 132 columns and can do 330 cps.
Assuming square characters, 99 rows are needed to maintain the 4:3 aspect ratio
of the video image. 99 is convenient for neither computers nor NTSC, so some
nearby round figure is indicated. I'll arbitrarily pick 120, i.e. every other
scanline, since this is a reasonable upper bound.

Taking 132 samples of a video line requires a sample rate of roughly 2MHz. I'm
not sure of the state of the art in 1976 but that feels achievable. 26
greyscale levels only needs a 5-bit ADC, which also sounds doable. 132x120 is
15,840, which is close to 16,384, and given the 4116 was launched in 1975, five
of those would be perfect. This has a certain elegance and given the "instantly
freeze" claim, my money's on this design.

None of the dimensions are convenient powers of two, nor small integer
multiples thereof, so the actual page size and greyscale depth would be tweaked
to make the digital logic simpler. 128x80 (every third scanline) or 120x96
(every second scanline plus a bit of cropping) feel most likely, and perhaps a
depth reduction to 4 bits since who is going to check if it's really 26 levels
rather than merely assume so because it's made out of letters? If I'm
overestimating the abilities of mid-70s digital electronics, halve the
horizonal figures: digitise at 1MHz and print 64 columns (in 80 column mode).
It'll still impress the great unwashed. One may as well make it 64 rows as well
so it fits in a cheaper 1K DRAM.

A tape loop could be sampled a row at a time at the convenience of the digital
hardware. It still has to sample with 500ns precision, but not every 500ns.
Again, my calculations suggest six samples per line is sufficient to feed the
printer at 330cps. However, while this saves on high-speed digital components,
it adds a complex and unreliable analogue device which might not take kindly to
the hostile environment it's placed in, so I doubt it.

Another alternative is the wheeze done with cheap video digitisers on the 8-bit
micros: one sample per scanline, slow-scanning horizontally, and the subject is
told to sit still for the required duration. The one I saw was PAL and output
to a BBC Micro with its 160x256 mode, so it'd need to sample over 160 fields,
or 3.2 seconds. That's not exactly "instantly" but might be close enough to
fool enough people, especially when compared to a traditional photo booth.

Re: HP 3000, APL\3000, the HP 2641A APL Display Station, and stuff.

[Curious Marc via cctalk]

Bravo!
Marc

> On Sep 27, 2020, at 2:22 PM, Gavin Scott via cctalk  
> wrote:
> 
> As some people here are aware, I have spent probably too much time this 
> summer
> hacking on J. David Bryan's excellent Classic HP 3000 simulator and trying to
> build up the ultimate classic 1980s HP 3000 system (virtually speaking).
> 
> I started with the MPE V/R KIT that's widely available and expanded that into 
> a
> 5x120MB HP 7925 disc system and configured things like the system directory
> size and all the system tables to make a fully functional multi-user server.
> 
> I then set about collecting as much old MPE software as I could find, which
> included Keven Miller's collection of the old Contributed Software Library 
> tapes
> which were conveniently available in SIMH format. This is a huge trove of cool
> stuff including most of the classic mini/mainframe games (Dungeon, Warp,
> Advent, etc., etc.) and even a little game called DRAGONS that was written in
> 1980 by a guy named Bruce Nesmith when he was in college and he used it
> to get a job at TSR and went on to write parts of many classic D&D products
> and eventually landed at Bethesda where among other things he was the
> lead designer for another little game called The Elder Scrolls V: Skyrim. I 
> was
> able to track Bruce down and give him a copy of the system with his 40 year
> old game running on it. The CSL tapes also include other amazing goodies
> that people developed and gave away over the years, including a FORTH and
> LISP, as well as most of the system and utility programs that people used to
> run their 3000 shops. It's quite fun to explore.
> 
> I was curious how far we could push the 3000 simulator, so I hacked all
> the memory bank registers to be six bits instead of four bits, and we
> now have a simulated HP 3000 Series III that supports 8MB of memory, 4x
> more than any physical system ever did. I started trying to do the same thing
> for giant disc drives, but MPE turned out to have too much knowledge of
> what the supported disc models look like to make it practical. Bummer.
> 
> Since I met my first HP 3000 in 1980 (40 years ago this month), people would
> talk about what was probably the most rare and exotic HP software subsystem
> ever produced, APL\3000. APL on the 3000 was a project started at HP Labs
> in Palo Alto in the early 1970s. They were likely motivated by the success IBM
> was having with mainframe APL timesharing services. This would be the first
> full APL implementation on a "small" (non-mainframe) computer. It would be the
> first APL with a compiler (and a byte-code virtual machine to execute the
> compiled code), it would include an additional new language APLGOL (APL
> with ALGOL like structured control statements), and it managed to support
> APL workspaces of unlimited size through a clever set of system CPU
> microcode extensions that provided a flat 32-bit addressing capability (on
> a 16-bit machine where every other language was limited to a 64KB data
> segment).
> 
> Because APL required these extra special CPU instructions that you got as
> a set of ROM chips when you bought the $15,000 APL\3000, and because
> APL ultimately failed as a product (another story in itself) and thus HP never
> implemented these instructions on their later HP 3000 models, I never saw
> it run on a real HP 3000, but over the years we talked about wouldn't it be
> cool to find a way to get APL running again.
> 
> With assistance and moral support from Stan Sieler and Frank McConnell
> and others, I was ultimately able to reverse-engineer the behavior of the
> undocumented ten magic APL CPU instructions needed to get it to run and
> implement them as part of the MPE unimplemented instruction trap and now
> APL\3000 runs again for the first time in ~35 years. Somewhat ironically, this
> implementation method could have been used back in 1980 as I didn't
> actually end up changing the hardware simulation code at all, and it should
> also run (if a bit slowly) on any physical classic architecture 3000.
> 
> So that was cool and all, but what is APL without all the weird overstruck
> characters and whatnot? APL\3000 supports the use of plain ASCII terminals
> through blecherous trigraphs like "QD for the APL quad character, but this
> is hardly satisfying. So the quest was on to find a solution. Back in 1976 
> when
> APL\3000 was released, there was a companion HP terminal in the 264x line,
> the HP 2641A APL Display Station, which was basically an HP 2645A with
> special firmware and APL character set ROMs that supported all the APL
> special characters as well as overstrikes (the terminal would take 
> XY
> and lookup to see if it had a character to represent Y overstriking X and if
> so it would show that on the display, and if that got transmitted to the host 
> it
> would convert it back into the original three character overstriking 
> sequence).
> 
> I briefly looked into the idea of hacking QCTerm or Putty or something,