test-drb

test-drb@ccmp.vtda.org

101090 discussions

How compatible were "MS-DOS Compatible" machines?

by trixter＠oldskool.org

(Since the whole point of collecting and restoring old computers is to demonstrate and *use* them, I hope Jay will find this programming question on-topic...) I am currently in the middle of programming some vintage-era MS-DOS software that has the following requirements: - Manipulate the speaker to produce arbitrary tones - Update the screen in arbitrary locations (text mode; multiple screen pages if available) - Get single-key input from the user, including sensing keypresses from "inert" keys like shift and capslock (by themselves as well as in conjunction with other keypresses) I know how to do all of that, both high-level (DOS and BIOS calls, ANSI calls, etc.) and low-level (writing directly to b800:0000, screwing with the 8253 timer, hooking IRQ 9 and monitoring port 60h, etc.). My problem is that I'm not sure how much I can "get away" with doing things low-level and still have it work on machines that were less-than-100% IBM PC-compatible. If anyone who programmed for early IBM PC semi-compatible machines from 1981-1985 (Dave? Chuck?), I'd appreciate any thoughts or advice on what to watch out for. Obviously I'd love to code it ALL low-level, since that will result in the fastest program performance for the user, but not if it will lock out 20% or more of all clones made before 1986. For example, let's say I go completely low-level, all direct hardware access, compiling and testing on my IBM 5160 with CGA. Based on my past experience with clones, I am pretty sure of the following behavior: - IBM PC 5160: Should work perfectly - IBM PC 5150: Should work perfectly - AT&T PC 6300/Olivetti M24: Should work perfectly, although certain key combinations are known to "stick" without special handling - Sperry PC: Keyboard scan codes might be different? - Tandy 1000: Keyboard scan codes differ in 2 or 3 places - IBM PCjr: Keyboard scan codes are *definitely* different - DEC Rainbow: Keyboard different? Heard that display was vector-graphics based; would direct screen writes in text mode even work? - Tandy 2000: Again, wasn't the screen vector-based? ...etc. That kind of thing. I guess what I'm asking is something like, "Is it worth attempting to support 'MS-DOS only' machines made before Compaq, or were they just too goofy and limited to bother with?" Maybe a follow-up question is, "How many MS-DOS-only machines were made before 99.9% IBM PC compatibility became the norm after Compaq's example?" PS: I'm on a deadline for this project, which is why I care about wasting time trying to support four different ways of doing the same thing (like screen access, for example: 1. ansi.sys, 2. DOS calls, 3. BIOS calls, 4. direct screen writes). -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

18 years, 2 months

C64 on Craigslist

by cclist＠sydex.com

http://eugene.craigslist.org/sys/566685209.html Cheers, Chuck

18 years, 2 months

16-bit sector addresses in CP/M 2.2

by cclist＠sydex.com

> Date: Fri, 08 Feb 2008 01:43:37 +1030 > From: Alexis > I'm attaching a hard drive to my 8080 computer and there seems to be > something about the way the sector translation works that's caught my > attention. Before I go wasting my time trying to figure it out myself I'll > ask here because there's going to be someone who knows (it's 1:30am and > I'm feeling a little lazy). > Another thing is that the total sectors per track in the Disk Parameter > Block is a 16-bits, not 8-bits. > > Apologies if this has been discussed and I've missed it. (Perhaps > someone can provide a link if it has been) I'll confine my answer to CP/M 2.2, since that's probably what you're working with. There's lots of 16-bit arithmetic in CP/M 2.2--in particular, the 128- byte block number is maintained as a 16-bit value. This limits the size of a disk to 65536 128-byte records or 8MB. Yes, you can have a single track with 65535 sectors on it or 65535 tracks with a a single sector on each. In theory, the maximum disk size should be about 1GB (DRM=65535 and BSH=7). Check it out for yourself in the source at: http://www.cpm.z80.de/source.html Note that CP/M 2.2 contains no division routines in its sector and track computation--the block-to-track-and-sector translation is handled by repetitive subtraction. There is a little bit of code to reduce the burden of this by using the last translated block number to compute the next, though I wonder how many cycles are saved in practice. Hope this helps. Cheers, Chuck

18 years, 2 months

How compatible were "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Mon, 28 Jan 2008 15:40:04 -0600 > From: Jim Leonard <trixter at oldskool.org> > - Manipulate the speaker to produce arbitrary tones > - Update the screen in arbitrary locations (text mode; multiple screen > pages if available) - Get single-key input from the user, including > sensing keypresses from "inert" keys like shift and capslock (by > themselves as well as in conjunction with other keypresses) It depends on what you want to call "MS-DOS ompatible". NEC 9801 series machines have a completely different I/O port and memory layout; the CRT controller is a world unto itself and the BIOS interface is different. But the things run MS-DOS, albeit with 1,024 byte sector diskettes, and have an x86 CPU in them--some with Intel; others with NEC V-series CPUs. I think the family went as far as a 486 equivalent. For that matter, I believe a number of configurations of the S-100 Compupro boxes could run MS-DOS. I know of other MS-DOS compatible machines that do not have memory- mapped displays but rather interface to a serial terminal (no graphics capabilities). There are others with non-PC memory layouts that will give you most of a megabyte of contiguous RAM to work with. My point is, that "MS-DOS compatible" covers a huge amount of territory. On the other hand, "something that will boot from a PC- DOS 3.31 diskette" is quite a bit more restrictive. FWIW, Chuck

18 years, 2 months

manman fortran source

by rdawson16＠hotmail.com

I was wondering if anybody knows where I could find a copy of this dinosaur. I know it was written by the ASK group, and later bought by Computer Associates. I want to compile it and fire it up on a pc to show some folks, sort of a technology demo. They have a database on a VAX and are using this as a manufacturing database. Randy _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail?-get your "fix". http://www.msnmobilefix.com/Default.aspx

18 years, 2 months

16-bit sector addresses in CP/M 2.2

by ajp166＠bellatlantic.net

> >Subject: 16-bit sector addresses in CP/M 2.2 > From: Alexis <thrashbarg at kaput.homeunix.org> > Date: Fri, 08 Feb 2008 01:43:37 +1030 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >Hi, > >I'm attaching a hard drive to my 8080 computer and there seems to be >something about the way the sector translation works that's caught my >attention. Before I go wasting my time trying to figure it out myself >I'll ask here because there's going to be someone who knows (it's 1:30am >and I'm feeling a little lazy). > >Observe the following code: > >sectran: > ;translate the sector given by BC using the > ;translate table given by DE > xchg ;HL=.trans > dad b ;HL=.trans(sector) > mov l,m ;L = trans(sector) > mvi h,0 ;HL= trans(sector) > ret ;with value in HL > >>From a standard CP/M BIOS. Firt off that is for for up to 65536 sectors (per track). As that directly maps to only sectors on a track and only for 128byte logical sectors. (typically it's less than 64 for most disk drives) >My question is does the BDOS use this as a 16-bit value, or does it cut >it to an 8-bit value, like sectran does. H is loaded with 0 and L is >loaded with the translated sector. > >I'm thinking that if this is the case, then a total of 256 tracks * >65536 sectors * 128 bytes = 2048MB. This could be done without a massive >translation table by transferring the desired sector, BC, into HL. It would be that if for only one thing. The math is not way. The calulation is 65536 sectors total or 65536*128 or 8516608 (8mb). It's really a result that all math truncates to 16bits. there are BDOSs that fix this (P2DOS, Suprbdos, Novados, ZRdos...) and can do the full 2Gb. > >I've only just started writing the CBIOS for the hard drive interface >and I don't really want to waste my time on pointless endeavours. Define pointless.. The problem is if your using a LBA HD or CF that has more than 8MB then you have to partition the drive. Also for LBA addressing there are some track and sector tricks that can be applied as well for deblocking. >It wouldn't make sense to use 16-bits for a sector register and 8-bits >for a track register if you're only going to use 8-bits of the sector >register, but perhaps the upper 8-bits are used for internal flags or >error conditions? You might. >Another thing is that the total sectors per track in the Disk Parameter >Block is a 16-bits, not 8-bits. It allows up to 16bit values for both track and sector. While floppies never use more than byte values the parameters passed to the BIOS is a word and it's at your choice to truncate to byte. Caveat: For floppies and smaller hard disks they are CHS, usually cylinders needs a byte for floppy but hard disks it may have more than 256 cylinders. Both however rarely have more than 64 logical sectors per track so a byte works. The gotcga is devices like Ramdisks, CF and larger IDE drives are or can be LBA where it's easier to look at it as 1 track of 65536 sectors or 65536 tracks of one sector or anything that multiples out to 65536! Where the byte/word thing is important is this case: Hard disk organized as 16spt (assume they are 128 byte sectors which rarely happens) and 8192 tracks for 16mb. Thats a total of 131072 sectors. So to use it all you partition it in the bios as two drives and one has an offset(reseverd tracks) of half the total tracks or 4097. That means the parameter for tracks passed will be a word as you need at least 13bits. CP/M does handle that correctly. It's gets discussed but not often and it's straight forward and not obvious. The CP/M alteration guide is plain poor on why or how. the only book that explains this reasonably and you have to read the whole book to get all the bits is Andy Johnson-Laird, The Programers CP/M Handbook. I have done enough things with CP/M and it's bios to have the need to understand it and that books was both best and good reference. Prior to that I had to infer, guess and test to see what was really happening. As a result when I do a bios SETTRACK, and SECSEC stores a word value and else where I can then selectivly chose to use a byte or word. Also SECTRAN (AKA skew) is a allways NUL routine in my BIOS as it's useless when drives that have sectors larger than 128 bytes. For hard disks and CF/IDE types it's never used as they are too fast. If I need Sectran functionality I do it at the device level rather than have BDOS do the work. You may use it if you wish and it applies well for any disk that is SD especially for 8"SSSD. Hope that helps. Allison

18 years, 2 months

abandoned Sun facility

by aek＠bitsavers.org

> Are you sure it wasn't an 11/44? I now have that machine, and Mike (who > said you worked for him) told me that it was the brewhouse supervisory > machine. You're right. Have you talked to Mike recently? I haven't seen him for a couple of years. > I also got his VAX-11/780 Did you get any of the software collection? He had some very rare stuff. Sigh.. I can remember the exact layout of the stuff in the PCS basement.. At one time, the 11 and 8 systems were on the second floor. My desk was about a foot from two RP03 disks.

18 years, 2 months

16-bit sector addresses in CP/M 2.2

by thrashbarg＠kaput.homeunix.org

Hi, I'm attaching a hard drive to my 8080 computer and there seems to be something about the way the sector translation works that's caught my attention. Before I go wasting my time trying to figure it out myself I'll ask here because there's going to be someone who knows (it's 1:30am and I'm feeling a little lazy). Observe the following code: sectran: ;translate the sector given by BC using the ;translate table given by DE xchg ;HL=.trans dad b ;HL=.trans(sector) mov l,m ;L = trans(sector) mvi h,0 ;HL= trans(sector) ret ;with value in HL >From a standard CP/M BIOS. My question is does the BDOS use this as a 16-bit value, or does it cut it to an 8-bit value, like sectran does. H is loaded with 0 and L is loaded with the translated sector. I'm thinking that if this is the case, then a total of 256 tracks * 65536 sectors * 128 bytes = 2048MB. This could be done without a massive translation table by transferring the desired sector, BC, into HL. I've only just started writing the CBIOS for the hard drive interface and I don't really want to waste my time on pointless endeavours. It wouldn't make sense to use 16-bits for a sector register and 8-bits for a track register if you're only going to use 8-bits of the sector register, but perhaps the upper 8-bits are used for internal flags or error conditions? Another thing is that the total sectors per track in the Disk Parameter Block is a 16-bits, not 8-bits. Apologies if this has been discussed and I've missed it. (Perhaps someone can provide a link if it has been) Alexis.

18 years, 2 months

abandoned Sun facility

by aek＠bitsavers.org

The Sun building was Ford Aerospace on the Palo Alto side of San Antonio road. > Actually, it looks like the abandoned Pabst brewery has more > interesting electronics in it. yup, the vt100 was there as part of a supervisory control system the company I worked for installed in the mid 70's. Industrial 14's and an 11/34. You don't forget the smell around those brewing kettles or the fact they served beer in the lunch room.

18 years, 2 months

cctalk Digest, Vol 54, Issue 12

by pechter＠gmail.com

On Feb 7, 2008 6:16 AM, <cctalk-request at classiccmp.org> wrote: > > Message: 6 > Date: Wed, 6 Feb 2008 19:39:17 +0000 > From: Ethan Dicks <ethan.dicks at usap.gov> > Subject: Re: VAX-11730 (was Any word on OS/2 for PDP-11?) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <20080206193917.GC17779 at usap.gov> > Content-Type: text/plain; charset=us-ascii > > On Wed, Feb 06, 2008 at 08:12:11AM -0800, Bob Armstrong wrote: > > >Ethan Dicks wrote: > > > > >The 11/730 (and 11/725) has an on-board FEP - an 8085. You talk to > > >it much in the same way as you do to the LSI-11 in an 11/780, except > > >its console medium is TU58 tape, not RX01 disk. Syntactically, though, > > >I believe it's similar (I know the KA730 well, but not the KA780). > > > > Indeed, the 730 CFE (Console Front End or FEP) was very much like the > 780 > > - the commands were similar and the 730 even used indirect command files > for > > functions like booting and power up loading of microcode. All the > > microstore on the 730 was RAM; the only ROM was a little EPROM that > booted > > the 8085 operating system from the console TU58. Everything else - all > the > > CPU microcode, the microcode for the IDC (integrated disk controller) > the > > FPA microcode, and VMB - were all loaded from the TU58. Although the > 8085 > > operating system was some custom thing DEC wrote themselves, the TU58s > used > > an RT11 file system (again, just like the 780) and you could easily > > manipulate them with EXCHANGE or FILEX. > > That all sounds familiar. > > > The bad news was that TU58s are really, really, slow. With all the > > microcode and indirect files that had to be read from the TU58, your 730 > > could easily take ten minutes from power on to the point where VMB was > even > > ready to start thinking about loading VMS. When working on one, you > want to > > do everything you can to avoid turning off the CPU box power:-) > > Using the stock console tapes from DEC, that was absolutely true. One of > the scripts I wrote a while back, built a load-order optimized console > tape. > I think the 8085 must cache the directory, since the tape doesn't seek > back > to the directory blocks between each file. With the files in the right > order, > the file transfer time doesn't change, but the file-to-file time is just > about > nil (I think there may be one seek from end-to-end because of how many > files > there are to read and the block interleave on the tape). > > > Because everything about the KA730 microcode was "soft", it's fairly > easy > > to change the CPU microcode, update the console TU58 and reboot to > change > > the CPU behavior. I believe DEC even sold a set of microprogramming > tools > > for the 730, but I've never seen them and I don't know what's become of > them > > today. > > Back in the day, I remember occasionally seeing docs on PDP-11 > microcoding, > but I don't recall seeing anything for any model of VAX. > > -ethan > To do it on the 11/780 you needed to putchase the optional second WCS (Writable Control Store) board. The first WCS board was used for patches for microcode bugs from DEC. > > -- > Ethan Dicks, A-333-S Current South Pole Weather at 6-Feb-2008 at > 19:20 Z > South Pole Station > PSC 468 Box 400 Temp -48.6 F (-44.8 C) Windchill -75.5 F (-59.7C) > APO AP 96598 Wind 8.2 kts Grid 50 Barometer 675.4 mb (10802 > ft) > > Ethan.Dicks at usap.gov > http://penguincentral.com/penguincentral.html > > > -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com

18 years, 2 months

VAX microcode (was: VAX-11730)

by bqt＠softjar.se

Ethan Dicks <ethan.dicks at usap.gov> skrev: >> Because everything about the KA730 microcode was "soft", it's fairly easy >> to change the CPU microcode, update the console TU58 and reboot to change >> the CPU behavior. I believe DEC even sold a set of microprogramming tools >> for the 730, but I've never seen them and I don't know what's become of them >> today. > > Back in the day, I remember occasionally seeing docs on PDP-11 microcoding, > but I don't recall seeing anything for any model of VAX. I have the documentation for the VAX-86x0 micromachines... And I have the hardware. Want to do something? :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

18 years, 2 months

abandoned Sun facility

by rtellason＠verizon.net

http://www.abandonedbutnotforgotten.com/sun_microsystems.htm Rows of servers? A heck of a mess, there, and I have no idea what I'm looking at in terms of any of that equipment... Thought it might be of interest to some, anyhow. -- 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, 2 months

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

by cclist＠sydex.com

> Date: Tue, 05 Feb 2008 20:25:07 -0500 > From: Allison > 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. My point was "documentation" of these instructions as such was unnecessary. Had the documentation simply said "---", they wouldn't have been used, freeing the codes for later exploitation. But once documented as valid moves, there's no going back. 00H was the only *documented* no-op as such. But it's all 20-20 hindsight. Cheers, Chuck

18 years, 2 months

FT: Symbolics XL1201

by derschjo＠msu.edu

I recently acquired a Symbolics XL1200 and so my XL1201's been sitting dormant and I just can't justify letting such a cool piece of hardware go unused; as such I'm thinking of trading it for something of approximately equal "coolness value" if anyone's interested... The XL1201 is the "desktop pizza box" variant of the XL1200 and includes: - 4MW RAM, FPA, latest IFEP ROMS (allow booting from large SCSI disks, amongst other things...) - "Old Style" console w/keyboard & mouse - External 9gb SCSI drive w/Genera 8.3 & layered products installed - Genera 8.3 installation media (on CD) - Printed documentation set (optional if shipping is an issue) The machine is clean and is in good working order, located in the Puget Sound area. I'm mostly interested in old workstation-style hardware, I'd be interested in trading for the following: (In no particular order. Note that the realism of some of the following is questionable :) - Xerox D-Machines - Early SGI IRIS machines (1000/2000/3000, etc.) - Other Lisp-based hardware (TI Exploder, etc... kinda want a big 3600-series Symbolics, but I don't know if I have the space :)) - Sun2 hardware - PDP-11's with blinkenlights (hey, a man can dream, can he not?) - Transputer-based hardware - IMSAI 8080 or Altair 8800 - IBM 5100 with APL option (ha ha ha) If you've got something interesting to trade, let me know... Thanks, Josh

18 years, 2 months

abandoned Sun facility

by jfoust＠threedee.com

At 06:19 PM 2/6/2008, Jason T wrote: >> On 6/2/08 23:58, "Eric J Korpela" <korpela at ssl.berkeley.edu> wrote: >> >> > Actually, it looks like the abandoned Pabst brewery has more >> > interesting electronics in it. >> > http://www.abandonedbutnotforgotten.com/Abandoned%20Pabst%20Brewery.htm > >Hmm....wonder how long ago those pics were taken. Not far from me at all..... ;) It's in downtown Milwaukee, adjacent to the freeway. As with any of these places, I doubt you want to get caught by the police. Some is gone already: http://milwaukeestreets.blogspot.com/2007/10/pabst-brewery-demolition.html - John

18 years, 2 months

Looking for TK50 tapes & RX50 disks...

by silvercreekvalley＠yahoo.com

Hi, I'm in the process of restoring a 11/83 back to health. Its going OK so far, but I'm in need of some TK50/70 tapes for the tape drive and some RX50 5.25" disks. The RX50 disks - I'm assuming are different to regular 5.25" floppy disks (DSDD) - I do have some of those, but I'm told the magnetic composition of the RX50 disks is different? Finally, someone has changed one of the RX50 disk units for what looks like a standard (PC style) 5.25" disk drive. I'm just wondering if this was a standard thing to do, or a bodge? All the best Ian. ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

18 years, 2 months

making backups of IRIX media

by jlobocki＠gmail.com

hello, I need help making backups of my valuable IRIX media. I have heard that you can use CDRWIN, and i did, which made a decent backup, except I couldnt boot >from the copy, and CDRWIN wont work properly on my laptop. is there any good windows based program that would copy and image my IRIX media and keep them bootable? if none for windows, i do have ubuntu linux loaded, although not compatible with my network devices so it is rarely used and cant download things. thanks!! -Joe

18 years, 2 months

Any word on OS/2 for PDP-11?

by tshoppa＠wmata.com

Der Mouse wrote, in response to the spat between me and Dan Gahlinger, > And, both of you, I don't care who you are and when you were working > with what; the kind of remarks you've been throwing at one another are, > in my opinion, way over the top. When somebody comes here posting way over the top crap, what are we supposed to do? The "egging him on" of trying to take his words and correct them so that they could've been true, thus giving him some credence, is IMHO is a far worse disservice to computing history. I tried to give him the benefit of the doubt and he told me I was wrong. I think that paying him any attention at all was a mistake for all of us - every iteration he's making up more crap. Tim.

18 years, 2 months

Whitechapel Workstation - schematics

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, 2 months

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, 2 months

"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, 2 months

"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, 2 months

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, 2 months

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, 2 months

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, 2 months

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