More educated attempt at my VGA question

[rstofer]

I am looking at the VGA ignal my uVGAIII board is putting out. Eveything seems in line with what I've been reading. At 640x480, all timings are as I expected

Except one... The pulse width of the V sync is half what I read it should be. Everywhere I look, it says it should be 60 or so milliseconds wide, but the Vsync on my uVGA board is 31 milliseconds. Eery other thing (Hsync, porches, times bewteen pulses, ect.) is as I expected.

My understanding is that a vertical refresh is triggered by the down going edge of the Vsync pulse. Am I to infer, that within reason, the actual pulse width is not that important? Or is there something else at play with the uVGA's signal. I only ask because i'm starting to get a hold of this business, and this anomaly is bugging me!

Typo...  63.6 microseconds for vertical pulse width.  I have no idea why uVGA would use something different.  I would stick with the numbers.

[rstofer]

Consider the traditional set of operations supported by a bitBLT routine, and also note that when rendering text with an 8 pixel wide font, one will be incrementing to the next scanline to paint each row of the character far more often than incrementing within a scanline.  If using different width fonts, it gets to be an unholy mess of incrementing within a scanline and incrementing by scanline.  Adding hardware support for offloading managing the video RAM access pointer from the CPU when it isn't just a simple autoincrement is *DIFFICULT*.

It may be preferable to map a small window onto the graphics RAM into the main CPU memory map.  4K would probably be an appropriate size, as that would allow 32 scanlines (assuming 80 bytes/line at 128 byte increments) to be accessible in the memory window at the same time, which would make for easy scrolling of text of up to 16 pixels height.   Again for convenience, either a 4 bit adder would be used to combine the low bits of the window base register with bits A8 to A11 of the CPU address bus so that the window start could be set to any even scanline, or it would actually be divided into two 2K windows with independent base registers.

However I still prefer the idea of a slave processor handling the graphics, and a ring buffer in shared memory to feed it text, control codes and graphics commands.

All of the above is correct.  Think about how you would draw a diagonal line using my registers method.  Ugly!

However, I'm loathe to give up memory space in the CPU.  There is never enough RAM.  Mapping 4k for graphics is just too much to lose.  Plus there will be some amount of code for the driver.

So, is there some way to map the graphics in and out of the address space?  I'm thinking in CP/M terms where my BIOS resides at the top of memory.  If my graphics handler is in BIOS (and it could be) then I can map out any part of the CPU ram below the BIOS entry point.  But a graphics handler might be quite a bit of code and that would make the BIOS too large.  So, the second question is, can I map the handler in and out of memory space.  I don't see why not.  I could keep the BIOS small and remap everything below the BIOS entry point.  Just simple paging, really.  The BIOS would remap memory, call the handler and when the handler returns, the BIOS would map the normal CPU memory back in.

For monochrome, the entire 640x480 page will map in 38400 bytes so there is plenty of room left for the driver.

It's going to take time to do the paging so it better be worth it.  In other words, there should be fairly high level commands that do complex kinds of things (draw a circle or draw a box) rather than just setting a single pixel on every swap.  Pretty soon you have reinvented the graphics card.  It might be worth reviewing Pascal Turbo Graphics to see which commands are useful.

http://www.math.uni-leipzig.de/pool/tuts/FreePascal/units/node9.html

I would still have external logic accessing the graphics memory for display purposes.

In the end, this will be far beyond the capabilities of the period.

[BrianHG]

You can cheat a little with this chip:
https://www.digikey.ca/product-detail/en/idt-integrated-device-technology-inc/7132LA100PDG/800-3389-ND/5456363
Use it as your video memory, on the second side, tie the address's to your display H&V counters, with the V counter's LSB and the data out feeding a large EPROM's address containing a full color font, or, a second one of these dual port rams where you can program a 1 bit font into it with a serial bit select to hold a 256 character 8x8 font.

[Ian.M]

Hmm . . . . IDT7132LA High Speed 2K x 8 Dual Port Static RAM.
That's going to get real expensive real fast if you want to do more than a 80x25 mono text display.   OTOH it would be a rather nice buffer to communicate between a main CPU and a slave display processor, and could simplify the logic considerably.

[BrianHG]

OTOH it would be a rather nice buffer to communicate between a main CPU and a slave display processor, and could simplify the logic considerably.

Hence, the OT didn't want PLD/PAL/FPGA/MCUs, and wanted to breadboard this, that IDT chip with each read/write port all in a DIP, all separate lines on each side, would really simplify things.  I would go with 1 chip, suck up the 13$ as it would save soooo much debugging time & use an eprom containing my fixed multiple fonts.  I would use some upper address's on a register latch to select from 2-4 different character sets of 256 & wire 6 of the output bits to 3x2bit resistor dividers for RGB shaded color as large above 128k eproms are dirt cheap.

[rstofer]

Hmm . . . . IDT7132LA High Speed 2K x 8 Dual Port Static RAM.
That's going to get real expensive real fast if you want to do more than a 80x25 mono text display.   OTOH it would be a rather nice buffer to communicate between a main CPU and a slave display processor, and could simplify the logic considerably.

Apparently there are master devices and slave devices.  The master device (IDT7132LA) is a couple of dollars more than the slave device (IDT7142LA) because it has the arbitrarion logic.

There will still need to be logic to deal with the BUSY condition on both sides.

[BrianHG]

Hmm . . . . IDT7132LA High Speed 2K x 8 Dual Port Static RAM.
That's going to get real expensive real fast if you want to do more than a 80x25 mono text display.   OTOH it would be a rather nice buffer to communicate between a main CPU and a slave display processor, and could simplify the logic considerably.

Apparently there are master devices and slave devices.  The master device (IDT7132LA) is a couple of dollars more than the slave device (IDT7142LA) because it has the arbitrarion logic.

There will still need to be logic to deal with the BUSY condition on both sides.

Nope, a 5 MHZ cpu cycle write once every other clock is just slow and if you read the fine print, the data on the read side during a BUSY will just hold the last contents of that memory cell if a write on one side is at the same address as the read on the other side.  In other words, since one side always reads, you can ignore the busy signal all together.

The busy is important when interfacing between 2 CPUs with read/writes on each side and you want to guarantee the new data of a collision at the same moment both sides read and write to the same location, or, ensure 2 simultaneous writes on each side goes to the same location doesn't conflict.  These issues can be ignored in a display memory where one side is exclusively read only...

[Ian.M]

.... and even for a dual port memory between two CPUs, if the software is correctly designed e.g. with queues implemented as ring buffers,  the critical head and tail pointers are each only written to by ONE CPU, so again, no special BUSY handling circuits are needed.

[ale500]

I know you are against programmable logic but 14 $ plus VAT for a puny 2 kBytes SRAM is wasted money. A small FPGA like a Max10 with 2 K LUTS can give you dual ported RAM for far less money... or a MachXO2 for like 6-7$.

I don't remember who posted the Apple 2 Book in the other thread, but it is a very good read, specially well described is how to do video output using alternating clock phases. You need many muxes and clocks and so on. It is a discrete implementation after all.

Maybe you quest for the best video generator in terms of logic utilization, coolness factor or easiness of build contradict the point of the exercise: get the video going. One can improve (maybe) later on.

What exactly do you want ? remember that you 6502 can only address 64 kBytes at once.
- Text output ?
- Graphics ?

It doesn't matter, the point is how do you access video memory. Odd/Even phases are a good idea. Delayed writes are another, you can also duplicate the RAM and write to both RAMs but read only from non-video RAM then your video generator  can run asynchronous from the main processor, a kind of Dual ported RAM on the cheap.

You could also use another processor to generate the video signal. For instance, a couple of times I used a parallax Propeller (it has 32 kBytes of internal shared RAM and 8 RISC cores, one for video and the others to service your write request and other things). It needs buffers for 5->3.3 V, but it works and it is a 2 chip+crystal (5 MHz) solution. Can give you many text modes and graphic modes. But it is kind of cheating .

I have 3 retro projects that stopped on the how do I do video ?. I think that a FPGA is an acceptable solution, but I don't have the optimal board... but I have nothing against a Propeller doing the video output.

Look here for a 68k+Propeller that I did some years ago (I would use a couple of 74LVC245s today instead of resistors):
Video output is 256x256 with 8 colors or 512x256 with 4 colors in a 640x480 mode, if I remember correctly:

https://github.com/rosco-pc/propeller-wiki/wiki/pPropQL