"Software-Defined Flyback" for Nixie Tubes

[Mac Doktor]

Includes video:

https://www.hackster.io/news/charles-lohr-turns-a-0-10-risc-v-microcontroller-into-a-software-defined-flyback-for-nixie-tubes-aabafa76aa78

Terry Bowman, KA4HJH
"The Mac Doctor"

https://www.astarcloseup.com

"It gets calls when nothing else works"—W. Eugene "Doc" Scott, PhD, explaining somewhat facetiously why a "TV preacher" was smoking a cigar. ('80s)

[gregebert]

I've never been comfortable with software doing really tight-timing loops, especially if you need timing resolution well-below 1usec. I'll definitely look into it more. My biggest concerns w/ software implementations are interrupts and precise knowledge of the execution time for each instruction. Things get tricky with branches, and downright non-deterministic with CPUs that do prefetching, branch-prediction, and caching.

I've used FPGAs for the timing-critical parts (20nsec cycle time), and software to tweak the hardware knobs. Nothing has gone up in smoke yet, but I have recorded some warm temperatures. Now that I'm wrapping-up the wooden case for my NIMO clock, I should know pretty soon if the HV supply will overheat without a fan. No worries....I have several thermal sensors in the case to make sure it doesn't get too warm.

The last time I did timing-critical software was for a floppy-disk controller over 40 years ago; the Z80 CPU running at 4Mhz had 16usec to read and store each byte as it came out of the controller chip and the loop typically took 12usec. 

[Terry Kennedy]

On Monday, May 8, 2023 at 6:14:50 PM UTC-4 gregebert wrote:

I've never been comfortable with software doing really tight-timing loops, especially if you need timing resolution well-below 1usec

 I had a clock from someone well-known here. It used a sw-controlled high voltage supply. Doing a firmware update smoked some of the components because it held the CPU in reset while uploading the firmware.

The last time I did timing-critical software was for a floppy-disk controller over 40 years ago; the Z80 CPU running at 4Mhz had 16usec to read and store each byte as it came out of the controller chip and the loop typically took 12usec. 

uPD765 and DMA controller - a winning combination. WD1771 and programmed IO, not so much. I built a commercial SCSI (actually SASI back then) interface out of some parallel ports. That was an interesting driver.

[Mac Doktor]

On May 8, 2023, at 6:14 PM, gregebert <greg...@hotmail.com> wrote:

The last time I did timing-critical software was for a floppy-disk controller over 40 years ago; the Z80 CPU running at 4Mhz had 16usec to read and store each byte as it came out of the controller chip and the loop typically took 12usec. 

Af friend of mine, one of the programmers working on The Oregon Trail, wrote entirely new software for the infamous Commodore floppy drive. I can't recall if it was just the RWTS or something approaching a full DOS. This was a tricky exercise because the drive had its own 6502 inside. Debugging it must have been interesting.

On May 8, 2023, at 6:38 PM, Terry Kennedy <terry-...@glaver.org> wrote:

I built a commercial SCSI (actually SASI back then) interface out of some parallel ports. That was an interesting driver. 

I recall reading on multiple occasions that a SCSI driver was a non-trivial exercise. Sort-of like "if you don't appreciate how non-trivial it is don't even bother".

Oh, the days of SCSI voodoo. When APS brought out their line of enclosures things suddenly became reliable. I have old drives, enclosures and cables all over the place. 

Terry Bowman, KA4HJH
"The Mac Doctor"

https://www.astarcloseup.com

"I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched c-beams glitter in the dark near Tannhäuser Gate. 

"All those moments will be lost in time like tears in the rain.

"Time to die"— Roy Batty, Blade Runner

[Terry Kennedy]

On Monday, May 8, 2023 at 6:56:33 PM UTC-4 Mac Doktor wrote:

I recall reading on multiple occasions that a SCSI driver was a non-trivial exercise. Sort-of like "if you don't appreciate how non-trivial it is don't even bother". 

Yup. It was bad enough when there was an actual controller chip, but at least the chip handled some of the handshaking internally. Doing it with parallel ports alone was *quite* exciting. Fortunately the original design only needed* to support the Xebec S1410 SASI/ST-506 bridge. Even that was fraught with peril - the SyQuest SQ306 drive used a servo "wedge", so an incautious format operation would destroy** the cartridge servo information and render the cartridge unusable. To make matters worse, the field test drives had matching cartridges - interchange between drives didn't yet work. Ah, the bad old days...

* Of course, right after release a customer showed up wanting to use a tape drive

** Xebec eventually released a new S1410 firmware EPROM that prevented this - if you happened to have a controller with that EPROM  (it wasn't the default)

My company had lots of experience with oddball storage - we had a Vertimag 5MB(ish) floppy disk prototype. And I was involved with the Evotek ET-5540 disk drive. That was "interesting", but that's a story for another time. We eventually went with CDC Wren drives. DEC (Evotek's other large OEM customer) had a bit more inertia and had to scramble for available drives - that's why the DEC RD52 might be a Quantum Q540 (more common) or an Atasi 3046 (rather rare).

[gregebert]

My take on this is if you need to cut costs, the 10-cent microcontroller is definitely the way to go. It's quite amazing how much compute capability this thing has for the price.

For me, though, I like having the ability to remotely login thru VNC using WiFi, use my favorite pile of free Linux tools, and code-up all sorts of diagnostic checks and error-logging. It's definitely more costly (Raspberry Pi Zero W is now 15 USD....if you can find any, plus the cost of the microSD card and cabling/connectors), but I dont have to worry about how many kBytes of code get generated, and there is a decent amount of RAM (at least 148Mbytes free on the system running my b7971 clock) . BTW, the 7971 clk code was written in C, takes 25KB for the executable, and uses 0.3% of the RAM. No worries about a "1202 Program Alarm".