Hi all,
I recently obtained an old PDP-8/L in reasonable shape (why does this sound
like an AA meeting? :-)
Anyway, it doesn't work. So I'm happy debugging. The supplies on the
back plane are not right so I decided to pull the main supply.
I finally broken down and ordered an ESR meter. Is it smart to check
all the caps?
I've never used an ESR meter but it seems like a good idea to try it on
all the big caps just to see what sort of shape they are in. I assume I
need to open the little caps which are in parallel to get a good reading
(my experience, limited, is that the little axial electrolytics tend to
open/short much more often than the big cans).
One of the unregulated supplies (-6) coming off the main transformer was
a volt low when loaded and I thought I'd check the caps and the diodes.
Unloaded it shows -33v (but looking at the schematic, that may be
actually correct. Loaded the +5 was low (like 4.5), unloaded it's
perfect (5.01).
The lights do light, and run sets the run light, stop stops but load
address does not. Worse, it seems to toggle the MA, which is ringing a
bell about a common fault. I figured I'd get the supplies all cleaned
up first...
-brad
I offered these once before, but arrangements fell through.
I have the following collection of magazines to give for the cost of shipping.
USPS Media Mail works best (source zip code 01845)
PC Tech Journal
1984 - 1988
1984 V1 n: 8/May,9/Jun
1984 V2 n: 1/Jul,6/Dec
1985 V3 n: 1,2,2,3,3,4,4,5,5,6,7,8,9,10,11,12
1986 V4 n: 1-13
1987 V5 n: 1-13
1988 V6 n: 1,2,3,4,5,6,7,8,10,11,12
1989 V7 n: 1,2,3,4
Extras:
PC Products: Jan 84, Jan 85, Feb 85, Jul 85
----
Dave.
Ethan asks:
> I am a little unclear, though, about how traditional CP/M systems
> were set up for ROM and RAM. Was it common to use a "shadow ROM"
> in low mem at reset, then have the BIOS live at the top of memory?
> How did 64K RAM CP/M machines handle the BIOS?
The most traditional CP/M system has a toggle-in front panel and
16K of RAM, Ethan :-).
The much later CP/M systems that had boot ROM's either had them
consuming a small amount of high memory permanently with some
hardware hackery to jump there on a cold reset, or lived in
low mem at reset and had a later stage of the boot process map
them out.
And I am perplexed by your BIOS question. I think you are using
that acronym in a non-CP/M context. If you want to read the
"CP/M 2.0 System Alteration Guide" and rephrase your question I
think we could make some progress.
Tim.
Hi Andrew,
Just sitting here wondering why you're not using one of the enhanced-
functioning Z80 chips. Even going with the 64180 or Z180 would give
you 2 UARTS and an MMU, in addtion to 2 DMA channels and a timer.
Later version of this product line, will of course, give you more
instructions and functionality.
But the MMU can make the whole process of bootup very easy. Simply
use the MMU to map the ROM out after the system's been started
(you've got a 1MB physical address space). Duck soup.
But if you want to stick with the "real" Z80, I've seen two methods
of getting around the reset to 0000.
The first is to simply force three bytes onto the system bus to
perform a jump to whatever address you desire after a reset. You'll
only do this once per reset, so the circuitry's pretty simple.
Another way to is to start out with an EPROM mapped in and then
disable it using an I/O instruction. You can leave RAM mapped in for
write cycles, so that only reads will come from the ROM and writes
will go directly to RAM. That way, you can set up locations starting
at 0000 from a ROM.
In any case, the ROM needn't be very big. I think Don Tarbell used a
little bipolar 82S123 PROM. Gives you 32 bytes to do what you need,
which, in Don's case was enough to get the first sector of an 8"
floppy read.
CP/M BIOSes for 2.2 and below are easy--they're poll-mode with
clearly described inputs and outputs. About the only thing you may
find confusing is the IOBYTE convention, but that's optional and
fairly well documented.
I've written a CP/M BIOS without resorting to assembly, doing the
whole thing in machine code. It's not a big thing and you can start
with the basic set of disk and console I/O routines. There are two
boot entry points in the BIOS jump vector--the "cold start" entered
by a jump to 0000 that (re)loads the entire CP/M BDOS and CCP, and
the "warm start" that simply reloads the CCP.
Disk I/O is done in 128 byte "sectors", so if your physical sectors
are longer than that, you'll need to set up blocking and deblocking
routines.
All of this is covered in the CP/M System Alteration guide in pretty
fair detail, along with a couple of samples.
CP/M 3.0 or MP/M is more involved, taking advantage of bankswitching.
Interrupt-driven I/O is required for MP/M--and the I/O system is
more elaborate.
Cheers,
Chuck
A few days ago I finally managed to find and fit a perfect replacement
for the pinch roller in my apple 40Mb tape drive. The old roller, like
most these days had become a sticky mess and fitting the new one took a
half hour with a dremel and a bit of magic with a freezer so that the
replacement slipped on and would never come off once it warmed up.
Well after watching the thing properly retension a spare QIC-80 tape I
had (I have loads of QIC-80 tapes but only a few QIC-40 tapes) I then
grabbed an unopened copy of A/UX 1.1 I had been wanting to backup and
popped it into the drive and carefully watched it do it's initial
retension (like it does whenever a tape is inserted). After a few
moments I started to see the tape was not properly spooling back up (it
was starting to move up and down on the spool) and I pulled the tape
before it ate itself (or at least mashed up the sides of the tape).
I fed it another QIC-40 tape and it did it again so I tried the QIC-80
tape again and it didn't happen.
The only difference between my QIC-40 tapes and that QIC-80 tape is that
the QIC-40 tapes have never been used. Could it be that the drive belts
in the tapes are not enjoying me trying to use them after at least 20
years of no use?
I won't even risk backing the tape up until I can properly get it to run
through the retension cycle properly.
More info on the Apple Tape Backup 40SC can be found here:
http://docs.info.apple.com/article.html?artnum=704&coll=ap
John.
> Thanks for your work on this Steve, I need to find the one or two I
> spotted again, but yours was cleaner than mine.
>
> I tested the PCI NI-Analyser card again on the HP150 - which is the
> working HP-IB machine I have. Since I didn't know better I captured
> everything again - including timings. For someone writing an emulator,
> this could be helpful, but I don't know if you want another huge capture
> file of boring Amigo protocol stuff. I've attached what I did and
> captures of the analyser interface - I'd welcome your advice on what I
> should be capturing that would be useful for protocol understanding.
>
> Hope all's well and thanks again,
> Rodney Brown
>
Hey Rodney,
Hope you don't mind but, I'm gonna post this to the classiccmp list.
Someone there may want to follow the discussion.
What kind of system are you running the PCI Analyzer on? Windows? Linux?
I have FINALLY made some more progress with the ISA GPIB card in my
Linux box. Unfortunately, it uses the NEC7210 chip which has been a pain
in the rear to program. I found a few snippets of code online but really
didn't find anything that directly addressed my needs.
I have been able to read and write small data packets to the HP7980 but
that's about all. With the tape drive, you have to worry about block
sizes, file and record markers, rewind, readahead... Blah... Blah...
Blah... As of now, I have not yet figured out how to handle all that
stuff. So, I decided to take a break from the tape drive and concentrate
on the HPIB CS80 disks.
I suspect the HP150 is using the "Cold Load" command to read the tape on
bootup. I have not been able to read a tape using that method on my PC
(yet).
I was already familiar with the CS80 protocol so, I just had to learn to
program the 7210 chip. It took a while but, I can finally, with some
confidence, program the 7210 to do what I need. I was also able to write
some code to support a couple of HP instruments (multimeter / frequency
counter) over HPIB.
Programming the CS80 disk was fairly easy and, at this point, I can read
or write a raw binary file to any partition (including boot) of the HPIB
disk from my PC (linux). That disk is then bootable from the HP1000 with
a CS80 ROM.
I have created a small "library" of sorts with the common CS80 methods
and another with the HPIB methods in another. I'm not a "C" programmer
so, anyone looking at the code would probably think it's sloppy. But, it
works (sorta) :-)
The question is: What exactly are your goals at this point? If you're
still trying to boot the HP150 off the HP7980, I can probably provide
some additional insight into the tape protocol although, I cannot
provide any specific info for programming the HP150.
One of the problems with programming the tape drive is that you cannot
slow down the data interchange to see exactly what it is doing. With the
disk there is no "timeout" for any of the transactions. You can slow
down (or halt) the bus and watch the interaction between the disk and
the computer without causing any errors. You cannot do this with the
tape drive. It'll throw an error :-( Furthermore, when the computer
boots there is a large chunk of data that is passed across the bus this
bloats your analyzer's capture and makes it much harder to pick out the
important bits.
You might try to capture only the transactions where the ATN is
asserted. This will filter out the "data" and only leave the commands to
wade through.
If you have a HPIB card with the 7210 or 9914 I can perhaps provide some
insight into register level programming with those chips. I have not
given up on the AMIGO tape protocol. I just have been focused on other
stuff :-)
There is a steep learning curve when tackling all these protocols at the
same time. My suggestion would be to break up the project into smaller
chunks. The first thing is to figure out how to do the register level
programming on the HPIB card. You will need to know how to send and
receive "commands" and "data", how to conduct a "parallel poll", and how
to change "states" on the card.
The tape and disk protocols are not simple, I would also suggest using a
simple device (HPIB meter etc...) to refine you programming. Use the
analyzer card to watch the bus to see exactly what happens when a
certain chunk of code is executed. Once you get predictable results,
it'll be easier to tackle a more complex protocol.
Talk to me about the HP150. What HPIB chip does it use? Does your
version of DOS/UNIX have the tools that you need to do register level
programming? I have HPUX 10.20 on a HP9000/800 that has HPIB support
built in. Does the 150 have this kinda support?
See ya,
SteveRob
steerex at ccvn.com
These were popular in the day to connect small offices to the net... it
combined
a mini file server, served as the wan link, mail, etc...
These particular 2 units have the sync card and cable for an external
CSU/DSU.
If there is any interest, fire over an offer... I won't be doing
anything with them
and they are taking up space...
I have one new unit and one demo unit both in their original box with
docs and
csu/dsu cable.
-- Curt
Richard writes:
> I don't know why I never realized this before, but the Tektronix 4010
> graphics terminal is implemented enitrely in SSI TTL logic and
> contains no microprocessor. I guess that makes sense with it being
> introduced in 1971, but it just suddenly hit me like a brick.
My favorite parts of the 4010 are not even SSI TTL. There's
a pot you turn up (I seem to recall a Unijunction oscillator)
and down to change the baud rate for example :-).
> PS: anyone need a 4010 service manual online? I have one and just
> noticed it hasn't been scanned on the net anywhere.
There was something pretty spastic related to Tektronix and
archives of their scope documentation a couple years back,
but what you need seems to be online at bitsavers.org right
now. You might have to look under "401x" instead of "4010".
Wow, 101 Mbytes for what I'm looking at right now!
Tim.
>> PS: anyone need a 4010 service manual online? I have one and just
>> noticed it hasn't been scanned on the net anywhere.
>
>I think they are somewhere on pdp8.net
>
ftp://ftp.pdp8.net/misc/4010/
Forgot about them. That was a quick scan for someone who needed it and was
going to do some cleanup and put them somewhere better. Looks like that
is way overdue.
Hey guys;
So I'm staring at various pictures of Cray2s and I'm trying to work out
what the lower covers are made from. I'm referring to the covers that are
coloured, apparently, depending on the install - usually red or blue, but
images.google has one with a rather garish yellow/green combination. I'm
guessing, for what you paid for a Cray2, you got to pick the colours to
match your institute.
At any rate, they LOOK like they're puffy, like a vinyl covered foam
cushion of sorts, perhaps a nod to the Cray-1 power supply seat covers. Is
this the case?
Also, are the transparent covers on the inner and outer faces
perspex/plexiglass or something different? (I can't imagine real glass,
but perhaps polycarbonate? Lexan?)
I suppose replies should probably be off-list, given the inanity of the
question.
Thanks all!
- JP
