test-drb

test-drb@ccmp.vtda.org

101090 discussions

by cclist＠sydex.com

Just finished reading a 9 track tape made with IBM CMS in its dumpfile format. Why on earth--or might I say, what idiot--designed this format? First the file data in a series of records, *then* the file name and other metadata. Anyone know of a DOS/Windows/Unix utility to unravel one of these things? I don't feel too much like coding for a single tape. --Chuck

10 years, 2 months

M7859 KY11-LB PROM contents?

by mattislind＠gmail.com

Has anyone dumped the contents of the bipolar PROMs of the M7859, KY11-LB, programmer's console form the 11/34 and 11/04? Dump for both the program PROMS (512x4 4 pieces) and the decoding PROM (32x8 one piece) are sought after. It has a 8008 chip onboard but my logic analyzer trace is not matching very well with the listing in the manual. Maybe the revisions have changed from the manual. And I cannot find the PROM contents in the engineering drawing. /Mattis

10 years, 2 months

IBM Selectric-based Terminals

by pbirkel＠gmail.com

> - intention was to rip all this out and convert it to a full I/O serial terminal, using an Arduino-based setup > that Lawrence Wilkinson has already built and tested: > https://www.flickr.com/photos/ljw/sets/72157632841492802/with/9201494189/ Looks very nice! Is there documentation for it somewhere? I also have a Selectric (unfortunately it's located distant from me at the moment so I can't provide particulars) that I worked on interfacing to a micro in the mid-70's. I was using a MC6800 in my recollection, but I don't believe that I ever achieved operational status. Presumably I was working from an article in one of the hobbyist magazines of the era. I would have guessed Byte, but that doesn't seem to be the case based on recent search. Any hints from folks on what magazine/article that might have been? The Selectric wasn't one of the curvy(ier) office models; I recall it being a rather boxy affair with plenty of right-angles on the housing and a medium shade of blue -- presumably "IBM Blue". Rather utilitarian in design. Even *more* utilitarian than this one: http://www.covingtoninnovations.com/selectric/100112-Selectric-in-situ.jpg It included a full keyboard. I'm not sure anymore whether it operated in local-mode or was set up as two separate devices and therefore needed to be connected up to a remote controller to get local copy. It might have been a rehoused Selectric mechanism in a third-party enclosure and the IBM-like color a red herring. My recollection is that it was longer front-to-back; presumably the rearward extension housed the additional electronics. I have absolutely no idea how I acquired it. No luck finding a matching photo online as yet. I believe that the Selectric came configured for remote operation, but presumably using an EBCDIC-based data stream. I vaguely recall a DB-50 connector, but it's been an awfully long time ... Does this description sound familiar to anyone? ----- paul

10 years, 2 months

Interest level for new PDP-11 indicator panels

by jnc＠mercury.lcs.mit.edu

> I'm trying to get a sense of how much demand there would be for the > indicator panel option (for parts ordering; I have a chance to buy some > discontinued stuff, and I want to know how much to stock up on). If you > would be interested in one or more indicator panels, could you let me > know? (Please don't reply to the list, just to me personally.) I should have mentioned that we'll likely do a UNIBUS version of the card (ENABLE+, and it should be easy to guess why that name :-) as soon as we're done with the QBUS one; the same indicator panels would be supported by both (so they count to the parts pool). So if you have a UNIBUS machine, and would be interested in adding an ENABLE+ _with indicator panels_, I would be interested to hear about those too. Thanks! Noel

10 years, 2 months

Advice and Suggestions for a Debug Feature

by jhfinedp3k＠compsys.to

Sorry for that BAD stuff in the Subject line - my e-mail provider stuffs that in much of the time and I forget to remove it when I reply. If anyone needs a clean copy, I can send it again! Jerome Fine

10 years, 2 months

[SPAM key] - Re: Advice and Suggestions for a Debug Feature

by jhfinedp3k＠compsys.to

>Tapley, Mark wrote: >>On Dec 16, 2015, at 9:22 AM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote: > >>Note that for many CPUs, adding values (a push) results in the >>stack pointer becoming numerically smaller (unsigned of course). >>Internally, the code would handle the actual arithmetic. >> >(Warning: assembly language noob talking, please disregard if I see to be making no sense.) > >1) Does the debugger enhancement trigger a stop on overall size of stack pointer or on cumulative changes? Or could it be selectable (maybe via a negative argument?) > >Here?s what I?m thinking: suppose a routine is expected to remove things from the stack sequentially, then branch at some point to a subroutine. I want the debugger to halt execution when it branches. So I want the stop to occur when the stack pointer first increases, even if it has already decreased several times and its new value (on branching) is lower than where it was when the debug command was issued. > >2) Some machines (6809, which is the only one I?m familiar with) have a rapid-response branching mechanism for real-time control applications (on the 6809 it?s a Fast Interrupt input). Fewer registers are pushed onto the stack so the service routine can execute sooner. Is there a way to handle this situation? Say I expect two levels of subroutine calls, each stacking a full set of registers, but instead I get for the second subroutine a Fast Interrupt and don?t stack enough registers to trigger the debug counter to halt execution. > > Hope this is useful. > > - Mark > Yes, it is useful since it helps to be aware of what other systems do. So thank you. For those of you who might not have known, this is the Y01.16 Symbolic Debugger from RT-11 and in particular the SDHX.SYS variant. From the point of view of interrupts, when stopped at a breakpoint, the complete system is FROZEN - including RT-11 itself which is the operating system that is being used on the PDP-11. As for the user's stack, that is not even a factor since the Symbolic Debugger has its own stack and executes in Kernel mode. In fact, one of the other enhancements was to ass code to monitor the size of the stack for the Symbolic Debugger - which also allowed that stack to decrease. That was especially helpful since the stack must be in Low Memory in order to handle interrupts and subroutine calls. And as for the user's program stack, there is no effect at all. What the Symbolic Debugger does is save all of the user's registers, including the stack pointer of course. The enhanced code would then compare the original value of the Stack Pointer (actually as noted after the current instruction had been executed) with any subsequent value to determine if the conditions had been met to stop the execution of additional instructions, assuming that the value of the Stack Pointer was included (via value2 and / or value3) in the command to execute more instructions. Jerome Fine

10 years, 2 months

Advice and Suggestions for a Debug Feature

by jhfinedp3k＠compsys.to

I have been investigating the possibility of adding an enhanced feature to a debug program. There does not seem to be anything specific about the concept, so it should be applicable to every current CPU in addition to most old CPUs. The current syntax for many debuggers uses the letter "S" along with an optional value to specify a Single Step (or ONE instruction to be executed when the value is omitted) or a number of Single Steps (a number of instructions) equal to the optional value. Of the two different debuggers for the CPU, operating system and code which I use most of the time, both debuggers display the same information for each of the Single Steps, specifically the actual instruction that will executed and the values of the registers immediately before the instruction is executed. So if a total of 5 instructions are executed, the display is updated 5 times. For the debugger that I wish to enhance, the actual syntax is: value1,value2,value3;S and at present, value2 and value3 are ignored. My question concerns using value2 and value3 to specify the limits by which the stack pointer may change, specifically by adding data (also called a push) and subtracting data (also called a pop) to the stack in whatever manner the program uses to alter the value of the stack pointer register, respectively. Note that for many CPUs, adding values (a push) results in the stack pointer becoming numerically smaller (unsigned of course). Internally, the code would handle the actual arithmetic. For example, if the user specifies: 45,4,2;S then: (a) Up to 45 instructions are executed (b) If the stack has 4 or more pushes, instructions stop (c) If the stack has 2 or more pops, instructions stop Additional information: (a) Scroll / NoScroll is enabled, so the user can pause / resume at any time (b) Any single character by the user stops instructions (c) All pushes and pops are noted AFTER the current instruction is executed - which allows subroutine calls to be automatically handled as per the examples Defaults: (a) If no values are supplied (ONLY ";S"), then "1;S" is assumed and ONE instruction is executed (b) The debugger supports <ESC> in place of ";S" which supports Single Stepping with a single key (c) If any value is omitted, that limitation does not apply More Examples: ,,1;S instructions are executed until the code returns from the subroutine - IF the current instruction calls a subroutine ,,1;S instructions are executed until the code returns to the previous subroutine - IF the current instruction does NOT call a subroutine ,,1;S instructions are executed until the code restores the stack pointer - IF the current instruction does a push or creates space on the stack ,1,2;S instructions are executed until the code calls a second subroutine OR the code returns to the previous subroutine - IF the current code calls a subroutine 55,1,1;S 55 instructions are executed OR until the code calls a second subroutine OR the code returns to the current subroutine - IF the current instruction calls a subroutine 55,1,1;S 55 instructions are executed OR until the code calls a subroutine OR the code returns the the previous subroutine - IF the current instruction does NOT call a subroutine Many more examples could be considered, but that seems to be about the concept that I have. Please advise and comment. Please make any suggestions that would be any improvement and, most important, point out any problems that I have not considered. Jerome Fine

10 years, 2 months

Interest level for new PDP-11 indicator panels

by jnc＠mercury.lcs.mit.edu

So I've mention that Dave Bridgham and I are working on a new QBUS board (the 'QSIC', for lack of a more imaginative name) that will emulate a variety of older DEC disk controllers/drives using a micro-controller/FPGA and SD cards. (We currently have one prototype [for Dave] mostly constructed, and another [for me] half-way done.) Since Dave and I are both blinkenlitz addicts, we're doing an indicator panel option, emulating exactly the look of the old DEC indictor panels (4x36 lights, with 'inlays' to customize a panel to particular controller, mounted in a 5-1/4 panel for a 19" rack). (These panels are specific to the QSIC, and don't work with the original controllers.) A QSIC will be able to drive up to 4 (or so) indicator panels - I plan to have 3 on my machine: RK11, RP11, and a fixed-head disk. So I'm trying to get a sense of how much demand there would be for the indicator panel option (for parts ordering; I have a chance to buy some discontinued stuff, and I want to know how much to stock up on). If you would be interested in one or more indicator panels, could you let me know? (Please don't reply to the list, just to me personally.) Thanks. Noel

10 years, 2 months

Accessible Computing (Was "Re: Display-less computing")

by captainkirk359＠gmail.com

On 13 December 2015 at 13:46, Chuck Guzis <cclist at sydex.com> wrote: > At CDC Sunnyvale ops back in the 1970s, we had a blind programmer working. > His job output came as punched cards and he had no problem reading them by > feel. I remember him and his beautiful guide dog. > Hmm, that kinda makes sense. It would be kinda/sorta like braille. (I guess that would also work for punched tape as well.) I couldn't tell you how good it would be though, I might be vision impaired, but not enough that I've learnt braille. I wonder if any minis or mainframes (or micros) could actually produce output as braille... > In the same sort of spirit, I recall that one of the secretaries used a > monitor-cum-camera affair to enlarge her work documents so that she could > read them. > CCTV readers. They're still a thing. The tests and exams centre at my university has a bunch of them (one each per exam room, and a bunch of old analogue ones still sitting about). I find the older analogue ones are better than the newer digital ones. If only because the text zoom is more "fluid" (my preferred size of "embiggened" (what, it's a perfectly cromulent word) text is right between two of the settings on the machines we have which is mildly annoying); they also have less artefacts when using non-standard video modes (reverse video, or high contrast modes). > It's sad that early corporate efforts to accommodate all people, no matter > the impairment, aren't better documented. > I'd buy a book on that in a heartbeat; necause that is very much of interest to myself. I know DEC had their DECtalk speech synthesizers (isn't the eminent Dr. Hawking's voice an old DECtalk?) and they could be connected to serial lines. Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request.

10 years, 2 months

Rectangular holes punched from cards [was RE: Display-less computing]

by RichA＠LivingComputerMuseum.org

From: Fred Cisin Sent: Tuesday, December 15, 2015 9:12 AM > My father claimed that the use of round holes on divergent cards was due > to an attempt by IBM to patent the shape of the hole in the cards. http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/punchcard/ Prior to 1928, the holes in IBM's cards were round, too. The use of round holes by Univac was an avoidance of paying royalties to IBM, which held a patent on 80-column rectangularly punched cards. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

10 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb