test-drb February 2008

test-drb@ccmp.vtda.org

236 participants
373 discussions

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Holger Veit" <holger.veit at iais.fraunhofer.de> > Date: Sat, 02 Feb 2008 12:31:30 +0100 (CET) > To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> > > >Allison said: >> We can look back at CP/M and call it primitive but it was for the >> time a fair improvement and inovation. One only has to look at the >> 8080/z80 DOS of the day and compare, There were few really viable >> choices that werent tied to a fixed hardware or non-portable. > >>From the design, it looks as if CP/M was modelled after DECs RT-11. Actually PDP-8 OS8 started that, all the other DEC OSs TOPS-10 and RT had it as well. >It >became fashion there to interpret everything as a named device; some of >these contained structured data - namely a file system (in contrast, Unix >had the complementary paradigm: everything is a file in a single rooted, >hierarchical name space, and some files are actually devices). >RT-11 was by magnitudes more evolved than CP/M and its children CP/M-86 >and >PC/MS-DOS, when it comes to interrupt and DMA capabilities. Most real time OSs were better and of course most minicomputer system OSs exploited the hardware better. However while the IO was better CP/M had a far better file system that accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had the linear tag and dump that made enlarging a files or creating variable length files harder. >The 8080 and >Z80 CPUs were equipped by Intel/Zilog with a rich set of support chips - >so it could have been done *right*. S-100 was not designed right WRT IRQ >and DMA; maybe this was one of the stumbling blocks. True, the caveat then was the Z80 was not cheap but it saved hardware over 8080 so and it worked in practice as cheaper. The Zilog peripherals while very sophisticated were never cheap and the DMA was late and expensive (and never ran faster than 4mhz). Also S100 was one bus that really made putting Zilog peripherals off the CPU board difficult. When people started doing SBCs based on Z80/CTC/SIO DMA was left out for space (yet another 40 pin chip) and cost. The 8257 and 8237 while cheaper still suffered the cost/space (40pin plus what the octal latch needed) problem. However systems that did use DMA offered performance (AC85 was 8085 with 8257 for example) and of course the Compupro S100 cards that did DMA for floppy. That performance increase may have helped CP/M systems live for years longer before the 286 and faster machines with graphics started to offer a real advantage. What is funny to me was every one was looking for 16bits and faster when at that time I could see that 16 bit was nice but faster transfers and larger storage was the prime mover and offered the greater applications flexibility. People were chafing against multiple floppies and multiple foppy drives to do even the basic databases and the like of the day. Anyone thats has used a CP/M system with a pair of SSSD 8" floppies of around 241K usable space and then went to DSDD at 1MB or added a 5MB hard disk knew this. Assemble CP/M BDOS at around 100k using ASM and you find any disk under 400K free space is too small. You still see that today with faster disks and interfaces. Allison >-- >Holger

16 years, 10 months

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Chuck Guzis" <cclist at sydex.com> > Date: Thu, 31 Jan 2008 18:56:41 -0800 > To: cctalk at classiccmp.org > >> Date: Wed, 30 Jan 2008 18:27:23 -0500 >> From: Allison > >> Things like Termcap and the lise were not needed. However the console IO >> was not so good. Try printing a string containing $ using the print >> string call. The other was passing 8bit data when needed. > >Many avoided the issues with the BDOS and simply went through the >CBIOS vector. That's why it was important that your "cold boot" jump >at 0000 point to the proper entry in the BIOS jump vector list and >not to the cold boot routine directly. A lot programs used the cold >boot jump at 0000 to find the BIOS jump list--just take the address >in the jump instruction and set the low byte to 00. Done right it was portable. However I encounterd at least one system where the BIOS calls were unusuable for 8bit serial because every transaction in or out was masked with 07Fh.. >Timer as well as console interrupt I/O was pretty much necessary for >MP/M functioning (interrupt-driven disk I/O was *strongly* suggested) >and recommended for CP/M 3.0, as was bank-switching. > >I did a CP/M 2.2 implementation using interrupt-driven I/O for >everything but the memory-mapped display. It worked pretty well, but >the effort was wasted for the disk I/O--there was nothing to do while >you were waiting for the operation to complete. On the other hand, >it did make writing an MP/M XIOS much simpler. I'm still running a cp/m S100 box with interupt driven everything including disk. the disk get a parameter block and start and goes and pulls and interrupt wwhen done. It has local cpu for the IO. What to do with the freed up cycles... print spooler was first rans as a system background job as part of the BIOS. Later I tried other things but printing was a big step forward. At that time still using V2.2 I started working with romdisk/ramdisk and banked BIOS and having the bios where it could be any size I wanted with large buffers allowed for lots of things. > >> IObyte was mostly uniform, the problem was often it wasnt even >> implemented. This was a problem of allowing the BIOS spec to be >> minimal and it usually was. > >The problem with IOBYTE is that it was defined in terms of console, >reader, punch and list. Well, most systems didn't have a "reader" or >"punch". This made what to do with those items a matter of >implementation. BDOS Function 3 is defined as "Reader Input" and 4 >as "Punch Output". Yes and Reader didn't have a status bypass so once it was called you hung if nothing was happening. I used to make them null and return(0). I cound never thing of a good use for either Punch or Reader. Since the rules didn't say they were required... I didn't. > >> Ignorant, I think no, they gave the hooks and basic requirements. It was >> up to the BIOS developer to do a good job or just enough. > >By the time that 2.2 was offered, most CP/M systems were CRT oriented >with a printer and perhaps a serial port used to connect to a modem. >Instead of acknowledging that as the model configuration, DRI >stubbornly stayed with TTY and paper tape as their model of character >I/O. Not quite but very soon after. The problem was the paradiem of V1.4 was ingrained enough already. What DRI stuck with for a model was not what it had to be and that was their error. What was implmented generally for a BIOS was a whole other story. We can look back at CP/M and call it primitive but it was for the time a fair improvement and inovation. One only has to look at the 8080/z80 DOS of the day and compare, There were few really viable choices that werent tied to a fixed hardware or non-portable. Allison > >Cheers, >Chuck > >

16 years, 10 months

information on ancient matsushita/panasonic ICs

by frustum＠pacbell.net

A friend is stymied in getting his emulator for the Panasonic JR-200 computer complete. The machine uses some parts that are long discontinued. I'm hoping someone here might have an old databook that contains more information that can currently be found on the web. The MN1800A was apparently equivalent to the 6802. He has that working and so no mystery there. I just bring it up since the other parts were perhaps related. MN1544 -- here is the most information I can find after an couple hours of googling: 4-Bit Microcontroller-Microcomputer On-Chip RAM (Bytes)=1k On-Chip ROM (bytes)=4k Number of Interrupt Lines=2 Number of Maskable Interrupts=2 No. of I/O Ports=6 Vsup Nom.(V) Supply Voltage=5.0 Package=DIP Pins=N/A Military=N Technology=NMOS MN1271 -- Likewise, MN1271 Peripheral Interface Adapter (PIA) - Universal Interface Adapter Word Size=16 Data Transfer Type (S/P)=Multimode Vsup Nom.(V) Supply Voltage=5.0 Package=DIP Pins=64 Military=N Technology=CMOS If anybody has any more information than this, my friend would appreciate it. BTW, his emulators, including the JR-200, are here: http://www.geocities.com/emucompboy/ Thanks

16 years, 10 months

DEC LA180 printer (&LA100)

by dm561＠torfree.net

Date: Fri, 1 Feb 2008 09:37:40 -0500 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: DEC LA180 printer On Feb 1, 2008, at 6:35 AM, Rick Murphy 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. > LA36 and LA180 are the same mechanism? Are you sure? I don't >recall much similarity there, especially in terms of speed. > -Dave ------------- I'll be scrapping some more LA100s (RO) shortly; any useful parts in there for anyone? I believe that at least some parts are compatible with the LA210 and others, including the LA34 & 38; can someone confirm that? Also an LJ500 (B2), although it's probably clogged and I don't expect much interest... TIA, mike

16 years, 10 months

Stuff to see in Denver area?

by evan＠snarc.net

Business is leading me to Denver for a few days at the end of February. Might have a spare day to play tourist. What should I do or see there? Any collectors out there want to meet up?

16 years, 10 months

Anyone near Spokane Valley, Wa. who can make a 5.25" ImageDisk?

by dave06a＠dunfield.com

I have been contacted by a gentleman in Spokane Valley, Wa. who has recently acquired a Zorba and wishes to obtain system diskettes for it. Is there anyone on the list near there who can recreate the Zorba disk images from my site? They are in ImageDisk format, 5.25" 40 track double-density only - Any system running DOS or Win9x with a 5.25" drive should be able to recreate them for him. If you can help, please contact me off-list for details. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

16 years, 10 months

2.11BSD Patch 445; FPSIM fixed; 211bsd runs on systems without FPP

by W.F.J.Mueller＠gsi.de

A note to all 2.11bsd users: Some time ago I looked into running 2.11bsd on systems without floating point unit. The release notes state that this is untested and unsupported, and indeed it didn't work. Robin Birch some time ago fixed part of the issues, see patch 434, but still the kernel paniced when the very first program was started. I managed to localize and fix the problem in sys/pdp/mch_fpsim.s. Steven Schultz right away issued 2.11BSD patch #445. All patches up to and including 445 are provided by Steven under ftp://sg-1.ims.ideas.gd-ais.com/pub/2.11BSD A patch level 445 system will now boot on simh for example on a set cpu 11/70 nofpp 4m configuration and work just fine, albeit a little slower. It should thus also work on a real 11/70 without FPP. I heard of some 11/70 with non-working FPP's, so this maybe good news for the owners. With best regards, Walter Mueller -- Dr. Walter F.J. M?ller Mail: W.F.J.Mueller at gsi.de GSI, Abteilung KP3 Phone: +49-6159-71-2766 D-64291 Darmstadt FAX: +49-6159-71-3762 URL: http://www-linux.gsi.de/~mueller/

16 years, 10 months

DEC LA180 printer (&LA100)

by ajp166＠bellatlantic.net

> >Subject: Re: DEC LA180 printer (&LA100) > From: M H Stein <dm561 at torfree.net> > Date: Fri, 01 Feb 2008 14:54:19 -0500 > To: "'cctech at classiccmp.org'" <cctech at classiccmp.org> > >Date: Fri, 1 Feb 2008 09:37:40 -0500 >From: Dave McGuire <mcguire at neurotica.com> >Subject: Re: DEC LA180 printer > >On Feb 1, 2008, at 6:35 AM, Rick Murphy 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. > >> LA36 and LA180 are the same mechanism? Are you sure? I don't >>recall much similarity there, especially in terms of speed. LA36, 120 and 180 were mechanically similar but that about it. the logic and a few other detils were different. >> -Dave >------------- >I'll be scrapping some more LA100s (RO) shortly; any useful parts in there >for anyone? I believe that at least some parts are compatible with the LA210 >and others, including the LA34 & 38; can someone confirm that? The LA210 is a varient of the LA100RO for most mechanical parts. The la210 and LA100 shared the same print head, ribbon, carriage motor platten motor, font carts, and a few other bits. Again they were related so many parts could be shared but the logic board for each were differnt. Things you want to save are power supplies, print heads, drive motors, ribbons, and the litle one way clutch used for the ribbon advance. Allison >Also an LJ500 (B2), although it's probably clogged and I don't expect much >interest... > >TIA, > >mike > > > > >

16 years, 10 months

Chip ID and datasheet?..

by bpope＠wordstock.com

All, I am trying to ID a chip from a SFD-1001 motor control board. This is printed on the chip: JAPAN SERVO SA1001 3A It looks like a normal DIP, except for the middle pins which look to be twice as wide. Is this for heat sinking? I have tried searching for this chip but so far have found nothing. The board has this marking; PC-368C JAPAN SERVO TDK-T15V Which also has not turned up anything useful.. The 5 1/4" drive mech this board is connected to was made by Matsushita and its model # is JU-570-2. From reading the SFD-1001 technical manual, the 5 1/4" mech is just listed as a part so it does not have any detailed information for this board. :( Cheers, Bryan

16 years, 10 months

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Chuck Guzis" <cclist at sydex.com> > Date: Wed, 30 Jan 2008 10:57:15 -0800 > To: cctalk at classiccmp.org > >> From: "Joshua Alexander Dersch": > >> Were there similar problems in the CP/M world? That is, was it >> commonplace for there to be CP/M programs that bypassed CP/M BDOS calls >> and wrote directly to a specific machine's hardware? Seems like CP/M >> developers were more disciplined in this fashion, but maybe it's just >> because in the CP/M arena there were so many different pieces of hardware >> it was the only way to do it? (Whereas with IBM, the PC was seen as more >> of a reference standard, even if it wasn't really that way in the >> beginning?) > >The great thing about CP/M (and I'm talking about the 8-bit version >here) was that it imposed a file system and made disk I/O uniform-- >128 byte sectors, regardless of how the information was actually >formatted onto a drive. CP/M was really primitive when it came to >console I/O, giving only about 3 functions for output and input each. >No cursor positioning or screen control; basic TTY style I/O. And, >while there was an IOBYTE facility to redirect I/O, implementation >was very nonuniform between vendors. Things like Termcap and the lise were not needed. However the console IO was not so good. Try printing a string containing $ using the print string call. The other was passing 8bit data when needed. IObyte was mostly uniform, the problem was often it wasnt even implemented. This was a problem of allowing the BIOS spec to be minimal and it usually was. >As a result, for other than simple command-line utility programs and >compilers/assemblers and the like with minimal I/O requirements, most >productivity and comms programs had to go to the hardware directly >for display and communications. > >And that, I think was the innovation of programs such as WordStar and >SuperCalc, and, to a lesser extent MODEM7 and Kermit--that you were >running on an operating system that was basically designed for TTY >I/O with no connectivity and the majority of systems were using CRTs >and had modems. The problem became then how to make a single program >work for everyone--and that was done with custom patch overlays. > >DRI, for its part, seemed to remain blissfully ignorant of both of >these aspects. Ignorant, I think no, they gave the hooks and basic requirements. It was up to the BIOS developer to do a good job or just enough. I've repeatedly posted that if anything CP/M prevents little and you can do a great deal at the bios level to really deliver a better system. The best way to illustrate this is try a system with basic IO and one with a full interrupt drive IO. The first thing you notice is the ability to type ahead and the system feels more responsive. >Likewise, it wasn't MS-DOS that was the great advance for the IBM PC >platform, but rather the well-documented BIOS and I/O interfaces. >Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to >do your disk I/O through FCBs, just like CP/M. I believe, to this >day, you can still issue your DOS calls by loading (CL) with the >request number and calling TPA:0005. Well it was patterned (so say copied) after CP/M so.. No surpize there. ;) Allison > >Cheers, >Chuck

16 years, 10 months

Jump to page:

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