I found two HP Pen Plotters in a closet at work. One is a 2 pen 7470, the
other is a 6 pen 7475.
There is also a bunch of pens (50) that still work..
I powered up the 7470 and it works from the front panel. The self test
prints an *.
I haven't tried the RS232 interface yet.
I don't have the manuals for these plotters. I do have a summary of the
switch setting and RS-232 pinout.
Does anyone want them? Does anyone have access to the manuals?
Michael Holley
www.swtpc.com/mholley
Does anyone have the "Application Selector" software
for the IBM 5140 Convertible computer?
It used to be on the IBM website for download, but no
longer.
Thanks-
Steve.
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
I'm cleaning out my basement, and I have a few semiconductor
books I would like to dispose of:
Analog Devices, Data Converter Reference Manual, Vol I & II, 1992
Motorola Silicon Rectifier Manual, 1980
Hitachi ECL logic and Memory Data Book, Year Unknown
Precision Monolithics Linear and Conversion Products, 1984
Intersil Semiconductor databook, mid-1980's (has a section for the
IM6100)
Analog Devices, Special Linear Reference Manual, 1992
Harris, Analog and Telecomm Product Data book, 1984
Motorola Power Mosfet Transistor Data, 1984
Motorola Semiconductor, Master Selection Guide and Catalog. 1984
I will favor offers for the entire lot; plus book rate postage.
Thank you for your attention . . . ..
Jeff
________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
On Aug 19 2004, 11:10, Jules Richardson wrote:
>
> Hmm, my first ever floptical drive just landed on the doorstep
amongst a
> pile of hardware. Never seen one before now, and it seems there's
very
> little info on the web about the technology.
>
> I assume that although it'll (probably) read/write normal 3.5" floppy
> disks, it needs special media to reach the 21MB that I keep on seeing
> quoted in various places? (i.e. it can't reach that figure combining
the
> optical tracking technology that it uses with standard magnetic
media)
>
> (the drive's an Insite I 325VM, likely culled from an SGI I think)
Yes, it will read normal 3.5" floppies (at least HD and possibly DD),
and yes it needs special floptical media to do 20MB. Good luck finding
the media. I have some but I'm keeping it for my flopticals.
Do keep the drive clean. My experience is that they're vey prone to
dying (and trashing disks) if they get too dusty.
--
Pete Peter Turnbull
Network Manager
University of York
Hello ClassicCmp friends,
Right now as I type this an interview is in progress on the
Coast to Coast AM late night radio talk show about a supposed
time traveler who went back from 2036 to 1975 to obtain a
classic computer, specifically IBM 5100. Needless to say,
this story got me highly intrigued.
Since I don't really know anything about the machine in question,
I thought I would ask the collective list wisdom. There must have
been something really special about IBM 5100 for them to go back
for it from 2036. Does anyone know anything about that machine?
MS
meltie <lists(a)microvax.org> wrote:
> Failing that, has anybody taken an image of the ROMs in an IS100/150 - i'd
> quite like to try making a uVAX3100 think it's an Infoserver...
To my knowledge there are no special ROMs in an InfoServer other than
the standard MV3100 console ROM, and it's what lives on its boot disk
that makes it an InfoServer.
MS
> I beg to differ on opinions on e-mail quoting. I really dislike having to
> scroll past all of the stuff I have already read, or even scan through a
> mix of old and new.
That's one of the reasons I like threaded message boards better then email
lists.
Sure, the information isn't "delivered to your door" but you can follow a
thread from A to B easily, ignore threads you don't care about completely
and figure out what the latest additions are very quickly.
Of course, there's the possibility of the same types of issues you see
here with excessive quoting and such, but it seems a lot less prevalent on
boards I frequent.
Erik Klein
www.vintage-computer.comwww.vintage-computer.com/vcforum
The Vintage Computer Forum
I'm not sure this one's been reported before, but I'm watching This is
Spinal Tap, and in a short scene where the band is on a tour bus the
keyboardist is playing a Missle Command like game on an original TRS-80
Color Computer :)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
Hi,
I don't normally post such things to mailing lists, but this looks
like a nice bit of kit. It's very near me but there's no way I
could get it in the house :-(
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&category=1247&item=51165939…
--
Cheers,
Stan Barr stanb(a)dial.pipex.com
The future was never like this!
my experience has been...
1% of the people really like science
1% don't mind listening to science and can actually learn something
1% will listen but retain nothing
now for the gender split...
50% of the males in the remaining 97% are thinking about what the are going to eat for dinner and the remaining 50% are wondering who they are going to sleep with next
50% of the females in the remaining 97% are thinking about their makeup and the remaining 50% are trying to reduce, change, enlarge their physical appearance.
best regards, Steve Thatcher
your best bet is to find the entire Atari power supply chassis assembly
with the transformer, and the power supply pcb that goes along with it.
they show up on eBay, or you can try Scott Evans (thomas43(a)aol.com) who
should have a set.
d
In case anyone's interested, I've just listed a Morrow Micro Decision
at the VCM:
http://marketplace.vintage.org/view.cfm?ad=1121
Thank you for your attention . . . .
Jeff
________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
Looking for diagnosis or URL with troubleshooting guide:
TRS 80 Model III with two mini drives.
Powers up, drives spin and do not stop.
Does not attempt read, no red drive light.
Cass? and Memory Size? Ok
Basic prompt OK.
Type in and Run basic progam OK
Did not test loading program from tape.
Never opened (until yesterday).
Seeking help. I have sme experince with basic board work/IC replacem.
Could it be U40 or U41? "upper" RAM?
Thanks!
Bill
vintagecomputer.net (coming soon)
I have
-- E N D --
I received a note from a gentleman in Horseheads, New York,
with the following equipment he'd like to dispose of:
>(1) HP 286/12 ... working
>(1) 486 Leading Edge ... working
>(1) 486 ? ... working
>(1) Dot Matrix printer ... working
Send me an e-mail off-list if you're interested and I'll forward
his contact information.
Cheers,
Dan
On Aug 18 2004, 9:05, Stan Barr wrote:
> I built a 1-transistor regenerative reflex receiver back in the
> late '60s. I used a OC170 transistor salvaged from a scrap Ferranti
> computer board, which keeps it on-topic I suppose :-)
>
> I wish I'd kept the board now...probably an Atlas one :-(
I wish I'd kept the Ferranti ones I had -- lovely PCBs with alloy
surrounds, carefully wirewrapped. They were TSR2 avionics.
--
Pete Peter Turnbull
Network Manager
University of York
Bob asks about row/column based database software.
+ADw-snip+AD4-
Lots of mainframe database software existed but it was expensive and
took lots of CPU power and disk space. From my experience it all
depended if you purchased software or wrote your own.
At the University of Missouri in 1976 we made a database of food
poisoning victims.
I used one punch card for each patient which was one row.
Each column on the card was for each symptom or food consumed.
Columns 1-16 was usually last name
Column 17 might be Saturday morning vomiting
Column 18 might be Saturday afternoon vomiting
Column 19 might be Saturday evening vomiting
Column 20 might be Saturday morning diarrhea
Column 21 might be Saturday afternoon diarrhea
Column 22 might be Saturday evening diarrhea
Column 23 might be Saturday morning beer
Column 24 might be Saturday afternoon beer
Column 25 might be Saturday evening beer
We would usually look at a 3 day interval.
It usually takes 18 hours for food poisoning symptoms to start.
Some people are +ACI-immune/tough+ACI- and don't get sick.
Some people have symptoms from other sources+ADs- beer, other foods
If you listed a data deck of cards then row columns were how the data
was listed. We looked to trends and correlations. On one outbreak the
highest correlation was the potato chips but the chicken salad was the
actual cause. We used to get a lot of false positives for vomiting due
to the amount of beer consumed by students.
We also used SPSS on IBM 370/168 to analyze data also printed 2 X 2
tables of cross-correlations. The data was punched on an IBM 026 card
punch, later we got a 029.
We moved the analysis into FORTRAN programs on PDP-11/20 using DOS.
Later in 1979 I used BMDP and Datatrieve on a PDP-11/35 to computer
percentages of bacteria that consumed certain sugars.
The table looked like
S L M C
U A A A
C C N S
R T I I
O O T N
S S O E
E E L
e.coli 75 5 5 10
s.aureus 5 1 1 95
P.aeruginose 10 50 50 1
The PDP-11/35 was later upgraded to a PDP-11/70. BMDP required overlays
and lots of common areas to fit in the limited memory we had. We had
320K words of memory for 6 users, the RSX-11M OS and all external device
pages. All of our data was on RK05's. The system was on one RK05, the
programs on another, one for scratch and another for data. We changed
the data packs a lot to load more data. Our first RP04 was setup by us
to look like lots of RK05's since we stored data and analyzed in those
increments. For the clinical machines the data was stored in a PROM
board on a PDP-11/04 that analyzed bacterial growth and identified the
bacteria. If I remember correctly the table was about 30 rows by 26
columns.
Minicomputers were an attempt to move out of the computer center. We
weren't really classed as computer programmers but R+ACY-D engineers. We
stored lots of data in RAD50 and bit flags to save space.
>From: "Vintage Computer Festival" <vcf(a)siconic.com>
>
>On Wed, 18 Aug 2004, Patrick Finnegan wrote:
>
>> Anyhow, on discussion groups like this one, "conversations" over email
>> (exchanging email about a topic) is what the mailing list is all
>> about... It sucks when you end up seeing something 1/2 way through the
>> thread and can't determine what the people were talking about anymore,
>> from people either top-posting or deleting useful quoted info.
>
>I wouldn't mind as much if they would learn to TRIM THEIR REPLIES!!!
>
Trim replies and change subject when appropriate.
I'm guilty of failing to do both at times but I'll
try to do better.
Dwight
thanks and kudoos to Dwight and Dave for lightening a stressful day at work. To have taken my rather terse comment and created such wonderful content is what life is all about. LOL
best regards, Steve
now my only problem is whether I should leave the rest of the email or snip it off... sigh
-----Original Message-----
From: "David V. Corbin" <dvcorbin(a)optonline.net>
Sent: Aug 18, 2004 12:41 PM
To: "'Dwight K. Elvey'" <dwight.elvey(a)amd.com>,
"'General Discussion: On-Topic and Off-Topic Posts'" <cctalk(a)classiccmp.org>
Subject: RE: E-Mail Quoting...
I believe that Steves Last Comment (that being the last comment that I
received before any comments that he may have sent that I don't believe you
to have read at the time you sent the message that I am responding to and
you will soon (hopefully) be reading).
It would be a personal insult to Steve to NOT believe that he was sincere an
honest in that comment. Although the one prior to it (in the same message),
which has previously generated feedback from me (oh should I include that
too) may be taken in a number of ways, as I have previously done.
Additionally the interveneing comments by other members have an impact also
(although I am not sure what it is), but if you mook solely at the messages
that were sent in the interval between Patricks first post on this subject
and Hans first response you will see that Dave Dunfield has been tring to
focus on his own issue (which Wayne has of course been helping on).
I do suspect that Wayne may hve just been lurking since himing in in on the
other issue, which I wonder if the original poster ever got an answer that
he can use for hist original purpose..It would be interesting if the 94
responses (subjed to the one by Wayne mentioned above) did not provide such
an answer.
Or is it really not suprising since that is difficult to determine using
this technology....
David.
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Dwight K. Elvey
>>> Sent: Wednesday, August 18, 2004 12:15 PM
>>> To: cctalk(a)classiccmp.org
>>> Subject: Re: E-Mail Quoting...
>>>
>>> >From: "Steve Thatcher" <melamy(a)earthlink.net>
>>>
>>> Hi Steve
>>> You make several good points but I find your last
>>> statement without foundation.
>>> I tend to agree.
>>> Dwight
>>>
>>>
>From: "Steve Thatcher" <melamy(a)earthlink.net>
Hi Steve
You make several good points but I find your last
statement without foundation.
I tend to agree.
Dwight
>It's a 5 pin DIN socket, to an RJ11 + lead with a single large pin with a
>slot in it.
>
>I /think/ it was for a Wyse AT computer to allow the use of a standard PC
>AT Keyboard, but don't quote me on that.
You are correct, that is what the adaptor is for. Or at least it looks
just like the one I had for that purpose. I'm not sure if I still have
mine or not (I no longer have the Wyse PC it went with)
I have a crappy diagram and pinout to make one of these:
<http://www.mythtech.net/WyseKey.gif>
-chris
<http://www.mythtech.net>
Antonio Carlini <a.carlini(a)ntlworld.com> wrote:
> I have the following:
> EK-TUA81-TM-002 TU81/TA81 Technical Manual
> EK-TUA81-UG-004 TU81/TA81 and TU81 PLUS Subsystem User's Guide
> which both show up on http://vt100.net/manx, but
> without any links.
>
> If you think they'll be useful, I'll put them on
> an FTP site for you (and Paul I guess :-)).
When I finally get to play with my TU81E, I'm sure I will find them
useful! My drive is known good, but still having manuals is very
valuable just in case. Please put them up for all of us!
MS
>> According to the maintenance manual, line 1 cols 1 and 2 should
>contain the ID of the module it is looking for (18) and > 5 and 7
>contain an error code (07).
>>
>> I have not been able to determine what '07' means ... Perhaps its in
>the manual, but I have not found it yet. (Please > > bear with me, I
>haven't seen a real live 5100 in aver 20 years, and I have never worked
>on one before).
>
>My 5100 maintenance manual is buried, but my 5110 manual says that error
>"07" is a CRC error in the ROS. I have notes diagnosing a similar
>problem indicating that one possible solution is to remove any tape in
>the tape drive before powering on. Seems unlikely that this would work,
>but you never know.
Hi Wayne,
Where exactly in the maintenance manual are the codes listed - I did not
find them when I looked.
Although the machine was stored with a tape in the drive (keep mice out),
I had already removed it before my tests.--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
Item 5116593901
Very impressive. Look like a F series in dual bay rack, lots and lots of
memory (HSFCA at that!), and a 7925 disc drive that looks to be mint.
My trailer would have no problem driving to the UK *GRIN*
J
> Date: Mon, 16 Aug 2004 18:08:17 -0400
> From: Dave Dunfield <dave04a(a)dunfield.com>
> Subject: Help with IBM 5100 - ROS error
> To: cctalk(a)classiccmp.org
> Message-ID:
> <20040816220816.XZGR13092.berlinr.sprint.ca(a)smtp.sprint.ca>
> Content-Type: text/plain; charset="us-ascii"
>
> According to the maintenance manual, line 1 cols 1 and 2 should
contain the ID of the module it is looking for (18) and > 5 and 7
contain an error code (07).
>
> I have not been able to determine what '07' means ... Perhaps its in
the manual, but I have not found it yet. (Please > > bear with me, I
haven't seen a real live 5100 in aver 20 years, and I have never worked
on one before).
My 5100 maintenance manual is buried, but my 5110 manual says that error
"07" is a CRC error in the ROS. I have notes diagnosing a similar
problem indicating that one possible solution is to remove any tape in
the tape drive before powering on. Seems unlikely that this would work,
but you never know.
-W
>From: "Geoffrey Thomas" <geoffreythomas(a)onetel.com>
>
>Just remembered - it was the "spontaflex" ,- it was Sir Douglas Hall and
>there is a web page devoted to his circuits.
>Geoff.
>
Hi
A quick search shows that these are at:
http://freespace.virgin.net/spontaflex.reflex/
From looking at some of the text, these are a combination
of a reflex with some regenerative feedback to increase the
Q of the tuning circuits.
I suppose one could write programs to sing through such
a receiver on their clasic computer.
Later
Dwight
Hi,
I'm looking for a Technical Reference manual / schematics for a TRS-80
Model III and the Holmes VID-80 add-on board.
I've found a fair amount on the model I and 4 via Google however there
seems to be nothing on the Model III.
-Neil
I have picked up one of these ATC 510 also ... I have full set of docs for it, all maintenance books and tapes ... I don't recall seeing any charts for it .. but I have not got into all the boxes ... I would love to talk sims or real aviation some time . More than glad to share what I have ,I got this sim given to me from a school that wanted rid of it ... they say it does not work ... if fly's wrong .. but I am pretty sure that I can get it going ... I love to fart around with stuff like that, jeeps me out of trouble.
Anyway drop me line if you like
Mark Jones
MSN messenger - clubwood(a)hotmail.com
>I've got a monochrome NEC APC (dual 8" floppies) that
>I was going to eBay, but it hovers right at that magic
>70lb rate which seems to hit all kinds of shipping
>issues with USPS (won't deliver it), UPS (big $$$
>surcharge), & FedEx (only deliver to a business
>address, $$$). Seems by the time you factor in ship
>costs it wouldn't be worth it unless someone was
>really desperate.
Fedex ground ships to home addresses you know. Price isnt too bad. You could
also try Airborne/DHL or Emery/Menlo worldwide for ideas also.
--
I am not willing to give up my liberties for the appearance of 'security'
(I sent this from the wrong email address last night...oops!)
So, I was hoping to find some sort of manual (any kind) for my TU-81+
via google, but have failed.
So, my TU-81+ doesn't want to power up. I've found the "hidden" power
switch under the cover that I've flipped back and forth a couple of
times, I've made sure the 110/220V jumper was set properly (110V), and
tried different power cords, all to no avail. (I've bypassed the power
controller in the rack and directly hooked the drive to an outlet.)
The power supply "sounds" like it's getting some power when I plug it
in, as I hear a small arc, presumably charging up some capacitors.
However, the fan doesn't start up, and none of the front panel lights.
Does anyone have any suggestions of where to go next? (Tony? :) I
could just start pulling it apart and going through it, but I prefer to
have some direction before I do that.
Pat
--
Purdue University ITAP/RCS --- http://www.itap.purdue.edu/rcs/
The Computer Refuge --- http://computer-refuge.org
Hi
Reading the article by Sir Douglas Hall, he mentions
making an adjustment to keep the positive feedback below
the point of oscillation. This sure sounds like regenerative
to me. Regenerative feedback was used quite often to
increase the effective Q of circuits to increase selectivity.
The article of May 1976 seems to indicate that this is how
this circuit works. This makes sense. There are many, many
ways to introduce regenerative feedback. One of the
early ones was to place a variable coil in the plate
circuit that was not coupled to the tuned input. The
circuit worked by the parasitic capacitance of the triodes
grid to plate. This can be done with a transistor as well.
I remember when I was a kid, I had one of those 2 transistor
reflex receivers made by GE ( wish I still had it ). I
modified it to be regenerative and was able to greatly
extend both range and selectivity. At night, I pulled in
stations across the US.
Dwight
>From: "John Honniball" <coredump(a)gifford.co.uk>
>
>Geoffrey Thomas wrote:
>> Yes, thanks - but the author had a special name for it - that's what I can't
>> remember.
>
>Was it "regenerative"? Or is that a different type of circuit
>altogether? See, for example:
>
> http://www.electronics-tutorials.com/receivers/regen-radio-receiver.htm
>
>--
>John Honniball
>coredump(a)gifford.co.uk
>
The TU81 diag pathfinder and tech manuals are up now on
www.bitsavers.org/pdf/dec/magtape/tu78
The drive itself is an OEMed CDC Keystone, there are some docs
for it under cdc/magtape.
>From: "ben franchuk" <bfranchuk(a)jetnet.ab.ca>
>
>Geoffrey Thomas wrote:
>> Reminds me of the old Radio Constructor designs where the designer made one
>> transistor do both rf and af amplification.
>> Can't remember his name - or what he called his designs.
>> I'm sure he was knighted or something like that .... anybody ?
>> - Sir Alec Douglas Hall ? was it ?
>> Sounds too much like Alec Douglas Hume !
>
>I have no idea who invented it since it was used every where, since the
>humble
>vacume tube ( valve) was invented. You can still buy or build them today.
>
>http://www.vcomp.co.uk/one_tube_1935/one_tube_1935.htm
>http://schmarder.com/radios/tube/index.htm
>Ben.
>
>
Hi
The circuit is called a reflex circuit. The second web page
above shows a tube reflex circuit.
Dwight
Hey Chuck what would one of these things be worth. If it was in great operating condition? Where would a guy find out. MonroeMatic help
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Contact me off-list for this gentleman's e-mail address
if you have an interest in these Commodore computers
and software. He's located in St. Joseph, Michigan
(United States), which is in the southwest part of the state.
>We have Commodore Computer 64 & 128 systems and software. These were used
>in my wife's Special Education class room. We would like to find a new
>home(s) for this equipment and their educational software.
Cheers,
Dan
Aslo....
I just measured my average distance to the screen 26-28 inches. Readability
begins to suffer at about 7pt text.
David
-----Original Message-----
From: David V. Corbin [mailto:dvcorbin@optonline.net]
Sent: Tuesday, August 17, 2004 4:01 PM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: <Silly> RE: Help with question about web page access
If I use "blah" Notepad to open a text file at the default font size of 10pt
I see 106 lines of text. This is slightly less than one might calculate
because you need to subtract the taskbard,frames and other things...
This is being displayed in a physical vertical area of just over 10.5
inches, to the text is being displayed nearly ACTUAL SIZE. Holding up a
piece of printed paper I get about 4 lines of drift over the vertical
distance.
Considering that most printed material [eg. Paperback books and newspapers]
will use a smaller font...I don't see why ther is any surprise about working
at this resolution.....
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Patrick Finnegan
>>> Sent: Tuesday, August 17, 2004 3:40 PM
>>> To: General Discussion: On-Topic and Off-Topic Posts
>>> Subject: Re: <Silly> RE: Help with question about web page access
>>>
>>> On Tuesday 17 August 2004 14:33, David V. Corbin wrote:
>>> > 2048x1536 (with is 4 1024x768 areas on the same glass) is
>>> what I use
>>> > on some of my 21"/22" monitors.
>>>
>>> Ick. I don't do anything higher than about 1280x1024 on a 20"
>>> monitor, and I usually am sitting no more than 16" back from it. At
>>> 1600x1200, even on "good" monitors, I can't see things anymore. My
>>> rule of thumb is you should be able to see the individual dots in a
>>> grid of 1x1 pixel dots (but they shouldn't be too big).
>>>
>>> > 1600x1200 [not 1280 which you may be confusing with
>>> 1280x1204] is what
>>> > I run on my 17" screens.
>>>
>>> You must have 20-10 vision or something, because no human should be
>>> able to see 1x1 pixel dots on something with that high of DPI.
>>>
>>> Pat
>>> --
>>> Purdue University ITAP/RCS ---
>>> http://www.itap.purdue.edu/rcs/
>>> The Computer Refuge --- http://computer-refuge.org
At 11:23 AM 8/17/2004, you wrote:
> >>> Subject: Re: Help with question about web page access
> >>>
> >>> At 10:49 AM 8/17/2004, you wrote:
> >>> >WHY DOES SOMEBODY HAS TO SLAP A TINY TINY UNREADABLE FONT
> >>> IN MY FACE?
> >>>
> >>> It takes less bandwidth and server space.
> >>>
>Um...NO...not at all....
Well certainly then because of reduced X radiation from the CRT.
The smaller fonts disturb less phosphor.
You'd probably get increased life from your CRT also in that case.
Ed
At 01:26 PM 8/17/2004, you wrote:
>But you are assuming that radiation is bad.....How else would I get this
>good amber tan [with a slightly green tint]???/
Bypass your microwave door safety switches?
It's worth pointing out that Jerome is talking about 132 character access in
text-mode, not within the GUI.
I used to have a Tseng Labs card that supported all sorts of great text mode
resolutions.
Just for your information Jerome, if you were to go down the Linux route text
mode console is fully supported in 132 character mode with a variety of line
options. You could also plug in a VT terminal such as a VT520 and have a
'real' terminal to program from.
Regards,
Mark. (who has shunned using a laptop in the louge at home for a VT520 - it
focusses the mind on what is really important and stops endless 'browsing'.
I'm not addicted to the internet, honest!)
--
Mark Wickens
Rhodium Consulting Ltd
Sir, earlier this year you posted a question as to whether anyone had a
non-dec Hawley mouse for sale. I have an X063X, is that what you are
looking for or are you after something else?
Daniel Goldgrabe
Component Engineer
Isothermal Systems Research
2218 N. Molter Rd
Liberty Lake, WA 99019
PH: (509) 232-3442 Fax: (509) 444-1082
email: dgoldgrabe(a)spraycool.com
just a thought, remove the two 8" drives and ship them separately. It will also make the system a little less prone to internal breakup when the shipper keeps dropping it on a corner...
best regards, Steve Thatcher
-----Original Message-----
From: Rich Bramante <rich_bramante(a)yahoo.com>
Sent: Aug 16, 2004 9:55 PM
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org>
Subject: Re: Anyone ever shipped an NEC APC?
--- Vintage Computer Festival <vcf(a)siconic.com> wrote:
> On Mon, 16 Aug 2004, Rich Bramante wrote:
>
> > I've got a monochrome NEC APC (dual 8" floppies) that
> > I was going to eBay, but it hovers right at that magic
> > 70lb rate which seems to hit all kinds of shipping
> > issues with USPS (won't deliver it), UPS (big $$$
> > surcharge), & FedEx (only deliver to a business
> > address, $$$). Seems by the time you factor in ship
> > costs it wouldn't be worth it unless someone was
> > really desperate.
> >
> > Anyone ever sold-shipped one of these before, and are
> > my concerns founded?
>
> I just had a package shipped to me which, according to Fedex, weighed 75
> pounds. I had the sender use one of my pre-paid shipping labels. No
> problems. Perhaps the pre-paid label helped. It only cost $39 according
> to the breakdown. This was from Texas to California.
Yes, 75lbs is about what I am guessing once the box and packing materials is
added in. I assume you had it shipped to your business address, so Fedex
wouldn't beef about the weight.
> > On a tangent, anyone in the Boston area interested in
> > one of these that can pickup? If so drop me an email
> > for machine details and maybe we can work something
> > out.
>
> What model is it?
It is an APC I (APC-H01 Basic Monochrome APC) the big honkin' unibody with the
dual 8" floppies. I also have a very clean APC III which I am loathe to part
with, but could make it available for a really good offer ;-) I am trying to
sell alot of what I currently have and just concentrate on a small subset of
systems. The old time/space argument.
rich
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
I've got a monochrome NEC APC (dual 8" floppies) that
I was going to eBay, but it hovers right at that magic
70lb rate which seems to hit all kinds of shipping
issues with USPS (won't deliver it), UPS (big $$$
surcharge), & FedEx (only deliver to a business
address, $$$). Seems by the time you factor in ship
costs it wouldn't be worth it unless someone was
really desperate.
Anyone ever sold-shipped one of these before, and are
my concerns founded?
On a tangent, anyone in the Boston area interested in
one of these that can pickup? If so drop me an email
for machine details and maybe we can work something
out.
rich
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
>>> Question for list members.... what's the oldest functioning
>>> PDP computer that anyone out there has, to your knowledge?
The Computer History Museum's PDP-1
http://pdp-1.org/
Hi
I saw in a forum your discusion about reading Brother wordprocessor
floppy disks and am in the same situation, could you forward the tool
spoen about on the forum please?
does the software only convert the file, or does it allow you to read the
disk on a pc?
thanks
Tim
Don Maslin donm at cts.com
Wed Mar 3 16:05:07 CST 2004
Previous message: Brother Wordprocessor Floppy Disks
Next message: Brother Wordprocessor Floppy Disks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 3 Mar 2004, tim lindner wrote:
> Yesterday my boss came to me and handed me a stack of 3 1/2 inch floppy
> disks and asked me to get the data off them.
>
> Ahh, the perils of being the geekiest person in your orginazation! :)
>
> Anyway, all he could tell me is that they were from a Brother word
> processor. It didn't have a model number and no serial port.
>
> One of the disks is a system disk ("Spreadsheet, punctualtion alert and
> data storage disk for Brother Word Processor version <1.0>") and is
> dated 1991.
>
> I tried the disk in my DOS 6.22 PC, no deal.
>
> Then I tried cw2dmk (thanks Tim!) and my Catweasel, but I guess the
> format isn't close enough to IBM 370 (FM) or IBM 34 (MFM) formats to be
> useful.
>
> Does anyone know of a tool I can use to read these disks?
Tim, the attached ZIP contains software that was sent to me a
while back which is supposed to convert Brother Word Processor
stuff to other - perhaps, more common - WP formats. I have not
had occasion to try it, so will be interested in your experience.
It will not make it to the list, of course, thanks to the
attachment 'scraper'.
- don
> Barring that: does anybody know what format the disk is using? I'm not
> past modifying cw2dmk to read it, but I would hope not to have to
> reverse engineer the "on disk" format.
>
> Thanks!
>
> --
> tim lindner
> tlindner at ix.netcom.com
>
Timothy Baillie
ACUweb Online Education, ACU National
T +61 7 3623 7425 F +61 7 3623 7193
PO Box 456 Virginia Qld 4014, Australia
http://www.acuweb.com.au/
>From: "Pete Turnbull" <pete(a)dunnington.u-net.com>
>
>On Aug 13 2004, 11:27, Dwight K. Elvey wrote:
>
>> You should try to create a more exhaustive RAM test.
>> Although, time consuming, GALPAT is just about the
>> most intensive.
>
>I know Dave doesn't need it now, but a GALPAT is a very slow test for
>any sizeable amount of RAM. It's also very old, and not 100% effective
>against certain errors, though much better than some of the common
>march tests.
Hi
There are many kinds of test. The simplest effective
test for stuck-at and address problems is the March C.
It lacks many possible problems that are not simple stuck
at. Worst case column test require various types of walks
( GALPAT is one of these ). Still, most simple RAM test
Used by POSTs will do about as well as a March C. Now
we get into some of the other problems of address line
switching, retention and pattern problems.
One need not include the entire memory in there GALPAT
test. One can work in blocks and then work on a block to block
sampling. It is a long test but then it does a lot of
things that take a long time.
I only suggested it because it seemed that he had an
issue that a simple RAM test wasn't showing.
I am involved with creating BIST engines for use on
arrays in uP's I would never put a GALPAT in a production
test but if I can get two address generators, it is
easy to implement as a programmable element. It, along
with other test, can often be used for diagnostic operations
to help understand a fault until a simpler/quicker test
can be used to detect that particular fault.
Dwight
On Aug 14 2004, 11:11, Vintage Computer Festival wrote:
> On Sat, 14 Aug 2004, Pete Turnbull wrote:
>
> > registers), though it would on a 6502. If anyone wants a copy I
can
> > give you the Z80 code, some notes from the project writeup, and the
> > CACM references.
>
> Please!
OK, it's below. First I ought to explain a couple of things about the
code and the system it was written for. This was for a very basic Z80
system consisting of some EPROM, RAM, timers, and minimal I/O, which
included a 2-line x 16-char LCD display. It was used for second-year
project work.
The way the LCD display was interfaced precluded the use of normal
hanshaking or reading, so the routines that write to it incorporate a
delay long enough to ensure that the display has completed the update
before another write can occur.
Secondly, the whole system was designed to report any error (and refuse
to continue if it was serious), and to do this, the startup routines
perform a number of tests, each of which uses no part of the hardware
that's not already been passed "good". Well, that's the ideal; it's
not so simple in practice. It begins with a ROM CRC check (and it's a
proper CRC, not a simple checksum, so it will catch all single-bit
errors, most 2-bit errors, and many multiple-bit errors). It should
really do a CPU test first, but that would need the ROM to hold the
test routines. The justification here is that it uses nothing except
the processor and the ROM itself, and the assumption is that any
serious fault in the processor will cause that to fail. If so, it's
easy to take out the ROM, CRC check it on an EPROM programmer, and tell
whether the ROM really is at fault -- if not, it must be the CPU. The
chances of a CPU failing are quite small; the chances that a failing
CPU will still execute instructions are a fraction of that; the chances
that a CPU with faulty instructions will still execute the CRC test are
a fraction of that; the chances that a faulty CPU that still passes the
CRC has faults in common instructions used elsewhere are ... etc.
So at the point that the RAM test executes, we "know" the CPU is OK and
we know the ROM is OK, but we don't want to use the RAM to hold data
during the RAM test. So no variables other than in registers, and *no
stack* hence no subroutines. Hence the rather odd way of executing
pseudo-subroutines to display things (on the LCD which we assume is
working; it's just been "exhaustively tested" by the visual test of
seeing a "ROM CRC ERROR" or "ROM CRC PASSED" message, followed by "RAM
test" on it :-)).
Lastly, this test does everything one bit at a time, not one byte at a
time. That's because the system used byte-wide RAM, in which in theory
any bit could interact with any other. You could safely parallelise
this to do a byte at a time if you used a separate RAM chip for each
bit (because you could assume they wouldn't interact except through a
faulty data bus or power glitches) and that would speed it up more than
8 times.
Here's the code:
# Filename: RAMtest.s
#
# Author: Pete Turnbull
# Address: Department of Computer Science, University of York,
# Heslington, YORK YO10 5DD.
# Email: pnt1(a)york.ac.uk
#
# Created: 26-Nov-1995
# Last update: 18-Nov-1996
# Description: An efficient RAM test
# Version: 0.4 now uses 20-bit error-counter
# 0.3 modified to work as standalone test for CTS
19-Oct-1996
# 0.2 code converted from ZASM to as80 for MCP, March
1996
# 0.1 original module for inclusion in CTS 1995, coded in
ZASM
#
# **************************************************************************
# *
# * An implementation of Suk and Reddy's Test B RAM testing procedure.
# * Implemented from information in an article "Functional Testing of
# * Semiconductor Random Access Memories", M.S.Abadir and H.K.Reghbati,
# * Computing Surveys, Vol.15 No.3 September 1983, ACM.
# * The original NTA article is "Efficient Algorithms for testing
# * Semiconductor Random Access Memories", Nair, Thatte and Abraham,
IEEE
# * Transactions on Computing, Vol.C-27, No.6, June 1978.
# * A similar fault model was used by D.S.Suk and S.M.Reddy, to develop
even
# * better tests, including their Test B, described in "A march test
for
# * functional faults in semiconductor random access memories", IEEE
# * Transactions on Computing, Vol.C-30, No.12, Dec 1981.
# * This is an O(n) procedure, much more efficient for large memories
than
# * GALPAT. It also finds coupling faults invisible to GALPAT tests.
# *
# * GALPAT complexity 4n^2 + 2n, finds all stuck-at, and some coupling
faults
# * GALPAT-II 4n^2 + 4n, finds all stuck-at, and all coupling
faults
# * T&A 8n.lg(n), finds all stuck-at, and all coupling
faults
# * NTA 30n, finds all stuck-at, and all coupling
faults
# * S&R-B 16n, finds all stuck-at, and all coupling
faults
# * assuming no decoder multiple-access
faults,
# * and all decoder faults if no coupling
faults.
# *
# * The proviso about coupling/decoder faults really just means that
the two
# * types of fault are seen as equivalent (indistinguishable) by the
test,
# * not that they are not detected.
# *
# * There are even faster tests than S&R-B but they don't necessarily
find
# * all errors (some errors may mask others).
# * With our Z80 running at 3.6864MHz, this test takes about 6 seconds.
# * From the formulae above, an "equivalent" GALPAT would take over an
hour.
# *
# * Byte operations would be acceptable for 1-bit wide memories, merely
# * being an application of parallel testing. However, our RAM is
8-bit, so
# * we use multiple operations to access each bit in a byte. This is
not
# * quite according to the test specification, as the lower bits in
each
# * byte are read/written up to 21 more times than they should be.
# * However, if the RAM is OK, correct values are written every time,
and
# * consideration of the fault model shows that this will only affect
soft
# * errors, which, by definition, are likely to be corrected by other
# * operations in the test procedure and would not be detected by most
test
# * algorithms.
# * If we just used byte operations, we might miss some coupling
faults.
# *
# * Errors are reported on the LCD, using in-line code (no subroutine
stack),
# * in the form "aaaa:xx (yy) -pp" where "aaaa" is the address with the
error,
# * "xx" is the found data, "yy" is the expected data, and "pp" is the
section
# * number (1A, 1B, 1C, 2, 3 or 4). DE holds an error count,
supplemented by
# * H to use 20 bits so that multiples of 8*8192 errors (eg every bit
in every
# * byte of 8K) can be recorded.
# *
# * The test always runs to completion, but then displays the error
count and
# * HALTs if it's non-zero. If it is zero, this version prints the
message
# * "RAM OK " and halts.
# *
# **************************************************************************
#
#
# ***** Memory addresses *****
#
rom = 0 # start of 8KB EPROM area
romtop = 0x1FFF # last byte in ROM
ram = 0x4000 # start of 8KB RAM area
ramsize = 8192 # size of RAM
ramtop = ram+ramsize-1 # last address in RAM
#
#
# ***** I/O addresses *****
#
LCDins = 0x80 # LCD base address, instruction
register
LCDdat = LCDins+1 # LCD data register
#
#
# ***** assorted constants *****
#
LCinit = 0x3C # LCD "Funct.Set": 8 bit data, 2 lines
LCDoff = 0x08 # set off: OR this with D/C/B for ON
Don = 4 # sets Display ON
LCDon = LCDoff + Don # set on: OR this with C/B for cursor
Con = 2 # sets Cursor ON
Bon = 1 # sets Blink ON (else cursor is solid)
LCDclr = 0x01 # clears LCD display/RAM, sets address
0
LCDhom = 0x02 # moves cursor to position 1, line 1
setCG = 0x40 # sets "write to char gen RAM". OR
with addr.
setDD = 0x80 # sets "write to data display". OR
with addr.
line2 = 0x40 # address of second line
setL2 = setDD + line2 # sets "write" to write to line 2
#
dly120 = 32 # loop constant for just under 120
microsecs
space = ' ' # ASCII space character
#
#
# **************************************************************************
# *
# * Here is the actual code...
# * Note there's no point in pushing registers or calling subroutines,
# * as we're scribbling all over all the RAM including the stack area.
# * Before we start, reset LCD and tell the world what we're going to
do.
# *
# **************************************************************************
#
.org rom
init: ld a, LCinit # tell it about data format etc
out (LCDins), a
ld b, dly120
waitI0: djnz waitI0 # let the LCD sort itself out
ld a, LCDclr # clear display and RAM, home cursor
out (LCDins), a
ld bc, 4900/7 # that takes about 4.9ms
waitLC: dec bc # loop takes 26 T-cycles, about 7
microsecs
ld a, b
or c
jr nz, waitLC # wait for init to complete
ld a, LCDon + Con # turn on the display
out (LCDins), a
ld b, dly120
waitI1: djnz waitI1 # let the LCD get it done
ld hl, SRBmsg
jp mssgHL # and return from there to following
code
SRBmsg: "RAM test " # this message fills the first line
.byte 0 # terminator
#
#
# ***** Step 0. Initialise, and set all RAM to 0's (we hope).
# 8Kbytes-worth of LDIR takes 21 T-cycles x 8192, about 47
milliseconds
#
SRB0: ld de, 0 # assume we're going to pass - no
errors
ld h, d # (error counter is 24-bit)
exx # save that thought!
ld hl, ram
ld (hl), 0 # set first location to zero
ld bc, ramsize - 1 # make 1FFF copies...
ld de, ram + 1 # ...starting here
ldir # block copy, fastest way to set all
the rest
#
# ***** Step 1. 3 pairs of read/write operations for each *bit* (not
byte).
# This is a marching pattern, but tests that each bit can be 1 or
0.
# For sake of speed, loops are done with JP, faster than JR if
jump
# is made. However, JR is faster if the jump is not taken, so is
used for
# the jump-on-failure -- which hopefully is rarely taken!
# "nxtbit" loop takes 110 T-cycles, about 30 microseconds.
# "nxtbyt" loop takes 8 nxtbits + 60 T-cycles = 940 T-cycles,
about 255us
# 8Kbytes-worth takes 255us x 8192 = 2.09 seconds.
#
ld bc, ramtop + 1 # where to stop
ld d, 1 # mask for current bit in current byte
ld hl, ram-ramtop-1
nxtbyt: add hl, bc # start position
ld e, 0 # what the whole of the current byte
should be
nxtbit: ld a, (hl) # ** Read: Ci(=0)
and d # select current bit
jr nz, fail1a # if not still 0, it's duff
OK1a: ld a, e # what it should be, so far
or d # ** Write: Ci <-- 1
ld (hl), a # put it away
ld a, (hl) # ** Read: Ci(=1)
and d
jr z, fail1b
OK1b: ld a, e # current bit is still zero in E
ld (hl), a # ** Write: Ci <-- 0
ld a, (hl) # ** Read: Ci(=0)
and d # select current bit again
jr nz, fail1c # if not still 0, it's duff
OK1c: ld a, e # what it should be, so far
or d # ** Write: Ci <-- 1
ld e, a # update the copy
ld (hl), a # put it to bed
rlc d # next bit - NB 8-bit rotate
jp nc, nxtbit
inc hl
ccf # it was set by the last RLC D
sbc hl, bc # see if we've run out of RAM
jp nz, nxtbyt
#
# ***** Step 2. Check each bit Ci(=1), then toggle it twice.
# "nxtbi2" loop takes 62 T-cycles, about 17 microseconds.
# "nxtby2" loop takes 8 nxtbits + 46 T-cycles = 542 T-cycles,
about 147us
# 8Kbytes-worth takes 147us x 8192 = 1.2 seconds.
#
ld hl, ram-ramtop-1
nxtby2: add hl, bc # E is still FF, this section doesn't
change it
nxtbi2: ld a, (hl) # ** Read: Ci(=1)
and d
jr z, fail2
OK2: ld a, e # what it should be (0FFH)
xor d # make current bit zero
ld (hl), a # ** Write Ci <-- 0
ld a, e # restore the '1'
ld (hl), a # ** Write Ci <-- 1
rlc d
jp nc, nxtbi2
inc hl
ccf # it was set
sbc hl, bc # see if we've run out of RAM
jp nz, nxtby2
#
# ***** Step 3. Check each bit Ci(=1), then toggle it three times.
# "nxtbi3" loop takes 77 T-cycles, about 21 microseconds.
# "nxtby3" loop takes 8 nxtbits + 46 T-cycles = 662 T-cycles,
about 180us
# 8Kbytes-worth takes 180us x 8192 = 1.5 seconds.
#
ld hl, ram-ramtop-1
nxtby3: add hl, bc
ld e, 0xFF # it gets changed to 0 as we go round
nxtbi3: ld a, (hl) # ** Read: Ci(=1)
and d
jr z, fail3
OK3: ld a, e # what the byte should be
xor d # make current bit zero
ld (hl), a # ** Write Ci <-- 0
ld a, e # restore the '1'
ld (hl), a # ** Write Ci <-- 1
xor d # make current bit zero
ld e, a # copy it
ld (hl), a # ** Write Ci <-- 0
rlc d
jp nc, nxtbi3
inc hl
ccf # it was set
sbc hl, bc # see if we've run out of RAM
jp nz, nxtby3
#
# ***** Step 4. Check each bit Ci(=0), then toggle it twice.
# "nxtbi4" loop takes 62 T-cycles, about 17 microseconds.
# "nxtby4" loop takes 8 nxtbits + 46 T-cycles = 542 T-cycles,
about 147us
# 8Kbytes-worth takes 147us x 8192 = 1.2 seconds.
#
ld hl, ram-ramtop-1
nxtby4: add hl, bc # E is now zero, after finishing Step 3
nxtbi4: ld a, (hl) # ** Read: Ci(=0)
and d
jr nz, fail4
OK4: ld a, e # what it should be (00H)
xor d # make current bit a '1'
ld (hl), a # ** Write Ci <-- 1
ld a, e # restore the '0'
ld (hl), a # ** Write Ci <-- 0
rlc d
jp nc, nxtbi4
inc hl
ccf # it was set
sbc hl, bc # see if we've run out of RAM
jp nz, nxtby4
jp SRBend # testing completed
#
#
# **************************************************************************
# *
# * The following code uses IX to store the return address. It uses
BC,
# * but restores BC = ramtop + 1 on exit. It prints a message to give
# * the failed address, data as read, expected data, and section where
# * the error was detected.
# *
# **************************************************************************
#
fail1a: ld ix, OK1a # here if Read: Ci(=0) failed in Step
1a
ld a, 0x1A # section code
jr fail
fail1b: ld ix, OK1b # here if Read: Ci(=1) failed in Step
1b
ld a, 0x1B
jr fail
fail1c: ld ix, OK1c # here if Read: Ci(=0) failed in Step
1c
ld a, 0x1C
jr fail
fail2: ld ix, OK2 # here if Read: Ci(=0) failed in Step 2
ld a, 2
jr fail
fail3: ld ix, OK3 # here if Read: Ci(=1) failed in Step 3
ld a, 3
jr fail
fail4: ld ix, OK4 # here if Read: Ci(=0) failed in Step 4
ld a, 4
#
# ***** This is the part that actually does the printing
#
fail: ex af, af # save section code for the moment
ld a, setL2
out (LCDins), a # address LCD second line
ld b, dly120
fwait1: djnz fwait1 # give it time to do its stuff
ld c, h # upper byte of failing address
ld iy, f.L
jr f.hex # print it
f.L: ld c, l # lower byte of failing address
ld iy, f.coln
jr f.hex
f.coln: ld a, ':' # print colon
out (LCDdat), a
ld b, dly120
fwait2: djnz fwait2
ld c, (hl) # get the duff data
ld iy, f.spc
jr f.hex
f.spc: ld a, space # print space
out (LCDdat), a
ld b, dly120
fwait3: djnz fwait3
ld a, '(' # print left bracket
out (LCDdat), a
ld b, dly120
fwait4: djnz fwait4
ld c, e # expected data
ld iy, f.brk
jr f.hex
f.brk: ld a, ')' # print right bracket
out (LCDdat), a
ld b, dly120
fwait5: djnz fwait5
ld a, space # print space
out (LCDdat), a
ld b, dly120
fwait6: djnz fwait6
ld a, '-' # print a dash
out (LCDdat), a
ld b, dly120
fwait7: djnz fwait7
ex af, af # where we saved the section number
ld c, a
ld iy, f.fin
jr f.hex
f.fin: exx # remember H,DE' had zero to signify
"pass"
inc e # so update error count
jr nz, f.exx
inc d # update middle byte too, if necessary
jr nz, f.exx
inc h # update top byte if necessary
f.exx: exx
ld bc, ramtop + 1 # caller expects this to be here
jp (ix) # back to "caller" (or wherever!)
#
#
# **************************************************************************
# *
# * This pseudo-subroutine is "called" to print a pair of hex digits.
# *
# * Entry: value in C, return address in IY.
# * Exit: A and B mangled.
# *
# **************************************************************************
#
f.hex: ld a, c # get value to print
rrca # move upper nibble to lower
rrca
rrca
rrca
and 0x0F # remove any garbage
cp 0x0A # do we need a letter?
jr c, AOK.1
add a, 'A' - 0x3A # yes, adjust it
AOK.1: add a, '0' # make it ASCII
out (LCDdat), a # print it
ld b, dly120
Await1: djnz Await1 # give LCD time to do his stuff
f.hex1: ld a, c # get lower nibble this time
and 0x0F
cp 0x0A
jr c, AOK.2
add a, 'A' - 0x3A
AOK.2: add a, '0'
out (LCDdat), a
ld b, dly120
Await2: djnz Await2
jp (iy) # return to wherever caller specified
#
# **************************************************************************
# *
# * This pseudo-subroutine prints a message (if the as-yet-untested LCD
is
# * working) -- for use by the test routines that have no stack.
# *
# * Place the required message immediately after the call; this code
returns
# * to the address immediately beyond the message.
# *
# * Entry: HL points to the message, zero-terminated
# * Exit: A, B mangled, HL updated
# *
# **************************************************************************
#
mssgHL: ld a, (hl) # get the character
or a # is it the terminator?
inc hl # doesn't affect the flags...
jr nz, do.mhl # ...so this depends on the character
jp (hl) # to the code following the message
do.mhl: out (LCDdat), a # send character to LCD
ld b, dly120
waitm: djnz waitm # wait for our slow LCD
jr mssgHL # repeat until cooked
#
#
# **************************************************************************
# *
# * Arrive here on completion of RAM testing
# *
# **************************************************************************
#
SRBend: ld a, setDD + 4 # to replace "test" on LCD with count
out (LCDins), a
ld b, dly120
fwait8: djnz fwait8 # give LCD time to do his stuff
exx # alternate reg set had DE = error
count
ld a, h # ...see if it passed
or d
or e
jp nz, SRBerr # skip if errors
ld hl, SRB.OK # tell the user all is well
jp mssgHL
SRB.OK: "OK "
.byte 0 # marks end of message
halt # we're all done here
#
# ***** do this if RAM failed test
#
SRBerr: ld c, h # error count, MSByte
ld iy, SRBE.M
jr f.hex1 # only show 5 digits, to fit 16-char
display
SRBE.M: ld c, d # error count, middle byte
ld iy, SRBE.L
jr f.hex
SRBE.L: ld c, e # error count, LSByte
ld iy, SRB.em
jr f.hex
SRB.em: ld hl, errors # message " errors"
jp mssgHL
errors: " errors" # with 20-bit count, just fits 16-char
display
.byte 0 # marks end of message
SRBhlt: halt # unwise to carry on with duff RAM
--
Pete Peter Turnbull
Network Manager
University of York
Hi Guys,
Now that the SuperPET's are off the bench, I have moved on the 5100.
This is an IBM 5100, BASIC only, 16K model - I received it about a week
ago. It was reported working the last time it was powered up (I have a
picture of it taken then with a BASIC program on the screen), however it
has been stored in an attic for quite a few years since then.
The machine runs, however the "BRING UP" program is reporting an error
in the non-executable ROS content and CRC test. At least thats which I
understand from the maintenance manual.
It gets as far as the 'I' test, then lights the PROGRESS-CHECK light.
The screen displays:
--------------------------------------------
ABCDEFGHI
18 07
(Bottom line of display)
A B C B ~ N_ 13 EZEP (Z and P are underlined)
--------------------------------------------
According to the maintenance manual, line 1 cols 1 and 2 should contain
the ID of the module it is looking for (18) and 5 and 7 contain an error
code (07).
I have not been able to determine what '07' means ... Perhaps its in the
manual, but I have not found it yet. (Please bear with me, I haven't seen
a real live 5100 in aver 20 years, and I have never worked on one before).
I have tried removing and reseating all the cards (which is very unplesant
as the rubber/foam which supports then when they are in their normal
"upside down" position is about the consistance of tar on the surface,
which has glued itself to the faceplates of all the cards - I'll be looking
for a good way to replace this eventually).
Anyone have any experience with reports of bad ROS - is there any other
cause (power supply tolerance etc.).
I know this is a long shot, but anyone have a unused 5100 ROS? (perhaps
>from an APL upgrade or a dead machine) ... (I'd really like to find a full
APL ROS :-)
Anyone have the code?
Anyone ever tried making a substitute?
According to the manual, you can get into the level 1 diagnostic mode
by pressing either:
Cmd *
- or possibly -
Cmd + / Cmd - / Cmd *
Page 3-10 indicates just 'Cmd *' while page 3-15 indicates the longer
sequence - neither does anything on my unit - am I doing it wrong, or
is this a function in the non-executable ROS, which is not being allowed
due to the error? (Does it even recognize this sequence when in the
process-check state, as according to the register displays it appears to
be halted?)
Any help / insight would be greatly appreciated!
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html