A gamebuino "emulator" ?

[Deneth]

I was thinking about something different : when you generate a new frame, you make 50/50 merge with the previous one an you display the result. Do you get what I mean?

I think so, but the problem is what is a "frame". There are two threads running - one with the AVR simulator, including a simulated LCD display. Periodically (once every computer monitor refresh, I think) the LCD memory gets copied into a framebuffer, then displayed on the screen. If these refresh rates don't match - I read on these forums that about 44Hz is a good rate for grey, vs 60 Hz for your monitor - you'll get the flickering. Also, the LCD doesn't really have a fixed refresh rate (maybe internally it does, but you don't get any control over that), it just updates when you write to part of its memory.

Maybe the actual fading times for the LCD itself needs to be simulated. Being a passive LCD screen (not a TFT screen). there would be a noticeable fade in/fade out when you turn pixels on and off. This could be considered when handling LCD writes.

I don't know how you managed to get a working emulator so fast....

I guess I did the easy bit - the hard stuff came from simavr! That's also why it's a bit slow, but it's just fast enough for most computers these days. (I tried adding debugging support, but it runs at about 50% speed! I haven't made a Windows build with this yet.)

[ripper121]

Debugging sounds great, so the speed of 50% for debugging is ok

[Myndale]

Also, the LCD doesn't really have a fixed refresh rate (maybe internally it does, but you don't get any control over that), it just updates when you write to part of its memory.

I agree, simulating the LCD to any degree of accuracy is going to be extremely difficult without an intricate understanding of the 5110 controller circuitry. We know from the data sheet that the MUX rate is 1:40 (although I pegged it closer to 1:41 with the internal oscillator), but you'd need to know the exact nature of how the refresh is done, details about the optical properties of the cells and the internal capacitance of the drive circuits. And then of course there's that problem of aliasing with the emulator refresh rate.

I've been doing a little research into this over the past couple of weekends and I've managed to add acceptable (IMO) grey scale support to the emulator I've been working on:

greyscale.png (2.95 KiB) Viewed 6638 times

What I did was integrate the value of each pixel over two frames and apply a low-pass filter. Since my emulator also updates at 60fps that's equivalent to 3 frames at the LCD update rate, so aliasing is minimized and you also get a little persistence-type effect for free. I actually use a sliding window, so a new frame is rendered each 1/60th of a second and contains the average integrated pixel values for the 1/30th of a second leading up to it. The final step is to apply tri-level quantization to simulate the display's low contrast.

So that's what I'm doing. Very simple, but even with animation it seems to be working well.

[rodot]

Hurray for Myndale, every time you come on the forum it's with some very good news
Let's hope next time you'll announce you have sound on your emulator
When do you plan to release your emulator?
Keep up the great work!

[Drakker]

Great job Myndale, thanks for all your efforts. You're like Rodot's super brilliant sidekick. =)

[rodot]

The new version of the library doesn't seem to work with Deneth's emulator, the display remains blank

[DFX2KX]

The new version of the library doesn't seem to work with Deneth's emulator, the display remains blank

I was about ready to upgrade too, glad I stopped back on the forums before getting back to my game. I'da thought it was me that did something XD

Even still, having ways to test this stuff has been a Godsend for learning's sake.

[rodot]

The new version of the library doesn't seem to work with Deneth's emulator, the display remains blank

That's because I forgot to comment out a few "Serial.print" I used for debugging... it's fixed now!

[DFX2KX]

The new version of the library doesn't seem to work with Deneth's emulator, the display remains blank

That's because I forgot to comment out a few "Serial.print" I used for debugging... it's fixed now!

Yay!

[jonnection]

After 3 tries to port Gamebuino library to SFML (the same way I did to the tv_out library) I finally gave up.

The Gamebuino library relies heavily on non-standard functions and macros only found in AVR-libc and Arduino libraries. I tried to port them (F macros, flashstrings etc etc) to GCC but it was so hard work it wasn't worth it.

So I started from scratch and soon began getting some results. By the looks of it, I will probably be writing my own library to develop games, the ease of developing code without the need to run on an emulator/upload to arduino is just such a big speed boost. This is NOT emulation. This is a library that I will make for both PC and Arduino so that the game code can be ported without changes. More on that coming later.

Here are Myndales demos running on my measly old IBM R50e (xubuntu). One odd thing was that the monster in the 3d demo was broken (?) I tried to find out the reason but coldn't figure out what was wrong. This was 3 hours work, so haven't debugged it yet.

Sorry for lack of quality, my phone is an early crappy Samsung android phone (see the pattern ?)