Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mousefood – Build embedded terminal UIs for microcontrollers

github.com

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#21

Post by gmueckl »

weinzierl wrote: post #20
orbital-decay wrote: post #18

Earlier quoted context omitted.

It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead.

At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.

No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#22

Post by orbital-decay »

weinzierl wrote: post #20
orbital-decay wrote: post #18

Earlier quoted context omitted.

It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead.

At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.

Character-based hardware only stores the characters and the grid instead of the full bitmap for the frame, which is very efficient memory-wise. Tile-based hardware (e.g. most console graphics chips in the 8/16 bit era) also had scrolling and layers, and was extremely memory-efficient as well. With bitmap displays you already store full frames.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#23

Post by weinzierl »

gmueckl wrote: post #21
weinzierl wrote: post #20

Earlier quoted context omitted.

At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.

No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

Do you have an example? All the 8-bitters I know drew the characters from memory, which was a character ROM per default but could be changed either with a screw driver or by bank switching some RAM in-place.

EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#24

Post by weinzierl »

orbital-decay wrote: post #22
weinzierl wrote: post #20

Earlier quoted context omitted.

At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe.

Character-based hardware only stores the characters and the grid instead of the full bitmap for the frame, which is very efficient memory-wise. Tile-based hardware (e.g. most console graphics chips in the 8/16 bit era) also had scrolling and layers, and was extremely memory-efficient as well. With bitmap displays you already store full frames.

Sure. Maybe I should not have written 'blitting' when the rectangles are not copied from one memory location to another but end up directly on the screen.

My original point that putting a fixed number of small and fixed rectangles on a screen is more efficient than line drawing still stands though.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#25

Post by LoganDark »

weinzierl wrote: post #23
gmueckl wrote: post #21

Earlier quoted context omitted.

No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

Do you have an example? All the 8-bitters I know drew the characters from memory, which was a character ROM per default but could be changed either with a screw driver or by bank switching some RAM in-place. EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'.

The character ROM was not read and processed by the CPU. The CPU set some bytes in video RAM, which served as indexes into the character ROM by the video output hardware.

I believe on some systems there were some tricks that allowed some bitmap display by redefining glyphs. One example off the top of my head is The 8-Bit Guy's Planet X2, which can use text mode but with glyphs redefined to use for icons, units, terrain, UI, etc.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#26

Post by awkwardleon »

weinzierl wrote: post #23
gmueckl wrote: post #21

Earlier quoted context omitted.

No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

Do you have an example? All the 8-bitters I know drew the characters from memory, which was a character ROM per default but could be changed either with a screw driver or by bank switching some RAM in-place. EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'.

Maybe too old to be applicable here, but the TRS-80 Models I and III (and probably more models) had no way to address pixels. You had to use semigraphic characters to emulate larger blocks at sub-character resolutions. https://bumbershootsoft.wordpress.com/2022/01/28/touring-the...

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#27

Post by 0xbadcafebee »

01HNNWZ0MV43FF wrote: post #11
dbacar wrote: post #2

Hi Orhun, Could it be used with CYD (Cheap yellow display) ?

Today I Learned: https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display

fwiw, in my research into this, it looks like there are inconsistencies in the devices available, since there's no one manufacturer and they're clones of clones. one might have been reliable but then it goes out of stock

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#28

Post by LoganDark »

onjectic wrote: post #10

Reminds me a lot of the UI styles in the Minecraft mod ComputerCraft.

ComputerCraft was part of how I learned to code.

I first learned about password hashing when I tried to make the actually most secure door lock program. I first used raw SHA-256, but then someone on the forum introduced me to PBKDF2...

Sometimes I miss those days.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#29

Post by LoganDark »

zokier wrote: post #19
weinzierl wrote: post #16

Earlier quoted context omitted.

Sure, but that's beside the point. Text based graphics with fancy or custom fonts is just crazy efficient. That is exactly how we got the amazing graphics of The Last Ninja or Turrican on machines with less than 64KiB useable RAM. Same for more modern embedded devices. If you constrain yourself to text you increase both runtime performance and your developer productivity.

Are you claiming that scrapping together boxes and whatnot with line drawing characters is more efficient than just drawing the lines directly?

I think they're claiming that having character-based pipelines and algorithms can be more efficient than doing everything on the level of pixels... I can't help but feel there's a middle-ground somewhere, though.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#30

Post by direwolf20 »

weinzierl wrote: post #23
gmueckl wrote: post #21

Earlier quoted context omitted.

No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns.

Do you have an example? All the 8-bitters I know drew the characters from memory, which was a character ROM per default but could be changed either with a screw driver or by bank switching some RAM in-place. EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'.

With character RAM you can still only have up to 256 unique 8x8 blocks on screen.
Post reply on HN