Fred Cisin wrote: Even more interesting is to see all the races/hazards in the implementation -- and applications. I.e. if you can click on "Exit" and have enough time to move your mouse to click on something else, like "Edit | Preferences" and then watch the confusion that often results... Ooops!

On Sun, 6 Aug 2006, Tony Duell wrote: I'm trying to figure out how to make pneumatic (NOT hydraulic) gates. Once I can build a half adder and full adder with compressed smoke (no mirrors), THEN I'll be ready to start really learning how digital electronics works. yes, INDEED! -- Grumpy Ol' Fred cisin at xenosoft.com

On Sunday 06 August 2006 07:43 pm, Chuck Guzis wrote: Isn't that how an automatic transmission is supposed to work? Although they apparently have electronics in the newer ones... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

YEs. I have several workshop manuals that cover the Borg-Warner 35 transmission (this was the common automatic transmission used on UK cars in the 1970s). It really is a clever design. The hydraulic pump, driven by the engine, is not just used to provide the pressure to operate the clutches and brake bands, said pressure is also used to move valves against spring pressure. The faster the engine turns, the more pressure you get from the pump, and at a certain point the valbe moves far enough to select some other function. The better manuals explain exactly what happens for each gear shift... Alas yes. My father has just got a new car with electronics everywhere :-(. There's a control unit for the (automatic) gearbox. According to the workshop manual, there are 6 solenoid valves inside the gearbox, and also a manual slide valve coupled to the selector lever. Alas it doesn't explain what the latter does (if it fails you change the whole valve block), it doesn't explain what each of the solenoids does (it does give the dC resistances and the pins on the conector that each solenoid is linked to so you can find a defective solenoid) Oh well. I don't suppose I'll ever have to get amongst this, but it would be interesting to know what's going on. -tony

Ouch!. Is it fuel-injected? If so, often the same sensors (and control unit, at least in part) are used to trigger both the injectors and the ignition coils (most modern engines don't have an HT distributor, they either have a coil per spark plug, or a coil for every pair of plugs with a wasted spark on a plug in a cylinder that's at the top of the exhaust stroke, if you see what I mean). Do you have any docs at all? The workshop manual shold at least give pinouts of the control modules, from which you can deduce the signals, etc. Yep, different manufacturers used different terms. Ouch!. My guess is that you have a major mechancial problem with the transmission (burnt clutch plates?), and that the electronics might well be fine. At least the manual for our car does document taking the mechancial side of the transmission apart, right down to clutch plates and thrust washers, etc. I don't fancy doing it, but I would if necessary. -tony

It apperas UK and US vehicles are very different, then. Some UK cars still have the distributor cap and rotor arm, often mounted on one end of the camshaft (OHC engine). And a mormal ignition coil. Others have a coil-per-plug or whatevr and no distributor. There's normally a timing sensor on the crankshaft. Often a toothed ring on the crankshaft (or round the flywheel, or...) which causes the sensor to otuput a pulse for every 10 degrees of rotation. The teeth at TDC for each cylinder (that's 2 teeth, 180 degrees apart on a 4 cylinder engine, which most are in the UK) are missing to give a timing reference. The electronic block detects the pulses, interpolates to get the right ignition point, and sends a pulse to the coil I am not sure what the first UK car to do it this way was. Certainly the Austin Montego we had some 20 years ago was like that. Can you not get the factory manual (be warned, it'll be expensive, but IMHO worth it). I've never had any use for the 3rd party manuals. If it were mine, I'd find some way to get the transmission out (which is a pain if it's rear wheel drive, agreed), and strip it down myself. It's not _that_ complicated after all... I've removed sevaeral (manual) gearboxes to replace the clutch, etc. Not an easy job, but not hard either. So far I've never had to strip one down, but you know me. I don't replace entire modules in classic computers if they can be repaired, and the same applies to a car. If the transmission ever fails, you can bet I'll be taking it to bits. -tony

I do not think that is the reason. The engineering process for mainframe computers is far more disciplined, in keeping with the RAS philosophy. Sell one or sell a million - mainframe customers have very strict demands for their systems, and the engineers must adhere. -- Will

On Thu, 10 Aug 2006, Jules Richardson wrote: A reasonable assumption. BUT,... by that logic, Windoze is bug-free?? as author of a 3rd party manual, . . . The OEM factory service manuals are absolutely essential as reference materials for professionals. OTOH, if somebody needs to be instructed how to do the work, then a 3rd party manual is also needed, since a good factory service manual assumes a professional level of competence. -- Grumpy Ol' Fred (NIASE cert) cisin at xenosoft.com

On Wednesday 09 August 2006 06:25 pm, Tony Duell wrote: <...> Can't afford to pursue that at this point in time... I'm really not sure that's a job I'd want to tackle. My way of dealing with that is going to be either get it repaired somewhere or get another one and swap it out. If I can find one. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Incidentally, if you've just reassembled some complex mechanical device, like an ASR33, _ALWAYS_ turn it over by hand before powering up the motor. It's better to detect you've got something out of adjustment that will jam the mechanism when _you're_ turning it than to have the motor strip some gear teeth or worse. (And yes, I will admit I learnt that the hard way!) -tony

Tony Duell wrote: Yeah, CPU's are really very simple. Here's my half drunken rant about them. Skip this if you know how CPU's work. :-) Basically, CPU's fetch opcodes (instructions) and data, then decode said instruction, execute them, and increment their Program Counter register (or change it to a new value), and repeat. The ones with microcode (or RISC) are easiest to understand, although you don't get to see the microcode. They all are pretty much similar in that they have a register called PC (or IR) that point to the currently executing opcode. RISC ones and microcoded ones use the bits in the opcode to turn on circuits that do what the opcode says. With some CPU's you can almost "see" the circuitry that does this by looking at the opcode tables. Granted, they can be complex if you're dealing with x86, but even so, if you were able to see what the x86 ones really do underneath the the layer that's masked, each piece is simple. It's just that there are many, many, many pieces, which make for a complex device. The hard part of assembly language is that it's too simple: each opcode does something so tiny, that it's hard to see how to program in it. Once you figure this part out and get over it, it becomes easier. So you can imagine a very simple machine like this: A CPU is hooked up to a bunch of memory. The memory is addressable linearly (on most CPU's) and some of it is ROM because RAM loses it's data on power off. The CPU has a register called the Program Counter (or PC.) When you power this machine on, it sets the PC to a specific value, and starts executing code. The PC is usually automatically incremented (that is made to point to the next instruction each time, after it fetches an instruction.) CPU's have a bunch of other registers that they use to do work with. In CISC CPU's (complex instruction set computers) you see very few registers, which makes them inefficient. RISC CPU's (Reduced Instruction Set Computers) typically have very few instructions (except for PowerPC) and a lot of registers. Some do lots of fancy tricks with their registers (SPARC for instances uses register windows.) CISC CPU's normally don't execute the opcode they fetched directly. Instead, they have a built in ROM containing code called microcode. You can think of RISC chips as having the microcode as their native language (although this isn't exactly true, it's a good analogy.) Registers are simply set of flipflops (for example a 64 bit register has 64 flipflops - one per bit) that make up a single variable, and they're used for calculations, indexes, status, and so forth. To execute, it fetches a single instruction from memory, then does what that instruction says. Some CPU's use a fixed size opcode, this means that every instruction (opcode) is the same size. The opcode also contains information on what is being accessed: a source register and a destination register are typical, although some will have addressing modes, or memory addresses inside the opcode. The opcode and its operands (the information that says which registers to work on), are typically stored in special registers inside the CPU that aren't accessible. On microcoded CPU's there are also registers that point to the memory bus that say what address should be accessed. Typically the bits inside the instruction (microcode or RISC opcode) light up various circuits in the CPU. For example, an opcode that does an addition will turn on the circuits in the Arithmetic (and) Logical Unit that enable an ADD to occur, and they'll also load the two inputs and one output register. In a lot of CPU's the output register is one of the inputs. Other instructions can light up the barrel shifter, which can do bit rotates, or shifts in either directions. Other instructions can light up circuits that fetch or store data from memory, or copy registers from each other and so forth, access the arithmetic & logical unit (ALU), or floating point unit (FPU), vector unit (AltiVec for example), etc. In more modern CPU's, you typically have multiple instructions in flight. This is because the fetch, decode, execute cycle (which can be split up into even finer stages) would only keep one circuit light up at one time. So in order to be more efficient, you can have one instruction in the fetch stage, another in the decode stage, and another in the execute stage. More modern CPU's have several FPU's, ALU's, vector units, and can issue several instructions at the same time to each if the compiler did a good job of scheduling them. Even more fun, CPU's are far far faster than the memory they're attached to because this memory is dynamic RAM which is cheaper, but slower. You could use static RAM or SRAM, but this is far more expensive. 99% of the time when the CPU reads from address X, it will read from X+1 next, then X+2, then X+3, and so forth. Because of this you can predict the next memory access, so you can actually use some SRAM to pre-fetch a lot of the memory. This is called caching, and it can get very complicated if you want it to be effective. Modern CPU's actually consist of two CPU cores. These typically share their cache, so that you don't have inconsistencies, but for multithreaded code, these run your programs a lot faster. If all you're going to run is one application at one time, you won't see a difference, but if you run multithreaded code, or many applications/services at once, you will notice the difference. The above is not all very exciting, since we need to add some way to interact with the machine, which means I/O. Some CPU's have special I/O opcodes, others use the memory bus to map I/O devices as if they were memory. Since computers are thousands to billions of times faster than humans, it doesn't make sense for them to waste their power checking to see whether the end user pressed a key. You could program them to periodically check to see if a key is pressed - that's called polled I/O, but it's very inefficient. Instead, I/O devices have a way to signal the CPU. These are called interrupts, and there's typically several of them - one per device, although in some systems, IRQ's (Interrupt ReQuests) are shared, and then the CPU has to poll all the devices tied to that IRQ number to figure out which one to deal with. IRQ's are just signals. Just like you, in real life have to stop what you're doing when the phone rings and answer it, or the door bell, or an alarm clock, the CPU does exactly this. It save it's state on the stack, handles whatever device needs to be dealt with and then reloads its state from the stack and resumes the job it was working on. IRQ's have priorities. For example, if the phone rings at the same time the smoke alarm goes off because you left something on the stove too long, you need to handle the stove before you deal with the phone. So does the CPU. Some devices are more critical than others in that they're time sensitive. So they have a higher priority than others. When the CPU is taking care of an important task, it can choose to ignore interrupts. This is sort of like you shutting off your phone and doing work. Of course, some interrupts are non-maskable interrupts (NMI's). For example - the smoke alarm. There are other things that happen inside a computer that can be optimized. For instance, say a network packet comes in. In that case, an interrupt is generated, but because the CPU can only deal with one unit at a time - typically a byte, or word, it has to sit there and grab 1540 bytes, one at a time off the I/O bus and copy it into memory. This is of course inefficient. So more advanced devices have something called Direct Memory Access. They can transfer their data to memory without bothering the CPU - until the transfer is done. I mentioned something called the stack. This is simply a bunch of memory that's accessed last-in-first-out or LIFO. There's a special register called the Stack Pointer or SP. The stack grows downwards. That is it starts at some high address, and as data is pushed onto the stack, the SP gets decremented by 4 on a 32 bit machine, or 8 on a 64 bit machine. When data is popped (aka pulled) from the stack, it gets incremented. When an interrupt is triggered, the current state is saved to the stack by pushing the critical registers to the stack. These are usually the status register, the PC, and perhaps other registers. When the Interrupt Service Routine (ISR) - which is a bit of code that's part of the operating system or part of that device drive is done, the state is restored by being popped off the stack The stack is also what allows you to have functions that call other functions. SPARC CPU's do wonderful things with their registers for function calls - they use a set of registers called register windows. Remember when earlier on, I said that access to memory is a lot slower than the CPU? SPARC's take advantage of this by rotating some of their registers. In one function a set of registers that are labeled as "out" are used as parameters to the next function call. When the function is called, these "out" registers become that called function's "in" registers. This prevents them from being written to the stack, and then pulled off the stack, thus speeding things up a lot. If you trace code with a debugger, you'll see that function calls are very expensive! When you have, say 2 CPU's in your machine, say each one running at 1GHz, you don't really get the equivalent of a 2GHz's CPU. It's more like a 1.5-1.8GHz machine. This is because the CPU's have to fight over the various busses (memory, I/O) to get access to resources, and some resources aren't safely able to be accessed by two CPU's at once, so semaphores - or locks are needed to prevent data corruption or cache coherency issues. Dual core CPU's sort of alleviate some, but not most of these issues, because they're at least able to share their caches. Since I've digressed to modern CPU's: So things like Intel chips (and AMD, and Transmeta chips) have to waste a lot of circuitry to deal with backwards compatibility to the 8080 CPU. Because of this, they tend to be a lot more inefficient than the competition, even though they're a lot more popular. Even with the introduction of 32 bit CPU's, Intel and their clones have a limited set of registers. Remember that access to a register is a lot faster than to memory! So the more registers that you have and can efficiently make use of, the faster your code runs. In order to battle this, Intel chips have to do some insane stuff like register aliasing, which basically knows that a register, say EAX in the pipeline will get reused elsewhere, so it can be assigned to one internal register, and that another later on in the pipeline where EAX is reused can be assigned to another internal register, and all that code can be executed at the same time. Transmeta did something more interesting. They actually had something like a 128 bit or 64 bit RISC CPU whose microcode was programmed to decode, and recompile intel code into an internal format that would run much faster - well, in theory anyway. This is exactly the same was as Java's modern JIT (Just in time compiler) JVM's work. They translate one set of instructions into another (hence the name TransMeta?) Because of the overhead in Intel chips for backwards compatibility, pure RISC chips such as SPARC, ARM, HP-PA are a lot faster, and run cooler. They don't need all the overhead of backwards compatibility. Intel tried to get away from this mess with Itanium, but it didn't work out too well since AMD extended the IA32 (Intel Architecture, 32 bit) instruction set to 64 bits and won some momentum, so they had to do the same. Sad that. I don't recall exactly, but I believe Itanium had elements from HPPA and register windows from SPARC. Not sure where the Very Large Instruction Word (VLIW) instruction set comes in to which chips, but this basically allows a CPU to execute multiple instructions at the same time by dispatching a bunch of instructions to many parts of the same chip. As an aside, I'd like to also mention AT&T's Hobbit CPU which was not quite a RISC and not quite a CISC, but had some interesting features. As far as I know the Hobbit was used in two machines: AT&T's EO which competed with and was killed by Apple's Newton, and the prototype BeBoxes. The Hobbit was designed to speed up C code. Instead of internal registers, it used part of its cache to store registers on the stack. That way your registers were offsets of the stack pointer, so your code ran faster. It's not considered a RISC chip because it didn't have a fixed size opcode, but it's certainly a weird and interesting little chip. Assembly and machine code aren't very difficult. They're actually quite simple. Too simple. Imagine that you tell your dog, "go fetch" and throw a bone across the back yard. From a high level language, you might have a library call that does this for you, or maybe you can code it yourself. From assembly, you have to instruct the dog (CPU) at each step. Instructions like, look ahead of you, do you see the ball? Is it infront of you, if so: Move your left front leg this way. Move your right front leg that way, else, look a little to the left, is the ball ahead of you, look a little more to the left, and so forth. Some CPU's are a pleasure to write in assembly for. These include the 6502's, the Motorla 68000, and SPARC's. Some are a horrible nightmare: the intel chip for example, and to a far far lesser degree, MIPS. It's all a matter of "taste" and experience. But if you want to code for Intel, I highly recommend that you don't look at 68000 code or SPARC code. Because once you see how easy those are when compared to Intel, you'll want to cry that you now have to code in Intel assembly. :-)

On Saturday 05 August 2006 22:14, Chuck Guzis wrote: I like that analogy... and in order to add on the rooms, they had to get rid of some of the more "interesting" parts of the original, like the "POP CS" instruction. Pat -- Purdue University ITAP/RCAC --- http://www.rcac.purdue.edu/ The Computer Refuge --- http://computer-refuge.org

On Saturday 05 August 2006 11:38 pm, Ethan Dicks wrote: It is *so* nice to find others that feel this way... :-) -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

woodelf wrote: Yes, that's the problem. What they tried to do is akin to taking a 2D being from flatland (limited to 64K) and placing it into a 3D world. To do this, they created multiple planes (segments). So you basically still have a 16 bit processor, but it can access a lot more memory - 1MB instead of 64KB. But it also gets expensive to do so. You now have to track the segment number for each 64K chunk of memory, and your data structures are limited to 64K, so your code suffers, or gets more complex. Worse yet, you're wasting a bunch of useful registers from being used as general purpose registers. So now you have a bunch of special registers just for segments. A far cleaner approach would be to use 32 bit registers to begin with. Then, you're not limited to 16 bit segments, nor do you have to worry about segments. See the 68000. Yes, being able to access 1MB is a huge increase over 64KB, but IBM decided to put ROM and Video I/O addresses right smack above 640KB, which made sense, this was 10x bigger than the current 64KB machines of the day, hence "640KB ought to be enough for anybody." But it turned out to be a problem after all, one that was solved in and old way - bank switching. This was driven by Lotus 123 mainly, which formed the LIM (Lotus, Intel, Microsoft) standard for extended memory. Ugly, but it worked for a little while. Of course, 386's came out, and guess what, we were still stuck with 640KB of memory, even though the 386 was a 32 bit processor. And even though Windows 3.1 had a win32s API, it was still painful to access memory properly - at least if you weren't using Windows NT or OS/2. And that 640K of RAM was a big problem too as you loaded more and more TSR's and device drivers in memory. Turns out there were some holes in the memory above 640KB so you could remap some of that for TSR's and device drivers, hence the LOADHI stuff. The fun part was getting "out of memory" errors even when your machine had 8MB of RAM. Over all, the "segmented" way of doing things turned out to an ugly nasty hack. It turned out, it wasn't so good for programming after all. Think about how many hours lots of people wasted on configuring their config.sys, configuring things like EMM386, and QEMM and so forth. Many countless hours, or human lifetimes even, wasted because of a very poor design decision - one that still affects modern machines to this day to some extent - at least at power on.

Roy J. Tellason wrote: Absolutely. The 68000 is an amazing little chip when you compare it to the 6800 and 6502's that it evolved itself from. You can sort of get a feel from this from this journal: http://linux.monroeccc.edu/~paulrsm/dg/dg.htm DTACK Grounded was a Journal that was pushing a plug in board to Commodore Pet's and Apple II's and possibly other 8 bit systems to enable a 68000 to run inside of them. The differences between the 68K and the host they live inside of are huge. It's worth a read to get a feel of the excitement the 68K caused back in the day when it was introduced. Some of it is very funny, there's one issue where the author compares an Intel FPU to the 68000 running software floating point routines, and guess what, the 68000 actually ran FASTER! :-)

On 8/6/2006 at 10:41 PM Ray Arachelian wrote: I never did benchmark the 68881. IIRC, the 68K was a big deal in the fab business. I think it used the then-very-new 3 micron technology. My biggest disappointment was that the CPU instructions weren't resumable after a fault--i.e. with those 24 bits of address, there was no possibility of virtual memory implementation. I did hear of a scheme for using two 68Ks, one running a half-clock ahead of the other to get around this, but that was prohibitively expensive. 16 MB sounded like a huge amount of memory back then. Cheers, Chuck

Chuck Guzis wrote: Fixed in the '010

And thusly were the wise words spake by Roy J. Tellason I remember the 68010 was all the rage for Amiga owners when it came out.. All you had to do was replace your 68000 and BAM! you got almost close to a 10% speed increase... :) Cheers, Bryan

Yes, it's been a while for me too, but AFAIR both the 68000 and 68010 can be obtained at higher speed ratings. My StarShip had a self-developed 68000 board, and I upgraded it to a 68010. Hardware-wise that is simple, as they are pin-compatible. Software-wise it depends what you are doing. In my case, I had a tiny operating system to schedule tasks, a time-wait queue, etc., it was trickier, because the *stack frame* that a 68000 and a 68010 push onto the hardware stack when an exception occurs is *different*. My OS used exceptions to return from user to supervisor mode (which is BTW the only method). But the 68010 was a little faster, especial in tiny (3 instruction IIRC) loops, which where "cached". I am not sure there where much extra fancy instructions as as soon after that upgrade got a 68020 (at 30 MHz) running, and that one had a few instructions that I really missed on the 68000. Yes, I am a "Moto-man", not an "Intel-chap" :-) - Henk, PA8PDP. _________________________________________________________________ Eindeloos zoeken naar dat ene document is nu voorbij! http://desktop.msn.nl

On 8/8/06, Bryan Pope <bpope at wordstock.com> wrote: More like 5%, but not bad for a (at the time) $20 chip. All you had to worry about was badly written software that tried to do its own MOVECC instructions instead of calling the OS (the Calculator app with AmigaDOS 1.1 was the classic test app). Of course, you could install a trap handler to "do the right thing", but an unpatched machine would Guru if your user-mode app tried to execute that instruction. Still a fun chip, and it did fix instruction restart issues related to trying to implement true virtual memory. -ethan

On 8/7/2006 at 12:37 PM Roy J. Tellason wrote: had I recall that before the IBM PC was released, there was a solid camp of speculators thinking that the PC was going to be 68K-based. After all, IBM had just released its lab computer--and it was 68K based. I remember the sense of letdown when the machine debuted. Cheers, Chuck

Tony Duell wrote: True, but you don't find CPU's made of discrete logic these days, so it makes it very difficult to get at the microcode. This is one machine I've been wishing for, for quite some time. Were there any emulators of these? Are there enough docs, schematics and copies of the software online somewhere? Would be sad to lose this machine to the ravages of time. Wow. You da man! ;-) I do recall that my college book on computer architectures actually went into this detail. I'll go and dig it up if I still have it if you'd like to know its title. Sweet! Reminds me of the Xerox Star where it uses an 8085 to load code into a custom made bit-sliced microcoded CPU, and even allows individual applications to roll their own microcode...

Tony Duell wrote: CPUs run on magic smoke. When something electrical happens that causes the CPU case to break, you can witness this magic smoke escape and the CPU sumallarly stops working. -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds