I recently unearthed two 250 Mb QIC cartridges (like we used to use on
Sun workstations). They were last written on in late 1997.
I have no idea if they're any good, but they're free to anyone who'll
pay postage (from Israel).
If no takers, I'll just toss 'em.
Thanks,
Arnold
Here is a dump of the ROM in a text-based format. I couldn't think of a good way to represent the 4-bit words in a normal binary format with the order being ambiguous.
Connecting a logic analyzer up to the ROM and triggering an "autoload" sequence, the processor reads ROM address 0, followed by ROM address 1, and then seems to lock up. I'm curious if the processor is attempting to store the 8-bit word into RAM for some reason? My RAM board is in very poor condition and I will need to devise a way to troubleshoot it. It'd also be helpful to have some of those control lines hooked up to the logic analyzer while it is happening.
I'm working on a disassembler that should let me shuffle the order of the 4-bit words around until I get something that looks sane.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 13, 2020 3:27 PM, Ken Thompson <ken(a)google.com> wrote:
> can you send me the bits of the rom.
> i will take a look.
>
> On Tue, May 12, 2020 at 12:44 PM TangentDelta via TUHS <tuhs(a)minnie.tuhs.org> wrote:
>
>> Hello.
>>
>> I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save.
>>
>> The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers.
>>
>> I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler.
>>
>> My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it.
>>
>> If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it!
>>
>> Thanks.
Hello.
I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save.
The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers.
I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler.
My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it.
If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it!
Thanks.
> Does anyone know if dbx ended up 8 or 9th
I believe the only debuggers on research machines were
db v1-v6
adb v7,v9,v10
cdb v3-v6
sdb v8-v9
pi v8-v10
Doug
Reading some more stuff about the road from 7th Edition to 8th Edition, this time about debuggers.
My current understanding is as follows:
- On 6th edition the debugger was ‘cdb’
- On 7th edition it was ‘adb’, a rewrite / evolution from ‘cdb’
- In 32V a new debugger appears, ‘sdb’. Its code seems a derivative from ‘adb’, but the command language is substantially reworked and it uses a modified variant of the a.out linker format - in essence the beginnings of ‘stabs’. Of course the compiler, assembler, linker and related tools all emit/recognize these new symbol table elements.
- The July 78 file note by London/Reiser does not mention a reworked debugger at all; the 32V tape that is on TUHS has ’sdb' files that are dated Feb/Mar 1979. This stuff must have been developed between July 78 and March 79.
- In the SysIII and 3BSD code on TUHS (from early 80 and late 79 respectively) the stabs format is more developed. For SysIII it is ‘VAX only’. With these roots, it is not surprising that it is also in 8th Edition.
Two questions:
(1) According to Wikipedia the original author of the stabs format is unknown. It also says that the original author of ‘sdb’ is unknown. Is that correct, is the author really unknown?
(2) As far as I can tell, the ’sdb’ debugger was never back ported to 16 bit Unix, not in the SysIII line and not in the 2.xBSD line. It would seem to me that the simple stabs format of 32V would have lent itself to being back ported. Is it correct that no PDP11 Unix used (a simple) stabs tool chain and debugger?
I've forgotten who created stdio, USG or the research group. Can any of the
youthful BTL folks of the 1970's refresh my mind.
Given that stdio was invented and, in my opinion at the time, a reasonable
and usable standard interface to IO on Unix, I am curious why no standard
for networking was developed or proposed and discussed. Sockets just
defined a new and very quirky IO interface for Unix based systems.
Was any thought given to defining networking
using the
creat/open/read/write/close/mknod/link/unlink/chmod/chown
model of IO in UNIX?
Ed Bradford
--
Advice is judged by results, not by intentions.
Cicero
I was lucky enough to be in the room last year at VCF East when Ken
told the story of how the move from Berkeley to Bell Labs happened.
Ken's description of his interactions with the Bell recruiter was
entertaining and made clear that persistent effort was needed to get
him to come out to New Jersey and meet some of the people there.
Does anyone know who the recruiter was?
hello
Was sml/nj part of UNIX at some point? was it considered as a language to use
(proof tools may be)?
I was wondering if there is any history in common between the two. I've been
unable to find anything :-?, please share your stories! :-D
Is it true that the language was too slow to be generally useful? There seems
to be commentaries along these lines on the internet.
thanks!
gabi
