6502.org

Complete off-topic, but, any chance you have a collection of pictures of this thing in action?

Thanks.

As I wrote about it, I was thinking that I should take pictures of the screen with it working. I have not done that yet. It's one of many projects lacking from my project pages on this site. Some of the project pages that are there need to be updated.

The beam on the oscilloscope is not nearly as fine as what's on my monitor in front of me, so I have to give it only about 128 dots across and about 100 down on the 8x10cm CRT screen. Since it's a normal oscilloscope however, you can pan and zoom with the front-panel knobs.

I got it going in Forth with code to generate characters (upper and lower case, plus special characters) by looking up the dot patterns in a table and putting them in the video array which gets sent out the VIA shift register repeatedly. The idea, for next time I want a graphics display with the workbench computer, is to also write drawing routines for instrumentation graphics like a spectrum analyzer display for example, with various points labeled in text.

The VIA's shift clock output increments a counter whose output goes to one D/A converter. That controls the left-to-right position of the scanning beam. I'm not using the oscilloscope's internal time base. The serial data output goes to the Z-axis input, to turn the beam off and on. When the counter for the left-to-right position rolls over, it increments another 8-bit counter whose output goes to another D/A converter that governs the vertical position of the beam, to start another line. One more VIA output bit is used to reset both counters at the start of each frame.

In the picture, the RCA jack goes to the Z-axis input on the back, and the two oscilloscope probes get clipped to the four little posts seen at the right edge of the proto board. Since the horizontal position of the beam is governed the the D/A output instead of the oscilloscope's internal time base, the workbench computer has total control of the data and sweep rate. If you stop the data briefly, all the dots will still be in their correct places, but the one dot it was on when you stopped will appear brighter.

I can't scan as fast as I would like to because the Z input on the scope does not have high enough frequency response, and the picture gets smeared if I try to scan too fast. As it is, if I use a suitable scan rate for the Z input's response speed, and go for too many lines per frame, the frame rate gets too slow-- more than just a noticeable flicker. It's better if I limit the vertical to only 64 lines. Someone gave me another oscilloscope that I hope has a better Z input, but I haven't had a chance to try it yet. Another thing I should try is interlacing, which would require a small change in both the hardware and the software.

I suppose you know this already, but I'll mention it just in case.

They used to do it with just rectangular waves such that the
"pixels" are the tops/bottoms of the wave and the beam in between
gets swept (vertically) off the screen (or to the bottom/top of the
screen) too fast to see, (though in my experience the vertical part is
usually not completely invisible)


Add another DAC and do vectors

Obligatory video of someone employing Bogax's approach:

http://www.youtube.com/watch?v=s1eNjUgaB-g

Yes, I laughed when I saw how simple the oscilloscope readout was for one of the vintage computers, maybe the Sym-1. They used a sawtooth wave and pulled the line to the bottom when they didn't want a dot at the particular height of the wave at that point. They could only do one line of text though, whereas I can do a dozen or so lines of text, plus any raster graphics (as long as it's monochrome and without gray scale). I've done minor vector (non-raster) graphics with a quad DAC on another board. There's one DAC built into the workbench computer, and I've thought about adding another.

MrLinuxGuy, please feel free to take back your thread which we kind of hijacked. If you would like, we can start another topic and take the oscilloscope graphics discussion there (although I'm not sure there's much more to discuss at the moment).

Ah, I don't mind. It's an interesting read anyways. If you want to move to another thread, go ahead, but feel free to stay here. My dad has an old oscilloscope as well and I was also wondering how to send images/text to it.

Another question: Why doesn't the WDC have their 6551 chip out for sale yet? I mean, its not a real problem (I can always get a 6551 from Jameco or some other electronics supplier), but I read a thread made 4 years ago, and it said it was coming soon.

PS: I hope you don't take offense in this, but to see that picture of those stacked up RAM modules made me chuckle. I'd never thought of that, and I have never seen something a simple and ingenious (although a bit awkward) as that . Consider it a compliment.

They have the 65c51 available in samples, but the bug on page 33 of the data sheet is apparently still keeping them from considering it ready for full production. Take a look and see if you can put up with it. The other brands won't be good for nearly as many MHz. You can also use other UARTs, like the Maxim SPI MAX3100 which is smaller (14-pin DIP) and, in general, more capable. Being SPI, you'll have to bit-bang it through a VIA (until Daryl finishes his 65SPI CPLD [Edit: It's available at http://sbc.rictor.org/65spi.html]), but that's much simpler and faster than bit-banging RS-232, and without the timing requirements, and the MAX3100 has an 8-byte buffer anyway.

The IC-stacking has not been a regular practice for me, but it's more attractive sometimes than wire-wrapping more sockets and taking more board space. I have a stack of two half-flash A/D converters too, which you can essentially read voltages from as if it were a couple of memory locations, as long as you don't go over a MHz or so. Being that fast, you don't have to tell it to start a conversion and then come back later when it's done.

That bug wouldn't bother me a whole lot, but I think I will just use the MAX3100 for the moment. Maybe when they get it fixed I'll see if I can implement it.
I'm guessing bit banging through a VIA means that I'll have to use the VIA as a proxy from the MAX3100 to the 65826, right? (and the MAX3100 should be connected to a MAX232 Line driver/receiver). Maybe I should add another VIA to my system, because I'm already planning on using at least 1/2 a VIA for the keyboard, and now another 1/2 for the serial communications.

As for the keyboard, I'm looking to either go Apple IIe-style (a matrix of keys, if I do remember so), or connecting a PS/2 keyboard to it. Hopefully I'll be able to find something that isn't power hungry, although keyboards have never had a reputation of being so.

I'm not quite sure what you mean by "proxy," but it does sound approximately right. If you put the clock line on PB0 or PA0, you can toggle it with INC/DEC PB or PA (with A in 8-bit mode) after you start with it in a known state, without chaning the other bits. It's not necessary to AND and OR them. If you make your data-in line to the master (MISO) a bit 6 or 7, you can test it with BIT, again without ANDing, and do a conditional branch immediate following the BIT instruction, with no concern for what's in A at the moment, and without affecting A, X, or Y.

I would not stop at one VIA for a computer, but I will say that one VIA can be used for a lot more things simultaneously than most people realize. If you have 3 bits of I/O dedicated for serial I/O, plus let's say three more for SPI selects, that lets you use 7 SPI devices and a load of I²C devices (UARTs, A/D and D/A converters, keyboard controllers, display drivers, serial memory, hundreds of bits of I/O, etc., and you still have more than half the VIA free. A lot of things can be doubled up, since bits can be toggled on connected devices that are not selected at the moment. On a single VIA, I have a synchronous serial port (the SR) for dumb shift registers, the timer (T1) for the software RTC, the printer port, LCD interface, keypad interface, beeper output, I²C port, and ABORT button input (like a RESET button, but not as drastic since you can get the processor's attention with an NMI without resetting all the hardware), and a few of the bits are shared with other interfaces (like the oscilloscope raster graphics). The other two VIAs are only used for half as much stuff and are more free for non-dedicated I/O.

The MAX232 is what many people think of first for RS-232 line drivers and receivers, but there are lots of ways to accomplish the same purpose. For example, if you already have ±12V (or anywhere near it (like for LCD bias, supply for op amps for data converter input and output, etc.) you can use the MC145406 which needs no external parts and has three line drivers and three line receivers, instead of two, in the same size of package. Or, if you are on a super-tight budget, the 1488 and 1489 pair give four pairs of drivers and receivers for about twenty-five cents per IC, and again require no external parts like the MAX232 does.

if you REALLY want to go cheap, and you have +-12 volts, use 2N3904 transistors to bias and invert

From http://www.ntia.doc.gov/ntiahome/ntiage ... ossary.htm, a proxy is:A more general meaning of proxy is any entity which operates on behalf of another when interacting with still another. A go-between. Something which isolates. Etc. (E.g., opto-isolators can be thought of as proxies for wires -- they do the same basic job as wires, but there is an isolation between either side of it.)

In this case, the VIA is a "proxy" because the 65xx isn't driving the MAX3100 directly; instead, it's driving it via the VIA (heh, always wanted to write that).

In fact, all peripheral chips serve the roll of proxies -- they literally adapt one interface into another, more standardized interface more suitable to the processor's (or software's) liking.

You can also have software proxies as well -- this is the foundation of all remote procedure call systems, including DCE RPC, CORBA, DCOM, and SOAP systems. Even in single address space environments, proxies are often quite useful for loading and saving data from/to files on-demand, making for quicker disk I/O. You'll find many object oriented environments usually have some standardized method of "serializing" object state into some generic concept of a stream. These streams could well be disk files, but they could also be network connections, for use in RPC systems. DCOM is built this way, for example.

Anyway, I thought I'd clear up the use of the term, plus show how the term is analogously applied in other areas too.

The word "proxy" is not new to me, but I didn't feel I had a clear idea of what Mr.Linux had in mind in his question.

If we go with this definition then I'd have to say "not really," because the VIA won't "look like" the MAX3100 at all. The definition above bears more resemblance to an emulator. (And no, I don't mean a simulator which is software only and is what people often erroneously call an emulator. An emulator includes hardware.)

If we go with this definition then yes. But the SPI bit-banging is only a distant relative to the RS-232 bit-banging. It is much simpler and faster than RS-232, and leaves much of the real work for the MAX3100 to do. Are you familiar with SPI, Mr.Linux? SPI, I²C, Microwire, and other synchronous serial methods are super-nice solutions for a lot of interfacing problems.

Garth
Microsoft-free, with Linux

Err, I daresay I only know what they are in rough terms. Its basically, instead of sending the data at regular time intervals over a parallel bus or the sorts, you simply send it like serial communications would, except at higher speeds. That's my rough idea for it. I have no clue what SPI, I²C, Microwire, and the other things are. Even my concept of RS232 communication is pretty bad.
Now that's an idea. After all, isn't that what a line driver is? (Looking at the schematic on the data sheet, I think that that's all there is to it).

I might add that there is an example SPI interface using the VIA and an input SR on

http://www.6502.org/users/andre/csa/spi/index.html

Cheers,
André

P.S.: SPI is also used by SD-Cards, which is what I use it for. It requires 3.3V conversion though