Live data from Hacker News

8088 Domination Post-Mortem, Part 1

trixter.oldskool.org

31–40 of 111 posts

Re: 8088 Domination Post-Mortem, Part 1

#31
Wow... for that hardware, a 4.77MHz 8088 PC with CGA graphics and Sound Blaster audio, those stats are overwhelming:

1. Variable frame-rates up to 60 FPS.

2. Audio rates to 45kHz.

3. 16 colors through composite artifacting.

4. Simultaneous color and B&W output.

On a related note, you will probably be interested in Michael Abrash's Zen of Assembly Language. From the "README.md":

"This is the source for an ebook version of Michael Abrash's Zen of Assembly Language: Volume I, Knowledge, originally published in 1990. Reproduced with blessing of Michael Abrash, converted and maintained by James Gregory. Original conversion produced by Ron Welch."

https://github.com/jagregory/abrash-zen-of-asm

Re: 8088 Domination Post-Mortem, Part 1

#32

That's absolutely insane at that clockrate. The way I would get 'animations' (for want of a better term) done is by rendering them frame-by-frame, compressing that and then playing it back at high speed. And even that was next to impossible. Decompressing video @60fps, and doing real-time dithering to increase the effective number of colours and still have time enough for 45KHz audio is totally nuts. This qualifies a…

For me, the most interesting part is that his solution - updating only the changed parts between each frame and the previous one, and approximating the changes so that they're not (too) visually perceptible in order to satisfy a bitrate constraint - is one of the ways that modern video codecs achieve their compression. I agree it's also amazing that apparently, the true limitations of hardware from over 30 years ago…

The more I progress in our domain of expertise, the more I observe we're being incredibly wasteful† all over the place. For all the expressiveness power of our platforms and languages it somehow sounds insane that time (ruby -e '100_000_000.times {}') takes four solid seconds on my 3.4GHz machine††. I know, bogoMIPS are no benchmark, this is just to exemplify that layers of abstraction, while useful (necessary even), are also harmful, the underlying question being: how much layers is too much layers?

I dream of a system redesigned from the ground up, where hardware and software components, while conceptually isolated, cooperate instead of segregating each other to layers. See how ZFS made previously segregated layers cooperate to offer a robust system, see how TRIM operates on the lowest hardware levels by notifying of filesystem events, see how OSI levels get pierced through for QoS and reliability concerns. Notice how the increase in layers and thus holistic complexity rampantly leads to more bugs, more vulnerabilities, more energy wasted. We all know the fastest code is the one that does not execute, the most robust code is the one that doesn't get written, the most secure code is the one that doesn't exist. Why do I still see redraws and paintings and flashes in 2014? Why does a determined adversary has such a statistical advantage that he is almost guaranteed toget a foothold into my system? This is completely unacceptable. For as much as we love playing with it, the whole web stack, while a significant civilization milestone, is, as a whole, a massive technological failure (the native stack barely fares better).

† I consider wasteful and bloated subtly distinct

†† not at all an attack on Ruby, just what I happen to have at hand right now

Re: 8088 Domination Post-Mortem, Part 1

#33
post #32

Earlier quoted context omitted.

For me, the most interesting part is that his solution - updating only the changed parts between each frame and the previous one, and approximating the changes so that they're not (too) visually perceptible in order to satisfy a bitrate constraint - is one of the ways that modern video codecs achieve their compression. I agree it's also amazing that apparently, the true limitations of hardware from over 30 years ago…

The more I progress in our domain of expertise, the more I observe we're being incredibly wasteful† all over the place. For all the expressiveness power of our platforms and languages it somehow sounds insane that time (ruby -e '100_000_000.times {}') takes four solid seconds on my 3.4GHz machine††. I know, bogoMIPS are no benchmark, this is just to exemplify that layers of abstraction, while useful (necessary even),…

I sense the frustration around this subject is building. What I'm afraid of is that once it boils over into action it will lead to a repetition of moves. That's the hard one, to get a 'fresh start' going is ridiculously easy and one of the reasons we have this mess in the first place.

Very hard to avoid the 'now you have two problems' trap.

Re: 8088 Domination Post-Mortem, Part 1

#34
post #3

The work is very impressive, but the part I loved most was how even after deciding the problem was "impossible" to solve, he kept at it: > "Then I thought about the problem for 7 years."

Related earlier post: http://trixter.oldskool.org/2014/04/18/the-strangest-kind-of...

Re: 8088 Domination Post-Mortem, Part 1

#35
post #17

That's absolutely insane at that clockrate. The way I would get 'animations' (for want of a better term) done is by rendering them frame-by-frame, compressing that and then playing it back at high speed. And even that was next to impossible. Decompressing video @60fps, and doing real-time dithering to increase the effective number of colours and still have time enough for 45KHz audio is totally nuts. This qualifies a…

"This qualifies as art, not just software." For me there was never any doubt. A bit unrelated, but I've got an old 5150 at my parent's place, so when I'm visiting next Xmas I'll try to load this demo onto it. The only problem is that of transferring files to it. It only has a 5.25" floppy drive, and I don't have a means to copy files onto those floppies. Any suggestions?

I have, in the past, been forced to type an Xmodem transfer program into debug.com's hex mode, to get to the point where I can transfer files over a null-modem connection from another box. I can dig up the file in question, if that'd help you out at all.

I ended up typing it in 1k at a time, and independently typing in a CRC32 utility to check that I'd done it properly.

(That was to install Windows 98 on a computer with no drives, if I recall. So, not so very long ago.)

Re: 8088 Domination Post-Mortem, Part 1

#39
post #26
post #3

The work is very impressive, but the part I loved most was how even after deciding the problem was "impossible" to solve, he kept at it: > "Then I thought about the problem for 7 years."

In the demoscene, doing the impossible was just regular behaviour :-) Just look at what they get out of a mere C64...

The VIC-II and SID chips in the C64 are amazing. They blew away anything that could be found inside an IBM PC.

Re: 8088 Domination Post-Mortem, Part 1

#40

That's absolutely insane at that clockrate. The way I would get 'animations' (for want of a better term) done is by rendering them frame-by-frame, compressing that and then playing it back at high speed. And even that was next to impossible. Decompressing video @60fps, and doing real-time dithering to increase the effective number of colours and still have time enough for 45KHz audio is totally nuts. This qualifies a…

Isn't dithering done offline at encoding time?
Post reply on HN