test-drb January 2008

test-drb@ccmp.vtda.org

221 participants
430 discussions

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

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 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/

16 years, 11 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

16 years, 11 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

16 years, 11 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

16 years, 11 months

2716 with 100 nS access time - Lessons learnt by a Trainee Technical Officer in the dim, distant past...

by doug＠stillhq.com

Jos, You have sparked a funny (now) memory from my long distant past. In my youth, I had a Rockwell 65F11 SBC board, with a FDC, that was a small scale Forth development system. I spent many many hours writing code on it. One day, I decided that it needed a memory upgrade, and I designed a card to sit on top of the entire PCB that had buckets of ram (48K from memory??). As a trainee, I thought that I would be clever, an instead of laying out all of that tedious memory decode logic, I would use a 2732, and simply write a big decode matrix. (It worked beautifully for a traffic light controller state machine I did a little earlier...) So, I created an awesome memory upgrade PCB (with tape on film - 2 sided) - Photo reduce - expose - etch - drill - populate, etc, etc......All to discover that it didn't work.. After hours of trying to find the problem, I sheepishly approached one of the Senior Technical Officers, who suggested with a smile, that I connect a logic analyser to see what was happening... Low and behold - the CS* signal never got around to appearing before the memory was read. That day, I truly found out what 450nS access time actually meant. All to try to avoid mucking around with those pesky single use proms... Interestingly enough, a year or so later, I fitted one of those massive 62256 to get all of the memory I needed. Wo hoo. I hope you find a solution. BTW, does anybody remember the wierd diode logic decode that the TRS-80 model 1 used.... I tried that once as well, and discovered that you couldn't use silicon, and that only germanium worked. -- Doug Jackson, I-RAP, MAIPM, MIEEE Principal Information Security Consultant EWA-AUSTRALIA PO Box 6308 O'Connor ACT 2602 Level 1, 214 Northbourne Ave, Braddon ACT 2612 Tel: +61 (0)2 6230 6833 Fax: +61 (0)2 6230 5833 Mob: +61 (0)414 986 878 http://www.ewa-australia.com ============================================ IMPORTANT: This email remains the property of Electronic Warfare Associates - Australia. If you have received this email in error, you are requested to contact doug.jackson at ewa-australia.com or Ph +61 2 62306833 and delete the email. This message is not to be copied or distributed to other parties without the express permission of the author. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). ============================================

16 years, 11 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 McGuire <mcguire at neurotica.com> > Date: Wed, 30 Jan 2008 13:27:25 -0500 > To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> > >On Jan 29, 2008, at 4:33 PM, Joshua Alexander Dersch wrote: >>> In the early-mid 80's a program was "well behaved" if it did it's >>> I/O thru DOS calls. Those programs would run on just about anything. >> >> 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?) >> I'd be interested to hear opinions from people who were there at >> the time, since it was a little before my time. > > I was there; I was a CP/M weenie for many years. I still use it >from time to time; it's lots of fun. > > The CP/M BIOS definition doesn't provide for all the things a user >might want his/her hardware to do. Accessing serial ports >efficiently is one thing...Some popular CP/M communications programs, >such as the MODEM7 family, used the concept of "overlays" (not the >kind that we use in the PDP-11 world!), which are assembly language >modules which are written for your specific hardware that present a >unified (BIOS-like!) interface to the rest of the MODEM7 code. It >was intended that end users would write these routines for their >specific hardware. (in a day when end users were typically highly >technical people) > > Formatting floppy disks is another example. The CP/M BIOS has no >provision for floppy disk formatting, so a formatter program had to >be written for each floppy controller, and it accessed the >controller's registers directly to perform the formatting (and >sometimes verification) function. > > Other than specialized hardware (lab I/O, speech synthesizers, >real-time clocks) there weren't many instances of programs directly >accessing I/O in my experience. Another way to say that is if the application used BDOS calls there was a near 100% assurance of proper operation. If it did BIOS calls corectly that was near 100% as well. If it played with hardware direct all bets were off. Generally the hardware was simple enough that was a minor issue. The most common case was extra serial IO (modems and the like). Even then there is a YABUT.. If the system was IO interrupt driven and also fully implemented IObyte then doing modem IO was a easy task. The problem with that is CP/M didn't REQUIRE it but would certainly be nicer to use if you had it. Therein lies the statement: Most BIOS were minimal implmentations. It was the Ampro's, Kaypros, DEC vt180 and many others that were more than minimal BIOS and those you could actually count on more things as the bios did the lifting. Allison > -Dave > >-- >Dave McGuire >Port Charlotte, FL >

16 years, 11 months

← Newer
1
...
4
5
6
7
8
9
10
...
43
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb January 2008