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

41–48 of 48 posts

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#41

Post by Brian_K_White »

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'.

kaypro & trs-80, just a couple I happen to know myself. There is no way I just happen to know about the only 2.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#42

Post by joshka »

GeertJohan wrote: post #9
redanddead wrote: post #8

Earlier quoted context omitted.

Oh bubbletea is really cool. Is this how most interactive CLIs are made?

I used bubbletea for a while but quit it because of inconsistencies in the design. Went to ratatui and never looked back. Go and Bubbletea are nice, but rust is much more suited for building tuis.

Ratatui dev here. We love both Bubbletea and Textual (though I'm personally not a huge fan of either Go or Python). They're inspirations for us to make good looking stuff.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#43

Post by Kerrick »

GeertJohan wrote: post #9
redanddead wrote: post #8

Earlier quoted context omitted.

Oh bubbletea is really cool. Is this how most interactive CLIs are made?

I used bubbletea for a while but quit it because of inconsistencies in the design. Went to ratatui and never looked back. Go and Bubbletea are nice, but rust is much more suited for building tuis.

I'd love to hear more about those inconsistencies. Would you be willing to share?

I built RatatuiRuby recently, and I'm currently building Rooibos, its MVU framework to compete with BubbleTea. I'd love to avoid repeating Charm's mistakes.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#44

Post by worthless-trash »

LoganDark wrote: post #25
weinzierl wrote: post #23

Earlier quoted context omitted.

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, terra…

I believe you are correct, VGA even had character rom, where 'individual pixels' were not drawn by the CPU itself, the software presented an array of indexes into the rom and the vga hardware itself blitted the characters onto the screen.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#45

Post by numpad0 »

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'.

> which was a character ROM per default but could be changed either with a screw driver or by

No. Stop believing everything ChatGPT told you on this topic and DYOR. That's some bad hallucinations.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#46

Post by lizzylot »

codebje wrote: post #36
weinzierl wrote: post #24

Earlier quoted context omitted.

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.

It's still wrong, though. Without dedicated sprite hardware it's not more efficient to read a byte from one place and write a byte to another than to write background bytes and write line colour bytes. DMA controllers on µCs won't save you: a character is usually something like 8x8 or 8x16 and displays are rarely more than 8 bit, so we're talking about DMA transfers of just 8 bytes each, and the overhead of setting t…

Without DMA you need to insert a lot of wasted cycles to wait between each SPI transfer, so it doesn't take that many bytes to make it worth it. I use variable width fonts on 16bit rgb565 displays and DMA doubles the speed of drawing text with ~20 bytes/characters.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#47

Post by lizzylot »

LoganDark wrote: post #29
zokier wrote: post #19

Earlier quoted context omitted.

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.

For simple SPI displays it's the transfer bandwidth that dominates, so for best performance you wanna minimize the number of pixels you need to send. So for eaxmple: if you wanna draw a 100 pixel long horizontal line, if you ever send more than 100 pixels of data you're not gonna hit the speed of light. And if you wanna draw an angled line you're gonna have to do something like bresenham and pixel by pixel because drawing NxN blocks for a 45 degree line would be insane.

Re: Mousefood – Build embedded terminal UIs for microcontrollers

#48

Post by RetroTechie »

numpad0 wrote: post #45
weinzierl wrote: post #23

Earlier quoted context omitted.

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'.

> which was a character ROM per default but could be changed either with a screw driver or by No. Stop believing everything ChatGPT told you on this topic and DYOR. That's some bad hallucinations.

Actually a small flathead screw driver is a useful tool to pull an (EP)ROM from its socket. Been there, done that (80s/early 90s).

Might be fun though to check with ChatGPT on how to use a screw driver in this context. :-)

Post reply on HN