Відео

There aren't any voxels in this demo but there is a voxel landscape effect in the follow-up demo, Area 5150.

I believe it has been run correctly on the 86Box and MartyPC emulators. The latter (by @GloriousCow) was built with running this demo in mind - hence the BTTF-inspired name!

Yes, that's exactly what I did. The encoding of the images on the tape is described as RF (presumably because the frequencies involved are high enough to be described as Radio Frequency). VCRs have test points that can be tapped to monitor this signal encoded for tape, and I tapped them.

There are some technical details at www.reenigne.org/blog/rotating-fractals/ and www.reenigne.org/blog/rotating-fractal/

😱

MY CAKES WILL BURN!

The Kefrens bars sequence is made by a routine that is precisely timed to synchronise to the raster beam (by counting cycles - it takes exactly 304 CPU cycles for the beam to complete one raster line). The phrase "racing the beam" is also meant to put one in mind of Atari 2600 coding, where there is no frame buffer. There is no frame buffer as such in this effect either - just two scanlines worth of buffer which is repeated down the screen. Each scanline the contents of the line buffer is changed slightly so that the image varies vertically down the screen. DMA is not involved here (the PC/XT has a DMA chip but it's not useful for this purpose). An H-blank interrupt of sorts is possible by setting the timer period to the right length but the interrupt overhead would not leave sufficient time to do the VRAM updates so counting cycles is the only way. Hence this was the most difficult effect in the demo for emulators to get right.

@@andrewmjenner The slightest variation in timing an instruction in the emulator (or failing to enforce video/CPU timing synchronization), and you'd write to the "buffer" in the middle of rendering a scanline, hopelessly corrupting the output?

@@eddievhfan1984 Pretty much, yes. If the per-scanline code doesn't take exactly 304 cycles then the points along the scanline where the buffer updates are done will drift to the left or right as the beam moves down the screen, leading to tearing. And then the routine might be desynchronised for the next frame as well.

@@andrewmjenner TBH, I thought if the writing routine interfered with transmitting the sync signals from the CRT controller, it would basically cause the monitor to go haywire. Either way, a true testament to optimization and riding the edge of the hardware. Good on ya.

@@eddievhfan1984 The horizontal sync signals are still timed by the CRT controller and are not affected by the effect code. The effect code does takes over responsibility for the timing of the vertical sync signals, though, reprogramming the CRT controller at the top and bottom of the visible frame. So if the timing is wrong then the monitor might lose vertical synchronisation. We were concerned that this could damage monitors (hence the timing test at the beginning and warning if the hardware doesn't seem to be cycle identical with the original PC or XT). However, we have since learnt that this kind of monitor damage is not really possible in practice so the warning is probably redundant. Thanks!

That is quite impressively dedicated - thank you! I hope you will find some other interesting things to do with it as well.

@@andrewmjenner Back here! forgot about my own comment, yes, I found other use cases and I got a healthy collection during these years. I even got a Sony PVM monitor in order to be able to see the demo at it's best (not only because of that, but was an important factor). Fantastic fantastic.

Hope you enjoy the latest offering too!

@@andrewmjenner As soon as I have time, I'll install it and enjoy it!!!!! Seen the live video, is awesome!

Parts of the VCR are emulated, parts are real. The tape and heads are real, but the process for decoding the data coming from the heads and turning it into a visible image is done in software. It is not a huge step to go from there to a completely emulated VCR - I just haven't implemented it yet. It's something that I'd like to do at some point, though.

@@andrewmjenner I bet you'd be able to digitize the magnetic signals from the tape and emulate the heads, and then try to run it through the decoder.

@@eribetra Well, to digitize the magnetic signals from the tape you need some heads to get the signal off the tape and into an electrical signal that can be sampled. Which is what I am doing in this video - the source digitized signal is the one coming right off the tape heads (after they are combined into a single signal). It's possible to emulate the tape and heads as a system but not really just one or the other as emulated heads can't read physical tape and physical heads can't read emulated tape.

@@andrewmjenner So then you emulate the tape & heads, alongside everything you've already done, and then it's basically a completely emulated VCR?

Almost. The other part is that this is only a decoder so far - an encoder would be needed as well but that's just a matter of reversing the steps of the decoder. An interesting thing to do would be to add various real-world imperfections to the emulation, like dropouts, tape stretching, and the heads being misaligned with the data on the tape (and emulating the servo mechanism to get it back in synchronisation).

Emulators don't tend to do a good job with this demo since it relies on exact cycle counting and other low-level trickery. There are certain builds of 86box which have been able to run it, though.

The IBM PC was designed to compete with microcomputers like the Commodore PET, Atari 400/800, Apple II, Tandy TRS-80 and various CP/M machines. All of which were used in the home as well as the office. The fact that the PC (with CGA card) was designed from the beginning to be able to use an NTSC TV set as a monitor (hence the 4.77MHz CPU frequency) suggests that home use (i.e. games) was a market that IBM had in mind. In fact, one game (Microsoft Adventure) was a launch title for the PC. It's true that 8088 is a bit more powerful than the 6502 but not as much as you might suspect from the 8/16 bit difference - both machines had an 8 bit memory bus which was in practice usually the bottleneck (but the 8088 has a more space-efficient and powerful instruction encoding). As for more RAM: not really! The first PC's motherboard supported configurations of 16kB-64kB inclusive (it is a bit cheeky of 8088 MPH to use 640kB which would have been technically possible in 1981 but unusual and expensive).

I'm not entirely sure about the size-efficiency of the instruction sets of 8088 vs 6502. I suppose it depends on what you want to do. 6502 has the zero-page, which allows for very compact instruction encoding. There are also more common instructions that fit into a single byte than on 8088. Sure, you will need more instructions for the same code in many case, but I'm not sure if that balances out in the 8088's advantage.

@@Scalibq I had a recent example in mind: the fast Mandelbrot code I wrote over at vcfed in May. The inner loop was 23 bytes of 8088 code, and the corresponding 6502 code was 97 bytes. Granted that uses a lot of 16-bit arithmetic which the 8088 is particularly well-suited for (and the 6502 is particularly ill-suited for) but I think the 8088 has an advantage for 8-bit data types too (albeit a smaller one). In particular, a single 2-byte instruction can encode two 3-bit register numbers and a 3-bit ALU operation on 8088, whereas on 6502 you'd need two 2-byte instructions to address two zero page locations. But don't take my word for it - I encourage you to pick a little routine, optimise it for 8088 and 6502 and see which wins.

Doom is tricky because of the floors and ceilings - they need quite a lot of divisions to calculate, which are really slow on 8088. I reckon a pretty decent Wolfenstein 3D could be done on this hardware though.

@@andrewmjenner - What about a lookup table for translating coordinates? Or would that need to be prohibitively large?

@@Roxor128 Yes, prohibitively large tables is the problem. Doing walls with lookup tables isn't too bad because you can consider each vertical slice separately, and essentially have a table in which you can lookup the texture Y coordinate by screen Y coordinate and distance (which is manageable). Because you can rotate in the plane parallel to the floor there is orientation to consider as well as position - the lookup table method would just have too many inputs.

@@andrewmjenner - Ah, so you'd basically run into the fact that you'd need three or four dimensions of array data, which would easily eat up more memory than could be spared on a machine of the era.

The party version at ua-cam.com/video/yHXx3orN35Y/v-deo.html has 213K views at the time of writing...

Thank you for the kind words! If you're interested in how the multi-channel PC speaker music was done, I did a detailed write-up at www.reenigne.org/blog/8088-pc-speaker-mod-player-how-its-done/ .

Thanks, its a fun reading, you're amazing) Once I was shocked when heard cubic player playing the MOD with the volume modulation on pc speaker's but it was on 386... not sure I understood the physical process behind it, but I could guess that a diaphragm has its inertion so if we set bit to 1 it goes -1 and bit 0 it goes +1 if we do it really fast the diaphragm will stop somewhere between 0.3 and starts to head to -0.3 . Looks like PWM is another way to solve it - by thinking in time domain rather than amplitude domain. I.e. we assume that diaphragm moves fast enough but allow it to oscilate in small time slot ____||___

The PWM output is actually the easy bit (lots of other programs have done PWM playback on this hardware in the past). Yes, if you want the speaker at position x% of its range then you program the timer to output "high" for x% of the time and "low" for (100-x)% of the time. If the pattern of highs and lows repeats quickly enough then all the frequencies other than the desired ones will be out of the range of human hearing (or the ability of the speaker to reproduce) and you'll hear the desired sound. PWM just means that for any given cycle we put all the high bits together and all the low bits together in a single pulse of variable (modulated) width, which is easy for the timer chip to do and the carrier isn't too audible if the cycle length is short enough.

I see so PWM is just like a regrouping of pulses within the cycle. And indeed its not the most exciting stuff in the demo )) I like so many things in it amazing precise CRT ray timing control and many other neat tricks like raster font generator control etc. I used to write 386 asm and did some neat tricks with vga memory. For me it started from the Commander Keen and its smooth background scrolling on EGA. Sadly those days are gone and there's no practical use to these skills. I could imagine how many amazing games and demo experiences could be written if moore's law was frozen... What felt magic in 1990x now is just a niche wizardry for geeks.... And the modern hardware is too powerful and too abstracted out of the direct programmer's control...

Standard CGA is 240p no matter what year it is...