How about a simulator for the rest of us Imlac-less folks? :-) -Chandra -----Original Message----- From: cctalk-admin(a)classiccmp.org [mailto:cctalk-admin@classiccmp.org] On Behalf Of Tom Uban Sent: Thursday, September 12, 2002 7:23 PM To: Bob Shannon Cc: cctalk(a)classiccmp.org Subject: Imlac assembler almost ready... Hi Bob, Your work prompted me to spend some time on an assembler for the Imlac and after a couple of nights of work on a brand new program, I can correctly assemble the simple display program. I will get you a copy once I clean up a couple of things. What kind of machine would you like to run it on? --tom

Bob Shannon wrote: do you know of any DOCS on the web for the hardware/software details?

No on-line docs, but I have full schematics for the PDS-1. Not easily scannable... But to turn this into a FPGA processor, a MAJOR redesign is needed. The current design is highly dependant on RC pulse shaping networks, one-shots, etc. The memory timing is very core-specific, and some modifications were needed for it to use modern semiconductor memory. So to implement this on a chip, a new CPU needs to be designed just about from the ground up, using modern design methods. About all you really need is the instruction set information, the original schematics are not much of a help here due to the design methods used by Imlac back in 1968 and 1969. Its really amazing to see how much engineers did not know back then. Its also amazing that the Imlac worked at all, given how it was implemented back then.

Ben Franchuk wrote: <snip> all they had to work Clearly you haven't looked at the Imlac schematics! Engineers designed lots of hardware of the same era without resorting to the kinds of tricks used in the Imlac. Did you know that each Imlac had to have RC networks that control its clocks and timing signals tuned by hand, for each unit? The components used were garden variety ceramic caps with very loose tolerances, not poly or other higher quality components. The issue here is the quality of hardware engineering. HP machines of the same period are vastly better engineered, as are many other machines from the late '60's and early 70's. To suggest that nothing better was available to the engineering team at Imlac is laughable at best. computer product.The real would be a problem could be used but then you unrefreshed data fade off The vector display has nothing to do with the design quality whatsoever! What makes you say something like this Ben? For what the Imlac did, when it did it, VECTOR was FAR SUPERIOR to raster displays. Please note, the Imlac had a 1024 by 1024 addressable display, prior to 1970. This greatly exceeds what was possible with raster graphics at the time, and the Imlac was designed for calligraphic applications where its short vectors made for a mugh higher quality display than a pixellated raster display of the same resolution would have. There is also the fact that manipulating raster display is far more computationally intensive than manipulating a vector display list. The Imlac CPU would not be well suited for raster graphics at all, but its more than sufficient for its intended use. The problems with the Imlac are issues of engineering quality, like the total lack of decoupling capacitors, poor grounding, and poor logic design. This is also reflected in the manufacturing of early units in the failue to wash the etchant off the boards (many Imlac boards now have fuzzy green etches, or no remaining etches at all) and poor metal preperation prior to painting, and the fact that the design was very quickly repackaged as the PDS-1D's. The CRT used in the Imlac was common enough in its day, and that same tube was also used in much higher quality products as well. The last comment about the display refesh is hard to understand. The Imlac does not use a storage tube, and it must keep the display refreshed in the same way as any raster graphics display does. I'm not at all sure I understand your point here, can you expand on this point? If your suggesting re-implementing the Imlac with a raster display, this is totally impractical. My ReImlac project will use a real vector display, as that is the only way to duplicate the capabilities of the original machine. Remember, the Imlac does not have jagged vectors even when drawing at any angle. To try to do this on a raster display would reqire a resolution far far greater than 1024 by 1024. The anti-alising along would take more logic than the full original machine does. On the other hand, a Wells Gardner vector monitor is more than able to display the vector video from an Imlac exactly the way a real Imlac does. So will most small oscilloscopes, or even a modified TV monitor. Small vector display monitors are fairly common on eBay at very affordable prices. So whats the problem with a vector display? To be true to the original, I'm sticking with a true vector display. After all, I'm quite addicted to vector (and point plot) displays, and this was my main attraction to the Imlac. If this were replaced by a raster display, you might as well run a software emulator and not bother re-implementing the Imlac in hardware at all. The vector display of the Imlac is a thing of beauty and is a huge part of what makes an Imlac so unique. To call this "...the real problem..." is heracy!

chip, things, in. The Earl "Madman" Muntz approach. Just because you think he knew how to build things didn't make that good engineering practice. You should have *more* bypass caps than you need under normal conditions, because there will be real-world conditions that don't match your lab bench. There are definitely ways to determine a reasonable minimum number of bypass capacitors as an engineering exercise, but this is MUCH more complicated than taking them out until the product breaks, and adding one back in. In particular, it's not just the total count of bypass capacitors that's important. They have to be in the right places. Just because they're conceptually all in parallel doesn't mean that they can be anywhere on the board. The power and ground traces (or planes) have resistance and inductance, which is part of the reason that you need bypass capacitors in the first place. So the bypass capacitors must be physically near the components that have large current fluctuations. "One per chip" or "one per two chips" are rules of thumb that can be used with some kinds of logic chips to get reasonably bypassing without having to do detailed analysis. Yes, you can get by with less, but not simply by randomly removing some and hoping for the best. How do I know this is a problem? From personal experience with two companies that left out bypass capacitors despite the objections of the hardware engineer, because it still seemed to work OK in the lab. In both cases, I had to debug the resulting problems, which were blamed on software. At first I believed it was the software, but eventually I discovered that adding the bypass capacitor back into the circuit fixed the problem. Once I'd finally proven this to management, it was ECO'd back in. In one case, a bunch of inventory had to be reworked (expensive!), and in the other case, the inventory was scrapped. But the worst part was the units already in the field. RMAs cost a *lot* of money. You can't determine how many bypass capacitors you need by looking at the power supply. deflected deflection money is That has *nothing* to do with using lots of RC delays in the design of the digital logic of a processor. I won't go so far as to say that doing so is always wrong, but you would need an awful lot of justification for doing it. From what I've seen, the Imlac was in fact poorly designed, just as others have asserted. They might have reduced their manufacturing cost, or they might not have. But they decreased the reliability of the machine considerably. Usually a tradeoff like that winds up being a false economy for the company -- penny wise, pound foolish. Eric

I marvel at how well the HP2644A I have is built. But really, did it have to be built so well that it would be working 27 years later, long after it was obsolete? The original purchaser paid for a lot more than they used. HP used to make the best stuff. But if they still made stuff that way, they would be out of business. Such is the world we live in.

On Friday, September 13, 2002, Bob Shannon wrote: I suggest you make it platform-independent (e.g. Java).

Rumor has it that Jeffrey Sharp may have mentioned these words: Why not make it a lot *more* platform independent... e.g. Perl. There's a version of Perl 4.0.36 that runs on Atari STs (not too badly, either...) kinda bringing this back ontopic... ;-)

Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger -- sysadmin, Iceberg Computers zmerch(a)30below.com What do you do when Life gives you lemons, and you don't *like* lemonade?????????????

On Monday, September 16, 2002, Tom Uban wrote: You know, you're right. There's no reason to use anything other than standard C and its library. It's a fancy assembler that needs anything more than that.

Huw Davies wrote: Or 16 bit code to a 32 bit machine.

The best way (besides good design) to cure that is to write and test your C code on two architectures that have little common ground. It's one of the reasons cited for porting Unix to the Interdata 8/32.

On Friday, September 13, 2002, Bob Shannon wrote: I suggest you make it platform-independent (e.g. Java).

On Mon, 16 Sep 2002, Jeffrey Sharp wrote: Want PORTABLE? FORTRAN. "FORTRAN is more portable than syphilis" -Dijkstra

On Tue, 17 Sep 2002, Carlos Murillo wrote: Something fried the disk controller. I did this to one of my SE/30s once by being cavalier about not shutting the machine off before connecting and disconnecting an external disk drive. I suppose it goes without saying that the floppy controller is not a standard part.

Well... it's standard to Apple... there's a chip on there marked "IWM" - Integrated Woz Machine. That's the "floppy controller",

though I'm not certain that 100% of the floppy functions are performed by that chip (thinking of the Amiga where it takes two or three chips to run the floppies - Paula, an 8520, and Gary (if present)). There might or might not be some control-line stuff and/or analog stuff external to the IWM.

AFAIK, it's the IWM that controls the data clocks and handles the number of sectors-per-track changes, among other functions.

On Mon, 16 Sep 2002, Jeffrey Sharp wrote: Personally, I would say if you don't want to use Java, at least write it so it's posix compliant, maybe so it'll compile just fine on *nix, and using cygwin if necessary on windows.