test-drb February 2008

test-drb@ccmp.vtda.org

236 participants
373 discussions

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

by cclist＠sydex.com

> Date: Sun, 03 Feb 2008 07:34:54 -0500 > From: Allison > NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. There were also the independent implementations such as TPM (for the QX-10) and TuboDOS. There were others, even a a couple that provided the capability to run CP/M 2.2 programs under non-CP/M OS Z80 platforms. CP/M, particularly 2.2 was easily cloned. Most applications used the information in the reference manual set and didn't rely on "undocumented" features. IIRC, the bigger problem when MP/M came along, was trying to work with those programs that were just plain sloppy and performed file open requests without closing the file (since CP/M didn't even keep so much as an open file count, you could be very sloppy, even opening a file multiple times or not at all (as long as you filled in the FCB fields correctly). Some programs saved FCBs and then used them later. I wanted to add a "put that diskette back" alarm to my CP/M implementation when there were files opened for writing (one needn't even turn on the drive motor--just periodically sample the write- protect status; a diskette being inserted or removed will toggle it a couple of times). I'd already done it for DX-85M and it reduced our diskette file corruption problems to nearly zero. That "R/O error" diagnostic from CP/M was unreliable at best and nearly useless even when it worked. It was then that I discovered that CP/M made no attempt to track open files and indeed, the behavior of many programs depended on this. Cheers, Chuck

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: "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"? > >(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... That was easy in 8080. ;routine gets 16bit word passed on stack before call ; doesn't do anthing but put that item in bc RRST: org 010h shld hlsave pop hl ;hl has return address pop bc ; BC has data push hl ; hl back to stack lhld hlsave ; restor hl ret ;caller caller: push bc ;data in bc rst2 ...... >> 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? Interrupt driven, has some basic terminal sense (vt100 specific) and uses IObyte. > >> 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... In many cases no buffer. it was more like the other end would stop but by time you told it to your 1 byte maybe 2 buffer overflowed. Often the probem with byte at a time IO without interrutps. A more reasonable IO would be buffered 64 or 128 chars sing style with high water marking. Interrupt driven of course. >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. 16k was magical as that was the size of a standard CP/M extent and usually assumed to be enough space for capture. Allison > >(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

16 years, 10 months

compaq portable plus problems

by marvin＠west.net

When I am using debug to format a HD on an unknown controller, I'll do an unassemble at C800:5 and C800:6. The correct address will have a jmp instruction. Besides the HD formatting program on the utilities disk, going *way* back, I think Western Digital put out a formatting program WDFMT (?) that would allow the formatting of MFM HDs. I think there also might have been some PD/shareware programs to do the same thing. Assuming the Simtel archives are still around, I would expect to be able to find these programs there. > From: Roger Pugh <rogpugh at mac.com> > > does anyone know the correct incantation to low level format an MFM > drive, a rodime 351, driven by a Compaq controller board. > > I,ve tried with debug G=C800:5 to no avail. there is no format program > there!.

16 years, 10 months

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

by cclist＠sydex.com

> Date: Sat, 02 Feb 2008 13:07:03 -0500 > From: Allison <ajp166 at bellatlantic.net> > Actually PDP-8 OS8 started that, all the other DEC OSs TOPS-10 and RT had > it as well. "PIP" should be the giveaway. Odd that ISIS used "COPY xxx TO xxx". Some hated the mandatory "TO" in ISIS copy, but I thought it was a good idea. How many times under MS-DOS have you mistakenly typed "COPY D:*.*" and then hit the "enter" key before completing your thought? On faster machines, it makes a mess before you can stop it. The PIP "mathematical" syntax with all the strange options could be confusing in CP/M; some vendors supplied their own version of a file copier. > 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. On the other hand, fragmentation on a floppy can result in very bad performance--and CP/M had no "defragment" utility. I can see the advantages of a system that tends to keep files in a small number of pieces. I've seen the single-piece file structure a lot on industrial equipment controllers. > 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. CP/M was singularly ill-equipped to support hard disks of any size beyond a couple of megabytes. We'd started offering SA-8000 14" drives as an option and before too many months, we were getting 40MB drives for what we'd been paying for the single-platter ones. 5.25" HD size increases went even more quickly. We bought 7 and 14MB drives from Rodime and it wasn't long before Rodime was telling us that they were substituting 10MB and 20MB drives. I was asked if I could artificially (via software) limit the new drives to 7MB and 14MB so that marketing could charge for the extra storage. I discouraged the idea very strongly, pointing out that the customers weren't stupid--someone was going to peek inside and read the drive nameplate. CP/M's single-level directory wasn't suited at all to this kind of thing, even using the "user number" feature--something for which DRI never came up with a command-line syntax to express, which further hurt matters. But then DRI was really thinking of the "user number" feature as that- -there was the system (user 0) and your own files under your number, never considering that some users might want to use the feature to organize their data and go cross-number frequently. Cheers, Chuck

16 years, 10 months

How not to fix a classic mac (or: fried logic boards)

by trag＠io.com

>Date: Tue, 13 Nov 2007 11:17:41 -0600 (CST) >From: "Jeff Walther" <trag at io.com> >Subject: Re: How not to fix a classic mac (or: fried logic boards) >To: cctech at classiccmp.org >Message-ID: <12318.209.163.133.242.1194974261.squirrel at webmail.io.com> >Content-Type: text/plain;charset=iso-8859-1 > >> Date: Mon, 12 Nov 2007 22:45:09 -0800 >> From: Josh Dersch <derschjo at msu.edu> >> First point of business, I discharged the CRT. >> To the main chassis. This, as I have now discovered, is not what you >> are supposed to do to discharge the CRT unless you want to destroy the >> logic board. >That particular failure is documented in Larry Pina's "Macintosh Repair >and Upgrade Secrets" and probably in "The Dead Mac Scrolls" as well. I'd >look it up for you, but I don't have my books with me here. Okay, I'm home, I have my books. It says on page 98 that discharging the CRT without a big honking resistor may blow a 74LS38N (U2) on the analog board and the LAG chip on the logic board. The former sounds like it might be fairly standard. The latter sounds like it may be one of the custom programmed PALs or GALs or whatever that Tony was writing about. I wouldn't be surprised if folks had already figured out all the internal logic for the various Mac 128/512/Plus chips though. Finding it might be a bit of a challenge. OTOH, the LAG chip may be fine and it could be U2 on the analog board that has the problem. Jeff Walther

16 years, 10 months

MC3470

by aek＠bitsavers.org

> Also, does anyone have a proper data sheet for the MC3470 (disk read > amplifier etc). A reasonable description appears in the Semens FD100 service manual. The best analysis of a floppy read channel I have ever read appears here: http://bitsavers.org/pdf/shugart/SA850_450_Read_Channel_Analysis_Dec79.pdf

16 years, 10 months

Q-BUS primer?

by tiggerlasv＠aim.com

On 04-Feb-08, Jerome H. Fine wrote: >Probably your best option is to use the BA23 box. However, for that >option, you really need a quad M8189 CPU (PDP-11/23) >or a quad M8190 CPU (PDP-11/73). >It is entirely possible to use the dual M8186 CPU (PDP-11/23), however, >you will then require a controller with a boot ROM (usually only available >with a 3rd party disk controller) or you will need to enter the >boot program via ODT each time you power on the system. If you look carefully down the list, he's got an M8047 - MXV11 with (P)roms, so he'll be able to use the 11/23 that he already has, and, depending on the roms installed, should be able to perform an MSCP boot. >Entering the boot program manually (by hand one instruction at a time) >takes about 5 minutes. A boot program for the MSCP M7555 controller >is available. Entering bootstrap by hand? Eeek! That is what macros on terminal emulators are for. ;-) ________________________________________________________________________ More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com

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: "Dave Dunfield" <dave06a at dunfield.com> > Date: Mon, 04 Feb 2008 07:21:16 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >> >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... >> >> That was easy in 8080. >> >> ;routine gets 16bit word passed on stack before call >> ; doesn't do anthing but put that item in bc >> RRST: org 010h >> shld hlsave >> pop hl ;hl has return address >> pop bc ; BC has data >> push hl ; hl back to stack >> lhld hlsave ; restor hl >> ret >> >> ;caller >> caller: push bc ;data in bc >> rst2 >> ...... > >I don't think he was talking about pushing data on the stack, >I thought he was refering to putting the system service request >number inline with the code. The way you can "force that" in cpm is use the above code to call say RST2 where the call is broken out and organized in registers per cpm normal. It also has to preserve registers and adjust the returned data to be on the stack but it's not that bad. >This is exactly what I do on both my DMF (8080) and CUBIX (6809) >OS's. Understood and like it better too. However it's more natural for 6809 where 8080/z80 is kinda clunky around playing with stack. >I use an 'SSR' macro which looks something like (DMF/8080): > >SSR MACRO > RST 2 > DB \1 > END > > >It's fairly easy to fetch this: > >SSRENT: STA savea ; Save accumulator > XTHL ; HL = calling address > MOV A,M ; Get service request number > INX H ; Skip for return > XTHL ; Restore HL & new return address >; Now you have the SSR number in A >; most likely you would use it to index into a handler >; table sith something like: (untested) > PUSH H ; Save application HL > MOV L,A ; L = SSR number > MVI H,0 ; Zero high > DAD H ; x2 for two byte entries > PUSH B ; Save BC > LXI B,JMPTAB ; Point to jump table > DAD B ; Offset to table > POP B ; Restore B > MOV A,M ; Get low address > INX H ; Advance to high > MOV H,M ; Get high address > MOV L,A ; Set low address > XTHL ; Restore HL, dest on stack > LDA savea ; Restore A > RET ; Jump to caller That mkes the code read easier and may be easier to maintain but that hides whats really there unles you unroll the code. > >'JMPTAB' would contain a series of 2-byte addresses of >the individual SSR handlers. > >In practice it's usually a bit more complex ... iirc >in my SSR entry I save most of the registers (so that >the handlers don't have to) and switch to my own stack >(but it's been a very long time so I may be mistaken). > >In the application code, you can then do things like: > > MVI A,'?' ; Get prompt > SSR 3 ; Output to console (two byte OS call) > > >Dave Those are interesting ways to deal with it that I'd not have done. Chalk that up to lack of imagination on my part. Allison >-- >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

Simple peer to peer network?

by brain＠jbrain.com

Sellam wants to finish the 64 c64 cluster for the next VCF. I've been researching ideas for communicating among the machines, and the best ideas point to using the two synchronous serial ports on the user port (low wire count, transfers at 250kbps). But, I have grawn a complete blank on plans for a true peer to peer (token based or otherwise) networking protocol. Everything I see is master/slave. RS485 material talks about the hardware layer, but there is no detail on the protocol layer. I would think this would be a well researched and innovated area, low speed communication without a master node. Anyone have any pointers for things to look into? Jim

16 years, 10 months

Good Books

by technobug＠comcast.net

A couple of good books showed up on one of the remainder vender's lists at substantial discount that might be of interest to the list: Item 7036752: Power Supply Troubleshooting and Repair - switch mode power supply repair Item 6324134: Semiconductor Cross Reference Book Found at <http://edwardrhamilton.com/> (mail ordering) <http://www.hamiltonbook.com/hamiltonbook.storefront> (on-line ordering) CRC

16 years, 10 months

← Newer
1
...
30
31
32
33
34
35
36
37
38
Older →

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