VOGONS


8088 MPH: We Break All Your Emulators

Topic actions

First post, by slacka

User metadata
Rank Newbie
Rank
Newbie

There's a fascinating article on the magic behind the winner of Revision 2015 oldskool demo compo. Unfortunately it breaks all emulations. Does anyone have a good collection of x86 emulator to throw at this?

It creates a 1024-color mode by abusing CGA's 80×25 text mode + NTSC colorburst turned on. Any ideas on any emulators that might support this?

Reply 3 of 136, by Scali

User metadata
Rank l33t
Rank
l33t

Don't bother... even a lot of real hardware doesn't run the demo 100% as designed. Including XT clones that actually have a real 8088 running at 4.77 MHz, and a CGA-compatible card from the 1980s.
They have speed differences that are barely measurable by conventional benchmark programs, but which throw off the timing in certain routines completely (and may actually damage your CRT monitor).

In fact, we have even encountered some later IBM CGA cards, which use a HD6845 chip rather than the original Motorola 6845, which also does not work properly (although we can probably change some settings in our code to fix that).
So you really REALLY need an early IBM PC (5150/5155/5160) and early IBM CGA card to run the demo as intended.
The capture was from a 1987 IBM 5160 with an early IBM CGA card with original Motorola 6845.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 4 of 136, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
Scali wrote:

In fact, we have even encountered some later IBM CGA cards, which use a HD6845 chip rather than the original Motorola 6845, which also does not work properly (although we can probably change some settings in our code to fix that).
So you really REALLY need an early IBM PC (5150/5155/5160) and early IBM CGA card to run the demo as intended.
The capture was from a 1987 IBM 5160 with an early IBM CGA card with original Motorola 6845.

I have two late IBM CGA cards, one of which I converted by hand to function exactly like an early IBM CGA card. The untouched late IBM CGA card has an HD6845 and this caused the picture to jump noticeably during the screens where the large color palette was being used. It also lost sync on my CGA monitor when the developer's pictures were being displayed on one occasion. My "early" CGA card did not have a jumpy picture and it has an MC6845.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 5 of 136, by Scali

User metadata
Rank l33t
Rank
l33t
Great Hierophant wrote:

My "early" CGA card did not have a jumpy picture and it has an MC6845.

Yes, it really DOES work on the right hardware 😀
We were not aware of the HD6845 issues, since apparently all the cards we used during development were using MC6845s.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 7 of 136, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

That was a crazy demo, although the last part where they drew those polygonal objects didn't seem that impressive for the 5150. I could swear there have been a number of games made back in the 80s for that thing that pushed more polygons at once, albeit probably at a lower framerate. 🤣

Reply 8 of 136, by Scali

User metadata
Rank l33t
Rank
l33t
mr_bigmouth_502 wrote:

That was a crazy demo, although the last part where they drew those polygonal objects didn't seem that impressive for the 5150. I could swear there have been a number of games made back in the 80s for that thing that pushed more polygons at once, albeit probably at a lower framerate. 🤣

It's also the size of the polygons, the thing is almost fullscreen. And well, think again 😀
Try starting a 3d game such as Jet or F29 Retaliator, they aren't all that hot on a 5150 😀
And I think we're the only ones to actually attempt shading them on CGA.
Yes, more polys were possible at lower framerate... but it's all about finding a good compromise between number of polygons, size of polygons, complexity of object (the donut is an inconvex object of course, more difficult than a convex one), quality of shading, and framerate.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 9 of 136, by F2bnp

User metadata
Rank l33t
Rank
l33t

I think the segments that made my jaw drop were the one showcasing 16 colors to 256 colors, the kefrens bar effect and of course the credits.

This is a phenomenal demo, an amazing effort! Well done and thank you for pushing the machine that started it all to its limits!

Reply 10 of 136, by MobyGamer

User metadata
Rank Member
Rank
Member

It was our pleasure, glad everyone enjoyed it.

The polygons seem to get 100% love or 100% hate. I'll say this: Showing large polys without any double-buffering at that framerate must mean something fishy is going on. It is -- only the deltas that need to be drawn are calculated and put into video RAM. That is actually quite a lot harder than just doing a full erase and full redraw of every polygon, but the end result is a much faster display speed. The average scene of Indy 500, a *VERY* optimized game and one of my favorite 8088 programming examples of all time, draws about 25 polys at 3fps. The donut in the demo has IIRC 25 polys but averages around 18fps.

Reply 11 of 136, by Scali

User metadata
Rank l33t
Rank
l33t
MobyGamer wrote:

The polygons seem to get 100% love or 100% hate. I'll say this: Showing large polys without any double-buffering at that framerate must mean something fishy is going on. It is -- only the deltas that need to be drawn are calculated and put into video RAM.

I'd like to add that because you don't have a backbuffer, you need to draw from top to bottom, where conventional rendering just draws the polygons in whatever order they come in ('polygon soup').
The donut shape makes it extra difficult, since is is an inconvex object (rarely seen in games). Which means you need to take care of the z-order as well (with convex objects such as the pyramid and cube, just backface culling is enough to ensure proper z-order, since the object cannot overlap itself anywhere by definition).

I have done plenty of software renderers over the years, but the one I came up for for this platform is very unique. I have never written anything like it before, and I don't think many similar implementations exist. I started out just trying to optimize a conventional renderer to the extreme (based on the code of my 1991 donut intro), but that didn't get me very far on the limited bandwidth of the CGA card, so I had to completely re-think how to render polygons.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 12 of 136, by Scali

User metadata
Rank l33t
Rank
l33t

Here are two more articles on the demo, with background information on the 1k colour mode and the 16 KHz 4ch mod player:
http://www.reenigne.org/blog/1k-colours-on-cga-how-its-done/
http://www.reenigne.org/blog/8088-pc-speaker- … r-how-its-done/

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 13 of 136, by shock__

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:
Great Hierophant wrote:

My "early" CGA card did not have a jumpy picture and it has an MC6845.

Yes, it really DOES work on the right hardware 😀
We were not aware of the HD6845 issues, since apparently all the cards we used during development were using MC6845s.

Tell that to CPC users who have to bother with 3 variants of the 6845 + 2 licensed clones 😀
http://www.cpcwiki.eu/index.php/CRTC

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 14 of 136, by Scali

User metadata
Rank l33t
Rank
l33t
shock__ wrote:

Tell that to CPC users who have to bother with 3 variants of the 6845 + 2 licensed clones 😀
http://www.cpcwiki.eu/index.php/CRTC

Yes:

HSync pulse width in characters (0 means 16 on some CRTC), should always be more than 8; VSync width in scan-lines. (0 means 16 on some CRTC. Not present on all CRTCs, fixed to 16 lines on these)

I think that is our problem: We rely on the CRTC to interpret a hysnc width of 0 as 16. This gave us the best colour quality on our capture hardware. Apparently not all CRTCs behave that way, so we could turn the width down to 15 or less, which should solve the compatibility issue.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 15 of 136, by VileR

User metadata
Rank l33t
Rank
l33t

For interested parties... I've added my own rambling "illustrated guide" on how we squeezed 1024 colors out of CGA:
http://8088mph.blogspot.com/2015/04/cga-in-10 … llustrated.html

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 16 of 136, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Just found out about this from a random google search. Congratulations and great work!

I was impressed by the framerate and shading of the polygons (that kind of shading just wasn't done back then) and of course the 1024 (and even 256) colors. The high-quality music at the end was great too; I remember barely getting 8kHz PC speaker MOD music playback on my 8MHz 286.

Reply 17 of 136, by Scali

User metadata
Rank l33t
Rank
l33t

Here is another blog on some of the technology in the demo. This time it's the sprite compiler and vertical scrolling: https://scalibq.wordpress.com/2015/04/19/8088 … t-need-sprites/

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 19 of 136, by idspispopd

User metadata
Rank Oldbie
Rank
Oldbie

I can't even say which part impressed me most technically. The self-modifying MOD player at the end is awesome, but so is the sprite compiler.
The 1024 colour stuff is also great, but in a different way (less about coding, more artistically and exploiting the limited CGA hardware).

It's just a pity that you had to limit yourself to such a specific PC platform, there are probably more C64 today than PC's that could run this demo properly. But I understand why you had to do that.