Does anyone have the schematics for the Whitechapel
Workstation. I'm trying to 'rescue' a WCW that has
the dreaded leaked battery.
Its not made too much mess, but there is quite a bit
of crystalised battery fluid mainly on the terminals
of components directly beneath the battery.
The WCW wont boot, although the disk drive and fans
spin up OK, the front on/off button doesnt function.
Although I can hear a faint click on the PSU
'controller' from the small relay.
Any tips on how to clean this and/or anyone with a
spare mainboard (too much to hope for but you never
know) - :)
Ian.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Around 1981-1985 a friend loaned me a Piece of Equipment. It has a S-100
Bus with five slots Horizontal in the Back. I had a regular Keyboard and
a Hex Keypad. I remember I cold enter in Hex Code and was able to Access
a FDC to test it.
Can't be sure of the MFG. But Xpandor comes to mind. My Friend says SOL.
Does this ring a bell with anyone
TIA
Bob in Wisconsin
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Liam Proven" <lproven at gmail.com>
> Date: Tue, 05 Feb 2008 10:19:10 +0000
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 03/02/2008, Allison <ajp166 at bellatlantic.net> wrote:
>> >
>> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
>> > From: "Roy J. Tellason" <rtellason at verizon.net>
>> > Date: Sat, 02 Feb 2008 20:48:33 -0500
>> > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>> >
>> >On Thursday 31 January 2008 10:07, Allison wrote:
>> >> Whats more interesting is there was nothing to prevent a termcap file
>> >> and later improved CP/M work alikes did exactly that and many more things.
>> >
>> >What sort of stuff would you put into the category of "CP/M work alikes"?
>>
>> NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. They all could run
>> CP/M programs but added things missing from basic V2.2. The gotacha was
>> they required z80 as they were stuffing all that into the same space
>> required by V2.2.
>
>Fascinating stuff. I had no idea there were so many.
Actually there are more.
I left out three or four at least.
>I used to do some support work on some early, 8-bit multiuser system
>which ran something called CP/M but which wasn't, not even remotely.
>The host machine was a single integrated unit - CRT screen, floppy
>drive, CPU and optionally had a 5MB hard disk built into the console.
>This had a bunch of serial ports on the back and could support half a
>dozen or so terminals.
>
>The OS was called "CPM8" or something but was like nothing I've ever
>seen before. Alas, now, with the passing of some 20y, I can't remember
>make, model or anything else...
>
Unfamiliar to me but maybe they had somthing.
Allison
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Tue, 05 Feb 2008 15:46:14 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Tuesday 05 February 2008 04:08, Chuck Guzis wrote:
>> > Date: Tue, 05 Feb 2008 02:20:29 -0500
>> > From: "Roy J. Tellason"
>> >
>> > > I'd already done it for DX-85M
>> >
>> > What's that?
>>
>> Proprietary multitasking operating system, based on the 8085;
>> basically the other end of the spectrum from CP/M. Included built-in-
>> interrupt-driven I/O (including 4 channels of async), file types
>> (i.e. differentiated between executable, data, index, etc.), built-in
>> ISAM files and a bunch of other stuff. One of these days I'll chat
>> about it if anyone's curious.
>
>Yup! Count me in...
Always curious, that sounds like my definition of an OS.
>(Snip)
>> Re: passing arguments on the stack. It's an interesting exercise on
>> the 8085 using the "undocumented" instructions. For example, opcode
>> 38H, which is a two-byte instruction would take SP, add the second
>> instruction byte and stick the result in DE. Opcode 28H would do the
>> same, but use HL instead of SP.
>>
>> Another 8085 16-bit operation, opcode D9H, would store HL in the
>> address pointed to by DE. Opcode EDh would load HL from the address
>> pointed to by DE.
>>
>> There were a couple of other 16-bit operations in 8085 not
>> documented. 08H would subtract BC from HL, 10H shifted HL right one
>> place with sign extension. 18H rotated DE left one place through the
>> carry flag (i.e. 17 bit rotate).
>>
>> There were a few other instructions of less interest: a couple of
>> jumps that tested for unsigned overflow and a conditional restart to
>> location 40H (RST 8) if the overflow flag was set.
>
>Interesting stuff. I've run across the occasional info on undocumented ops
>for different chips, but don't remember seeing any for the 8085 before.
They were commonly known before the Z80 and both were both widely
circulated and all the vendors made sure thies worked exactly the same
way. Whats funny is while they all worked to see it was there none
officially acknopwleged that save for under NDA.
>> It was kind of unfortunate that Intel simply didn't leave blanks in
>> the 8080 documentation for the "do nothing" moves; (e.g. MOV A,A; MOV
>> B,B, etc.). It might have freed up a few more spare opcodes for
>> later exploitation.
>
>I suspect that a lot of the reasons for them laying things out the way they
>did had to do with convenience in the manufacturing process, mask layout or
>somesuch stuff, rather than intent.
Maufacturing no. Design yes. back then there was little if any automated
chip design so anything to save time or transistors on the die was good.
The redundant moves are simple example of not decoding all possible states.
Saves transistors at a time when getting things on that much silicon was
still hard.
Allison
subtitled "computers - past, present, and future"
It's smallish - anyone interested?
I'm looking for reasons to put stuff on eBay (or maybe
it's keep it off!). Let me know. Fair shape.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
At 12:27 AM 2/1/2008, Paul Anderson wrote:
>My books are still in storage,( basement wall are up! ), but I seem to
>recall the LA36 had adjustments on the servo. Could the LA180?
Yes, it's basically the same mechanism.
I've sent the maintenance manual to der Mouse for scanning.
-Rick
Remember this post Chuck?
Don't know if this one comes up too often, but I recently acquired an HP
4145 semiconductor analyzer software diskette. It's SSSD 5.25". If
anyone's interested, I can shoot out an image.
Cheers,
Chuck
Are you able to make an image still? Do you want to sell this unit?
Thanks,
Dennis A. Drew
805.560.0404 Ext. 105
dennis at multiprobe.com
Director of Software Engineering
Multiprobe Corporation
819 Reddick Street
Santa Barbara, CA 93103
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Sat, 02 Feb 2008 20:48:33 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Thursday 31 January 2008 10:07, Allison wrote:
>> Whats more interesting is there was nothing to prevent a termcap file
>> and later improved CP/M work alikes did exactly that and many more things.
>
>What sort of stuff would you put into the category of "CP/M work alikes"?
NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. They all could run
CP/M programs but added things missing from basic V2.2. The gotacha was
they required z80 as they were stuffing all that into the same space
required by V2.2.
Allison
>(Snip)
>> Andy Johnson-Laird The Programmers CP/M Handbook went far to extend
>> and clarify both what the BIOS can do and more.
>
>Good book, that one. I dug it out of a box recently, and should probably get
>to re-reading it sometime soon, maybe.
>
>(Snip)
>> As you can se the whole interrupt thing was not CP/M as a limiting
>> factor but hardware or implementor understanding.
>
>I'd like to implement something that'd not only use one of those single-byte
>calls, but take the data inline, as well -- no need to load it into
>registers to pass it along, though there are some rather clumsy aspects to
>getting the stack pointer and fixing it...
>
>> For those that never used a really nice bios try a VT180, it didn't
>> do two sided but those disks where just emerging at the time. It did
>> implement interrupts with ring buffers for IO.
>
>Can you point to anything specific with regard to this?
>
>> The other thing was DMA. On S100 is was a timing and bus nightmare
>> and took years to almost get right. Many of the single baord systems
>> omitted it as it took space (8257 or later 8237 40 pin chips and a latch).
>
>Hmm, I seem to have some number of those on hand here. :-)
>
>> It works fine and made useful systems. However it means the CPU is locked
>> up for the duration of the transfer and cannot respond to interupts
>> making for poor latency as floppies are slow. Again CP/M doesn't care
>> how the transfer happens only that it does happen. So the fist system
>> built with DMA was a real eye opener. First it allowed background
>> activities to run faster and smoother like a line printer spooler.
>> also interrupts could be used byy the disk system to say "ready"
>> or "ready with error". Thats a lot of available CPU cycles.
>> the biggest areas of change is that modem programs werent pausing
>> for disk IO, they could fill a big (say 16k) circular buffer and
>> the cpu can be processing interrupts for IO and disk to manage
>> transfers rather than doing a lot of waiting in loops. It doesn't
>> take a lot more code but the complexity and debugging is greater
>> due to the near concurrent activities.
>
>One of the real problems I had with early BBSing was the fact that I was using
>a CP/M box and that had only a lmiited buffer in the modem program (probably
>MDM740 at first, IMP a bit later I think), while the guy at the other end
>had a newer and higher-speed modem that had several K of buffer in it that it
>would continue to empty after my end had asked it to hold on a minute...
>
>That same program had a print or capture buffer (I forget exactly now) that
>was way bigger, something on the order of 16K, and it came to me to use
>that for buffering the input rather than the teeny buffer provided, but I
>never did get around to making that particular modification to it.
>
>(Snip)
>
>--
>Member of the toughest, meanest, deadliest, most unrelenting -- and
>ablest -- form of life in this section of space, ?a critter that can
>be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
>-
>Information is more dangerous than cannon to a society ruled by lies. --James
>M Dakin
> Date: Tue, 05 Feb 2008 02:20:29 -0500
> From: "Roy J. Tellason"
> > I'd already done it for DX-85M
>
> What's that?
Proprietary multitasking operating system, based on the 8085;
basically the other end of the spectrum from CP/M. Included built-in-
interrupt-driven I/O (including 4 channels of async), file types
(i.e. differentiated between executable, data, index, etc.), built-in
ISAM files and a bunch of other stuff. One of these days I'll chat
about it if anyone's curious.
Sometimes interrupt-driven I/O wasn't very good. We used an Intel
8275 CRTC in the CPU and some enterprising engineer decided to
hardwire it to DMA channel 1, not 0. On the 8257 DMAC that meant
that we couldn't use auto-initialize to keep the display going and
basically had to re-initialize the DMA transfer between screens,
using an end-of-screen interrupt. Servicing that interrupt 60 times
per second was a big drag on the CPU--and if you missed it, the
screen would flicker.
Re: passing arguments on the stack. It's an interesting exercise on
the 8085 using the "undocumented" instructions. For example, opcode
38H, which is a two-byte instruction would take SP, add the second
instruction byte and stick the result in DE. Opcode 28H would do the
same, but use HL instead of SP.
Another 8085 16-bit operation, opcode D9H, would store HL in the
address pointed to by DE. Opcode EDh would load HL from the address
pointed to by DE.
There were a couple of other 16-bit operations in 8085 not
documented. 08H would subtract BC from HL, 10H shifted HL right one
place with sign extension. 18H rotated DE left one place through the
carry flag (i.e. 17 bit rotate).
There were a few other instructions of less interest: a couple of
jumps that tested for unsigned overflow and a conditional restart to
location 40H (RST 8) if the overflow flag was set.
With the exception of the double-precision subtract, none of these
instructions have close analogues in the Z80 instruction set. Nor,
AFAIK, did any commercial products exploit them.
It was kind of unfortunate that Intel simply didn't leave blanks in
the 8080 documentation for the "do nothing" moves; (e.g. MOV A,A; MOV
B,B, etc.). It might have freed up a few more spare opcodes for
later exploitation.
Cheers,
Chuck