Great, well done! I'll look forward to checking it out in more detail when I have a bit more time

Huge congrats! Can't wait to see the demos

Couldn't sleep much, so here is my first big demo! The requisite Gouldian Finch!

I took the picture from the internet and ran it in GIMP. Scaled to 320x240, indexed to 4 colors, back to RGB, color mapped to my particular 4 colors. Ran it through my converter program for hex values, dumped them into an .asm file with a short program copying ROM to Video RAM. Done!

I've done a LOT of bitmap data conversion in the past for textures in my OpenGL video games. I don't know why, but when I'm reading in bytes from a .bmp file, you always have to switch red and blue, and then it also reads from the bottom up! Weird, but things I've worked through over the years.

Some things I'm noticing:

The first 4 pixels are not displaying on the far left side. I believe this is because at H800 the Video ROM enabled H-Reset as it should, but I put that chunk in H-Blank also. I could play with it, and I think I could get 3 out of the 4 to display. I'll test that soon.

Soon I'll get some text going too. I have a bunch of busy days ahead of me, so I don't know how much further I can get at the moment. The finch will have to do!

Thanks everyone, I appreciate all that you have done for me.

Chad

EDIT: Yep, just re-did the blanking during reset and I actually got all 4 pixels to display on the side, very nice! Ok, it's a full 320x240 now.

Nice, and well done again. I've had similar issues with left-column pixels in the past, including having them be missing altogether, and having them be duplicates of the ones in the next column. It can be hard to spot on test patterns.

For two-bit colour in my own circuits, instead of joining B and G together, I used a resistor divider to derive G from R and B, so that I'd still have pure white as one of the colours, but have more pleasing tones for the other two. I ended up with orange and light blue, which was quite nice.

Good use of the shift registers.

Have you tried making it loop forever writing the picture to the video memory, rather than dropping through to the tight loop at the end? Stress-testing the write timing is a good way to flush out any issues with it - even if it's just writing the same data over and over, you can still watch out for speckles appearing all over the screen, for example, or randomly corrupted writes.

Some of y'all might be thinking I'm post-happy today. I am

George! In reply:

My first pixels seems perfect, I checked them against the image's pixels, and they line up.

I do like your softer colors. I could put a higher resistor in between G and B for a darker cyan, but... right now I like the super BRIGHT colors, haha!

I did do the stress test one or two times just now, no flickers no noise, no nothing. So that's good!

Attached is my updated assembly with character fonts added! Found a cool 8x8 public domain font on the internet, ran it through GIMP, and then a program to convert it to hex values for me. It only takes up 1K of ROM, which is nice because the finch takes up around 30K! And of course I put a little test string on top of the picture to show off the characters

Well, I got a clear picture, I got characters, now it's time to add the VIA and play with the keyboard a bit. I hope to build a hex monitor for this very soon.

Thank you George. Without you and your schematics, I would not have been here today. Your plans are the basis of this computer, so thank you.

Back to normal life again!

Chad

interesting design!
i've wanted to try something like this for a while now but never got around to it.
currently i'm using an ATF1508 hooked up to an 8kB Dual Port RAM IC. it works perfectly but DPRAM is not cheap in large amounts so i might just try this out.

if i understood the schematic right then this should be a simplified block diagram of your system:

and i got a question about it, why is the whole memory map shared between the Video Circuit and the CPU, including IO?
i assumed it would be more like this:

where only some RAM (and maybe a character ROM) is shared between both, and stuff like IO and a program ROM would be exclusive to the CPU Bus.

does it simplify the circuitry to share the whole bus instead of a part of it?

Thank you! And yes I understand.



I... do not know exactly how to read simplified block diagrams apparently. I get where you are going. I'll try my best.

The User RAM and the Video RAM are separate. I would see this system something like 6502 + 32K User RAM + 32K User ROM + VIA I/O, and then I said, "Hey wouldn't it be nice to add VGA to this simple circuit?" So I put 3x 74HC244's on the address bus and data bus, and connected the other end to 32K Video RAM which 'shadows' the 32K ROM area (read comes from ROM, write goes to RAM). VGA reads from that Video RAM through shift registers.

The problem is how do I set up the timing of the VGA? That's where the counters and Video ROM comes in. I programmed it in binary to send out signals at just the right time. So:

Counters -> Video ROM -> Sync Signals
and
Counters -> Video RAM -> Shift Registers -> RGB Signals
and
6502 -> Video RAM

The only 'talking' the 6502 can do with this VGA system is through those 74HC244's and only at very specific times when the VGA circuit doesn't care (because it's shifting instead of loading). The rest of the time, this VGA circuit just does it's own thing.

I hope that answers some questions. I do not share any RAM or ROM, they are completely separate from one another. Only the 6502 has access to the VGA circuit, and only at very specific times.

I'm already thinking of modifying the circuit a tiny bit to include more colors. I am fixed on circuit's timing, because it works and I don't want to mess that up. But I'm seeing if I can squeeze more colors out somehow, perhaps through a color palette that is preloaded during the back porch time frame. Though, as George taught me, timing is very critical to making this all work nicely.

Thank you Proxy!

Chad

EDIT: Yes, after looking over those diagrams again, I see that it is the SECOND one you have there. Yes exactly. Thank you!

Yes it's the problem I mentioned here: http://forum.6502.org/viewtopic.php?f=4&t=7030&start=0#p90951
It reduces the time for things like address decoding to see the address before the read/write signals are activated, and it's also likely to confuse things like the 6522 which expect valid address at the start of phi2.

Ideally only the video RAM should be behind the transceivers, and everything else should be directly connected to the CPU's bus.

It's probably hard to fix on the PCB unfortunately. It sounds like what you have already is working though. If you do have trouble with the 6522 then you could maybe delay the 6522's phi2, like the write enable signal - and that might be possible to bodge. I'd definitely fix this on the next PCB revision though!

in case the big "MUX" is a bit confusing, that thing basically just represents your Address/Data Bus Multiplexer.

oh wait, i'm stupid.
i just saw that you had an updated schematic further down the thread. i read through the whole thread but when doing the diagrams i used the one from your first post where it only had a single RAM IC, so your description here really confused me for a second.

yea looking at the correct schematic this time, i see what you mean. quite clever to use a ROM as replacement for logic!

yea, again sorry i looked at the wrong schematic... and the second diagram is closer to what you actually made.
and that makes me wonder if it would be possible to adjust your system to have the CPU and Video Circuit (VC) running at different clock speeds. it would likely require a few extra octal D latches between the CPU and VC, but it would allow you to run the CPU faster to do more work!
hmm, something to think about.

i assume you're using 640x480 as a base resolution, and then just draw every pixel twice, and every line twice to get 320x240 (that's how i do it atleast)
so standard 640x480 timings would give you 160 cycles @ ~25MHz or 20 cycles @ ~3.13MHz between each visible line (except the last one because that has all the vertical blanking).
question is, is that enough time for you to load a color palette for each line (or every n lines)?

I haven't implemented any palette support yet but my main thoughts on that are:

1. If you have fast enough palette RAM you can just put it between the shift registers and (a better) resistor network, and maybe add another latch after the palette RAM to get a sharp consistently-timed transition for each pixel. But you also need to be able to write to the RAM, which means yet more transceivers to control its address bus.

2. An alternative could be using 8-bit D flipflop registers, one per logical colour, and enabling their outputs based on the logical pixel colour value. They're easier to update (separate input pins), and plenty fast enough, but this is only good for fairly low colour depths as it requires a lot of ICs.

3. Slower RAM could still work if you decode multiple pixels together so that you can do the lookups at a slower pace - I've thought about several ways to do this, but not really made any decisions

4. This is something that an FPGA would be way better for, but that's a slippery slope, as they are way better for a lot of things!

Modifying the palette on the fly was "a thing" back then - even on the BBC Micro in 4-colour modes (Even on the BBC Micro changing the screen mode on a per-frame basis to get higher resolution mono with a lower resolution colour block at the bottom - see "Elite" for example... So being able to do it on at least a line by line basis might be a good thing...

Also see "the demo scene" to take ideas from what they're doing today on machines of then...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

So... unless I wired something wrong (totally possible), that VIA should not have any issues. I have run 2 other boards with identical configurations, and have had no issue. I am just following Garth Wilson's model, with a slight modification from BDD. At its core, this is just a Garth Wilson / Ben Eater board with VGA tacked on.

It is true I have not yet tested the VIA, Ill be looking out for that. Thank you George.

Im on a cell phone so Ill keep the replies shorter:

I had tried a different timed CPU vs VGA before, with my "V3" boards. It was a failure, and Bill and George convinced me to keep the CPU at a multiple of 25 MHz. I am very happy at 3.14 MHz personally, I would have been happy at 1.57 MHz!

A separate palette RAM would be nice, but definitely more ICs, more logic, more everything. Yes FPGA/CPLD would be better.

Gordon, you mention the demo scene, thats good info! I was driving for 3 hours today and had time to think through this color issue. I think I might just use a pin from the VIA to enable a buffer or decoder between the shift registers and the VGA out. It would be super "cheap" but Im imagining getting a palette close to the Apple II (white, black, and 4 colors but only 2 at a time) yet a bit more crude. A mid-line palette switch would then be possible, but timing must be perfect, devoting most of the CPU to watch-and-wait, or perhaps using the VIAs timers with interrupts. It reminds me of "demo scene" tricks, because nobody would spend so much time waiting for a palette change normally. I dont know, just thinking out loud. Not saying it is ideal or even "good". The octal D latch has been on my mind a lot, but my resistor knowledge is much smaller than digital logic.

Good info guys, thanks for the input! I am always happy to receive it.

Chad

An update!

VIA is working great! PS/2 keyboard is working great!

I had to learn a lot about interrupts. Being a C++ programmer did not help me in the least, it probably hurt some. The biggest 'bug' I had to solve was when I was only reading 10 bits from the keyboard, not 11. Why? Because my interrupt sub-routine was WAY too long! It was long enough that I just completely ignored one of the bits, and that threw everything off. After I figured out that puzzle, the rest was fairly straight forward.

I'm also learning a lot of assembly. Quick tricks with the stack, better uses of instructions. I am not in any way GOOD yet, but it is neat to learn such a bare-bones language.

Lastly, I had to rewire my PS/2 connections because I had originally intended on using the shift register with CB1 and CB2. Nope! There is a bug in the 6522 that WDC hasn't fixed, and it affects exactly what I was planning on doing. I just switched things over to CA1 and PA7 and it works great.

Next is the piezo buzzer, but I don't think that will be too difficult. After that is SD card interface! THAT will probably be difficult.

Thank you everyone! I'm so happy to be in the 'software' phase now.

Chad

Sounds like you're enjoying yourself! That's great. Making things tick when you're working down at the machine level is very satisfying.

Hey everyone! I just made a hex monitor!

Attached is some demo screenshots. It has 4 commands:
J = jump to page/selection (as in, the JMP function, basically is a 'run' command)
PXX = change current page
SXX = change current selection (byte within page)
WXX = write value to page/selection

I can't fit 16 byte values on a line, but 8 bytes per line would not show the entire 256-byte page, so I went with 10 bytes across each line for counting purposes. I have been thinking of doing a WozMon style monitor, but this one was VERY simple to do.

I'm attaching my code, but at this point it is near junk. I feel like a lot of it is piecemeal at this point, regardless if it is or not. Some of the functions are really great, but others are not. My naming conventions are wild. I will definitely be re-writing *most* of this, and perhaps in a more common or 'readable' format (sometime in the future).

It seems my PS/2 keyboard routine is not super great either. If I mash the keyboard or something, it doesn't register correctly. Why? Because my main loop is so long sometimes, that some keyboard values get missed entirely. Not the signals, those are in the interrupt. The value I grab after 9 pulses come through. I do not have a keyboard buffer or anything, so whatever happened LAST is what is going to show up. Right now it works as long as I type each key slowly. The return key I have to press twice sometimes, not sure exactly why, I think it's an internal byte value that I don't change or something. Backspace works great! I have not implemented Shift keys, or anything in the Extended format. So numbers are all from the numpad for now, very awkward!

While coding this stuff, I am learning SO much! I'm learning what things I want to keep and what things I want to modify on the next version of the board. One thing in particular, I really want to move all my plug-ins to one side. I also want a power switch Been using a screw driver to remove the FlashROM each time, but that seems to be going well, the 'lips' sockets are SO much better than the circular ones. So what if they are cheap and bend, at least I can not tear my FlashROM to pieces each time!

Just an update. Glad to be in software. That analog/audio stuff I've been working on is cool, but so hard! It is so cool to learn, but I really really like coding.

Thanks everyone!

Chad