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

by mbg＠world.std.com

>IIRC in an 11/34, the power connectors are at the A-end of the backplane. Come to think of it, I think you're right... confirmed by the fact that the grant cards go in the D slot, which is the fourth from the back of the chassis... >It wouldn't be hard to make up the harness. It does have 2 connectors on >the PSU end (15 way for power and 6 way for LTC/ACLO/DCLO). The VT11 does >use LTC IIRC to sync the display to the mains and reduce flicker. I guess I could make a harness if I can't find the one which already has one... I'd like to have the printset so I can make the cable lengths correct, and so I have the part numbers for the connectors... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

1
0
0 0

PDP-11/34A rebuild project Was: Re: Post-move diary

by pete＠dunnington.u-net.com

On Mar 30, 17:01, Megan wrote: > Subject: Re: PDP-11/34A rebuild project Was: Re: Post-move diary > > >I believe you can put an MUD or SPC card in slot 5 if you don't have the > >cache. I can't remember what happens if you don't have the FPU - either > >slot 3 is also an SPC slot (I think that's the case) or you move > >everything left one slot (Which I think is not the case). Slot 3 is SPC; you *must* put the two main CPU cards in the rightmost two slots. > First step will be to remove everything from the backplane and > vacuum it out... When you've removed all the disintegrated foam-that-used-to-be-front-panel-filter, you might want to replace it with something less prone to aging. I found the synthetic fibrous filter material sold for cooker hoods (over-the-stove extractor fans) works very well, and you can tear it into half thickness for lighter duty. -- Pete Peter Turnbull Dept. of Computer Science University of York

27 years, 3 months

2
1
0 0

PDP-11/34A rebuild project Was: Re: Post-move diary

by mbg＠world.std.com

>I believe you can put an MUD or SPC card in slot 5 if you don't have the >cache. I can't remember what happens if you don't have the FPU - either >slot 3 is also an SPC slot (I think that's the case) or you move >everything left one slot (Which I think is not the case). I just realized that one of the connectors I did find was one which appeared to connect over-the-top with two boards. The other one I found has three connectors, and the spacing between 1 and 2 is different from that between 2 and 3... I presume it is because 1 and 2 connect to the CPU and FPU in slots 2 and 3, and the third needs extra space to connect to the Cache in slot 5... I may just have what I need to get that working... First step will be to remove everything from the backplane and vacuum it out... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

4
3
0 0

#029 variants (was: IBM 557 Alphabetic Interpreter??

by pete＠dunnington.u-net.com

On Mar 30, 14:14, Fred Cisin (XenoSoft) wrote: > Subject: #029 variants (was: IBM 557 Alphabetic Interpreter?? > In addition to the rare "Interpreter punch", there was also a quite a bit > less rare variant, the "Verifier". It would READ a card as the operator > typed. If the card and keyboard didn't match, (IIRC after a couple of > tries) it would put a notch in the top of the card at the point of > discrepancy. If everything matched, it would put a notch in the side of > the card, as testimony to it having been checked. Yes, we had a few of those -- almost all reserved for "specialist operators". -- Pete Peter Turnbull Dept. of Computer Science University of York

27 years, 3 months

1
0
0 0

Epson HX-20 EPROM programmer???

by rigdonj＠intellistar.net

I have an Epson HX-20 with an EPROM programmer built on. See it at "http://www.intellistar.net\~rigdonj\hx20.jpg". Does anyone know anything about this? The case for the EPROM programmer is made of the same material and is the same color as the Epson case and has the name "Motorola" cast into it. It's held on with a steel bracket underneath. Someone went to a lot of trouble to make this. There's also a ribbon cable (?) cconnector in the top corner. Any idea what it was used for? There are also "Motorola" marked EPROMs in the socket sin teh bottom of the HX-20. Any idea what this machine was used for? The batteries in it are dead and I haven't had time to get it working yet. Joe

27 years, 3 months

2
3
0 0

11/34a restoration diary

by mbg＠world.std.com

Obviously there has been a fair amount of 11/34a traffic today what with the descriptions of the cache/fpu and CPU boards and interconnects. Armed with this info, I searched the documentation I got in the haul and found an 11/34a printset. I also did find 1) the FP11 floating point, 2) the cache, and 3) the two over-the-board connectors which would allow me to connect them to the CPU. First step was cleaning the BA box. I removed all backplanes with the exception of the primary DD11-PK backplane. The other backplanes were the VT11 without a power harness, and an RH11 backplane. I removed all the boards from the primary backplane (noting where they went). I then vacuumed the backplane, removing all sorts of dust and particulate matter, including what appeared to be degraded foam padding, which fell apart if I tried to pick it up. With the backplane as clean as I could make it, I checked the wiring harness and the backplane pins, sighting along the rows and columns looking for any bent pins. Fortunately I didn't find any. So the next step was to apply some power. The power controller in the bottom of the rack did not have a normal 115vac plug on it, so I plugged the BA box into the unswitched side of the power controller I have in the bottom of my 11/10. I tried the front panel switch... nothing... Whoops, forgot the circuit breakers in the back of the BA box. I switched those on, turned the front panel switch and I got DC OK light, and the power supply fans ran (I'd forgotten how noisy they are with the skins off the box). Power off... next step was adding the boards to the backplane, one at a time. With each board, I lengthened the amount of time I left the unit on doing the smoke test... (checking for any whisps of the magic smoke which makes electrical things work :-) I finally had the CPU (two boards), memory (MS11-LD, 128kw, 256kb) the programmers console interface, a serial line, the boot board and a bus terminator in the backplane. With power applied, I finally had the programmer's console displaying something. But when I tried to do stuff, the bus appeared hung. I turned the machine off and thought about it... 'oh yeah, I forgot the bus grant cards"... With bus grant cards in, it powered up just fine and I entered a few simple code fragments (actually single instructions) just to see if it would work. First test was a simple branch to self: 1000/777 started it, and it ran. Next, a memory clearing routine... 0/15740 15740/0 R0/160000 start at 0, it ran briefly and halted with 000002 in the display. Just as expected... memory was clear... At this point I got a little daring and moved boards around so that I could install the FPU, the cache, and the FPU and cache in successive attempts. Unfortunately it didn't work with any of those two boards in it, so I restored it to the working configuration. Slot 1 - 11/34a data paths (ABCDEF) Slot 2 - 11/34a control module (ABCDEF) Slot 3 - boot board (EF), KY11LB console interface (ABCD) Slot 4 - DL11-W (ABCD) Slots 5-9 bus grant cards (D) Slot 9 - Bus terminator (EF) I then checked the address for the console interface, hoping that the serial line unit (DL11-W) that I put in it was actually at the console address, and it appears it was. I then checked the amount of memory and found 124kw (248kb) as expected. So, bottom line is that the first day of real work was quite successful. Next step will be to find the cable I need to attach a terminal to see what sort of boot code is available. Then I'll have to try putting the RUX50 in it, attach that to an RX50 in a leprechaun box, use one of my qbus machines to build an RT-11 bootable RX50, and actually try to boot this thing. Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

1
0
0 0

Post-move diary

by mbg＠world.std.com

27 years, 3 months

2
1
0 0

Rebirth of IMSAI

by allisonp＠world.std.com

<It was always somewhat of a nuissance dealing with the Z-80 because of the <way it presented its interrupt acknowledge, which was a combined I/O and M <cycle, as long as the I/O cycle, but with M1. That meant, in my case, tha All instuction fetch cycles were short, INTA cycle had an extry cycle added for interrupt resolution in the supporting chips. To get around the short M1 cucles I'd use a tiny bit of logit to stutter the clock to the chip (slip a cycle) for M1 only. This results it running generally faster and still using slower memory. <This same protocol made it unwise to try to use memory mapped I/O, since th <cycle length of an I/O cycle differed from that of a memory cycle. I used to do it all the time and like I posted earlier the NS* disk system used MM-IO very effectively. Allison

27 years, 3 months

1
0
0 0

Rebirth of IMSAI

by allisonp＠world.std.com

<I said 'ROM' because on a number of machines, it was just a few TTL chips <that gated C3, lobyte, hibyte onto the data bus on the first 3 fetches <after reset. Most used a mux and jumpers to fake a 3byte rom with the first byte hardwired as C3h (jmp in 8080/8085/z80) and it was jammed on the bus for boot and only then. another approach was to on power up map rom to loc 000 and also F800h and then disable the mapping after the code was running up high. Plenty of tricks to fake that. Allison

27 years, 3 months

1
0
0 0

IBM 4869 / TRS-80 external box????

by roblwill＠usaor.net

Anyone have a spare IBM 4869 floppy drive? Power supply died in mine. I'm also looking for an external floppy from a TRS-80 (w/PS). Doesn't need to have a drive. -- -Jason Willgruber (roblwill(a)usaor.net) ICQ#: 1730318 <http://members.tripod.com/general_1>

27 years, 3 months

1
0
0 0

followup

by allisonp＠world.std.com

<I guess it's fortunate there was only one DMA process going on at the time <else it might have been real sticky figuring out what had been overwritten <already.. If you were doing a read in order to do a write, using DMA, you <might actually get tangled up. Fortunately that showed up while the vendo <was debugging his code, so I didn't have to deal with that. Multiple DMA streams are doable too though hard to apply usefully. <That's quite so. Fortunately one wasn't required to load data at the <granule size, but rather at the sector size, so you could get by with a rea <of a 1K sector. Of course you had to read it before you could write it, s <you had to wait for the next revolution of the disk. All this went by so <fast, and, since I didn't run big databases requiring sorts to and from <disk, I didn't perceive much delay, as it only takes a few revolutions to <load up a program. So each drive had six logical drives on it. I have. Running a pair of drives and using ramdisk and my own smartdisk system. That was the speed order as well, the smartdisk system was fasest as it hard its own CPU and DMA channel to processor ram using hidden cycle stealing plus caching to 4x physical track size. That and a 6MHz z80 and dust flew. <This all sounds like it could be fun if, for example, you're running it al <on classic and unmodified hardware. I'm not sure I'd want to try to earn m <living that way, though. it's more fun on current hardware like 33mhz Z180s and it's still in use in odd pockets here and there. I don't (never did) make a living off it. Allison

27 years, 3 months

1
0
0 0

Computer busses....

by edick＠idcomm.com

Please see comments imbedded below. Dick -----Original Message----- From: Arfon Gryffydd <arfonrg(a)texas.net> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Tuesday, March 30, 1999 11:59 AM Subject: Re: Computer busses.... >>You've hit most of the important signals. One I'd add, however, is a data >>bus disable, and perhaps an address bus disable as well. This would allow a >>front panel or other bus mastering device to steal cycles under certain >>circumstances. > >Why wouldn't BUS REQUEST work? > It would only work if BUS REQUEST were not a request for negotiation. If you do have a bus negotiation handshake, then it might not work simply to asser BUS REQUEST because you may want to "jam" data in to certain locations while the processor is doing most of the work. CPU places addresses on the bus, you, by means of your front panel, want to put different data there. You float his data bus, and drive it yourself while he creates the strobes in his normal timing. Likewise, you might want to redirect his data flow, hence you float his address bus, driving it yourself, while the CPU generates normally timed transaction control signals. It's an obscure point but I've seen it done for whatever reason on several occasions. > >>What would you do with the HALT signal, and how would you implement it? > >WAIT sould act as a "pause and hold the bus in it's current condition" >signal. Halt should mean "Stop what you are doing, release the control of >the bus and wait until the HALT signal is removed". IMHO > Now this one seems like it could be accomplished with the BUS REQUEST signal. I suppose it's arguable, but if you want control of the bus, and want the processor to more or less disconnect himself from it, it would require a signal to each processor/master on the bus. If the FP wants to control the bus, it doesn't have to HALT the processor does it? It just needs to seize the bus. Whether that stops the processor(s) would depend on what's on the CPU card. It depends, of course, on whether you have multiple master candidates on the bus. If not, it's moot, but if so, then you might not want to halt them, but merely seize the bus for a moment. > >>There's some debate about how one should signal the beginning of a new bus >>cycle. This should be at the earliest moment at which addresses are stabile. > >I guess the RD/WR signals should be seperate and only applied AFTER all >signals on the bus are stable. > As I mentioned before, it's quite critical to the operation of the bus, how you time the WRITE signal. Many processors following the MOTOROLA model, i.e. with a regular 2-phase clock, with one clock per bus cycle, tell you when the cycle begins by asserting the "E" clock in the MOT case. If R/W is true at the beginning, it's a read cycle, else R/W must be low, meaning it's a write. Most of the older processors of this sort assert the WRITE state, i.e. R/W LOW quite some time before the E clock (or phase 2) becomes true. Nevertheless, the data is only held valid for a minimal time after the falling edge of E, hence some steps have to be taken to hold the data for some time after end of E so that the data will persist beyond the rising edge of the nWR signal. On a 6800 or 6502, this is quite straightforward. The CPU is fed a single phase clock, sometimes called phase 0. It produces (in the case of the 6502) a pair of non-overlapping complementary clocks, phase 1 and phase 2. The 6800 required you use a clock generator to produce those and feed them to the CPU. You could still gate them with R/W to create nRd and nWr signals, but the results were slightly different. More recent processors don't give you the two clocks, so you don't have as many options. Some give you both an address strobe and a data strobe, from which you can derive appropriately timed nRD and nWR strobes. These often are needlessly short, however, leaving valuable bus bandwidth unused. I think a less conservative though still correct approach would be to limit your statement to signals other than data. Most peripherals require only that the data be stabile on the trailing edge of the write command. It's likewise with memories, so I think that's a safe approach. There are exceptions, though, but I hope they're dead forever. Dick > >---------------------------------------- > Tired of Micro$oft??? > > Move up to a REAL OS... >######__ __ ____ __ __ _ __ # >#####/ / / / / __ | / / / / | |/ /## >####/ / / / / / / / / / / / | /### >###/ /__ / / / / / / / /_/ / / |#### >##/____/ /_/ /_/ /_/ /_____/ /_/|_|#### ># ###### > ("LINUX" for those of you > without fixed-width fonts) >---------------------------------------- >Be a Slacker! http://www.slackware.com > >Slackware Mailing List: >http://www.digitalslackers.net/linux/list.html

27 years, 3 months

2
1
0 0

Tandy 100 pile - could it be valuable?

by fauradon＠pclink.com

By all means if you can get a shot at it do it, get them all. I would be interested in a complete set of each:) Francois >Having said that, I did see a good amount of Model 100s and their >accessories (disk drives, manuals) and a couple of other Tandy things >(cassette recorders). Is any of this especially rare? Some machines might >be model 102s, since I saw the 102 tecnical manual. It would be a fair >amount of effort to get everything; I might be able to convince the surplus >people to make the Tandy stuff their own lot, but I'm not optimistic about >that. > >-- Derek >

27 years, 3 months

9
21
0 0

Computer busses....

by edick＠idcomm.com

You've hit most of the important signals. One I'd add, however, is a data bus disable, and perhaps an address bus disable as well. This would allow a front panel or other bus mastering device to steal cycles under certain circumstances. What would you do with the HALT signal, and how would you implement it? There's some debate about how one should signal the beginning of a new bus cycle. This should be at the earliest moment at which addresses are stabile. If you have separate strobes for memory and I/O, then either of them could do it, or if you generate separate strobes for read and write, that could work as well. The question comes up, however, of how to generate the write strobe, which is often shorter than the read signal from the processor, if there is a separate read strobe at all. On a read, it's generally desirable to time the read strobe so the strobe at the processor goes away, signalling that the data has been sampled, before the memory or I/O device is disabled, making the data go away. Likewise, it's desirable to make the write strobe during processor write cycle go away before its data becomes invalid at the target. What's more, some peripherals don't like having data change once a write cycle begins, so it's necessary to have valid data before signalling a write. This is complicated by the fact that some processors initiate a write cycle before the data is valid, while others do not. Many schemes for generating these signals end up making the processor operate relatively slowly with respect to the memory bandwidth in order to satisfy these conditions. Circuits which latch the data or otherwise fiddle with the cycle length in order to avoid slowing the processor down will increase the parts count and complicate the timing, while those that accomplish this fit by using faster memories and peripherals will cost more due to the higher and not as effectively used bus bandwidth. If you'll start with the model you've suggested, consider the types of devices you anticipate attaching to the bus, and decide how each can be accomodated, you'll eventually settle on a good approach. Dick -----Original Message----- From: Arfon Gryffydd <arfonrg(a)texas.net> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Tuesday, March 30, 1999 9:49 AM Subject: Computer busses.... >Anyone have any idea what was/is the best bus design? > >I'm thinking a stripped down Z-bus (without the M1 signal and etc). What >else should be on a bus besides: > >ADDRESS >DATA >RD/WR >MEM/IO >BUS REQ >BUS ACK >INT >INT ACK >WAIT >HALT >RESET >CLOCK > > >---------------------------------------- > Tired of Micro$oft??? > > Move up to a REAL OS... >######__ __ ____ __ __ _ __ # >#####/ / / / / __ | / / / / | |/ /## >####/ / / / / / / / / / / / | /### >###/ /__ / / / / / / / /_/ / / |#### >##/____/ /_/ /_/ /_/ /_____/ /_/|_|#### ># ###### > ("LINUX" for those of you > without fixed-width fonts) >---------------------------------------- >Be a Slacker! http://www.slackware.com > >Slackware Mailing List: >http://www.digitalslackers.net/linux/list.html

27 years, 3 months

3
2
0 0

Rebirth of IMSAI

by edick＠idcomm.com

It was always somewhat of a nuissance dealing with the Z-80 because of the way it presented its interrupt acknowledge, which was a combined I/O and M1 cycle, as long as the I/O cycle, but with M1. That meant, in my case, that I had to insert a wait state in the M1 cycle in order to avoid having to use much faster RAM, since the M1 signal appeared before either the IORQ or the MEMRQ signals. By either synchronizing the resulting signal with the clock, thereby eliminating the glitch, or by waiting for either of these two steering signals, the resulting cycle was too short. By that I mean that it was almost an entire clock period shorter than the normal M1 cycle would have been, had I been able to ignore the IACK protocol in the Z-80 peripheral devices. I was stuck with them as a result of decisions already made. <sigh> This same protocol made it unwise to try to use memory mapped I/O, since the cycle length of an I/O cycle differed from that of a memory cycle. Dick -----Original Message----- From: Tony Duell <ard(a)p850ug1.demon.co.uk> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Tuesday, March 30, 1999 2:20 PM Subject: Re: Rebirth of IMSAI >> >One of the problems with the S100 bus is that it is _very_ dependant on >> >the 8080 signals. Even using a Z80 is a bit of work - things like PINTE >> >(which indicates if interrupts are enabled) and SSTACK (address lines >> >contain the value of the stack pointer) don't exist as external signals >> >on the Z80. >> > >> Of course if you wire your own Z-80, you can ignore most of the weird >> signals if you are using static ram. Just use a memory write signal for >> writes, and another to gate read data onto the buss. > >True, until you find you have some strange (commercial) card that depends >on one of these signals for some strange reason. I know that many >commercial Z80 CPU boards did have extra logic at least for PINTE. > >> There is nothing in the Z-80, etc. to prevent you from using memory mapped > >-tony >

27 years, 3 months

1
0
0 0

Thrift store loot, some left for others

by max82＠surfree.com

Hi, today was a good day at Amvets on Brighton Ave. in Allston/Brighton, MA. I picked up 6 books on old computers, all of which are available is someone wants them: Minicomputer Systems: Organization, Programming, and Applications (PDP-11) This book is a russian translation of the above title, includes very in-depth explanation of PDP-11 (now I need one) CODASYL: Data Description Language Committee Ditto. Could someone tell me what CODASYL is, though? This book is far too boring for me to figure it out myself... Minicomputers in Data Processing and Simulation In English for a change, has in-depth explanation of computers and their components (including PDP-8, -11, HP and Varian machines) Fortran 77 In Russian Advanced Programming Techniques: A second course in programming using Fortran In Russian Assembly Language Programming In Russian, for a Russian mini or mainframe (EC-EVM) Here is what is still at the store: Osborne-1 with modem in perfect physical condition DEC Letterwriter 100 in perfect physical condition Advanced-looking book: Digital Signal Processing Lots of modern Borland and Microsoft programmer's manuals --Max Eskin (max82(a)surfree.com)

27 years, 3 months

1
0
0 0

Rebirth of IMSAI

by edick＠idcomm.com

Please see comments imbedded below. regards, Dick -----Original Message----- From: Tony Duell <ard(a)p850ug1.demon.co.uk> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, March 29, 1999 5:36 PM Subject: Re: Rebirth of IMSAI >> >> Thanks for posting this information. It might be useful, in addition, at >> least to me, to have to correspondence with the S-100 bus pins so they can >> be cross-referenced to the '696 standard signal names. I do hve the 8080 >> data in house, but nothing tying it to the S-100 bus pinout or timing. > >Isn't this already on-line somewhere? If not, I could type in the pin >descriptions for the Altair 8800b bus that I happen to have here. I have >a very useful book called 'The S100 Handbook' that contains things like >the S100 pinout, schematics for a dozen common cards (including Altair >and Imsai CPU/frontpanel/memory), etc. But I'd rather not duplicate the >work if I don't have to. > >> >> Actually, it might be as correct to say that 8088 signal names are more or >> less like "all the other" microcomputers in the non-Motorola camp. with the >> 8085 and z-80, it became obvious that the large number of strange signals >> generated by the 8080 didn't even help the Intel folks with the task of >> interfacing the processor to memory and peripheral devices. The simple > >One of the problems with the S100 bus is that it is _very_ dependant on >the 8080 signals. Even using a Z80 is a bit of work - things like PINTE >(which indicates if interrupts are enabled) and SSTACK (address lines >contain the value of the stack pointer) don't exist as external signals >on the Z80. What's more, those signals are really of little use. They could be, but it was too much trouble to use them when they were available, so the fact they aren't is of no concern. >> a transfer of data to or from the processor. Additionally, it's nice to >> know whether the read or write is between the processor and memory or I/O. >> With the MOT class of processor, you have an address strobe to tell you a >> cycle's begun, and you have to decode the address to determine whether it's > >Actually, I prefer the Motorola / PDP11 idea of having memory and I/O in >the same address space. It means you can use the same instructions and >addressing modes to access either. > >If the total address space is large enough, you don't need all of it for >memory, so you can assign (say) 1/256th of the entire address space for >I/O. So you use something like an 8-input NAND to decode the top 8 >address lines. One TTL chip. Not a lot of work IMHO. Yes, this was a common approach, and one which we used with bus-based memory mapped I/O on the 6502 and 6809, etc. With a small address space, though, is was common to have the PROM live above the I/O page because the reset vector lived there anyway. With the I/O mapped processors, where the ROM was expected to live at the bottom of addressable memory, tricks had to be used to make the rom at the bottom go away and be replaced with I/O handlers at the top. Intel finally figured that out with the 8086 family, but with IBM's implementation, it became a pain. There it might have been more practical to put all the ROM at the bottom, with each adapter having a pointer at its beginning to indicate where it ended. >[Incidentally, can people please trim the messages they are replying to. >It's not necessary IMHO to include a complete copy at the end of your reply] > >-tony

27 years, 3 months

3
2
0 0

IBM "Baby" 36

by a2k＠one.net

Hello, I'm cleaning out the basement making room for some new stuff... I have an IBM PC/36 (aka Baby 36) Model 5364 with floppy drive and one hard drive (I can get the other drive but it needs to be wiped first). Removed >from operation, still works, needs controller card for console machine. Uses twin-axe terminals. I cleaned it out when I got it (took 5 minutes for the dust to clear from the air in my workroom!) Anybody interested in it? If not, I'd be interested in finding an OS for it and the controller card to put it back in service. Kevin -------------------------------------------------------------------------------- After sifting through the overwritten remaining blocks of Luke's home directory, Luke and PDP-1 sped away from /u/lars, across the surface of the Winchester riding Luke's flying read/write head. PDP-1 had Luke stop at the edge of the cylinder overlooking /usr/spool/uucp. "Unix-to-Unix Copy Program;" said PDP-1. "You will never find a more wretched hive of bugs and flamers. We must be cautious." -- DECWARS ____________________________________________________________________ | Kevin Stewart | "I am a secret | | KC8BLL ----------| Wrapped in a mystery -Milford High School | | a2k(a)one.net | Wrapped in an enigma Drama Tech Dept. | |jlennon(a)nether.net| And drizzled in some tasty chocolate stuff.| --------------------------------------------------------------------

27 years, 3 months

1
0
0 0

FS: Tandy specific printer cables

by rhblake＠bigfoot.com

I have 4 Tandy printer cables to sell, individually or as a lot. 1) 12 ft heavy guage Tandy card edge female to Centronics 36 male $10 plus ship 2) 6 ft heavy guage Tandy card edge female to Centronics 36 male $7.50 plus ship 3) 6 ft flat ribbon Tandy card edge female to Centronics 36 male $5.00 plus ship 4) 6 ft ribbon Tandy header to Centronics 36 male, Tandy number 2x-1409 for PORTABLES, in package $7.50 plus ship ALL ABOVE for $30.00 but will ship FREE. Shipping will most likely fall into the $3.20 priority category for USPS. USA and APO/FPO only. Contact me by direct email

27 years, 3 months

1
0
0 0

AES 7100

by amichael＠nortelnetworks.com

> Lawrence Walker <lwalker(a)mail.interlog.com> wrote: > > Sounds like Doug has a head-startt in collecting Canadian-made computers > what with the Hyperion and the AES. Now to get an ICON and a MCM 70. I > have a couple of clone types. A Tryllium 286 and another, a MAX , a 386 > with > dreadfull physical attributes, looks like an oversized XT, but nice > internal > architecture, OEMed by a Quebec company whose name escapes me at the > moment. > Would that Quebec company be Ogivar? Arlen > -- > Arlen Michaels amichael(a)nortelnetworks.com >

27 years, 3 months

4
5
0 0

IBM 557 Alphabetic Interpreter??

by pete＠dunnington.u-net.com

On Mar 30, 8:34, Fred Cisin (XenoSoft) wrote: > Subject: Re: IBM 557 Alphabetic Interpreter?? > #026 and #029 keypunches, nor the punch outputs of most computers, did > NOT print anything on the card. We had lots of 026 and 029 punches at Edinburgh University when I was there, and they all *did* print on the top edge. I wish I still had some of those cards; alas I only have a few empty steel boxes. Come to that, I wish I had one of the punches :-) -- Pete Peter Turnbull Dept. of Computer Science University of York

27 years, 3 months

1
0
0 0

PDP-11/34A rebuild project Was: Re: Post-move diary

by mbg＠world.std.com

>Great choice to start with! (Uhh, actually, I'm trying to get my own >11/34A running and this will open up our list colleagues' assistance for >benefit of both of us ;-) Thanks... I'm sure it will... >The 11/34A CPU backplane (slots 1-9) has to be a DD11-PK. The backplane does appear to be the correct one... >Does the ID label on the outside, right side panel of the system box say >1134A xx or is it BA11 xx? I'll have to check... >Can't help with the VT11. Sorry. Sounds quite cool though. It is... when I was in college (the first time around), I used to write programs for it under RT-11... I wrote a program for an ME grad student which displayed a four-bar linkage problem, allowing the student to examine the results of various lengths of the legs by actually moving them in real-time with the light pen... Another program I did graphed trajectories of objects given initial angle and velocity... it properly did clipping at the top of the screen if the graph went that far, and did automatic scaling... Finally, I developed a program which allowed design of logic circuits using the light pen to first drag parts from a library along the edge of the screen out to the breadboard field, then wired them, then could supply a clock and test what the circuit did... >Should have three cables connecting to the console panel: a two-wire >shielded cable going to the M9312 (P/N: 70-11413-3F), a four-wire twisted >cable going to the H765 PSU (P/N: 70-11992-0-0) and a 20 cond. flat cable >(P/N: 70-12214-2D) which goes to the M7859 Programmer's Console module. It looks like it has the right cables, but I'll have to check when I get home... Thanks for the info... >The FPU is M8267. (The FP11-A option) Turns out I have one in the box of parts... (see my list at the bottom of this post). >Cache board # M8268 (the KK11-A option) Found it too in the same box... >Important to find the over-the-top jumper boards which go between the >various modules and possibly dependent upon whether you have the FPU in >or out. I'm assuming you got a box with a rat's nest of cables and misc >parts. If so, dig for small PC boards with dual-row, 0.1" center >connectors. Part numbers on white paper labels are H8821 with dual 40-pin >connectors and (hopefully for addition of your planed FP option) the >H8822 with three 40-pin conns. I did find some familiar connectors for such things... I'll have to check them out when I get home and see if they are what I need... >If you do not have the 11/34A printsets and KK11-A Cache tech manual >please get back to me and I'll give you more P/N's and some details on >what goes where based on my system and 11/34A printsets. This can get >confusing with just simple, brief statements. Not for someone who has seen the stuff before... I'm not a guru with it, but I recognize what you're talking about... >I have not found an FP11-A tech manual and printset and Cache printset as >of yet (hint-hint anybody! :) I still have a box of printsets to go through as well... it may just have that in there... we may both luck out... >Two other important cables to root around for in the box, which go >between the M8266 and M7859, are two 10-conductor flat cables P/N >70-11411-1D. When the M8367 FPU board is plugged-in, they run between the >M8267 and the M7859 (this is where the docs are *real* handy) and a >over-the-top board connects the M8266 and M8267. More to checkout when I get home... >The board lineup in my machine is as follows (going from slot #1 to the >left) and the first five must be adhered to: > >#1 M8266, 11/34A Control Module (KD11-EA) >#2 M8265, 11/34A Data Path Module (KD11-EA) These two are in the machine... >#3 M8267, 11/34A Floating Point Processor Not yet, but soon... >#4 M9312 (slot A-B), Bootstrap/Terminator; M9301, but I have an M9312... >#4 M7859 (slot C-D-E-F), Programmer's Console I/F (KY11-LB) It's in there... >#5 M8268, 11/34A Cache (1kbyte) (KK11-A) Not yet... >The following can now be any MUD module . . . >#6 M7891-BC, 64KW MOS memory >#7 M7762, RL01/2 controller (RL11) >#8 G727A, buss grant jumper >#9 M9202, backplane jumper to next backplane . . . Haven't found the RL11 controller yet... I do have the bus grant jumpers, and a terminator in the main backplane. The VT11 backplane wasn't even connected... but then again, it doesn't have a power harness... >For you Megan, the first three slots shall be M8266, M8265 and M8267 with >the H8821 over-the-top jumper between the 8265 and 8267. So, the H8821 is >the hot item to find to get your FPU lit up. I don't think I saw the over-the-top connector in the machine, but I think I saw one in the random parts box... >Incidentally, my system box has several of the module numbers printed on >the slot number label strip going across the top of the backside of the >slot cage. Yours may if it is indeed an 11/34A box instead of a generic >BA11-K. Yep, it has that strip... >Oh, I am salivating at the RUX50 controller! :) Can you clone that >module? Sorry... :-) Okay... here is the list of what I have found (so far) in my collection of UNIBUS related parts... DD11-CK 4 slot hex backplane DD11-DK 9 slot hex backplane DD11-B 4 slot hex backplane (comm backplane?) G109C part of memory option... don't know which yet G114 (with H217C and G235) G231 part of memory option... don't know which yet G235 (with H217C and G114) G651 (with H221A) H114 (with G114 and G235) 2 H214 8 Kw 16-bit stack used in MM11-L H215 8 Kw 18-bit stack (parity) used in MM11-LP H221A 8 Kw 18-bit stack (plugs into G651) 4 M3105 DHU11 - 16-line async mux 3 M5904 RH11 Massbus controll transceiver 2 M5922 RM03 transceiver port A 2 M5923 RM03 transceiver port B M7013 ??? M7014 ??? M7093 FP11-F 11/44 Floating point module M7097 KK11-B 11/44 4 KWord cache module 2 M7228 KW11-P Programmable real-time clock 2 M7260 KD11-B 11/05,10 Data paths 2 M7261 KD11-B 11/05,10 Control logic M7341 ??? M7521 DELUA M7522 RUX50 3 M7547 TUK50 M7684 RK05 control sequencer M7685 RK05? M7686 RK05? 2 M7792 DEUNA port module (1/2) 2 M7793 DEUNA link module (2/2) 3 M7800 DL11 M7819 DZ11-A 8-line async mux 3 M7856 DL11-W SLU and real-time clock M7859 KY11-LB 11/34a programmers console interface M7860 DR11-C parallel I/O 3 M7891 MS11 (I don't know which variants yet) M7892 TU60 Cassette interface M7893 DRS11 M7895 DSS11 M8203 (with M8207) DMP11 M8206 (with M8207) DMC11 M8207 (one with M8203, one with M8206) DMC11/DMP11/DMR11? M8256 RX211 RX02 floppy disk interface M8265 KD11-EA 11/34a data paths module M8266 KD11-EA 11/34a control module M8267 FP11-A 11/34a floating point processor M8268 KK11-A 11/34 cache module M8293 16K UNIBUS timing 2 M8398 DMZ32 24-line async interface M873 BM873 bootstrap/loader 4 M9202 UNIBUS backplane jumper M9312 Boot/terminator M9970 Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

2
1
0 0

IBM 557 Alphabetic Interpreter??

by drbilling＠ucdavis.edu

At 09:41 PM 3/29/99 -0800, you wrote: >On Mon, 29 Mar 1999, John Lawson wrote: > >> Do you actually *own* this, or just know where one is? Tres Cool! > >I might very soon. Its a huge beast! Too adorable to ignore. Verily, it is a huge *beast*, and though adorable it should be ignored, IMHO. Unless it is in perfect working condition, you probably will not be able to restore it to working condition, especially if their is any appreciable wear and tear on the print unit or the giant cams that are inside. The 557 was a very unusual machine in the IBM tabulating line. I worked summers at college for IBM field engineering during the 60's and the 557 was notorius for needing constant maintenance. IBM kept incredibly detailed records of every maintenance action on a piece of punched card equipment, since practically all of them were rented at the time. The 557 was the hanger queen of all tab equipment, consistantly the most maintenance intensive of tab card machines. Open the covers and you will see why. There are two giant cams, about 3' across driving the internals. It takes so much mechanical energy to drive the print wheels, that the wheel cage is actually skewed inside the frame, so that if all the print wheels are printing the same character, they don't all fire at once. I have heard of field engineers taking off the covers of a 557 for the first time, thinking that the whole machine was trashed because the print wheel cage was torqued in relation to the machine frame. When the machine runs it feels like a washing machine out of balance and hops around the floor. -- Dean

27 years, 3 months

3
2
0 0

Post-move diary

by mbg＠world.std.com

Okay, since it has been a long time since I last did anything with a real pdp-8, and since I did pdp-11s for some 20+ years, I decided to start with what I knew... so I started examining the pdp-11/34a I got in the recent move. Turns out that the system box has the cpu backplane, one DD11-DK (9 slot backplane for taking 'small peripheral controller' (SPC) boards), and one VT11 backplane. Unfortunately, there is no power harness on the backplane, no boards in the backplane, and no cable to attach the boards to the VR14 that I did get. I think I may have a VT11 backplane with power harness and boards somewhere in my 'warehouse' (a couple of closets). The machine has the programmers console, but no memory. In one of the boxes I got in the move, I got a couple of MS11-LB memory boards, so I'll use one of them. I think I also got an FPU, but I'll need to see if I got prints for the 11/34a to see where it goes and how it gets connected (if it does). I don't have a cache board, so I'll be looking for one of those. I think I have an RL11 somewhere... but I'll need an RL drive. I may, for the time-being, take one of the RL01s from the -8 system racks. I also have an RUX50 controller and some RX50 disks, so I may try to get that working... I might be able to boot the XXDP+ RX50 kit that I have and do some system diagnostics. That's it for now... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

4
4
0 0

Strange DEC box

by karlm＠blitzen.canberra.edu.au

Hi All, Today I salvaged a very odd looking DEC box, and I have no idea what it is. It is in a black metal case, with vents at the top, the external ports look like those of a VT-100, it has Video in, Video Out, Comm, 20ma Current Loop, and keyboard. The model number is stamped 70-17562-01, but the Serial number is stamped N/A. Does anyone know what this is? I suspect it is some kind of terminal, but I'm not sure. Cheers Karl ------------------------------------------------------------------------------ Karl Maftoum Computer Engineering student at the University of Canberra, Australia Email: k.maftoum(a)student.canberra.edu.au

27 years, 3 months

2
1
0 0

Rebirth of IMSAI

by allisonp＠world.std.com

<One of the problems with the S100 bus is that it is _very_ dependant on <the 8080 signals. Even using a Z80 is a bit of work - things like PINTE <(which indicates if interrupts are enabled) and SSTACK (address lines Neithrr of which had much application. <Actually, I prefer the Motorola / PDP11 idea of having memory and I/O in <the same address space. It means you can use the same instructions and <addressing modes to access either. nothing about z80, 8085 or 8088 stops one from doing that. The Northstar* floppy controller was memory mapped for exactly that reason. Allison

27 years, 3 months

2
1
0 0

Decwriter II

by netcafe＠pirie.mtx.net.au

-----Original Message----- From: Tony Duell <ard(a)p850ug1.demon.co.uk> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Tuesday, 30 March 1999 6:43 Subject: Re: Decwriter II >The paper out logic is pretty simple. The output of the switches goes >through a little RC circuit to the input of a 7474 d-type (unfortunately >which chip this is depends on the board version - it's E5b on an M7723 >and E34b on an M7728). The output of that ff is the ready line. marvin was kind enough to post similar data. Looking at that area this afternoon. >It appears that the switch is closed when the printer is out of paper. So >my first test would be to find the 100 Ohm resistor between the D-input >of that chip (pin 12) and pin BB on the keyboard connector. Unsolder it. >This disconnects all the switches. Does it work now? No. >I don't, alas, have the schematic of the chassis. But it appears from a >general wiring diagram that the paper out switch is in parallel with the >cover interlock switch. Have you checked that one? Yes. the switches are not implicated. I disconnected the whole switch assembly, still no go. Stuck output on the chip I'll bet, the fact it was intermittent for a while makes a logic chip failure even more likely. (I don't think I mentioned that earlier) Thanks for your help...... Cheer Geoff Roberts

27 years, 3 months

2
1
0 0

DEC cables

by rigdonj＠intellistar.net

Hi, I have some DEC cables that I peicked up. Does anyone know what they're for? Marked "BC-022D-10" also "82351-000" DB-25F on both ends estimate 10 foot long Marked "BC22D-50" also "71065" DB-25F on both ends, estimate 50 foot long Marked "BC22D-25" also "71065" DB-25F on both ends, estimate 25 foot long,NIB Thanks, Joe

27 years, 3 months

1
0
0 0

Rebirth of IMSAI

by edick＠idcomm.com

Thanks for posting this information. It might be useful, in addition, at least to me, to have to correspondence with the S-100 bus pins so they can be cross-referenced to the '696 standard signal names. I do hve the 8080 data in house, but nothing tying it to the S-100 bus pinout or timing. Actually, it might be as correct to say that 8088 signal names are more or less like "all the other" microcomputers in the non-Motorola camp. with the 8085 and z-80, it became obvious that the large number of strange signals generated by the 8080 didn't even help the Intel folks with the task of interfacing the processor to memory and peripheral devices. The simple interface used by the 8085 and Z-80, which had to be painstakingly created >from an 8080, lives on, in the ISA and other bus architectures. What it's come down to over the last 20 years is that you need a pair of signals, i.e. nRD and nWR to tell you (1) that something's going on, and (2) whether it's a transfer of data to or from the processor. Additionally, it's nice to know whether the read or write is between the processor and memory or I/O. With the MOT class of processor, you have an address strobe to tell you a cycle's begun, and you have to decode the address to determine whether it's I/O space or memory that's the target. In either case, you need only one level of logic to create the necessary strobes, and none of it is clocked logic, so no nonessential time loss is generated. One of the reasons the S-100 required such fast memory for its relatively slow processors was that you had to operate relatively complex timing structures to create proper timing. That's a reason the standard, in my considered opinion, killed the S-100 rather than perpetuating it. Intel figured this stuff out a decade earlier with its Multibus-I. That used a very ISA-like set of bus handshakes. Because the '696 standards committee couldn't take the hint from the rest of the world and simply pick WHICH write signal to use and WHICH read signal to use and that they couldn't figure out that the system didn't need to have data valid at the beginning of a write cycle, but only a short while before the end, and that data had to be held for a time after the end of a cycle, simply was a dreadful shame. That's what happens when folks meet with no intention of compromising. The result of course, was the chaos that results when surplus vendors e.g. CompuPro/Godbout (cited here because they were BIG, not because they were BAD) design their boards considering only what's out in the dozen 55-gal drums full of TTL parts in the warehouse as opposed to how the functions can be implemented BEST. Dick -----Original Message----- From: Tony Duell <ard(a)p850ug1.demon.co.uk> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, March 29, 1999 2:18 PM Subject: Re: Rebirth of IMSAI >> >> GAWD! The 8080 data sheet! I wonder if my archives go back that far . . . > > >I know I still have the 8080 data sheet (actually a NatSemi version of >it). I found it the other day when looking for the SC/MP data (which I >also found...) > >> Soooo . . . the signals were named the same also, eh? pSYNC, /pWR, sMEMR, >> etc??? > >I have the Imsai 8080 CPU board schematics here. > >Here are the signals (modulo buffering/inverting): > >reset/ -> 8224 clock generator reset >Prdy, Xrdy logically ORed and fed to 8224 rdyin >PINT/ -> 8080 INT >HOLD/ latched by D-type (clocked from phi2), -> 8080 Hold >POC <- 8224 reset output >Phi1 <- levelshifted 8224 phi1 output >SSW DIS/ -> logic -> data buffer enable pins >Phi2 <- 8224 phi2ttl output >Cloc <- gate-delayed version of phi2 >Data, address lines <- 8080 >Pwait, Pwr/, Pdbin, Pinte, Phlda, Psync <- 8080 >CCDSBL -> enable line on buffers for last list of signals. >Addr disbl/ ditto for address buffers >DO Disbl/ ditto for data out buffers >RUN, SS -> logic -> data buffer control >SINTA, SWO, SSTACK, SHLTA, SOUT, SM1, SINP, SMEMR <- 8212 latch on CPU >data lines, clocked by STSTB from 8224. >STAT DISBL -> enable of buffers for those lines. > >That#'s basically it. The S100 bus is very similar to the raw 8080 lines >(like 8-bit ISA is pretty much 8088 signals). > >-tony >

27 years, 3 months

3
3
0 0

ASR-33 Data Format?

by cmcmanis＠mcmanis.com

At 09:27 PM 3/29/99 -0800, Sellam wrote: >Same difference. [110 baud vs 110 bps ] Bzzzt! And thanks for playing. Actually this would be a reasonably good trivia question. The term 'baud' is used to indicate signalling states, the term 'bits' is used to represent transmitted data. The ASR-33 transmits 110 signaling states (bauds) per second, out of every 11 one is a start bit, eight are data bits, and two are stop bits, thus the number of bits per second is actually 8/11 * 110 or 80 bits per second. When you use 8 bits to represent a character this is 10 characters per second. --Chuck

27 years, 3 months

2
1
0 0

followup: Rinky dink hamfest

by rigdonj＠intellistar.net

Today I went to see a couple of the people that I meet at yesterday's hamfest. One of them used to service XEROX computers. He told me that he threw out three rooms full of old XEROX computers less than a year ago. :-( He gave me part of the stuff that he had left, I have to take a Truck (note capital) back to get the rest (estimated at two cubic yards but no complete machines). So far I've found lots of docs and 8" flopppy disks for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM, CPM-86 and MS-DOS. Does anyone have one of these? What's your opinion of them? He has a floppy disk drive control box to manual operate 3.5", 5.25" and 8" drives during alignment. Anyone have an idea of what one of these is worth with the alignment disks and manuals? Alos found a Lisa mouse to go with the Lisa that I got yesterday. Joe

27 years, 3 months

8
12
0 0

Vector Graphic range...

by kevan＠heydon.org

I have been offered a "Vector Graphic B" and would like to find some more information about it. I have found they did a 1 and 1+ from the Haddock book and I have seen reference to an "MZ" on the comprehensive computer catalogue. Where there other machines in their range? The "B" apparently runs the p-system was this common for these machines or did they run any other systems? I would like to talk to any other collectors out there who have one of these machines so I can work out just what I will be getting. Many Thanks -- Kevan Collector of old computers: http://www.heydon.org/kevan/collection/

27 years, 3 months

2
1
0 0

OT: 'Melissa' Virus

by healyzh＠aracnet.com

OK, this is totally off topic, but if you haven't heard the weekends news I'd recommend checking out the following URL: http://www.zdnet.com/zdnn/special/melissavirus.html Normally I discount these as hoaxes, but this isn't. Thankfully I'm one of the 'Dinosaurs' at work that refuses to give up an antique RS/6000 for a nice shiny new NT box, so I'm still on UNIX e-mail. The problem in a nutshell, don't open any messages in a Microsoft E-Mail program with the following title "Important Message From: {persons name}". Zane | Zane H. Healy | UNIX Systems Adminstrator | | healyzh(a)aracnet.com (primary) | Linux Enthusiast | | healyzh(a)holonet.net (alternate) | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | and Zane's Computer Museum. | | http://www.dragonfire.net/~healyzh/ |

27 years, 3 months

6
9
0 0

Decwriter II

by geoffrob＠stmarks.pp.catholic.edu.au

Anyone know where I'd find a circuit diagram for a Decwriter II? Preferably in South Australia. I have one that thinks it's permanantly out of paper. (No, it doesn't seem to be a microswitch) I suspect it's just a stuck logic state in a 74xx ttl chip, but a circuit will make it a lot easier to find..... Alternatively, if this is a common fault, anyone know which chip is implicated? Cheers Geoff Roberts Computer Systems Manager Saint Mark's College Port Pirie, South Australia. Email: geoffrob(a)stmarks.pp.catholic.edu.au ICQ #: 1970476 Phone: 61-8-8633-8834 Mobile: 61-411-623-978 Fax: 61-8-8633-0104

27 years, 3 months

5
4
0 0

IBM 557 Alphabetic Interpreter??

by jimw＠agora.rdrop.com

At 08:37 PM 3/29/99 -0800, Sellam wrote: > >Does anyone know what the function of an IBM 557 Alphabetic Interpreter >is/was? ... and yes, if you had not guessed... I still have a manual on how to program these things! (now, if I could just remember that trick that we used to teach a 402 tabulator how to multiply... B^} ) -jim --- jimw(a)agora.rdrop.com The Computer Garage - http://www.rdrop.com/~jimw Computer Garage Fax - (503) 646-0174

27 years, 3 months

4
3
0 0

Dec color schemes

by cmcmanis＠mcmanis.com

Another interesting thing I noticed this evening is that the color scheme of the PDP-8/f is subtley different than the scheme of the 8/m. The Rust colored handles are the same but the brown ones are more yellow. Megan's got a picture of the green one that was the 'lab' 8. How many were there? --Chuck (who thought he had extra 8 switches but finds he has mostly extra 8/m switches)

27 years, 3 months

1
0
0 0

ASR-33 Data Format?

by kyrrin＠bluefeathertech.com

At 21:27 29-03-1999 -0800, you wrote: >On Mon, 29 Mar 1999, Bruce Lane wrote: > >> Actually, ASR-33's ran at 110 Baud rather than BPS. > >Same difference. > >(you were just joking though, I'm sure) No I was not, and it's not necessarily the same (contrary to popular belief). From 'Data Transmission, Second Edition' by Tugal and Tugal (McGraw-Hill, 1989), Pages 133-134: "...The transmission rate is generally expressed in Baud (Bd). Although in most systems it is equivalent to bits per second (b/s), the baud transmission rate must not be confused with the information rate, bits per second, the rate at which actual data are transmitted. One baud signal may carry one or more bits of the data..." The book goes on to detail some specific examples. In essence, in a case where QAM (Quadrature Amplitude Modulation) is used between a pair of 9600 b/s modems, every discrete change in the signal represents four bits. 9600/4 = 2400, so the actual 'baud' rate of such a signal is 2400, even though the bits/second is 9600. They give another example specifically related to the transmission of ASCII code where the baud rate is representative of the total number of bits in a single character (11 in their example, made up of 8 data, 1 start, and two stop bits). Anyway, it makes a good read. The book itself may be a bit dated, but the principles don't change. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bruce Lane, Owner and head honcho, Blue Feather Technologies http://www.bluefeathertech.com Amateur Radio:(WD6EOS) E-mail: kyrrin(a)bluefeathertech.com SysOp: The Dragon's Cave (Fido 1:343/272, 253-639-9905) "Our science can only describe an object, event, or living thing in our own human terms. It cannot, in any way, define any of them..."

27 years, 3 months

1
0
0 0

IBM 557 Alphabetic Interpreter??

by jimw＠agora.rdrop.com

At 09:48 PM 3/29/99 -0800, Sellam wrote: >On Mon, 29 Mar 1999, James Willing wrote: >> At 08:37 PM 3/29/99 -0800, Sellam wrote: >> > >> >Does anyone know what the function of an IBM 557 Alphabetic Interpreter >> >is/was? >> >> ... and yes, if you had not guessed... I still have a manual on how to >> program these things! > >Cool. I especially liked the patch panel. I'd love to learn how to >program the thing. OOH!!! I see a program for VCF III coming on! "Progamming IBM Unit Record Equipment"! You will have to find a couple of more pieces tho... We'll need a keypunch, a sorter would be nice, (I have both of those, but they are a bit hard to move that far), a reproducer would probably be excessive, but a tabulator or calculator would be just keen! (WARNING - IBM had a REAL interesting definition of "calculator") A collator might be fun too... >> (now, if I could just remember that trick that we used to teach a 402 >> tabulator how to multiply... B^} ) > >Are you implying these things had some general purpose computing >attributes? Yes... (BTW: brain fart - it was a 403 that we taught how to multiply) The Tabulators could do addition, subtraction, and summary functions (basic accounting machines) controlled by the programming on the plug board. The Calculators could also do multiply, divide, and logical functions. Again, controleld by plug boards and the cards... Any which way... watch out what you ask for! I can probably still teach someone how to program these things! B^} (Damn, I'm starting to feel old!) -jim --- jimw(a)agora.rdrop.com The Computer Garage - http://www.rdrop.com/~jimw Computer Garage Fax - (503) 646-0174

27 years, 3 months

1
0
0 0

followup

by edick＠idcomm.com

><I have no idea, however, how you block and deblock I/O with 1K blocks when ><you have only 1k in your sector buffer. I suppose I could go back and loo > >You copy the sector to the 1k ram area and then copy out the desired >sector. the real trick is keeping track of whats in ram and if it has >to be written back. I guess it's fortunate there was only one DMA process going on at the time, else it might have been real sticky figuring out what had been overwritten already.. If you were doing a read in order to do a write, using DMA, you might actually get tangled up. Fortunately that showed up while the vendor was debugging his code, so I didn't have to deal with that. ><at the software, but the stuff I had at my disposal at the time seemed to ><work best with a big hard disk requiring the largest available granules ><(allocation blocks) and since the logical drives were limited to 8MB and > >the largest allocation blocks are due to the need to store in ram on a bit >per allocation block basis, a bit for every allocation block on the disk. >for something like a 8mb disk using 4k blcks that would be 256 bytes! That's quite so. Fortunately one wasn't required to load data at the granule size, but rather at the sector size, so you could get by with a read of a 1K sector. Of course you had to read it before you could write it, so you had to wait for the next revolution of the disk. All this went by so fast, and, since I didn't run big databases requiring sorts to and from disk, I didn't perceive much delay, as it only takes a few revolutions to load up a program. So each drive had six logical drives on it. ><since CP/M was pretty much a thing of the past, I didn't see any point in ><wasting time and resources fine-tuning it. I used it because I had a few ><already-paid for cross assemblers and other tools for CP/M. Once a decent ><version of the PC-DOS became available, I was sure to make the switch. O ><course I didn't realize how long that would be. Nonetheless, once I had a ><PC with a '186 processor, I could run the CPM emulator to use my tools and ><the more modern hardware to do my work, and the CPM became a relic. > >Shame. I still use it. And I'm still finding ways to tune it for even >more performance. It was the active full time OS amd machine until >89 when I went pdp-11. After that it was the part time on line system. > >Current project is to add heirarchal directories (not the ZCPR user thing). >it turns out to be doable though the bdos will have to be altered. This all sounds like it could be fun if, for example, you're running it all on classic and unmodified hardware. I'm not sure I'd want to try to earn my living that way, though. >Allison >

27 years, 3 months

1
0
0 0

IBM 557 Alphabetic Interpreter??

by fmc＠reanimators.org

Sellam Ismail <dastar(a)ncal.verio.com> wrote: > Does anyone know what the function of an IBM 557 Alphabetic Interpreter > is/was? Yeah, it "interprets" punched cards, meaning it reads the punches and prints human-readable characters, probably across the 12-edge. "Alphabetic" probably means "can do letters too" (in addition to 0-9). I vaguely remember one that used to sit in the University of Maryland College Park Computer Science Center dispatch room, as I recall it would print sixty-mumble characters across the the 12-edge and put the next eleventy-so off to the right about where the 12-punches would be. -Frank McConnell

27 years, 3 months

1
0
0 0

Oneac ON! computer

by rws＠enteract.com

Hi everybody- First off my e-mail address changed. I used to be rws(a)ais.net, now it's rws(a)enteract.com. Second, at the LAMARSfest yesterday at Grayslake IL (which was pretty poor- a few expensive C=64's, lots of expensive PC clones, and not much else), I got an Oneac ON! computer. (Actually somebody was holding a "weird CP/M computer" for me there.) It's a black box about a foot square by 3" tall, with no on/off switch, a huge capacitor inside across the rectified mains to keep the switcher running for a while in case of power failure, and serial console I/O. It has a ONFILE (basically a RAMdisk) of 2 MB, in 4256 DRAMs. A 5 1/4" DSQD floppy is permanently connected by ribbon cable. It appears from the somewhat sketchy manual that it runs ZCPR. Upon plugging it in and waiting 30 seconds, hitting CR gets a nice main menu with choices of a (decent) monitor, initialize the ONFILE, run Z-system, and a few other things. I can't get it to load from disk to init the ONFILE yet but I didn't try very hard yet. Has anyone even heard of this thing? It looks pretty neat. I hope I can get it running. Richard Schauer rws(a)enteract.com

27 years, 3 months

1
0
0 0

IBM 557 Alphabetic Interpreter??

by jimw＠agora.rdrop.com

At 08:37 PM 3/29/99 -0800, you wrote: > >Does anyone know what the function of an IBM 557 Alphabetic Interpreter >is/was? > >Looks like a punch card sorter of some sort. Not quite... The 557 interpreter reads and prints the content of a card back onto the card, in a format of up to 60 print columns and on one of 25 selectable horizontal positions. Thie was a more advanced model that the previous 548 and 552 models, and had more available options. Some of these included: (quoted from "IBM Machine Operation and Wiring - 2nd edition") * Repetitive print for printing on detail cards the information read from an X or NX master * Proof checking of interpreting and other functions * A second print entry that will permit one control panel to handle two lines or two jobs * A pre-sensing (control-X reading) station for use in selecting alphabetic information and also for use in the repetitive-print operation * Large type wheels and check protection (for printing checks) Up to four selective stackers So, why? Did you find one??? -jim --- jimw(a)agora.rdrop.com The Computer Garage - http://www.rdrop.com/~jimw Computer Garage Fax - (503) 646-0174

27 years, 3 months

1
0
0 0

followup: Rinky dink hamfest

by allisonp＠world.std.com

<I have no idea, however, how you block and deblock I/O with 1K blocks when <you have only 1k in your sector buffer. I suppose I could go back and loo You copy the sector to the 1k ram area and then copy out the desired sector. the real trick is keeping track of whats in ram and if it has to be written back. <at the software, but the stuff I had at my disposal at the time seemed to <work best with a big hard disk requiring the largest available granules <(allocation blocks) and since the logical drives were limited to 8MB and the largest allocation blocks are due to the need to store in ram on a bit per allocation block basis, a bit for every allocation block on the disk. for something like a 8mb disk using 4k blcks that would be 256 bytes! <since CP/M was pretty much a thing of the past, I didn't see any point in <wasting time and resources fine-tuning it. I used it because I had a few <already-paid for cross assemblers and other tools for CP/M. Once a decent <version of the PC-DOS became available, I was sure to make the switch. O <course I didn't realize how long that would be. Nonetheless, once I had a <PC with a '186 processor, I could run the CPM emulator to use my tools and <the more modern hardware to do my work, and the CPM became a relic. Shame. I still use it. And I'm still finding ways to tune it for even more performance. It was the active full time OS amd machine until 89 when I went pdp-11. After that it was the part time on line system. Current project is to add heirarchal directories (not the ZCPR user thing). it turns out to be doable though the bdos will have to be altered. Allison

27 years, 3 months

1
0
0 0

ASR-33 Data Format?

by allisonp＠world.std.com

<Teletype, so I'm pretty sure the Elf code is correct. I'm using 110 <bits per second, no parity, 8 data bits, one low (logic 0) start bit, <and one high (logic 1) stop bit. It seems to like the data TWO stop bits, tty did two. 8n2 <characters; I get consistent hex values for each character I send to the <Elf, but they seem to usually be either shifted left or right by one <bit, or they have the high bit set when it shouldn't be. It feels like It may be the one stop bit missing or there are too many transistions going on die to contact bounce (dirty commutator and poor signal conditioning on the other end). TTy reading 8 level tape is a continious stream of start, lsb...msb,stop stop and repeat. the COSMAC in this case is just sitting there playing catch. If the timing loop is off on the RX end you get garbage. Allison

27 years, 3 months

1
0
0 0

Strange DEC box

by mbg＠world.std.com

>Today I salvaged a very odd looking DEC box, and I have no idea what it >is. It is in a black metal case, with vents at the top, the external >ports look like those of a VT-100, it has Video in, Video Out, Comm, 20ma >Current Loop, and keyboard. The model number is stamped 70-17562-01, but >the Serial number is stamped N/A. > >Does anyone know what this is? I suspect it is some kind of terminal, but >I'm not sure. I think it is the VT100 portion of a VSV11... the output of the VT100 in that box could be fed through a signal cable to the VSV11, and thus displayed... (If you otherwise have no need for it, I have a VSV11 without that part). Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

27 years, 3 months

1
0
0 0

Strange DEC box

by danburrows＠mindspring.com

Yes. That is the "toaster" that is a VT100 logic board and power supply to provide 'normal' text and video sync on green with a VS11 graphics board set. I have a few here along with the VS11 boards and docs. If you don't have the VS11and cab kit you can use the video out and go straight into a VR241 green. Dan -----Original Message----- From: Karl Maftoum <karlm(a)blitzen.canberra.edu.au> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, March 29, 1999 11:03 PM Subject: Strange DEC box > >Hi All, > >Today I salvaged a very odd looking DEC box, and I have no idea what it >is. It is in a black metal case, with vents at the top, the external ports >look like those of a VT-100, it has Video in, Video Out, Comm, 20ma >Current Loop, and keyboard. The model number is stamped 70-17562-01, but >the Serial number is stamped N/A. > >Does anyone know what this is? I suspect it is some kind of terminal, but >I'm not sure. > >Cheers >Karl > > >--------------------------------------------------------------------------- --- > >Karl Maftoum >Computer Engineering student at the University of Canberra, Australia > >Email: k.maftoum(a)student.canberra.edu.au >

27 years, 3 months

1
0
0 0

followup: Rinky dink hamfest

by edick＠idcomm.com

I have to defer to your more recent experience. Aside from the occasional job requiring my portable development station, I seldom used CP/M after 1984 or so. I did have a farily flexible prom programmer with which I could program parts not yet supported on my PC-based programmer, but in the span between '81 and '84, I had other concerns. I have no idea, however, how you block and deblock I/O with 1K blocks when you have only 1k in your sector buffer. I suppose I could go back and look at the software, but the stuff I had at my disposal at the time seemed to work best with a big hard disk requiring the largest available granules (allocation blocks) and since the logical drives were limited to 8MB and since CP/M was pretty much a thing of the past, I didn't see any point in wasting time and resources fine-tuning it. I used it because I had a few already-paid for cross assemblers and other tools for CP/M. Once a decent version of the PC-DOS became available, I was sure to make the switch. Of course I didn't realize how long that would be. Nonetheless, once I had a PC with a '186 processor, I could run the CPM emulator to use my tools and the more modern hardware to do my work, and the CPM became a relic. It had performed fairly well and competitively with the PC up to the point at which I got an XT clone which used a '186 at 16 MHz. Together with a couple of fairly fast drives it outperformed CP/M on the Z-80 even when it was emulating CP/M. Dick -----Original Message----- From: Allison J Parent <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, March 29, 1999 8:01 PM Subject: Re: followup: Rinky dink hamfest ><I agree that the ramdisk improved performance. It was just the ><implementations that made the system so fragile once ramdisk was in place. > >I have a kaypro with a 2048k ramdisk, it screams and would beat any kaypro <snip> >Allison >

27 years, 3 months

1
0
0 0

Help: root password for System V/i860

by ss＠allegro.com

Hi, I just picked up an i860 box, which has System V on it ... and I don't know the root password. If I interrupt the boot cycle at the start, I get a prompt of "?". If I say "boot", it boots System V and puts me at a login prompt. Is there a way to get logged on as root without knowing the root password? thanks, Stan Sieler sieler(a)allegro.com

27 years, 3 months

2
1
0 0

Decwriter II

by danburrows＠mindspring.com

>Just how much does one of these (*#^@&* things weigh? I had to move mine >today to get a monitor box for a 21" monitor that was sitting behind it. >After moving the DECwriter the monitor which was about 80 pounds seemed >downright lite! > I know they are under 140 lbs. I FedX P1 shipped one for a customer. (it had to be under 150 to go P1 and not the freight group) Also 2 of them on a pallet with a heavy box over them was 270 lbs IIRC. They are just cumbersome. Dan

27 years, 3 months

2
1
0 0

followup: Rinky dink hamfest

by allisonp＠world.std.com

<I agree that the ramdisk improved performance. It was just the <implementations that made the system so fragile once ramdisk was in place. I have a kaypro with a 2048k ramdisk, it screams and would beat any kaypro hard disk. I also have a 512k Mdrive on s100 and it's plenty big enough and fast. Fragile, neither. <The virtual disk features with which I had contact were pretty memory <hungry, in that they required a fair sized buffer in order to allow speedy <caching of data from the drive from which it was being loaded. They There were some ugly implmentations. The first one I did was in late '80 and was pretty tight. No banking and it left 56k(to the base of the BDOS) for transient programs. <or that it provide a buffer in lower memory so that the higher memory coul <be switched in and out. This became quite taxing in terms of hardware <resources and memory bandwidth. I never ran out of either. <You're certainly right about the observations you made of the effect of <various floppy disk handling factors, e.g. sector skew, on performance. <Since you're probably referring to SSSD floppies, which were not only the <smallest but also the slowest, I can see why you might favor such a scheme By late 82 I was running a 4 z80/6MHz multiprocessor system using CP/M2.2 as the core OS with a task manager added. I've done most all of it at one time or another. I took advantage that statistically the data bus was actually unused between 40-60% of the time! Z80 T1 and T2 states offer very litle in the way of actual transfer activity other than preperation. <The software overhead was burdensome only because it had to reserve quite <bit of memory in order to block and deblock on a track-by track basis. <That's why we didn't use ramdisk. One could manage disk I/O almost <transparently when the disk was spinning at 3600 instead of 360 rpm. Well to deblock you only needed a chunk the size of disk sector and typically that was 256 or 512 bytes, trivial space. The code to do it is under 512bytes. Giving up 1k for a huge increase in performance is worth it. Usually I would bump that host buffer up to at least the same size as the allocation block size, as that meant you could cache a whole allocation block. That usualy being either 2k or 4k. For that I would bank in a small amount of ram in lowmem just for that and generally that was based on the common size chips (2k or 8k x8 rams). later I would do a full MMU for even more space for track buffers. the code to do basic deblock will do any size with ease. The latentcy even at 3600 rpm is low but that assumes DMA direct to ram. most controllers had a small (usually 1-2 sectors) sized buffer and would read to buffer and transfer from there.. added delays. Also those controllers could be driven harder than the usual supplied drivers did for far greater peformance. The bios often used the least efficient means to move the selected 128 bytes to the target address. Considering how often that was done it's a big hit. The average systems did not utilize the possible performance of the z80 even at 4mhz. When 6 and 8mhz parts started to show up they were often idling in loops waiting for something to happen. Spooling printer and keyboard/modem interrupts were often not done. So the user often never saw type ahead or any semblence of concurrency. All of which were possible. If there is a point, CP/M prevented nothing performance wise and usually anything it did offer was not used (it can signal when to flush the cache). Think like forground/background were easily done and there were a few print spoolers that really worked. Allison

27 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb