test-drb

test-drb@ccmp.vtda.org

101090 discussions

by aek＠bitsavers.org

Is there anyone out there that can save these? http://www.vcfed.org/forum/showthread.php?56313-IBM-Displaywriter-printer-(… I'm primarily interested in archiving the software.

8 years, 8 months

Wildly hopeful eBay seller

by jnc＠mercury.lcs.mit.edu

Now, this person: http://www.ebay.com/itm/182469963119 really is ... incredibly over-optimistic. Noel

8 years, 8 months

after a long search, I found the Dr. Dobbs bound volumes

by rdawson16＠hotmail.com

Located here: http://6502.org/documents/publications/dr_dobbs_journal/ Apologies to the list if this is common knowledge. Randy 6502.org: Documents Archive<http://6502.org/documents/publications/dr_dobbs_journal/> 6502.org A collection of useful documents pertaining to the 6502 microprocessor.

8 years, 8 months

adb use on xenix 3.0?

by ray＠arachelian.com

I'm trying to help out Jason Perkins who wants to demo Multiplan on Xenix 3.0 for the Apple Lisa at the upcoming VCF. While the bits for it are on bitsavers, it requires a serial number and so far he's had zero no luck finding one. So I'm trying to use adb to step through the code and find where it checks for the serial number, etc. So I run adb ./brand and then set a breakpoint using :b on "." which is the start address for the binary, and then I do :r /usr/lib/mp/mp and it does stop before the 1st instruction is executed (or maybe right after), however, when I try :s to step to the next instruction it runs the rest of the program in its whole. I know there's also :e which should step but skip over any function calls. I've also tried :ss, and got the same results (whole program runs without stopping). ? and enter does disassemble the non-running binary. $r and $m show registers and the map. I'm actually not sure if I'm setting the breakpoint correctly as $b shows it, but there's also a "command" field next to the address, so if I do :bfoo, it shows address 0 and foo for the command. So what should "command" be? and how do I single step through the running code? Some more details of what I got so far for those with historical interest: The basic installation is untarring the multiplan disk, which writes to /usr/lib/mp and /once. In /once there's a script init.mp that runs brand -s {serial} /usr/lib/mp/inter, but if you enter the wrong serial number it removes all the files. brand seems to look for a string starting with SCOSN - there's 4 copies of the "SCOSN" string inside brand, not sure why. The /usr/lib/mp/inter binary has only one like this: SCOSNMFO9999990000. I suspect that brand replaces the stuff after SCOSN with whatever the properly encoded serial number is. There's some sort of simple ROT13-like encoding of the string stored in inter. Out of the box running "/usr/lib/mp/inter /usr/lib/mp/mp" produces output with a product number and a serial # of NUL-000000 - the "MFO" is decoded to NUL (basically substitutes A for Z, B for Y, 0 for 9, 1 for 8, etc.) and ofc it says invalid serial # and quits. The serial number is checked by both brand and inter, but maybe not the code in mp.cod (I touched a file called /usr/lib/mp/foo.cod and then it said /usr/lib/mp/foo.dat missing, so I touched that one too, and when I ran it, it said invalid serial number. Running inter by itself just prints a banner without saying invalid serial number.) I'm guessing the serial number is 3 letters a dash and 6 digits, but there's maybe 4 more digits that have to be entered, or those 4 extra digits are generated by brand, not sure. However, so far brand hasn't accepted any serial number tried. I suspect inter to be a Microsoft virtual machine that wants to load mp.cod and mp.dat which are the real code for multiplan. I read somewhere that early on MSFT was using VMs to do help them from having to port the same code to lots of targets. This way they could port the interpreter for the vm and run anywhere, though inter has string saying multiplan so perhaps there's some customizations to each copy of inter based on what it's supposed to run? brand seems to take two more options -m and -n (and -q which I suspect is "quiet" as the init.mp script uses it). Both -m and -n cause a core dump but first print "identifier string found at D in" This is an interesting bit of history that I'd like to reverse engineer if possible. brand hasn't been stripped so it's likely a bit easier to disassemble. inter however is stripped, so would be much harder to reverse engineer. But it would be very useful to be able to step through one instruction at a time to find where it's doing a checksum or whatever and try to figure out what the serial number looks like. Jason is trying to brute force it assuming it's SCO-###### by running brand in a loop, but so far no luck either. Thanks.

8 years, 8 months

Ohio Scientific 560Z Board: IT LIVES!

by systems.glitch＠gmail.com

IT LIVES! I spent most of today hacking on the 560Z board. I got the 12-bit porthole going first, took a bit as the manual doesn't tell you that you need IC CC installed if you want to be able to write to the 4K exposed in the porthole. After that, I plugged in a Z80 and tried to get it running the test code in the manual. Turns out I had a dud Z80 :) With a good one installed the test code ran no-problem, as did a little hand written code to push data to the lamp register on the new memory board. I plugged in an IM-6100 and pretty much determined that at least the first one I tried is dead. I'll recheck the soldering on it later -- it's stuffed into a machine pin socket and soldered in, since half of the legs were rotted off by that corrosive black foam everyone loves so much. Anyway, the second IM-6100 works! And the 560Z board works! And the 12-bit RAM board works! I made a (low-res, poorly focused) video with our old digital point-n-shoot: https://www.youtube.com/watch?v=ZYbGXHJST8U The IM-6100 is running a little loop that increments the accumulator and stores it to the lamp register. Storing of course clears the accumulator, but I have the lamp register mapped over RAM, so I just read the value back out of it. My first foray into PDP-8 code, it's certainly different, but it's still just machine code. Very happy that this seems to be coming fully together! Now if only I could find more IM-6100s...I'll test the remaining 3 tomorrow. Thanks, Jonathan

8 years, 8 months

LGP-30 Video Update

by COURYHOUSE＠aol.com

GREAT TO SEE PROGRESS! Keep up the good work Cory! yes, heads have to be close to work.. at least that is the way it was with the VRC drums for storage on the GEPAC process control systyems Ed# _www.smecc.org_ (http://www.smecc.org) In a message dated 2/25/2017 7:24:30 P.M. US Mountain Standard Time, coryheisterkamp at gmail.com writes: Some promising news on getting the LGP-30 up and running. With all systems stable, I tightened the head spacing on the three timing track heads (using brass 0.001" feeler gauges though I may have to go closer). This has resolved 'hanging' when hitting Start; it actually appears to execute for a cycle before toggling back to Stop for each press of the Start key. Of course without being able to see what's happening, it's likely just 'executing' garbage, but it's a solid first step. In Manual mode, keystrokes from the Flexowriter now trigger a Stop/Compute toggle for each key entered and status neons on the flip-flop cards are registering unique bit patterns as each comes in. I put the scope on the (rebuilt) clock generator card and we have good 'T' and 'T-bar' signals propagating, but still haven't licked the 'digital display' issue. After further probing, the display began to stabilize and the single line expanded into the proper 3 for Counter, Instruction and Accumulator, and eventually a bit pattern emerged for the Instruction. No signs of data yet for Counter nor Accumulator, and there is an extremely pronounced 'throbbing' and visible refreshing. Here's a video: https://youtu.be/Nhya46V-l70 System timing looks spot on (top trace), but I also see some 'throbbing' when putting my scope on any of the three timing heads which seems a little strange to me (example on lower trace). Here's a quick vid: https://youtu.be/JjRKDWVUyjA One thought is that the timing and short register heads are still too far off the drum surface for a solid signal, purely conjecture at this stage. -C

8 years, 8 months

HP 2647F cable

by COURYHOUSE＠aol.com

I have a 2647 or a 2628.. ( has cassettes in it) I thought there was basic for it... neat.. how do we generate the tape to load it? Bet the rollers in the drive are toast? details? thanks ed# In a message dated 2/25/2017 4:46:10 P.M. US Mountain Standard Time, mloewen at cpumagic.scol.pa.us writes: On Sat, 25 Feb 2017, Dave wrote: > Also, the online documentation indicates that there is supposed to be a > "BASIC/Autoplot/47" disk, but I only see an "Autoplot/47" disk among the > included floppies. Is this likely to contain the BASIC as well, or am I > missing a disk? I'd be interested in any software anyone may have for > this machine. The HP Museum site has a ZIP file available for download that has 3 disk images: http://www.hpmuseum.net/display_item.php?sw=306 Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/

8 years, 8 months

LGP-30 Video Update

by coryheisterkamp＠gmail.com

Some promising news on getting the LGP-30 up and running. With all systems stable, I tightened the head spacing on the three timing track heads (using brass 0.001" feeler gauges though I may have to go closer). This has resolved 'hanging' when hitting Start; it actually appears to execute for a cycle before toggling back to Stop for each press of the Start key. Of course without being able to see what's happening, it's likely just 'executing' garbage, but it's a solid first step. In Manual mode, keystrokes from the Flexowriter now trigger a Stop/Compute toggle for each key entered and status neons on the flip-flop cards are registering unique bit patterns as each comes in. I put the scope on the (rebuilt) clock generator card and we have good 'T' and 'T-bar' signals propagating, but still haven't licked the 'digital display' issue. After further probing, the display began to stabilize and the single line expanded into the proper 3 for Counter, Instruction and Accumulator, and eventually a bit pattern emerged for the Instruction. No signs of data yet for Counter nor Accumulator, and there is an extremely pronounced 'throbbing' and visible refreshing. Here's a video: https://youtu.be/Nhya46V-l70 System timing looks spot on (top trace), but I also see some 'throbbing' when putting my scope on any of the three timing heads which seems a little strange to me (example on lower trace). Here's a quick vid: https://youtu.be/JjRKDWVUyjA One thought is that the timing and short register heads are still too far off the drum surface for a solid signal, purely conjecture at this stage. -C

8 years, 8 months

VIC 20 in film

by spacewar＠gmail.com

Anyone else notice it in _John Wick Chapter Two_? I don't recall having ever seen a VIC 20 in a mainstream film before.

8 years, 8 months

VIA SMECC __ PART 1 RTTY Journal A Gift to all of us From Bill Henry

by COURYHOUSE＠aol.com

LINKS FOR DOWNLOADING THE RTTY JOURNAL AND FOLLOW ON PUBLICATIONS FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILES FROM THIS SECTION ONLY Thanks to Bill Henry of HAL for putting these into the public domain for all to enjoy. These are ZIP files which will break down to individual issues. They are presented in groups like this to enable easier and quicker downloading. Dates are in filename! These files below represent all of the RTTY Journal that were collected into a set CD-ROMs by Bill Henry K9GWT the owner and most recent publisher and Wayne Matlock, K7WM (SK). These journals represent 50 years or RTTY history in the Amateur Radio Field and along with the ARTS journals (an east coast publication) at SMECC represent a truly fantastic study of Amateur RTTY. The RTTY Journal was first published by the Southern California Radio Teletype Society as the RTTY Bulletin in January 1953. Over the years, the name has changed to RTTY Journal, RTTY Digital Journal and The New RTTY Journal. Past editors included Dusty Dunn (W8CQ), Don and Dee Krumpton, Dale Sinner W6IWO, Jim Mortensen N2HOS (SK) and Bill Henry. Thanks to Chen K7AY and Jay WS7I for distributing these. You will want to pull all of these down and expand them on your hard drive - then, you have the entire publication run as it evolved!. Enjoy! I am spending hours reading these! Ed Sharpe archivist for SMECC FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILES FROM THIS SECTION ONLY _www.smecc.org/media/rttyjournalzip/1953-1962.zip_ (http://www.smecc.org/media/rttyjournalzip/1953-1962.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1963-1972.zip_ (http://www.smecc.org/media/rttyjournalzip/1963-1972.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1973-1977.zip_ (http://www.smecc.org/media/rttyjournalzip/1973-1977.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1978-1982.zip_ (http://www.smecc.org/media/rttyjournalzip/1978-1982.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1983-1987.zip_ (http://www.smecc.org/media/rttyjournalzip/1983-1987.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1988-1991.zip_ (http://www.smecc.org/media/rttyjournalzip/1988-1991.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1992-1994.zip_ (http://www.smecc.org/media/rttyjournalzip/1992-1994.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE _www.smecc.org/media/rttyjournalzip/1998-2003.zip_ (http://www.smecc.org/media/rttyjournalzip/1998-2003.zip) -FEEL FREE TO DISTRIBUTE THIS RTTY JOURNAL ZIP FILE

8 years, 8 months

Jump to page:

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