- test-drb@ccmp.vtda.org - classiccmp.org

by aek＠bitsavers.org

I've been grinding through the stack of early 80's Wang VS docs William Donzelli loaned me, and was wondering how many people have these systems in their collections, and if there was any later docs or software out there. Seemed like a fairly decent system midrange system.

18 years, 6 months

4
3
0 0

abandoned Sun facility

by korpela＠ssl.berkeley.edu

Actually, it looks like the abandoned Pabst brewery has more interesting electronics in it. I wonder if there's something interesting behind the control board that has the temperature and humidity chart recorders on it. Anyway, there's at least a VT100 (I think. Can't read the number) there. http://www.abandonedbutnotforgotten.com/Abandoned%20Pabst%20Brewery.htm On Feb 6, 2008 3:36 PM, Zane H. Healy <healyzh at aracnet.com> wrote: > At 5:59 PM -0500 2/6/08, Roy J. Tellason wrote: > >http://www.abandonedbutnotforgotten.com/sun_microsystems.htm > >

18 years, 6 months

6
7
0 0

ebay seller "dlcs3"

by pat＠computer-refuge.org

Has anyone here noticed this guy on ebay, claiming to have a "warehouse" of stuff in New Jersey? I know that's relatively close to some other MF nuts on this list (well, much closer than Indiana, anyways) so I though I'd see if anyone had gone to see what he had in his "warehouse". The stuff he has listed right now doesn't look all that interesting, but it's hard to tell from the dark, small pictures of smoked plexiglass rack doors, what's inside the rack... Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

18 years, 6 months

2
1
0 0

error with tapecopy writing, buffer to small ??? Fixed

by g-wright＠att.net

Thanks everyone well I was trying to write with a corupt tape image file. I guest it was too late at night for the brain cells..... tried another file and it worked fine. I had been reading a lot of bad tapes that where sticking on the rollers as they reverse I thought I had deleted all of the bad files but I must have missed one. The file was Only was 8k in size ?? - Jerry

18 years, 6 months

1
0
0 0

Emulex QD34 question

by pat＠computer-refuge.org

So, I've got a question about the Emulex QD34 QBUS SMD controller (yes, like the one on ebay right now, which the seller claims is "SCSI"). It appears to have a S-BOX mounting bracket/dist panel on it, with some annoying "inverted" high-density connectors on it (like the HD50 connectors used for DSSI). I'm wondering if it's possible to pull the bracket off the card, and if there's some sane-looking IDC connector headers (like the normal 20 and 60 pin ones on an SMD drive) that one can get to. Thanks, Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

18 years, 6 months

1
0
0 0

ebay seller "dlcs3"

by evan＠snarc.net

Yeah, we're in the process of checking that out here in Jersey. -----Original Message----- From: Patrick Finnegan <pat at computer-refuge.org> Subj: ebay seller "dlcs3" Date: Sun Feb 10, 2008 2:53 pm Size: 611 bytes To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Has anyone here noticed this guy on ebay, claiming to have a "warehouse" of stuff in New Jersey? I know that's relatively close to some other MF nuts on this list (well, much closer than Indiana, anyways) so I though I'd see if anyone had gone to see what he had in his "warehouse". The stuff he has listed right now doesn't look all that interesting, but it's hard to tell from the dark, small pictures of smoked plexiglass rack doors, what's inside the rack... Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

18 years, 6 months

1
0
0 0

Unibus SMD controller available?

by pat＠computer-refuge.org

I'd like to pick up a UNIBUS SMD controller for a project I'm working on, Emulex would be best, but other brands are acceptable. MSCP support would probably be the easiest to work with, and support of E-SMD isn't required but would be a nice extra. :) Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

18 years, 6 months

1
0
0 0

apple stuff still for sale

by spliffrd＠inch.com

I have a ton of old apple stuff for sale, trade or maybe even free if you've got a project you're working on and need something apple. I also have a ton of other computer parts..cases, mobos, processors, nic cards, graphic cards, memory, drives etc to build stuff that I really want to get rid of/donate to the right person. I need to clear out my loft and i really dont want to trash it all. I'm in Bushwick Brooklyn near the Morgan Ave stop on the L train. email Matt spliffrd at inch.com and lets arrange a time for you to come see my stuff.

18 years, 6 months

1
0
0 0

my old machines in France

by nierveze＠radio-astronomie.com

hello everyone ,maybe you will be interrested on the page I have built (in french) about a very old french computer ,a that multi4 from intertechnique (1972)I have here at home ,in perfect condition,I did not find another one until now.It seems a 'clone' of microdata1600 The url: www.radio-astronomie.com/multi4.htm also on www.radio-astronomie.com/info.htm ,you will find pictures of our vaxes,pdp and all other oldthing I hope you will like this best regards alain nierveze

18 years, 6 months

1
0
0 0

Seattle-area computer recycler.. saves classic hardware?

by feedle＠feedle.net

I don't know if this has been mentioned or noticed by members of this list, but I got a pleasant surprise the other day when I stopped by the Re-PC store near Southcenter. Sometime in the last few months, they seem to have started pulling out the "best" of the junk and (most importantly) keeping it as complete as they got it. When I was there earlier this week, they had a C-16 _IN THE BOX_, a couple of complete VIC-20 systems (including disk drive, printer, datasette), a couple of Apple //c's, two shelves of software, and another shelf of various accessories (a lot of Atari 8-bit stuff, oddly enough no Atari 8-bits). Prices were reasonable.. I think, for example, the complete VIC-20 systems were going for $30-$40. Somebody who knows something about classic equipment is obviously working there, as the stuff is getting as close to the "white glove" treatment as you could possibly give it in that environment. I did not see anything similar in the other Re-PC store "downtown". Just something interesting to share...

18 years, 6 months

3
2
0 0

WTB: DEC BA11-MA

by ron_of_america＠yahoo.com

Hello Dave! I think we have a few BA11-MA or BA11-SA's here still. They'd be BNIB. Ron ------------ Anybody have a spare DEC BA11-MA chassis in good shape with the red pdp11/03 label on the front? -Dave -- Dave McGuire Laurel, MD

18 years, 6 months

4
3
0 0

PDP-11/40 for sale

by wacarder＠earthlink.net

The YouTube URL should not have a period on the end. The correct URL is http://www.youtube.com/watch?v=iIsZVqhaneo Thanks, Ashley -----Original Message----- >From: Ashley Carder <wacarder at earthlink.net> >Sent: Feb 9, 2008 11:18 PM >To: cctalk at classiccmp.org >Cc: wacarder at usit.net >Subject: PDP-11/40 for sale > >Ok, I've reached maximum capacity in my shop, so I'm starting a little downsizing. If anyone is interested in obtaining a working PDP-11/40 system in a short DEC rack, I have just put one up for sale on eBay, item #250214591120. I did a short video today showing me toggling in a program using the front panel, then running the program, halting it with the HALT switch, then continuing execution with the CONT switch. I've loaded the video and the program listing to YouTube at http://www.youtube.com/watch?v=iIsZVqhaneo. Even if you're not interested in buying the system, you'll likely find the video interesting. > >Ashley >http://www.woffordwitch.com >

18 years, 6 months

1
0
0 0

PDP-11/40 for sale

by wacarder＠earthlink.net

Ok, I've reached maximum capacity in my shop, so I'm starting a little downsizing. If anyone is interested in obtaining a working PDP-11/40 system in a short DEC rack, I have just put one up for sale on eBay, item #250214591120. I did a short video today showing me toggling in a program using the front panel, then running the program, halting it with the HALT switch, then continuing execution with the CONT switch. I've loaded the video and the program listing to YouTube at http://www.youtube.com/watch?v=iIsZVqhaneo. Even if you're not interested in buying the system, you'll likely find the video interesting. Ashley http://www.woffordwitch.com

18 years, 6 months

1
0
0 0

Microsoft BASIC on CP?M

by cclist＠sydex.com

> Date: Sun, 03 Feb 2008 08:34:34 -0500 > From: "Richard A. Cini" <rcini at optonline.net> > Ive encountered a devilish problem with MBASIC running on CP/M. Ive > completely rebuilt my IMSAI disk system and so far, the only program Ive > 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 doesnt > work (I get no sign-on message). I have seen patched-for-specific hardware MBASIC. Are you certain about having an absolutely vanilla-flavored unvarnished copy? I probably have one kicking around here if you don't. Cheers, Chuck

18 years, 6 months

10
11
0 0

First Osborne Group diskettes wanted

by edwin.kaminskas＠sbcglobal.net

Hey Scott, I have the complete Chicago FOG library as well as 3 Osbornes and many hardware spares. You can email me at: Edwin.kaminskas at sbcglobal.net Ed Kaminskas Grand Rapids, MI

18 years, 6 months

1
0
0 0

A note on microprogramming DEC hardware

by kahrs＠caip.rutgers.edu

This recent thread about microprogramming VAXen was interesting. If you read Dave Patterson's history of VLSI RISC machines you'll see that he was interested in programming the 780 but changed his mind. It's also interesting to note that microprogramming was used in two different cases to create capability machines: one, a 11/730 at Cambridge and the other the 11/40E at CMU. There's the KMC-11, but that's another kettle of squid.

18 years, 6 months

1
0
0 0

Note on LISP Machines available

by sellam＠vintagetech.com

On Thu, 7 Feb 2008, Christian R. Fandt wrote: > Been a loooong time since I've last had contact with you. I've been busy > with other stuff, been off classiccmp list for quite awhile, but still > am somewhat aware of classic computer goings-on thru the MARCH list > (MUCH less traffic to mess with, especially that danged OT stuff). Hi Christian. [ I copied this to the CC list for the edification of all who are involved with this. ] Good to hear from you again. Sorry for never following through on that LaserJet carthridge you wanted. I'm really bad at follow-up sometimes. If you still want that cart, I still have it! It's been in the same place ever since we last spoke about it. If you want it, send me your address again and I'll ship it off to you, my treat. > Were you one of the bunch she contacted? If so, then I don't need to > forward pictures to you. I tagged onto this email the Excel file though, > since it's relatively small (58k), just in case she hadn't contacted > you. Yep, I was one of the victims of her unreasonably high expectations. The entirety of the hardware she has is worth, in my opinion, less than $200. $100 would be reasonable for the lot. She only has one monitor/keyboard/mouse, and because these systems use custom display and keyboard interfaces you can't (easily) just take a standard monitor and keyboard and connect them. I tried to explain this to her but she said other people she contacted said they would just build interfaces. Whatever. For the complexity of doing this, please refer to old postings to the CC list from Tony Duell (do a search). Suffice it to say, it's not straightfoward. So in effect she has one complete system, a bunch of otherwise useless CPUs, and a pile of documentation and software for various different Xerox systems. > <BEGIN copied email text> > > I am finally done listing all the Xerox stuff.... I found more manuals > and software on 1/30. I have attached a spreadsheet with everything > listed. I would really like to sell everything altogether. That may not > work.... but that is how I would like to start. I would like to ask > $2500.00 for all of it to start. I will modify based on the response > received. I am sending this same message to about 20 others that have > expressed sincere interest. I want to make sure that this stuff goes to > someone who will care for it in the best way and who will > document/archive all the manuals/software for others. This is a large > amount of work. Notes about the items are included in the spreadsheet... > please ask any questions that you wish. This, to me, is a substantial > collection of vintage computing items. > > > > There is a note in the spreadsheet indicating that I am really only > offering 6 of the 1186s because I want to keep one. I would rather not > ship the stuff... for several obvious reasons... but it is not ruled out > completely. Also, I did not try to turn anything on, because several > have requested that I do not. Damage can occur from merely turning them > on, thus, I have not done that. > > > > Thanks for your patience while I go through all of this stuff. It has > been an experience! > > > > Diana > <END copied email text> > > I'm no where near an expert like you on values, but doesn't $2500.00 for > the whole lot seem high for all this?? Or are these LISP machines > getting to be like hen's teeth? I've never seen one in the wild myself. > Her attitude about preservation of the gear/docs is rather good though. 6085's are certainly rarer these days. I don't know if my own experience can be a reliable indicator because I'm a hyper-collector, but I have about 8-10 of these systems in my collection (with maybe 3 monitors and 2 keyboards). They are certainly uncommon--I won't say rare--but when they are found they are usually found in batches like this. The last time I got any was a pallet load I hauled from North Carolina back in the 1998 timeframe. In the meantime I have seen one or two here and there, but not often. Then again, I don't see anything with the regular frequency that I used to, so one could argue everything is rare these days, including C64s. I could be mistaken (probably am) but I could swear I remember seeing one at WeirdStuff in Sunnyvale recently. Anyway, they have a certain cachet because they are second generation STAR machines. They don't have the physicality of the original 8010, but they do run the same software, and for those who want to own a piece of early GUI history, this would be a good entry point. Keep in mind that these systems will still take a lot of work and reading to get up and running. Example: when they boot they expect to connect to a time server on the network. There are (easy) ways around this, but again it's not a system for the casual collector. You have to know what you're doing before you can get to a desktop login dialog. The real treasure here are the disks and manuals. I'd really like to get my hands on the 6060 system disks and manuals (I have a 6060 but no software or manuals) and the 8" floppies. I have the facilities to make copies for other people, BTW. So in general, the hardware is not interesting to me. To others it might be because they probably don't already have a pile of them :) But because she only has one keyboard, mouse and monitor (the latter of which from the sounds of it is pretty beat up) she only has one complete system. The rest is spare parts. The documentation and software is a different story. I would say it's worth a few hundred bucks (I don't want to be more specific because I don't want to bias the bargaining process), but it should be separated into logical lots. It makes no sense to include the 8" floppies with the 5.25" stuff, for example, because the 1186 doesn't have an 8" floppy drive. Ditto with the 6060 stuff. In conclusion, for someone who really wants an 1186 system, $500 would not be unreasonable for one complete system with software and manuals. Based on the description of the physical condition of the monitor, I'd knock that in half. I'd have to look at the spreadsheet in detail to guess at prices for the various software and docs. But unless she's willing to separate the lot then the deal is a non-starter. $2,500 is a pipe dream. I hope this helps. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

18 years, 6 months

8
7
0 0

$3000 ASR33?????

by wh.sudbrink＠verizon.net

Good grief! ebay auction: 190195405164 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.21/1265 - Release Date: 2/7/2008 11:17 AM

18 years, 6 months

8
11
0 0

bogus SIDs on eBay?

by spectre＠floodgap.com

It's a strange thing to do but it might be worth keeping in mind if you are looking at buying SID chips off of eBay (the C64's sound chip, for those who don't know). http://kevtris.org/Projects/sid/remarked_sids.html I make no comment on the factuality of the assertions presented, but I suppose the moral is when buying NOS, caveat emptor. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Absence of evidence is not evidence of absence. -- Carl Sagan --------------

18 years, 6 months

7
9
0 0

$3000 ASR33?????

by tshoppa＠wmata.com

> Good grief! > > ebay auction: > 190195405164 I bought my first Model 33 ASR at the tender age of 14. It was the main console I/O peripheral as well as a mass storage drive :-). At the time, my net income was probably $10-$20-$30 a week. It depended on how many lawns I could mow a week :-). I paid $150 for it. So that was probably a month or two income for me. Today a month or two of income is way more than $3000. Not to brag or anything! And obviously not all of it is disposable income like when I was a kid. Could I somehow scrounge together $3000 as disposable income in a month or two? Probably, it'd be hard to justify it to my wife :-). So honestly in terms of "Tim Constant Dollars" I don't see a huge discrepancy here. Tim.

18 years, 6 months

1
0
0 0

$3000 ASR33?????

by quapla＠xs4all.nl

> Good grief! > > ebay auction: > 190195405164 > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.21/1265 - Release Date: 2/7/2008 > 11:17 AM > > Indeed. For that amount I will sell my own ASR-33 and it will come with pedestal, copyholder, chadbox, a box of papertape, 2 rolls of paper and the 3 manuals... Ohhh wait, I have a complete spare one in storage too. Shall we say $5000 for both???? Ed

18 years, 6 months

2
1
0 0

How compatible were "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Thu, 07 Feb 2008 16:38:58 -0600 > From: Jim Leonard <trixter at oldskool.org> > My summer job between college terms was working at Egghead software, and > there was a massive, MASSIVE push from Egghead to sell MS-DOS 5.0. We > (lowly sales floor associates) were bussed to a convention center and > shown various presentations on why MS-DOS 5.0 was dA b0mB and why it was > the perfect add-on to any and all sales already in progress at the > register. Many cheezy sales guides and videos followed. While I liked > the built-in memory management and disk compression (because I'm a > compression geek) of 5.0, I was extremely turned off by the push. Speaking of cheezy MS-DOS, does anyone want a copy of the MS-DOS 5.0 user's manual, beta version, labeled "Microsoft Confidential"? May 17, 1990 and the usual rough-copy workup with lots of boxes labeled "This artwork not available for this release". About 350 pages. Otherwise, I value the binder it's in more than the paper, so the ephemera will go into the recycling pile if unclaimed. I don't know how it differs from the release version, as I never bothered to read it. Real programmers don't need no stinkin' user's manual. Cheers, Chuck

18 years, 6 months

3
2
0 0

Modern Marvels: 90s Tech

by classiccmp＠vintage-computer.com

This is a little OT but the show does track back to things on-topic. >From the producer: --- Modern Marvels: 90s Tech Premieres: TONIGHT! Thursday, February 7th @ 8pm ET/PT on The History Channel (please check local listings) 90s Tech: It was the dot com decade that opened up the information superhighway. "Modern Marvels: 90s Tech" takes you way back to the end of the 20th century and the beginning of today's trendy technologies. From DVDs to TIVO to GPS, see how the digital gadgets we can't live without all started in the 90s. Hear the Amazon story from its very own founder, Jeff Bezos, and see how millions of cyber goods are packaged and shipped at an 800,000 square-foot Amazon distribution center. At Google, learn the science of the world's most popular search engine. And was Furby really a threat to national security? We go beyond its furry exterior to show you the inner-workings of the intriguing pet. Heavyweight Boxing Champion George Foreman, will show us how to "knock out the fat" with one of the best-selling appliances of the decade. And its creators will demo some of the original first-person shooter games: Wolfenstein 3D and Doom. --- There is some neat stuff about Google including some images from the CHM. When they talk about portable computers they show an Osborne 1 (mine), a PowerBook 170 (also mine) as well as some other gear. The Compaq in the background is another item I sent them for the show. Evan Koblentz was their technical consultant for the portable computing segment. It's a bit late for the East Coast folks but the show will re-run, I'm sure. Erik Klein www.vintage-computer.com www.vintage-computer.com/vcforum The Vintage Computer Forums

18 years, 6 months

4
3
0 0

C64 on Craigslist

by cclist＠sydex.com

> Date: Fri, 8 Feb 2008 01:19:50 -0500 > From: "Golan Klinger" > Is there something particularly noteworthy about this 64? I see them > on Craigslist around here quite often and I never thought them worthy of > mention on this global list. I don't know a thing about it, but I do know that folks collect them, so I thought I'd mention it. It holds no interest to me. Cheers, Chuck

18 years, 6 months

1
0
0 0

TI-52 manual

by mraven＠home.nl

Hello Mike, I came across a message from you regarding the manual for a TI-52. If you still have a PDF for it would you be so kind to mail me a copy? Regards, Jos Raven Holland mraven at home.nl jos.raven at gmail.com (for a file lager then 5MB)

18 years, 6 months

1
0
0 0

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

13
24
0 0

C64 on Craigslist

by cclist＠sydex.com

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

18 years, 6 months

3
2
0 0

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

1
0
0 0

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

5
7
0 0

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

1
0
0 0

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

1
0
0 0

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

2
1
0 0

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

1
0
0 0

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

2
1
0 0

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

1
0
0 0

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

1
0
0 0

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

6
6
0 0

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

2
1
0 0

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

1
0
0 0

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

1
0
0 0

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

10
13
0 0

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

6
8
0 0

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

3
2
0 0

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

4
3
0 0

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

4
3
0 0

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

1
0
0 0

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

1
0
0 0

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

1
0
0 0

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

2
1
0 0

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

4
4
0 0

HP4145

by dennis＠multiprobe.com

Remember this post Chuck? Don't know if this one comes up too often, but I recently acquired an HP 4145 semiconductor analyzer software diskette. It's SSSD 5.25". If anyone's interested, I can shoot out an image. Cheers, Chuck Are you able to make an image still? Do you want to sell this unit? Thanks, Dennis A. Drew 805.560.0404 Ext. 105 dennis at multiprobe.com Director of Software Engineering Multiprobe Corporation 819 Reddick Street Santa Barbara, CA 93103

18 years, 6 months

1
0
0 0

"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"? 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. Allison >(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... > >> 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? > >> 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... > >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. > >(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

18 years, 6 months

3
3
0 0

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

by cclist＠sydex.com

> 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. Sometimes interrupt-driven I/O wasn't very good. We used an Intel 8275 CRTC in the CPU and some enterprising engineer decided to hardwire it to DMA channel 1, not 0. On the 8257 DMAC that meant that we couldn't use auto-initialize to keep the display going and basically had to re-initialize the DMA transfer between screens, using an end-of-screen interrupt. Servicing that interrupt 60 times per second was a big drag on the CPU--and if you missed it, the screen would flicker. 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. With the exception of the double-precision subtract, none of these instructions have close analogues in the Z80 instruction set. Nor, AFAIK, did any commercial products exploit them. 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. Cheers, Chuck

18 years, 6 months

2
1
0 0

Looking for TK50 tapes & RX50 disks...

by silvercreekvalley＠yahoo.com

Many thanks for the info. That's a great help. I'll investigate the newer drive as it sounds like it could be the RX33. I have plenty of DSDD 5.25" disks, so I'll give those a try first. Thanks 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, 6 months

1
0
0 0

Any word on OS/2 for PDP-11?

by shoppa＠trailing-edge.com

I don't follow the mailing list closely, but earlier this month folks were talking about a tape supposedly labeled "OS/2" for the PDP-11. My gut feeling is that this is something like how "ASCII" sometimes becomes "ASC-eleven" or even "ASC2" among those who don't know what's a roman numeral vs digits vs whatever. Possibly DOS-11 became D OS-11 became OS/2 :-). But DOS-11 on a TK50 would be unusual in any event! Finding, say, a late version of RT-11 or RSX-11 or RSTS/E or Ultrix-11 on a TK50 seems far more likely. Almost all PDP-11 OS's have an "11" in the name, usually at the end, and it's easy to see how this could become a "2" in the mind of someone who thinks that there is a VAX named Saul or SOL. Tim.

18 years, 6 months

6
7
0 0

Any word on OS/2 for PDP-11?

by tshoppa＠wmata.com

Al wrote: > I wrote: >> I think it's time for me to unsubscribe from this list and >> get back to reality. > Talk is cheap. > Let's see the proof. Well, I was trying to give him the benefit of the doubt, that of the zillion layered products that DEC was churning out in the 80's and early 90's that a guy might mistakenly think something was on the tape that wasn't there because of the language DEC or somebody else used on the TK50 tape label. But he tells me I'm insulting his intelligence by suggesting that there may have been some confusion based on his reading of the tape label. He's made it perfectly clear he doesn't want any advice on what was actually on the tape, he's made up his mind, case closed, there was a VAX named Saul and OS/2 for the PDP-11 because he's been using the VAX since the year before it shipped. What else can you or I do, Al? Tim.

18 years, 6 months

2
1
0 0

GEnie National CP/M RoundTable archives?

by d_cymbal＠hotmail.com

Does anyone have an archive of the files for the GEnie National CP/M RoundTable? I am in the process of putting together a site for the Visual 1050 and there was apparently a section dedicated to the 1050: "Library 37. Visual-1050 CP/M". If possible I would like to include these on my site. I have found several stray entries on the net but have not been able to locate the bulk of the contents (most are named VLIBnn.ARK and described as "Visual 1050 Library Disk #nn"). Any help? Thanks. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

18 years, 6 months

1
0
0 0

MicroAnglelo text editor

by les＠frii.com

I found a web page by a guy who made his own MicroAngelo clone. Its a pretty neat web page but it hasn't been updated for many years, and he doesn't seem to respond to emails. http://www.infinetivity.com/~delscott/ua.htm

18 years, 6 months

3
2
0 0

"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 01:21:19 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 09:19, Chuck Guzis wrote: >> > 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. > >Sure it did. It was whatever you used to format a disk... :-) Seriously, >I'd copy stuff off elsewhere and then with a clean start re-copy it back >again, no fragmentation. Defragger for CP/M is both easy and fun... Use pip to copy the source disk to the destination disk. Best with two or more drives. the real problem is it's hard to defrag with limited on disk space without buffering in ram and thats doable too. >I thought I had remembered one, but can't seem to find it at the moment. > >> 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. Makes sense where the file is static in size and whats really being done a loader. what happens if your doing data bases or data collection and the assumed file size exceeds the as built file... oops. >> > 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. It supported drives to 8mb as a logical unit. ou can have up to 16(less if you have floppies) logical units (A->P) for a total of 128mb. All of the CP/M derived works starting with P2DOS and on fixed the math inside the BDOS allowing for drives to 1Gb. >Oh yeah. I think if there were one thing I'd like to change about CP/M that >would probably be it, give me a multi-level directory. Last time I gave >that some thought I was considering using something like *.LBR files do, >only in those the utilities commonly used would have you set the number of >entries you wanted to add at the outset, and you had to go through some >stuff to add more or compact it., and compressing/decompressing library >members was a whole separate operation and also had to be done manually. But >I think it's possible. Thae allocation scheme used makes it hard to keep track of how many blocks are used by the content of a subdirectory... you can do it but lots of recursion needed and that means a rewrite of the whole files system code and also compatability issues as none of the apps will have any idea of subdirs. >I did have a "COMMAND.LBR" that was around 600K in size, had all sorts of >stuff in it, though mostly I used a fairly small handful of utilities. > >> 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. > >Yup, that's exactly what I did. Many of the ZCPR and later improved CP/M work alikes added named directories that equated to user numbers. >Any of you know how some of the CP/M variants dealt with HDs and these other >issues? Briefly CP/M doesn't, the BIOS writer does. Since basic CP/M has a hard limit of 8mb per logical disk drives larger than 8mb are divided into logical partitions as needed. I have many (6 or more) systems with hard disks and all have disks greater than 10MB. The system with a 45mb is partitioned (in bios not using MBR or other dosisms) into 5 logial disks four 8mb and one 5mb. The bios also allows for assigning what partition is what letter though a user utility. I also have a system with a 120mb disk set up so any four 8mb partitions can be "mounted" and "dismounted" as needed. Reason for this is each disk in the BIOS has buffers associated and they can become significant in space used. By limiting the number of active drives I save that space at the cost of only have 32mb on line at any given time. That was a fair trade for a large TPA in a non banked machine. that and by most users even 8 megs of disk in one lump is luxury afer using floppies. Allison

18 years, 6 months

1
0
0 0

"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 02:20:29 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Monday 04 February 2008 14:48, Chuck Guzis wrote: >> I wanted to add a "put that diskette back" alarm to my CP/M >> implementation when there were files opened for writing > >:-) Fortunately it at least did a check for a changed disk. >> 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. > >It wasn't really much of an OS, compared to a lot of what else was out there. I'd argue that CPM is barely an OS annd a should be catagorized as a filesystem and monitor. there are thing it doesn't manage. For some without all the IO bells implemented the IO is notably poor. Allison

18 years, 6 months

1
0
0 0

"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 02:00:47 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 07:34, Allison wrote: >> >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. > >Not much of a gotcha, I don't think I'll be doing much with the 8080 these >days anyhow, and pretty much every single one of the CP/M boxes I have on >hand here are all equipped with a Z80. > >ZCPR I've run across, those others are not familiar to me. Are they out >there and available? Might be worth a look at them if so. Try google and expect a lot of results. They have been out there for years. Allison

18 years, 6 months

1
0
0 0

"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 01:58:20 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Sunday 03 February 2008 07:27, Allison wrote: >(Snip) >Yup, but that assumes that you want two bytes. CP/M would give a function >code and then anywhere from zero parameters to several of varying lengths and >some even were pointers to tables and data areas. You might also want to >bump the return pointer past the data. :-) The general methodology works for any length but I showed it for two. >I think rather than use a scratchpad location to save HL into I just swapped >it with the top of the stack, which would give you HL pointing to the first >byte beyond the call, though it's been several years since I worked on this >and my recollection is a bit more than fuzzy about the whole thing. You can but if you need HL to do 16bit arithmetic of some such you may have to save it. I've done code that passed variable length parameters on the stack but after 3 maybe 5 bytes you have to start storing something somehwere. Even Z80 has a finite number of registers. >> >> Interrupt driven, has some basic terminal sense (vt100 specific) >> and uses IObyte. > >Sounds worth looking at, is it out there anywhere? Never looked but whole VT180s are findable. >(Snip) >> >> 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. > >I could be mistaken but I think those early comm programs had something like >128 or 256 bytes of buffer in them. Which was like nothing when the >higher-speed modem on the other end had several K... Makes little differnce as the reall pain is when you have to hit the disk be floppy or hard, most systems the CPU is totoally involved in doing PIO for the disk transfer(expecially floppy) and the rest of the world is left to hang. You have to stop the transfer prior to going to the disk. Many cases that doesnt work well. When you need speed this is where releaving the CPU of that using DMA pays. allison

18 years, 6 months

1
0
0 0

Digitalker Information

by brain＠jbrain.com

My son and I watched War Games a few nights back, and I pulled out my old Jameco JE520 speech synthesizer. We played with it a bit tonight, and it has a bad EPROM #2, so the upper half of the first word set is garbled. Questions: * Anyone have a JE520 that could copy the ROM? * Or, anyone have other ROMs for the DIGITALKER (soft copies, that is)? * Anyone have a datasheet on this device? NS54104 Jim

18 years, 6 months

6
9
0 0

"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

18 years, 6 months

2
1
0 0

"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

18 years, 6 months

3
3
0 0

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!.

18 years, 6 months

6
5
0 0

"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

18 years, 6 months

2
1
0 0

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

18 years, 6 months

6
9
0 0

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

18 years, 6 months

4
9
0 0

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

18 years, 6 months

2
1
0 0

"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

18 years, 6 months

1
0
0 0

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

18 years, 6 months

19
31
0 0

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

18 years, 6 months

2
1
0 0

"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 >

18 years, 6 months

3
2
0 0

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

18 years, 6 months

5
5
0 0

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

18 years, 6 months

2
1
0 0

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.

18 years, 6 months

1
0
0 0

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

18 years, 6 months

4
6
0 0

"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

18 years, 7 months

4
3
0 0

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

18 years, 7 months

1
0
0 0

"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

18 years, 7 months

1
0
0 0

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

18 years, 7 months

1
0
0 0

"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

18 years, 7 months

1
0
0 0

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Fred Cisin <cisin at xenosoft.com> > Date: Sat, 02 Feb 2008 17:25:27 -0800 (PST) > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >> > 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." > >On Sat, 2 Feb 2008, Roy J. Tellason wrote: >> Can you do that on a 5.25" disk? What is that, 77 tracks, I forget how many >> sectors... 26 >IF your disk controller is "cooperative". The "1.2M" drive is almost the >same as an 8" drive. 'course, his remark was during the days of 48 tpi 35 >track 5.25", . . . Therein lies the problem. I'd asked the same question in 78 IE: are you ever going to consider a different disk format? No, there ae so many and none compatable, some too small and a few limited to a specific vendor. Until there was a viable and better standard 8" SSSD was it. I think that standard emerged around 1983 with 360K (40tracks two sides DD) soft sector and again with 1.44MB 3.5". Other than those what other wide spread and not limited to a specific vendor and those two were standard only for PCs. Allison

18 years, 7 months

1
0
0 0

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

by cclist＠sydex.com

> 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. 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. 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. Cheers, Chuck

18 years, 7 months

3
3
0 0

MPI floppy drive service manual

by ard＠p850ug1.demon.co.uk

There is currently an HP9826 in bits on my bench, this machine incorporates a single 5.25" floppy drive. Now must such machines used Tandon TM100-2As (slightly modified to HP spec), but this one has a different tye of drive. A label on it says : Magnetic Peripheals Inc (A Control Data Company) P/N 77711807 I am looking for a servicv manual for this drive, in particular _mechanical_ information. Looking at the drive, all the electronics (inclduing the spindle motor speed cotnrol) is on one PCB on top. The spindle motor is the normal motor + tachogenerator at the rear left corner, driving the spindle by a blet on the underside. The head postiioner stepper motor is at the rear right corner, shaft vertical with a taut-band mechanism to move the heads. To the right of the stepper motor drum, attached to extensions of the head carriage, is some sort of damper unit. The PCB might be HP special. In particualr there is a header connector to link up an external drive in-use LED. But I susepct it's closely related to a standard MPI drive. I need to know how to dismantle the band mechnaism to remove the heads, and als what to do about the damper which is leaking grease onto the chassis (!). Does anyone recognise that drive mechanism and know where I could find a service manual. I've not found anything on-line yet. Also, does anyone have a proper data sheet for the MC3470 (disk read amplifier etc). The only one I can find on the web is the NTE one which doesn't have that much information in it. -tony

18 years, 7 months

3
2
0 0

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Dave Mabry <dmabry at mich.com> > Date: Sat, 02 Feb 2008 13:39:09 -0500 > To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> > >Roger Ivie said the following on 2/2/2008 1:16 PM: >> >> I did a small amount of work with ISIS, but after I had used CP/M. I >> used an Intel PDS development system for the 8051 to debug some >> firmware; I think it was for DEC's SCSI floppy controller. >> >> The PDS was interesting in that it was a portable system about the size >> of a Kaypro and had *two* 8085s. ISIS gave you an A> or B> prompt, but >> it indicated to which processor you were speaking rather than which >> drive was the default. > > >Now *that* was multiprocessing! I remember it well. In fact I still >have a working one. With ISIS-PDS there was a logical locking so that >you could have both processors (actually *two* complete computers, each >with its own 64KB of RAM) doing disk i/o concurrently and they wouldn't >scramble each other's files. Interesting. Before I'd seen a PDS I experimented with S100 boards of my own design with the goal of getting 3 z80s complete with local ram and public ram to do mutiprocessing. By time I was done I'd achieved that and more. All the disks had their own CPU and DMA to public ram as well as the IO system having it's own CPU to manage buffers and pending IO. Each Z80 had it's own boot and 64K ram plus a mapper to page out any 4k portion to public ram or make any 4k pag of public ram part of the 64k private space. Public ram was initially 256k and grew to 512k. The 3 Z80 has doorbell interrupts and used public ram for data and status passing. It ran CP/M2.2. The mostbizare hack was one cpu running CCP attached to console, the second running the BDOS nad dispatch bios and the third running the application (any cpm app). Since the disks and IO was smart they acutally ran the Bios abstraction so the dispatch bios really only routed calls and data pointers for the DMA. Learned some things. 3 cpus can be fast, and takes nine times longer to program and 9times that to debug. Keeping everyone from killing each other is hard. One really fast cpu with smart peripherls is faster. Smart peripherals that can DMA to public memory are a a definate win. You end up adding time slice and process management in some form to keep everyone doing the right thing in the right order. CP/M is not safely recusive. Hardware for prioritizing bus access is complex for S100. S100 bus will make you crazy. I learned a huge amount about multitasking, multiprocessing and process management in real time. It was successful but I would later pull two two of the three 4mhz cpus and upgrade one to a 10mhz Z80 to far greater advantage. I still used that highly modified NS* Horizon running a 10mhz z80 and a smart controller for floppy, HDC and IOP board with an 8085 to handle the two serial ports, parallel printer and RTC. Years later I would get a Compupro MPX1 (8085 system IO MUX). It was much like what I did for the IOP save for the IOP use real DMA (8257A) where the MPX1 does PIO. File locking: You can lock CP/M files by marking them system or RO so other cpus/processes can crunch them. The real trick is getting the "owner to" not recognize the lock. >It came with a single full-height floppy drive. I changed mine to have >two half-height ones and if I was careful I could run ISIS-PDS on one of >the processors and CP/M-80 or CP/M Plus on the other. ISIS-PDS would >boot from the internal bubble memory (128KB) and CP/M would boot from >the floppy. I would do my Intel development work on the ISIS side and I still have a pair of BPK72s working with spare bubbles. >document it in Wordstar on the CP/M side as I was developing. it. >There was no mechanism to keep one side from clobbering the other side's >files on floppies, so I had to keep that straight in my head. At the >time it was not hard to do, but today I am probably too lazy to keep it >all straight. ;) It's still a cool thing to see "lowly" 8085 doing fancy stuff. Allison > >Dave >

18 years, 7 months

1
0
0 0

Automatic virus scan of uploaded files on BBS?

by jrzagar＠gmail.com

Looks like this feature of WWIV will be important in a patent lawsuit by Trend Micro. Trend Micro claims to have a valid 1995 patent for doing virus scanning on email servers, and many of their claims appear to be well-known capabilities that WWIV had well before 1995 For mor information on this please look at this article: http://www.groklaw.net/article.php?story=20080125135544713 -RZ

18 years, 7 months

3
2
0 0

"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: Fri, 01 Feb 2008 13:06:58 -0800 > To: cctalk at classiccmp.org > >> Date: Thu, 31 Jan 2008 09:21:58 -0500 >> From: Allison > >> 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. > > >IIRC, in ISIS-II, programs were loaded somewhere above 3000H, >depending on the buffer requirements of the program, but always above >the ISIS resident, which always occupied the same space, regardless >of memory size. > >On some early 8080 implementations, an 8259 wasn't used (expensive!) >and a simpler circuit using a priority encoder and a latch to stuff >111iii11 onto the bus in response to an interrupt acknowledge. CP/M >could get in the way of this scheme, if it was desired to use the >RST0 vector for an interrupt. Otherwise, there was no problem, >except for the RST vector (usually 7) used for DDT--but that's local >to DDT and easily patchable (it's done for the Amstrad PCW, for >example). That scheme also work for Z80 mode2 where I is XX and the inserted low byte comes from the commonly 74148 and a pair of 74175s. >After having used ISIS before CP/M, I was happy to see the "lean and >mean" CP/M. ISIS was verbose, clumsy and slow (e.g., :F0: instead of >A: for the first floppy drive; "DELETE" instead of "ERA"). Also an ISIS user. The usual OS used on the shop MDS was not ISIS but instead CP/M! >Of course, had CP/M simply shifted the TPA up 256 bytes and used the >area between 0100h and 01FFh for command-line storage, system request >vectors and FCBs, that would have solved the problem, but for the DDT >RST vector. Having the RST0 vector already used wasn't too bad as it's also RESET but the DDT one was harder as the cheap pullup resistor address (RST7) was easy. Most of the z80 boards had vectored interrupt logic and that made it easy as most systems only needed maybe two or three ints to do the job and 6 were unused. It was only the early 8080 S100 machines that were impacted and some did have interrupt hardware that was more than RST7 by pullup. By time CP/M-2 was available Z80 was almost universal and the few that werent were either 8085 or 8080 with ints. Whats interesting is the 8085 interrupt pins were all usable including trap in a CP/M environment, thats potentially four interrupt inputs. Now if you are doing low memory banking those interrupts locked in page zero were a pain. Z80 mode 2 or other hardware was needed to get out of that hole. Allison >Cheers, >Chuck

18 years, 7 months

4
3
0 0

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Roger Ivie <rivie at ridgenet.net> > Date: Sat, 02 Feb 2008 10:16:28 -0800 (PST) > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Fri, 1 Feb 2008, Allison wrote: >>> From: "Chuck Guzis" <cclist at sydex.com> >>> After having used ISIS before CP/M, I was happy to see the "lean and >>> mean" CP/M. ISIS was verbose, clumsy and slow (e.g., :F0: instead of >>> A: for the first floppy drive; "DELETE" instead of "ERA"). >> >> Also an ISIS user. The usual OS used on the shop MDS was not ISIS >> but instead CP/M! > >I did a small amount of work with ISIS, but after I had used CP/M. I >used an Intel PDS development system for the 8051 to debug some >firmware; I think it was for DEC's SCSI floppy controller. Use a MDS to bring up CP/M2.2 on a NEC PDA-80 an 8080 based FP machine that had a remex tape punch reader. Yep configured CP/M, bolted on a bios and punched it to PT! >The PDS was interesting in that it was a portable system about the size >of a Kaypro and had *two* 8085s. ISIS gave you an A> or B> prompt, but >it indicated to which processor you were speaking rather than which >drive was the default. It was a bizzare little box. Allison >-- >roger ivie >rivie at ridgenet.net

18 years, 7 months

1
0
0 0

FTGH: VAX green cards

by listmailgoeshere＠gmail.com

Smallish grey booklets, AV-D827C-TE, entitled "VAX-11 Programming Card". I have two of these available. If you want one, drop me a mail off-list please. Ed.

18 years, 7 months

1
0
0 0

Stuff to see in Denver area?

by rdawson16＠hotmail.com

I think this is a great idea: We should all put in our travel notes. I forgot who entered the bay area surplus shops and hamfests, but thank you! If you are stuck in Denver, you may need some fuel, and I recommend the Tortilla Flat mexican restaurant in lLittleton; The Blue Parrot Italian in Louisville. It all my travels, the best surplus place I have ever been to is Mendelssohn Electronics in Dayton, Ohio. A huge old building downtown, loaded with things you never see anywhere else. I got a IBM plug board there, I think it belonged to a card reader sorter. It was still all wired up with the last program and I spent many hours trying to figure out what it did. In Albuquerque there is a place called the Black Hole, I have not been there yet, but I have herd so much about this place and its eccentric owner. He gets all kinds of weird things from the Los Alamos lab and sometimes to their embarrassment when somebody later figures out what the item was, or was used for. Im headed back through in a month, and I'll be sure to write it up. On the way, I plan to stop at the aircraft boneyard and Titian missle silo in Tucson: http://www.pimaair.org/index.php Let us know what other cool stuff you have found! Randy > From: evan at snarc.net > To: cctalk at classiccmp.org > Date: Fri, 1 Feb 2008 23:45:25 -0500 > Subject: Stuff to see in Denver area? > > 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? _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008

18 years, 7 months

2
2
0 0

interact model one -- looking for docs

by frustum＠pacbell.net

Hello vintage microcomputer fans. I recently bought an Interact Model One computer on ebay (#150208636366). It was in good shape and it went relatively cheaply. This beastie is 8080 based, and has very coarse color graphics. Mine is unusual in that it has a white housing and a real keyboard, not the ash gray case and tiny rubber keys of all the other interacts I've seen. It has an integrated cassette deck, and no ROM BASIC -- that has to be loaded from tape. By all measures is was really a miserable little runt. :-) Well, the seller put it in a box that was exactly as wide as the computer, such that there was no padding in that axis, other than the cardboard of the box. The rest was just stuffed with foam peanuts, and a small sheet of bubble wrap that was floating in the box. As you might guess, it didn't fare well. The space bar popped off and peanuts got jammed inside the machine. Luckily, it was easy to put back. Three of the five buttons of the integrated cassette deck broke off. The plastic buttons are OK; it was just the glue that broke, and the keys can be glued back on. Worst, a corner of the case shattered into pieces, and left a large crack along the top rear. Being out $68 isn't so painful as the idea that this thing found its way through the world for 30 years in decent condition and then got ravaged due to simple carelessness. Still, I crossed my fingers and plugged it in. At first I thought it was dead, but then realized it is putting out modulated video. After swapping my in nice Sony color monitor for a TV and tuning in channel 3, I get a "DEPRESS L TO LOAD TAPE" message. Hooray for that. All isn't well, though, as pressing the "READ" button doesn't cause the tape mechanism to turn, even after pressing L. It is kind of moot, though, as the plastic cover doesn't pop up when I press eject. A web search hasn't turned up any useful information on the machine -- scans of manuals, in particular. A short time ago, a much more complete system, including manuals, sold on ebay (#220191106456), to "hokinfan". I attempted to contact the buyer to see if he could help me out, but ebay rejected my attempts because they didn't see any trading history between us. (please, no ebay rants) So, does anybody on the list happen to have any form of technical documents that I might be able to use to help troubleshoot this? Beside wanting the information just to have it in case, I do have an immediate need to figure out the tape deck, and to rig up some replacement joysticks, since the machine didn't come with them. Thanks

18 years, 7 months

3
3
0 0

"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

18 years, 7 months

1
0
0 0

"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 > >

18 years, 7 months

3
2
0 0

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

18 years, 7 months

1
0
0 0

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

18 years, 7 months

2
1
0 0

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?

18 years, 7 months

1
0
0 0

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

18 years, 7 months

1
0
0 0

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/

18 years, 7 months

6
6
0 0

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