test-drb February 2008

test-drb@ccmp.vtda.org

236 participants
373 discussions

by silvercreekvalley＠yahoo.com

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

18 years, 1 month

Looking for a Real Oldie

by trebor72＠execpc.com

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

18 years, 1 month

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >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

18 years, 1 month

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >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

18 years, 1 month

I found a book - "the Analytical Engine" by Jeremy Bernstein

by chrism3667＠yahoo.com

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

18 years, 1 month

a link for AT & T 6300 gurus

by chrism3667＠yahoo.com

http://www5.ncr.com/support/support_drivers_patches.asp?Class=pc_library_63… all free, all legal. No one will even check your I.D. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

18 years, 1 month

DEC LA180 printer

by rick＠rickmurphy.net

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

18 years, 1 month

HP4145

by dennis＠multiprobe.com

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

18 years, 1 month

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >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

18 years, 1 month

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> 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

18 years, 1 month

← Newer
1
...
28
29
30
31
32
33
34
...
38
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb February 2008