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

51–60 of 102 posts

Re: 8088 MPH: We Break All Your Emulators

#51

Post by ajenner »

Maakuth wrote: post #46
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 uninten…

There are emulators (for other targets) which do emulate NTSC decoding properly, but until I did the research for this demo nobody understood how the CGA card generates composite signals well enough to be emulate it properly. I have some code which I hope to be adding to DOSBox (and any other emulators that want it) soon.

Re: 8088 MPH: We Break All Your Emulators

#52

Post by Mithaldu »

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.

Keep in mind that demos are usually released at parties in competitions, and occasionally even rewarded with real value prices.

Re: 8088 MPH: We Break All Your Emulators

#53

Post by qrmn »

aerique wrote: post #48
draugadrotten wrote: post #27

Earlier quoted context omitted.

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.

Toggling the register to change between 50/60Hz mode at the right time, specifically, could reset the counter in the ST's Video Shifter and trick it to carry on drawing screen when it should have been outputting blank border. Top and bottom borders were however much easier, because you could open them with just one carefully-timed interrupt each (I used Timer-B, which was linked to horizontal blank and counted lines, if I remember!). Described as far back as the B.I.G. Demo (check the scrolltext).

Opening the left and right borders however required doing it for each line, I recall, which uses a lot more CPU time. (Unless, of course, there's a trick I don't know!)

Spectrum 512 uses NOP timings to swap the palette at regular intervals throughout the screen; the "4096 colour interlaced" mode just flickered between one colour and another on alternate blanks to give the visual impression of flickery intermediates (before the STe came out, which used the high bit of each nybble to actually have 4-bit-per-channel palettes of 16). That technique, in turn, came from the C64 scene, as did the border trick, though I think they wrote the screen address?

What's old is new again: plenty of lower-end TN LCD panels pull the same colour trickery to fake 8-bit colour from 6-/7- bit panels (or, reportedly, 10-bit deep colour from 8-bit ones in some cases).

This demo is crazy. I don't think CGA even gives them a VBL to hang off! Wonderful.

Re: 8088 MPH: We Break All Your Emulators

#54

Post by vidarh »

lscharen wrote: post #49
nitrogen wrote: post #20

Earlier quoted context omitted.

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.

That's actually cool, as it would also allow clipping against a "foreground" by varying the address of the scanline mask. E.g. imagine foreground trees in a jungle scene.

Re: 8088 MPH: We Break All Your Emulators

#55

Post by Jare »

aerique wrote: post #48
draugadrotten wrote: post #27

Earlier quoted context omitted.

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.

Vague details from memory: To make the vertical borders disappear, you could reset the refresh timing (maybe it was just by switching from 50Hz to 60Hz mode) halfway through a frame, and the video chip on the ST would desync from the retrace in the CRT. The only way I know to draw on the horizontal borders of a vanilla ST was by perfectly timed border color changes - I used that along with the compiled sprites technique discussed elsewhere in this post, to write a border-less horizontal scroller.

Re: 8088 MPH: We Break All Your Emulators

#56

Post by vidarh »

qrmn wrote: post #53
aerique wrote: post #48

Earlier quoted context omitted.

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.

Toggling the register to change between 50/60Hz mode at the right time, specifically, could reset the counter in the ST's Video Shifter and trick it to carry on drawing screen when it should have been outputting blank border. Top and bottom borders were however much easier, because you could open them with just one carefully-timed interrupt each (I used Timer-B, which was linked to horizontal blank and counted lines,…

You're close with respect to the C64 border trick.

On the C64, you could pull the border in the width / height of one character in order to support smooth scrolling (coupled with registers to set a 0-7 pixel start offset for the character matrix). This was done so that the borders wouldn't move in/out while scrolling.

By turning this option on/off precisely timed, the VIC graphics chip never found itself at the "correct" location to enable the borders, and so never did.

Opening the top/bottom borders was done very early because it didn't require much timing.

Opening the left/right borders with static sprites happened soon afterwards.

Opening the left/right borders with moving sprites was particularly nasty because the VIC "stole" extra bus cycles from the CPU for each sprite present on a given scan line, so if you wanted to move sprites in the Y position and open the borders, you needed to adjust your timing by the correct number of cycles for each scan line, often done by jumping into a sequence of NOP's. There were additional complications, but that's the basics.

I think DYSP (Different Y Sprite Positions) on C64 was first achieved in 1988.

Re: 8088 MPH: We Break All Your Emulators

#58

Post by diydsp »

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.

I am sorry for whatever pain you're feeling.

I don't feel the ethics of open-source apply here or to any works of art.

Programs like Microsoft Word, which have a near-monopoly on the work that literally billions of people do everyday to be productive and feed their families, when not distributed in a free manner, are tools of unjust power.

I don't feel this person's expressive work, a lifelong dream with no monetary gain, that might merely provide a few weeks of bliss and 15 minutes of internet fame a little inspiration for the rest of us, then become horribly forgotten to the sands of time, is a tool of unjust power.

> alpha-male thing going

I am sorry for whatever you've experienced that leads you to sexist comments like this. I hope that it's able to work its way through your life until you reach the point that you can simply share another person's joy without feeling entitled to have a piece of it yourself.

Re: 8088 MPH: We Break All Your Emulators

#59

Post by userbinator »

ajenner wrote: post #50
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 i…

Modifying code in the prefetch queue was a well-known anti-debugging/emulation trick in the pre-Pentium days but this is probably the first time I've heard it being used as an optimisation - seriously amazing work.

Re: 8088 MPH: We Break All Your Emulators

#60

Post by bane »

The party this was released at had some absolutely mind-blowing stuff. The 8k and 64k competitions were amazing. The demoscene continues to be an astonishing force in computing.

Some of the stuff would be completely at home as installation art in any top modern art museum. My favorite is https://www.youtube.com/watch?v=XF4SEVbxUdE done in 64kb!

Here's the results with links to productions (most of them have youtube videos by now)

http://www.pouet.net/party.php?which=1550&when=2015

Post reply on HN