Hello, all:
Just a quick announcement. Today was the official release of version 2.1 of
the Altair32 Emulator. Yeah!
It's been about four months since the 2.0 release and a lot has happened
since then. Floppy disk images for CP/M, Altair DOS and Disk BASIC are fully
functional and the Altair32 now has an integrated debugger, courtesy of Jim
Battle's Sol-20 emulation project. These two items alone took over half of
the time between releases and integrating the debugger required a major
overhaul of the 8080 emulation code.
On the negative side, a small regression error has crept in and 4k BASIC
will no longer run. This is not so bad because if you could run 8k BASIC
there's no reason to run 4k BASIC.
The next phase of the project will hopefully include some or all of the
following:
Continued code cleanup; minor fixes to IMSAI conditional
Further testing of the debugger (it's been only lightly tested with the
Altair32)
A set of Windows-based tools to manipulate diskette images (to enable people
to download programs from http://www.retroarchive.org and get them onto
diskettes)
Support for BBS software
Support for different floppy controllers/disk formats and maybe a
pseudo-floppy hard drive.
That's it for now. As always, you can check out the project at:
http://highgate.comm.sfu.ca/~rcini/classiccmp/Altair32.htm
Rich
Rich Cini
Collector of classic computers
Build Master for the Altair32 Emulation Project
Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/
/************************************************************/
On Dec 15, 12:28, Matthew Sell wrote:
> Typically, the time spent "in the water" isn't long enough to damage.
Even
> items made of steel and iron won't rust if the water is removed after the
> cycle is complete. If they sit overnight, well, that's a different story.
>
> The only production problem I saw with untreated water was with an
> electronic test instrument that had a lot of high-impedance signal
> interconnects throughout. Many signal lines ran for long distances next
to
> each other. While the design of this piece of test equipment was
> questionable, it was our duty to get it to work.
>
> The two biggest problems were contaminants from the water supply used in
> the washing process (city water - switched to using a commercial
filtration
> system), and humidity (had to paint a sealant on all of the boards).
That's a well-known problem. Some of the residues from a domestic water
supply -- especially in hard water areas -- are mildly hygroscopic, and as
a result, the boards would acquire very small amounts of moisture on the
surface, especially when exposed to a humid atmosphere. In combination
with the salts in the residue, this makes for leakage across the board,
which could easily upset very high impedance circuits.
I heard of someone who had the opposite problem. He designed a CMOS
circuit which worked fine when forst contructed, but stopped when given
anti-environment protection or was potted. He'd inadvertantly relied on
the normal leakage across a PCB to hold the unused inputs of a CMOS gate at
a particular level. Remove the leakage current and the gate stops working
properly. Solution: add the pullup resistor that should have been there in
the first place.
--
Pete Peter Turnbull
Network Manager
University of York
On Dec 15, 1:32, Matthew Sell wrote:
> Here's the secrets to doing this right:
>
> 1) Do not use any detergents. NONE.
Why not? Commercially, detergents are used to remove flux. I use
laboratory detergent to clean PCBs I've made or modified. I don't use
washing-up liquid, though, and I don't use the harsher detergents sometimes
found in dishwasher detergent.
--
Pete Peter Turnbull
Network Manager
University of York
On December 15, Jim Davis wrote:
> IMHO: All software development should be performed as such:
>
> 1) Requirements - what should it do, and not do. Spin this till
> everybody
> signs off.
> 2) Prelim design - Ok, a rough outline of the design, data structures
> and control/data flow defined here.
> 3) Detailed design - Define all the modules and their function, break it
> down.
> 4) Test plan - integrate testing into detailed design, make it unit
> testable.
> a unit is somthing that has input and output and side effects, like a
> function.
> 5) Finally, coding - build modules in parallel with test code.
> 6) Unit testing - verify that modules comply with detailed design.
> 7) Integration testing - hook it all together, make sure it works, apply
> test plan developed in step 4 for fully integrated aplication.
>
> Do 1-3 until marketing decides what they want,4-7 until you find no
> errors.
>
> For safety critical, you should /have to perform statement and decision
> coverage in
> step 6 and 7 and the detailed design should have a one-to-one
> corespondence
> with the detailed design document.
Hmm, that procedure "reads" nice, but it sounds like more meetings
than actual work. But then I've been a software developer for about
twelve years, and nobody that I've worked with can figure out how I
can blow off all the meetings and not get fired...it's because I end
up writing all the code that the rest of the developers are talking
about in their meetings, WHILE they're in their meetings, and by the
time they're doing screwing around, the code is running.
Procedures are nice, but they can be taken too far. Goal-orientation
is better.
(While I'll freely admit that this approach simply doesn't work for
multi-million line applications, I should state that I generally work
on applications of less than one million lines, but generally more
than 100,000. I further state that my methods should probably NOT be
used in life-critical applications...more than two eyes need to look
at that stuff, no matter what.)
-Dave
--
Dave McGuire
St. Petersburg, FL "Less talk. More synthohol." --Lt. Worf
On Sat 15 Dec 2001, Jeffrey S. Sharp wrote:
> There's a big difference between writing code to solve problems and being
> a software engineer. Designing, coding, and compiling is only 40% of the
> battle. Hopefully you're also spending some time planning and testing.
The company I work for seem to have forgotten the planning and testing part
of the software design process. We had a lot of embedded software written by
outside contractors for a 486 running QNX real time OS. Over the years the
software has evolved into the hardware equivalent of a rats nest and it's been
left to our customers to find the bugs - most being "show stoppers".
I sometimes wonder just how many customers we've lost because of this.
Also, dont get me wrong, the same should be applied to hardware design.
We recently interviewed an electronics engineering graduate who didn't know
the difference between NPN and PNP transistors !! What do they teach kids
these days ??
Should engineers be licensed ? - It's not a bad idea.
Chris Leyson
>X-Authentication-Warning: ns2.ezwind.net: majordom set sender to
>owner-classiccmp(a)classiccmp.org using -f
>X-Sender: cfandt(a)206.231.8.2
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
>Date: Thu, 13 Dec 2001 21:54:36 -0500
>To: <classiccmp(a)classiccmp.org>
>From: Christian Fandt <cfandt(a)netsync.net>
>Subject: Couple of items available . . .
>Sender: owner-classiccmp(a)classiccmp.org
>Reply-To: classiccmp(a)classiccmp.org
>
>I've got four Iomega Bournoulli Boxes, model A210H, if anybody wants them.
>I can maybe think of a few bits to swap for them but that doesn't matter. I
>just need the room (as several list members who've visited us can attest)
>and want them to go to a new home.
>
>I can ship but just reimburse me for the shipping cost and maybe purchase
>of a proper shipping carton or two as needed. Seem to weigh 15 to 20 lbs.
>each. Zip code 14701.
>
>Also, any interest in several IBM 3287 printers? Dot matrix 132 column page
>printers which use SNA network interface.
I have had a few questions asking (basically) what those Bournoulli Boxes
are. Please forgive me as I thought they were somewhat well known - but
that's probably because we used them all over the plant where I once worked
and I kinda got used to them. Plus, it's been a relatively long time since
they fell out use and younger folks of course wouldn't know much of them.
At any rate, they are a removeable media mass storage device which uses
what are essentially disk cartridges. Vintage '82-'85, I think. The media
inside its case, IIRC, is similar to an 8" floppy disk except encased in a
rigid plastic case. The cart is something like 8" wide, about 12" long and
about 5/8" or so thick.
These model A210H units have two 10 megabyte drives within a single
enclosure. It measures approximately 5 inches high, about 12 inches wide
and about 13-14 inches front-to-back.
The PC XT, AT and compatible host machines had installed within themselves
a proprietary ISA card with a cable from it to the Bournoulli Box. I know
I've got at least two of these cards tucked away somewhere but I need to
dig and hunt for them. They're packed away in one of the boxes from our
move to this house several years ago. I've got a software driver disk or
two around too. Same thing: where the h*** are they at the moment? But I
can find them with diligent hunting. We live on a 66' x 210' lot and they
can be eventually found :-)
Iomega's Bournoulli Boxes were great for use as backup of the contemporary
20-to-80 mb hard disks of that era. That is what these units had been used
for at my ex-employer along with their use as local data storage for daily
Customer Service and Field Service records. I rescued them when we cleaned
out an off site warehouse back in the mid 90's.
I've also got maybe a dozen or more of the cartridges, too, which I just found.
Yours for the taking too. Same conditions as previously stated (pay
shipping, help towards a shipping box if actually needed, etc.,
yadda-yadda-yadda).
Come and get 'em.
Thanks. -Chris
-- --
NNNN
Christian Fandt, Electronic/Electrical Historian
Jamestown, NY USA cfandt(a)netsync.net
Member of Antique Wireless Association
URL: http://www.antiquewireless.org/
On Dec 15, 15:47, Chad Fernandez wrote:
> So it's almost like cloth, but made of wire?
Yup, though the ferrite core rings mean the spacing between strands is
larger than in cloth woven from thread. And it's knitted. I was told the
other day that there are still two old ladies in the Midlands who can
repair some types of core by re-knitting it.
--
Pete Peter Turnbull
Network Manager
University of York
On December 13, Doc wrote:
> > Remember Linux too needs lots of memory. With >16 meg on a video card
> > your OS needs about 16x that. It is the video display that is the
> > killer.
>
> BZZZT!! Wrong.
>
> Linux *likes* lots of memory. I can show you X running on a 386SX with
> 12M and a 1M video card. Not just a demo; that's my friend's firewall.
A firewall with a video card? Gotta love them PCs. ;)
But yes, I agree...Linux can be made to work well on machines with
small quantities of memory. It's actually pretty good at it.
-Dave
--
Dave McGuire
St. Petersburg, FL
In a message dated 12/15/2001 7:18:46 PM Eastern Standard Time,
jhellige(a)earthlink.net writes:
<< >That is just right. Airc, IBM would'nt buy Intel's processor for the IBM
>PC unless Intel had multiple sources. This was to ensure supply to IBM if
>Intel's plants were overridden by bugs, damages by an infusion of dust (or
>aluminum powder.....;-)). AMD at least (and I think Seimens and NEC as
>well) was contracted to produce the 8088 cpu. AMD was given all info
>needed to clone the chips.
>
>This relationship continued through the 80286 and 80386 processors, but
>became very strained as AMD was making 386's cheaper and imho better than
>the intel products by modifying the Intel designs. Intel and AMD ended up
>in court over the 80486 chip ; intel claiming that the contract between it
>and AMD did not include information or production of this CPU. AMD was
>eventually forced to produce a 'clean room' 80486 design but because of
>the delays caused by the litigation they had plenty of time to do it.
AMD's faster coprocessors also caused quite a problem if I
remember correctly. Harris also pushed the 286 faster than any of
the other sources. I remember PC Magazine running an article
comparing various 286 machines with a headline that mimicked the
Corvair's 'Unsafe at any speed' headline. >>
I've always liked AMD stuff. My first PC I got myself was an AMD 386 dx40. I
couldnt decide whether to get a 486-25 and didnt quite understand the sx/dx
issue. Ran OS/2 great on 8 meg. Later, I found that the AMD 486 dx2/80 was
cheaper than Intel's 66 so I got that and never any problems with it.
--
Kwanzaa is NOT a real holiday.
Where were you a few years ago when I was looking
for a home for my Burroughs software & manuals (didn't
run across this list at the time though). After 10 years
or so programming these babies (L/TC/B80&90) I'd
accumulated pretty well every piece of firmware, utility
& app software there was, but then (as now) there wasn't
much interest in what most people (unfairly, in my biased
opinion) derided as "just" an accounting machine (you
haven't lived 'till you've played Lunar Lander with
a golfball printer...)
Unlike the mainframes, these machines were generally
sold outright & therefore scrapped outside of Burroughs,
so there were lots of them around.
Finally sold the hard disk carts to a rebuilder,
recycled the floppies & tossed the mylar tapes
& manuals.
HOWEVER, I do still have an electrical parts
catalogue from 1972, a little early for the B80,
but might have some of those chips from the
TC listed; if you're interested, send me a couple
of part numbers off list & I'll see if they're listed
and it's worth while scanning it for ya.
If size vs computing power were a criterion,
there wouldn't be very many old mainframes in
Sridhar's collection...
And yes, rugged indeed; extremely reliable, aside
>from the occasional head crash. Alas, many of
them were disembowelled & ended up as desks
or workbenches.
As mentioned elsewhere, I also still have a digital
cassette drive & tapes with who knows what on
them (for the L/TC's), as well as a TD700 flat-
screen display unit & controller for the B80, if
anybody's interested.
mike
----------------Original Message-----------------
Date: Fri, 14 Dec 2001 17:44:21 +0100
From: "Sipke de Wal" <sipke(a)wxs.nl>
Subject: Re: Burroughs - any information?
I did obtain about 5 TC5500 consoles and a B80
back in the '80.
They were rather large for their computing power
and no software was obtainable so I scrapped them.
I still have a couple of kilo's TTL-chips from them, with
their own Burroughs legacy partnumbers.
Very rugged design though!
Maybe you could get some old "B" hardeware but
software was out of the question.
Sipke de Wal
