test-drb

test-drb@ccmp.vtda.org

101090 discussions

by ajp166＠bellatlantic.net

> >Subject: Re: DEC LA180 printer (&LA100) > From: M H Stein <dm561 at torfree.net> > Date: Fri, 01 Feb 2008 14:54:19 -0500 > To: "'cctech at classiccmp.org'" <cctech at classiccmp.org> > >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. LA36, 120 and 180 were mechanically similar but that about it. the logic and a few other detils were different. >> -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? The LA210 is a varient of the LA100RO for most mechanical parts. The la210 and LA100 shared the same print head, ribbon, carriage motor platten motor, font carts, and a few other bits. Again they were related so many parts could be shared but the logic board for each were differnt. Things you want to save are power supplies, print heads, drive motors, ribbons, and the litle one way clutch used for the ribbon advance. Allison >Also an LJ500 (B2), although it's probably clogged and I don't expect much >interest... > >TIA, > >mike > > > > >

18 years, 2 months

Chip ID and datasheet?..

by bpope＠wordstock.com

All, I am trying to ID a chip from a SFD-1001 motor control board. This is printed on the chip: JAPAN SERVO SA1001 3A It looks like a normal DIP, except for the middle pins which look to be twice as wide. Is this for heat sinking? I have tried searching for this chip but so far have found nothing. The board has this marking; PC-368C JAPAN SERVO TDK-T15V Which also has not turned up anything useful.. The 5 1/4" drive mech this board is connected to was made by Matsushita and its model # is JU-570-2. From reading the SFD-1001 technical manual, the 5 1/4" mech is just listed as a part so it does not have any detailed information for this board. :( Cheers, Bryan

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: Wed, 30 Jan 2008 10:57:15 -0800 > To: cctalk at classiccmp.org > >> 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. 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. 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. >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. 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. >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. Well it was patterned (so say copied) after CP/M so.. No surpize there. ;) 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: Fri, 01 Feb 2008 08:05:02 -0800 (PST) > To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> > >On Fri, 1 Feb 2008, Allison wrote: >> >> 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.. > >Which is consistent with the manual: > >"All simple character I/O operations are assumed to be performed in >ASCII, upper- and lower-case, with high-order (parity bit) set to zero." > >(from the section 6 of the CP/M 2.2 manual) It is sorta.. Parity may not be a visible bit if the terminal is set for 8P1, the manual would imply the required serial format is 7S1 or 7S2 which may be for TTY but not always. The manual is at best obscure on that. ;) My implmentations had two serial drivers TTY (masked to 7bit) and CRT not masked. Add to that printer (DEC LA100) serial 8bit and modem 8bit I used the high and low bits of IObyte usefully. Allison >-- >roger ivie >rivie at ridgenet.net

18 years, 2 months

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

by cclist＠sydex.com

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

18 years, 2 months

Any word on OS/2 for PDP-11?

by aek＠bitsavers.org

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

18 years, 2 months

Has anyone ever written a standalone Commodore disk drive emulator?

by dm561＠torfree.net

Have a look at: http://www.baltissen.org/newhtm/cbmhd.htm Ruud's the main guy behind the 1541 IDE project I mentioned to you, (and is on the CBM hacker's list I also mentioned) but he does have an IEEE <> PC project on his site as well. I've been meaning to look at the IEEE version myself; if you try it out, share your experience (as will I if I get to it first). mike --------------------------------------------------------------------------------------------- Message: 12 Date: Wed, 30 Jan 2008 02:19:23 +0000 From: Ethan Dicks <ethan.dicks at usap.gov> Subject: Has anyone ever written a standalone Commodore disk drive To: cctalk at classiccmp.org Message-ID: <20080130021923.GA7074 at usap.gov> Content-Type: text/plain; charset=us-ascii Hi, Commodore folks, I have just tracked down an ISA IEEE-488 card and was thinking that it might be interesting to use it to build an older PC into a Commodore diskette drive emulator - I recall there are various projects to interface modern hardware to PETs (like the C2N232 I have with me), but the idea in this case is to allow existing apps to work as if there were a real C= drive hanging off the PET's IEEE port. Essentially, the PC would act as closely to, say a 4040, as possible. My thought was that if I had a real IEEE-488 interface, it could handle the physical-layer protocol, and the emulator would only have to handle sending and receiving command strings and data. The virtual diskettes would be, of course, image files. I'm not really as worried about RELative files - more along the lines of "direct access" files where the code running on the PET wants to read and write individual sectors, ignoring the C= DOS filesystem. That is, in fact, the major reason for trying to emulate drives in the first place - if it was just a case of loading and saving streams of data as files, the C2N232 does a fine job of that (and costs on the order of $10 to breadboard). There seem to be a number of ways to emulate C= IEC-bus devices (such as the 1541-III), but not for the IEEE-488. If anyone can point me at any existing projects, even if they are incomplete, it would be a big help. Thanks, -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 30-Jan-2008 at 02:00 Z South Pole Station PSC 468 Box 400 Temp -34.8 F (-37.1 C) Windchill -57.9 F (-50.0 C) APO AP 96598 Wind 7.9 kts Grid 45 Barometer 674.7 mb (10829 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

18 years, 2 months

How compatible were "MS-DOS Compatible" machines?

by cclist＠sydex.com

> Date: Wed, 30 Jan 2008 13:07:48 -0600 > From: Jim Leonard > Was there ever a *vanilla* MS-DOS? Short answer--yes. It was called an "OEM Kit". Basically, you got the binaries and instructions on how and what I/O drivers to write and you linked the whole mess together to form two files, IO.SYS and MSDOS.SYS, though you weren't confined to those names. Many utilities, such as MODE and FORMAT were provided in skeleton form with the vendor filling out the details. This lead to a some interesting variations on MODE. For example, the Grid MS-DOS version of MODE allows one to control the power status of the peripherals and a whole bunch of other things. I may even still have the OEM documentation wandering around somewhere, printed up on fading tractor-feed paper. A key difference between the two OEM arrangements was that you agreed to serialize the copies of DRI products that were sold, while Microsoft didn't require that. I think that MS simply charged you on the basis of the number of systems shipped--I'd have to go back to my files to make sure. When you get that "Synchronization error" message from MOVCPM, it means that MOVCPM has compared the serial number of the copy of CP/M that it contains with the one of the system on which it's running and the two don't match. Easy to patch out, however--but beware if you "fill out" your CP/M disk with another's files. Cheers, Chuck

18 years, 2 months

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

by glen.slick＠gmail.com

On Jan 30, 2008 11:53 PM, Zane H. Healy <healyzh at aracnet.com> wrote: > > Has anyone ever made an up-to-date install tape that doesn't require > you to apply all the patches? I've got a chicken/egg situation going > on, my PDP-11 uses a Viking QDT SCSI board, which requires one of the > very last patches in order to be supported. > > Zane > I have an MTI QTS-30 (aka CMD CQD-200/Ts) and TTi QTS-1 / QTS-3 SCSI tape controllers which I can use to boot a 2.11BSD install tape, but the install process hangs up while trying to restore the files from the tape to the hard drive. Anyone know for certain if the latest patches might help that with these TMSCP controllers? With the same SCSI tape drive and a CQD-220/TM I can complete the 2.11BSD tape install process to a hard drive attached to the CQD-220/TM, but then it won't cold boot from the hard drive attached to the CQD-220/TM. One of the MSCP boot loader patches is supposed to fix that, but I haven't built and verified myself yet. It's on the to do list.

18 years, 2 months

Radio Shack Science Fair manuals

by sdenkin＠bayridgeprep.org

Hi, I see that you have the manual for science fair 200 in 1 from radio shack. It would be great if I could get a copy of this manual. I would like to use this system with my students. We have the machine, however, the manual is missing. Thank you, sdenkin at bayridgeprep.org

18 years, 2 months

Commodore parts?

by mcguire＠neurotica.com

Hey folks...I've got an otherwise-pristine Commodore 1702 monitor that is missing the little front door that covers the controls. Does anyone have one of those doors that they can spare, perhaps from a junker 1702? I'd really like to make this one perfect. Thanks, -Dave -- Dave McGuire Port Charlotte, FL

18 years, 2 months

DEC LA180 printer

by harten＠injectstar.de

I slipped off the belt from the motor pulley. Now the motor can turn without moving the carriage. I tried to turn the motor by hand (power off) and it can be turned easily. On power up the motor starts to turn for about one second and then stopps with the bell continously beeping (till power off). I observed the signals -carry-, -borrow- and -inc- with an oscilloscope. They are there when the motor turns but are the timings o.k.? Regards Axel Harten.

18 years, 2 months

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

by cclist＠sydex.com

> Date: Thu, 31 Jan 2008 23:04:55 +0000 (GMT) > From: Tony > IIRC, while the MDA card had a light pen connector, it was never really > documented or supported by IBM, due to the fact that light pens didn't > work properly with the very long persisnence phosphor of the 5151 > monitor. The CGA card's light pen connector was docuemtned, though > (although I have never seen a light pen designed to work with it I've got a light pen that was salvaged from some 60's era graphics equipment. This is the kind with the fiber optic tip and a microswitch that determines when the tip is depressed. Has some discrete circuitry in it (probably an amplifier, pulse shaper, etc.) and works just fine with the MDA/CGA/EGA cards. About the diameter of a felt tip marker (ca. 3/4"). I once used it with a monitor with a short-persistance white phosphor. It wasn't bad; just couldn't think of a good application for it. I've got a VGA card here (Paradise I think) that also has the connector, but it's hooked to an LCD monitor, so that's not going to work very well--but does give another reason to hang onto CRT displays. Cheers, Chuck

18 years, 2 months

DeskWriter Disks

by technobug＠comcast.net

A while back someone was looking for DeskWriter software disks. If that need remains, please contact me off-list. CRC

18 years, 2 months

Help needed on a DEC LA180 printer

by harten＠injectstar.de

Hi! I'm a Computer collector from Germany and the last 3 years i spend a lot of time in reconstructing and repairing my PDP11/05 along with its peripheral devices (2x RK05,RX02,BA11ES). Noe that these things are working im trying to repair my LA180-PD printer, that was in no good condition. With a copy of the logic-prints i was able to find some faulty IC's on th logic board- but there must be at least one more. On Power-Up the carriage starts to move back to left edge but stopps before reaching the left end then the bell is turned on permanently. There is no reaction on any button pressed or switched over. Unfortunately i have no Maintenance Manual or Logic description, maybe there is a person out on this list who can help me with a copy of the documents. Regards Axel Harten.

18 years, 2 months

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

by cclist＠sydex.com

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

18 years, 2 months

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

by cclist＠sydex.com

> Date: Wed, 30 Jan 2008 15:44:40 +0100 > From: Holger Veit <holger.veit at iais.fraunhofer.de> > MSDOS was much better in abstracting hardware, because it had a loadable > driver concept. Loadable drivers didn't come along until MS/PC DOS 2.0. Before that, adding another device, say an extra disk drive, was a brutal patchwork affair. CP/M 86 was far more advanced (for that matter, CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1 reference material included information not only on commands, but system table layout, .EXE file structure and system requests. ONE disk buffer for blocking/deblocking. Read and write transferred one record to and from the DTA. Flat file structure; file I/O done with FCBs. As a matter of fact, if you didn't know any better, you'd have sworn that someone took CP/M 2.2 and ported it to the 8086. MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission, the goal was to get closer to Xenix in operability. > Point is there in both cases: the hardware designers did not foresee how > their hardware could or should be used by software, so they basically > implanted the bare chips, not even respecting IRQ and DMA requirements; > the OS developers did not foresee usable and extensible interfaces to > access and abstract various hardware and just hacked something that it > would somehow work; and finally the application designers found the whole > base OS functions where plain unusable and reinvented, each one > differently, the wheel, leaving burnt ground for others that somehow > required similar functions - "thou shall not use the printer port for your > dongle, I have it already." 20-20 hindsight is great, but let's take it from the viewpoint of the times. There were very many CP/M systems around at the time with *no* interrupt or DMA support. Remember that the 5150 made extensive use of peripheral chips that were from the 8-bit world (8237, 8253, 8259, 8255, not to mention the NS8250), so the fact that DMA and an interrupt controller (with 8 interrupt levels yet) and a timer was somewhat remarkable considering the competition. Although the BIOS functions came a long way as the PC evolved, MS-DOS still ran on a 5150, so the added BIOS functionality couldn't be exploited. The parallel port was designed as a printer port; the fact that it was used for other things can hardly be blamed on MS-DOS. The printer port does what it was designed to do extremely well. The fact that a dongle designer was so short-sighted as to not provide printer pass-through functionality can hardly be laid on the designers of the PC. Personally, I'm surprised the light pen interface wasn't used for more things. Cheers, Chuck

18 years, 2 months

A sign of the times

by cclist＠sydex.com

I've been using a couple of Panasonic laser printers for years; a KX- P4455 (PS/PCL) and a KX-P4451 (PCL). They're real beasts of machines; I'd guess that they weight somewhere around 60 lbs. each-- heavy enough to cause me to grunt when lifting them. These are the kind of units that requires one to add toner to a compartment periodically. Drum and developer are separate cartridges. The time came to replace the OPC drum in one of these--after pricing the remanufactured ones and checking the deals on eBay, it turned out not to be practical. I found that I can get a factory refurb Brother 5240 from Staples.com for $40 shipped. When it runs out of toner, I can just buy another one at that price (1200 DPI, 23 PPM and most important--a parallel interface). So what to do with the old monsters? They use 68000 CPUs, with differing SIP and DIP memories. Scrappers, I guess. It's sad because both of these have pretty much been the only printer I've used since a Diablo Hitype II. It wouldn't surprise me if each has more than 250,000 copies on it. It's just a shame that such a nicely engineered piece of gear is now worth only its weight in scrap metal. But nobody collects printers, not even vintage ones. Cheers, Chuck

18 years, 2 months

Simple peer to peer network?

by cclist＠sydex.com

> Date: Wed, 30 Jan 2008 14:16:32 -0500 > From: scheefj at netscape.net > What is the desired end result? What is the application? A simple > application may not need a "real" networking protocol. If "cluster" > means distributed processing, then you have a lot more than just > protocols to figure out. You know, a $2 PIC (e.g. 18F2580) MCU implements CAN. It's not really fast(CAN, not the PIC) but it keeps your car going. A minimum of external components required. You even get a bunch of other neat stuff thrown in (USART, timers, ADC, etc.). All in a 28 pin skinny DIP or QFN. (Dodging brickbats, for not keeping things contemporaneous) 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: "Chuck Guzis" <cclist at sydex.com> > Date: Thu, 31 Jan 2008 02:06:29 -0800 > To: cctalk at classiccmp.org > >> Date: Wed, 30 Jan 2008 15:44:40 +0100 >> From: Holger Veit <holger.veit at iais.fraunhofer.de> > >> MSDOS was much better in abstracting hardware, because it had a loadable >> driver concept. > >Loadable drivers didn't come along until MS/PC DOS 2.0. Before that, >adding another device, say an extra disk drive, was a brutal >patchwork affair. CP/M 86 was far more advanced (for that matter, >CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1 >reference material included information not only on commands, but >system table layout, .EXE file structure and system requests. ONE >disk buffer for blocking/deblocking. Read and write transferred one >record to and from the DTA. Flat file structure; file I/O done with >FCBs. As a matter of fact, if you didn't know any better, you'd have >sworn that someone took CP/M 2.2 and ported it to the 8086. > >MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission, >the goal was to get closer to Xenix in operability. Roger that. >> Point is there in both cases: the hardware designers did not foresee how >> their hardware could or should be used by software, so they basically >> implanted the bare chips, not even respecting IRQ and DMA requirements; >> the OS developers did not foresee usable and extensible interfaces to >> access and abstract various hardware and just hacked something that it >> would somehow work; and finally the application designers found the whole >> base OS functions where plain unusable and reinvented, each one >> differently, the wheel, leaving burnt ground for others that somehow >> required similar functions - "thou shall not use the printer port for your >> dongle, I have it already." > >20-20 hindsight is great, but let's take it from the viewpoint of the >times. There were very many CP/M systems around at the time with >*no* interrupt or DMA support. Remember that the 5150 made extensive >use of peripheral chips that were from the 8-bit world (8237, 8253, >8259, 8255, not to mention the NS8250), so the fact that DMA and an >interrupt controller (with 8 interrupt levels yet) and a timer was >somewhat remarkable considering the competition. DING! Thats is the point. the 5150 was running at 4.77mhz which by 8088 standard of the day was SLOW. but it wasnt sitting the cpu in tight loops waiting for keypressed or FDC data ready. Every Z80 system that did exactly that was nothing short of phenominal to use and could easily blow the doors off a 5150. I worked with a one off Multibus system at that time that had Z80/6mhz 64k shadow rom DMA floppy controller and later ST506 hard disk. For text based work, cross assemblers it was light years faster. >Although the BIOS functions came a long way as the PC evolved, MS-DOS >still ran on a 5150, so the added BIOS functionality couldn't be >exploited. Also the early bios was only 16k than even two years later it was twice the size. Reason ram and rom became cheaper and larger. More space more functions. >The parallel port was designed as a printer port; the fact that it >was used for other things can hardly be blamed on MS-DOS. The >printer port does what it was designed to do extremely well. The >fact that a dongle designer was so short-sighted as to not provide >printer pass-through functionality can hardly be laid on the >designers of the PC. >Personally, I'm surprised the light pen interface wasn't used for >more things. That never caught on. I think when it could have the CPU was still too slow to do the work. Allison

18 years, 2 months

Q-BUS primer?

by ajp166＠bellatlantic.net

> >Subject: Q-BUS primer? > From: "Dave Dunfield" <dave06a at dunfield.com> > Date: Wed, 30 Jan 2008 22:12:16 -0500 > To: cctalk at classiccmp.org > >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. Here comes a huge first shot. Any questions ask. I've likely answered them before. I have here most every Qbus configuration for PDP-11 and a few DEC would never support and a few Qbus uVAX too. All operational. If you liked programming the 6809 the PDP-11 will be familair and even nicer. (CUBIX-11). Any (and all) of the late 70s through mid 80s "MicroComputer Handbooks" [microcomputers and memories, Microcomputer interfacing handbook] DEC put out. They are chock full of info, explanation and are just gotta have items. The PDP11 and MicroVAX have heavy overlap in the Q-bus realm so any and all info for one will be helpfull for the other. Those books will help with.. PDP11 programming (or microVAX) PDP11 modules and their jumpers Standard addresses for various functions Some info on standard configurations including what board goes where. Boot code for many devices Mxxxx to function conversion DEC history! >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) To make a system you need roughtly (pdp11). A box with power, backplane and at least minimal front pannel (three switch) A CPU be it LSI-11 or M8186 the latter is mroe versitile. An SL serial port configured as console (dl11 or better DLV11J OR MXV11) My prefernce is the 11j and seperate ram as the MXV is a sea of jumpers. However teh MXV-11 Two or up to 4 total make for a compact systems with boot and IO galore. the MXV11s mostly seenare limited to Q18 configurations due to limited address decoding but fully populated boards times four Gives you 64KW (128KB) with is a moderately large memory system and also 8 serial lines 4 PPI! Popular card for embedded systems. Memory at least 4K more for an OS (16k minimum) To run an OS some form of mass storage (could be a Tu58 emulator running on a PC on A serial port) A good OS to start with is RT-11, compact, small ram fooprint and can run from any device 256k or larger, looks like dos. ;) NOTE: The LSI-11 is the oldest and has some bus configuration items to pay attnetion to. It's limited to 32KW addressing (Q16) and when you remove the IO page (PDP-11 and VAX use memory mapped IO) typical space is 26KW (big for basic 11). The M8186 is the F11 cipset and has MMU also (Q18/Q22) can address larger memory. Most all 8186s I've seen despite handbooks claims of only Q18 addressing do Q22 (22bit). It's also much faster than the LSI-11. >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. The dual floppy is RX50. The front pannel is processor specific as are the real pannel (if present!) inserts. That box works for both Q-bus 11 cpus and Qbus uVAX cpus. > 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. BA11N BAllVA??? Should have a label somewhere identifying it. > - 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. Generally the DEC backplanes are wirecage to cupport the guides and the backplane at the end with power and control connectors. >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 That is the base "LSI-11" cpu card. Use in many machines and even the H11. >M7504 Ethernet adapter (older DEQNA) Older and often flaky, if it works keep it, if unsure keep it. >M7546 TMSCP controller for TK50 >M7555 Winchester and floppy disk controller AKA the RQDX3 controller for MFM and floppy(RX50 and RX33 aka TEAC FD55GFR). >M7606 MicroVAX II KA630 >M7608 x2 2/4 MB RAM (boards are fully populated) uVAXII cpu has matching ram with an over the top IDE cable. M7608 is ONLY for uVAXII. >M7940 x2 SLU Module DL-11 card, generic serial line interface. That an older one but very useable. Pair that up with LSI-11 cpu. >M7944 x3 4-Kword RAM Goes with the LSI-11 CPU. >M7946 x2 RX01 floppy disk controller It's not teh FDC it's really only the bus interface to the FDC. The drive RX01 has a simple randome logic processor to do all the heavy lifiting. RX01 is SSSD 8" standard. >M8043 x2 4-SLU peripheral interface DLV11J, the standard 4 serial line interface for QBUS. >M8044DB x2 32Kword RAM >M8044DF x2 32Kword RAM For qbus 11 systems. >M8047 RAM, Async, ROMs MXV11 compact card with a million jumpers that gives you yp to 32kB of ram, ROm, 2 serial(DL compatable) and parallel(8255). >M8186 11/23 CPU First generation F11 cpu, fine board has uODT in microcode. ODT is a very simple Octal based (all 11s are octal) monitor debugger. >M9047 Grant continuity Always handy for filling holes. The bus is wires such that interrupt and DMA grant are passed through eash card so that the highest priority requestor is nearest the CPU. >M9400YA 120-ohm terminators with refresh & floppy boot used with Qbus 11 cpus that are romless. can boot RX01 and I think two otehr devicves >M9400YE Headers and 250 Ohm resistors bus terminator reqired in some cases optional in others not wanted in some. >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) Memory says same as RQDXn. desireable board if you have info. >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, 2 months

Dosbox and TOPAS working!

by rdawson16＠hotmail.com

After some serious hacking, with this 3d animation program, I have it running under DOSBox!!! Next questions: 1. Its a really cool program, expensive in its day, but abandoned by its owner AT&T who got out of the graphics business about 1993 or so. What have others done, to get the OK to post these type programs somewhere. (Im thinking about the Mame arcade emulator guys, who never were able to post the ROMs) 2. How can you free up the dosbox mouse to get back to a windows control so I can grab a screenshot? Dosbox is cool! Randy _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/

18 years, 2 months

Whitechapel WC1 on Ebay

by stimpy.u.idiot＠gmail.com

Astounding - something genuinely rare on ebay. Item number: 260206754118 I'd have it myselft but alas my loft is full. -- Pete Edwards "Prediction is very difficult, especially if it's about the future" - Niels Bohr

18 years, 2 months

Help needed on a DEC LA180 printer

by tiggerlasv＠aim.com

I'm assuming you've already verified that the carriage isn't binding, by trying to move the print head with the printer turned off, so we'll skip that step. If the carriage is moving, and suddenly stops, with a continuous error bell, it's possible that there is something wrong with the head positioning electronics. The motor that moves the print head has an encoder wheel on the back of it, which of course is monitored by the logic board. I would GUESS that if the printer doesn't see any feedback from the encoder, that it would stop the print head, and turn on the warning bell. I have one of these at home, with the classic "head slam" problem, which is also related to the encoder and/or electronics. It will print, but when returning to the left-hand side, it will start with a gentle tap while it's printing, then a bit louder, then a bit louder, as the carriage slams harder and harder up against the left stop plate. Finally, it stops, and the bell sounds. In this instance, it's losing track of where the print head is. I haven't had time to isolate the problem myself, but it sounds like you're having problems along the same lines. I would check the connections to the encoder wheel. . . the encoder wheel itself, (sometimes they get dust / dirt inside the enclosure, which interferes with operation), then the infrared sensors, and related circuitry on the board. Tim ________________________________________________________________________ More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com

18 years, 2 months

HP-UX install tape available

by jack.rubin＠ameritech.net

I have an HP DDS cartridge labelled "HP-UX Install S800 / HP-UX 10.10 Release / For the HP9000 S800". Marked as 1 of 1, SD FMT, P/N B3920-13427. Available for cost of postage. Email me off-list Jack No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.16/1250 - Release Date: 1/29/2008 10:20 PM

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