test-drb April 2007

test-drb@ccmp.vtda.org

257 participants
560 discussions

by jefftnc＠compascable.net

Hi all, Cutting back on my collection... Synertek SYM Model 1, untested, in great physical shape. http://tinyurl.com/ysf2s2 USA only...sorry...Post Office issues... Thanks for looking. JT

17 years, 2 months

CP/M survey

by ajp166＠bellatlantic.net

> >Subject: Re: CP/M survey > From: "Chuck Guzis" <cclist at sydex.com> > Date: Wed, 18 Apr 2007 23:35:31 -0700 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On 18 Apr 2007 at 17:17, Allison wrote: > >>> I'd do the bios development on one of the existing long list of >systems. >> All of my listed systems work especially the CP/M hardware. > >Not me--I do it under emulation on a nice speedy windoze system. >It's amazing how fast MAC will munch code running on a software >emulator. :) I do have Myz80 and Dave Dunfeilds NS Horizon emulator as tools for when I'm purely messing with code. But when I have a hefty 10mhz z80 S100 crate next to the PC with solid tools and a good programmer in it why mess with a PC. >> Qualifies as an 8080! With a bunch of Pc hardware to impair it. ;) > >Maybe, but ti couldn't run JRT Pascal. AFAIK, the only commercial >product that ever used the bizarre coding sequence: > > LXI SP, PROC-1 > CALL PROC JRT Pascal was Z80 code if memory serves. But LXI SP, value is valid as the arithmetic is done at compile time not execution. Loading a stack address prior to a call is ok if you need to recover the stack content (for recursion or some such) but I'd expect prior code to save/restore the stack or the routine making the call will return to nowhere. I've seen a lot of code that mucks with the stack in the past and it's ok if you remember your return addresses are on that pile! I've not encounterd this problem with V20. That sequence is not so strange to me. though I've not used JRT Pascal (or many other high level) tools on a V20 because I haven't found that a V20 XT PC to be all that great compared to a 4mhz z80. I have been meaning to try the Tandy 1000HX which has a V20 and see if thats better. In the end running an 8080 (V20) when I have Z80 or even fast(6mhz HmosII) 8085s is sort of less than interesting. Allison

17 years, 2 months

CP/M survey

by ajp166＠bellatlantic.net

> >Subject: Re: CP/M survey > From: ard at p850ug1.demon.co.uk (Tony Duell) > Date: Thu, 19 Apr 2007 18:40:54 +0100 (BST) > To: cctalk at classiccmp.org > >> just tell it what particular ICs you're using and at what port addresses, and >> away it goes? Or was it more complex than that, and realistically you'd have >> to write your own comms / FDC driver which exposed some defined interface to >> CP/M itself? > >You had to write something called a CBIOS (Customised Basic Input Output >System IIRC). This was a set of routines to handle terminal I/O (and >printer, paper tape I/O if you wanted that), disk block read/write, and >so on. There's a manual giving the specs for these routines, how to get >CP/M onto the target machine, and so on. The original CP/M distibution >came with the source for a CBIOS for the Intel MDS800 (IIRC)m which you >could use as a starting point > >I've never done it, but it ;ooks like quite a 'fun' thing to do for >suitable values of 'fun'. Of course if you bought a packaged machine to >run CP/M it came with a CBIOS written for that machine. And alas you >rarely got the soruce of that :-( > >-tony Trust me haveing done it more tha a few times it was fun or at least interesting. You did miss the third case, packaged machine and time for upgrade. In that case sometime the existing BIOS was needed or not. Having sone more than a few random integrations (S100 crates) usually you didn't have a explict bios to match but did have similar or at least a pattern. Often during S100 upgrades here the FDC was the item being upgraded or outright replaced it was easier to start from scratch and build in features the earlier bios neglected like buffered IO for serial lines or better error messages. Allison

17 years, 2 months

Bondwell 2 CP/M laptop available

by frustum＠pacbell.net

I received an email asking if I was interested in a Bondwell 2 laptop. You can learn a little bit more about it from one of my web pages: http://www.thebattles.net/bondwell/bondwell.html It has a 640x200 bitmapped LCD display (capable of displaying 80x25 text), a 4 MHz Z80, integral floppy drive. The downsides are that it has a pair of heavy sealed lead acid batteries (I replaced the two 6v bricks in mine with a single 12v brick; as I recall it cost $15 or so), and that scrolling text is painful since the text is just drawn as bitmapped graphics. I don't want another one, so I offered to pass along his contact information. He is in Redwood City, CA (just south of san francisco), but it seems he is willing to ship; ask him to be sure. When I asked about price, he said: "SURE, GO AHEAD AND LIST IT, I WOULD MUCH APPRECIATE. I DON'T WANT ALOT OF MONEY, I'M JUST LOOKING FOR A GOOD HOME FOR IT." I'll obscure the email address to prevent harvesting. Robert is his name. Reply to: AcopsBisCtops @ yaDhoo . comE Remove the capital letters and spaces.

17 years, 2 months

Disk Drive....Repair (?)

by cheri-post＠web.de

Hi guys, as myself being a harddrive collector, this video really hurts alot ! Such clips should be forbidden... Regards, Pierre > > A nightmare is up on youtube. At least it hits me that way, as a full time > disk person. > > > > Billy > > > > http://www.youtube.com/watch?v=JUQzGIqp4t8 > > _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

17 years, 2 months

CP/M survey

by ajp166＠bellatlantic.net

> >Subject: Re: CP/M survey > From: Jeffrey Armstrong <jba at sdf.lonestar.org> > Date: Thu, 19 Apr 2007 12:08:11 +0000 (UTC) > To: cctalk at classiccmp.org > > >>> > >>> >Subject: CP/M survey >>> > From: Mark Tapley <mtapley at swri.edu> >>> > Date: Wed, 18 Apr 2007 09:09:45 -0500 >>> > To: cctalk at classiccmp.org >>> > >>> >DEC Rainbow (8087, 832k (max for -A model), but >>> that's irrelevant to CP/M-80). >>> >>> Not true as the rainbow also ran CP/M-80/88 as it >>> was a dual CPU (has a z80). >>> >>> Allison >> >> Could it access more then 64k under CP/M-80? Don't >> you mean CP/M-86? Not to nit pick... >> I don't know about specific Rainbow revisions, but I >>was under the impression the 'bow could go up to 896k. >>Maybe I'm thinking of the Tandy 2000 via an 3rd party upgrade. > >I think Mark was trying to say that an 8-bit CP/M program on the Rainbow >can only access 64k RAM, which is true, under Rainbow CP/M-86/80. A >16-bit program could access all of the Rainbow's system RAM under CP/M. Of course and I referred to that. What I avoid trying to do was say, hey it's a Z80 and 8bitters like 8080 and Z80 without only address 64k. Granted you can hang bank hardware on them and extend but the addressing is still only 64k. >And he's also right about the memory. A 100A maxed out at 832k, while a >100B/100+ maxed out at 896k. This is because 100A models shipped with >128k on the motherboard, while 100B/100+ models shipped with 192k. So >when a maxed-out ram expansion card was installed, the 100A still had 64k >less than an equivalent 100B/100+. > >One interesting thing about 16-bit programs on CP/M-86/80 on the Rainbow >was that some were confused by too much RAM. The most notable examples >are all the Rainbow ports of Infocom adventures; they all complain about >"not enough memory" if you have more than 512k or something like that. Unlike PCs were 640k was all there was. Allison

17 years, 2 months

PC-MOS?

by daviderhart＠oldzonian.com

> -----Original Message----- > From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] > On Behalf Of Chuck Guzis > Sent: Wednesday, April 11, 2007 11:02 PM > To: cctalk at classiccmp.org > Subject: PC-MOS? > > I was looking for something else and ran across a two-binder set of > something called "PC-MOS" by The Software Link, circa 1992. I opened > the shrinkwrap on the nstallation manual and the thing looks like > it's a multi-user version of MS-DOS, talking to terminals. I > appear to have a 5 user version. > > Anyone familiar with this animal? The version is 4.2. > > Cheers, > Chuck Sounds like the PC-MOS I used in the mid-80's to build a multi-user system using an IBM PC/AT with an expansion box that had one CGA card per user. The expansion box had special cables for monitor and keyboard (thick & bulky). This let me run DBase III, Wordstar 2000, etc. in an office for up to eight stations. Each station appeared to have the PC/AT to itself. Worked really well. I wonder if I was using the same PC-MOS but a very early version. david.

17 years, 2 months

errors in disk images (was Kapro 10 format.com)

by aek＠bitsavers.org

> I have download the kaypro disks > from dave's site and the system disk 2 is really multiplan. It is REALLY REALLY important that you tell Dave, or other archivists when errors are found in disc images. One of the most difficult things to do is to verify that a distribution disc still contains good copies of what it claims to on the label.

17 years, 2 months

WH-27 Problems (was RE: Heathkit H8's, H9's and H-11's)

by ajp166＠bellatlantic.net

> >Subject: Re: WH-27 Problems (was RE: Heathkit H8's, H9's and H-11's) > From: "Ethan Dicks" <ethan.dicks at gmail.com> > Date: Thu, 19 Apr 2007 09:31:25 -0400 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On 4/19/07, Robert Armstrong <bob at jfcl.com> wrote: >> The [W]H-27 drives were both the best and the most disappointing part of >> the H-11 system... > >> Yes, most people would not be impressed by a drive that can format >> diskettes, but real DEC RX01/2 users never knew this joy. > >And, except for Rainbow uses, most RX50 users never knew this joy, either. Other than Robin (Vt180), Rainbow and Vaxmate (sorta PC) formatting a disk was unheard of. The first vax widely available that could format it's hard disk or a floppy was the Microvax-2000 without resorting to diagnotic software kits (MDM for VAX or XXDP for PDP11). >> So the bottom line is that if you want to run standard RT-11 on the H-11, >> you have to set the switch to RX-01 mode and you have the equivalent of an >> RX01 drive. No double density, and no formatting. >Perhaps, but, then again, with a "custom" OS, there might have been >some check somewhere in the Monitor to enforce compliance. It will be >interesting to take apart the OS and see where the differences lie. >One could then, presumably, build a patch kit to "transform" a genuine >RT-11 kit into HT-11, as folks already do with various versions of >Infocom adventures (i.e. - *you* get a legitimate copy of the game >file, then acquire and apply patches to it to turn it into the >different release versions of the game. Since the patches are based >on a known quantity and aren't themselves the game, they are made >freely available) It was simpler than that. It was an old version of RT11 and from that version to current the driver structure apparently is different enough to not work. However if you used drivers from V2.x HT11 was happy. >I have never seen one, but another list member has offered to send me >some H-11 media. Once I get things working, I'll see about archiving >it. I'd have to dig as I have media and tu58 tape that overlaps that timeframe and OS use. Not anytime soon as I'm ripping the room apart to build a new desk in. Allison

17 years, 2 months

CP/M survey

by ajp166＠bellatlantic.net

> >Subject: Re: CP/M survey > From: Sridhar Ayengar <ploopster at gmail.com> > Date: Thu, 19 Apr 2007 03:20:51 -0400 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Dave McGuire wrote: >> On Apr 18, 2007, at 4:43 PM, Jules Richardson wrote: >>> Interesting; did CP/M ship with a range of UART and FDC drivers then, >>> so you just tell it what particular ICs you're using and at what port >>> addresses, and away it goes? Or was it more complex than that, and >>> realistically you'd have to write your own comms / FDC driver which >>> exposed some defined interface to CP/M itself? >> >> The CP/M distribution, as shipped only boots & runs on one particular >> type of machine: an Intel MDS-800 development system. If you (or a >> computer manufacturer, say Kaypro for example) wanted your machine to >> run CP/M, and it wasn't exactly like the MDS-800 in terms of what I/O >> chips were used and at what addresses, you had to write the drivers to >> support your hardware. These drivers form the BIOS. CP/M was shipped >> with the intention that users would write their own BIOS code to support >> their own systems. >> >> In truth it is really not all that difficult. The BIOS interface is >> very simple and well-defined. Under the tutelage of an experienced >> mentor, I was writing BIOS code on my Imsai when I was about fourteen. >> It's nothing like the complexity of, say, a device driver system for an >> implementation of UNIX. > >How does it differ? Aren't all drivers just fundamentally open, close, >read, write and ioctl? Not under CP/M. this is the bios call entry table. ; ; perform following functions ; boot cold start ; wboot warm start (save i/o byte) ; (boot and wboot are the same for mds) ; const console status ; reg-a = 00 if no character ready ; reg-a = ff if character ready ; conin console character in (result in reg-a) ; conout console character out (char in reg-c) ; list list out (char in reg-c) ; punch punch out (char in reg-c) ; reader paper tape reader in (result to reg-a) ; home move to track 00 ; ; (the following calls set-up the io parameter block for the ; mds, which is used to perform subsequent reads and writes) ; seldsk select disk given by reg-c (0,1,2...) ; settrk set track address (0,...76) for subsequent read/write ; setsec set sector address (1,...,26) for subsequent read/write ; setdma set subsequent dma address (initially 80h) ; ; (read and write assume previous calls to set up the io parameters) ; read read track/sector to preset dma address ; write write track/sector from preset dma address ; ; jump vector for indiviual routines jmp boot wboote: jmp wboot jmp const jmp conin jmp conout jmp list jmp punch jmp reader jmp home jmp seldsk jmp settrk jmp setsec jmp setdma jmp read jmp write jmp listst ;list status jmp sectran ; The relevent ones for char IO are conin, conout, constat, list, listst, punch, reader. Disk or any block addressable device is seldsk, settrk, setsec, setdma, read, write and sectran. While the names are descriptive they do not adaquately tell you what the task is. For example SELDSK selects a disk and to do that was do several things like save the number of the drive to be used and return a pointer to a table (DPH or disk parameter table) of addresses of information and scratch areas needed for that disk. One very important address in that table is the DPblock which actually descibes the size, CHS organization and allocation block size of the reference drive. The BDOS uses these to compute the calls to seltrk(set track) and selsec(set sector) that will be used for reading or writing. These are in unix terms the very rawest level device calls. What CP/M is/does is provice three major functions. CCP, console command processor and simple monitor that is the user interface. BDOS, this does "high level" stuff like open a file, get a char, put a char put a char to list device and other filesystem and IO sundries. BIOS, this is the layer that translates a standard set of calls from the BDOS to perform things that are very hardware specific. Modern term is hardware abstraction layer. The bios tried to make the various different disk controllers and connected disks and serial/parallel devices looks like very standardized but elementary IO. What you call a driver in *nix is the BDOS level calls in CP/M for equivilent level of functionality. included is the BDOS command dispatch table from CP/M2 (8080): ; ; command dispatch table DISTBL: DEFW WBOOTF ; 0: System reset DEFW REDCON ; 1: Console input DEFW WRTCON ; 2: Console output DEFW XRQ ; 3: Reader input DEFW XRQ ; 4: Punch output DEFW LISTF ; 5: List output DEFW DIRTIO ; 6: Direct console I/O DEFW GETIOB ; 7: Get I/O Byte DEFW PUTIOB ; 8: Set I/O Byte DEFW PRNBUF ; 9: Print string DEFW REDBUF ; 10: Read console buffer DEFW GCSTAT ; 11: Get console status DEFW GETVER ; 12: Return version number DEFW RESET ; 13: Reset disk system DEFW LOGIN ; 14: Select disk DEFW OPEN ; 15: Open file DEFW CLOSE ; 16: Close file DEFW SEAR1 ; 17: Search for first DEFW SEARN ; 18: Search for next DEFW DELETE ; 19: Delete file DEFW READ ; 20: Read sequential DEFW WRITE ; 21: Write sequential DEFW CREATE ; 22: Make file DEFW RENAME ; 23: Rename file DEFW GLOGIN ; 24: Return login vector DEFW GETDRV ; 25: Return current disk DEFW DMASET ; 26: Set DMA address DEFW GALLOC ; 27: Get addr (alloc) DEFW MAKRO ; 28: Write protect disk DEFW GROVEC ; 29: Get R/O vector DEFW SETATT ; 30: Set file attributes DEFW GETPAR ; 31: Get addr (disk parms) DEFW MODUSR ; 32: Set/Get user code DEFW REDRND ; 33: Read random DEFW WRTRND ; 34: Write random DEFW FILSIZ ; 35: Compute file size DEFW SETRND ; 36: Set random record DEFW RESDRV ; 37: Reset drive DEFW XRQ ; 38: Undefined - go back DEFW XRQ ; 39: Undefined - go back DEFW ZERRND ; 40: Fill random file w/ zeros ; To wrap up: The cpm prompt A:>edit fred.txt causes the CCP to do this>> call bdos open and see if edit exists, if it does it does several read sequential andd loads the read file startin at 100h in memory and jumps to it. *runs edit* That program calls the bdos open to see if fred.txt exits, if yes it loads it's buffer(s) as needed with further bdos calls. IF not then it may create a file entry and allocate a block to it for future storage use. Of course the bdos makes a pile of calls to gets and put characters, check the console device for any keys pressed and outputting characters as well as disk related IO. Very un *nix like. Likely more than anyone wanted to know but while CP/M is pervasive not everyone is familiar or familiar to the code level. Allison

17 years, 2 months

← Newer
1
...
20
21
22
23
24
25
26
...
56
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 April 2007