1
\$\begingroup\$

I'm thinking about making a project like this one and add a graphics card like that one. Using an EEPROM for the video memory and changing its content setting it in write mode and assigning a value for every pixel that need to be change. The problem is that the CPU will run at a very slow frequency, so the change will require some time and in this interval the monitor will show nothing (if I will disconnect the output signal during writing) or constant color lines depending of the value that is being changed (if I will leave the output connected).

Is there a way to "freeze" the image on the monitor during this operation? Or are there better solutions?

Till now my last idea was to use two EEPROM with the same content and change the value in one memory while reading the data from the other, then read from the first memory while writing the same data in the second one (flipping the roles of the two EEPROM); but it seem extremely inefficient to me.

PS: I didn't find any documentation for freezing the image using simply the VGA lines.

EDITS:

  • I was thinking to use ROM so that I can preload a fixed background and change fewer pixels while running (to save time and memory)
  • This will be just for fun, without any real practical use, so I didn't think a lot about the frequency, but I can imagine from few Hz (while debugging or for demo purpose) to few kHz, while the "video clock" will probably be 10 MHz, so write in precise, small and synchronized intervals is not a easy task, I think.
\$\endgroup\$
3
  • 2
    \$\begingroup\$ EEPROM sounds terribly slow/an odd choice for this application. Would SRAM not be a better choice for video memory? \$\endgroup\$ Commented Aug 5, 2020 at 10:07
  • 1
    \$\begingroup\$ That's not how VGA works. Really this project does not make much sense. If you really want to build at this level, use an FPGA. Otherwise generate output to a serial terminal or use a command-based LCD or OLED with its own memory. \$\endgroup\$ Commented Aug 5, 2020 at 11:29
  • 1
    \$\begingroup\$ dual ported ram would make the design simple, but also expensive, \$\endgroup\$ Commented Aug 5, 2020 at 11:50

2 Answers 2

2
\$\begingroup\$

Using an EEPROM for the video memory

.. why? (Is this a self-imposed restriction, a parts availability issue, or part of some grander scheme to achieve some other purpose in the design?)

As you've spotted, you can't freeze the image; you have to continously generate the VGA signal. You could take a copy of the image in RAM, but presumably there is a reason why your design is allergic to RAM?

The normal solution to using single-port memory without corrupting the displayed image is to only do writing in the vertical blanking interval. That does limit your write bandwidth, but depending on how many pixels are on the screen it may be sufficient.

An intermediate solution might be to have a small amount of video RAM which is character-mapped rather than pixel-mapped, and use the EEPROM for character generation. Same VBLANK suggestion applies.

\$\endgroup\$
1
  • \$\begingroup\$ I think I will try to write during the VBLANK time as you suggested, maybe buffering the data in a register before the copy in the memory. Thanks \$\endgroup\$
    – Paa
    Commented Aug 6, 2020 at 20:20
2
\$\begingroup\$

VGA provides no way to freeze the image, VGA is analogue signals intended to drive a CRT display, if you turn of the drive to CRT the picture disappears.

The Ben Eater project is basically a CRTC (CRT controller) interfaced with a ROM.

Dual ported ram is one possible solution, but at about $1 per kilobyte it's fairly expensive.

There might be a way to interleave CRTC and bus access to the ram. this means putting the processor into a hold state if it tries to access the RAM while the CRT controller is using it, or synchronizing with the CPU clock cycle so that CRTC and CPU access are interleaved.

Most commercially produced 8-bit computers used some variant of this.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.