Isn't the display only a small part of the project? Even if this display is obsolete, the advances you make might apply to other similar displays.
Not to mention, the project on the whole might be of interest to others, either now or in the future. Keep posting!

Daryl

The display is a minor bump in the road. The meat and potatoes are in your circuit design and logic. You can always work out the interface to another display device once you're satisfied with how the core circuit is operating.

Incidentally, in your circuit you show an 'F138 decoder. The 'AC138 version has identical propagation times at 5 volts, but being CMOS, eats fewer electrons as it goes about its business. Unless you have logic that requires TTL voltage levels, you should abandon all 74LS' and 74F' logic where possible. In most cases, you can use 74ABT' or 74ACT' silicon to interface to TTL-level circuits and still achieve single digit nanosecond performance.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Keep going!

keep posting!

you never know who might find it useful or interesting, now or in five years time. Or fifteen!

Not wasting my time. My vote is to continue posting about your project.

By the way, what is the latest problem?

I just wanted to see if anyone was interested. The only problem right now is that the display is discontinued, so now that I am making progress, I was asking myself what is the point of posting if noone could replicate what I am doing. But like 8bit said, the display is only part of the project. I was getting too wrapped up in the video part of it. But now I get to see all you lurkers anyway

I'm going to make a video soon after I wire in an 8-bit ADC and finish the DRAWBOX routine. I'm done with the horizontal and vertical line routines, and should finish the DRAWBOX routine tonight. I'll save the diagonal line routine for later, that'll be a challenge. Without the delays, it clears the screen about 4 times faster than those 2 videos I have on youtube. Still this is not fast enough. I would like to copy the contents to RAM and run the "OS" from it. Right now I'm using an 8Kx8 EEPROM with access times of 70ns. The 32Kx8 SRAM has access times of 20ns. Right now with my present setup I can run at 7MHz max. How much faster could I run using the RAM? If I do opt to get the 640x480 display that's alot more display memory I will have to manipulate.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

There I go again. There's no need for a diagonal line in my project. I am thinking ahead to when I may need a simple graphics engine, and I may as well do it while my brain is in the mode. But this is the temptation all designers face:"Why stop here, when we can make it better?". I was also thinking about starting over with the NHD640480 display, but I'm going to stop now with the graphics part and go back to wirewrapping in the 0820 A/D converter. I am so jealous of the 640x480 because it can display a full 256 pixel vertical with room left over, unlike the 320x240 vertical I am using now. I will have to use numbers to display the exact value and the graphs will be 1/2 value. I plan to use the data sampled from the ADC to see how fast the same data can be displayed on several different bar graphs and horizontal dot graphs like an oscilloscope. I'll post a pic soon, but I realized the C-64 char's are good for some things but I need a smaller 5x7 character set, which I will have to type in myself since I can't find any raw data on the web. This will take a few days...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

5x7 was still too large. Had to make a 3x5 character set. Also made the PLTCHAR subroutine recognize a charset variable that automatically does the vertical and horizontal spacing and character table offset. 2 Character sets so far. I would also like to do a 3rd character set, that's 16x16, for the startup screen.

It's been more than 20 years since I programmed 6502 assembly for graphic routines and I have been away from electronics for just about as long, but I really like the reward that comes from finishing a good subroutine. Even more than building a piece of hardware. Nice and compact, fast and clean. So anyway, so far I have written a little over 1K of code. These are the routines I've completed.

CLeaR SCReen.
XYCALCulate.
DRAW Vertical LiNe.
DRAW Horizontal LiNe.
DRAW BOX.
PLoT CHaR.

Now I am back to doing a subroutine I mentioned before but I never did get around to tackling it. I need to figure out how to display a 3 digit decimal number from an 8 bit hex value. Is there a better way than just doing a 256 value lookup table?

Things planned for tomorrow:
1) Wire up an ADC0820 and hook up a mic for simulating signals.

Things planned for the future:
1) Update videos on youtube.
2) Learning Macros for Michal Kowalski's Macroassembler.
3) Learning PICs and/or Atmel Atmega series.

I think the Atmel part is what I really need for frequency generation. I need to have a programmable 50/50 duty cycle frequency generator that can run sub 20MHz and have good divider resolution.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

This will be the startup screen. All live data read from inputs will be put inside the boxes.

I am thinking about an alternate screen with large character's.. So you can switch between the fuel injector pulse widths (quick changing data), and the coolant temp, air temp, etc. (slow changing data). I will be looking at this datum while driving.

Notice as well, if I had a 640 H x 480 Vertical display, I could display another 4 cylinders, but all characters would be half sized...

EDIT:old image updated.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I forgot the TPS sensor: The previous post will be updated soon.

At this point, I realized there will be no need for the: Cam position sensor, MAF/MAP sensor or any of the oxygen sensors. Not at this point anyway. I need to observe fuel injector pulse widths to see where I can modify my driving skills to achieve max fuel economy within the restraints of EOM incar CPU programming. And then recompare after a supplemental fuel additive. And then take over control of the fuel injector PWM after that.

I expect all of the sensors I will be monitoring to be linear. The crankshaft position sensor will have to be referenced to 1 sec for a RPM display. This is an obvious linear sensor. The TPS, Coolant, Air Temp, and Speed hopefully will be linear . The plan is to manually measure each one of these sensors at 2 different lower speeds and then be able to interpolate all other readings, in between and above the initial measurements.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

PLot CHaR2 with variable X and Y sizes completed today... I can now display slow changing 8 bit data in large number form. While the faster 8 bit data will be displayed in bar graph form.

...I accidentally deleted all pics from Photobucket. I'll upload the originals soon...

I've not wired in the ADC yet, as I've mentioned I would ... Software is taking more time and my mind goes off in tangents. But I am looking at an 8 channel ADC, along with a multiplexed 8/16 bit counter to analyze the fuel injectors. Also I want to transmit the data wirelessly.

I am really interested in picture data next. Text is boring and now all the text routines have been completed. With a 65C02 at 6MHz, I want to make 65K color sprites/icons from, say a .JPG file. I'm in the process of doing research.

Next I'm going to try to take a pic from a cam, convert it to 16 bits, look at the datum in the hex editor, and then and see what it looks like on the display. I am thinking even if the colors aren't matched, there will be some kind of correlation.

If you can, 24bit BMP files are much easier, as there is typically no compression. Just a header and pixel data.

I read this link and was able to convert a 24bit bmp file to a compatible 8 bit image on my SBC-3 using a simple QBASIC program. Took 30 minutes from start to finish. Making sprites and background pictures should be simple. Conversion to other color depths is just a matter of using the most significant bits for each color from the 24 bit source.

http://local.wasp.uwa.edu.au/~pbourke/dataformats/bmp/

Hope that speeds things along!

Daryl

Thanks for the lead... I have 2 days off starting next week. I'll look into .bmp's. Are you aware of any hex editors that can perform the same function as the QBasic program you used?

No, I have a few hex file viewers, but they do not allow editing.

In my case, I was converting 24 bit to an 8-bit pixel size which required some math, not just some cutting and pasting.

Daryl

I don't know if this is what you're talking about, but the very feature-loaded programer's text editor I use, MultiEdit by American Cybernetics in Arizona, has a hex mode that lets you edit hex code. It's all in rows and columns of two hex digits for each byte, with ASCII interpretation on the right if it's displayable.

For Intel Hex which is plain text, any text editor will work. I don't think MultiEdit can re-calculate the checksum byte at the end of an Intel Hex line, but if you're making just a few changes to a file, you could calculate it by hand.