Most active commenters
  • IWeldMelons(3)

←back to thread

331 points willm | 11 comments | | HN request time: 0.002s | source | bottom
1. lynx23 ◴[] No.41216782[source]
Anyone old and naiv enough to share this observation: Almost everything I looked at after TurboVision was inspired, but actually not really finished. Once you take the toolkit for a ride, you realize its kind of cute but unfinished. Maybe another way of looking at this is to call many of the TUI frameworks I say "opinionated", whatever that exactly means.

I am likely just dense and uncreative, but the truth is, when I switched from DOS to Linux in the 90s, I was never again as productive as I happened to be with B800. Granted, it likely took me a long time to understand the need for double buffering and the difference between a local/direct text mode vs a terminal, let alone escape sequences. But still. Whenever I tried to do something directly in ncurses, I pretty much gave up due to a distinct feeling of being unhappy. Completely different to what I was able to do with the simple ideal of B800.

replies(2): >>41217025 #>>41217464 #
2. thechao ◴[] No.41217025[source]
I learned GUI programming using win16, then win32 — this would've been during the transition to WinXP. I must have a city-wide blind spot, but every post message pump GUI framework has left me completely befuddled. One thing I never understood was how these OO frameworks helped to really solve the multithreaded UI issues. In Win32, I just threw the main renderer into a thread, then had support renderers build models "on the side", and then updated the difference. The code never really got out of hand.
replies(1): >>41221618 #
3. dualogy ◴[] No.41217464[source]
I get what Turbo Vision is (was), but what's that B800 thing? Surely you aren't talking about a Celeron processor? Seems tricky to google, also no Wiki page on that. You got me curious, plz spill it! =)
replies(3): >>41217630 #>>41218725 #>>41218941 #
4. anothername12 ◴[] No.41217630[source]
Ok I think he’s referring to 0xB800, the VGA text buffer segment in real mode.
replies(1): >>41226427 #
5. vetinari ◴[] No.41218725[source]
In real mode addressing and graphic card in text mode, your video memory started at absolute address 0xb800:0x0000. It was an two-dimensional array, where you could poke and whatever you changed here, was reflected immediately on the display. Each element of the array was two bytes: character itself and color attributes.
replies(1): >>41226441 #
6. lelanthran ◴[] No.41218941[source]
0xb800 is the address of the framebuffer for text. Simply write characters to that address, using offset `((row * width) + col)` and they'll appear on screen.

In graphics mode it was, IIRC, 0xa000. I once wrote a pacman-type easter egg inside the point-of-sale system[1], because doing direct graphics straight to an address is so easy and simple.

[1] Was removed after pilot and before actual release.

7. ◴[] No.41221618[source]
8. IWeldMelons ◴[] No.41226427{3}[source]
No not VGA, CGA actually
9. IWeldMelons ◴[] No.41226441{3}[source]
I think it is also 0xb800 as it is a physical address; not ionly in real mode.
replies(1): >>41228277 #
10. vetinari ◴[] No.41228277{4}[source]
For physical linear address, it would be one digit (4-bits) longer (-> 0xb8000); when the segment:offset is combined, the result is 20-bit address.
replies(1): >>41233430 #
11. IWeldMelons ◴[] No.41233430{5}[source]
Was not my point though.