| Hardware Malfunction | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||||||
|
popularity : 58% |
|||||||||||||
alltime top: #7814 |
|
|||||||||||||
added on the 2020-04-12 20:07:02 by fgenesis  |
||||||||||||||
popularity helper
comments
that thingie KICKED ASS. Real wild. Real good!
rulez added on the 2020-04-12 20:09:55 by HellMood 
wild
Nice thing ATMEEEGAAAAAAA
Some more info about the HW that would have been too much detail to mention for the compo; some people on discord asked for this:
The LCD has its own RAM but this specific controller is (to my knowledge) write-only.
That means no framebuffer on the AVR, and 8K memory is really not enough to store much
(remember, a 64 x 64 x 8bpp image already takes up half of the entire RAM,
and the audio player and mixer buffer require some of the global budget as well).
There is also no support for palettes or sprites or anything in hardware.
The communication with the display basically boils down to this:
- send set (x1, y1), (x2, y2) rectangle commands, send "hey i'm going to send pixels now" command
- set two halves of a 16bit (5.6.5 bits) color to PORTA and PORTC
- toggling the LCD write pin twice sends one pixel
- keep toggling that pin for as many pixels as your rectangle specified. The LCD does the rectangle wraparound logic internally.
- doing the math, this can reach about 50 fps (2 cyc/pixel at 16 MHz) assuming the color is never changed and loop overhead doesn't exist
- there is no support for clearing regions of the screen, you have to pump out pixels in software to the bitter end
- you can't skip pixels either, specifying a rectangle and then sending pixels always overwrites the content that was there
- there is a VSYNC pin but it's not connected to the outside, so there is no way to really avoid flickering
The display has two hardware features that are sort of interesting:
- scrolling. but only on the long axis and there is no off-screen memory, so the large scrolling image for example must be decompressed on the fly directly into the display.
- inverting colors. but what would you use this for except for strobo...?
The 3D stuff is pretty standard, normal indexed meshes rendered directly to the LCD, with perspective division and everything.
So basically most effects boil down to writing long stretches of the same color to keep things fast, and interlacing like crazy to hide the fact that there is totally not enough bandwidth to do anything fluid on this thing.
I might write a more detailed writeup if someone is interested.
The LCD has its own RAM but this specific controller is (to my knowledge) write-only.
That means no framebuffer on the AVR, and 8K memory is really not enough to store much
(remember, a 64 x 64 x 8bpp image already takes up half of the entire RAM,
and the audio player and mixer buffer require some of the global budget as well).
There is also no support for palettes or sprites or anything in hardware.
The communication with the display basically boils down to this:
- send set (x1, y1), (x2, y2) rectangle commands, send "hey i'm going to send pixels now" command
- set two halves of a 16bit (5.6.5 bits) color to PORTA and PORTC
- toggling the LCD write pin twice sends one pixel
- keep toggling that pin for as many pixels as your rectangle specified. The LCD does the rectangle wraparound logic internally.
- doing the math, this can reach about 50 fps (2 cyc/pixel at 16 MHz) assuming the color is never changed and loop overhead doesn't exist
- there is no support for clearing regions of the screen, you have to pump out pixels in software to the bitter end
- you can't skip pixels either, specifying a rectangle and then sending pixels always overwrites the content that was there
- there is a VSYNC pin but it's not connected to the outside, so there is no way to really avoid flickering
The display has two hardware features that are sort of interesting:
- scrolling. but only on the long axis and there is no off-screen memory, so the large scrolling image for example must be decompressed on the fly directly into the display.
- inverting colors. but what would you use this for except for strobo...?
The 3D stuff is pretty standard, normal indexed meshes rendered directly to the LCD, with perspective division and everything.
So basically most effects boil down to writing long stretches of the same color to keep things fast, and interlacing like crazy to hide the fact that there is totally not enough bandwidth to do anything fluid on this thing.
I might write a more detailed writeup if someone is interested.
Really nice music and some cool effects
Very nice megademo, and all on an Arduino, wow!
This is also cool, thanks for the source https://github.com/fgenesis/hwmf
impressive
what. the. actual. fuck.
Thanks so much for clarifying on the high FPS. Really great one
really nice demo on exotic platform!
Awesome demo, for such a cheap hardware !
Very nice!
Fantastic prod <3
hardware pr0n fuckery. awesome!
Really impressive!
Goor Enough! This Demo Rocks!
Fantastic demo. Awesome tech, great presentation.
Lovely soundtrack and direction. Congrats for great effort.
This is great!
So many effects, nicely put together and with a really sweet music track.
Congrats for this, and of course, on this platform!
So many effects, nicely put together and with a really sweet music track.
Congrats for this, and of course, on this platform!
Impressive and have some style
Finally it's done ;)
Cool! I especially liked the twist-vu-meter! :-D
A mix of various influences it seems...
A mix of various influences it seems...
Supercool stuff!
keen platform usage!
only Arduino makes it possible!
@psenough: HWMF actually contains no Arduino code.
It was one of the first things we tried, but it was orders-of-magnitude too slow, as IIRC it uses dynamic dispatch everywhere (I forgot whether it was C-style, with structs of code pointers, or C++ style, but same thing)
Instead, the device- and board-level configuration in HWMF exists as template parameters, so all that is evaluated and code-generated at compile-time and the primitives for writing to the MIPI bus compile down to a tiny bit of inline ASM (despite being fully configurable)
It was one of the first things we tried, but it was orders-of-magnitude too slow, as IIRC it uses dynamic dispatch everywhere (I forgot whether it was C-style, with structs of code pointers, or C++ style, but same thing)
Instead, the device- and board-level configuration in HWMF exists as template parameters, so all that is evaluated and code-generated at compile-time and the primitives for writing to the MIPI bus compile down to a tiny bit of inline ASM (despite being fully configurable)
PS: fg gets all the blam^W credit for the config template madness. I vaguely figured out how to poke it, but I wouldn't claim to understand it.
(Unlike, say, the template linear algebra lib, which none of us understand anymore, as it contains fg's most dread sourceries, and my mathemagics most foul)
(Unlike, say, the template linear algebra lib, which none of us understand anymore, as it contains fg's most dread sourceries, and my mathemagics most foul)
Quote:
(I forgot whether it was C-style, with structs of code pointers, or C++ style, but same thing)
(Arduino is just C++ and a preprocessor in a trenchcoat)
This is appreciated, thanks!
lists containing this prod
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !