test-drb

test-drb@ccmp.vtda.org

101090 discussions

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

Looking for DEC side panel

by abacos_98＠yahoo.com

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

18 years, 2 months

never knew DOS system files were resettable

by chrism3667＠yahoo.com

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

18 years, 2 months

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

by ajp166＠bellatlantic.net

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

18 years, 2 months

SC-01 speech chips, is there still a source

by g-wright＠att.net

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

18 years, 2 months

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

by cclist＠sydex.com

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

18 years, 2 months

Microsoft BASIC on CP?M

by rcini＠optonline.net

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

18 years, 2 months

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Roy J. Tellason" <rtellason at verizon.net> > Date: Sat, 02 Feb 2008 20:54:28 -0500 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On Friday 01 February 2008 03:36, Jim Battle wrote: >(Snip) >> Also, people did *plenty* of ugly stuff to save a few bytes back then, >> as you know. RST1 isn't particularly ugly anyway. And if for some >> reason one did find it unpleasant, you could use a macro to make it to >> your liking. > >Yup... > >(Snip) >> we agree. :-) I had a vague recollection of a faint memory of hearing >> third hand that CP/M was ported to some heathkit machine, but that the >> machine already had a ROM in low memory, and so instead of "CALL 0005H", >> one had to use "CALL 2005H" or some such. CP/M programs could be very >> easily reassembled/patched for this, but stock CP/M binaries wouldn't >> work. rather than repeating this slanderous story, I didn't bring it up >> and pretended it was just a supposition. ooops, but now the cat is out >> of the bag. > >I believe the H-8 did indeed have a ROM at low memory. Never worked with that >machine, though. There were also some TRS-80 boxes that I seem to recall >having a need of a special version of CP/M as well. TRS80 (original) had the first 16k used for rom, keyboard and videoram, Therewas a hacked version of CP/M for it that moved page 0 (first256bytes) to something like 4200h and TPA started arond there too. The problem was none of the usual CP/M programs were assembled/compiled to start at 4200h (norm was 0100h) and even if the trs80 was full of ram you were under 48k which was ok but bigger CP/M apps like MSBASIC used some 24K of that or more. Not a popular implmentation. Allison >-- >Member of the toughest, meanest, deadliest, most unrelenting -- and >ablest -- form of life in this section of space, ?a critter that can >be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters" >- >Information is more dangerous than cannon to a society ruled by lies. --James >M Dakin

18 years, 2 months

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

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

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

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: Dave 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, 2 months

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

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

by ajp166＠bellatlantic.net

> >Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines? > From: "Chuck Guzis" <cclist at sydex.com> > Date: 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, 2 months

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

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

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

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

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

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

by ajp166＠bellatlantic.net

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

18 years, 2 months

information on ancient matsushita/panasonic ICs

by frustum＠pacbell.net

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

18 years, 2 months

DEC LA180 printer (&LA100)

by dm561＠torfree.net

Date: Fri, 1 Feb 2008 09:37:40 -0500 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: DEC LA180 printer On Feb 1, 2008, at 6:35 AM, Rick Murphy wrote: >>> My books are still in storage,( basement wall are up! ), but I >>> seem to >> recall the LA36 had adjustments on the servo. Could the LA180? > >> Yes, it's basically the same mechanism. >> I've sent the maintenance manual to der Mouse for scanning. > LA36 and LA180 are the same mechanism? Are you sure? I don't >recall much similarity there, especially in terms of speed. > -Dave ------------- I'll be scrapping some more LA100s (RO) shortly; any useful parts in there for anyone? I believe that at least some parts are compatible with the LA210 and others, including the LA34 & 38; can someone confirm that? Also an LJ500 (B2), although it's probably clogged and I don't expect much interest... TIA, mike

18 years, 2 months

Stuff to see in Denver area?

by evan＠snarc.net

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

18 years, 2 months

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

by dave06a＠dunfield.com

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

18 years, 2 months

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

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

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

18 years, 2 months

Jump to page:

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