> When pushing them for more answers on details of their hacked together
> video solution, and ideas for scan converting --- they clammed up, and
> said that since they will be offering a commercial product at some point
> in the future, they couldn't talk about it. Weren't going to document
> it publicly, post it online, etc.
Did I read that right? A commercial FPGA Lisa implementation in the future?
Or a commercial scan converter?
Tim.
> I think the mole is defined from the number of attons in a certain mass
> of a certain isotope of an certain element (carbon 12 IIRC)
>
The mole is the amount of a substance which contains Avogadro's number
(6.0225 ? 10^23 ) of atoms or molecules of the substance.
Stated differently, it is the same amount of grammes of the substance as
that element's molecular weight.
The definition says that it is the amount of a substance which contains
the same number of molecules of the substance as 12 grammes of
carbon-12, which is a way of expressing the number of molecules in such
a manner that the required number of molecules can be provided by means
of weighing, which involves a comparison :-)
I suppose Tony's teacher would have wanted him to measure out a mole of
sugar by counting the number of molecules of sugar...
/Jonas
> >
> > I don't have one of these installed, as I have no base:
> > http://www.pdp8.net/asr33/pics/old_rdr_power.shtml
> >
> > I believe that reader mod or no, I need to have power to the reader.
>
>Yes, you do.If you don't ahve the reader PSU connectoed, I think the
>reader trip coil will still work, the transmit clutch will engage and
>the distributor will spin, but the reader itself will do nothing.
>
>I've not looked at your pictures, do you have a free cable coming out of
>the Model 33 ending i na 15 pin socket to connect to the reader PSU?
I got a power supply, will send an update asap. Here's to wishful
thinking. I spent about 2 hours with a teletype technician
yesterday, went through the whole thing. I will plug the 15 pin
molex connector into the power supply for the reader, and the other
two leads into pins 4 and 6 of the pdp 11 cable.
Bill
If so, it's the first one I've heard of in a floppy drive, but anyway...
>> > It is indeed a rack-and-pinion positioner.
> That is unusual. I think it would be worth trying to restore this drive,
> if only to have a working example of such a mechanism
>
Good point. I don't think they are terribly rare, they probably turn up
on eBay every so often, and Atari 1040s aren't rare. OTOH they seem to
have used a variety of drives.
I shall see what I can do to get it working again.
>>> > > You would want som way to eliminate the backlash between the rack and the
>>> > > drive gear. One common way to do thsi is to make the gear in 2 'slices'.
>>> > > One is fixed to the spidnle, the other is free to move by a small angle,
>>> > > but there;s a bias spring forcing it in a particualr direciton relative
>>> > > to the spindle. The idea is that said spring is pre-tensioned when the
>>> > > mechnaism is assembled so that the teeth of the 2 gears are forces to
>>> > > commpletel fill the gaps between the teeth on the rack.
>> > I know what you mean. There is nothing like that here, everything is
>> > probably too small. The pinion is about 2 mm diameter and the teeth on
>> > the rack are something like 3 per mm...
> 3 teeth per mm? That's a very fine pitch.
>
> Thinking about it, 3.5" 80 cylinder drives have 135 tpi. So the track
> spacing is 1/135" or 0.19mm. The backlashj in the mechansim must be a lot
> less than that, I guess with a 0.3mm pitch rack you can get that.
>
3 per mm was a guess, but I can't see the teeth on the rack with my
naked eye (i.e. wearing reading glasses only). I need a magnitying glass
to see that there are teeth at all.
>>> > > What I would do next is with the drive removed, try carefully moving the
>>> > > head back and forth and/or rotatign the stepper motor spindle and see
>>> > > what moves. If something is stripped then moving the head will not
>>> > > rotrate the motore and vice versa. Of course you may find that something
>>> > > is jammed solid, in which cae that could be the problem.
>> > I removed the motor, it turns out the rack and the pinion is in good
> As soon as you remvoed tht motor, you lost the head alighment...
Any alignment must be totally lost by now. But if I do get it working I
can format a disk on it and see if that works. Reading and writing files
might be more of a problem, I can't remember if there is any way to
create directories and files in the bare OS, or if one needs programs
>from another disk, in which case I would be out of luck if it is so
badly misaligned that it can't read other disks.
>> > shape. What I was seeing was just a deposit of grease and/or gunk. The
>> > head assembly was locked solid. It runs on a steel rod approx. 2 mm
>> > diameter which goes through what looks like bushes, and it was
>> > completely jammed from lack of lubrication, dirt etc. The bad news is
>> > that now everything is out of alignment since the head assembly came
>> > loose when I was trying to move it (it was locked really, really solid),
> Provide the head is not damaged, I'd try cleaning it up, making it work
> freely again, and then see if you can get the drive working. Even with
> the radial alignment way off, the drive should be able to read its own
> disks (ones formated in that drive).
>
> As for doing the full alignment, there are various ways of getting it
> somehat near using a disk formatted on a known-good drive, but it's a lot
> easier with an alignment disk and 'scope.
>
If I get that far I shall have to try something. I have a 'scope but no
alignment disk.
>> > and I don't have an alignment disk. Still, it was a learning experience...
>> > I have ordered a new drive from a local shop, they don't keep them in
>> > stock. They are only 6 Euros so replacing it will be a lot less trouble
> Hmmm. I wonder if those cheap drives are ever aligned at the factory...
> I've seen new drives over here that are certainly marginal when checked
> against a good alignment disk.
>
I shall soon find out :-)
>> > than making it work again. I would have liked to fix it, but that is
>> > simply not practical, sadly.
> I'm not convinced it's impossible.
>
I didn't say "impossible" :-) I meant practical given my resources. But
then I may be underestimating myself. And I would of course have to be
committed to taking the time to make it work. OTOH, why not?
>> > Interestingly, Atari drives are sold for about $50 on eBay, with
>> > shipping to Sweden another $50. I suppose they are "collectable". That
>> > works out at about 10x the price of a new one. The difference is that
>> > the original drive is 720K and has a special bezel and eject knob, a new
>> > one is 1.44M and the bezel and knob can be transferred from the old one.
>> > The machine itself works with a 1.44M drive.
> Hmmm... I guess I am more of a purist, but I really don't like replacing
> modules (such as drives) in classic computers with random modern units.
> To me, the design of the drive is part of the design of the machine, and
> it should be preserved if at all possible.
>
Indeed. It would also guarantee compatibility with all the old game
disks I got with the machine :-) It is an interesting machine, I bought
one ages ago instead of a PC. It was faster than the equivalent "turbo"
PC, cheaper, the display was higher resolution and it also had very good
built-in MIDI support. I used mine a lot, not only for playing games,
but I also translated several books using it as a word processor, and
ran accounting software on it. I think I even designed a PCB on it.
There was a lot of good and really useful software for it, word
processors, early desktop publishing software that was better than the
PC software, CAD programs, and of course *lots* of music software.
Musicians used it a lot, and I knew a chap who used his to drive a very
big Roland plotter type machine that had knives instead of pens, to make
signs by cutting sheets of plastic film. And GEM was way ahead of DOS
and Windows at that time.
I could kick myself for getting rid of my first one... Well, at least I
have one again :-)
/Jonas
I know there's been discussion in the not too distant past about troubleshooting a Xerox Alto, but I just want to add a couple of words on the subject.
Ours went dead suddenly: it had been left running with the monitor turned off and, when I turned the monitor on, the cursor was on the screen in the upper left corner and was unresponsive. I rebooted with the button on the back of the keyboard and the screen went blank white. There didn't appear to be any response (seek behavior) from the disk (the Diablo 31 shakes things pretty well as it seeks). I shut down the machine and began to strategize.
First I wanted to be sure the basics were OK. I used a scope and DVM to check all the power supplies, both for voltage level and noise: good. I scoped the clocks: good. Damn, nothing easy.
I checked with the man who had sold us the machine (and who had originally restored it) to see if he had any advice on where to start. He wished me luck. :-) Since the Alto was a research platform, neither the documentation nor the engineering drawings were created with the idea of troubleshooting. I suspect the original Xerox repair strategy was, "Ask so-and-so at PARC."
I took a hard look at the disk subsystem, since according to the documentation (AltoSubsystems.pdf) the first thing the firmware does on reboot is load a sector from the disk. I scoped signals that go into and came out from the disk and saw that a key enable line from the Alto, *RDGATE, was not asserting. The documentation for the Diablo 31 was helpful here.
There were two possible reasons: it was not being 'told' to assert by the microcode, or there was a logic flaw along the combinatorial path. Recalling that the cursor was still being generated (a microcode task) when I turned off the machine, I initially figured the processor was OK. I traced through the disk controller's logic with the scope but found no smoking gun (or chip). So I reversed myself on the processor - time to get out the logic analyzer.
Now don't get me wrong, I love the logic analyzer (HP 1630G). It's a powerful tool, and it's geek fun to play with one. But it's also a pain to hook up all those little leads, especially if, like me, you have "mature eyes." Further, the Alto doesn't make it all that easy: there are no extension boards available for its 122-pin backplane. (I plan to make some.) Fortunately, many key signals are present on the backplane, and the disk interface card is in the bottom slot of the card cage with several empty slots above it. It was tight in there, but I managed to get DIP clips on ICs and hook up analyzer lines.
First I looked at the processor bus. In AltoSubsystems.pdf, it's documented that the microcode looks at the word coming from the keyboard to determine which disk sector to load (or whether to net-boot). At first, it looked like I had a stuck bit on the processor bus. Examining the drawings, I learned that the processor bus is a pretty conventional wire-OR design with termination on one end at the Memory Extension And Termination (MEAT) board, and on the other end on... the disk interface board! I verified the seating of pull-up and pull-down resistor packs in their sockets, tested some more - and ultimately figured out that one bit was bad on the analyzer pod! <sigh> Using a different pod, I was now seeing activity on all 16 lines (remember, bit 0 is MSB). I was able to capture the assertion of the keyboard word on the bus as well as the changing response with various key presses, giving me confidence that the microcode engine was running and sane. But *RDGATE still wasn't asserting. Damn, back into the disk board logic.
>From there it was a simple but tedious matter of tracing back from the disk interface toward where the microcode was consumed to drive the assertion of the control line. With the logic analyzer, I traced the failure to A41, a 74H11 AND gate that wasn't AND-ing (output stuck low). Problem solved.
So I think the takeaways are that it's important to know the processor is working, and looking for the appearance of the keyboard word address (177034 octal) on boot is one way to know that the firmware is being run. (The blank white screen is meaningless - the display controller H/V oscillators free-run until they're brought under control by the microcode.)
Also, nearly every signal line is a complex combination of both active logic driven by the microcode and "control" logic representing various inputs from hardware elements that run concurrently with but separately from the microcode engine. IMHO this makes it hard to find even moderately involved failures with a scope alone. The engineering drawings (AltoIIMaintSchem_1978.pdf, for our machine) document the combinatorial logic pretty well, but the alphabet soup of the signal names may take a bit of puzzling to decipher sometimes.
One critical set of signal lines is from the task priority encoder: unlike a modern system, the tasks are cooperative and are represented by signal lines that enable parts of the control logic. A particular value on e.g. the processor bus will "mean" something completely different depending on which task's signal line is asserted. The hardware manual (Alto_Hardware_Manual_May79.pdf) does contain a lot of information about this, but you need to read both the "Microprocessor" section and the "Control RAM, ROM, and S Registers" section to get the whole picture.
The documents I've cited are all available on (and were retrieved from) BitSavers - thanks, Al!
I hope my experience is helpful for someone out there.... -- Ian
UNIX is user friendly. It's just selective about who its friends are.
Ian S. King, Sr. Vintage Systems Engineer
Living Computer Museum
A project of Vulcan, Inc.
http://www.livingcomputermuseum.org
Does anyone know who has a good supply of 5.25" floppy drive cleaning
disks for sale?
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Well, a few more bizarre things to report:
I tried to disable interrupt sources as suggested. The only one, apparently, was the DL11-W SLU/LTC card which was set for both functions. The card was reconfigured to be "SLU Only". No change in behaviour. The DL11-W console is set for address 177560, vector 60.
Next, there are three memory cards: one M7847-DJ (16K*18 MOS, MS11-JP), one "Motorola memory systems" card with 48K words, and one "MOSTEK memory systems" card with 96K words. Both the two later cards use 4116 DRAM chips.
Tried to use the M7847-DJ card alone (after all, RT-11SJ should run on 16KW of memory). Reconfigured the card address to start at 0 and verified that it occupies addresses 000000 to 077777 via the front panel. When the machine it turned on, the display reads "054207" (this was not expected). Tried booting using the bootstrap on the M9301-YB card: the heads don't engage at all and the program halts rapidly displaying "173764" ... BIZARRE since that is a non-existent address.
Next, tried the Motorola memory card which was already configured to start at 0. When the CPU is powered-on, displays "000002" on the display. Tried to boot the disk, heads engage, a few steps of the disk heads, and halts again at "005134".
Finally, tried the MOSTEK memory card. Reconfigured to start at 0, and verified that addresses 000000 through 377777 are occupied by RAM. Powers up with a display of 000002 and halts at 005134 when a boot is attempted.
The system is now stripped during testing, consisting of the following:
Slot 1/2 = CPU, Slot 3=M7859 Panel interface and M9301-YB bootstrap/terminator, Slot 4=memory, slot 5&6&7 empty (with a grant continuity card in D), slot 8=M7856 SLU/LTC, slot 9=M9302 at the unibus end and M7846 RX-01 interface.
Originally, had three memory cards in slots 4&5&6.
Now I'm just puzzled.
Question: Should the unit power-up with "000002"?
As I was typing this, had a thought about slots: I recall reading something about not putting memory into slot 9. So, I moved the RX-01 controller to slot 6 (and moved the grant card in slot 9D). Now, when powered-up with the Motorola or Mostek memory cards, displays "000000" but otherwise no changes in booting behaviour. When the MS11-JP RAM was installed instead, displays "177777" once, "163776" the next time (when powered up), and still absolutely nothing when boot is attempted (i.e. no heads engaging at all).
Is there something about RT-11 5.04 that I am not aware-of? An it was suggested that there is a difference between the Unibus and Q-Bus boot ... any thoughts on that one?
I can't see memory being the issue anyway: sure, 16KW might be an issue (and that card might even be 'flaky'), but the other two cards are large enough.
I suppose I could try an older copy of RT-11 however 5.04 is the only one I currently have which also has DX.SYS and DU.SYS drivers (allowing me to make a bootable copy on my LSI-11 system which has an MSCP drive ... I believe previous versions of RT-11 lacked MSCP "DU" device support?).
Cheers! Mark
>>
>> Thanks for the suggestions so far. I tried a few things with the =
>> following to report:
>>
>> I verified the copy of RT-11 on RX-01 floppy. It boots fine on the LSI-11 =
>> system it was built on, tried "BOOT RT11SJ" as well as with the "/FOREIGN" =
>> option and it ran fine on that system (which has an M7946 controller). =
>> The drive is configured for RX-01 mode only (since these are the only =
>> controllers I have in both Q-Bus and Unibus flavour).
>>
>> Now, put that same drive on the 11/34 CPU with an M7846 card. Checked the =
>> CPU carefully: NPG jumpers are all intact on the backplane (CA1-CA2) and =
>> all unused slot D's have a grant continuity card. Just to ensure it works =
>> I reconfigured the console for 9600 baud (originally 300) and ran a simple =
>> "echo" program loaded at 001000 which runs fine (so it can store programs =
>> in memory and the execute them). The system has loads of memory - three =
>> cards with 16K, 48KW, and 96kW on them - so I did a quick check at =
>> locations 100000 and 700000 and memory is certainly there.
>Some random thoughts
>What devices do you have in the 11/34 system? An RX11, obviously. A
>DL11-something (but what?) for the console port. Anything else?
>Obviously the console and the RX11 must be at the right I/O addresses for
>the system to get as far as it has. What about the interrupt vector
>settings? Are those correct. Could it be falling over when it enables
>interrupts on some device, the interurpt comes along and the vector is
>not what's expected so it goes to thw wrong routine.
>You have an M9301 at the CPU end of the bus. What, if any, terminator do
>you have at the other end? Unibus (unlike Q-bus, normally) is terminated
>at both ends.
>Could it be a bad memory location? RT11SJ doesn't need much RAM to boot,
>so perhaps you could try yor memory boards one at a time, each one set to
>start at location 0, and see if that helps.
>-tony
Professor Mark Csele, P.Eng.
Niagara College, Canada
300 Woodlawn Rd., L-23
Welland, ON, L3C 7L3
(905) 735-2211 x.7629
E-Mail: mcsele at niagarac.on.ca
URL: http://technology.niagarac.on.ca/people/mcsele
Author of "Fundamentals of Light Sources and Lasers", Wiley, 2004
I know I have Quick Basic 3.n, and maybe even Quick C somewhere.
Quick C had become popular w/developers (not for primary use) long after M$ canned it. Not sure why, maybe they just liked the IDE. And liked using it for quick and dirty tasks.
I spied QB 4.5 on eBay, brand new (someone placed a bid, I won't at this juncture). Is there any big difference between early versions of QB or QC? Early version of Visual C++ for instance are doggish compared to later ones, but that's a different world.
What about other M$ products, like Professional Basic (as compared to QB)?
Any Borland/Turbo fans still out there?
Already straying offtopic, a book I own states that Delphi could be used to write Visual Basic, but not the other way around. I'll assume Quick C could be used to write Quick Basic, but what about the other way around?
The MS11-JP has only five DIP switches which set the starting address ... nothing about parity in the manual I pulled from bitsavers. I believe the parity control card is just an option, but not required (this machine was used for years with three memory cards but never a parity card: it had three RK-05's and ran RT-11).
There is an M9302 terminator in slot 9AB (end of the run). Originally the 9302 was in an RK-05 controller backplane on the system (removed that, so slot 9 is now the end).
Professor Mark Csele, P.Eng.
Niagara College, Canada
300 Woodlawn Rd., L-23
Welland, ON, L3C 7L3
(905) 735-2211 x.7629
E-Mail: mcsele at niagarac.on.ca
URL: http://technology.niagarac.on.ca/people/mcsele
Author of "Fundamentals of Light Sources and Lasers", Wiley, 2004
>>> Paul Anderson <useddec at gmail.com> 04/19/11 3:02 PM >>>
Hi Mark,
I don't remember what the difference would be, but I seem to recall
the MS11-JP might have a parity enable/disable switch on it. The
parity control card is seperate, and you did not mention it. Also, do
you have a M9302 terminator?
Good Luck, Paul
On Mon, Apr 18, 2011 at 7:44 PM, Mark Csele <mcsele at niagaracollege.ca> wrote:
> Well, a few more bizarre things to report:
>
> I tried to disable interrupt sources as suggested. The only one, apparently, was the DL11-W SLU/LTC card which was set for both functions. The card was reconfigured to be "SLU Only". No change in behaviour. The DL11-W console is set for address 177560, vector 60.
>
> Next, there are three memory cards: one M7847-DJ (16K*18 MOS, MS11-JP), one "Motorola memory systems" card with 48K words, and one "MOSTEK memory systems" card with 96K words. Both the two later cards use 4116 DRAM chips.
>
> Tried to use the M7847-DJ card alone (after all, RT-11SJ should run on 16KW of memory). Reconfigured the card address to start at 0 and verified that it occupies addresses 000000 to 077777 via the front panel. When the machine it turned on, the display reads "054207" (this was not expected). Tried booting using the bootstrap on the M9301-YB card: the heads don't engage at all and the program halts rapidly displaying "173764" ... BIZARRE since that is a non-existent address.
>
> Next, tried the Motorola memory card which was already configured to start at 0. When the CPU is powered-on, displays "000002" on the display. Tried to boot the disk, heads engage, a few steps of the disk heads, and halts again at "005134".
>
> Finally, tried the MOSTEK memory card. Reconfigured to start at 0, and verified that addresses 000000 through 377777 are occupied by RAM. Powers up with a display of 000002 and halts at 005134 when a boot is attempted.
>
> The system is now stripped during testing, consisting of the following:
> Slot 1/2 = CPU, Slot 3=M7859 Panel interface and M9301-YB bootstrap/terminator, Slot 4=memory, slot 5&6&7 empty (with a grant continuity card in D), slot 8=M7856 SLU/LTC, slot 9=M9302 at the unibus end and M7846 RX-01 interface.
>
> Originally, had three memory cards in slots 4&5&6.
>
> Now I'm just puzzled.
>
> Question: Should the unit power-up with "000002"?
>
> As I was typing this, had a thought about slots: I recall reading something about not putting memory into slot 9. So, I moved the RX-01 controller to slot 6 (and moved the grant card in slot 9D). Now, when powered-up with the Motorola or Mostek memory cards, displays "000000" but otherwise no changes in booting behaviour. When the MS11-JP RAM was installed instead, displays "177777" once, "163776" the next time (when powered up), and still absolutely nothing when boot is attempted (i.e. no heads engaging at all).
>
> Is there something about RT-11 5.04 that I am not aware-of? An it was suggested that there is a difference between the Unibus and Q-Bus boot ... any thoughts on that one?
>
> I can't see memory being the issue anyway: sure, 16KW might be an issue (and that card might even be 'flaky'), but the other two cards are large enough.
>
> I suppose I could try an older copy of RT-11 however 5.04 is the only one I currently have which also has DX.SYS and DU.SYS drivers (allowing me to make a bootable copy on my LSI-11 system which has an MSCP drive ... I believe previous versions of RT-11 lacked MSCP "DU" device support?).
>
> Cheers! Mark
>
>>>
>>> Thanks for the suggestions so far. I tried a few things with the =
>>> following to report:
>>>
>>> I verified the copy of RT-11 on RX-01 floppy. It boots fine on the LSI-11 =
>>> system it was built on, tried "BOOT RT11SJ" as well as with the "/FOREIGN" =
>>> option and it ran fine on that system (which has an M7946 controller). =
>>> The drive is configured for RX-01 mode only (since these are the only =
>>> controllers I have in both Q-Bus and Unibus flavour).
>>>
>>> Now, put that same drive on the 11/34 CPU with an M7846 card. Checked the =
>>> CPU carefully: NPG jumpers are all intact on the backplane (CA1-CA2) and =
>>> all unused slot D's have a grant continuity card. Just to ensure it works =
>>> I reconfigured the console for 9600 baud (originally 300) and ran a simple =
>>> "echo" program loaded at 001000 which runs fine (so it can store programs =
>>> in memory and the execute them). The system has loads of memory - three =
>>> cards with 16K, 48KW, and 96kW on them - so I did a quick check at =
>>> locations 100000 and 700000 and memory is certainly there.
>
>>Some random thoughts
>
>>What devices do you have in the 11/34 system? An RX11, obviously. A
>>DL11-something (but what?) for the console port. Anything else?
>
>>Obviously the console and the RX11 must be at the right I/O addresses for
>>the system to get as far as it has. What about the interrupt vector
>>settings? Are those correct. Could it be falling over when it enables
>>interrupts on some device, the interurpt comes along and the vector is
>>not what's expected so it goes to thw wrong routine.
>
>>You have an M9301 at the CPU end of the bus. What, if any, terminator do
>>you have at the other end? Unibus (unlike Q-bus, normally) is terminated
>>at both ends.
>
>>Could it be a bad memory location? RT11SJ doesn't need much RAM to boot,
>>so perhaps you could try yor memory boards one at a time, each one set to
>>start at location 0, and see if that helps.
>
>>-tony
>
>
> Professor Mark Csele, P.Eng.
> Niagara College, Canada
> 300 Woodlawn Rd., L-23
> Welland, ON, L3C 7L3
>
> (905) 735-2211 x.7629
> E-Mail: mcsele at niagarac.on.ca
> URL: http://technology.niagarac.on.ca/people/mcsele
> Author of "Fundamentals of Light Sources and Lasers", Wiley, 2004
>
