Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

8088 Domination Post-Mortem, Part 1

trixter.oldskool.org

Post reply on HN
Print view View original

41–50 of 111 posts

Re: 8088 Domination Post-Mortem, Part 1

#41

Post by _quasimodo »

jacquesm wrote: post #12

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…

> real-time dithering

Wasn't dithering done before the encoding? I thought that was the reason he needed ordered dithering.

Re: 8088 Domination Post-Mortem, Part 1

#43

Post by Intermernet »

jacquesm wrote: post #24
userbinator wrote: post #20

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…

> "throw more brainpower at it" Back then there was simply no other way. I remember doing a 3D real-time fly-by of a big architectural development in Amsterdam ("Meervaart") in the 80's. I custom built the machine, pulled a trick where I clocked the fp coprocessor faster than the main processor, had a tseng graphics card (just about as fast as it would go at the time). And all the rest was software, hidden line remov…

Wow, as someone who saw some "cutting edge" 3D as a young student in the early 90's, this is beautiful. Weren't the Tseng cards in the 80's pretty much the first consumer cards with features hinting at fmv / 3d ? I was a tad young to know the details, I know their cards in the early 90's were incredible, but I wasn't there for the first Tseng labs stuff. Friends of mine claim that the early Tseng stuff was so impressive they suspected fakery in some of the demos!

Your clocking antics remind me of when I had to match a motherboard / processor to the maximum serial data rate acceptable by an old milling machine. The controlling software was no longer supported, and relied on the clock speed for timing (disastrous for controlling motors / servos etc) so I trialled a bunch of processor / MB combos until the milling machine accepted the output... Involved underclocking a Cyrix Cx something on some unknown brand MB that supported non-standard clock multipliers.

I got paid with a set of 5 year old race skis :-)

Re: 8088 Domination Post-Mortem, Part 1

#45

Post by InclinedPlane »

jacquesm wrote: post #33
lloeki wrote: 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.

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-billionaire finance a series of massive development projects.

Re: 8088 Domination Post-Mortem, Part 1

#46

Post by jacquesm »

Intermernet wrote: post #43
jacquesm wrote: post #24

Earlier quoted context omitted.

> "throw more brainpower at it" Back then there was simply no other way. I remember doing a 3D real-time fly-by of a big architectural development in Amsterdam ("Meervaart") in the 80's. I custom built the machine, pulled a trick where I clocked the fp coprocessor faster than the main processor, had a tseng graphics card (just about as fast as it would go at the time). And all the rest was software, hidden line remov…

Wow, as someone who saw some "cutting edge" 3D as a young student in the early 90's, this is beautiful. Weren't the Tseng cards in the 80's pretty much the first consumer cards with features hinting at fmv / 3d ? I was a tad young to know the details, I know their cards in the early 90's were incredible, but I wasn't there for the first Tseng labs stuff. Friends of mine claim that the early Tseng stuff was so impress…

I loved the Tseng mostly because of its nice memory map and the fact that the registers weren't very secret. Before that it was "VGA Wonder" (ATI).

The Tseng vesa cards did not do 3D but they were blisteringly fast (for the time) if you knew how to hit them 'just so'. Do everything by the row and avoid bank switches at all cost.

The funny thing is that the driver I wrote for the card was only about 2% or so Tseng specific. gp_wdot, gp_rdot, gp_wrow and gp_rrow were the only routines out of about a 150 or so that were optimized and they were quite short to begin with. And that alone was enough to get very close to maximum bandwidth between the CPU and the graphics memory (this was across the VLB).

I like your clocking trick a lot better than mine, I just soldered an extra socket for an oscillator to the motherbord and ran one wire under the chip to the right pin (and I cut one trace on the motherbord). Plugging in a bunch of oscillators until the FP chip started to behave weird (and then adding a little fan and pushing it some more :) ).

Interesting how those payments worked out.

Now I'm seriously wondering if there is a way in which I could resurrect that demo. No idea what I did with the data, I probably still have the code in some form or a descendant of it.

This was the card I originally wrote the code for:

http://www.vgamuseum.info/index.php/component/content/articl...

But by then I may have upgraded to a et4000 (the 3000 was 16 bit ISA).

Re: 8088 Domination Post-Mortem, Part 1

#47

Post by userbinator »

lloeki wrote: post #32
userbinator wrote: post #20

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 think the underlying cause of this overabstraction 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. Abstraction is the way to solve problems. More abstraction is better. Even in the famously acclaimed SICP lecture series [1] there is this quote:

"So in that sense computer science is like an abstract form of engineering. It's the kind of engineering where you ignore the constraints that are imposed by reality."

There is an implication that we should be building more complex software just because we can, since that is somehow "better". Efficiency is only thought of in strictly algorithmic terms, constants are ignored, and we're almost taught that thinking about efficiency should be discouraged unless absolutely necessary because it's "premature optimisation". The (rapidly coming to an end) exponential growth of hardware power made this attitude acceptable, and lower-level knowledge of hardware (or just simple things like binary/bit fields) is undervalued "because we have these layers of abstraction" - often leading to adding another layer on top just to reinvent things that could be easily accomplished at a lower level.

The fact that many of those in the demoscene who produce amazing results yet have never formally studied computer science leads me to believe that there's a certain amount of indoctrination happening, and I think to reverse this there will need to be some very massive changes within CS education. Demoscene is all about creative, pragmatic ways to solve problems by making the most of available resources, and that often leads to very simple and elegant solutions, which is something that should definitely be encouraged more in mainstream software engineering. Instead the latter seem more interested in building large, absurdly complex, baroque architectures to solve simple problems. Maybe the "every byte and clock cycle counts" attitude might not be ideal either for all problems, but not thinking at all about the amount of resources really needed to do something is worse.

> how much layers is too much layers?

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

[1] http://www.youtube.com/watch?v=2Op3QLzMgSY#t=10m28s

Re: 8088 Domination Post-Mortem, Part 1

#48

Post by Perseids »

lloeki wrote: post #32
userbinator wrote: post #20

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'd answer in two ways: One, it is already happening. The 10M problem (10 million concurrent open network connection) is solved by getting the Linux kernel out of the way and managing your own network stack: http://highscalability.com/blog/2013/5/13/the-secret-to-10-m... - The beauty of their approach is that they still provide a running Linux on the side to manage the non-network hardware so you have a stable base to build and debug upon.

Two, I am not sure we are that much smarter now than we were then. As you have quoted a language problem I'll use one myself as an example. See this SO question: https://stackoverflow.com/questions/24015710/for-loop-over-t... . I wanted to have a "simple" loop over some code instantiating several templates. I say simple, because I had first written the same code in Python and found out it was too slow for my purposes and thus rewrote in in C++. In Python this loop is dead simple to implement, just use a standard for loop over a list of factory functions. In C++ I pay for the high efficiency by turning this same problem in an advanced case of template meta programming that in the end didn't even work out for me because one of the arguments was actually a "template template". And on the other hand, making the C++ meta programming environment more powerful has its own set of problems: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n361...

Re: 8088 Domination Post-Mortem, Part 1

#50

Post by Intermernet »

adestefan wrote: post #39
frownie wrote: post #26

Earlier quoted context omitted.

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.

I'm a softy, but I still think the SID is amazing. The sounds that developers squeezed out of that chip are a testament to true hackery. I have a feeling the tricks developed to stress the SID to it's maximum have been adopted by a lot of serious audio developers in recent years to get higher track count / lower latency / higher bit rate etc. It's like the SID was the home-chemistry set equivalent for many a professional DAW / plugin designer.
Post reply on HN