>On Sun, 4 Apr 1999, Buck Savage wrote:
>>not stored in RAM. Instead, they are stored in ROM.
>
>AFAIK, they are hard-coded into the CPU (except for PERQ and the like
>where they can be altered). ROM conjures up images of little socketed
>chips on the motherboard.
>
>--Max Eskin (max82(a)surfree.com)
>
Consider the PDP 11/44 in my living room. It is constructed using the
AMD 2900 series of bit-slice microprocessor chips. In this case, the
microcode is, in fact, stored in ROM chips, each of which is socketed to
the motherboard.
For some other types of processors, sure, the CPU real estate does
carry the code but, the part of the chip that holds the code is ROM.
William R. Buckley
Hi,
Several different subjects in one message...
Sony 650MB 5.25" MO drive
-------------------------
I posted about this drive a couple of week ago. At the time, I thought one of
the firmware EPROMs was faulty. (It wasn't. I have backed up all four EPROMs in
the drive.) It turned out that the drive lens needed cleaning. Not having a
5.25" head cleaning disk -- these are expensive, I think IBM wants over 50
pounds for one -- I had to disassemble the drive, removing both circuit boards
to reveal the lens. After cleaning with a cotton wool bud & isopropyl alcohol
and putting the drive back together, it miraculously worked!
The surfaces of all the disks were quite dirty. I believe the drive was used in
the City of London, and years of pollution left a residue on the surfaces. I
don't have a 5.25" MO disk cleaning kit, but luckily it's quite simple to clean
5.25" disks by hand. Briefly, I did this:
- wear plastic gloves to avoid getting oil from skin on surface
- breath on disk surface and wipe radially with a folded-up kitchen towel
- rotate the disk using finger (there is space to do this between the outside
of the disc and the casing) and repeat the breath & wipe until the entire
surface is cleaned
- do the same for the other side
Things I learned:
- Old MO drives and disks are sometimes available very cheaply, so it's worth
looking out for them.
- Cleaning the drive lens and disk surfaces can bring performance back to as-
new. Dirt impairing performance might be a common reason why a company would
get rid of old drives.
- You don't need an expensive cleaning kit to clean 5.25" disks. If you're
adventurous, you can clean the drive lens without needing to buy a special
disk.
- The old drives are much slower than modern ones. Performance is about
equivalent to a 4.5x CD-ROM drive for reading, with average seek time of
95ms (some modern drives are 20-25ms).
If anyone in the UK wants to get rid of an old 5.25" MO drive, especially a
1.3GB unit, please let me know. I'd like to have a backup unit in case my drive
breaks down.
EPROMs
------
My experience with one of the firmware EPROMs (made by TI) in the Sony drive
showed that "not all EPROMs are the same", which is news to me at least. Data
in most EPROMs can be dumped by doing this:
- drive /OE low
- set up address lines
- read value on data bus
However the TI EPROM didn't like that; doing it that way, even reading multiple
times and ANDing the results, gave errors. After changing my program to set up
the address lines before driving /OE low, everything went okay. Now I need to
re-dump the various EPROMs from other things that I thought were bad.
Hopefully at least some will be okay.
C= PET VisiCalc EPROM
---------------------
The Commodore PET version of the VisiCalc spreadsheet came with a chip that
plugged into a socket on the main board. This was probably an EPROM, used for
copy-protection. I have an original VisiCalc package, minus this EPROM. Does
anyone know where I can download an image of the EPROM from?
Nutspinner
----------
Disassembling PCB-mounting D-type connectors is a pain without having a
nutspinner for the hexagonal bolt things which typically fix the connector to
a panel. What size, number or whatever nutspinner is the right one for this
purpose?
IBM 3363 WORM drive
-------------------
Along with the Sony MO drive, I picked up an IBM model 3363 WORM drive (IBM
part number 63X4146). This was made in 1987. The original product announcement
can be read on the IBM web site. It uses write-once disks which store about
200MB. Luckily it came with twelve such disks, four of which are still in
their wrapping.
Anyway, the drive uses some kind of custom interface. It connects to a special
ISA or MCA card via a cable with 37-way D connectors at each end. The drive
came with two MCA cards, part number 63X4266. I have been unable to test the
drive or cards, since I don't have an MCA machine.
Does anyone know what the part number of the ISA controller for the 3363 drive
was? And where I might get one (cheaply)?
The MCA controllers have a firmware (EP)ROM on. One uses a 27C64 EPROM, which I
was able to backup without (many) problems. The other uses what I presume is a
mask ROM, MN2364DSP; this is made by Matsushita. I can't seem to dump this
properly, so its pinout must be somehow different to the 2764 EPROM. Any ideas
where I might look to find the pinout for this chip?
Regards,
-- Mark
>> Generally, a "D" at the front means it's some sort of communications
>> option, a "M" means memory, a "K" means CPU, "R" means disk controller,
>> a "T" means a tape controller, an "A" means an A/D or D/A converter,
>> a "V" means some sort of video-related hardware, and "L" means either
>> a line printer or a linear module. I'm sure someone will come up
>> with many options that don't quite fit into this scheme :-).
>Obvious exceptions without even thinking about it :
I don't think they're all obvious exceptions, though some are certainly
pushing the definitions to their limits!
>DR11-x (parallel interfaces, not really comms)
"Yeah but" a very common use of these cards were for interprocessor
communications (not necesarily between two -11's.) In any event,
a parallel interface is conceptually not much different than a serial
one, though certainly by the time you start putting interrupt request
and DMA handshaking on the cable you are stretching the boundary of
what "comms" is.
>KMC11 (soft-microprogrammed version of the DMC11. Not really a processor)
DEC felt differently - they really pushed the fact that there was a
processor (they call it a "microprocessor", somewhat at odds with the
modern interpretation, but it makes historical sense) in there.
>KM11 (maintenance card, not a processor)
>KW11-x (time clocks, etc)
Well, the module designation has to start with some letter, and I
think K is more appropriate than anything else here.
>KL11 (early version of the DL11, current loop serial at 110 baud)
If used as the console interface - as the KL11's usually were -
K isn't too inappropriate.
>MNCxx (MINC I/O modules, not memory at all)
>LPS11 (Lab Peripheral System, not a printer interface)
These are, indeed, true exceptions - though I don't think anyone would
get too confused and try to use a MINC module in place of memory :-).
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
OOPS!
I thought you were referring to the ubiquitous "text mode" switch on the
back of so many EGA-class monitors, e.g. NEC Multisync-I, of which I've
pressed several into service for Win95 with VGA cards. These use analog
inputs and really aren't much different from VGA monitors, with the
exception of their default horizontal sweep rate.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 04, 1999 4:09 PM
Subject: Re: homemade computer for fun and experience...
>>
>> You're right. The "text" mode was really not a valid construct for VGA
>
>Eh? Text mode has nothing really to do with the monitor. It means that a
>single character cell on the screen is controlled by 2 bytes of memory.
>One contains the character code (Ascii + a lot more characters), the
>other contains the attributes (foreground/background colours, etc)
>
>> valuable. The "hardware" text mode with which I'm familiar is simply a
>> color killer, which drives the display into a light green on a dark green
>
>Text mode can be (and is, on CGA and EGA and probably VGA) a colour mode.
>
>-tony
>
>Things must be dry before power up or electrolisys and other bad things
>happen. Pure water is generally harmless.
In what way harmless? Even 'pure' water has ions... (or so I've
learned in chem class)
>Soap, I used one of the standard products that seems to work well on
>glasses.
You mean something with a surfactant?
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
>> "Buck Savage" <hhacker(a)home.com> wrote:
>> > Actually, microcode is not compiled.
>>
>> All the microcode I've ever written was compiled. Of course, it was
>> compiled from special source languages defined for that explicit purpose.
>> No one with any sense would write a non-trivial amount of microcode any
>> other way.
>
>All the microcode I've ever written (or seen) was written in a special
>_assembly_ language. Or at least I'd class it as that as (a) one 'line'
>of microcode corresponded to one microinstruction and (b) the language
>statements were pretty close to the hardware definition.
>
>Here's a PERQ microinstruction :
>
>R0:=R0+R1, if neq goto(loop);
>
>The first 'phrase' defines the contents of
>X and Y fields (select particular registers)
>AMUX, BMUX fields (gate registers to ALU inputs, rather than, say gating
>a constant there)
>ALU field (do an addition operation)
>W field (we want to write it back to a register and not just set the flags)
>
>The second phrase sets the
>Condition field (to select the 'not equal' condition)
>Jump field (to do a got and not just a next instruction, say)
>SF and Z fields (to define the jump address).
>
>So the actual machine instruction is pretty close to the higher level
>version. OK, some fields (Z in particular) can be set by several
>different types of phrase, as the Z field is used for jump addresses and
>IO addresses and shifter control and constants and... Yes the assembler
>moans if you try to set it in 2 different ways in the same instruction.
>
>-tony
>
This is my experience as well. HP 21MX microcode is very similar. I will
dig up some examples and post it at a later time.
Thanks, Tony, for the examples and the clarification.
William R. Buckley
>On Sun, 4 Apr 1999, Chuck McManis wrote:
>
>>They are micro-coded to run LISP, sorta like the WD P-Engine machines run
>>PASCAL.
>
>So, an assembly language program for them would look like lisp, as opposed
>to MOVs, ADDs, and so forth? And same with Pascal? But why would anyone
>want something that was microcoded to run Pascal? Are there any other
>languages that have gotten microcoded into a processor?
>
> --Max Eskin (max82(a)surfree.com)
>
The value of a high-level language capable machine is that the code can run
without the need to invoke language translation. In such cases, the
hardware
becomes a language interpreter, with the speed of processing dramatically
increased. For a well designed system, the speed of processing is actually
greater for a Lisp program running on a Lisp machine than it would be for
the same Lisp program to run on a non-Lisp machine CISC or RISC
processor.
William R. Buckley
You're right. The "text" mode was really not a valid construct for VGA
monitors. Many EGA monitors would work just as well as VGA's, which, I
guess is a testament to the not so unusual notion that people charge less
for a product even though they've spend extra resources to make it less
valuable. The "hardware" text mode with which I'm familiar is simply a
color killer, which drives the display into a light green on a dark green
background. It didn't do anything to the sync. Monitors which work with
VGA should be fine. What's required in order to make the VGA look like
monochrome, is either to drive all the colors equally or to drive only the
green video. It would be much simpler to allow the use of an S-100 adapter
to use his old monochrome monitor with either a mono or a Hercules, or
whatever other card he desires. His software will have to deal with it
anyway, and the hardware for mapping it isn't too complicated to support on
an adapter card.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 04, 1999 12:13 PM
Subject: Re: homemade computer for fun and experience...
>> Fire). One of those little switch boxes would serve just fine. The 8.0
MHz
>> Z80 wouldn't be sufficient to drive a VGA, so no need for anything fancy.
>
>Hmm... Don't VGA cards still have a hardware text mode? That's all you
>really need for the Z80 machine, and using it wouldn't be any worse than
>using an MDA or CGA card, once it's initialised.
>
>Of course that means you need to get a VGA card based on a documented
>chipset so you do know what to stick in all the registers. The on-board
>BIOS is going to be no use at all.
>
>I've seen a VGA card in a 4.77MHz 8088 machine, and it was usable for
>text and point-plotting type graphics. I think a Z80 could manage that as
>well. Of course you'd probably need some kind of paging hardware to map
>all the VGA's memory space into the Z80 memory map.
>
>The advantage of using a VGA card is that most people have a VGA monitor
>on their desk anyway...
>
>-tony
>
Will do.
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
-----Original Message-----
From: Mike Ford <mikeford(a)netwiz.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 04, 1999 3:15 AM
Subject: Re: Apple stuff....
>
>I bought a box full of Apple etc. cables recently, wait a couple days and I
>will sort out what I have and put it on my web page.
>
>http://www.netwiz.net/~mikeford/MacList.html
>
>
>