Hello everyone

40 years ago I dreamed about building my own computer. But then buying them was so much easier. Then I saw Ben Eaters video and got really hooked. My first attempt derived from Ben's SAP1 was a success (or as my father put it "a lot of effort to calculate 1+1"). But I had to realize that expanding that system beyond the stage of "demonstration level speeds" would not really work, so I'm going for a 6502 based design as Mark2.

After about a month of research I had to realize that the biggest obstacle would be video. For modern monitors it has to be at least VGA, and I have not found any simple video chip that could be used. I don't want to use microcontrollers or FPGA. That left a solution like

https://tldr.fi/2014/09/27/zc160-vga-adapter1/
https://www.bigmessowires.com/2008/07/2 ... em-design/
or
viewtopic.php?f=4&t=3329

I especially liked the Vulcan design, although IMHO from those projects listed it's the one least documented. Unfortunately it seems to be dead in the water Still my design borrows heavily from Vulcan, so many thanks Brad!

Design goals:
VGA Video 640x480 or 800x600
no FPGA or micro crontroller
I like the Vulcan copy machine
16k part of the video buffer should be mapped to the CPU 64kb memory space
some extra memory for data (64kb is not much for data)
I also want to add a AMD coprocessor ... just for the kicks.
64 colors (2 bit per color)

I came up with this layout:

The CPU controls a number of 574 chips. I will need a number of GALs to create the selection logic. The whole address space looks like

0000-00FF Page Zero
0100-01FF Stack
0200-03FF I/O space
0400-7FFF memory
8000-BFFF 16kb window
C000-FFFF 16kb ROM

The extra 574 register to the top right helps to map the extra memory (16kb at a time).

The Video memory is double buffered. One buffer is used by the sync counters to generate the VGA signal. The second buffer is written to in parallel either from CPU or the copy machine. That means I have a number of possible datapaths between the components, and I plan to use (a lot) 245 chips to separate each of them. Another issue is the bus width of 9 and 10 bits - that adds the need of some extra 245 chips.

The sync signal is generated by 2 counters and a 512kb memory chip. I will need to set up correct information in the memory during initialization of the computer. The 8bits will also reset the 2 sync counters at the right time.

There is a copy machine. The source counter is made up of 193 chips and can be switched between 2 separate 12bit counters and a full 24bit counter. I figure a simple transistor between counter four and five should do the job, pulling the ripple input low if I need 2 separate counters.

The destination counter is made up by counter-comparator-register trios forming 2 10/9 bit counters to address the buffer ram.

This little trick should enable me to access a 64x64 (7bit by 7bit) Window of the Video memory. Adding 3x bits and 2y bits to the IPC of the 6502 should allow me to directly draw into the video buffer

So please tell me what you think and help me straighten up the design
thanks
Michael

_________________
No simulation survives contact with reality!

Welcome Michael!

Nothing if not ambitious - anything is possible, but some things take longer to build or longer to debug. I'd recommend an incremental approach, especially for any aspect you haven't tackled before.

Also, while anything is possible, as you add complexity you are likely to be sacrificing clock speed, so if you want an unlimited complexity budget, you might not meet some specific clock speed that you had in mind. And the closer your design gets to not quite working at speed, the harder the debug. So a modest speed goal might be a good place to start.

very interesting design. for practical approach I personally think using a FPGA/CPLD is test out the design (I know you said you didn't want to use FPGA); otherwise it will take alot of time and effort to wire-up all the TTL chips and debug the design.

How many chips can the WDC 6502 drive on the address bus without additional buffering? My current estimate is I need 5 GALs for the decoding logic alone.

thanks
Michael

_________________
No simulation survives contact with reality!

that is my project for the next 1-2 years - time is not an issue

_________________
No simulation survives contact with reality!

It's a very ambitious project, but have you thought about the sort of speed the 6502 will be able to write to the video RAM? I suspect that 640x480 (at 8bits per pixel) will take far to long to clear the screen, let alone write some text to or draw a line, or scroll.

Even if you used the 65816 block-move instruction, you have 300KB of RAM to clear, so at 7 cycles per byte on a 1Mhz CPU it will take a shade over 2 seconds. It will be worse on the 6502 as it'll take more cycles.... Get the clock up to 14Mhz or more and it will obviously be much better but you're not going to get 30fps out of it...

Back in the late 70's/early 80's the consumer level display technology (ie. TV sets) mostly matched the hardware capabilities so it wasn't much an issue then - we put up with what we got - 280x192 on the Apple II taking 8KB of RAM, and a couple of years later the BBC Micro dedicated 20KB of it's 32KB RAM to the highest resolution (640x256x1bpp) and we wondered how we'd be able to write any code for it! But don't let that put you off... Especially if you can separate the video part well enough to adapt other CPUs to it in the future, should you want to - or even "FPGA" the whole video part for other retro-system to use?

Hope it goes well!

Cheers,

-Gordon

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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

thanks!

_________________
No simulation survives contact with reality!

the main copy/clear operations happen in the video system itself based of 74F chips at 10MHz+. There is an error I discovered after posting in the data bus routing - but the idea is the 6502 writes into the 4MB video ram to set up he graphics. What is necessary is then copied via the multiple counters to either of the buffer memory. Once a buffer memory has been set up, and a VGA cycle is complete, the 6502 switches the 2 buffers.

At least that's the theory ......

_________________
No simulation survives contact with reality!

So I've completed the first step, and wanted to report about my experiences

I started to layout a test board with enough connections to add the video systems step by step later.




PCBway delivered very quickly:


and after 2 weeks of debugging v1 was running (printing to LCD display and communicating over serial line with PC at 500kHz)

The breadboard contains an external timing circuit to single step or up to 100Hz, as well as an LCD display (connected to VIA1) and the GAL organizing the memory layout. The board currently is only half populated, I could add one ROM, one RAM, one VIA and one ACIA chip in the future. The Arduino is only a cheap logic analyzer.

So what have I learned?

bringing 2 chip select lines to the external control board is really stupid (duh, now fixed on backside with wires )
bringing all RW signals out to control board is probably worse (double duh, now also fixed on backside with wires)
the reach of a 6 month old is greater than you can imagine, and you will debug for 2 hours until you find the missing resistor
there is an irresistible force drawing 3 year old boys to wires. He will "look" with his fingers, the wires will come out - so naturally the boy will put them back (out of order) for another 2 hours of debugging....
those chips are pretty hardy - if you think you ruined one of them, think again and check your layout. After some debugging you'll still think the chip is broken .... so THINK AGAIN (and read this forum; thanks Garth for http://forum.6502.org/viewtopic.php?f=4&t=4346#p49340)
there is a 99% chance the USB-serial cables you have at home are not compatible with TTL serial from a 6551 (though the cables to connect to an Arduino work nicely)
no matter how simple a connection, if you have 2 options you will connect them in the wrong order and then go bug hunting in the wrong places
a simple logic probe is a good friend
using an Arduino to watch address and data lines brings a lot of insight what the CPU is doing

lots of fun

_________________
No simulation survives contact with reality!

Future forum members!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

So baby steps progress, but still progress!



I put LCD and GAL on little PCBs and it's still working as expected at 500kHz. At that point I decided I need to look at a software pipeline. I need at minimum a little monitor and the ability to peek and poke around on the address bus. Probably most people here will "yell" at me - for not using pure assembler

But while I have some 35 years experience in c-programming, my assembler is pretty thin - and because days might pass between some time developing code, I would quickly forget my plans and start again. So c it is, and I came down with 4 alternatives

a) x86-to-6502 translator by Lefticus (https://github.com/lefticus/x86-to-6502/) - I really like the idea, modern compiler optimizations are really good .... but it failed to translate my simple monitor program. Tried it with a dozen different compilers, but no luck. As Lefticus writes correctly, that program is more of a case study then a full developed translator.
b) WDC c-compiler - I had so high hopes for it, but again it failed the basic test. Crushed with a memory error on my simple code piece. So not an option either
c) CC65 - the first one to actually compile the program.
d) gcc 6502 port found here https://github.com/itszor/gcc-6502-bits - also passed the basic test. And produced smaller code (1100 vs 1600 bytes). So for the moment this will be my plan to use in my first iteration of the monitor.

_________________
No simulation survives contact with reality!

There's a gcc port found here too, formerly known as puppeh's but now itszor's:
https://github.com/itszor

That's what I'm going to use - I fixed the URL in my post. You have to use https://github.com/itszor/gcc-6502-bits, not https://github.com/itszor/gcc-6502. The later is the port, but cannot be compiled directly. gcc-6502-bits compiled without issues on Cygwin with a gcc 7, and provides tinylibc as well.

One problem - it has support for BCC, c64 and the "integrated" semi65x simulator - but self build systems are a different topic altogether. It also uses the cc65 linker (ld65), which means I'm banging my head now against the ld65 .cfg file (for memory layout). Does anyone know a good howto on the topic? The original documentation is a bit ... cumbersome. I prefer explanations along simple examples

_________________
No simulation survives contact with reality!

Two steps back, one step forward ....

So I wrote a simple monitor program in C with a bit of assembler startup code. Naturally your first attempt does not produce anything, so for debugging I went looking for a simulator and was very happy to find https://github.com/sethm/symon, because it also simulates a 6551 chip! Then I run into a problem with understanding the assembler code that my toolchain (6502-gcc and ld65) produced. So I wrote a small python program that combines the annotated assembly produced by the gcc with the actual addresses created by the linker. That would result in something like

for a simple c-code:

Honestly, I had to swallow hard when I saw the overhead c created. Still I started to debug away, found a couple of minor errors in logic (for instance the compiler had optimized away "unnecessary" loops), until I hit a wall. Possibly I'm too stupid...but no matter what I did, the program simply did not echo back the characetrs I sent over serial. The c-code I thought was pretty straightforward:

but the compiler gave me was

So a character is received in $8800 (ACIA data port), stored in _r0 aka $0004, the subroutine returns, loads _r0 into the ACC, compares with $0d, jumps to L@35, then loads 1 into ACC and stores it into _r0 before echoing the character back? Do I understand that right??? (I think I do, I pondered over that for 2 hours....)

So I abandoned gcc at that point. I seemed easier to start learning 6502 assembly for real
3 days later I had a working monitor, that can display and modify memory locations. So back to the hardware now to layout my first parts of the VGA card!

_________________
No simulation survives contact with reality!