Returning to this topic because I've learned a few tricks in the last few years and it is slowly dawned on me that I can trade speed for hardware complexity. W65C02 can run reliably at 25MHz so it is time to take advantage of that capability to reduce the complexity of hardware.

In my first attempt with VGA beam racing, I wanted a capable serial port but had to sacrifice the CF function to fit the logic in the small CPLD. The idea now is to simplify the serial function to the simplest bit-bang implementation and keep the CF function. In fact, the plan is to expand the memory to 2 banks and find a way to have PS2 keyboard function as well. I can have it all if I keep it simple but paid with degraded performance and more memory.

Enough about ideas, here is what's possible: CF interface, 640x480 VGA, bit-bang 115200N82 serial and possible PS2 keyboard. The modifications to the existing CRC65 is minimum, most of the changes are in the CPLD which is 77% utilized and there is one spare pin to drive 2nd bank of memory.

It still takes 90% of CPU and 40K memory to paint the 640x480 screen. Swapping in 2nd bank of 40K should alleviate the memory shortage. I have to work with the remaining 10% of 25MHz 6502, or a 2.5MHz 6502.

CF can supply the graphic files instead of uploading them serially. I'm exploring different fonts right now. It seems to me 30 rows, 80 columns of 8x16 fonts is a good fit.
Bill

Looks really good! It's cool to see you running this at 25 MHz, wow! And having a 2.5 MHz equivalent CPU as 'left over' is still plenty fast to run additional software.

So what are your future plans with this now?

Chad

I still have one spare pin and 20-25% spare logic in CPLD. I'm thinking of 2nd 56K memory bank with 8K of common area. I also want to add a PS2 keyboard but I'm out of I/O pins so I may share it with the serial port with a toggle switch which is pretty crude. CPLD has 4 JTAG I/O pins that can serve as user I/O, but I had not tried that ever, because the CPLD can't be reprogrammed anymore. However, GlennSmith recently posted an excellent write-up about restoring JTAG functions. I need to investigate that--still learning about CPLD after 30 years!

I have a very similar 25MHz Z80/RAM/CPLD board, so it also occurs to me I can beam race Z80 as well. In fact, I can design one pc board that accommodate both 25MHz Z80 and 6502 similar to BB6580, except it can do graphic.

Software-wise, I have a monitor already, but I am following your path of editor then high level language, probably Forth. Lots of projects to keep me off the street!
Bill

The follow-on from the BBC Micro, the BBC Master had 128KB of RAM - the original 32K of main RAM the rest (shadow RAM) being accessed in different ways.... In normal. BBC Micro compatible mode, the shadow RAM was disabled and video came from the main RAM - variable size, depending on the video mode from 1KB (teletex text) to 20KB (640x256x1).

When you picked a screen mode +128, it then used 20KB of the shadow RAM for the video RAM, so user programs had all the 32KB (minus the usual OS overhead).

So - you're following on in the footsteps of others here!

The down-side is, as usual, the number of cycles needed to manipulate all that 40KB of RAM - if you can change the top-line start address in hardware and arrange the video generator to wrap then you can have super fast scrolling though - so scrolling a line just means clearing the (new) bottom line which ought to be relatively quick.

Clearing the screen, even with line-start lookup tables will still be a bit slow - the lines being 640 pixels or 80 bytes wide and 480 lines deep... There was a lot of loop unrolling in the BBC Micros OS to do that.

Is there any way to do the odd/even cycle thing so the 6502 can carry on running at full speed? I'd guess the RAM must already be fast enough due to the 6502s half cycle access mechanism, but could the CPLD work with it?

Cheers,

-Gordon

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

Beam racing is around for long time, so this exercise is to further my understandings of video generation. It is more about trade-off than anything new. What's amazing to me is how early designs managed with 2-MHz 6502. No doubt, lots of hardware were involved. My thought is to reduce hardware complexity at the cost of software burden and more memory. My first boss used to beat me up over every little physical components--IC, resistors, even screws, but seemed not concerned about software complexity, probably because he didn't understand software at all. I'm becoming my first boss in my old age.

Scolling is exactly as you've described, a matter of defining where in video RAM correspond to the top of the physical screen. I can even do a sexy, smooth scroll by scrolling one line of pixels at a time.

By paging in 2nd bank of RAM I can ping-pong images between two banks. So I can work on 2nd screen of image while the first screen is being displayed. This way the slowness of screen update may not be as visually impactful. I'm undecided about the common/bank split, whether it is 16K/48K or 8K/56K. It is done in CPLD so I can change my mind later.

CPLD can certainly take over the bus during the low half of PHI2 clock in Apple II fashion. I had a color video design like that but can only run 12.6MHz. I'll need to review it why I stopped working, may be there is a new inspiration waiting now.
Bill

I read this recent topic "Displaying an ASCII spiral in 6502". I want to try that on the 6502 VGA controller. I started out with random video contents in $4000-$ef00, then I start from the center of the screen, spirally fill it with incrementing values translated into 8x15 fonts; then spirally erased it starting from the center; and then spirally filled it again with different values. This is all done during the vertical retrace period. The program is slowed down to about 1/4 speed so the spiral filling can clearly be seen. I'm please to see that 2MHz equivalent 6502 is reasonably quick even for graphic applications.
Bill

I must admit I am curious to see how well my 2.5MHz cpu will handle writing text to a pixel-addressed 15k(ish) memory space - 384 by 300 pixels to give 48 by 20 lines of text. Also to see how it fares against a 32MHz ARM which can DMA the video directly, but only in blanking (6us line blanking, 740us field blanking).

Neil

Are you using 8x15 fonts? which one? I got my fonts from https://github.com/viler-int10h/vga-text-mode-fonts I'm vacillating between standard.F14 or standard.f16. For ease of calculation, I want to fit 80 characters in 15 pixel rows so characters use 8x15 fonts. Standard.f14 already has generous space all around so it looks sparse with another blank row of pixel; I truncate one row of standard.f16 to fit. It looks nice and large, but somewhat crowded.
Bill

I'm using ARMSCII8.F14 from, I think, the same place. But displaying an empty line between them. I believe that it does go down to use the fourteenth line (but maybe just the thirteenth) on descenders. The rationale is to reduce storage space for the font table, which lives in RAM, but may be redundant if I let the STM do all the video drawing including text. I also only intent to provide a character set from 0x20 to 0x7f, for now. I'm not feeling international at the moment, after a week or two of fighting German bureaucracy.

Neil

That GitHub page is a great repository of fonts.

I may use 8x14 fonts after all because it has room for thick underscore to indicate the cursor position. I'm using $0-$7F fonts where $0-$1F serve as nice diagnostic uses; it also can be redefined for different applications.
Bill

I have a nasty tendency of juggling too many balls, so I'll document what I've done before it got dropped. The VGA65Rev1 design is based on CRC65 with slight pcb modifications to add a VGA connector. The modifications are repurposing the 2-wire I2C interface plus address-11 for VGA's VSync, HSync, and pixel outputs. The pixel output drives VGA's R/G/B inputs through 330 ohms resistors. HSync output is also tied to 6502's interrupt.

CPLD design changes are more radical, but the design actually becomes simpler. It is designed in schematic and easy to understand. The hardware serial receiver is replaced with bit-bang serial receive to free up resources for VGA logic. VGA logic is a shift register that loads data in address ranges $4000-$EFFF; a HSync generator that's a modulo-800 counter and assert HSync for 100 clocks every 800 clocks. HSync is connected to 6502's interrupt and also suppresses the pixel generator output when active. The latest addition is a semi-automatic VSync generator that's triggered by software at the end of active 640x480 scan. This frees up software from counting HSync and generating VSync during the vertical retrace period. The VSync generator also has a modulo-45 counter output that's readable by software to see how much time is left.

The "displaying an ASCII spiral" software is a good template for VGA controller software. It loads standard.F16 fonts in memory $800-$FFF. The main program set up HSync interrupt handler and initialize some common variables then sit in an endless WAI loop waiting for 31.5KHz HSync interrupts. Interrupt handler is splitted into active displaying of 640x480 video from memory $4000-$EFFF or vertical retrace phase where task can be processed without worrying about every 31.5KHz interrupt. There is a 3-second delay before any video activities because my VGA monitor takes about 2 seconds of stable video signals to turn on the display.

Homepage for VGA65 prototype rev1:
https://www.retrobrewcomputers.org/doku ... 65:vga65r1
Bill

I'm exploring what can be done during the 1.5ms vertical retrace period of every 16.6ms video frame. The processor is being interrupted by the 31.5KHz horizontal sync so it is more efficient to do work inside the interrupt service. However, I need to measure how much time is available to do a task, so to budget enough slice of time to do the work. That involves quite a bit of trial and error. I found out I can set up the CF to read 2 sectors (1024 bytes) of data and read the data to display memory during next vertical retrace period and then setup CF for 2 sectors again. So effectively I can read 1KB of CF data every vertical retrace or 60KB per second. A bit of calculation shows it can stream 192x144 monochrome video at 18 frames a second without data compression.

This video clip shows the sword-play sequence of BadApple near real time (real time is 20 frames/sec) at about 18 frames/sec. The resolution is 192x144. Data is stored in CF as one contiguous block so I don't have to deal with a file system.
Bill

Built up another CRC65_prototype modified as a VGA controller. I managed to find another spare I/O pin by externally derive compact flash chip select using a 7474 flip flop. So now I have enough pin for PS2 keyboard as well as 2nd 44K memory bank ($4000-$EFFF). This is a barebone standalone 25MHz 6502 computer with serial port, CF interface, PS2 keyboard, and 640x480 monochrome VGA. It is not a pampered hardware with I/O data nicely formatted and presented to it on a silver platter; it has to bit bang serial, PS2, and chase VGA beam to display data on screen. The poor thing is working 90% all the time just to keep up with the regular housekeeping functions dealing with display and basic I/O.

Currently it can serially load and run programs via TeraTerm and display image on VGA display with data from memory or CF disk. I'm testing the PS2 keyboard function now. My immediate plan is a monitor that receives input from keyboard and displays it on VGA. I want to find out what it can do with the 10% of leftover throughput.
Bill

But it's doing it so well!

How do you access that CF disk? It is parallel correct? Do you use the CPLD, or is there some other method through the 6502? I went through your schematics and CPLD pdf and didn't find anything specific to that. Am I just missing something?

Looks good! Keep it up!

Chad

The CF interface was in the original CRC65 design. It is basically 8-bit parallel data interface with 3 addresses. CPLD generates the CF select, CF read, and CF write. You probably can generate the equivalent control signals using VIA although it may be slower. My CF design is memory mapped with 4 wait states; CF itself is capable of tens of megabyte/sec transfer, but without DMA and with 6502 only active 10% of the time, 100KB/sec is likely the limit. In my BadApple demonstration, it is sustaining 60K/sec transfer of video data.

Replacing the CF select with discrete flipflop is likely temporary in order to try out PS2 function. In the finished design, I'm likely to sacrifice one address line to eliminate the external flipflop. I am able to combine PS2 and serial port in 3 CPLD I/O pins; it looks like I'll be able to sample PS2 input with spare capacity in the 31.5KHz horizontal sync interrupts so bit-bang PS2 is not too costly in this particular implementation.
Bill