[WORKING] Simple 6502 SBC from scratch (Deck65)

[and3rson]

GARTHWILSON wrote:

and3rson wrote:

Garth - your LCD ASM examples were very helpful!

Thanks; but you might need to take a closer look.  These LCDs do work reliably if you do it the way I show there.  I've done it this way with many different LCD sizes and manufacturers, and they have always worked 100%, even reset after reset, re-initialization after re-initialization, etc..  I never have any trouble with them.

Just double-checked my build - I think it was due to either lousy jumper connections or some timings that I've recently tweaked. My LCD is now working consistently across resets & power cycles!

[and3rson]

So PS/2 took me some time, but I'm really surprised how easy it was to implement, including make/break/extended scancode handling as well as shifted characters. My biggest mistake was forgetting to terminate my functions with `rts` and wondering why weird code is being called.

Also, some WDC instructions are totally awesome, including SMBx, RMBx, & STZ. ROR seems to work properly with shifting the carry bit in - I heard some myths about "bug" with it, maybe it's only relevant for some ancient 6502 NMOS revisions.

I think my PS/2 bit handling code could be slightly improving by juggling with VIA's shift register after start bit was received, but I decided to keep it simple and read all 11 bits in a bit-banging style.

Now I'll be able to do some interaction with my device. Probably the most helpful commands that I'll implement first will be reading/writing memory locations - that's gonna heavily reduce the amount of EPROM flashes!
Finally, having LOAD command to run arbitrary code from ROM or SD card in C64 format (i. e. binary that's prefixed with little-endian address specifying where to load the code) will be nice, especially for playing SID songs. I'll try to keep my code @ github updated at all times.

EDIT: I've considered an option of porting one of small BASIC variants (e. g. TinyBASIC, since it's free for non-commercial use), but decided to stick with a simple 1-character-command terminal for now:

[ttlworks]

Nice progress so far, I'm impressed.

In the long run, that LCD will be a bit too small for your computer.

But generating a video signal was a topic we had quite a few times here in the forum,
either by using a microcontroller, a CPLD, or "a handful" of TTL chips.
//The TTL approach tends to be too big for a beginner's project.

Looking forward to watching the progress of your project.

[and3rson]

ttlworks wrote:

Nice progress so far, I'm impressed.

In the long run, that LCD will be a bit too small for your computer.

But generating a video signal was a topic we had quite a few times here in the forum,
either by using a microcontroller, a CPLD, or "a handful" of TTL chips.
//The TTL approach tends to be too big for a beginner's project.

Looking forward to watching the progress of your project.

Thank you!

Yes, I've been thinking about video a lot. And yes - I think I read nearly all existing topics on video solutions here! Ideally, I'd want to achieve it with some constraints:
- FPGA: I wouldn't want anything in my SBC that could replace the entire SBC itself. Yes, with FPGA I can get nice video and a nice board, but It almost feels like cheating!
- VIC chip: this would totally be cheating!

Those constraints were pretty much inspired by original David Murray's vision of a "perfect" 8-bit machine, and while his X16 team decided to go with FPGA for video to make their system richer as a commercial device, I still don't want to dive into FPGAs. Yes, they provide huge possibilities and allow to implement all logic in a single chip, but it just doesn't feel "oldschool" enough. I even almost ditched the idea of using GAL22V10 for address decoder at some point because I felt like it was "too simple". (Well, I still ditched it in favor or NANDs, but I might still use it for my future versions.)

Some serious (and esoteric) options:
- As you mentioned - discrete logic: Having a simple video like Apple-1 made purely of basic components would be really fun, but I'm afraid it might end up being really big (and complex!). But that's a totally viable option, I could even design in a PC-card style and plug it into my main SBC. Though this would mean my SBC is no longer a SBC, but a DBC!
- Second 6502 & DMA: It would be interesting to have a separate 6502 solely to render video. Instead of DMA, second 6502 could have its own RAM and some glue logic to sync it with primary data bus.
- *Heresy alert!!!* - Z80: I never actually developed for it, but I own several Speccies (originals as well as few clones from soviet era). Would be fun to try and make it lean under 6502's control and handle video rendering, just for the sake of it.
- Some exotic "video"-interfaces: a printer? A matrix of nixie tubes with shift registers? (Damn, that's gonna cost a fortune.) Etch-a-sketch with two stepper motors?

But really, my main fetish is composite video. I always liked it - I grew up with it, it had a nice round connector and always worked with no effort whatsoever. And all the artifacts like noise & jailbars just add to the atmosphere. I suck at analog electronics, but a possibility of generating composite video signal makes me want to learn it better!

[Michael]

Not sure if this would be of any interest to you, but, I used a $5 Pi Zero and a fork of the PiGFX "bare metal" VT-100 Terminal Emulator software on one of my projects which produced HDMI and composite video output (I only ever tried HDMI video). I've attached a DipTrace file with the proper hole dimensions and outline for a Pi Zero if you'd like to take a peek. Geoff Graham's ASCII Video Terminal also produces composite (and VGA) video output.

[barnacle]

and3rson wrote:

Yes, I've been thinking about video a lot. And yes - I think I read nearly all existing topics on video solutions here! Ideally, I'd want to achieve it with some constraints:
- FPGA: I wouldn't want anything in my SBC that could replace the entire SBC itself. Yes, with FPGA I can get nice video and a nice board, but It almost feels like cheating!
- VIC chip: this would totally be cheating!

A man after my own heart. I'm currently playing with discrete video generator designs; I have one untested which uses the 1.8... UART crystal to generate a 640x480 VGA output with a text only output (but you don't get 640 pixels across a line ) and I'm now looking at an 800x600 SVGA to give a monochrome pixel addressable output (at 40MHz) which after flirting with the dangers of generating clock signals with combinational logic looks like a dozen chips to generate the timing and ram addressing signals. It fits in with my paged ram described elsewhere and uses five 16k pages (each line uses one hundred bytes of a 128 byte chunk to simplify the counters).

Neil

[ttlworks]

and3rson wrote:

Yes, I've been thinking about video a lot.

Because it would simplify debugging a lot.

and3rson wrote:

- VIC chip: this would totally be cheating!

Aha, so EF9345 would be cheating, too. //PDF page 14
Same thing for EF9367 and TMS9918.

and3rson wrote:

Some serious (and esoteric) options:
- As you mentioned - discrete logic: Having a simple video like Apple-1 made purely of basic components would be really fun, but I'm afraid it might end up being really big (and complex!).
But that's a totally viable option, I could even design in a PC-card style and plug it into my main SBC. Though this would mean my SBC is no longer a SBC, but a DBC!

That's right.
My solution was to make the TTL CRT controller a separate unit, running with its own clock, mirroring 6502 write cycles into its own display RAM.
So that the SBC doesn't need to be changed, and is able to work without the CRT controller being attached to it.

and3rson wrote:

- Second 6502 & DMA: It would be interesting to have a separate 6502 solely to render video.
Instead of DMA, second 6502 could have its own RAM and some glue logic to sync it with primary data bus.

Either that, or two 6502 CPUs sharing the same RAM chip.
Hmm... looks like Mouser doesn't have IDT dual port RAMs anymore, and I don't have any practical experience with that W65C02 BE pin...

and3rson wrote:

- *Heresy alert!!!* - Z80: I never actually developed for it, but I own several Speccies (originals as well as few clones from soviet era).
Would be fun to try and make it lean under 6502's control and handle video rendering, just for the sake of it.

Yes, this would be more fun than just adding a microcontroller to a 6502 system for video signal generation...

and3rson wrote:

- Some exotic "video"-interfaces: a printer? A matrix of nixie tubes with shift registers? (Damn, that's gonna cost a fortune.) Etch-a-sketch with two stepper motors?

elm-chan Laser projector, or dot flippers ?
"oscilloscope vector display" probably would be boring, because there are a lot of oscilloscope clock projects in the internet...

and3rson wrote:

But really, my main fetish is composite video. I always liked it - I grew up with it, it had a nice round connector and always worked with no effort whatsoever.
And all the artifacts like noise & jailbars just add to the atmosphere. I suck at analog electronics, but a possibility of generating composite video signal makes me want to learn it better!

As long as you don't want to use/display colors, genenerating a composite video signal isn't "rocket science".

[drogon]

ttlworks wrote:

As long as you don't want to use/display colors, genenerating a composite video signal isn't "rocket science".

Rocket science is easy - Rocket Engineering... Now that's properly hard to get right ...

However, on the composite video front - I started with that for the Ruby Board - my intention was to use the board 'host' processor to do it - an ATmega 1280p and it worked well and I had 320x240 pixel display, so 40 columns x 30 lines of 8x8 font text, or pixel graphics....

It worked well. The down-side was it was using some 60-70% of all CPU cycles in the ATmega so I moved to plan B.

However while I don't think you need to go quite as deep as the transistor level in the Pong document above, doing it in TTL is do-able...

The down-side and another reason I gave up on composite video... At the time I was thinking of offering it as a kit, but just how many people still have a TV or monitor that will accept composite video? A few, but not many now...

-Gordon

[Michael]

drogon wrote:

... how many people still have a TV or monitor that will accept composite video? A few, but not many now...

I agree, Gordon. My TV has a composite input but they've all but disappeared on new TV sets.

I've got a couple of these little 4.3" monitors that sync' on either PAL or NTSC and work well. Basically just an inexpensive TFT display and PAL/NTSC adapter stuffed into a nice plastic case. I've also heard you can modify the display for 5 volt operation instead of 12 volts.

Cheerful regards...

[Dr Jefyll]

ttlworks wrote:

and3rson wrote:

- Second 6502 & DMA: It would be interesting to have a separate 6502 solely to render video.
Instead of DMA, second 6502 could have its own RAM and some glue logic to sync it with primary data bus.

Either that, or two 6502 CPUs sharing the same RAM chip.

It's intriguing to contemplate a single RAM array shared by two CPUs (one of them primarily for video).

and3rson, you and others may enjoy such an implementation from many years ago (back when 64K was so... much... RAM... you'd obviously be forced to go with DRAM, because who's got room for thirty-two SRAM chips!). Single Board Computer using dual 6809's

Yes it's 6809, but 68xx family bus cycles are the same as 65xx's. Also, as Dieter hints, the BE input featured by modern 65xx CPUs might be something that could be used to advantage in a modern, 65xx dual-CPU, shared-RAM design...

-- Jeff

[ttlworks]

drogon wrote:

However while I don't think you need to go quite as deep as the transistor level in the Pong document above, doing it in TTL is do-able...

Having tinkered with transistor logic long time ago, I found the transistor circuitry in that Pong document quite impressive.
On the other hand, I just remembered that we happen to have a dissection of the NES PPU in the forum... //for PAL and NTSC video output.

Michael wrote:

My TV has a composite input but they've all but disappeared on new TV sets.

Dang.

I wasn't aware that the composite video input on modern TV sets went the way of the Dodo.
Looks like SCART on new TV sets also went extinct.

Hmm... rolling your own DVI/HDMI interface might be possible,
but I'm not sure if it's a good idea.

[drogon]

I wasn't aware that the composite video input on modern TV sets went the way of the Dodo.
Looks like SCART on new TV sets also went extinct.

Hmm... rolling your own DVI/HDMI interface might be possible,
but I'm not sure if it's a good idea.

Here in the UK there is no analog terrestrial TV broadcast anymore. It's been digital for some time now, so finding an old TV for the old Channel 36 outputs from old computers is a little problematic...

Other than 2 old monitors I use for Apple II's the only thing left I have is an old portable TV that has video/scart and a now redundant TV input...

Those little reversing camera monitors are popular though.

-Gordon

[ttlworks]

drogon wrote:

Here in the UK there is no analog terrestrial TV broadcast anymore.

Same thing here in Germany.
So trying to build RF modulators (like they were in some old computers) won't make sense.

Hmm... it's a pity that 320*240 monochrome graphic LCDs without a LCD controller already integrated became pretty exotic.
Because my TTL CRT controller was able to generate an analog video signal while working as a LCD controller...

;---

Jeff, that block diagram of the dual 6809 computer looks nice.

In 6502 computers, sometimes the 6502 (during PHI2=HIGH) and a CRT controller (during PHI2=LOW) had shared the bus.
In theory, it might be possible to build something where two 6502 CPUs are sharing the bus.
Clock generation and correct timing might become a bit tricky, of course.

[barnacle]

It's getting harder to find cheap LCD screens that accept other than HDMI now, too, though I still have one. It offends my sense of aesthetics to stick a raspberry pi or similar on the board just to get video output (ignoring the size of the ram required!) so I'll carry on with the 74xxx SVGA, thanks!

Pal or NTSC is essentially trivial even if you grow the circuitry from scratch and the only real issue with VGA or SVGA is that if you want to share memory with the processor, you end up with a dot clock of 25.5MHz or 40MHz and that implies an easy system clock of 3 and a bit or 5MHz or a multiple thereof.

Though to be fair, once you get to those resolutions, you're starting to have to look beyond a simple bitmap font (though I'm not convinced that a 6502 could handle a truetype font with any great facility!). Nonetheless, I shall persevere!

Neil

[Dr Jefyll]

ttlworks wrote:

Jeff, that block diagram of the dual 6809 computer looks nice.

Thanks, Dieter.

Quote:

In 6502 computers, sometimes the 6502 (during PHI2=HIGH) and a CRT controller (during PHI2=LOW) had shared the bus.
In theory, it might be possible to build something where two 6502 CPUs are sharing the bus.

Yup. Sharing between two CPU's is scarcely any more complex than sharing between a CPU and a CRT controller.

Quote:

Clock generation and correct timing might become a bit tricky, of course.

Yes and no. When two devices use alternate clock phases to "take turns" accessing shared RAM one does need to pay attention to how it's done. But a CPU sharing with a CRT controller is much the same as a CPU sharing with another CPU.

Bottom line: you mustn't allow the RAM's /WE input to go low immediately when one device's turn ends and the other device's turn begins. There needs to be a bit of delay (address setup time) before /WE is allowed to go low. And familiar designs using a CPU and a CRT controller already successfully manage this.

-- Jeff