6502 or Z80 as VGA controller

[Bill Shen]

I posted two topics today both showing Z80 and 6502 running at 25.175MHz.  It takes fast RAM and real W65C02 to run at 25MHz, but CMOS Z80, even the fake ones from eBay, 10 for $10, are generally capable of 25.175MHz operation.  25.175MHz is not just about speed, but because it is the dot clock of the standard 60Hz 640x480 VGA.  If you can find a set of instructions in 6502 to push a byte out to a pixel shift register every 8 clocks (or 2 bytes in 16 clocks for Z80), then they can serve as VGA controller and still have 10% leftover throughput during the vertical retrace period to do something.  That's effectively a 2 MHz 6502 or Z80, just as fast as the early hobby computers.

This is my recent work on adding a VGA controller to CRC65+prototype which is a 25MHz 6502.  It turns out a modest CPLD with 64 macrocells (EPM7064S or ATF1504) can be a VGA controller yet retain the CF interface and a serial port.  I even believe it can also have PS2 keyboard interface.  This opens the door for very simple standalone computer with 640x480 VGA graphic and PS2 keyboard and performance of early hobby computers.  I believe similarly standalone computer is possible with Z...@25.175MHz.
  Bill

[Stefan V. Pantazi]

Hi Bill,

 

Fascinated by this. I thought a CPLD alone was enough for a graphics subsystem for retro-computers. I realize now I was thinking small. So here I am, puzzling over your post. I am wondering if I am way off thinking about this as graphics-co-processors that, with the appropriate software and communication mechanism to a main processor board, could be programmed to take care of complex graphics tasks (GUI windowing systems, moving sprites around, collision detection, gfx etc) while the main processor does the other useful things?  That opens a whole new realm of parallel processing possibilities and of course complexity. 

Stefan

 

[Bill Shen]

Depending on resolution and color depth, graphic can take enormous amount of computation power or relatively little.  Retro processors are probably limited to VGA (640x480) class of display under its direct control or with some help of CPLD.  For higher resolution, the graphic work are generally offload to high power graphic chip, FPGA, or any number of inexpensive but powerful processors, like PiZero, but becoming mysterious blackbox in the process.  I'm mostly interested in hobbyist level of graphic display that I can construct and full understand.  Of course it is of limited capability; monochrome VGA or one bit of RGB color is about all I can do.
  Bill

[Andrew Lynch]

Hi

In the pre-IBM PC days, that was accomplished with the NEC uPD7220 Graphics Display Controller or TI's TMS34010 graphics coprocessor.  

Possibly Yamaha V9938/V9958 Video Display Processor to some extent (very popular in MSX).  

Then IBM CGA/MDA/EGA/VGA came along and wiped out most of the alternative graphics processor market.

Over the years, I've been experimenting with a retro uPD7220 board in various incarnations.  Getting ready to try again as a duodyne board in the not-too-distant future.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/retro-comp/a3b35dff-4da7-4f62-a1cd-b70fe203e525n%40googlegroups.com

.

[Alan Cox]

On Tue, 16 Jan 2024 at 04:12, Bill Shen <coinst...@gmail.com> wrote:
>
> Depending on resolution and color depth, graphic can take enormous amount of computation power or relatively little. Retro processors are probably limited to VGA (640x480) class of display under its direct control or with some help of CPLD. For higher resolution, the graphic work are generally offload to high power graphic chip, FPGA, or any number of inexpensive but powerful processors, like PiZero, but becoming mysterious blackbox in the process. I'm mostly interested in hobbyist level of graphic display that I can construct and full understand. Of course it is of limited capability; monochrome VGA or one bit of RGB color is about all I can do.

The Apple IIe had a usable desktop on 65C02 despite the weird display
layout and other fun. The C128 had an even more brain dead high
resolution display and also sort of managed it (with a lot of smoke
and mirrors) in GEOS.

Swapping the 65C02 for a 65C816 would give markedly better graphics
performance as you can now do 16bit operations and 16bit pointer
operations without all the zero page stuff, and you can also move zero
page so you can place it in your video whilst doing fast manipulation
in a given area. The 816 is all round quite a speed boost if you run
it in 16bit mode.

Scrolling in particular sucks when you try and do 640x480 mono with
low end hardware, but at 25MHz it shouldn't be quite so bad.


Alan

[Alan Cox]

On Tue, 16 Jan 2024 at 11:06, 'Andrew Lynch' via retro-comp
<retro...@googlegroups.com> wrote:
>
> Hi
> In the pre-IBM PC days, that was accomplished with the NEC uPD7220 Graphics Display Controller or TI's TMS34010 graphics coprocessor.
>
> Possibly Yamaha V9938/V9958 Video Display Processor to some extent (very popular in MSX).
>
> Then IBM CGA/MDA/EGA/VGA came along and wiped out most of the alternative graphics processor market.

I'm not sure that's the whole story. What killed a lot of it was that
every workstation, game console and "gaming" home computer (Amiga etc)
integrated their own video with different degrees of accelerator, or
in the Apple case a lot of very very tight hand tuned assembler
graphics ops.

The 9938/58 is actually probably a better accelerator for what we
think of as GUI acceleration today than the 7220 as it has hardware
blits, off screen blits and can do accelerated font expansion and
rendering from a font in offscreen buffers. It's got no Alpha blend
but that aside it has most of the pieces of a conventional "modern" 2D
UI.


Alan

[Bill Shen]

There were a number of graphic chips to go with retro computers.  They are generally lower resolution with composite video output.  VGA was introduced late 80's with IBM PS/2, by then graphic devices were mostly fine pitch SMT and 3.3V and unobtainium.  Graphic also became complex and more blackbox-like.  For my own education, I want to know how graphic works and want to work with digital VGA rather than analog composite.  Perhaps a more modern name for the topic is "software-defined graphic with 6502 or Z80", i.e., using Z80 or 6502 operating at video frequency and drive the video output with software.  I don't know what Z80 or 6502 can do as a graphic processor, but one requirement is the clear understanding of graphic functions.  I know 6502 can manage 640x480 monochrome and I suspect Z80 can as well.  Some graphic functions like scrolling become very simple when it is done in software--it is a matter of defining where in memory corresponds to beginning of a video frame.  Other functions like text fonts become more flexible but more difficult to do in software.  What about blits. zoom, blending?  I don't know but lets find out.  can it becomes a graphic coprocessor under the control of main processor? yes, 6502 is particularly well suited for dual processor architecture.  There are quite a number of interesting topics to explore.
  Bill

[Stefan V. Pantazi]

 Hi Bill,

 

It is definitely interesting to think of the flexibility of having fully programmable co-processors (graphics, audio), that can be programmed in familiar ASM languages, compared is what seems to be the usual way to access a set of fast but limited functions on dedicated video processors where one has to write to this register, read from that register, in order to make it do their accelerated hardware things. Of course, having multiple processors (main plus video co-processor) opens the complexity of having either synchronize them or make them communicate asynchronously. I think this is where your explorations with Dual port SRAM may be worth revisiting, not necessarily only as VRAM, but also as a method of asynchronous communication between processors. From what I read, that is exactly the use-case described for such devices. I may be off mark regarding the complexity of all this, but the dreaming has officially started for me... Thank you for the inspiration.

Stefan

[Alan Cox]

The joy of the 6800 bus (and thus also 6502/C816) is that the CPU has
a clear half cycle it owns and a half cycle it doesn't.

There is some (quite some) fun in getting all the clocking right but
these processors were always built to share the bus and from fairly
early on things like 6845 were designed to pair with it running on the
other half of the cycle whilst doing the video and DRAM refresh (which
done right is a side effect of the video fetch). The later 6847
follows a similar mode with the 6809 even having a two chip set (6809E
and SAM) that did all the memory sharing, refresh, CPU interface and
video feed to a 6847.

The Tandy MC10 is a fairly easy to understand schematic for this and
explanation in the service manual, although it's a bit more complex
than a 6502 based solution as the 6803 has a 4x clock input and the
board has to synchronize the 6847 and 6803 clocks as well as generate
an early drop for \WR (so devices see the write ending before the bus
address switches to the video). The PET is another good example but a
lot of the parts don't have the standard 74xx/40xx numbering due to
their age which does make it harder to decipher.

The 6545 and later 6845 can also do VGA 640x480 mono although you need
16bit wide RAM access on the video side. As the 6845 just generates
all the decode and timing it doesn't care how many bits you shovel
into a shift register each fetch. 16 is enough for 640x480 at the
clock rates the 6845 supports. It does make 8bit CPU interfacing a bit
trickier.

8080/8086/Z80 based systems don't have the same timing behaviour so
the rest of the board logic has to handle it. Some older systems
ignored it (eg VZ200, PC CGA), some halted the CPU during writes to
video RAM in video periods, others (eg the ZX Spectrum) use wait
states to generate a steady video fetch gap. Finally of course some
people just solved it by getting the video RAM off the CPU bus (MSX
etc)

While the Spectrum ULA is a bit of a closed book the
re-implementations of it in TTL logic are not - for example the
Pentagon, the Harlequin etc.

Alan

[Andrew Lynch]

Hi

What made the SY6545 special is it could be accessed as an IO device with it's own separate video memory space.  No shared memory with the CPU and all the associated complexities.  6545 is a good pairing for Z80 style computers.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/CAK9X0%2BvUcoPJqrze%3DZCUSDa-MNY0rauYaZLZx_4by_5BEruMXA%40mail.gmail.com.

[c f]

I had a fun time seeing how far I could push the SY6545 in the Kaypro 2/84 to try to play video on it: http://www.chrisfenton.com/exploring-kaypro-video-performance/

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/154579269.1306001.1705420040244%40mail.yahoo.com.

[Bill Shen]

This is an example of 6502 as VGA controller playing animated video stored in CF disk.  There are about 70 frames of 192x144 pictures extracted from the sword play scene of BadApple video.  They are stored in the CF disk as a contiguous file so I don't have to deal with a file system.  2 sectors of data (1024 bytes) are read from CF disk every 1.5mS vertical retrace period, so the effective transfer rate is 60KB/sec.  The video rate is about 18 frames/sec.  Only the 192x144 frame is updated every vertical retrace, the rest of 640x480, including the texts are static.  The texts are generated with 8x16 fonts.
  Bill

[Bill Shen]

This topic started off as VGA controller based on 6502 or Z80, but in the case of 6502, it is increasingly clear that it can be more than a VGA controller; this is evolving into a barebone standalone computer with VGA, keyboard, serial port, and mass storage capabilities.  I have build another modified 25MHz CRC65 but added an external flip flop to free up one more CPLD pin so I can has 2nd bank of 48K RAM and PS2 keyboard interface.  The 31.5KHz horizontal interrupt service has enough spare capacity to sample PS2 keyboard input then process it during the vertical retrace period.

This demonstrate data entry with PS2 keyboard.  One of the key input it checked is 'Esc' key which toggled the streaming of video from CF disk as mentioned in previous post. PS2 processing is quick, but video display of 1KB data from CF disk to video memory every frame took most of the available throughput.

6502 only has time to do general processing during the 1.4mS vertical retrace every 16.7mS video frame, so time is of the essence.  To monitor the available time, I added bar graphs on the upper right corner of the display,  Vertical retrace is 45 horizontal sync periods, so a horizontal bar can display up to 45 horizontal pixels where each pixel represents a horizontal sync period.  The heavy vertical bar at edge of screen marked the boundary of 45 horizontal pixels.

For this demo, I added 30 bars as histograms of past 30 vertical retrace activities.  The most current activity is the bottom bar and it scrolled up so the top bar is histogram of oldest activity (500mS ago).  While it made a neat dancing graph, the 30-bar algorithm consumes about 5 horizontal sync periods as evident by the 5-pixel thick base such that 6502 barely had enough time to process keyboard and video.  You may've noticed the screen flickered when typing on keyboard while video is active which is an indication of vertical retrace tasks spilled into active video displaying.  Normally a 3-bar histogram is sufficient to monitor performance.
  Bill

[Bill Shen]

Picture of the board for video demonstration above.

[Stefan V. Pantazi]

Hi Bill,

I for one remain fascinated and inspired by these posts. Your VGA graphics controller is evolving nicely into a graphics terminal and mass storage (IDE) controller. For sake of completeness (I mostly jest, but why not), I think some sort of sound output may be worth squeezing in especially given the spare processing available. A beep (1 bit some output port you may have as a spare) would do, but your badapple demo begs for the chiptune rendition of the original soundtrack played through a Turbo Sound device (dual 6 channel AY). There are a few great ones on the zxart.ee website in pt3 tracker format. And, naturally, I keep thinking about the dual port SRAM as a method of rapid communication with another processor but I am unsure of the hidden technical complexity of implementing such.

Keep up the good work!

Stefan

[Bill Shen]

Oh good, I'm glad you like these posts.  I tried to keep it down because this group is mostly Zx80.  Most of my 6502 posts are on 6502.org.  I am making progress with scrolling function today, so with scrolling, PS2 input, and row selection, the available throughput in the video back porch time slot is down to 10 clocks.  At most I can do is a 'beep' every 31.5KHz at most.  Sound is my weakness--my lab is deathly quite because I'm easily distracted by sound.  I imagine I need a dedicated sound processing, but I have not look into it.

Here is a scrolling demo by manipulating the starting address of the video memory.  Yep, this starts to look like a monochrome graphic terminal.

I'm done with 6502 for a while, I need to go help someone developing a 68040 workstation.
  Bill

[Bill Shen]

Made more progress with VGA65.  This is rev0 of VGA65 pc board in 2 layer, 100mmX100mm.  It is basically a CRC65 board but with VGA and PS2 connectors incorporated.  So it is now a minimal standalone 6502 computer, but with some prototype area for experimentation.
 
Software-wise, it has a basic monitor taking input from PS2 keyboard and output monochrome texts to VGA.  I included the BadApple demo to demonstrate its graphic capability.  While the monitor program is very simple, it is rather challenging to write mainly because 6502 spent 90% of its time painting the VGA screen, so monitor functions are performed only during the vertical retrace period.  This is a graphic display where texts need to be rendered from 8x15 fonts, so there are not enough time to complete a monitor command in one vertical retrace period.  There are only enough time to scroll the screen and display one new line, so even the 'help' command needs four vertical retraces to complete.  I created the 15-bar display at the right of the screen to display how much vertical retrace time was used for a task.  A real time scheduler would be helpful for programming VGA65.

Ironically, it can display graphic image much faster.  The BadApple demo is stored in CF disk; it can be retrieved from CF disk and displayed on screen as 192x144 video at 17 frames a second.

Instead of capturing VGA screen with a video camera, I bought a VGA capture device and recorded the VGA output to my computer directly which has better resolution, but I can't adjust the intensity and screen, so the image is dim and there are noises at the bottom of screen that's normally adjusted out with physical monitor
  Bill

[Bill Shen]

Picture of rev0 VGA65 pc board

[Tom Storey]

On Mon, 29 Jan 2024, 04:34 Bill Shen, <coinst...@gmail.com> wrote:

Oh good, I'm glad you like these posts.  I tried to keep it down because this group is mostly Zx80. 

The group is called retro-comp, so as far as I am concerned anything retro goes. :-)

The mere prevalence of one topic shouldn't preclude any others.

[Stefan V. Pantazi]

Very interesting and inspiring! I think you are progressing nicely toward quite a flexible display, keyboard and storage solution. I think the prototyping area begs for a dual port SRAM that can be shared between this controller and separate CPU and RAM modules through a RC-type bus but I am sure it won't be easy given the tight timings of the controller. If it were possible, maybe most monitor components should execute in other CPU and RAM modules and interact with this display, keyboard and storage controller not only through exchange of data and simple commands (e.g., load from storage, draw on screen, vertical scroll)  but also by updating its code to change its behaviour on the fly. Thank you for the work!

Stefan