Catch and Halt Fire - Drama set in early days of personal computing

On 5/27/2014 2:27 PM, tom wrote: As little as I watched of the online preview, it is looks pretty much like an excuse to have angry young person rebel against sympathetic teacher. Won't know till I get a chance to watch more on an empty stomach, so I don't choke. Just that nonsense up front makes it nearly unwatchable for me, and I did not get far enough to deal with technical stuff, just a silly dialog over jargon. I might point out that a certain machine in the Revolution display when equipped with core memory, especially the 8K core type will catch fire with the following front panel microcode procedure. Panel Mode Select any register, R if you want to verify your instruction Enter Write half microinstruction (write full also works but slower) Reset Run. I will leave it up to the reader to figure out which system and the binary, just in case. The half cycle write on the system reads out the core contents and leaves the core all in one state, which can be assumed to be a logical 0xFF. This makes it handy to do a read - modify - write in just on full cycle timing access on the core from microcode. However continued reads half cycle would take place in just 3 of the normal 6 cycles required for a full cycle, so hammering at the faster rate would overheat and eventually burn up the load resistors on the memory board with the core location. The system in question on display has a processor my company made which can do the half cycle operation ,but is mos memory, and not subject to fire. I have had several old timers come up and do this on my demo systems, and I just let them do it (since I don't run core systems). I would be more impressed if they come up with such as 'DCS' or "Dispense Can of Soda' instructions. I don't know that normal microprogrammed machines would ever be susceptible to the above w/o a programming or microcode error. The system I'm referring to was meant to be a general purpose microprogrammable system by users. Jim