im still to this day amazed on how smooth the video output is and how clean the audio sounds coming out of a computer around the same age as an nes i ran the demo on dosbox and its unbelievable how good it looks and sounds
@Vicinity If I understand the blog posts correctly, the TL;DR of how it works, is that instead of decoding a compressed video file into a stream to the video memory, the XDV file itself is the decoded stream, which means there's very little overhead (relatively speaking, this actually uses something like 90% of the cycles on a 4.77MHz CPU), but it takes a lot of space on the hard drive. Bad Apple is 20MB (absurdly large for the early 80's), and that's 1-bit video with a 22KHz audio track, that streams from the hard drive at 150KB/s (slower on MFM hard drives, this is probably running from a CF card). That entire show is about 31 MB on the disk, and for the early-mid 80's, this was basically your entire hard drive. You only need to write to the video memory the bits which change, which is why some of the quicker full-screen motion has a tearing effect, because you can only read/write the changes so fast, and you need to be clever in how you trick the eye into perceiving fluid motion. Jim will probably come along and correct me somewhere.
You're mostly correct. :-) 150KB/s is the maximum rate needed by the demo, which is not sustained in all sections; it's buffered into RAM, so a typical 90KB/s MFM drive (if the interleave is set properly) should still be able to play it. (And if it can't, it pauses gracefully to buffer for a second or two.) While 20MB for the Bad Apple video may seem large, keep in mind the system was designed for maximum framerate above all else. I could easily get that down to 15MB by going with a data format instead of x86 code, but there would be a 5 to 10fps speed penalty depending on how complex the frame changes are. And I could get the audio portion down from 4MB to 1MB by encoding the audio with a simple 256-entry VQ codebook of 4-byte entries, but would take additional time to decompress realtime (maybe another 5fps) and would also degrade the audio quality a bit. So nearly halving the video size and still having it play realtime is possible, but the framerate would be cut nearly in half in complex sections, and that wasn't the focus of the design.
In my defense, some Bad Apple conversions for vintage systems have stored 100% raw uncompressed frames into 60MB of data and require playback using a homebrew adapter and flash card, so being able to run on any system's period-correct hardware is a win, in my humble opinion.
@@JimLeonard yeah i think its worth it, especially nowadays with xt to ide adapters makign it possible for pc of this era to hold gigabytes or storage. it was very well done especially considering the jump between corruption and domination. keep up the good work, man!
@@JimLeonard It might interest you to know that I've been using badapple.xdv to quick test a bunch of Sharp LH2464 memory chips (64k x 4) on one of my XT's as a means of quickly weeding out which ones are bad. It's quicker than firing up CheckIt, and if there's a memory error, it shows up pretty quickly.
Honestly, the Demoscene pulls off so many amazing technical feats that I sometimes find myself wondering if there's ANYTHING that can't be done on a computer.
The XDC Compiler/Player (used to create 8088 Domination) are the main tools I'm using on my 5150. Out of all the demos you created, this is the most useful and one of my favorites.
I'm assuming you wrote all of the source code in C or assembly you must know an awful lot about old computers at a very low level to have done this Audio and visuals this smooth and good sounding is something I'd never expect from anything to be done in software ran on old hardware
Is the apparent tearing due (particularly in the B&W segment) to the video camera recording the screen, or was that due to one of the shaving options you mentioned in the write-up?
Neither; it's actually due to how the system degrades the video to deal with out-of-bandwidth conditions. The largest changes are always plotted first; then, if a quality threshold is not yet met, the new timeslice is spent making more changes to further reconstruct the frame. If the quality threshold IS met, then any remaining changes are dropped and a new frame begins. The "tearing" you're seeing is when there simply isn't enough bandwidth (cpu time + memory speed) to "paint" an entire frame, and what you see is the best decisions the encoder could come up with. I could have increased the quality by using more bandwidth but I was afraid of exhausting it during the presentation, which would have resulted in a pause.
Oh, gosh no. That couldn't be farther from the truth. The demoscene is a very unique, unto itself european-centric culture. I just chose Bad Apple because 1. It was going around on all platforms anyway, and 2. It was perfect test material to show off the capabilities of the software.
Well, after watching 8088MPH, and now this, and having tried both on my Tandy 1000 HX, I've come to the conclusion that the Tandy times it's composite output differently than the IBM PC/XT does, because the colours I get over composite don't look nearly as good.
@@JimLeonard Why does that not surprise me. Tandy did all kinds of dirty little tricks to make their machines affordable, that always lay out of sight until you try delving into the hardware. Like IRQ 5, for instance? If you delve into the schematics on the early Tandys which have Tandy Graphics, the IRQ 5 pin on the 8259A is triggered by the vertical sync pulse, of all things. IRQ 6 and 7 are hardwired to the onboard floppy and printer controllers (which can't be disabled), and that's why only IRQ's 2,3 & 4 are wired to the expansion bus, except on the SX and TX, which have dip switches to disable that and allow IRQ 5 to be used. I haven't been able to find a lot of documentation on it, but I think that IRQ5 (the V-sync pulse) is used to time pallet switching between frames, or something. I'm completely fuzzy on the details.
@@BlackEpyon IRQ 5 It's tied to v-sync because that's what the IBM PC junior did, and the Tandy 1000 was meant to be an enhanced clone of the IBM PC junior. That's why it's graphics and sound are also the same as the PC junior. A hardware vertical sync interrupt can be used for pallette changes, switching display pages, or updating the sound registers every frame.
@@JimLeonard And here I thought that IRQ 5 was supposed to be a cost-saving measure. Never tried to take a close look at the PC-Jr schematics to be honest... They're a complete mess, and you can tie yourself in knots trying to get from one end to the other. They're not quite identical though, both worked with the 0xB8000 & 0xBC0000 memory blocks a bit differently. Something about Tandy being able to address 32K directly from 0xB8000, where the PC-Jr could access 16K at 0xB8000, and had to do a reach-around to get the next 16K from 0xBC000? Not too clear on why that is. The Tandy is a bit more straight forward on it's memory management.
They are powerful enough to render almost anything you want, which makes it much less impressive when it renders something like Tron Legacy. The impressive stuff comes under limitations, like 64 kilobytes file size.
@@immibis Oh, there will be limitations. Imagine what computer hardware will be able to do in 30 years from now. It will be a challenge to backport the same visuals to the mentioned hardware.
@@Aranimda An RTX 3090 calculates 40 teraflops. It's hard to think of anything that can fully utilize one, short of a large AI, a weather simulation, or just turning up the quality way settings way past the point you can't tell the difference. New effects will come from cleverer coding - hardware won't be a limitation. I do expect to see a generation of neural-network-based demos though.
So does this work like h264? Since the playback is stuttering in huge changes ( I read the last comment that mentioned the stripes ) and h264 only updates the video only when something changes
@@JimLeonard Thanks! I've been looking for that for ages. Please mention it somewhere! And at the "Not just graphics..." it's Power Up (Psy Craft Remix), and everyone knows the rickroll and Bad Apple.
@@YuutaTogashi0707 In 1981, NEC's Terminal Units Division of the Information Processing Group launched the personal computer series N5200, which was branded as the "personal terminal". It used an Intel 8086 processor and a µPD7220 display controller. Its architecture was similar to that of the PC-98, but it mostly ran the proprietary operating system PTOS. Components from N5200 were reused in PC-98.
I was like: "If they port bad Apple with graphics mode I'm about to lose my mind",
And they did.
Clicked for bad apple, got rickrolled.
lol :D
Lol hahahæ
Næ I say!
3:19
get Rick rolled in 1981 IBM PC xD
Dos PCs: I have 3D games I can run i-
8088: *Introducing Bad Apple*
When people tell me they can't do something because the hardware is too slow, I link them 8088 Domination.
Pop goes the speakers! :-)
instablaster...
im still to this day amazed on how smooth the video output is and how clean the audio sounds coming out of a computer around the same age as an nes
i ran the demo on dosbox and its unbelievable how good it looks and sounds
@Vicinity If I understand the blog posts correctly, the TL;DR of how it works, is that instead of decoding a compressed video file into a stream to the video memory, the XDV file itself is the decoded stream, which means there's very little overhead (relatively speaking, this actually uses something like 90% of the cycles on a 4.77MHz CPU), but it takes a lot of space on the hard drive. Bad Apple is 20MB (absurdly large for the early 80's), and that's 1-bit video with a 22KHz audio track, that streams from the hard drive at 150KB/s (slower on MFM hard drives, this is probably running from a CF card). That entire show is about 31 MB on the disk, and for the early-mid 80's, this was basically your entire hard drive. You only need to write to the video memory the bits which change, which is why some of the quicker full-screen motion has a tearing effect, because you can only read/write the changes so fast, and you need to be clever in how you trick the eye into perceiving fluid motion.
Jim will probably come along and correct me somewhere.
You're mostly correct. :-) 150KB/s is the maximum rate needed by the demo, which is not sustained in all sections; it's buffered into RAM, so a typical 90KB/s MFM drive (if the interleave is set properly) should still be able to play it. (And if it can't, it pauses gracefully to buffer for a second or two.)
While 20MB for the Bad Apple video may seem large, keep in mind the system was designed for maximum framerate above all else. I could easily get that down to 15MB by going with a data format instead of x86 code, but there would be a 5 to 10fps speed penalty depending on how complex the frame changes are. And I could get the audio portion down from 4MB to 1MB by encoding the audio with a simple 256-entry VQ codebook of 4-byte entries, but would take additional time to decompress realtime (maybe another 5fps) and would also degrade the audio quality a bit. So nearly halving the video size and still having it play realtime is possible, but the framerate would be cut nearly in half in complex sections, and that wasn't the focus of the design.
In my defense, some Bad Apple conversions for vintage systems have stored 100% raw uncompressed frames into 60MB of data and require playback using a homebrew adapter and flash card, so being able to run on any system's period-correct hardware is a win, in my humble opinion.
@@JimLeonard yeah i think its worth it, especially nowadays with xt to ide adapters makign it possible for pc of this era to hold gigabytes or storage. it was very well done especially considering the jump between corruption and domination. keep up the good work, man!
@@JimLeonard It might interest you to know that I've been using badapple.xdv to quick test a bunch of Sharp LH2464 memory chips (64k x 4) on one of my XT's as a means of quickly weeding out which ones are bad. It's quicker than firing up CheckIt, and if there's a memory error, it shows up pretty quickly.
Honestly, the Demoscene pulls off so many amazing technical feats that I sometimes find myself wondering if there's ANYTHING that can't be done on a computer.
@Vikrinox That's the printer's fault.
@Vikrinox I dunno, computers print money legally for the treasury/mint.
I mean there's the halting problem...
@@danmakufan Seems like they're limited only by what's mathematically impossible, doesn't it?
@@Roxor128 yea
I remember the speakers popping every time the DAC turned on and off on the original SoundBlaster I had many years ago.
not a single dislike... Touhou fans are literally so much bizzare than jojo itself.
I mean yeah, jojo is only bizzare through punching with his stand
So many pop culture references...
And using Bad Apple of all things :D
If this is done on prettyuch a pocket calculator, makes you really wonder about current games "optimizations" and CPU requirements. VERY well Done
Daniel Witzel If PC games were as optimized as this, you could run crisis on windows 2000 and get 144 fps
@@liquidcontainers The OS doesn't really matter all that much.
Pate Jate it doesn’t, i made that comment a year ago
More like Crysis on hardware made for Windows 2000, which would be impressive.
Nintendo games are pretty well optimized. Breath of the Wild looks stunning, and it's basically running on average smartphone hardware.
The XDC Compiler/Player (used to create 8088 Domination) are the main tools I'm using on my 5150. Out of all the demos you created, this is the most useful and one of my favorites.
This is extremely well done! I recently build a 286 16mhz and playing this on it made me almost cry!
I'm assuming you wrote all of the source code in C or assembly
you must know an awful lot about old computers at a very low level to have done this
Audio and visuals this smooth and good sounding is something I'd never expect from anything to be done in software ran on old hardware
Correct! You can read more at trixter.oldskool.org/2014/06/19/8088-domination-post-mortem-part-1/
0 dislikes. Well deserved.
This comment hasn't aged well...
@@Slamm1n-Salm0n Dang it
2:37 beautiful moment
agree
Превосходная оптимизация!
I love the Bad Apple Music video and running on something like this is awesome!
2:55 Touhou is in everywhere
i like how ppl clapped at the rickroll one
istg if its a bad apple port on graphic mode I AM GOING TO LOSE IT
edit: DUDE.
This is really inspiring
Is the apparent tearing due (particularly in the B&W segment) to the video camera recording the screen, or was that due to one of the shaving options you mentioned in the write-up?
Neither; it's actually due to how the system degrades the video to deal with out-of-bandwidth conditions. The largest changes are always plotted first; then, if a quality threshold is not yet met, the new timeslice is spent making more changes to further reconstruct the frame. If the quality threshold IS met, then any remaining changes are dropped and a new frame begins.
The "tearing" you're seeing is when there simply isn't enough bandwidth (cpu time + memory speed) to "paint" an entire frame, and what you see is the best decisions the encoder could come up with. I could have increased the quality by using more bandwidth but I was afraid of exhausting it during the presentation, which would have resulted in a pause.
VIDEO??? On a 8088, even not 8086? Unbelievable...
seeing bad apple just makes me think...
is the demoscene just full of lowkey weeaboos
Oh, gosh no. That couldn't be farther from the truth. The demoscene is a very unique, unto itself european-centric culture. I just chose Bad Apple because 1. It was going around on all platforms anyway, and 2. It was perfect test material to show off the capabilities of the software.
@@JimLeonard Huh. neat. guess touhou does make its way through every part of culture...
Well, after watching 8088MPH, and now this, and having tried both on my Tandy 1000 HX, I've come to the conclusion that the Tandy times it's composite output differently than the IBM PC/XT does, because the colours I get over composite don't look nearly as good.
Correct, Tandy systems have a 180-degree rotated phase from CGA cards.
@@JimLeonard Why does that not surprise me. Tandy did all kinds of dirty little tricks to make their machines affordable, that always lay out of sight until you try delving into the hardware. Like IRQ 5, for instance? If you delve into the schematics on the early Tandys which have Tandy Graphics, the IRQ 5 pin on the 8259A is triggered by the vertical sync pulse, of all things. IRQ 6 and 7 are hardwired to the onboard floppy and printer controllers (which can't be disabled), and that's why only IRQ's 2,3 & 4 are wired to the expansion bus, except on the SX and TX, which have dip switches to disable that and allow IRQ 5 to be used.
I haven't been able to find a lot of documentation on it, but I think that IRQ5 (the V-sync pulse) is used to time pallet switching between frames, or something. I'm completely fuzzy on the details.
@@BlackEpyon IRQ 5 It's tied to v-sync because that's what the IBM PC junior did, and the Tandy 1000 was meant to be an enhanced clone of the IBM PC junior. That's why it's graphics and sound are also the same as the PC junior. A hardware vertical sync interrupt can be used for pallette changes, switching display pages, or updating the sound registers every frame.
@@JimLeonard And here I thought that IRQ 5 was supposed to be a cost-saving measure. Never tried to take a close look at the PC-Jr schematics to be honest... They're a complete mess, and you can tie yourself in knots trying to get from one end to the other.
They're not quite identical though, both worked with the 0xB8000 & 0xBC0000 memory blocks a bit differently. Something about Tandy being able to address 32K directly from 0xB8000, where the PC-Jr could access 16K at 0xB8000, and had to do a reach-around to get the next 16K from 0xBC000? Not too clear on why that is. The Tandy is a bit more straight forward on it's memory management.
@@BlackEpyon It was an oversight, IMO, during the design of the PCjr. Tandy fixed this, and other oversights, when they made the 1000.
Ngl the glitch effects just makes it better
What is the pop sound?
Does it play when the compressed video is loaded on to the RAM?
The pop sound was the result of reinitializing the sound card between each video, and was rushed programming on my part.
@@JimLeonard Alright, thanks!
2:36 friends likes Rick rolled
Skip here at 3:22
I was like: "If they port bad Apple with graphics mode I'm about to lose my mind",
And they did.
@Dobr 2021
43 years old processor, never thought that it would work, but it does :3
That you algorithm for this video.
There's a saying that goes "when you have 2 colours, you can make Bas Apple."
Image what the demoscene geniuses can get out a Core i9 with RTX card in 30 years.
Just bought mine last month. Start the countdown.
They are powerful enough to render almost anything you want, which makes it much less impressive when it renders something like Tron Legacy. The impressive stuff comes under limitations, like 64 kilobytes file size.
@@immibis Oh, there will be limitations. Imagine what computer hardware will be able to do in 30 years from now. It will be a challenge to backport the same visuals to the mentioned hardware.
@@Aranimda An RTX 3090 calculates 40 teraflops. It's hard to think of anything that can fully utilize one, short of a large AI, a weather simulation, or just turning up the quality way settings way past the point you can't tell the difference. New effects will come from cleverer coding - hardware won't be a limitation.
I do expect to see a generation of neural-network-based demos though.
2:36 and I was already rick rolled
surprising that they managed to generate color without too much overhead
not a single dislike. never seen that before.
Check out my other videos on TheOldskoolPC channel -- very few dislikes there too :)
(of course, having said that, I probably jinxed it)
2:36 Get Rick rolled in a original IBM PC xD
So does this work like h264? Since the playback is stuttering in huge changes ( I read the last comment that mentioned the stripes ) and h264 only updates the video only when something changes
No, way less power than h.264. Google "8088 domination" to see a series of blog posts that explain the method.
@@JimLeonard What music was used?
@@immibis Power Up by Space Cat
@@JimLeonard Thanks! I've been looking for that for ages. Please mention it somewhere! And at the "Not just graphics..." it's Power Up (Psy Craft Remix), and everyone knows the rickroll and Bad Apple.
Video: Bad Apple
Me: Jaming
Now let's play Bad Apple on a CASIO watch\!~ :D
👏
Will nerds be making 2022 computers play 64K video in 2047?
Human eyes can't see 64K. It might be 200fps VR though.
woa, only 76 comments, im early, expect more to come.
What, was this video mentioned somewhere?
@@JimLeonard made it to the front page.
@@justminibanana9128 Of what?
@@JimLeonard of youtube
Rick Roll @ 2:36
;)
The IBM PC wasn't the best X86 microcomputer in 1981 i.e. NEC PC-98
PC-98 came out in 1982, not 1981.
pc-98 was 82
@@YuutaTogashi0707 In 1981, NEC's Terminal Units Division of the Information Processing Group launched the personal computer series N5200, which was branded as the "personal terminal". It used an Intel 8086 processor and a µPD7220 display controller. Its architecture was similar to that of the PC-98, but it mostly ran the proprietary operating system PTOS.
Components from N5200 were reused in PC-98.
3:22
Roblox 0:45
Minecraft worst game
what
Wtf
bruh what
ur channel banner is literally minecraft 💀
@@fakedutch_ its a joke lol