开云体育

Makes sense. They added the optocoupler later, it looks like.

It doesn't look like the 492 used the line trigger for power-good reset, at
least at first glance, so it sounds like the disconnected capacitor may have
been failing to suppress some noise that kept the controller from booting
properly.

-- john, KE5FX

Hi all,
I'm having an issue today with 'View/Reply online' (I'm not able to find the window to enter a message) and that's the reason for using 'Reply to group'.If Edward's 'Please explain more' request refers to my previous message 'Not clear about the role of DC502 here...' then Barry's first sentence of this topic should be re-read
RegardsT

The PSU hasn't been fully recapped although it the ESR was checked

Hi Menahem.

Before, it wouldn't turn on. The two 0.068?F's had exploded.

James.

And before the RIFA's were replaced, what was its condition?

Menahem

Please explain more.

On Tue, Mar 4, 2025 at 04:37 PM, Dave Brown wrote:

The museum is open to the public with no admission charge. We participate in
external STEM events for free. The museum relies 100% on volunteers,
donations, and eBay sales for its operation. These sales help keep the museum
open.

Hi Dave,
If you feel that this discussion is harmful to the Museum's revenue stream, then I will certainly "cease and desist". I'm just a hobbyist, and I don't want my interests and curiosities to harm a small business. The museum I work at ( ) struggles with funds of course also. We do charge admission, and have several paid staff in addition to a number of volunteers like me; but we also have over 50 acres of property and 8 or 9 buildings to maintain (one of which is on the CO Historic Register). We host multiple school group tours every week, host STEaM camps, etc. We think we are one of the very best museums of its kind anywhere.

Pete

Nothing shorted nor open on the A9 board

Thank you Craig. The museum is open to the public with no admission charge. We participate in external STEM events for free. The museum relies 100% on volunteers, donations, and eBay sales for its operation. These sales help keep the museum open. If you haven't noticed lately, a lot of museums have folded.

On Tue, Mar 4, 2025 at 03:23 PM, Brian Cockburn wrote:

Open sourcing would be nice, but I would guess that the museum see this as a
(small) revenue generator. Although, an open source set of instructions could
include a request for a donation.

My understanding is that the fellow that wrote the code for the VintageTEK design passed away (per a note from Tom Fang). And I inferred (but could be wrong!) that the source code is lost/missing, so making changes would require a re-write.
Please correct me if these things are not true.

Meanwhile, I want to re-iterate that I won't be selling anything, and I have no interest in "reverse-engineering" someone else's design. If my project (basically just FW/SW) seems useful to someone, I will share it. If a non-profit (such as VintageTEK) feels that sharing my code is a bad thing for them, then we can talk about that... I volunteer at a local Museum every week, so I fully understand the issues.

Pete

Open sourcing would be nice, but I would guess that the museum see this as a (small) revenue generator. Although, an open source set of instructions could include a request for a donation.

As to volume, 25 at a time seems about right to me. Go for 250 and you'll be left with a lot of stock I'd reckon. Demand has been pent up, but is limited.

On Tue, Mar 4, 2025 at 3:09?PM saipan59 (Pete) via groups.io <saipan1959=
[email protected]> wrote:

Correct, AFAIK. The distinction (I think) would be: To draw a line, you
have an X-Y START point, and also an X-Y END point. You could have analog
circuitry that causes the X and Y voltages to move linearly from the start
point to the end point, thus drawing a perfect line.

The 2430 and its ilk have a relatively simple vector generator circuit for
X and Y that recreates absolutely beautiful traces on the CRT. The slope is
generated by subtracting the current and the desired X/Y, which is then
sampled at the appropriate time. I guess to generate arbitrary vectors
you'd want to be able to set a starting point ... or just control the Z
axis as well?

No clear about the role of DC502 here...
T

On Tue, Mar 4, 2025 at 12:49 PM, Craig Cramb wrote:

Leave the design and building to the Tek Museum. They use it to keep the
museum in operation. Soon as they allow everyone to get the design or
reverse engineer the board then it’s for others to run with and take money
away from the original developer.

The same thing has been done many times, for years. Consider all of the "oscilloscope clock" designs out there. Anyone who wishes to support VintageTEK.org should absolutely buy from them (do they actually make a profit on those sales??). As for me, it's an intellectual exercise, which I think some folks on this forum are interested in.

Jimbert wrote:

I've never worked with vector displays, but isn't what you describe how it has to be done? You can't just tell a 'scope to draw a line from point A to point B.

Correct, AFAIK. The distinction (I think) would be: To draw a line, you have an X-Y START point, and also an X-Y END point. You could have analog circuitry that causes the X and Y voltages to move linearly from the start point to the end point, thus drawing a perfect line.
When an MCU with a DAC is involved, the difference is that there are discrete steps. In my case, there are 4095 steps between 0 volts and 3.3 volts. The DAC output could be LP filtered to give a very close approximation to a true line.
For drawing a picture, it could be made up of a collection of "lines", each with a different position, direction, and length. This is what a vector display does. My simplification is to replace a line with a series of dots.

Pete

Leave the design and building to the Tek Museum. They use it to keep the
museum in operation. Soon as they allow everyone to get the design or
reverse engineer the board then it’s for others to run with and take money
away from the original developer.




On Sun, Mar 2, 2025 at 1:03?PM Dave Brown via groups.io <davebr=
[email protected]> wrote:

We have inventory for another set of 25 and will begin building. Watch the
store. We didn't expect this amount of demand and have a lot of shipping to
tend to this week.

Pete said: "... Each vector can have a default length of "one". That is, each is actually a pixel, which only needs an X and Y position. It's not necessary to "draw proper lines". .... In the MCU, the code simply goes to each pixel position and "lingers" for a short time. ..."

I've never worked with vector displays, but isn't what you describe how it has to be done? You can't just tell a 'scope to draw a line from point A to point B. I guess the only difference would be how the image is stored. In your description, I think the image would be stored as pixels. The alternative would be to specify the vectors in the image file and have the MCU calculate each pixel and then "draw" them as you describe. The latter would make the image file smaller but would place more burden on the MCU. It would boil down to a tradeoff between memory size and speed of redraw (flicker).

Sorry, one more thought:
Making vectors programmatically doesn't have to be difficult: Each vector can have a default length of "one". That is, each is actually a pixel, which only needs an X and Y position. It's not necessary to "draw proper lines". I should be able to handle up to about 5K pixels (much more than is really needed I think). In the MCU, the code simply goes to each pixel position and "lingers" for a short time.
So, the PC program simply looks at each pixel (or group of pixels) in a BMP file, decides if it is 'on' or 'off', and if it's 'on' then output the X and Y values. An optimization would be to send the pixels in a "nearest first" order, to avoid traversing the display more than necessary.

Pete

Meanwhile, in my experiments this morning:
A raster display WITHOUT a Z-axis is looking "impractical". Two issues so far:

1) A 256 X 256 bitmap only updates 4 or 5 times per second. The issue is (primarily) that the pixels are 'compressed' as 8 pixels per byte, so there is code required to 'unpack' individual bits from each of the 8K bytes.

2) To avoid using a Z-axis, my idea was that the dot would move off-screen to the left for any 'blank' pixels. This allows each pixel to be "equal time", which is good. But the limited BW of the MCU's output causes some 'smear'. And, with my test scope (Tek T935), when in X-Y mode the horizontal position control doesn't allow the 'blank' trace to go off-screen. Because it has a high duty-cycle relative to the 'image', it is VERY bright. AND, the T935 is 35 Mhz BW, so on an older, slower scope the smearing and such would be even worse.

So, I think I'll switch to working on a vector-based solution. The only downside I can think of at the moment is that it adds a lot of complexity to the code on the PC that must generate the vectors (I would like to feed it a BMP file, and have it produce a set of vectors). Of course, creating image vectors by hand would be easy (just tedious).

Pete

On Tue, Mar 4, 2025 at 10:34 AM, Nick wrote:

Throwing a raster image on an analog scope misses the point in my opinion. ... Send your bitmap through digital DisplayPort to a digital LCD, it'd look better.

I understand your point, but (to me) the main point is "display something **on an old analog scope**". That is, displaying a GOOD image is NOT the point of the exercise - of course there are much better ways to do that.
As for raster vs vector: a raster is a collection of vectors, perhaps with a Z-vector added.

Pete

Throwing a raster image on an analog scope misses the point in my opinion. One of the biggest advantages of an analog XY display is its ability to draw vectors with infinite resolution, something that no modern digital system can achieve. If you're not going to showcase that capability, then why use XY at all? Send your bitmap through digital DisplayPort to a digital LCD, it'd look better.