Hacker News Reader

Comment by pavlov | Hacker News Reader

Somebody should wrap this into a VGA-As-A-Service platform so that kids could learn programming the correct way:

  mov ax, 13h
  int 10h

View on HN

Ducktaping assembler into DOSBox Debugger would be interesting project, it provides almost whole UI otherwise by itself https://zwomp.com/index.php/2020/05/01/understanding-the-dos...

I recently found some of my old Pascal mode 13h projects from when I was a teenager. Is DOSBox the best way to run those and Turbo Pascal?

The assembly you’ve listed there assumes it runs in real mode and ring 0. You’d need to use virtualization of some kind to execute that.

With a BIOS, or CSM on UEFI.

That's the only Holy way to run.

Not exactly the same, but https://www.endbasic.dev/ tries to achieve precisely that: a REPL with built in graphics for learning purposes, albeit with BASIC instead of asm.

Sort of like this, but with BASIC? https://en.wikipedia.org/wiki/Logo_(programming_language)

Pretty much, though I’m trying to replicate what I got in an Amstrad CPC computer.

I'm guessing you typed that from memory. What were you doing in the 90s? (demo coder, video game developer checking in here)

These two lines are deeply ingrained in the minds of a whole generation of programmers. They start a graphics mode of size 320x200 with a 256 byte palette and you can start dumping your pixels in the 0xa0000 segment right away.

I am yet to find a modern graphics programming environment that is so comfortable and easy to use as this.

Well your sorta comparing heavyweight OS graphics stack APIs with old school firmware ones. Even so, things like SDL2 are dead simple, one requests a window region and its possible to write bytes to the resulting buffer that show up in a window. That said modern firmware interfaces are still pretty clean. If you write a UEFI hello world, its possible to access the raw frame buffer with just a connection to the GOP, which is just a couple lines of code in C. Its conceptually pretty close to what your describing, except its designed to work with a slightly more modern programming paradigm.

https://wiki.osdev.org/GOP

I wouldn't call SDL2 "dead simple", unless sarcastically. Just opening an empty SDL window requires writing about 20 lines of code that deal with several different abstractions, a "window", a "surface", a "renderer, an "event". I only want an array of pixels that I can edit and see the results in realtime. It is of course possible to do that, but it seems ridiculously overcomplicated.

I was taught as a kid to program simple graphical demos using peek and poke in basic. Then in assembler. In either case, stupid me got colored pixels on the screen after a few minutes of work. Kids these days, how do they start? Please, don't tell me "matplotlib" or I will cry myself to sleep.

It depends a bit on your language bindings, if you look at say a python example:

https://about-prog.com/en/articles/python/hello_world_sdl2

Its basically, grab a window, show it, grab a render/draw buffer update it and make it visible.

I don't really find the base C version much more complex, although it does have a bit of boilerplate around init/window creation/grab surface/display surface/etc. I'm not sure I would consider that particularly complex. Sure SDL can get complex when you start trying to use GL/etc but if all you want is a buffer to write bytes that become pixels its pretty straightforward IMHO.

I would say its roughly the same level of complexity (if not less) than HTML canvas+JS.

Reply on news.ycombinator.com