Astonishing. Back in early 1992, my old man brought a PC back from work, as they were chucking it out - an IBM XT with CGA display, two floppy drives, 512K of RAM and a broken hard drive. I was 12, and fascinated by it - but the blocky text, four colour display wasn't going to set the world alight (aside from a Breakout clone which had 16, much to my puzzlement, of course it was using the "160x100" trick). I still used it daily - as a games machine, of course, and eventually managed to find a copy of Windows 3.0 for it. It was unusably slow... you could see the window elements being drawn one by one, and it was in 640x200 mono only. The following year we bought a VGA card and monitor for it (not that Windows could use it, turns out the VGA driver has 80186 code in it), and I still remember how Prince of Persia went from looking awful to superb, and how sharp the text became. In late 1994 we bought a 486 and the poor old XT was given away to a friend. Seeing this 32 years on from those days, running on CGA... absolutely incredible. Not only figuring out the various tricks, but implementing them with that painfully slow hardware.... astonishing. A hearty "well done" to the talented coders, for pulling off the seemingly impossible. I can only imagine what the IBM folks would have made of this back in the day!
The latest release of FastDOOM (a Doom engine port) has added an "ansi from hell" CGA video mode based on the idea from this demo. It won't run on 8088 of course, but the possibilities are out there!
It's much more difficult in a real game. They are relying on techniques like switching colour modes faster than the electron beam can trace across the screen. That's feasible for a demo like this where everything is scripted but much more problematic in a game where you must respond to user input, run game logic etc. Not impossible - the Atari 2600 was so limited in hardware that that was basically the only way to do it - but it does limit your options.
Yep, with some effects the CPU is the hard limit... things like the rotating 3D objects and the voxel landscape especially. But others are still limited by the CGA's "snow" issue (in those modes you get artifacts if you access video RAM during active raster time, which effectively cuts the bandwidth by a factor of >4).
@@x86VileR A V20 could help alleviate the CPU bottlenecking a wee bit (probably a lot more with an overclock) For the CGA Snow, dual port ram on the card could fix it, but would require modifying the card or outright replacing it with one designed for dual port ram
Here's a revised version: "This demo, back in 1981, would have obliterated the market, wiping out Apple, Commodore, Tandy, and every other computer maker altogether. There would be no Amigas, no Atari STs, or any other computers-just the PC. Kudos to the team!"
Wanted to, but I couldn't get the right brightness/color balance with ambient room light.. not to mention reflections. That's always one of the trickiest bits for some reason!
I just discovered your website and channel! I love your retro content! I grew up on DOS and now I use Linux most of the time. I have a love for all things old.
Unfortunately that's a negative to both... it needs some 560k of free RAM. A V20 should play nice with most sections, but some (the end credits and the 'wibbly' image just before it, as well as the rotating 3D objects) rely on cycle-exact 8088 behavior.
The CGA can only fetch a new character from VRAM at 8-pixel increments; a new one for every pixel would've required 8 times the bandwidth (and would also exceed the 6845 CRTC's capabilities in terms of clock speed).
The audio and the visuals aren't 100% perfectly synced in the 'party version' of the demo, so it'll drift a bit from one machine to the next; right now certain parts still don't compensate for different media read speeds, but that's something we plan to fix for the final version. I suspect that the CF card in my XT is a tiny bit slower than Trixter's. :)
ooooh that would explain why I didn't notice that in 86Box, as (at least when I tried it) it didn't support slowing down IDE drives, so they were always running at maximum speed, which is probably pretty close to CF. also, have you ruled out TSRs slowing down the executable bootup process enough for a desync?
@@FavoritoHJS Nope, haven't ruled that out completely. Most TSRs should have no effect, since irrelevant IRQ channels are supposed to be masked off during disk reads, but it's likely not 100% watertight in this version. Unfortunately, on a typical 8088 system, any but the smallest TSRs would simply take up too much RAM for Area 5150 to run all the way through... but this will hopefully be optimized in the final version as well.
On CGA vsync can be detected by polling the status register - it just doesn't generate an IRQ (EGA/VGA can do that, but in practice the vsync IRQ line is disconnected on most boards). Luckily the system timer can substitute for that if it's set to the right frequency and phase.
@@x86VileR I tested CGA and EGA modes on "Titus the Fox" game and... EGA and VGA work vsync. But CGA gets the screen tearing on any game/application due to no vsync support. 🙂
@@ricarnuninho80 The technique to do this on CGA is just different, so that depends on the game/app. Some games managed to do CGA hardware scrolling without screen tearing on 4.77MHz IBM PCs: for example Prohibition, Hexsider, Boulder Dash, Spy Hunter, Super Zaxxon. Area 5150 uses a similar idea.
8:35 is impossible with CGA's memory limitations. No "hidden mode" magic can beat this limitation. Also, this isn't a video of a real IBM PC/XT; light reflects the left side but not the right side buttons.
Interesting statements. The image isn't impossible; all 16K shows the top half, and CRTC restarts change the start address on every raster line for the bottom half to refer to the data in the top half. As for not being a real PC, the demo only runs on a real PC, so not sure what you're saying there. The monitor is an IBM 5153, the same monitor we all developed the demo on (and, in fact, the video is of the very monitor viler composed all of the graphics for).
Multiple people have run it on their IBM PCs and XTs with CGA, and it's strange to expect light rays to somehow turn a corner past the CRT bezel and land on the control buttons, but I guess "impossible" is as good a compliment as any!
I can confirm this runs on a real PC (and pretty much only on a real PC or XT or PC portable - edit: see Scali's comment below for another machine that runs it). I have seen it in person. I'm not sure what you mean about the light reflection. Perhaps you could explain. I see light reflecting on the left and right bezel from the screen. It's hard to image how it gets from there to the control knobs. Also VileR, Trixter and I all spent many, many hours figuring out ways to film a real monitor. It should be obvious from the remaining focus, geometric distortion, Moire and brightness issues that this cannot be anything but a real monitor.
@@PCRetroTech There's various other videos on RUclips running it on an IBM 5150, 5155 or 5160. There are also multiple videos that show this running correctly on a Compaq Portable (the first clone we know that is compatible enough to run both 8088 MPH and Area 5150 perfectly, and probably not the last). So if people don't like/trust this one, they can compare with the other videos. Or just grab a machine of their own and run the demo.
Well, if the 5150 and CGA adapter couldn't do all this, then it appears nobody told the makers of this demo and they didn't find out for themselves.
I am actually more impressed by what they did soundwise. Incredible.
Shiru8bit is quite possibly the best composer in the world for PC speaker music. Check out his album System Beeps if you haven't, it's insane
Astonishing. Back in early 1992, my old man brought a PC back from work, as they were chucking it out - an IBM XT with CGA display, two floppy drives, 512K of RAM and a broken hard drive. I was 12, and fascinated by it - but the blocky text, four colour display wasn't going to set the world alight (aside from a Breakout clone which had 16, much to my puzzlement, of course it was using the "160x100" trick). I still used it daily - as a games machine, of course, and eventually managed to find a copy of Windows 3.0 for it. It was unusably slow... you could see the window elements being drawn one by one, and it was in 640x200 mono only.
The following year we bought a VGA card and monitor for it (not that Windows could use it, turns out the VGA driver has 80186 code in it), and I still remember how Prince of Persia went from looking awful to superb, and how sharp the text became. In late 1994 we bought a 486 and the poor old XT was given away to a friend.
Seeing this 32 years on from those days, running on CGA... absolutely incredible. Not only figuring out the various tricks, but implementing them with that painfully slow hardware.... astonishing. A hearty "well done" to the talented coders, for pulling off the seemingly impossible. I can only imagine what the IBM folks would have made of this back in the day!
How is this even possible? 🤯
old school programmers are something else man.
This is so incredibly impressive!
Could such graphical insanity ever be implemented in a CGA game?
The latest release of FastDOOM (a Doom engine port) has added an "ansi from hell" CGA video mode based on the idea from this demo. It won't run on 8088 of course, but the possibilities are out there!
It's much more difficult in a real game. They are relying on techniques like switching colour modes faster than the electron beam can trace across the screen. That's feasible for a demo like this where everything is scripted but much more problematic in a game where you must respond to user input, run game logic etc. Not impossible - the Atari 2600 was so limited in hardware that that was basically the only way to do it - but it does limit your options.
Really love how the CRT compliments the dithering to make this look Amiga esque.
I’m starting to think that the CGA adapter isn’t the bottleneck anymore and that the 8088 is stopping this from being more epic
Yep, with some effects the CPU is the hard limit... things like the rotating 3D objects and the voxel landscape especially. But others are still limited by the CGA's "snow" issue (in those modes you get artifacts if you access video RAM during active raster time, which effectively cuts the bandwidth by a factor of >4).
@@x86VileR A V20 could help alleviate the CPU bottlenecking a wee bit (probably a lot more with an overclock)
For the CGA Snow, dual port ram on the card could fix it, but would require modifying the card or outright replacing it with one designed for dual port ram
Wow what a stunning achievement!
This is the coolest thing I've seen today
back in the 90s i wish i had a cga adapter, but i only had a hercules - now i wish i had that cga card again :)
Here's a revised version:
"This demo, back in 1981, would have obliterated the market, wiping out Apple, Commodore, Tandy, and every other computer maker altogether. There would be no Amigas, no Atari STs, or any other computers-just the PC. Kudos to the team!"
You should've made the monitor fully visible for the complete experience. :) Show off that 5153!
Wanted to, but I couldn't get the right brightness/color balance with ambient room light.. not to mention reflections. That's always one of the trickiest bits for some reason!
AMAZING!
But how ??? Using the CGA connection, not the composite ? And the standard CGA 16KB ????
hax👾
What sorcery is this?! Guess I’ve underestimated the CGA card all this time.
We all did!
Why aren't there any pauses to change floppies?
Double density floppy?
I just discovered your website and channel! I love your retro content! I grew up on DOS and now I use Linux most of the time. I have a love for all things old.
holy shit err, i guess I need to try this out on my 5150 now.
Does it work fine in 512k of RAM?
Is a V20 ok or do i need to whack the 8088-8 back in?
Unfortunately that's a negative to both... it needs some 560k of free RAM. A V20 should play nice with most sections, but some (the end credits and the 'wibbly' image just before it, as well as the rotating 3D objects) rely on cycle-exact 8088 behavior.
How can I run this demo perfectly on DOSBox, DOSBox Staging or DOSox-X?
Would it be possible to simulate 640x400 by using only one pixel of every ANSI a character? Or is that way too CPU intensive for stock 8088?
The CGA can only fetch a new character from VRAM at 8-pixel increments; a new one for every pixel would've required 8 times the bandwidth (and would also exceed the 6845 CRTC's capabilities in terms of clock speed).
What did i just watch, what is this again can someone explain
thats not possible 😲
my geforce 4090 can run this game?
This demo is tooooo hiperlight. 😂😂😂😂🤣🤣🤣 loool
Is it just me or is the audio somewhat desynced?
*Darn you and your refactoring ways!*
The audio and the visuals aren't 100% perfectly synced in the 'party version' of the demo, so it'll drift a bit from one machine to the next; right now certain parts still don't compensate for different media read speeds, but that's something we plan to fix for the final version. I suspect that the CF card in my XT is a tiny bit slower than Trixter's. :)
ooooh
that would explain why I didn't notice that in 86Box, as (at least when I tried it) it didn't support slowing down IDE drives, so they were always running at maximum speed, which is probably pretty close to CF.
also, have you ruled out TSRs slowing down the executable bootup process enough for a desync?
@@FavoritoHJS Nope, haven't ruled that out completely. Most TSRs should have no effect, since irrelevant IRQ channels are supposed to be masked off during disk reads, but it's likely not 100% watertight in this version.
Unfortunately, on a typical 8088 system, any but the smallest TSRs would simply take up too much RAM for Area 5150 to run all the way through... but this will hopefully be optimized in the final version as well.
Niceee ^__^
?!?!?!??!?!?!?!?!?!?!?!! HOW
Impossible!
Your real CGA graphics card works vsync!?????????? No but vsync requires EGA card or newer graphics card.
On CGA vsync can be detected by polling the status register - it just doesn't generate an IRQ (EGA/VGA can do that, but in practice the vsync IRQ line is disconnected on most boards). Luckily the system timer can substitute for that if it's set to the right frequency and phase.
@@x86VileR ok but vsync enabled eliminates tearing. I will test on CGA mode to see if vsync supports or not.
@@x86VileR I tested CGA and EGA modes on "Titus the Fox" game and... EGA and VGA work vsync. But CGA gets the screen tearing on any game/application due to no vsync support. 🙂
@@ricarnuninho80 The technique to do this on CGA is just different, so that depends on the game/app. Some games managed to do CGA hardware scrolling without screen tearing on 4.77MHz IBM PCs: for example Prohibition, Hexsider, Boulder Dash, Spy Hunter, Super Zaxxon. Area 5150 uses a similar idea.
@@x86VileR ok. I'm running DosBox v0.74 emulator. I'll test these examples...
:O
8:35 is impossible with CGA's memory limitations. No "hidden mode" magic can beat this limitation. Also, this isn't a video of a real IBM PC/XT; light reflects the left side but not the right side buttons.
Interesting statements. The image isn't impossible; all 16K shows the top half, and CRTC restarts change the start address on every raster line for the bottom half to refer to the data in the top half. As for not being a real PC, the demo only runs on a real PC, so not sure what you're saying there. The monitor is an IBM 5153, the same monitor we all developed the demo on (and, in fact, the video is of the very monitor viler composed all of the graphics for).
Ye of little faith
Multiple people have run it on their IBM PCs and XTs with CGA, and it's strange to expect light rays to somehow turn a corner past the CRT bezel and land on the control buttons, but I guess "impossible" is as good a compliment as any!
I can confirm this runs on a real PC (and pretty much only on a real PC or XT or PC portable - edit: see Scali's comment below for another machine that runs it). I have seen it in person. I'm not sure what you mean about the light reflection. Perhaps you could explain. I see light reflecting on the left and right bezel from the screen. It's hard to image how it gets from there to the control knobs. Also VileR, Trixter and I all spent many, many hours figuring out ways to film a real monitor. It should be obvious from the remaining focus, geometric distortion, Moire and brightness issues that this cannot be anything but a real monitor.
@@PCRetroTech There's various other videos on RUclips running it on an IBM 5150, 5155 or 5160. There are also multiple videos that show this running correctly on a Compaq Portable (the first clone we know that is compatible enough to run both 8088 MPH and Area 5150 perfectly, and probably not the last). So if people don't like/trust this one, they can compare with the other videos. Or just grab a machine of their own and run the demo.