> From: Mike
> The one question I do have for the older gentlemen on here is what in
> the world did the computers without a screen to look at do?
There are a number of different generations, and the way they were used
generally depended on what the computer in question had for I/O capabilities.
In the very earliest machines, the computations tended to be mathematical
modeling; things that needed a lot of computing, but had very modest I/O
requirements. The classic example was the hydrogen bomb calculations
performed on ENIAC (which was originally built to do ballistics
computations), but other similar ones included structural modeling, etc.
That class of application continued (and does so, to this day), but over
time, more and more things got done using computers, as their capabilities
(online storage, I/O, etc) grew. In general, the new applications were added
to the existing ones, but did not supplant the earlier ones.
Starting with a computer in England called LEO:
https://en.wikipedia.org/wiki/LEO_(computer)
they were also applied to business applications (inventory, payroll, billing,
etc), which typically did more modest computations, but more I/O, which
required better I/O capability (cards, tapes, printers, etc).
With the advent of timesharing in the early 1960's, it became common to add
individual character-output terminals (initially printing, moving mostly to
video terminals circa the mid-70's), and with the ability of users to
interact with applications running on a computer, applications broadened even
further; online text preparation was one common one.
The final phase came with the introduction of bit-mapped video terminals,
which allowed the interactive users to use graphics, and images; the very
earliest such systems were on time-sharing mainframes, but with the growth of
personal computers, that technology migrated there (note that the very
earlist PC's had only character-output terminals, mimicing their main-frame
big brothers of the time).
Noel
At 03:04 PM 12/20/2015, Eric Smith wrote:
>The problem has been solved.
Is the solution available online?
Dale H. Cook, Roanoke/Lynchburg, VA
Osborne 1 / Kaypro 4-84 / Kaypro 1 / Amstrad PPC-640
http://plymouthcolony.net/starcity/radios/index.html
Does anyone have a scan of the IEEE-696 (S-100) standard that has NOT
been run through OCR to screw up the typography (and even some of the
illustrations)?
I'm *not* looking for the draft, only the final standard.
Is anyone using this combination? I'm having problems getting it to work
reliably on a soft-sector controller in my Heath H89 and their forum is
essentially dead.
--
The WD9000 Pascal Microengine main box does not include floppy drives.
It can support up to four floppy drives, which can be either 8-inch
(500 kbps transfer rate), or 5.25-inch (250 kbps transfer rate), as
selected by a DIP switch setting on the WD900 board. Unfortunately
the DIP switch directly controls the clock rate into the 1793 FDC
chip, so it is not possible to mix 250 kbps and 500 kbps drives.
However, it should be possible to mix 8-inch drives with high-density
5.25 inch or 3.5 inch drives that use the 500 Kbps transfer rate.
The floppy connector on the back of the WD9000 box (and the WD900
board) uses a DC37S connector, and the pinout seems to be unique to
the Pascal Microengine. My Microengines did not come with the floppy
drives or cabling. I've designed a simple adapter PCB, and just got
the first boards back from PCBWay today. I haven't yet finished
assembling one because I screwed up ordering on some of the components
and connectors. Photos:
https://www.flickr.com/photos/22368471 at N04/albums/72157660580290148
The WD900 board uses an FD1791 double-density floppy controller. It
appears that the main board may have been originally intended for the
FD1771 single-density controller, as the board revs I've seen don't
have a suitable double-density data separator built in. On one of my
units, the FD1791 is on a daughterboard with a typical analog data
separator design using the WD1691 floppy support logic and a 74LS629
VCO. My other board has the FD1791 on the main board, but has some
significant rework to install an SMC FDC9216B digital data separator
chip in place of one of the TTL chips originally used by the main
board design. I've seen other WD900 boards with the FDC9216B
modification, so I think this was rework done at manufacturing time,
rather than a field change.
One aspect of the floppy controller design seems a bit unusual. The
WD controllers have a HLD output used to tell the floppy drive to load
the head, and an HLT input (Head Load Timing) to indicate that the
head is loaded. After the controller asserts HLD, it waits for HLT to
go true before proceeding with read, write, or format operations. A
typical 8-inch drive takes 35 ms to load the head, and maybe a few
more for head settling. A common way to wire the controller is to use
an external one-shot triggered by HLD, with its output wired to HLT,
and adjusted for a time delay a little longer than the drive requires
for loading the head. 8-inch drives typically can either be jumpered
to use a dedicated head load control line on the interface to control
the head load solenoid, or to automatically load and unload the head
as the drive select signal is asserted and deasserted.
Normal 8-inch drives have the head load solenoid to do what was
previously described, and run the spindle motor either all the time,
or whenever a disk is inserted and the door closed. 5.25-inch drives,
and some later 8-inch drives such as the Tandon TM848, do away with
the head load solenoid and instead are intended to operate with the
spindle motor active only when the drive is selected, or when a motor
control signal is active. As such, they don't require any head load
time, but instead require a motor startup time that is even longer;
the slowest drives require about a second for spinup. With a WD
controller, this is also sometimes accomodated by using the one-shot
between HLD and HLT.
Some WD-based controller designs, such as those in the TRS-80 Model I,
III, and 4, are only intended for 5.25-inch drives (or the 8-inch
drives that use motor control and no head load solenoid), and tie the
READY signal from the drive to the HLT input of the FDC.
The WD900 board tries to acommodate these variations by bringing the
HLT signal to its DC37S connector, for the system integrator to wire
up as desired. The only complete Pascal Microengine system I've seen
up close in recent history had a hand-wired drive cable to 8-inch
drives, with the HLT signal simply tied to a +5V pin on the same
connector. The net effect of that is that the FD1791 asserts HLD,
delays 15ms if the h bit of the command is 1, and does not delay any
further. Unless the drive can actually load its head that quickly,
this doesn't seem ideal, but I suppose it works because the FDC won't
be able to read a valid sector address field until the head is loaded.
For a write operation, I'd worry that the head might not have fully
settled by the time the actual write begins, possibly leading to
unreliable writes.
To support proper head load or motor spinup timing, I put an optional
PIC microcontroller and DIP switch on the adapter, to act as a digital
delay between HLD and HLT, with sixteen switch-selectable delays. The
drive select lines are wired to PIC inputs, so if desired, firmware
could actually use different delays for different drive selects, if
you mix drives with different head load timing requirements. I
haven't yet written any PIC code for it. The board should basically
work as described above with HLT jumpered to +5V, without the PIC and
related components installed.
The adapter has both a 50-pin connector for 8-inch drives, and a
34-pin connector for 5.25-inch or 3.5-inch drives. It is intended for
one connector or the other to be used, but not both. Even if you use a
combination of drives that all use the 500 kbps transfer rate, having
them cabled separately to the two connectors could result in
termination problems.
Naturally, only hours after ordering the PCBs I thought of
improvements that I'd like to make to the design, but I don't
anticipate that there will be a second run of boards.
I don't presently have any bootable disk for the Pascal Microengine,
so I'm not yet able to test the adapter. However, if anyone else needs
such a thing, I have a small number of bare boards that can be made
available inexpensively. (I don't have time to assemble boards other
than for myself.) If there's any interest, I'll publish the Eagle
design files, gerber and excellon files, a PDF of the schematic, and
source and object code for the PIC firmware. The firmware will be
GPLv3 licensed, and the other design files with be under a Creative
Commons license, probably CC BY-SA 4.0.
Hi there everyone.
I'm hunting for an NEC PC-8031A mini-disk module for the NEC PC-8001A
computer. I have the computer itself and PC-8012A expansion chassis
already.
Additionally looking for anything else relating to this computer that you
might have kicking around and be willing to part with. Including but not
limited to the "Wedge", expansion unit cabling, expansion cards, etc.
Note: I have seen the one floating periodically on eBay and am keeping a
close eye on eBay in general for this unit so am looking for leads outside
of that.
If anyone has stuff for this computer, please contact me off-list. I'm
near Philadelphia and willing to drive to avoid you having to pack/ship.
Not against shipping stuff either.
Thanks!!
-Todd
From: Mike Ross <tmfdmike at gmail.com>
> I have a 3172 controller; physically rough and needs restoration but *should* work if
> I can fake the remote connection and modem - bisync etc. B
From: Paul Berger <phb.hfx at gmail.com>
> you need a modem eliminator mostly to provide the clocks for the sync data line,
> other than that is is similar to a null modem.
Not sure if this would work here, but the Cisco IOS "IBM Feature Set"
has support for all sorts of weird bisync use cases. I've used it to
fake termination of an ALC (Airline Line Control) bisync connection
where a modem connection was expected. You can then convert, tunnel
or bridge to any number of other strange things.
There even exists an IBM channel attach card for the Cisco 7k routers
that turns it into the equivalent of a 3172 and/or 3745.
KJ
> From: Brent Hilpert
> I need to move to something newer but I haven't evaluated current
> schematic-drawing programs
Dave Bridgham got me started with KiCAD, and that seems like a pretty good
system to me. It has separate sub-systems for schematic capture; circuitry
checking; netlist generation; PCB layout; etc, etc. I've only worked with the
first three, but it seemed pretty good for them.
> I'm a little concerned they won't provide the degree of control or
> finesse I like
Well, you'll have to try it and see, but it's pretty customizable: they
provide libraries of common components, but it has a nice component editor
for drawing up new ones (or customizing the ones it comes with).
Component location and line routing (in the schematic capture) are manual,
but it's grid-based, so things line up.
Noel