Live data from Hacker News

8088 Domination Post-Mortem, Part 1

trixter.oldskool.org

61–70 of 111 posts

Re: 8088 Domination Post-Mortem, Part 1

#61
post #32

Earlier quoted context omitted.

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 think the underlying cause of this over abstraction is largely a result of abstraction being excessively glorified (mostly) by academics and formal CS curricula. In some ways, it's similar to the OOP overuse that has thankfully decreased somewhat recently but was extremely prevalent throughout the 90s. In software engineering, we're constantly subjected to messages like: Abstraction is good. Abstraction is powerful…

Up to the ~'60s gave us a vast theoretical foundation, and from then on we toyed with it, endlessly rediscovering it (worst case) or slightly prodding forward (best case), trying to turn this body of knowledge into something useful while accreting it into platforms of code, copper and silicon. My hope is that the next step will eventually be for some of us to stop our prototyping, think about what matters, and build stuff this time, not as a hyperactive yet legacy addicted child, but as a grown up, forward-thinking body that understands it's just not about a funny toy or a monolithic throwaway tool that will end up lasting decades, but a field that has a purpose and a responsibility.

To correct the quote:

Computer science is not an abstract form of engineering. Software (and hardware in the case it's made to run software) engineering is leveraging CS in the context of constraints imposed by reality.

> Any more than is strictly necessary to perform the given task.

Easy to say, but hard to define up front when 'task' is an OS + applications + browser + the hardware that supports it ;-)

This[0] is the typical scenario I'm hoping we would build a habit of doing.

[0]: http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

Re: 8088 Domination Post-Mortem, Part 1

#62
post #32

Earlier quoted context omitted.

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.

I think it didn't happen because the people feeling this way are precisely in the situation to understand how vast and hard an undertaking it is, not only to achieve, but also to succeed.

Few have attempted a reboot, yet the zeitgeist is definitely there: ZFS, Wayland, Metal, A7, even TempleOS (or whatever its name is these days). Folks are starting to say themselves 'hey, we built things, we learned a ton, we do feel the result, while useful, is a mess but we now genuinely understand we need to start afresh and how'. It's as if everyone were using LISP on x86 and suddenly realised they might as well use LISP machines.

I too fear we just loop over, yet my hope is that in doing that looping, our field iteratively improves.

Re: 8088 Domination Post-Mortem, Part 1

#63

Earlier quoted context omitted.

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.

Indeed. The problem with starting over is that anything you start over with is going to be simpler, at first. Thus potentially faster, easier, etc, etc. Rewrites are hard and costly, which is rarely taken into account. Even just maintaining a competent fork is hard enough. I think it's probably worth the effort, but I'm not quite sure how you get from A to B without just having some super competent eccentric multi-bi…

> I think it's probably worth the effort, but I'm not quite sure how you get from A to B without just having some super competent eccentric multi-billionaire finance a series of massive development projects.

And Elon Musk is busy doing rockets and electric cars!

Re: 8088 Domination Post-Mortem, Part 1

#64
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'm finding that an inherent psychological part of software development is to accept that nothing will be perfect. Everything is fucked up at some level, and there's no practical way around it. You just bite the bullet.

You stop worrying and learn to love the bomb.

Re: 8088 Domination Post-Mortem, Part 1

#65
At first I wanted to link to C64 productions such as this one https://www.youtube.com/watch?feature=player_detailpage&v=gG... but then I realized that the IBM PC was vastly worse designed than the C64. On the CPU, although running at whopping 4.77 MHz, trivial operations takes loads of cycles. The graphics memory sits on an ISA slot, 8-bit path and few MHz data-rate.

So, well done doing this on a machine that weak!

Re: 8088 Domination Post-Mortem, Part 1

#66

For perspective, it was still difficult doing video in the year 1999... I still remember the lengths some people had to go, to get MPEG working on the Nintendo 64: http://web.archive.org/web/20080331015735/http://www.gamasut...

(Edit - Single Page View: http://web.archive.org/web/20080326212226/http://www.gamasut... )

Re: 8088 Domination Post-Mortem, Part 1

#67
I imagine that part 2 is effectively going to involve "compiling" the sequences to assembly and executing them. You just don't have a lot of cycles to do much math on the 8088, so you may as well just write compile this as a big assembly program and start running it.

Looking forward to part 2 very much.

Re: 8088 Domination Post-Mortem, Part 1

#68
I can't wait to try this out. I still have my 4.77 MHz 8088 IBM PC with CGA video.

I don't have a monitor for it anymore, but that is fine since this was designed for the composite out anyway which I can put on a TV.

And I need to find an 8-bit SoundBlaster to put back in it.

Nice to see trixter doing stuff. I remember him from demoscene stuff in the 90s. Back then, PC demos were for 386/486/Pentium and VGA graphics. Nobody bothered with PC or XT (or CGA or EGA graphics) even back then.

Re: 8088 Domination Post-Mortem, Part 1

#69
post #32

Earlier quoted context omitted.

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 think the underlying cause of this over abstraction is largely a result of abstraction being excessively glorified (mostly) by academics and formal CS curricula. In some ways, it's similar to the OOP overuse that has thankfully decreased somewhat recently but was extremely prevalent throughout the 90s. In software engineering, we're constantly subjected to messages like: Abstraction is good. Abstraction is powerful…

I think to reverse this there will need to be some very massive changes within CS education.

Well, I mean, that is most definitely true regardless. But, with my experience getting my BS in CS a few years ago, it had nothing to do with "mainstream software engineering" either. I had classes on formal logic and automata, algorithms (using CLRS), programming language principles (where we compared the paradigms in Java, Lisp, Prolog, and others), microprocessor design (ASM, Verilog, VHDL), compilers, linear algebra, and so on. Very little in the way of architecting and implementing large, abstracted, real-world business applications or anything remotely web-related. In my experience I did not meet anyone interested in glorifying heaps of whiz-bang abstraction, they seemed to be more in line with the stereotypical "stubbornly resisting all change and new development" camp of academics.

Re: 8088 Domination Post-Mortem, Part 1

#70
post #35
post #17

Earlier quoted context omitted.

"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 w…

Yes, I would love to find that specific program - as there are several Xmodem transfer programs out there and I'd like to use one that's not only small in size, but also most likely to work.
Post reply on HN