VGA Space invaders on bluepill

Im trying to get https://www.artekit.eu/space-invaders-for-stm32/ working on bluepill but im failing

I have just make small code fix to get it compile on atollic studio, but at first I was getting message that I have to little RAM, but on original project CPU has same amount of ram as bluepill 20K…

So I have just tried to put smaller screen size, but then it hangs while clearing screen in simple loop.

If someone want to tryout to debug here is code for atollic…

Edited:
Fixed problem with fb array that I made by copy pasting …

Perhaps the RAM issue is a compiler or linker option issue

instructionFailes.png (10.76 KiB) Viewed 568 times

I think I got it.

fb was defined two times and that is why code was to big.
and I made mistake while copy pasting from mbed and defined fb as single dimensional array, and it needs to be two dimensional (that was crashing code)…

I will test it after on VGA and put code on git if all is working…

space2.jpg (35.42 KiB) Viewed 539 times

Very nice! .. Is your code posted anywhere?

You posted also the elf binary! Great!

wow…

So much fun stuff is going on at the moment.

Thanks Goran…

+1 cool thanks!

Did you use a voltage divider on the Green Video signal? From what I read the range seems to be 0-> 0.7v?

No, I have just used direct connection, like on original site…

https://www.artekit.eu/space-invaders-for-stm32/

But here resistors are suggested …

https://www.seanet.com/~karllunt/S4DVGA.html

Afik, R, G, B inputs are 75ohm and 0.7V max, others are 5V TTL..
Most probably there is real 75ohm (the 75ohm resistor) at the RGB inputs wired against Gnd.

I suspect that the VGA signal is being somewhat “overcooked”, however most VGA monitors will put up with this, as they generally will have clamping circuitry on the inputs to protect them by clamping to a maximum of 0.7V, or whatever the input stage of the monitor will easily withstand. Since we are only driving them to 3v3, this is probably safely within the power dissipation capabilities of any protection.

More hints here.
https://en.wikipedia.org/wiki/Video_Graphics_Array

If you want shades of grey in your VGA (or shades of green in this case), then you would need to use multiple pins and a voltage ladder, and keep the total voltage of the signal levels within the correct range.

In summary, since we are only doing 1 bit per pixel video, then on/off is all we need, however the video signal is not actually within spec. rather it is probably within safe limits in most cases.

You could put a 100K pot between the VGA output pin and ground, and take the wiper pin to the monitor to give you a brightness control. Uses screened cable, and be aware you may introduce reflections/ghosting in the image if the cable is unscreened, or too long. You could also feed the signal to the red and green pins via other similar pots to allow you to choose pretty much any other single colour you like..

v dodgey istr w is contrast or is it a threshold level ?
stephen

ahull wrote:You could put a 100K pot between the VGA output pin and ground, and take the wiper pin to the monitor to give you a brightness control. Uses screened cable, and be aware you may introduce reflections/ghosting in the image if the cable is unscreened, or too long.

As I wrote above there is a 75ohm resistor against ground wired at RGB inputs (inside the VGA monitor).
Thus a 470ohm resistor at the MCU output will create a voltage divider 470 / 75ohm = 0.137. That gives you max 0.7V at 5V.
A 270ohm / 75 ohm gives you 0.217 * 3.3V = 0.71 max at 3.3V.
With STM32 you must use 270ohm resistor from mcu pin to VGA connector at R/G/B inputs.
@ahull: a 100k potentiometer will not work.

Pito wrote:As I wrote above there is a 75ohm resistor against ground wired at RGB inputs (inside the VGA monitor).
So a 470ohm resistor at the MCU output will create a voltage divider 470 / 75ohm = 0.137. That gives you 0.7V at 5V.
A 270ohm / 75 ohm gives you 0.217 * 3.3V = 0.71 max at 3.3V.

Pito wrote:As I wrote above there is a 75ohm resistor against ground wired at RGB inputs (inside the VGA monitor).
So a 470ohm resistor at the MCU output will create a voltage divider 470 / 75ohm = 0.137. That gives you 0.7V at 5V.
A 270ohm / 75 ohm gives you 0.217 * 3.3V = 0.71 max at 3.3V.

I’m going with the inline 270 ohm based on what I know about the post by the msp430 author and your confirmation Pito. : )
That is the right approach
If the stm32 connected directly the pin’s output current would be 3.3V/75ohm = 44mA at least, that is off the spec, sure.

The pot to ground will work, but it risks over driving the output, so adding a 270 Ohm inline resistor, or putting a smaller value pot inline with the 270 ohm resistor rather than to ground will probably work better. Suck it and see, but be aware that some older CRT based VGA monitors (non multisync), may not like any of this, as the sync signals may not be 100% stable. Most modern monitors are much more robust in this respect, and dont care (or at least dont blow up), so proceed with caution if you are playing with some rare early IBM antique.

4 bit Colour… ? OK That way madness lies

Have an ancient Acorn Atom schematic instead. This is how the original 6845/6847 based video boards pushed out the pixels..

We are spoiled by all these $3 LCDs.

The guys generate a multicolor VGA with 80MHz pic32mx, so it must work with STM32F4 too

http://encyclopedia2.thefreedictionary.com/RGBW

seems it allows variation of the white intensity
srp

One of the reasons I mentioned the humble 6847, is that it managed 128 × 192 4 bit colour (or color if you prefer) graphics using a mere 6K of ram. Most colour graphics processors use high speed DACs to drive the colour output, but if you are dealing with relatively low resolution and low colour depth, then it may be possible to use DMA and a crude resistor ladder DAC to generate relatively simple VGA colour. Something along these lines.
http://quinndunki.com/blondihacks/?p=955

Or we could be really authentic and just use rainbow coloured cellophane

BTW the 6847 datasheet does go in to some detail about the circuitry of the luminance ladder and a great deal of detail about the timing and so forth needed to produce its analog colour component signals.

.. another reason I mentioned the 6847 and posted the Atom schematic is that the Acorn Atom (as a self assembly kit) was the first computer I actually owned (as distinct from the many I had played with up till that point), so I have a bit of a soft spot for it, and am pretty familiar with its quirks and design. It was by no means the most quirky design around, there were many others. https://en.wikipedia.org/wiki/List_of_h … o_hardware

Fore reference about color VGA, this due project provides vga output with color:
https://hackaday.io/project/9383-pacman … 41-and-vga

Looking at the files, it does so using several pins for each code with different divider resistor values:
https://github.com/DrNCXCortex/Pacman-A … master.ino

victor_pv wrote:Fore reference about color VGA, this due project provides vga output with color:
https://hackaday.io/project/9383-pacman … 41-and-vga

Looking at the files, it does so using several pins for each code with different divider resistor values:
https://github.com/DrNCXCortex/Pacman-A … master.ino

Blue

but I found others that look different where blue sensitivity is not so bad

(LOL) thanks

So… RGB 332 would be the best way to pack colour in 8 bits. (I think the video systems I worked on, years ago, were possibly 16 bit colour as I don’t think the numbers of bits were 322, more like 664)

found a useful article
http://lslwww.epfl.ch/pages/teaching/co … es/VGA.pdf
-A VGA video signal contains 5 active signals:
• horizontal sync: digital signal, used for synchronisation of the video
• vertical sync: digital signal, used for synchronisation of the video
• red (R): analog signal (0-0.7 v), used to control the color
• green (G): analog signal (0-0.7 v), used to control the color
• blue (B): analog signal (0-0.7 v), used to control the color

blue pill / maple mini do not have a DAC, but those STM32F407VE/ZE series have them, just that i’m not too sure if the built-in DAC is fast enough to generate all the RGB signals to do full color vga rendering
in addition a full color rendering 640x480x24 bits(3 bytes) would take a whopping 921k of screen buffer memory– The video signal must redraw the entire screen 60 times per second to provide for motion in the image and to reduce flicker: this period is called the refresh rate. Refresh rates higher than 60 Hz are used in PC monitors
– In 640 by 480-pixel mode, with a 60 Hz refresh rate, this is approximately 40 ns per pixel. A 25 MHz clock has a period of 40 ns

F407VE/ZE it seemed has only 2 channels for DAC outputs, i’m not too sure if that could be multiplexed
it would seem 40ns may be pretty difficult to do on stm’s f4 dac as well

perhaps pair up stm32f1 or better f4 with a hi speed parallel dac and additional ram? but the specs seem to say that video circuits tend to be specialised and dedicated rather than use generic mcu parts e.g. dac, dma etc. or perhaps pair up multiple stm32f1 to do it, but dac would still be a problem to get 640x480x24 bits color x 60 hz

perhaps instead of full color VGA what seem possible may be ‘1-bit’ colors i.e. feed ‘digital 0.7v or zero’ into the vga analog pins, but that’d need to run at 25mhz (40ns per bit), i’m not too sure if it is possible to hack 2 bits or 3 bits colors at those speeds
even with 1 bit of each color R, G, B, my thoughts are that that would give 8 different color combinations that way

@ag123

I think you missunderstood.
This thread is not about replicating a complete VGA display system, its just that a Blue Pill can be turned into a 8 colour Space Invaders game, outputting straight to a VGA monitor..

Quite an achievement for a general purpose $2 board.

yup this would fit the ‘1-bit’ colors or rather 8 colors scenario the binary combination of each color signal R, G, B would give 8 color combinations
at 3 bits per pixel, 640x480x3/8 ~ 115,200 bytes for the screen buffer
my thoughts are that this seem ‘easier’ on an f407 chip with a good amount of sram. i’m not too sure if ccm ram which do not do dma could be used for that
the other way is to compute each pixel and draw it directly without the screen buffer ram, my guess is it may be somewhat ‘more difficult’

these days with lcd monitors, i’m not too sure if we’d need to run refresh at 60hz, in the sense that the lcd monitor would possibly ‘remember’ that dot we draw on the display after all. hence all that ‘refresh’ is after all ’emulated’, we can then run at much lower pixel rates (less than 25mhz) without compromising display quality

this may be a ‘big deal’ in a sense if stm32 could simply output on vga (lcd) monitors, no need for ili9341 and all those etc
the crt types could still be tough to do due to the 25mhz pixel rates at 60hz refresh

I’ve not looked at the STM32 code, but if the processor is spending most of its time generating the frame, there’s not much time left to do the game logic and update the frame buffer (if it has a frame buffer)

I recall these old systems used to do tricks like do the game code computation during the horizontal and vertical frame flyback periods. I forget how long each of these are, as its a bit before my time

But I really appreciate how hard the designers used to have to work to get every last ounce of processing power out of what are now seen as exceedingly show processors, with very limited RAM, and not that much ROM.

i’m thinking with $2 for each BP/MM it may even be possible to say hook up 2 pieces of it say via spi and one of the bluepill can be dedicated in managing the vga display. so we have a BP/MM running as a ‘VGA card’ and the other could do dedicated game logic, etc. this would allow 1 BP/MM to use most of its limited 20k ram (and possibly less) to do the vga display

f4 should most likely be able to ‘do it alone’ & would likely be able to manage 640×480 resolutions. i think on f4 APB2 can run at 84 mhz and APB1 runs at 42mhz it would likely be able to handle the 25mhz pixel rates, just that i’m not sure if say we bit bang at 21mhz (42/2) if that may cause any issues with the video timings etc

If you leverage DMA to spit out the buffer, you take a big load of the cpu. That way the code can be a bit more complex than if the cpu is grinding out the bits at the same time as moving the sprites. You *can* sort of do graphics and code at the same time on an 8 bit CPU, take a look at the ZX80 and ZX81 – though it did have some other logic glue, there wasn’t much.

… and yes.. it could play space invaders … in a rather blocky, monochrome, snowy, jumpy manner…

Say 400x200pixels, 8bits per pixel (256 colors), 4x 2bit R2R VGA DAC.
You need 80kB video buffer, which fits inside F407.
You get maybe 50us to shoot out 400pixels or bytes. That is 125ns per pixel. That is an 8MHz byte stream off the gpio.
ZX80/81: The ZX81 did not use pixels resolution, but 8×8 fixed chunks generated off ROM char gen, afik (I owned one..).
Basic setup got 1kB of ram, inclusive video

From what I recall the ZX80 could not maintain the video output while any code was running.

I think that even when typing in the code, that the screen could blink ( but I may be wrong on that front)

I had one when I was at highschool.

The ZX81 was better, as it could maintain video output and run code, but I dont recall what the difference was. Presumably the Zx81 had some sort of dedicated video output dma system.

No DMA or even double buffering on the ZX80, just lots of 74 series magic.

As a result, the TV picture was at the mercy of various other systems, if you loaded from tape, you got snow. If you didn’t stick to very strict timings in the code, snow.. etc.

In ZX81 they put the TTLs into the ULA chip. So ZX81 (I got a kit) was about 5 chips (Z80, ULA, 2×2114 sram, Rom).
The most important parts in ZX80/81/Spectrum – the R4-R11 resistors in the data bus They isolated Z80+mems from other subsystems when busy.. The Z80 had automatic refresh cycle for drams, that was used somehow too..

At least it is possible to emulate a ZX81 with an Atmega644p which directly creates the b/w VGA signal without any additional hardware.

Pito wrote:Say 400x200pixels, 8bits per pixel (256 colors), 4x 2bit R2R VGA DAC.
You need 80kB video buffer, which fits inside F407.
You get maybe 50us to shoot out 400pixels or bytes. That is 125ns per pixel. That is an 8MHz byte stream off the gpio.
ZX80/81: The ZX81 did not use pixels resolution, but 8×8 fixed chunks generated off ROM char gen, afik (I owned one..).
Basic setup got 1kB of ram, inclusive video

When the ROM character generator would be used you must be able to address and read out the Flash during sending the pixels out. That may cost a lot of time with BP. The advantage of this approach is you need a single byte for 8×8 pixels, thus for 400x200pixels the video ram would be 1250bytes (50×25). Not good for graphics as you know from today (lines, circles etc primitives), however. Worked with ZX81 and space invaders fine