>OB_CCTALK: Do modern (oxymoron?) Japanese, British, and Amurican cars
>have "Disc brakes" or "Disk brakes"? (German cars have "disk")
My 1965 T-Bird said "Disc" on the brake peddle.
-chris
<http://www.mythtech.net>
The classiccmp knowledge base will soon be supporting subcategories in
addition to the current "major" categories. If anyone has better suggestions
on how to name/arrange the categories & subcategory structures, I'm all ears
:)
Jay
> doesn't seem to be a regional thing.
In the docs I've been looking at, HP uses 'disc' while
DEC uses 'disk'.
Haven't looked at any 'DEC' docs from the Compaq or HP
era to see if it changes one way or the other.
>
>Subject: Re: Compupro progress / Console questions ?
> From: Dave Dunfield <dave04a at dunfield.com>
> Date: Sun, 24 Jul 2005 21:24:53 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi Allison,
>
>>known but forgotton problem in the 8" world. 765 has a READY sense line
>>and the 851 is know for changing state of the line during select.
>>Solution, force ready at the board (jumper) and don't use it. READY
>>was for detecting disk changes.
>
>Tried forcing READY on the original SA-851's, and it still didn't boot.
>I immagine there must be some other jumpering issues. I'm leaving that
>for now, as I do have a drive working.
There is a board level jumper.
>>>According to Compupro Docs, the Console port is USER 7 - I have
>>>setup the board to respond to users 4-7, which is the default setup
>>>requireed for the console shows in the Compupro docs. As noted
>>>above, I can select user7 and talk to the console correctly, which
>>>would suggest that this is all working correctly.
>>
>>It is likely initing the ports but may not use any of them. It's
>>possible the bootable media may use a different port scheme. Its
>>likely a difference between the boot roms and the BIOS code once
>>the boot transfers to the OS.
>
>Yes, thats one of the possibilities - others are that it is hanging
>on some other part of the init, or simply crashing (bad RAM etc.)
>
>
>>I assume based on the CPU your runnig CP/m-86 (or any DRI -86)
>>as the boot roms load a loader then load the OS (bios and all).
>>So booting is multi step code.
>
>Yes, it is CP/M 86 as noted in my original message:
>
>>The disks I am using are original Compupro distribution disks
>>(Can't make copies yet), labled:
>>
>>Serial# C86-272-1854
>>Version: CP/< 86 (P0 in handwriting)
>>CP/M 86 1.1
>>SYSTEM MASTER
>>Disk Number 1
>>Single Sided - 1024 B/S
>>
>>Serial# C86-0272-1854
>>Version: 1R
>>CP/M 86
>>SYSTEM MASTER
>>Disk Number 2 of 2
>>Single Sided - 1024 B/S
>
>I was hoping someone might recognize these disks and be able to tell me
>if they are setup for the Interfacer-4, or some other device - or perhaps
>someone has a known good boot disk for this config (86/87, Disk1A,
>Interfacer4)?
>
>I've had to put it away to get some other more pressing items on the bench,
>however when I get back to it, I am going to proceed as follows:
>
>I've been using an EPROM emulator to load my modified boot - this will also
>let me change the content of the boot ROM with power-on (while it is switched
>out of course).
>
>The boot rom provides 512 bytes at 00-FF - while it is enabled (out of reset)
>I can write all of memory, however I can read only the boot ROM - once I hit
>the enable, the boot-rom disappears and RAM appears.
>
>I plan to write a loader which will allow me to load a block of code into
>RAM at $0200, and to switch the ROM OFF and the RAM ON in the very last
>instruction of the 0000-01FF block - so it should transition to the code in
>RAM correctly.
>
>Boot the system normally,
>then load the loader into the boot-rom (via EPROM emulator),
>Reset should start loader.
>Send my 8086 monitor.
>Loader will put it in RAM and transition to it.
>Then I should be able to browse around the loaded memory image,
>and perhaps determine what type of console device it wants to communicate
>with.
>
>Main problem is: I don't know much about CP/M-86 - I do not have technical
>documentation or experience with it.
>
>With CP/M-80, it's fairly easy to find the console drivers by following
>addresses. I have no idea how to do this with CP/M-86
>
>Can you give me any pointers to how to find the console I/O functions under
>CP/M-86?
>
>I do have CP/M-86 running on an APC that I Can experiement with - I will also
>check the APC docs to see if they contain any useful info. I also have a Rainbow
>and docs, however I do not know how similar it will be as I seem to recall that
>the CP/M it has is a special dual-processor version.
Well I've never had to find the drivers blind. the time I spent with -86 was
at the front of the process, creating a working bios so I knew where I was going
rather than trying to figure were someone else went. It didn't hurt that I had
a boot monitor (subset of DDT in eprom).
CP/M 86 is not unlike cpm-80. The rom boot is enough to pull the next boot
off disk and usually that loads the loader. The laoder gets dropped at a
standard address 0000:0400h sticks in my mind. The loader is really a
minimal bdos and bios, enough to find CP/M86.sys and put it at the load
address for the system. I don't remember there being dynamic sizing so
if there isn't enough ram, Oops, crash. Once loaded the BDOS and BIOS
addresses have standard calling locations that are jumps (long jumps)
to them. A handy thing would be to disassemble the load file directly
rather than finding it ram, if possible.
The apc is a good version. The rainbow is really in a different league
as the bios is shared with the z80 making it much more complex.
Allison
I just pulled a somewhat parted Typeset-8 out of a very dirty Memphis
basement, and just like the PDP-8/e I had before this, the panel paint is
just starting to peel above the rightmost switches.
This bugs the hell out of me. I hate peeling paint.
I am toying with the idea of mixing up some paint to patch the flaws (the
rest of the panel is really great). Is there any interest in 8/e orange
(both shades) touchup paint, or am I the only one that manages to get
8/e's with peels?
The Typeset came with a DF32/DS32 pair and a Teleype BRPE paper tape punch
(PP67?), but the paper tape panels and electronics were removed years ago.
William Donzelli
aw288 at osfn.org
Hi Allison,
>known but forgotton problem in the 8" world. 765 has a READY sense line
>and the 851 is know for changing state of the line during select.
>Solution, force ready at the board (jumper) and don't use it. READY
>was for detecting disk changes.
Tried forcing READY on the original SA-851's, and it still didn't boot.
I immagine there must be some other jumpering issues. I'm leaving that
for now, as I do have a drive working.
>>According to Compupro Docs, the Console port is USER 7 - I have
>>setup the board to respond to users 4-7, which is the default setup
>>requireed for the console shows in the Compupro docs. As noted
>>above, I can select user7 and talk to the console correctly, which
>>would suggest that this is all working correctly.
>
>It is likely initing the ports but may not use any of them. It's
>possible the bootable media may use a different port scheme. Its
>likely a difference between the boot roms and the BIOS code once
>the boot transfers to the OS.
Yes, thats one of the possibilities - others are that it is hanging
on some other part of the init, or simply crashing (bad RAM etc.)
>I assume based on the CPU your runnig CP/m-86 (or any DRI -86)
>as the boot roms load a loader then load the OS (bios and all).
>So booting is multi step code.
Yes, it is CP/M 86 as noted in my original message:
>The disks I am using are original Compupro distribution disks
>(Can't make copies yet), labled:
>
>Serial# C86-272-1854
>Version: CP/< 86 (P0 in handwriting)
>CP/M 86 1.1
>SYSTEM MASTER
>Disk Number 1
>Single Sided - 1024 B/S
>
>Serial# C86-0272-1854
>Version: 1R
>CP/M 86
>SYSTEM MASTER
>Disk Number 2 of 2
>Single Sided - 1024 B/S
I was hoping someone might recognize these disks and be able to tell me
if they are setup for the Interfacer-4, or some other device - or perhaps
someone has a known good boot disk for this config (86/87, Disk1A,
Interfacer4)?
I've had to put it away to get some other more pressing items on the bench,
however when I get back to it, I am going to proceed as follows:
I've been using an EPROM emulator to load my modified boot - this will also
let me change the content of the boot ROM with power-on (while it is switched
out of course).
The boot rom provides 512 bytes at 00-FF - while it is enabled (out of reset)
I can write all of memory, however I can read only the boot ROM - once I hit
the enable, the boot-rom disappears and RAM appears.
I plan to write a loader which will allow me to load a block of code into
RAM at $0200, and to switch the ROM OFF and the RAM ON in the very last
instruction of the 0000-01FF block - so it should transition to the code in
RAM correctly.
Boot the system normally,
then load the loader into the boot-rom (via EPROM emulator),
Reset should start loader.
Send my 8086 monitor.
Loader will put it in RAM and transition to it.
Then I should be able to browse around the loaded memory image,
and perhaps determine what type of console device it wants to communicate
with.
Main problem is: I don't know much about CP/M-86 - I do not have technical
documentation or experience with it.
With CP/M-80, it's fairly easy to find the console drivers by following
addresses. I have no idea how to do this with CP/M-86
Can you give me any pointers to how to find the console I/O functions under
CP/M-86?
I do have CP/M-86 running on an APC that I Can experiement with - I will also
check the APC docs to see if they contain any useful info. I also have a Rainbow
and docs, however I do not know how similar it will be as I seem to recall that
the CP/M it has is a special dual-processor version.
As always, thoughts, ideas, suggestions etc. are welcome.
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
>
>Subject: Re: local demolition of SAGE building
> From: shoppa_classiccmp at trailing-edge.com (Tim Shoppa)
> Date: Sun, 24 Jul 2005 13:11:41 -0400
> To: cctech at classiccmp.org, cctalk at classiccmp.org
>
>> The minis and subminis of the 1950s, made for computer usage,
>> were really not effected by power cycling. Filament burnouts on these
>> types of tubes are exceeding rare.
>
>But inter-element shorts and leakage become more common, and my
>experience (backed up by many years of leaky/shorted tubes) is that
>these are related to power-on cycles. (i.e. "it worked last time I
>used it, but then I turned it on and all it does is hum").
>
>Maybe reduced sizes make physical tolerances between the elements more
>critical in the smaller tubes. Even though a lot of the leakage
>I've seen is between adjacent pins, not between adjacent elements.
>
>Tim.
This is very true.
The tube machines were not friendly to power cycling. Due to the amount of
power invloved and loading effects. The preference was to kill B+ (high volts)
to the affected section and keep the filaments hot. Further like all thermally
affected things temperature cycleing ws not only a filament problem but tube
seals (glass to metal) and element movement is problematic. Many high gain
tubes have remarkably close spacing of the elments particulary cathode to
grid1. Another phenomenum was tubes have materials to grab gasses and ions
in them that only work well when hot. Temperature cycling was (and still is)
a reliability issue. It was just much more easily noticed when you have
more than ten thousand tubes and the differential temps from cold to hot
(both filament and cabinet) are so large. The smaller mini and submini tubes
were only somewhat better but smaller means closer in smaller space and
prescreening weeded out infant mortality at the mechanical level.
There were even special tubes developed that would better withstand being
at cutoff for extended periods without losing emission. I have a few
of these, they are pin compatable with 12AX7 duo triode but have slight
differences as they are for extended operation at cutoff.
Outside of computers I have years to commercial radio where tubes have
had long standing in the transmitters especially at high power. Power
cycling was and still is avoided. When the power has been removed such
as for maintenance or expecially retubing (done based on time in service)
the initial bring up is done slowly to warm up the "getter" (degassing)
and to avoid thermal shocking parts. It's also not uncommon to see step
starting built into the power supplied to avoid the harsh effect of
surge loading the power lines or trying to bring 500uf of capacitor up to
voltage in a half cycle (kills rectifiers!).
The last bastion of widespread tube use was television and over time even
tube sets (particulary those with series string heaters) adopted
"instant on" circuits which ran the filaments at 50-70% when powered off
and removed the operating DC. This reduced warmup time to nil and also
improved the operating life of the tubes and the reciever greatly.
Treated right tubes(valves) offer excellent reliability and lifetimes
mistreaded and those can be drastically shortend.
Allison
> For transmitting tubes (valves), yes, careful power-up is
> important, but for computer rated minis, not so much.
Not just the Tx valves, all the valves from the synthesiser
on were protected, the exception was the audio pre-amp which
were the cause of > 50% of shutdowns until replaced by solid
state units.
> If anything, the a slow power-up is probably protecting the
> power supplies more than the tubes.
Not in these transmitters.
> Weak filaments that lead to burnouts and loose elements that
> lead to shorts generally get weeded out quickly, as the tubes
> die prematurely.
New valves are always run for the guarantee life, modern valves
are very poor, more than half are either DOA of fail within
the guarantee period.
Lee.
.
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
here's his web site.
http://www.rvhe.com/
If folks are interested in seeing a bridge, send him some email.
He's looking for applications/customers for the board.
The gentlemen who sold me the classic PDP-8 recently
told me that he had worked in the early 70's at an
outfit called Varisystems. They made dedicated
typesetting systems, one of which he had installed to
replace the PDP-8. He showed me a few bits and pieces
that he had saved, including a wire-wrapped TTL CPU, a
core stack, and a removable (technician-only)
diagnostic panel. From the panel, I concluded that it
was most likely a single accumulator machine. Has
anyone else seen one of these machines or know any
more about them?
There was also an auction on eBay recently of some
spare parts for a Compugraphics typesetter that
indicated that it too was based on a proprietary CPU.
The machine in question was from the late 60's. I had
never heard of them until the 80's, when they were
building systems around the PERQ (!!) and funding some
development work at CMU.
--Bill
