We're doing similar things, library-wise :)

[marciot]

I came across this project from a comment on Hackaday. I've just recently made a similar library, also borrowing code from ESP32_8_BIT, but instead of using AdaFruit's graphics API, I am using Bitluni's graphics API which has a few cool extras features like being able to render 3D meshes.

Maybe there is a possibility to collaborate or at least share ideas about how to simplify the underlying rendering code, which is fairly hard to understand. Anyhow, here is a link to my library if you are interested in seeing it:

https://github.com/marciot/ESP32CompositeColorVideo

[marciot]

A few differences between your library and mine:

• You seem to be using the base code from the Sega emulator, which gives a 256 by 240 framebuffer with rgb332 colors.
• I am using the base code from the Atari emulator, with a 336 by 240 framebuffer with the Atari color palette that uses hue + luminance.
• You are using the AdaFruit GFX library, while I use Bitluni's GFX library
• You library seems to support animated gifs (cool!) while bitluni's library is supporting 3D meshes

[Roger-random]

Neat!

I have no objections to collaboration, we just have to figure out something that makes sense.

Let me share a few notes from my side:

• Higher pixel resolution of Atari mode would be nice, there is already have a request for >= 320 pixel width. Screen size larger than 256 pixels? #14
• I never got Atari mode to work in ESP_8_BIT. It failed to allocate a large piece of contiguous memory for the frame buffer. Looking over memory statistics on my ESP32 running a bare ESP-IDF Hello World project, there does not exist a large enough block for the allocation at all. Somehow my bare ESP32 has more fragmented memory than yours (and rossumurs, etc) and I haven't figured out why that is.
• With only Sega and NES emulators remaining at my disposal, I chose Sega for its more colorful RGB332 256-color palette rather than the 64-color palette of NES.
• In addition to my ESP_8_BIT_GFX the Adafruit GFX-compatible library, I also expose as-raw-as-I-can library as ESP_8_Bit_composite for access to the raw frame buffer. I'm confident Bitluni's 3D mesh library can also be built on top of ESP_8_BIT_composite as it just needs a raw frame buffer.

For reference, what I see in the serial debug output when I try to run in Atari mode:

MALLOC32 235820 free, 113792 biggest, allocating Screen_atari:92160
MALLOC32 allocation of Screen_atari:92160 3FFE4374
MALLOC32 143644 free, 64864 biggest, allocating MEMORY_mem:65540
MALLOC32 FAILED allocation of MEMORY_mem:65540!!!!####################

[marciot]

@Roger-random: The funny thing is I never actually ran ESP_8_BIT before borrowing the code for my own library, so I cannot comment on whether the Atari emulator works unmodified on my module.

One thing to consider is that the Atari framebuffer is actually 384 x 240 pixels in the emulator. ESP_8_BIT allocates the whole framebuffer and then the NTSC/PAL routine only shows the central 336 x 240 pixels. This means that about 12% is being wasted. While it allocated just fine for me with the full framebuffer, I later modified the PAL/NTSC code to read a 336 x 240 framebuffer without all that wasted space.

As an aside, that optimization had an interesting effect that threw me a curveball: The original code asks to allocate the framebuffer in IRAM, but the originally sized framebuffer does not fit there, so it was being allocated in DRAM instead. I didn't know this (or even, at the time, about the different types of RAM on the ESP32). But once I shrunk the frame buffer to get rid of the dead space, my code went from running to crashing, which totally puzzled me. To make a long story short, the newly trimmed framebuffer was just small enough to fit in IRAM, which has the special limitation of only being accessible in 32-bit chunks, whereas I was trying to write to it in 8-bit chunks!

Right now, I have everything stored in DRAM, although I suppose it would still be possible to store the palette and line pointer array in IRAM (I should do that, to be honest).

Anyhow, I would recommend you try compiling and running my ESP32 Dali Clock. If it runs, then we would at least know your board was capable of allocating the entire framebuffer. Once we know that, maybe we can narrowing down what is fragmenting your memory.

[marciot]

Oh, there is one more difference that might be relevant. Rossum's library allocates the memory in individual lines and maintains an array of pointers to each line. It turns out that this is compatible with the way the ESP_8_BIT video out routine works, so I was able to use that without much modification. I wonder if I will run out of memory if I try to allocate two contiguous buffers.

[Roger-random]

I think it'll be interesting to try running your Dali clock on my board to see what's going on. However it'll be some time before I can do so as I've moved on to other projects: my current workbench configuration has no room for the composite TV I had used before.

I want to understand the Atari memory behavior before I attempt converting my library to use it. I want to be able to explain to people who have problem running it on their ESP32. I don't want to say 'Um, don't know, sorry" which is where I am now. I understand the array-of-line pointers system, specifically the SEGA application of it, well enough to modify the memory allocation routine to allocate 4kb segments. Because of this change (#3) I am now confident my library will gracefully deal with even highly fragmented memory spaces.

---

I forgot to mention on item earlier: I chose Adafruit's GFX library because there is A LOT of available sample code for that library. (As is typical of Adafruit and much-appreciated.)

[marciot]

I think you made a smart choice by using the AdaFruit library.

Anyhow, I am digging through the code for the emulators and am trying to get a handle for what it would take to modify your library to use the higher resolutions.

A couple thoughts:

• For your library to work with the higher Atari resolution, the Atari code would need to be modified to use a RGB332 color palette, as this is what the AdaFruit library expects.
• At first blush, you would think you could simply lift the color tables from the SEGA emulator and drop them into the Atari framebuffer code, but this is not so (I just tried)
• The SEGA emulator uses a different horizontal resolution than the Atari emulator and this varies the ratio of pixels per NTSC/PAL color clocks, which means the tables are incompatible.
• So, in order to generate a RGB332 palette for the Atari resolution, one would need to generate new tables

Fortunately, I managed to find the code used to generate the Atari tables here:

https://github.com/rossumur/esp_8_bit/blob/c65fa1e70e3a981abb9f232ef481fcf0a42eab0a/src/emu_atari800.cpp#L47

I suspect it won't be very hard to modify, so I will try to modify it to spit out RGB332 tables. This would be useful for my library as well, as I think offering RGB colors is useful.

A second issue that might be relevant to your users is that cranking up the horizontal resolution comes with a trade-off of artifact colors. While it looks like the SEGA does have some artifact colors, the Atari in particular exhibits the purple/green artifacting which I think is in many ways worse than the SEGA.

So, there isn't a ideal resolution in NTSC. It's all a balancing act.

[Roger-random]

Yikes, I hadn't known artifact colors were worse on Atari path since I never got that running. Thanks for the link on artifact colors, that was very educational.

When I started learning about NTSC, I came across a joke claiming the acronym stood for Never The Same Color. This source also claimed PAL had better color rendering, but I think the difference is minor (if at all) compared to the bigger picture: analog composite video (either NTSC or PAL) completely pale in comparison to modern digital video.

I doubt anyone playing with analog video today expects accurate colors.

[marciot]

@Roger-random: I started a wiki page listing all the various projects that use the ESP chips to generate video. Mostly this is my attempt to categorize the techniques and peripherals used so that maybe I can learn about them a little bit better. I thought you might be interested in taking a look:

https://github.com/marciot/ESP32CompositeColorVideo/wiki/A-survey-of-signal-generation-on-the-ESP32

Feel free to suggest projects I haven't looked at yet.