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

8088 MPH: We Break All Your Emulators

trixter.oldskool.org

Post reply on HN
Print view View original

41–50 of 102 posts

Re: 8088 MPH: We Break All Your Emulators

#41

Post by ghostberry »

draugadrotten wrote: post #27
blackhaz wrote: post #3

I can't believe my eyes. 256 colors on CGA?! HOW?!

On Atari ST, it was possible to change the palette colors in midflight, and using that trick to display more colors on screen. The technique was used by Spectrum 512 and Quantum Paint and many demos. "QPs 512 mode is pretty straightforward; its only color limitation being that it can display a maximum of 40 colors on a single scan line. Mode 4K uses a special technique called "interlacing" in order to display a suppo…

You could also go beyond that by changing the image 50/60 times a second, which would then blur together. Enabling you to display colours that aren't even in the ST's palette.

Re: 8088 MPH: We Break All Your Emulators

#42

Post by userbinator »

rcthompson wrote: post #34

I'm interested to know why it breaks all the emulators. Certainly I wouldn't expect emulators to reproduce all the graphical glitches that this takes advantage, but what is it doing that actually crashes them?

This is just a guess, but one thing that could do it would be cycle-exact self-modifying code using interrupts. Modify the code too early or too late and the CPU will execute the wrong instructions.

I see this demo as somewhat of a challenge to the emulator authors.

Re: 8088 MPH: We Break All Your Emulators

#43

Post by userbinator »

kyberias wrote: post #38

These days I find it slightly weird that they don't share the source code of the demos or related tools. Demo scene has this wonderful alpha-male thing going.

The demoscene grew out of the cracking/warez scene, so it's somewhat implied you should take a disassembler to it if you really want to figure out what a demo is doing. It's the complete opposite to the OSS culture, where the prevailing assumption is that the source code is most important and nothing can be done without it; in the demoscene, it's more like "we don't need no stinkin' source!" I think these two approaches are both interesting in their own ways.

Re: 8088 MPH: We Break All Your Emulators

#44

Post by boomlinde »

ekianjo wrote: post #8
corysama wrote: post #5

Quick explanation of compiled sprites: Most commonly a sprite is represented as a 2d array of pixels that you for X, for Y over and use math or branching to blend on to the screen. But, that's a lot of reading and writing, and a lot of the math ends up doing nothing because a lot of the pixels are intentionally invisible. So, you could do some sort of visible/invisible RLE to skip over the invisible pixels. That's be…

> it becomes a read instruction, write data in two straight lines in memory. So basically this kind of hack could not be used for a game, then, where interaction is needed?

I think Wolfenstein 3D compiles column scaling for each texture to speed up column rendering.

Re: 8088 MPH: We Break All Your Emulators

#45

Post by boomlinde »

ekianjo wrote: post #39
detaro wrote: post #37

Earlier quoted context omitted.

As if the majority of people had a clue about these things back in the day.

Probably more than now because computing was not really "mainstream" at the time. Before Win95 at least.

Computing was not mainstream, so kids had a better idea about it?

Re: 8088 MPH: We Break All Your Emulators

#46

Post by Maakuth »

ptype wrote: post #28

Wow, amazing. Would be interesting though to know which hacks make the emulators fail

I bet their color hacks end up doing something weird or possibly nothing with emulators. No idea about the implementation details of any PC emulator, but it sure would be tempting for an emulator to just display the bitmap copied from the emulated machine's display buffer instead of emulating the actual display adapter. Even emulating the adapter wouldn't be enough, I suppose, as the color tricks rely on some unintenional (from vendors PoV) bleed behavior, probably on the analog side of things. So I guess a proper emulator should also emulate some of the analog details of the display itself.

Re: 8088 MPH: We Break All Your Emulators

#47

Post by pdpi »

boomlinde wrote: post #45
ekianjo wrote: post #39

Earlier quoted context omitted.

Probably more than now because computing was not really "mainstream" at the time. Before Win95 at least.

Computing was not mainstream, so kids had a better idea about it?

I guess the kids who got it were a smaller fraction of the total population of kids, but a bigger fraction of the population of kids who owned a computer.

Re: 8088 MPH: We Break All Your Emulators

#48

Post by aerique »

draugadrotten wrote: post #27
blackhaz wrote: post #3

I can't believe my eyes. 256 colors on CGA?! HOW?!

On Atari ST, it was possible to change the palette colors in midflight, and using that trick to display more colors on screen. The technique was used by Spectrum 512 and Quantum Paint and many demos. "QPs 512 mode is pretty straightforward; its only color limitation being that it can display a maximum of 40 colors on a single scan line. Mode 4K uses a special technique called "interlacing" in order to display a suppo…

I'm not aware of the specifics anymore but by using well-placed NOPs when drawing a scanline you could make the borders disappear on the Atari ST thus getting a higher resolution. This was one of the many advantages the Amiga had over the Atari ST: being able to use the whole screen while the ST had a screen like a letterboxed movie except on all four sides of the screen.

Re: 8088 MPH: We Break All Your Emulators

#49

Post by lscharen »

nitrogen wrote: post #20
corysama wrote: post #12

Earlier quoted context omitted.

IIRC, because of relative-address store instructions, the destination address does not have to be hard-coded. So, the sprites can still move around dynamically. What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall bac…

What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall back on a more complicated blitter. In fullscreen modes, you could also just make your screen buffer bigger than the actual screen by the width and height of your l…

In my game engine I wrote for the Apple IIgs a long time ago, I used compiled sprites and maintained a 1-scanline-wide mask that I used to clip the compiled sprite to the screen edge.

This only cost one extra AND instruction and allowed the sprites to be clipped to any size rectangular playfield while still maintaining almost all of the speed benefits.

Re: 8088 MPH: We Break All Your Emulators

#50

Post by ajenner »

rcthompson wrote: post #34

I'm interested to know why it breaks all the emulators. Certainly I wouldn't expect emulators to reproduce all the graphical glitches that this takes advantage, but what is it doing that actually crashes them?

The emulator I was mostly using for development (DOSBox) doesn't actually crash itself, but here's a nice example of how it goes wrong. In the final part of 8088MPH there is an instruction that modifies the instruction after it, but then (on the real hardware) the old version of the instruction is executed (because it's already in the CPU's prefetch queue when the modification is made). DOSBox executes the modified instruction because it doesn't simulate the prefetch queue. I tried moving the to-be-patched instruction above the patching instruction but that made the code take longer to execute and it no longer met the precise timing requirements necessary for the best audio quality.
Post reply on HN