Hi.
My apologies to those of you who already know this; I am going through
my address book somewhat indiscriminately. :-)
I am sending this message to a melange of my friends, family, and
business contacts. I have moved (from Rochester, NY, to Canastota, NY)
and very shortly will no longer be at cchiesa1 at rochester.rr.com.
My new e-mail address will be cchiesa1 at twcny.rr.com . Please use it
henceforth. Thank you!
Chris Chiesa
Jay wrote:
>You might try Crisis, see www.crisis.com
>They are great folks, I've delt with them a lot.
>
>You might try some of the comp.sys.hp.XXXX newsgroups,
>I know there is an HP hardware one there that used to
>have good info (not saying they don't anymore, I just
>haven't been there in ages). There was also an HP3000
>newsgroup that had a lot of grizzled veterans from
>"back in the day" who may have some info. I just noticed
>a csd.machines and csd.machines.hp group that
>could be fruitful just based on the name (I'm assuming
>csd is Computer Systems Division).
I will poke around in these groups and see what I can find.
>> I need to construct an interface cable for my
>> recently acquired HP7202A flatbed pen plotter.
>I messed with a few HP plotters many many years ago.
>I seem to recall that their interfaces were bizarrely
>"multipurpose". You're going to need a manual I bet.
>I seem to recall that there were option selections in the
>cable as well as dip switch settings? Whatcha gonna
>do with your other 72xx plotter?
I have the service manual for the 7200A, which is basically
the same plotter. I am still trying to figure out the
technical diagrams in the manual. HP does not appear to
have as much detail in their engineering diagrams as DEC
did. If I can't find a cable, I will figure it out. I just
need to find out which 4 pins are used for the 20mA interface
and then I should be in business.
I plan to keep my other old HP plotter, which is a 7210A model.
Right now I need to "borrow" the pen holder from it because
the one on the 7202A is broken.
The 7210A was a couple years newer than the 7200A/7202A. It
used a different command language and a different interface.
Ashley
http://www.woffordwitch.com
I got no bites the first time, so I'm trying again.
Does anyone know of any good classic HP forums,
sites, or parts sources?
I need to construct an interface cable for my
recently acquired HP7202A flatbed pen plotter.
This plotter was manufactured around 1971 and
could be interfaced using one of three styles of
interface cables (it appears that they all plugged
into the same male adapter port on the back of
the unit, but must have used different pins). I
plan to use the 20mA style of hookup, which I
assume will use four of the pins. I just need
to determine which of the pins are used for the
20mA send and receive. Other options were for
an EIA (RS232) connection, and a third type of
connection. The plotter is controlled using
ASCII commands to plot points or lines.
I am looking for someone who may have had some
experience with these plotters in the past. Even
better (although not likely) would be that someone
would have an interface cable. These are HP part
numbers 17251A, 17252A, and 17253A.
Last night I repaired the fuse housing, cleaned
out the dust, and powered on the plotter. It
worked fine in standalone mode. The electrostatic
"chart hold" feature held a piece of paper in
place on the bed, and the lower left and upper
right "pen set" functions worked, as did the
"pen up / pen down" button and the controls to
move the pen.
The plan is to hook this ancient device up to
my 11/40 as part of my classic computer center.
Ashley Carder
http://www.woffordwitch.com
>
>Subject: Re: Billy Pettit real disappointment
> From: Gordon JC Pearce <gordon at gjcp.net>
> Date: Thu, 28 Jun 2007 15:02:42 +0100
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Thursday 28 June 2007 13:58:28 Jay West wrote:
>> Billy wrote...
>>
>> >> Come on people: there were computers long before there were
>> >> microcomputers.
>>
>> I seem to remember a recent post complaining that this list was nothing but
>> minicomputer and big-iron talk, no microcomputer discussion. Apparently
>> that was wrong, as now there is a complaint it's just micro talk? ;)
>
>It's never going to be "all things to all men", is it? Everyone has their own
>little sphere of interest, and what may seem hugely off-topic to one person
>might be massively relevant to another. For instance, I like the DEC
>conversations, but I'm not quite so interested in HP (but I keep an eye on
>them just the same). I'm surprised there's not more about the UK
>microcomputer scene. I'm incredibly surprised that there's no discussion at
>all of early computer-based musical equipment; we all know about EMS and the
>Putney Studio I'm sure, but what about the Fairlight CMI and the Synclavier?
>I'm surprised the latter wasn't mentioned during the "weird computers"
>thread...
>
>And what of the things to keep the big *big* iron running? I'm also
>interested in stuff like the power plant and environmental plant around old
>kit - but I can easily see how some would see that, and the Fairlight, as
>offtopic.
>
>Maybe we need some sort of map showing what we think is on- and off-topic...
>
>Gordon
Well for on topic and weird Computers or IO...
PDP-8 I've never seen anything else that did IO that way save
for the CMOS version.
TI9900 (and 990) oddball IO but loved the workspace pointer idea.
Minuteman Missle guidence computer. Bizzare transistor serial machine
where the fixed head disk drive served both program storage and as
active registers. I wonder if there are any around and if they are
operational or the mountain of manuals needed to figure it out?
Allison
Hi,
> The only reason I feel Tony's HP can't be classified as a
>microcomputer is because I was taught that a microcomputer
>utilized a microprocessor, and I was taught that the definition
>of a microprocessor is a processing solution contained entirely
>on one chip. Anything larger (more than one chip) and it's a mini....
That's a bit too inflexible a definition. Just off the top of my head, by
that logic, the i8080 is a minicomputer....which it clearly is not.
Likewise, would you consider a processor made from bit-slice devices to be a
mini?
TTFN - Pete.
Has anyone got any recommendations for PCB CAD software on Linux?
I tried Eagle, which I'd heard a lot about, but found it to be utterly
useless. Practically everything I tried to do resulted in a big pop-up box
saying something to the effect of "This feature is disabled in the Light
version", even things like moving pads on the grid.
Gordon
The Lisa Emulator Project, Release Candidate 2 is now ready for
download: http://lisaem.sunder.net/downloads.html
The biggest change is in the video handling code. The following
description on video methods is a bit technical, so skip over it if you
find your eyes glaze over.
The rawbitmap method:
The video updates are now using a hidden API in wxWidgets called
rawbmp.h, which allows direct read write access to the pixels. This
isn't a secret API by any means, since wxWidgets is open source,
however, it is undocumented. To turn this on pass --with-rawbitmap on
compiling.
This is a lot faster on OS X, but it crashes win32, and shows a black
screen on Linux
The SetRGB wxImage display method:
An alternate method is also available for systems where rawbmp.h doesn't
work, such as on win32. Compile using --without-rawbitmap to enable
this slightly slower mode.
While this mode is also much faster than the original version on OS X,
it's slower than rawbmp.
The SetRGB method builds a wxImage, and access the pixels via the SetRGB
method, then converts the wxImage into a wxBitmap, and blits the result
to the display. (On wxWidgets, you can't blit Images, they must be
converted to wxBitmaps, and there's no SetRGB method on wxBitmaps.)
The original code which built 4x1 blits has been ripped out. In terms
of speed, it worked fine on Linux and Windows, but it failed miserably
on slower OS X machines. The new code is also a big hack, but at least
it's a good hack. :-)
The rest of the display mechanism is based on Brian Foley's code, which
refreshes only the changed data, and schedules CPU execution via a
timer. While Brian's UI code is a lot cleaner, the main LisaEm wx UI
code has branched off too far for it to be compatible, so I've adapted
the code to do what his code does. Future updates will aim for cleaner
C++ code.
There may be issues refreshing the display on scrolling, however.
Another issue, is that the new code causes a bit of fuzzing in the
antialiased modes. This is due to the color levels used by the new
code. This will be fixed eventually by trial and error. I suspect that
tweaking contrast/brightness levels is what's needed.
The Display refresh rate options have been removed as they're no longer
needed.
The biggest improvement is for G4 OS X machines - the new display code
is fast enough to get a 5Mhz on average for a 500Mhz G4 running OS X
10.3.9. It uses about 60M of real memory and about 160M of swap (which
includes things like profile disk images, and other mmap'ed data) on the
same G4.
Other improvements:
Dual Parallel ROM cheat - if you have this ROM and are using it, the
power on self test is very painfully slow, especially on older systems,
the new version bypasses the test routines, so power on time is a lot
faster. Should future releases of the emulator support other expansion
port cards, this method can be used there as well.
NOTE: If you do not enable the ROM cheats when using the Parallel ROM,
and set the throttle to anything other than 5MHz, the Parallel ROM tests
will not only take a very long time, but fail since they test CPU vs VIA
timing.
Unlike most standard open source software, LisaEm doesn't use
"./configure; make; make install" autoconf/automake method of building.
However, Linux distro maintainers have scripts that make use of that, so
I've built a fake configure script file that builds a makefile which
acts as a wrapper around the build.sh script.
libdc42 updates allow access to both macbinaryII wrapped DART and
DiskCopy 4.2 images, and detects Disk Copy 6 images. (Since the
NDIF/DMG file formats are undocumented, libdc42 cannot support them.)
Floppy code can now deserialize tools/install disks and offers the
option on disk mounting.
Inserting a blank floppy works again. Previously, it either attempted
to install an existing floppy, or when inserting a blank disk whilst
running Lisa Office System it would cause LOS to hang when initializing.
Added raw buffered keyboard mode to compensate for keyboard repeating
when throttle >5MHz.
The Lisa's COPS Clock is now decoupled from CPU clock, so that the time
is accurate regardless of the throttle setting.
Remaining known bugs:
Screen blurriness with new display. This is a color levels issue. (new)
win32 crashes when built --with-rawbitmap (new)
Linux shows a black screen when built --with-rawbitmap (new)
There's a problem with MacWorks emulation which has existed for a few
versions of the emulator - when quitting an application MacWorks gets
stuck in a loop refreshing the desktop and reading from the floppy.
This prevents the Hard Drive installer from completing as well. I've
done a bunch of swap & compile attempts to switch out parts of the
source code to isolate the code causing this but haven't been able to
locate the bug.
Scrollbar arrows overlap in LOS. This has existed since the very first
versions.
>> Hp does not appear to
>> have as much detail in their engineering diagrams as DEC
>> did.
>
>Oh, I strongly beg to differ as I'm now intimately familiar with both
>documentation sets. However, at the risk of starting a religious war I shall
>just saunter off quietly instead :)
>
>Jay West
Nah, don't saunter away. I'll scan the stuff in and maybe
you can give me some pointers on deciphering it!!
Ashley
http://www.woffordwitch.com
Rather urgently needed....
Servo formatting PCA (12995-60114) and the special servo writing head
Servo reference cartridge (12995-60031)
I was sure that I had the above items, but I just went looking for them and
it appears all my "special" cartridges were head alignment carts not servo
formatting carts. Also turns out all my disk service boards were head
alignment boards, no servo formatting boards. Yikes!!
What hurts the most - is someone showed me a link to the above on gov liq a
few weeks ago. I didn't bid - and now wish I did.
If anyone has the above, I'd be interested in borrowing for a bit... or
trading for.
Jay West
Hi,
> How about early modems, anyone collect them?
Not exactly early, but at one time I did collect various Hayes SmartModems
and assorted other "interesting" modems....still have them, but lost
interest in them LONG ago.
TTFN - Pete.
Well, I can assure you that I do not have deep pockets,
but I have 3,000 square feet of telephone switching equipment.
Two main manufacturer's TRW Vidar and Stromberg Carlson DCO switches.
I have been repairing these swithes for 25 years. The interesting thing
about the DCO to this list is it was based on the DEC processors, 11/34 and
11//75. The DCO still incorporates the DEC Alpha CPU's, and at one time
there were 1500 switches installed in the US. I know of 10 operating
companies, including national carriers that are still using them. To the
best of my knowedge, there is only one woking Vidar switch still operating
in the US.
With gov regs and technology pushing towards VoIP all of the companies will
soon have the "suitcase" sized switches.
Oh, and as you might guess, the MTBF is not engineered in years anymore, it
is based on product life cycle.
>
>Subject: Re: Modern external storage emulating RX02 (was Re: Most used toys,was Re: The late, great TRS-80)
> From: Richard <legalize at xmission.com>
> Date: Wed, 27 Jun 2007 12:54:41 -0600
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>In article <468295F6.5050801 at nktelco.net>,
> C H Dickman <chd_1 at nktelco.net> writes:
>
>> Ethan Dicks wrote:
>>
>> > and expansion options. An RX01/RX02-attached device, at least, will
>> > work with OMNIBUS machines as well as the VT78 and DECmate I - overall
>> > not a bad range to cover.
>>
>> I did that using a PC as the external storage and a PC parallel port as
>> the interface. Lets me run my PDP-8/e and PDP-11/40. DECtape is cool,
>> but a little slow.
>
>Do you have software/interface schematics? I have a DECmate I and no
>RX0[12] drives.
Easier to find an rx01.
Allison
>--
>"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://www.xmission.com/~legalize/book/download/index.html>
>
> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
>
>Subject: Re: Modern external storage emulating RX02 (was Re: Most used toys,was Re: The late, great TRS-80)
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Wed, 27 Jun 2007 16:02:14 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 6/27/07, Allison <ajp166 at bellatlantic.net> wrote:
>> Using a Tu58 on an -8 is not a goot match and there are lots of gyrations.
>
>Agreed.
>
>> >If all PDP-8s had a spare serial port, it might make sense to have a
>> >serially-attached modern mass storage peripheral.
>>
>> Adding a second serial is trivial as there were many differnt serial
>> cards available. To make a TTY card RS232/432 passable is also not hard.
>
>It's trivial from the OMNIBUS days onward to add another serial port.
>Not so trivial for a Straight-8, an -8/S, an -8/L or -8/i. One may
>argue that machines that old don't matter so much, but I do happen to
>have a BM08 on one --8/L (total of 12K) and would like to be able to
>bring up OS/8 on it someday. I'd also like to expand my -8/i to have
>8K of core (and perhaps a full 32K eventually) and bring OS/8 up on
>that as well.
If you have a parallel port or even an interface to read/write one bit
with an IOT (less parts than parallelport or tty interface) there are
possible interfaces even for 8s.
>Changing out 20mA for RS-232 isn't hard at all with the older machines
>- Vince Slyngstad made some EIA paddle cards for pre-OMNIBUS boxes. I
>have at least two of his cards. Some day, I'll find the time to
>assemble them, but for now, I'm fine with hanging a VT220 off of my
>-8/L with a 20mA cable.
20ma works too. Though it's not hard to pick up the TTL or logic
before 20ma conversion.
>> What is possible now is a small micro and a big static ram of 512k are
>> which fairly easy to find it's not unreasonable to simulate a RX02
>> using a micro at the end of a serial line (or parallel) and NOT use
>> the protocal of TU58.
>
>Sure. There's no requirement to use the TU58 protocol, it's just
>understood, is out there, and happens to work with a real device. If
>you are going to write an OS/8 driver anyway, there's no reason to
>stick with a protocol that's hard to use. I just dredged up an old
>thread in my reading where someone suggested the TU-58 as the
>"obvious" device for a diskless PDP-8. I was just heading that debate
>off at the pass, since it was extensively investigated over 20 years
>ago and determined to be difficult, technically.
The need to buffer the tape data is the annoying part as well.
>> The cpu/micro used does not have to be very high
>> powered or fast as all it's doing is data transfer and PDP-8 PIO is
>> usually slower than 30-40K words/sec.
>
>Certainly not if you are rolling your own interface. If you are
>trying to make a plug-compatible RX02 emulator, there might be some
>bit-level stuff that's timing critical, but the overall bandwidth is
>rather low by modern standards.
RX02 interface [RX8E] is fairly simple bit serial with clock.
>> In the end what is used is more a matter of convenince than technology.
>
>Agreed.
>
>> I happen to be lucky(?) as my 8f has two serial cards but nothing
>> else device wise. One of th cards is the usual console TTY but the
>> other is a UART based M8652 that were often used for modem
>> banks and serial data concentrators/switches made using PDP-8s.
>
>Nice.
What I have is some Q or Ubus quad wide proto cards that could easily
be used on Omnibus with a few cuts. Parallel IO is spelled out in the
interface handbook.
>
>In amongst all the other recent PDP-8 discussions, I have to wonder
>that if one was going to be spending $$$ on a 1 sq ft. PCB with edge
>fingers and whatever line drivers, what would be a good choice of
>peripheral options to stack on the same board. For example, the
>DKC8AA has several independent devices on one hex-height card. In a
DCKAA, have to look that one up.
>quad-height form factor, one could easily stuff two RX8Es, and at
>least one, if not two KL8Es, which should take care of a lot of
>external I/O requirements. The RX8Es would use the standard OS/8
>driver, of course, simplifying that aspect of things, but then one
>could attach that to either a real RX02 if you had one, with floppies
>to read/write, or to an off-board RX02 emulator as we've been
>discussing. Personally, I don't have even one RX8E per OMNIBUS
>machine, so alternatives are an interesting direction for me.
If the driver were developed for the device it could be anything.
For example the device could be two parallel output and one input
port. One output port sets the block address (128word block for
512kW) and the second is read/write to ram data with auto increment
to the low block counter. That would be PIO, no micro and two
512k byte wide rams (4bits wasted) and 5 74LS161s as the ram
address counter (modulus 128). There are existing pdp8 parallel
IO cards that can do that.
When it cools down and I get a few minutes that might be an easy
board to try and build. I imagine patching OS/8 is not hard as
the device page is locatable. Though the complete package would
need a test program, formatter and a device driver for OS/8.
Allison
>
>-ethan
Hi,
>>....I though they'd dropped that after the 400 series?
>
> No.
Yeah, I've just had a rummage around "hpmuseum.net". It seems the
"HP-Apollo" name was used up until the end of the 700 series, in fact the
712 (the last of the 700 series) was the first machine to be branded "HP"
alone.
Learn summat new every day. :-)
> http://www.debian.org/ports/hppa/
>
> I've installed it on C110 and possibly HP "Apollo 715" systems
>a few years ago...
Thanks for the info. I did a reasonable amount of "googling" when I picked
up this 712, but didn't find that port. Only OpenBSD and NetBSD appeared to
have PA-RISC ports.
I don't currently have any intention of switching away from HP-UX, but it's
nice to have the option....
TTFN - Pete.
On 6/26/07, Dave McGuire <mcguire at neurotica.com> wrote:
> > Serially connecting would rot though...
>
> Yeah, kinda.
I was just reading some old list threads about PDP-8s and TU58s and
emulators - transfer speed aside, the real problem was that most
pre-OMNIBUS PDP-8s didn't have a spare serial port (just the console
TTY), and that the serial hardware needs to be able to send a Break to
the TU-58 to properly initialize and reset the controller in the
TU-58, and unmodified PDP-8 hardware can't do that. I did run across
a bunch of old 12-bit SIG newsletters from when the TU-58 was new, and
all the gyrations folks went through to be able to use them, since at
the time, they were about the cheapest mass storage you could get from
DEC. One entire aspect of the project was how to mod M706/M707 or
KL8E serial interfaces to generate a break. Another aspect was trying
to wedge a driver into a couple of pages of code.
If all PDP-8s had a spare serial port, it might make sense to have a
serially-attached modern mass storage peripheral. Since that's
nowhere near universal, it frequently comes down to deciding on which
models to support. One of the few disadvantages of the PDP-8 spanning
1965 to 1994 (PDP-8 to DECmate III) is that there's a huge variety of
hardware that all runs the same instruction set (give or take a couple
instructions), but with an equally huge variety of default peripherals
and expansion options. An RX01/RX02-attached device, at least, will
work with OMNIBUS machines as well as the VT78 and DECmate I - overall
not a bad range to cover.
-ethan
>
>Subject: Modern external storage emulating RX02 (was Re: Most used toys,was Re: The late, great TRS-80)
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Wed, 27 Jun 2007 11:14:19 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 6/26/07, Dave McGuire <mcguire at neurotica.com> wrote:
>> > Serially connecting would rot though...
>>
>> Yeah, kinda.
>
>I was just reading some old list threads about PDP-8s and TU58s and
>emulators - transfer speed aside, the real problem was that most
>pre-OMNIBUS PDP-8s didn't have a spare serial port (just the console
>TTY), and that the serial hardware needs to be able to send a Break to
>the TU-58 to properly initialize and reset the controller in the
>TU-58, and unmodified PDP-8 hardware can't do that. I did run across
>a bunch of old 12-bit SIG newsletters from when the TU-58 was new, and
>all the gyrations folks went through to be able to use them, since at
>the time, they were about the cheapest mass storage you could get from
>DEC. One entire aspect of the project was how to mod M706/M707 or
>KL8E serial interfaces to generate a break. Another aspect was trying
>to wedge a driver into a couple of pages of code.
Using a Tu58 on an -8 is not a goot match and there are lots of gyrations.
>
>If all PDP-8s had a spare serial port, it might make sense to have a
>serially-attached modern mass storage peripheral.
Adding a second serial is trivial as there were many differnt serial
cards available. To make a TTY card RS232/432 passable is also not hard.
> Since that's
>nowhere near universal, it frequently comes down to deciding on which
>models to support. One of the few disadvantages of the PDP-8 spanning
>1965 to 1994 (PDP-8 to DECmate III) is that there's a huge variety of
>hardware that all runs the same instruction set (give or take a couple
>instructions), but with an equally huge variety of default peripherals
>and expansion options. An RX01/RX02-attached device, at least, will
>work with OMNIBUS machines as well as the VT78 and DECmate I - overall
>not a bad range to cover.
>
>-ethan
What is possible now is a small micro and a big static ram of 512k are
which fairly easy to find it's not unreasonable to simulate a RX02
using a micro at the end of a serial line (or parallel) and NOT use
the protocal of TU58. The cpu/micro used does not have to be very high
powered or fast as all it's doing is data transfer and PDP-8 PIO is
usually slower than 30-40K words/sec.
In the end what is used is more a matter of convenince than technology.
I happen to be lucky(?) as my 8f has two serial cards but nothing
else device wise. One of th cards is the usual console TTY but the
other is a UART based M8652 that were often used for modem
banks and serial data concentrators/switches made using PDP-8s.
Allison
On 6/27/07, Allison <ajp166 at bellatlantic.net> wrote:
> For PDP-8 ops, even 10mb is a "large" disk I'm sure so even a 1mb ram
> could work well as a "ramdisk".
Sure... since OS/8 uses 12-bit block pointers, 10MB works out to 5
"devices". 1MB of RAM for a RAM disk isn't tiny, either.
-ethan
> Are there people out there, on the list or otherwise, that are actively
> collecting these machines?
Absolutely. There are private collectors with operational CO's. These are
serious deep-pockets people who are buying surplussed microwave relay stations
and putting museums into them. There are two I know of in San Jose and the
central valley in private hands.
The telephony collectors have many decades of head start on us computer types.
Another magazine article unearthed on the subject of pulling the lid on a DRAM
chip and using it as a camera sensor...
This time it was in the May 1984 issue of "Your Robot" magazine, and looks to
be intended for use with a Spectrum. Unfortunately the article was a
two-parter; only the second part (containing the software) is in this issue
and the hardware side was in the previous issue.
Does anyone else on here have good copies of the following:
HP-85 Mass Storage ROM Pocket Guide (00085-90139)
HP-85 Plotter/Printer ROM Pocket Guide (00085-90141)
HP-85 BASIC Reference Card (00085-90039)
HP-85 Pocket Guide (00085-90040)
Assembler ROM HP-83/85 Pocket Guide (00085-90445)
Advanced Programming ROM Pocket Guide HP-83/85 (00085-90147)
I/O ROM and Interface Pocket Guide Series 80 (00087-90122)
... the ones I unearthed today are decaying extremely badly, with chunks of
the pages missing, lots of brown discolouration, and the surface of the main
HP-85 pocket guide's cover is actually falling off.
If I were *very* careful I might just get a scan out of them if I first snip
the staples and separate the pages (with staples in place I don't think
they'll open up and lay flat without crumbling into dust). If someone else has
good copies though already I'll not waste my time...
If someone already has high-res colour scans then even better :-)
(I have no idea what happened to them to make them like this - whilst I've
seen older 'rough' paper discolour and go a little brittle, I've never seen
more recent 'glossy' paper like this just start to completely crumble into
nothing)
cheers
Jules
>
>Subject: Most used toys, was Re: The late, great TRS-80
> From: Dave McGuire <mcguire at neurotica.com>
> Date: Tue, 26 Jun 2007 16:22:36 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
My list is not very esoteric.
My older NS* Horizon system with many mods running CP/M as a workhorse
system for micros and 8085/z80 coding as it tend to behave better than
PCs and also has the Prom Programmer. The system is Z80/10mhz, 256k ram,
two 31mb disks, floppies, and a few other goodies.
My PX-8 as a data logger and all round Field Day Logging system a
database written in of all things BASIC.
AmproLB+ small, fast, hard disk and CP/M.
PDP-11/73 rack system for those times when I need a break.
Nothing like programming in basic or micropower pascal under RT-11.
PDP-8f, when I need a handle. I like hand toggleing programs and
watching them run.
PILOT: my MicroVAX3100/m76 running OpenVMS, for when it really has to
be different or when once cpu is not enough (running as nine way LAVC).
My portable EElf2000 (embedded elf with Video, PS2 keyboard and CF disk)
that runs nicely on a 12V gell cell for a while (>10hours!).
If it really has to be Wintel, my 486sx brick system (Modular Solutions).
it's about the size of a red brick and runs on 12V nicely. What makes it
useful is 800mb hard disk, network, SVGA, serial, parallel
and runs whatever I care to. It seems to like DOS6.22 and Linux(slackware).
Allison
--- Chris M <chrism3667 at yahoo.com> wrote:
> Problem w/WD-40 and other stuff is that it will
> dillute the true lubricant, and wherever metal is
> coming in contact w/metal, rapid wear will ensue.
> Best
> to keep that stuff away from machinery or any other
> critical moving parts. Paint thinner would work
> better
> at releasing junk, and at least it evaporates (much
> more quickly).
As an addendum, I do use Liquid Wrench (or WD-40, or
the generic Walmart variety) and a Scotch-Brite (which
comes in grades) for rush removal, then usually rinse
off w/thinner. Keep in mind that a SB supposedly has
imbedded metal particles, so it essentially DOES
remove metal. I'm not joking, and in some instances
this is critical (high tolerance machine parts,
watchmaking equipment, etc.). You may ask how does
such stuff get rusty to begin with, but take for
instance a 100 year old lathe w/hand scraping marks
(indicative of a VERY accurate finish) in areas. The
application of a SB and light oil, and...bye bye.
Sometimes it's better to start out with real fine
steel wool or even a paper towel :)
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
>
>Subject: Re: Most used toys, was Re: The late, great TRS-80
> From: Dave McGuire <mcguire at neurotica.com>
> Date: Wed, 27 Jun 2007 03:09:30 -0400
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>On Jun 26, 2007, at 8:01 PM, Chris M wrote:
>>> The SBC is currently sitting on the table behind
>>> the 8/m, mostly
>>> due to laziness on my part. The disk images reside
>>> on the SBC's
>>> system disk, which is a 1GB CF MicroDrive plugged
>>> into the SBC via a
>>> daughterboard. The SBC is headless; I access it
>>> over the network.
>>
>> You ought to document this arrangement.
>
> I would be happy to. Perhaps I'll take some pictures of it tomorrow.
If you do a simple block diagram and maybe descriptions of software on both
the host (pdp-8) and SBC would be helpful or better yet sources.
>> I get the jist of most of it, but yer SBC must have integral ethernet.
>
> It does.
>
>> When I see SBC I think Ampro or something LOL.
>
> It's very similar to an Ampro x86 SBC that I also have in my junk
>box. (if I could only turn it into a LittleBoard..) The SBC is a
>Teknor VIPer 830.
>
I suspect any SBC or PC that could run headless and has disk would work
given the right code and interface. I've considered a small 8085 powered
board with a IDE or CF drive to do that.
I have a BCC180 (z180 with 256k ram) and lots of parallel IO that would
be a good candidate for that.
For PDP-8 ops, even 10mb is a "large" disk I'm sure so even a 1mb ram
could work well as a "ramdisk".
Allison
>> And what sort of daughterboard (PC-104?).
>
> Not PC/104...The Teknor board has a mezzanine slot (which I think
>is proprietary) which takes a small daughterboard that's not much
>bigger than a CF card. You plug the CF card into the daughterboard,
>then snap that assembly onto the SBC. It's quite a nice arrangement.
>
>> I have
>> a few PMMX SBC's that I believe have ISA slot
>> capability (maybe even PCI), and even my Ampro Little
>> Board/PC has a header w/ISA signals.
>
> Yes, this one is similar. It can take PC/104 and PC/104+ boards,
>and the SBC itself can plug into a passive 16-bit ISA backplane. I
>always found it odd that a board that has PC/104+ (which is PCI on a
>different connector) capability would have an ISA card-edge connector
>on it instead of PCI.
>
>> Some earlyish
>> SBC's have "flash" storgage capability, RE Robot/Vesta
>> OEM-188, but that's something different I take it
>> (like eeprom?).
>
> Is it DiskOnChip(tm)? Many SBCs can take those, both early and
>modern. I have a small pile of them somewhere.
>
> -Dave
>
>--
>Dave McGuire
>Port Charlotte, FL
>
Patrick Finnegan <pat at computer-refuge.org> wrote:
>
>On Tuesday 26 June 2007 23:50, Ensor wrote:
> > I also question whether the thing will run Linux as he says in the
> > auction description....Open/NetBSD certainly, but I've not seen a
> > PA-RISC port of Linux.
>
> http://www.debian.org/ports/hppa/
>
>I've installed it on C110 and possibly HP "Apollo 715" systems a few
> years ago...
The Debian GNU/Linux port to PA-RISC mature and fully supported. I've
used it for the last 5 years or so on two boxes. I first installed it on
a nice HP 715/100 system and used it as a desktop with KDE. It was slow,
but not unusable. My webserver currently is a nearly OT HP Visualize
B2000 workstation running at 400MHz (www.approximatrix.com). It runs
Apache 2 and Zope/Plone content management system on top of Debian
GNU/Linux 3.1 HPPA.
The PA-RISC hardware is rock-solid, and Linux is well supported on it,
thanks to HP. I've never had a system crash except when an external SCSI
disk catastrophically failed (not the HP system's fault). I would suggest
trying out Linux on the 700 series systems people have as I pesonally
can't stand HP-UX.
The NetBSD port to the PA-RISC is, by comparison, completely immature.
IIRC, up until last year, they didn't even support booting from CD.
Their install procedure was laughable at best (required another NetBSD
machine to prep the disks or something...), and it made me wonder what
their criteria was for "supporting" an architecture.
jba at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org