Roy J. Tellason wrote: The ads list a 12au7 for about 65 cents in 1955. In 2006 a generic 12au7 is about $8.00. I suspect a better deal now than 50 years ago.

From: "Ethan Dicks" <ethan.dicks at gmail.com> Thyratron divider circuits. http://www.g1jbg.co.uk/thyratro.htm Divide by any integer, using around 6 components (the practical division limit is around 6, but I've made them work as a divide by ten). Jim.

Michael Holley wrote: Interesting, that's essentially a copy (minor circuit diffs) of the HP AC-4A decade counter module, down to the pinout of the octal plug. Northeastern Eng. also made them and the ones by Beckman are similar?identical. I've been trying to figure out who actually made them first (I suspect HP). http://www.nixiebunny.com/hpac4/index.html http://www.cs.ubc.ca/~hilpert/e/edte/HP520.html#AC4 Ethan Dicks wrote: The electronic technique in the day would have been to use the phantastron circuit. Division up to a factor of 10 for a known fixed input frequency required only one active device and one diode. An RC delay was used to inhibit input triggers for a period of time between n-1 and n cycles, so that only the n'th input cycle would result in retriggerring. Division by 3600 could be accomplished with just 4 active devices. Same principle but a little simpler still in circuitry than the monostable technique mentioned by Allison. (The other technique likely to have been used in the day would have been a synchronous motor, gear reduction to 1RPM and an optical sensor.) Tube-digital clock projects: http://www.eldocountry.com/projects/tubeclock.html dekatron for power-line div-by-60. And http://www.selectric.org/tubeclock/ I was thinking of going for a new-old hybrid design where one stayed with a string of decade counter/displays and programmed a microcontroller as a TOD clock which then pumped the counter string at 1Hz or 1/60Hz, with bursts of fast pulses to invisibly jump over the 60 to 99 range. Any old frequency/event counter could be turned into a clock with no or minimal modification. With the micro continuously powered, one could power up/down the old power-hungry stuff without having to manually set the time on every occasion. I'd hazard a guess you won't be running this thing 24/7 at the South Pole unless the 'energy accountants' are willing to include it in the heating budget :)

woodelf wrote: Neat idea .. looked up the glow bulb logic manual and there is a circuit for a ring counter. Each stage requires 1 neon bulb, 1 diode, 1 resistor and 1 capacitor. So in theory one could build a 12-hour 6-digit digital clock (60Hz-line timebase) with 3*(10+6)+12=60 neon bulbs. Perhaps 61, using another bulb to square up the 60Hz line trigger. Might need amplifiers between digits. However, my understanding of neon logic is that it's great in theory, but not so much in practice. The characteristics between bulbs vary enough to make implementation awkward and the characteristics of the bulbs vary over time, leading to reliability problems. As the description of ring counters in the the manual says: "Lamps should be aged for best results and some selection may be desirable." There was a discussion about these issues for neon-lamp-memory on the list in May 2005.

Ethan Dicks wrote: With the comment about the south pole, on the heating budget for the clock, I found out for some reasion penguincentral.com is down. I was looking for SBC-1620 software and was hopeing to find more about the adventure port. Could a older Z-machine engine be ported to the loveable 8?

Gordon JC Pearce wrote: Oddly I think the world has more than ample simple PDP-8 emulators. SimH is the only one I trust to have most of the 'bugs' and 'un-documented' features of a real machine.

Gordon JC Pearce wrote: Hey I am trying to build real hardware here. This is about my 20'th revision here on quad paper since about 2002. Since I found where I can get proms burnt development is moving faster for 2901/rom based computer. What I am trying to do is squeeze it all into 512 words of control rom for the cpu & front panel.

On 9/3/06, Gordon JC Pearce <gordon at gjcp.net> wrote: Yes. My hosting provider of 10 years, Colossus, vanished without a trace about a week ago. I'm still working on options to bring it back up. I only have a couple of photos of my SBC-6120, and as for software that runs on the Z-machine, I had a couple of tutorials, and my port of Zork, not Adventure. Can? I think so, with some possible pitfalls. In principle, I don't see how implementing a v3 Z-machine (128Kbyte max game file) is beyond the capabilities of a PDP-8. I do think that unless one were to require a KT8A and at least 64K words (out of a max possible 128K words), a v5 Z-machine is out of the question (ZDungeon is a z5 file, FWIW). The smallest machine I am aware of with a v5 Z-machine is the Commodore 64. There are several implementations of a v3 Z-machine on 8-bit machines with 32K-48K (Apple II+, TRS-80, and recently, the Elf 2000 (1802 w/32K RAM and ElfOS). The fundamental limitation is available RAM after storing the Z-machine (4Kbytes to 8Kbytes in machine code) and the "impure storage". On small machines, Infocom and others implemented a demand-paged virtual memory scheme for the bulk of the game - all the code fragments and text fragments are swapped in as needed. The variables and objects are dynamic, so they were loaded from disk once then held in memory throughout play. When saving the game, all the Z-machine has to do is write out the impure area to disk. While helping Mike Riley (author of ElfOS) debug "ZRUN". we discovered that with a v3 game and a 32Kbyte machine, after you subtract a few K for resident OS overhead and a few more K for the Z-machine, and many K for impure storage, there was on the order of 2K free for swapping out the fixed bits of the game. With 512 bytes per disk block, that worked out to, I think, 3 game pages at a time. There was _not_ enough free RAM to hold the larger impure storage area of a v5 game, so we came up with a banked memory expansion scheme (to 512Kb with one SRAM chip) that would allow it, but it's obviously not a popular enough design to catch on to a wide enough audience to make the effort of writing a v5 Z-machine more than a personal vanity. If one were to implement a true VM scheme where both pure and impure pages could be read and/or written, then 32K is no longer the boundary it once was, but performance would suffer terribly. Back in the day, on a C-64, it was many seconds between typing a command and getting a response. On machines with a faster disk implementation, the Apple II+, say, it was still a few seconds between prompts. If one were to add in the necessity to write and keep track of impure pages as well, it would be a long wait. Infocom abandoned machines as "small" as the C-64 for later games in favor of the larger and newer machines of the day (Amiga, Mac, PC). An easy choice, in part, because these larger machines could hold an entire 256K max game file in memory, simplifying the internals of the Z-machine and leading to greatly improved performance. As for a v3 Z-machine (that could run the Zork trilogy, Planetfall, Starcross, and many other titles), the hardest thing I can envision would be the constant battle of trying to implement a 16-bit virtual machine on a 12-bit real machine. The pointers in the game code to text and code fragments are 16-bits (that are then extended to 17-bits inside the Z-machine to find the "real" location in the file) and the 256 variables are 16-bit, so you'd have to deal with a lot of 24-bit items to keep track of the elements of the game. Not impossible, but does take a bit of code to do it. The actual opcodes themselves are quite straight foward, even if they typically operate on 16-bit quantities. There are other examples (like dealing with object properties), that make one decide between storage efficiency and code efficiency (v3 objects are 32 settable attribute bits plus three bytes for parent/sibling/child entries, plus variable amounts of "properties", on the order of a few bytes each) - all very 8-bit-multiple-centric. I'd recommend going with an established (and debugged) emulator. If there's something that simh won't do for you, that's another matter, but it does run OS/8 very well. Well... up to 32Kwords that's fine, but above that, you have to implement the KT8A memory management board that allows up to 128Kwords. More than a simple #define. -ethan

Stan Barr wrote: Note that for flip-flops one should 'properly' be using types such as 5963 or 6211 ("computer tubes") to avoid the cathode emission problems which results it was the one at cut-off). (Perhaps not a problem for a clock, I don't how extreme the asymmetry had to be before the problem showed up.)

Roy J. Tellason wrote: Well if it's the "Marshall sound" it should be ECC83s and EL34s, not this American stuff. Gordon (drifting offtopic, sorry Jay)

Hi, Gordon JC Pearce said: Or in my case 7025, 12AT7 and 6L6 - Fender Twin... Getting back to the topic, I've run 12AX7s on 12.6 volt anode supply which eases power supply requirements at the expense of gain, but I've not tried that with digital circuits, perhaps an experimental flip-flop is in order. -- Cheers, Stan Barr stanb at dial.pipex.com The future was never like this!

Gordon JC Pearce <gordon at gjcp.net> wrote: Just as a benchmark, if you're buying random new-old-stock (still new in boxes) tubes in quantity, do not expect to pay more than a few pennies per tube (and even then that might be too much!) Random used tubes should be available for free. All those tubes are way above the random price guides I attempt to categorize above, and you can easily hit many tens of dollars or sometimes hundreds of dollars each, with extremely wide variance on brand and subdetails of construction. Tim.