Acolyte "Homebrew" 6502/VGA

[sburrow]

Introducing the Acolyte "Homebrew" 6502 Computer with VGA capability!

The 6502 processor is running at 3.14 MHz. It has 32K RAM (expandable up to 80K) and 32K ROM (expandable up to 128K).

VGA modes include:
640x240 monochrome
320x240 4-color
160x240 16-color

Look at my Gouldian Finch now! Also, the monochrome text looks great!

Attached are some pictures from some demo code I have been working on for the past couple of weeks. The bird came out great, the text looks good, BUT:

1) My ML monitor is not exactly 'correct' yet. Now that I can test my code, I'm sure it will look better soon. A good start though!
2) My bird is blue tinted, and a bit dim. I was sure I got my resistor values right. Hm...
3) Lastly, there are these thin green lines at specific intervals. They occur even when I have no ROM plugged in, so it seems to be a hardware issue. I'll be checking into that first. If any of you have seen this behavior before, please tell me what you know!

Whelp, there we have it! A good start to a new project. And more to come soon. Thanks everyone!

Chad

[sburrow]

Hm.

Attached is the new 16-color bird. And it's just as expected now. It is no longer blue tinted. Why was it blue???

Well... My schematic connected these 3 resistors together. My board layout connects these 3 resistors. I grabbed a blank printed board and they connected these 3 resistors. BUT on the board I was soldering... they were not connected. I mean, I *could* have sliced through it somehow. Somehow? Or burned through it? I don't know, SO weird.

Has this sort of thing ever happened to you? As in, the board manufacturer doesn't have 100% guarantee or something? So strange, never had an issue in the past. It *could* have been me, but that would be strange unto itself!

Lastly, I connected it to another monitor, and I got DIFFERENT lines. Still green (there are some red ones in there too, you can't see at some angles), but they were almost static. All over the place, moving around. I would bend the cable, and it would change the brightness of the green lines.

So! I am convinced it is the cable's fault. Unfortunately I don't have another cable, all my equipment is at the office from Math Day. So tomorrow I will bring home the CRT and some extra cables, and see what happens there. One step at a time.

There's the update! Thanks.

Chad

[sburrow]

Three out of four monitors work fine.

From the bottom up:

My normal widescreen LCD monitor for my own desktop computer. Looks fine. When it's black I see a bit of fuzzy greenish stuff, but you almost have to be told it's there.

My super-huge LCD monitor, looks great, I can't see any issues at all.

My CRT monitor is perfect, spot on as always.

My little Dell LCD is... messed up. The monitor is still displaying weird lines.

The last picture is from the same Dell at a top viewing angle. You can see various colors of lines going on. They aren't moving, so...

I think this is a noise problem. Cables, monitors, etc, something isn't *perfect* so the monitors are acting differently to compensate. Some just ignore the noise, some think it's important, some just blend it in.

Attached is the 'analog' portion of the board, where the color signals are sent to the VGA connector. Should I have not put power and ground traces around this area? Because I am seeing non-moving vertical lines on the Dell monitor that it is detecting this noise at specific time intervals, thus it is involving the clock, and thus it could be when there are big transitions of bytes or something. Just speculation.

Or the Dell monitor could be broken after Math Day. I mean, all types of things happen when you transport stuff around in boxes.

Thoughts?

I'll test on another Dell LCD monitor soon. But three out of four is pretty darn good.

Thanks everyone.

Chad

EDIT:

OH darnit... I went to the Dell monitor menu, and noticed "phase" and "clock". Adjusted those, and the lines moved! Then I hit "auto adjust" and... the lines are gone. Entirely.

*sigh* Case closed. Thanks. Now onto software!

[sburrow]

Attached is some software demos for this hardware. Trying to include anything relevant.

Demo-Keyboard.asm is my latest keyboard code for monochrome mode. It uses a 256 byte page as a key buffer, so you can type as fast as you want and it doesn't bog down or miss any keys. WOW it was easy to do this, keep it simple and it works beautifully. No support for release or extended yet, but it detects them (and I just simply ignore them for the moment).

Demo-Sixteen.asm and Demo-Four.asm are the Gouldian Finch in both 16 and 4 color modes. Good for showing off screen resolutions and colors.

PictureConverter.cpp is what I used to change .bmp files into .hex files, in case you are interested.

VideoROM.cpp is SUPER important to this build, as it will output the .bin file that does all of the screen timing.

And also a picture of my monochrome text from the keyboard demo, 80 columns by 30 lines, clean and crisp!

When I get more software designed for this build, I'll post it eventually, but for now I just wanted to get the basic demos out there. In the future I plan on providing code for the 'cassette' audio input, SPI stuff, and hopefully the ML monitor at some point.

Thanks everyone!

Chad

[BigDumbDinosaur]

sburrow wrote:

Attached is some software demos for this hardware. Trying to include anything relevant...Demo-Sixteen.asm and Demo-Four.asm are the Gouldian Finch in both 16 and 4 color modes.

Wow! You’ve made quite a bit of progress.

Code: Select all

	LDX #<screen
	LDY #>screen
picture_loop
	STX copy_read+1
	STY copy_read+2
	STX copy_write+1
	STY copy_write+2
	JSR copy_read
	JSR copy_write
	INX  <———————————————
	CPX #$00  <——————————
	BNE picture_loop  <——
	INY
	CPY #$FF
	BNE picture_loop
	LDA #%00000011 ; 16-color mode
	STA via_pa

You can gain some efficiency in the above code by eliminating the CPX #$00 instruction. Anything that changes the datum in a register will automatically affect n and z in the status register. Hence the INX instruction can be followed by the BNE picture_loop instruction, as the branch will be taken each time .X is incremented, until it wraps to zero.

Also, as a matter of style, you should avoid use of “magic numbers” in code. Constants should be symbolically defined at the beginning of the program and the symbols used in program statements, such as the LDA #%00000011 ; 16-color mode statement. The problem with use of magic numbers is a trivial typo in entering the number as part of an instruction will result in a difficult-to-locate bug. On the other hand, if you assign your constants to symbols and use those symbols instead of “raw” numbers, you are much less likely to introduce a bug at only one location if the constant used at that location is wrong, e.g., a wrong bit pattern being given to the VIA. Also, if you later decide to change a constant, you only need to change the symbolic assignment. Upon reassembly, all references to that constant will change.

[BigEd]

This looks great - well done!

[sburrow]

Thank you Ed, I appreciate it.

And thank you BDD. That makes a lot of sense! Like, I don't use arbitrary numbers (often) in C, so why would I use them here? Good point. As I continue to code, I will try to do that more often. I'm learning Assembly along the way, and what techniques are best practices, etc. So thank you for that!

Attached is the 'cassette' audio input demo code. I haven't measured baud rates and whatnot, but it's slow. Very slow. I can type just a bit faster than this!

BUT, it does work! I'm sending keyboard hex codes over to the at the moment, and the 6502 is just spitting them out onto the screen. Even though this is slow, it is automated, which frees me up to make a sandwich or something.

Big thanks to Garth on this one. He designed the audio input circuit for me. I barely understand it myself, but it works flawlessly. Thank you very much Garth!

I'm posting these demos to demonstrate that the hardware is working as expected. I hope to make *real* software for this soon enough.

Thank you again Ed and BDD, and everyone else watching!

Chad

[sburrow]

Only a few more hardware features to test! This will be the last for a while, since the others will require an ML monitor.

I have my SPI EEPROM working fine now! Attached is the code and a picture of course. It was super easy except for HOURS I didn't understand that I had to also set some status flags THEN start writing... arg.

I also have updated the AudioInput.asm demo somewhat, but more importantly I made the AudioPacket.cpp better. It accepts a string of characters now. I tested it with 256 characters in particular, had the C program create the audio file, and then it sent it all at once to the computer. It SIGNIFICANTLY increased the speed, it was complete in about 2.5 seconds. I measured somewhere around 800 baud, so that's not bad! I have one 'quiet' bit before each 8 bit packet, so 9 bits at 1000 Hz essentially, makes for around 800 baud apparently. I did the math and... it would still take some time to load the basic 32K RAM, let alone my extended 80K RAM! But it is a solid option now.

And, if you are reading, I have a request, open for anyone: I want to 'sharpen' my 16 color mode. Right now I have RGBI format, and... my bright red is nearly pink, like (255,192,192), and my dark red is nearing black, like (64,0,0). My two greys are almost identical. I did the falstad.com simulation to find the resistor values I have, and though I'm *ok* with it, I wish my bright red was more like (255,0,0) and my dark red more like (128,0,0). Any configuration you know of to make the RGBI style better? I don't mind using diodes and maybe some transistors, but I would like to not have to use another IC. Any help there would be much appreciated!

Thank you all, have a good day.

Chad

[sburrow]

I think I have a working model. Basically I would use some diodes in reverse, or something? I'm getting 0.675V when "I" is on, and 0.5V when "I" is off.

In case you are interested:

https://falstad.com/circuit/circuitjs.h ... rDR3dkaqAA

I'll probably try this out on the board tomorrow and see what happens. It shouldn't be hard to just solder a couple extra diodes here and there. Who knows!

If you have any suggestions I'm all ears. Thanks!

Chad

[BigEd]

It might be that what you need is gamma correction, so a search for analog gamma correction might be the thing. I found this
https://forum.allaboutcircuits.com/thre ... ry.138712/
(Login needed to view the diagram - it turned out I already had a login!)

[Proxy]

The way I did it: my VGA circuit (ATF1508) has a 2-bit DAC for each channel (RRGGBB) and to get 16 colors (RGBI) I just connected the high bit of each channel together inside the CPLD's circuit.
It works perfectly fine but I don't know if it would work the same if you were to physically connect the high bit of each DAC or if you would need a 74x244 or similar in between.

[gfoot]

I think by the time the RGBI palette was "digitised" in EGA cards the bright colours were indeed desaturated slightly.

If you don't mind "bright black" being the same as "normal black", you could just add a diode to each I connection, so that it only ever pulls down. This way, if I is high then the R, G, and B signals are passed straight through (still divided down according to the load impedance), while if I is low they are divided down more.

For this I would tune the RGB resistors first to get bright colours to 0.7V, and then tune the I resistors by eye to control the dark colours.

[sburrow]

Thanks guys. I see some possibilities now. I think I'm going to breadboard a couple of ideas before I start to rip resistors off the board Thank you all, will update when there is something to update about!

Chad

[GARTHWILSON]

gfoot wrote:

I think by the time the RGBI palette was "digitised" in EGA cards the bright colours were indeed desaturated slightly.

If you don't mind "bright black" being the same as "normal black", you could just <...>

I have not dealt with this color video field at all; but I would think that if the two I's tell how many bits to shift the others over, there should be no difference between "bright black" and "normal black," as 0 shifted left any number of times is still 0. Non-0 numbers (ie, they are colors), should not be de-saturated at all by having the two intensity bits telling how many bits to shift them over. Is that not how it's being done?

So taking one color, red for example, the possibilities would be:

Code: Select all

    |  II:
RR: |   00    01    10    11
----+------------------------
 00 | 00000 00000 00000 00000
 01 | 00001 00010 00100 01000
 10 | 00010 00100 01000 10000
 11 | 00011 00110 01100 11000

although you have less than five bits of resolution, even slightly less than four, because the allowed values, when not counting the duplicates, are limited to:

0, 1, 2, 3, 4, 6, 8, 12, 16, 24

It would be like having multiple ranges of gear ratios in a truck transmission or a bicycle with three chainrings, with some overlap between ranges. The possible values for the four ranges are:

Code: Select all

      | possible values for any color:
range:|   0   1   2   3   4   6   8  12  16  24
------+----------------------------------------
  00  |   √   √   √   √  
  01  |   √       √       √   √
  10  |   √               √       √   √
  11  |   √                       √       √   √

(I tried the chart scaled logarithmically too (leaving out 0 since you can't take its log), but it didn't change a whole lot.

[gfoot]

GARTHWILSON wrote:

gfoot wrote:

I think by the time the RGBI palette was "digitised" in EGA cards the bright colours were indeed desaturated slightly.

If you don't mind "bright black" being the same as "normal black", you could just <...>

I have not dealt with this color video field at all; but I would think that if the two I's tell how many bits to shift the others over, there should be no difference between "bright black" and "normal black," as 0 shifted left any number of times is still 0. Non-0 numbers (ie, they are colors), should not be de-saturated at all by having the two intensity bits telling how many bits to shift them over. Is that not how it's being done?

I believe what Chad has implemented so far is just 4-bit RGBI, which was pretty much the way CGA worked. EGA used a 6-bit system (RRGGBB) and maintained some backward compatibility by mapping the 16 CGA colours to specific RRGGBB values.

RGBI itself is mostly very simple - you just connect the "I" line to all three output lines, through resistors, and overall it functions as a constant add to all channels. Here's one I used before:

my RGBI-to-VGA circuit

This then leads to desaturation in the bright colours, but also means that "light black" is distinct from "black" so you get 16 distinct colours. In CGA monitors there was also a weird special case for "dark yellow" being rendered as brown, but I don't bother with that for simplicity's sake.

Edit - to elaborate a bit on what I suggested before, if you are using a similar RGBI circuit then adding three diodes in series with the 680 ohm resistors will mean the intensity signal only pulls down, never up, and everything will be fully saturated. The 470 and/or 220 ohm resistors would need adjusting to still maintain full output brightness. It may also work to just add one common diode near the IC pin, risking a little crosstalk between the colour channels.