test-drb

test-drb@ccmp.vtda.org

101090 discussions

by marc.verdiell＠gmail.com

Oh, that blue 1970's psychedelic color! The fast line printer! The vacuum column drive (drool)! And it is alive! Congratulations! Marc

10 years, 7 months

'New' PDP-11 prints

by jnc＠mercury.lcs.mit.edu

So, I've been going through all my PDP-11 prints, looking for ones that aren't already online (so I can scan/upload them). I have a couple (see later message), but this is about something else. In doing the above, I ran across an LSI-11 print set (MP-00706) which is about 340 pages long, and contains prints for all manner of boards, some of which do not show up (for reasons I don't understand) when looked for in a common search engine (Google, to be precise). I will eventually be adding them to my list of 'online by unfindable print sets': http://ana-3.lcs.mit.edu/~jnc/tech/FMPSOnline.html (which I have recently updated with more finds falling out of the search of my collection of prints), but: does anyone know of any other similar large compendiums of prints online? In particular, I'm hoping there's a later equivalent (this one's from October 1978) which would show a lot of the later QBUS boards which we don't have prints for. As I previously mentioned, I've gone through a number of PDP-11 print sets which are online (11/05, 11/05S, 11/23, 11/34, etc) in compiling the initial list, but it seems like there are more out there. Please let me know of any others you are aware of, so I can trawl them too! Noel

10 years, 7 months

Self modifying code, lambda calculus - Re: ENIAC programming

by mark＠markesystems.com

> I wrote X.25 software in Fortran:-(. We had some machine specific routines One of my first professional jobs after college was with a company that created after-market hardware and software for Apollo workstations. Despite having a good Pascal, I was tasked with (and completed) a port of a scientific word processor package (WordMarc), all in Fortran (77, at least). Since I ended up being pretty familiar with both the language and environment, I used it again to throw together a simple 8080 assembler in about a day, too. ~~ Mark Moulding

10 years, 7 months

Self modifying code, lambda calculus - Re: ENIAC

by mark＠markesystems.com

> Early 3rd generation machines had special instructions to finagle their > way around self-modifying code: And some didn't: The HP 2100 and the PDP-8 (and I think the Honeywell x16s), instead of a stack, would store the return address of subroutine calls in the first word of the subroutine; obviously, this made recursive subroutines impossible without handling a stack manually. > Few CDCers of the time even knew that the STAR-100 existed. I remember Reading up on the early history of CDC, I stumbled across the "Little Character" - Seymour Cray's six-bit proof of concept for his first computer designs at CDC. Apparently, one was actually built, because it's now at the CHM. However, I haven't been able to find any significant information about this on the Web (my Google-fu must be failing me). Does anyone know where I could find some documentation about this machine? Performance specs (memory size, speed, etc.) would be nice, but I'd really like a detailed architecture and instruction set description - you know, in case someone wanted to make an emulator or something... ~~ Mark Moulding

10 years, 7 months

would like to find blue dg et head looking terminal to go with small ecli...

by COURYHOUSE＠aol.com

yes ET! the one in the with the head in the yoke although anything blue and pretty would be better than nothing! Our Eclipse is not as grand as some photos ,,, and the tape drive is a small side by side reel unit that fits in the single rack here is a photo of ours.... http://www.smecc.org/data_general.htm had it for years need manuals etc and maybe some sales lit. or scans of advertising material to display with it... but yea... it cries out to have a terminal with it! In a message dated 9/22/2015 9:08:14 A.M. US Mountain Standard Time, jwest at classiccmp.org writes: Jay Jaeger wrote... ---- ??? What do you mean by "blue dg et head looking terminal" ??? ---- I'd bet that he's referring to the Data General Dasher D200 terminal. I have one: https://www.flickr.com/photos/131070638 at N02/21058074082 But perhaps a better picture: http://maben.homeip.net/static/s100/data%20general/photos/DG%20dasher%20d200 %20front.jpg The D200 isn't always on ebay, but usually they show up mildly frequently there and seem to go around $200 to $250. There was another common terminal on eclipse systems. I'm not sure if it was in the Dasher series, but I believe it was called a "5821". I have one of these as well. http://www.museumwaalsdorp.nl/computer/images/GRP.jpg Lastly, a common combination system console (terminal)/printer that is VERY cool looking was the Dasher TP1 and TP2. Mine is a TP1. http://www.foxdata.com/blog/wp-content/uploads/2011/05/IMG_0210.jpg J

10 years, 7 months

would like to find blue dg et head looking terminal to go with small ecli...

by COURYHOUSE＠aol.com

that may have been the one i had.... In a message dated 9/22/2015 11:59:29 A.M. US Mountain Standard Time, jwest at classiccmp.org writes: On mine, there is no "blank panel space" to the right of the screen. The screen takes up the entire horizontal width. Diagonally, the terminal "head" measures 21 inches so it's slightly unusually large for a terminal. On the back, under model number it says "5821NT".

10 years, 7 months

PDP-11 Overlays

by jhfinedp3k＠compsys.to

Recently, there have been a number of references to using overlays on the PDP-11. There have also been strong suggestions that overlays were structured differently under the 3 operating systems: RSTS/E, RSX-11 and RT-11. Obviously, I understand how RT-11 overlays were set up, but for those readers who don't: ROOT - contains overlay code subroutines and data tables - data used by more than one overlay FIRST Overlay Region - size of the largest overlay in the region - one or more overlays and the data used by just that overlay SECOND Overlay Region - size of the largest overlay in the region - one or more overlays and the data used by just that overlay THIRD Overlay Region - size of the largest overlay in the region - one or more overlays and the data used by just that overlay FREE MEMORY Any overlay could be called from any location. About the only requirement was that the calling instruction code (specifically the code which followed the calling instruction) had to be in memory when the code returned from the overlay. In practice, the usual protocol was that an overlay in a higher region was only called >from a lower region or the root. I understand that RSTS/E and RSX-11 were a bit more complex. Can anyone briefly summarize and also provide a link to the details in the appropriate manual if it is available on the internet? Jerome Fine

10 years, 7 months

Multi-platform distribution format (Was: Backups [was

by jhfinedp3k＠compsys.to

>Rod Smallwood wrote: > >On 21/09/2015 10:30, Johnny Billquist wrote: > >> >On 2015-09-21 02:11, Jerome H. Fine wrote: >> >>> You bring up a VERY notable lack of support by DEC of that >>> situation!!!!!!!!!!!!!!!!!!!!!! >>> >>> For both the DEC RX01 and the DEC RX02 8" floppy drives, >>> while it might have been possible that DEC engineers were unable >>> to initially figure out how to allow users to perform an LLF (Low >>> Level Format) on the 8" floppy drives, it seems certain that after >>> 3rd party manufactures figured out, DEC could also have supported >>> that function as well. >>> >>> Instead, DEC pretended that all 8" floppy media HAD to be >>> purchased PRE-FORMATTED from DEC. Well, if you >>> ever discussed that option with a DEC person, it certainly >>> did not seem like the individual was pretending. >>> >>> After I managed to locate a DSD (Data Systems Design) >>> drive which supported the DEC RX02 floppy drive function, >>> it was game over for that particular DEC monopoly. The >>> DSD drive was able to perform an LLF for either single >>> density or double density in addition to being both single >>> sided and double sided. >> >> Not that tricky. All you needed was a way to format into RX01 format, >> which is plain simple IBM single side, single density format. >> RX02 floppies have the same low level formatting. To use them in RX02 >> mode just requires flipping a bit in the sector header, and the RX02 >> drive is able to do that. > I am not sure that I understand your suggestion. While I agree that the RX02 was able to switch a single-density floppy to a double-density floppy (and visa versa), the difficulty, as you pointed out, was performing the initial LLF (Low Level Formatting) in the first place on Un-Formatted 8" floppies. That may have been easy with IBM hardware, but DEC made that impossible if all the user had was a DEC system. For readers unfamiliar with DEC vocabulary, the FORMAT command did NOT create a file structure! That command in RT-11 was INITIALIZE and something similar was probably used for RSTS/E and RSX-11. Note that under RT-11, the FORMAT command for the RX02 did NOT perform an LLF, but did set the density bit in each sector if an LLF had already been performed and was sufficiently intact to support clearing out all the data in the sector setting and the density bit to the value requested by the user. In practice, I found that when an RX02 floppy started having problems, the LLF was VERY rarely a problem. For reasons which were not understood, when the floppy media started to have read and or write errors, it was usually possible to have the RX02 floppy drive perform the software command which DEC called FORMAT and re-initialize all the sectors so that the media could be used again without any read and or write errors. That obviously would have required the LLF to be sufficiently present for the software and hardware to repair the problems and reset all the sectors as either single-density or double-density depending on what the user requested. I am not sure what conclusions can be drawn from this example. >>> Note that the RX50 was the same. DEC finally changed >>> their marketing policy with the RX33 drive which used the >>> same 3.5" HD floppy media as the PC. It was actually >>> possible to FORMAT those floppies under RT-11. >> >> No, DEC actually did support users formatting RX50 floppies on their >> own, but only on the Rainbow. >> >> Johnny > If it was possible to perform a LLF using the same RX50 drive on the Rainbow, what was the reason why an LLF could not also be performed on a PDP-11? There seems to be a number of possibilities: (a) There was some hardware that the Rainbow had which was missing on the PDP-11 systems (b) The firmware in the controller on the Rainbow supported an LLF, but the firmware in the controller on the RQDX1, RQDX2 or RQDX3 on the PDP-11 did not support an LLF (c) The Rainbow used a program which DEC supplied that could perform an LLF, but DEC did not supply such a program for the PDP-11 systems (d) Another possibility of which I am not aware. Is there an answer as to which possibility supported the Rainbow being able to perform an LLF using an RX50 drive, but that the PDP-11 systems with that same RX50 could not perform an LLF? >> Take me back to my desk in DECPark thirty years ago and I could have >> pulled out the internal documents on this. > > I cant do that so we will have to make do with my dodgy memory. > When floppy disks first appeared end users just wanted to take the > disk out of the box and use it. > They could not see why they should waste time preparing every new one. > They did not need matching to a particular drive as DEC's > manufacturing tolerances made sure any disk would work on any drive. > > In fact it was more difficult and expensive to provide pre-formatted > disks. > It was more about customer service and making sure the equipment kept > running. > > I heard the following story > > One customer went out and got a huge pile of unformatted (and > untested) floppys and a third party format program. > He expected DEC to make it work. > > The account manager asked to see his DEC maintainance contract and had > to be restrained from tearing it up. > Through the window of the office was building site and the inevitable > 50 gallon oil drum burning rubbish. > He was offered a choice; he could put the disks or the contract in the > burning drum. > > Rod Smallwood > > > > > DEC supplied pre formatted disks I don't know how to respond since different individuals will interpret your story in the opposite manner, So I will add my own experience when I used the RX02 drive from DEC along with the DSD RX03 floppy drive. Around 1990 after I had acquired the DSD RX03 floppy drive in a DSD 880/30 system, I also managed to acquire many brands of 8" floppy media. At that point, I had not yet managed to acquire any tape hardware such as the TK25 which supported a 32 MB disk image, so the floppies were my primary backup. I probably had about a dozen different brands of 8" floppies that required an LLF before they could be used. And since a double-density, double-sided 8" floppy media held about 1 MB (1976 blocks) as opposed to about 1/2 MB (988 blocks) for double-density, single-sided media, I set set about the task of enhancing the DEC DY.MAC RX02 device driver after I found the code in V04.00 of RT-11 which included support for double-sided media. What may be called "interesting" was that DEC had removed all of that optional code in DY.MAC by the time V05.00 of RT-11 was released. That might have had something to do with the fact that DEC never sold (that I heard of) an RX03 drive. In any case, adding and correcting the extra code was quite easy. The challenge was to also add support for a user buffer being above the 1/4 MB boundary in a PDP-11 with all 4 MB of memory when a Mapped RT-11 Monitor was used since the controller supported only 18-bit addresses. Another problem was that the index hole for single-sided floppies was offset about 1/2" from the index hole for double-sided floppies. That challenge was solved by using a DPDT switch to flip the sensors that were used on the DSD 880/30 and that supported using, as double-sided, floppies with the single- sided index hole. While a number of 8" floppies had been purchased that had the double-sided index hole, that was less than 10% of the total and after punching the extra pair of holes in single-sided floppies just a few times, it was very quickly apparent that the DPDT switch was a much better one-time solution. What was initially a surprise was that EITHER the single-sided OR double-sided index hole could be used with the same floppy to access the sectors even though the holes were in different positions. The timing did not seem to matter. Only the device driver software cared if the bit was set one way or the other, so flipping the sensors which were activated was an excellent one-time solution when the user (me!!) wanted to use a floppy with a single-sided index hole as a double-sided floppy. In any case, the code was enhanced, my version of DYX.SYS supported the RX03 double-density, double-sided floppy drive under a 22-bit RT-11 monitor. So I set about the job of the LLFs for double-sided 8" floppy media. As mentioned above, in addition to a couple of dozen 8" DEC floppies, I had about a dozen other brands. To make a long story short at this point, the results were "interesting". Every non-DEC branded 8" floppy could hold an LLF for double-sided, double-density. On the other hand, I seem to remember that only about 2/3 of the DEC 8" floppies managed to complete the LLF. The other 1/3 of the DEC 8" floppies could hold an LLF on the normal first side, but not on the second side. Obviously this story was somewhat different since it was not necessary to ask DEC maintenance to make the LLF capability with the DSD 880/30 to work - it already worked. In addition, there was no DEC maintenance contract in the first place and there was no 50 gallon oil drum. There was also no refusal by DEC to enhance the DY.MAC device driver to support the RX03 floppy drive since DEC was not asked. Over the decades since, I have always wondered how it was even possible for ONLY the DEC 8" floppies to be unable to take an LLF double-sided when every other brand managed to do so. There was probably one floppy that was so severely damaged that it would not take an LLF on either side, but that was a specific exception. Any 8" floppy which could take a double-sided, double-density LLF held the data successfully when used in practice. In any case, I also ask the questions: (a) Was it more difficult and expensive to provide pre-formatted disks? (b) FOR WHOM was it more difficult and expensive to provide pre-formatted disks (DEC or the user)? (c) Was it more about customer service and making sure the equipment kept running? (d) Was it more about DEC charging about TEN times the price for pre-formatted disks over the price for un-formatted disks and having a technician take the time to do the LLF (about 2 minutes for each double-sided, double-density floppy or about 30 floppies an hour)? At the time, I seem to remember that a box of 10 pre-formatted 8" floppies from DEC was about $ 50 while a box of 10 un-formatted 8" floppies was about $ 5 a box. If a technician could format 3 boxes of 8" floppies in an hour, that would seem to save that user about $ 135 which would probably be less expensive for the user. (e) Was it equally reliable and less expensive to use non-DEC unformatted 8" floppies if the user had the necessary hardware and or software to pre-format the floppies? Also, I want to be sure to add that in my experience, RT-11 is probably the best written and documented operating system that I have encountered. While there are still a few bugs that can actually crash the operating system and many enhancements were and are still needed, RT-11 is mostly stable and easy to use. RT-11 obviously lacks any security when running under an UnMapped Monitor since the user has access to all of the memory. Even with a Mapped Monitor, a user program can gain access to the Monitor. But RT-11 was not designed to be secure in the first place. So I still think that DEC did an exceptional job - especially since almost all programs written for the very first version of RT-11 can still run under the latest version. Jerome Fine

10 years, 7 months

Reading a masked ROM the hard way (was Re: Wanted: ROM images from HP 9895, 82901/82902, and other HP-IB disk drives)

by spacewar＠gmail.com

Someone was kind enough to mail me the masked ROM out of his HP 9895 floppy drive. I've read it and mailed it back. It's an MK36000 series 24-pin 8KB masked ROM, with the same pinout as the Motorola MC68764 EPROM, so reading it with an EPROM programmer set for the Motorola part should work fine. In read mode, no programming voltage is applied, so there should be no risk of damage to the part. Unfortunately my Data I/O Unisite does too good a job trying to protect devices against reverse or misaligned insertion or incorrect device configuration; if it thinks the current drawn by the device is too low or too high, it aborts with a device insertion error. The MK36000 draws significantly less current than the MCM68764. I tried putting an appropriately valued resistor in parallel, but still got the error. I ended up kludging the masked ROM to the expansion bus interface of a TI Launchpad board with a Tiva TM4C1294 microcontroller (ARM Cortex-M4 based), using an SN74LVC245A buffer on the data bus because the Tiva is not 5V-tolerant. I wrote C code to read the ROM and send a hex dump out the USB-serial interface. Photo: https://www.flickr.com/photos/22368471 at N04/21611518545/ As I've needed to use the expansion bus interface of the Tiva for other projects, even though this was a lot of work to read one ROM, the experience and maybe even the code may be useful in the future. The next issue is that it appears that the 9895 may permute the address and/or data busses, as the contents of the ROM don't actually look like reasonable Z80 code.

10 years, 7 months

vintage datacenter furniture

by BHuntsman＠mail2.cu-portland.edu

This is sort-of off topic, but not entirely... I've seen a fair amount of furniture like in the following picture: http://dooki.com/supercomputers/ibm/ibm.s390g4.gif It looks well-made, industrial, and vintage (sort of). Anyone know who makes such things? Did IBM have a go-to desk manufacturer for their stuff, or just whatever the customer provided? Thanks! -Ben

10 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb