Home Page Forums MAME MAME Tektronix 2465 oscilloscope emulator

The venerable 2465 oscilloscope is widely (by me) regarded the best portable oscilloscope of all time. Between the service manual and the TEK-MADE INTEGRATED CIRCUITS Catalog, almost all the hardware is documented. Out of a desire to understand the firmware in this scope, I initially wrote a 6800 processor spec for Ghidra, but after futzing around with decompiling a bit, I realized that it'd be much less boring^W^Wmore interesting to see the code executing.
Ultimately I'd also like to look at the firmware for the 2467/2465A/B, as well as for various options, all of which have elaborate memory banking arrangments.

So, I've been slowly futzing around with a MAME emulator for the scope.
To this point there's enough hardware emulated to:

• allow it to display the on-screen display,
• pass the power-on self tests up to the 05 tests (given a good EAROM image),
• interact with buttons & the calibration jumper as well the time/div and sec/div dials with the mouse and/or keyboard,
• digitize the various pots and sensor voltages in the scope.

It seems all the custom Tek hybrids have shift registers to control the hardware, and I'm currently working through those to implement at least the capture of the data. It's been quite rewarding to see how the data seems to line up with the specs in the TEK-MADE catalog when I manipulate the front panel controls .
I'm particularly interested in understanding what's happening when the built-in calibration routines run, which will require capturing all the state and emulating at least the trigger hybrids to some level.

In the limit, it might be possible to emulate this down to the capture and display of input waveforms, whether emulated or e.g. from a sound card.

Here's a short video of what the emulation looks like as of a few days ago:
[video:youtube][/video]

At this point I could use some help and/or guidance in how to present and better enable interaction with the dials and pots.

The dials are backed by multi-position gray code switches, which I've implemented with a remapping table. The presentation is currently done by an inline SVG image for each state. This works OK so long as I only use the mapped keys to adjust the dials. However, if I click them, they seem to go for a one way trip into an impossible state.
As a further complication, the A/B sweep dials have some mechanical interlocks, with a switch when the B-sweep dial is pulled out of the interlock.

How to present the pots is also a bit of a conundrum to me. There's a lot of them, plus one or two of those pots are connected 90 or 180 degrees out of phase to the same shaft, which rotates freely, effectively allowing usage similar to modern day quadrature encoders by digitizing the position of both pots.

So, any ideas on how best to do this? I'm a MAME n00b, so don't assume I know or understand the obvious . Ideas or pointers to code that do similar things would be most appreciated. Even displaying interactive sliders for the pots would be nice at this point, though displaying them interactively in-place would be ideal.

So finally someone researches what the software inside a "real" oscilloscope does.

In 2020 someone had reverse-engineered a very cheap chinese tablet scope by FNIRSI, wrote own firmware and somehow gave up with fixing its (FPGA?) flaws. Apparently the Fnirsi 1013D contained very strange code (processing of each frequency looks like written by different people?) and was more an imposter than a scientific instrument by only guessing the waveforms at higher frequencies to camouflage the noise of the unshielded analogue parts and possibly faulty FPGA implementation.

https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/

=CO=Windler, what does ANY of that word salad have to do with Tektronix? You need to stop spamming people with irrelevant dross.

These are very different kinds of scopes. The FNIRSI is a modern digital capture scope.
The Tek 2465, on the other hand, is an analog scope, albeit one that's largely "drive by wire". All the little analogues are controlled by a 6800 MPU, a 12 bit DAC with a bunch of sample-and-holds, plus a bunch of custom logic (ASICs in todays terminology, I'd think) in the Tek hybrids.

At a first quick glance, the firmware in the 2465 is ... interesting ... Of course I've never (yet) tried to code in 6800 assembly, so some of this might be due to the quirks of the instruction set.
It seems most of the subroutines take arguments in globals(!!!) and may return more than one result, sometimes in registers, but most often in globals.
I remember tripping over an Add16(X, A) subroutine that returns both the 16 bit sum in X, as well as the 8 bit sum in A or B - I forget. The sum is done by stashing X to a global and adding to it there. Of course to do this safely the subroutine has to save the interrupt flag, disable interrupts, and then restore the flag while all this is going on.
It's ... entertaining ... to read.

A 1984 design is probably not ASICs. It's more likely the custom logic is a lot of 74-series gates strung together, and possibly a few PALs.

ETA: but there's something going on under all of the big bolted-down heatsinks on the main board that could be early ASICs. So you never know I guess, especially with Tek.

By the way, hey, Siggi - sorry for any confusion, I go under a bunch of different nicknames depending on the site. I'm the guy who was giving feedback on your initial commits over on your repo.

Sorry again for the confusion about bracing, you really should use whatever is most comfortable for you if it comes down to a choice between Allman, K&R, and 1TBS.

Can you give more quantifiable info on this bit?


I'm not familiar enough with the artwork system to be able to help, but having more data could help someone like Vas Crabb provide insight.

I don't think concepts like inputs being coupled together - either how the A/B sweep dials are coupled, or by having dials coupled phase-relative to each other - is a situation anyone's ever had to deal with in MAME, so for better or for worse, you're breaking new ground here. That's a good thing.

My immediate thought would be to use some sort of Lua script embedded in the layout file (I know there are examples of this, but I don't recall any immediately), but I don't think that'll get you very far. As I understand it, Lua script can't force values onto an input port, and that's exactly what would be necessary in this case.

I really think Vas needs to speak up on this one, because it involves the precise intersection of areas where he's the expert: Artwork, and inputs.

Siggi: sorry, clickable artwork and analog I/O port fields don’t mix well at the moment. You can kind of work around it with dummy ports and scripting tricks, but it’s ugly. Once I get to another checkpoint with the current input system refactoring I'm working on I’ll try to give you a hand.

At the time Tek was in the business of making custom silicon and I've been able to track down first-hand documentation for all the digitally controlled hybrids save for the preamps. See the TEK MADE IC Catalog (there's another version on archive.org that's OCRed with clickable hyperlinks). The display sequencer, the sweep hybrid(s) and the trigger hybrid are all documented in that catalog. The display sequencer is a very specific state machine that orchestrates which sweeps are displayed in which order, and whether by trigger or delay.
I've tried to leave a trail of breadcrumbs for the dies inside the hybrids.
I seem to remember the channel switch, as well as the vertical output hybrid also make an appearance in the catalog - perhaps others. Of course the pure analog hybrids aren't too interesting for the emulator at this point in time.

Thanks, I'm not in a great hurry with the UI, but it would be nice to be able to jiggle the pot values, presentation be damned. Is there a good way for me to throw up a bunch of sliders to allow me to manipulate a bunch of port values?
I can plumb things up to the analog muxes from there...

I took another quick look at the 6800 instruction set. It's pretty ... limiting ... in that it looks like there's no good way to push the X register, nor is there any way to load or store X to/from A or B, except through memory. The only register stores to from X are to/from S, the stack pointer.