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: Thu, 31 Jan 2008 09:53:03 +0100 > To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org> > >Allison schrieb: >>> 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. >> >Termcap was very needed, but not present. Net result was that almost any >software that required terminal control beyond backspace and CRLF had to >be tweaked manually. IN that sense yes. Is it requried of the OS no. Does the OS need it, no. CP/M was minimal as it's day ram was expensive interms of cost, power and space. Was it short sighted, yes. Would it have been implmented right in 1975? No as terminals were just starting to have basic intelligence and maybe 2-3 years later what would the requirements be like? > I remember having written code to fit in the >Wordstar patch area to adapt to some obscure or not so obscure terminal >dozens of times. Termcap and terminfo under the various Unixes of the >time was god-sent then even if some entries were plainly buggy - maybe >just estimated from some hear-say information. Many others too like Vedit. It was a one time task, not nice but compact. 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. The bottom line is sans BIOS where do you put termcap in a OS thats only 5.5KB? As to unix, it was the big machine OS and was not going to run on a 256kb floppy. It was only popular in academic and research and far from mainstream till the mid 80s. >The print string BDOS function was indeed an example that was almost >immediately replaced by do-it-yourself routines, often by using the '\0' >delimiter (which then caused trouble with slow terminals that require >some delaying NUL bytes after a CRLF). Or the +80H (end of line on high bit set). >> 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. >> >IO byte, besides as you correctly remarked not being implemented at all, >was outdated soon after CP/M was released for the Altair. I haven't seen >many paper tape readers and punches connected to CP/M systems for >serious business work. IObyte did not take care of additional devices >beyond the 4 standard devices; it did not deal well with additional >serial or parallel ports for more terminals and printers. This resulted >in unofficial BIOS extensions to get such available hardware into the >boat, and again unportable programs to swap vectors in to BIOS to write >output to a second printer, for instance. Needless to say that >"well-written" software to use the IOByte failed to use these additional >devices - there was even software that insisted that PTP is dumb and AUX >is intelligent, so abusing these pseudo devices for two printers >resulted in different behaviour. Paper tape and Punch were rare in most CP/M systems and often unimplmented. I tend to implment the console and list fields (upper and lower two bits) completes to use the printer ports and second (and third serial if available). Andy Johnson-Laird The Programmers CP/M Handbook went far to extend and clarify both what the BIOS can do and more. >> 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. >> >Since the BIOS reduced the available space for BDOS and TPA - which >admittedly improved with CP/M+, which, however, IMHO came too late - >many vendors came up with a not so elaborate BIOS but rather tweaked the >sample code from DRI. It was plainly easier to add some custom program >to directly hack the non standard hardware than extend the BIOS with >useful, clever and portable features. What has been the GHz mania of the >processor later was at that time the "xxK TPA available" selling argument. Actually I'm running system with CP/M-V2.2 that page the BIOS and have multiple hard disks and a tpa in the 62-63k range. CP/M+ is not required to achive that. But both approaches need some kind of memory paging and the ram/rom and a BIOS to support it. The otehr issue is most developers didn't have a useful system interrupts or were time pressed enough to feel that it was worth it. By useful interrupts I mean.. most early S100 8080 machine if you pulled the interupt line the default was vector to 38H as that was RST7 (11111111b) which happend as a result of pull up resistors. that location is ued by DDT for trap. Early Z80s also did that. later 8080/8085 and Z80 systems implmented basic vectored interrupts so how you could use RST 2 through 6 and that meant resonable interrupt drivers wer possible. The Z80 SBCs like Ampro and others that used the Z80 peripherals all had the Z80 vectored system which was powerful and a bit intimidating to those that hand not used them before. As you can se the whole interrupt thing was not CP/M as a limiting factor but hardware or implementor understanding. 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. 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). 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. >>> 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. >>> >CP/M-86 and MS DOS were initially designed to allow a simple 8080->8086 >cross translator to run the whole set of already existing CP/M >applications without reinventing the wheel. Later DOS versions added >Xenix compatible calls (equivalents of Unix raw I/O: open, close, read, >write, lseek, unlink) but often still the well-understood FCB crap was >used. The call to TPA:0005 is still present in contemporary MS-DOS >versions, as well as INT21h calls; Thats what I believe in too for dos. >however today the "DOS box" under Windows just prepares the environment >for such old DOS programs and uses virtualization to fake an existing >DOS. You can't trace an INT21h call any longer into an MSDOS.SYS or IO.SYS. Yes thats true after NT flavored took over (NT, Win2k XP and likely vista). for win 3.1x it was dos with gui and for Win9x dos was very much there. I ahve Dos7 and dos8 which is extractable from win9x. Nothing worth reporting there. :) Allison > >-- >Holger >

16 years, 3 months

Q-BUS primer?

by dave06a＠dunfield.com

Hi Guys, Recently acquired a goodly amount of DEC gear - I had put the Q-BUS stuff aside while I got the "all in one" VAXstation/VAXservers up and running, but I'm starting to collect information - I've no experience whatsoever with Q-bus, but from what I've read, I understand that it will take a bit of research to determine how to properly configure and position the boards. I'm hoping that I have enough material to built up at least one (possibly 2) nice little PDP-11's, and/or a MicroVax II) At this point, all I'm really looking for is a good "starting point". Can anyone recomment a good document/resources for a Q-bus newbie? Btw, this is what I've got - If there's anything I'm obviously missing, or will have to find extra parts for, please advise me so that I can start looking... Three chassis: BA-23: complete with outer shell and end caps. It bears a "MicroVAX II" label on the console switch panel, and has a floppy drive (dual disk) installed in it. I don't know the model numbers for the next two: - One looks like a BA32 but smaller, and has the "3-switch" PDP console/display panel on it. The cards are inserted from the front beside the panel. - The last one is the smallest, looks much like the one above, complete with 3-switch console/display panel, however instead of metal side/top/bottom plates, it has a "wire cage". It also has a second expansion chassis of similar construction with no power supply or console panel. I've got the following DEC Q-BUS cards: (Descriptions taken from the "Field Guide to Q-BUS and Unbus modules" M3106 4-line async M7264 11/03 processor with 4-Kword RAM M7504 Ethernet adapter (older DEQNA) M7546 TMSCP controller for TK50 M7555 Winchester and floppy disk controller M7606 MicroVAX II KA630 M7608 x2 2/4 MB RAM (boards are fully populated) M7940 x2 SLU Module M7944 x3 4-Kword RAM M7946 x2 RX01 floppy disk controller M8043 x2 4-SLU peripheral interface M8044DB x2 32Kword RAM M8044DF x2 32Kword RAM M8047 RAM, Async, ROMs M8186 11/23 CPU M9047 Grant continuity M9400YA 120-ohm terminators with refresh & floppy boot M9400YE Headers and 250 Ohm resistors I've also got the following third party cards - I don't know anything about these, other than the identifying marks found on the boards listed below - if anyone can provide more information on these, that would be helpful: (Several of them appear to be media controllers of one sort or another). Andromedia Systems UDC-11 rev H (50 pin connector at front edge) Micro Technology Inc. MSV05B (x2) (50 pin connector at front edge) TD Systems TDL-11H/A (50 pin connwctor at front edge) Xylogics "Wizard 1" (50 pin connector at front edge) SDC-RXVZ1 "8202 FD Controller" (50 pin connector at front edge) Versatec LSI-11 P/P Interface (40 pin connector at front edge) Sigma Information Systems Assy 40100 - This board has one 40 + one 50 pin connector, and a place to populate another 40 pin - none are at the front edge. W951 "Flip Chip" - This board has places for various sized chips (most of them populated) with pins to wire-wrap connections between them - looks like some sort of prototyping board. + A couple of the little grant continuity boards. I don't expect this to be a short journy, but it should be interesting... Thanks in advance for any advice/tips. 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, 3 months

Graphics for S-100 machines (MicroAngelo S-100 Graphics

by marvin＠west.net

Congratulations on the selling price of the MicroAngelo board!!! I did take a look at the bidders and it appears that at least the winning bidder had just registered on Ebay a week ago and had a bidding war with another person who, by their feedback, looks like they had been a member for a while. If that bidding war had not taken place, it would have probably sold in the $30.00 range or so. At least you know how much someone is willing to pay for one of these if you list another one :)! > From: "Robert Stek" <robert.stek at gmail.com> > > No one was more surprised than me at the selling price - and I'm the one who > sold it! I was expecting maybe $20 - $30. I think I even have another one, > but I haven't found it yet. Anyway, it was a nice surprise and will mean > some extra money for Xmas. > > > > Bob Stek > > Saver of Lost Sols

16 years, 3 months

Looking for DEC side panel

by abacos_98＠yahoo.com

Hello, I am looking for outer side panel for my BA123 chassis. I need the panel thats on the cardcage side(the right side when looking at the front of the chassis). For the life of me I cannot find it anywhere. If anyone might have an extra I can pay the shipping to 14012. Thanks, Brian.

16 years, 3 months

never knew DOS system files were resettable

by chrism3667＠yahoo.com

is there any way to make these visible? I'm trying to do something funky, and for some reason XP won't *visualize* the hidden files on a boot disk (bootdisk.com). I tried unhiding them with attrib, but it tells me uh uh. What to do? Yes I did change my folder option to display hidden files, but to no avail. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

16 years, 3 months

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Jim Battle <frustum at pacbell.net> > Date: Thu, 31 Jan 2008 02:01:43 -0600 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Holger Veit wrote: >.... >> The interrupt and DMA handling was also lousy thanks to DR abusing some >> 8080 and even worse Z80 RST vector locations for the BDOS and CCP >> buffers and FCBs. ... > >That is one thing I always wondered about. CP/M has "CALL 0005H" as the >BIOS entry point. Why didn't they map it to 0008H instead? Considering >that code space was at a premium, saving two bytes off of every BIOS >call would have been an obvious optimization, I would have thought. If one takes a moment some of that was INTEL MDS artifact that were programmed around. Also there are plenty of unused RST vectors. For the later systems the 8259 was available and it inserted a CALL XXXX where XXXX was anywere in addressable memory. The Z80 in mode2 interrupt also could vector anywhere in ram. DMA is not impacted by how the low page is used. Generally it's a non-issue and easy to work with. >On the other hand, I never wrote any 8080 code that used RST, so maybe >there is some gotcha that I don't know about. No it's a one byte call to 8 canned locations in the bottom of ram. RST0 is to 0000h (warm boot) (locations 0000-0007 are used by cpm) RST1 is to 0008h (nothing there) RST2 is to 0010h RST3 is to 0018h RST4 is to 0020h RST5 is to 0028h RST6 is to 0030h RST7 is to 0038h (used by DDT as trap) None of the 8085 hardware RSTx.5 or Trap interrupt lines conflict with anything as they fall i the nothing there range. Z80 NMI lands at 66h which is in the default FCB/DMA area that goes from 005Ch to 00FFh >Anyone have opinions why it was done with CALL 0005H instead? It's explicit either works but only one allows coding to look like: Call BDOS ; Bdos defined as 0005h which reads easier than RST5 ; call location 005 >The only thing I can come up with is that DR might have entertained, >early on, making CP/M relocatable to different addresses (eg, some >vendor wants an OS that lives in high memory). In the process of >patching all the code for the high addresses, substituting "CALL 0FF05H" >instead of "CALL 0005H" is trivial, but substituting "CALL 0FF05H" for >"RST 1" would be a problem. Yes, one could require such systems to have >a "ORG 0005H / JMP 0FF05H" vector. I'm grasping at straws here. Yes straws. CP/M loads to the last typically 8k of high ram and sparsely uses the first 256byte page as a system area. Everything inbetween is open land but CP/M convention is executables start at 100H and have space that can continue as high as the start of the BIOS (if you need cold boot) or 3.5K lower if you need BDOS services. The CCP is considered overlayable. Allison

16 years, 3 months

SC-01 speech chips, is there still a source

by g-wright＠att.net

-------------- Original message ---------------------- From: Ethan Dicks <ethan.dicks at usap.gov> > > On Thu, Jan 31, 2008 at 05:23:09PM +0000, Pete Turnbull wrote: > > > snip................ > > I have an SC-01 in my RB5X robot here, and at home, in my Gorf arcade > machine. The SC-01 is versatile enough that there's code for the RB5X > to have it try and sing. I can't say that it's wonderful, but it does try. > Has anyone found a source for these. I robbed a good system to get 1 for Hero JR Robot - Jerry

16 years, 3 months

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

by cclist＠sydex.com

> Date: Sat, 02 Feb 2008 19:11:16 -0500 > From: "Roy J. Tellason" <rtellason at verizon.net> > > I asked Gary Kildall, "Now that most commercial machines are going to > > 5.25 inch disks, what is the STANDARD format for 5.25?" He answered, "8 > > inch single sided single density." > > Can you do that on a 5.25" disk? What is that, 77 tracks, I forget how > many sectors... 26 128-byte sectors per cylinder, single-sided, 77 tracks. Interleaved 13:1, directory starts on the third cylinder. Corresponds more-or-less to a "1.2MB" DSHD 5.25" (or "1.25MB DSHD 3.5"), but they came along rather late in the evolution of the 5.25" drive, which is probably why you see so few of them with formats for CP/M-80 systems. Did the 5.25" DSHD format originate in Japan? Cheers, Chuck

16 years, 3 months

Microsoft BASIC on CP?M

by rcini＠optonline.net

All: I?ve encountered a devilish problem with MBASIC running on CP/M. I?ve completely rebuilt my IMSAI disk system and so far, the only program I?ve not been able to get to work is BASIC. Does anyone recall if BASIC directly messed around with CP/M or anything weird like that? Even if I limit the assumed memory size with the ?/M:? parameter, it still doesn?t work (I get no sign-on message). Thanks. Rich -- Rich Cini Collector of Classic Computers Build Master and lead engineer, Altair32 Emulator http://www.altair32.com http://www.classiccmp.org/cini

16 years, 3 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:54:28 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Friday 01 February 2008 03:36, Jim Battle wrote: >(Snip) >> Also, people did *plenty* of ugly stuff to save a few bytes back then, >> as you know. RST1 isn't particularly ugly anyway. And if for some >> reason one did find it unpleasant, you could use a macro to make it to >> your liking. > >Yup... > >(Snip) >> we agree. :-) I had a vague recollection of a faint memory of hearing >> third hand that CP/M was ported to some heathkit machine, but that the >> machine already had a ROM in low memory, and so instead of "CALL 0005H", >> one had to use "CALL 2005H" or some such. CP/M programs could be very >> easily reassembled/patched for this, but stock CP/M binaries wouldn't >> work. rather than repeating this slanderous story, I didn't bring it up >> and pretended it was just a supposition. ooops, but now the cat is out >> of the bag. > >I believe the H-8 did indeed have a ROM at low memory. Never worked with that >machine, though. There were also some TRS-80 boxes that I seem to recall >having a need of a special version of CP/M as well. TRS80 (original) had the first 16k used for rom, keyboard and videoram, Therewas a hacked version of CP/M for it that moved page 0 (first256bytes) to something like 4200h and TPA started arond there too. The problem was none of the usual CP/M programs were assembled/compiled to start at 4200h (norm was 0100h) and even if the trs80 was full of ram you were under 48k which was ok but bigger CP/M apps like MSBASIC used some 24K of that or more. Not a popular implmentation. Allison >-- >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, 3 months

← Newer
1
...
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