Area 5150: 8088 MPH gets a successor
scalibq.wordpress.com
scalibq.wordpress.com
There were even a few debuggers that used this into the VGA era - program would be on the color monitor and your debugger on the black and white (actually usually orange or green).
The demo Stars by NoooN (https://www.pouet.net/prod.php?which=301) has an easter egg for a combination of VGA and MDA/Hercules: on the monochrome screen, a Snake game appears, which can be played via keyboard while the demo is running.
Design a text and a graphics card, make them have different base addresses so you can have dual monitor. Or allow having an option ROM at a specific address that can hook into the boot process of the BIOS, adding additional boot sources, eg network boot (whatever you can cram into 32k).
Of course this problem is with us even today. PCIE Resizable BAR is a brand spanking new feature, first proposed in 2008, enabling expanding directly mapped buffer from previous limit of 256MB to full capacity of VRAM. AMD tried to repackage it under different name (Smart Access Memory) and upsell as exclusive to only highend brand new parts, Intel new lol GPUs require it to work reasonably fast, but lock out support on non Intel platforms.
Probably a good thing, because then those 'holes' could be used for UMBs...
Then again 8088MHz worked well for me because I lost the RGBI monitor for it at some point and that demo is designed for composite.
Getting files to the PC is an interesting challenge. Have to copy from Windows 10 or 7 to a USB drive and movie that to a PC I have with a serial port and Windows XP and then transfer the demo with Hyperterm in Windows and Telix in MS-DOS on the PC side via null modem.
The one I have has a slot in the backside metal bracket: I can load a Compact Flash (1 GiB, FAT-32 formatted) in a modern PC with a USB adapter, then I insert the Compact Flash in the back of my IBM PC and switch it on with new fresh data and software.
Note that the Compact Flash is seen by DOS (6.2 in my case) as a hard disk drive, you may boot on it. It may also co-exist with an MFM harddrive: in my case, the MFM drive is C: and boots, the Compact Flash is D:.
It is a very convenient setup to make the IBM PC a smooth place in our modern IT world.
I just put a NIC in mine and use the mTCP utilities. Easy as pie :-))
There's one piece of hardware (3.5" hardware emulator) whose clones are popular enough to even have third-party customizable firmware on github!
I own one, but unfortunately, I can't remember the name of this hardware nor the alternate firmware off the top of my head. When I get to a computer I will check my ebay history.
Even though it's physically a 3.5" 'drive,' with the IDC-style connector, the alternate firmware lets you emulate various disk geometries, and I believe the 3.5" and 5.25" signals are electrically compatible.
It's an extremely useful piece of hardware, especially if you're already getting software in the form of floppy disk images from a place like winworldpc.
Unfortunately, many adapters advertise being RS-232 but the specifications go on to say they are TTL. (I'm not sure that's accurate either, but it is the vendor's shorthand for 0 V and 5 V levels.) Some won't say anything at all, which leaves compliance an open question.
Of course, this all depends on sane current limiting behavior from the 12V side. I'm sure there's at least one line driver out there that does a good "gnome swapping terminals on a car battery really fast" impression.
FTDI were good, but they went apeshit with the drivers bricking non-genuine devices, and I don't wish to support them if at all possible.
Prolific have always been troublesome, and their proprietary drivers refuse clones these days (which broke my chinese usb-rs232 dongle).
ch340 is very popular these days, but I've found they have little tolerance for slightly-off or jittery clocks.
I haven't seen a FDD controller in a new motherboard in a very long time. I use GreaseWeazle[0] for my floppy needs.
https://www.newegg.com/rosewill-rcr-fd400-74-in-1/p/N82E1682...
https://web.archive.org/web/20100130173743/http://www.geeks....
My condolences to emulator authors who emulate CGA. :)
In an emulator like DOSBox, only the active raster is rendered, and it attempts to dynamically work out the H/V refresh and aspect ratio. Maybe for historical reasons, since it was originally meant for emulating VGA on a VGA monitor. Same goes for 86box, PCem and MAME... although at least the first two do somewhat better with this demo.
Whereas something like the NES had defined hardware that was mostly identical and so if some feature existed some game somewhere used it.
In NTSC, color is added to the monochrome signal by modulating a quadrature amplitude modulated signal onto a carrier whose frequency is actually within the monochrome image bandwidth itself. NTSC did this for compatibility with black and white TVs of the time. (If that sounds too complicated, it "just" means that changing brightness very fast creates color.)[1]
To get more than 4 colors in CGA, you "just" switch pixels fast enough that you are effectively modulating the color signal yourself! But the problem with CGA is that it doesn't have a graphics mode with high enough resolution to get all those colors. But text mode does, so there's tricks to chop the text lines into pieces which allow puzzling back together a high res image that modulates the color signal.
It's pretty cool.
[1] PAL is the same with a twist, SECAM is very different but "changing brightness very fast" is still accurate.
Dither patterns/"artifact colors" are exactly what I meant, they achieve color by modulating the luminance signal (which is of course the same as "normal" color, but the trick is to let the software influence only the luminance and getting "unintended" colors instead of directly telling the CGA adapter to modulate the color on, and over a separate circuit probably, like what normal 4/16 color mode does).
If you were unlucky enough to have an early model 5150, the board could only take 64k. That limit was however because 4116 memory chips of 16kbit capacity were used. The board could be modified to take the later 4164 chips of 64kbit capacity, in which case it would take 256k. Alternatively, you could use two memory expansion cards to bring the memory up from 64k onboard to 640k total. Although I doubt many people would use such a contraption in practice.
Early model 5150s also required a BIOS upgrade, as a bug would prevent the BIOS from detecting more than 544k of installed memory.
So in theory it is possible to have a 5150 with 640k, and no doubt such machines exist in the wild. But it's probably far more common to find a 5155 or 5160 with 640k. So just like with 8088 MPH I guess that's the 'practical' target of the demo.
I think it came with software to help you use all that RAM, like a print spooler and a RAM drive. The 1987 version of the manual talks about the software on page ix [1].
(I also noticed the manual mentions you can enable/disable parity checking. I wonder if that would let me leave 1/9 of the chips out since I have a few bad chips and have to use less than 640KiB currently. I should just try to source some replacement chips though.)
Fun fact: The 8-Bit Guy (from YouTube) used to work at AST.
[1] AST SixPakPlus manual (PDF) http://vtda.org/docs/computing/AST/000490-001A_SixPakPlusUse...
However I think everyone is going to have to temper expectations regarding what this will run on. Even my effects (the 3D Glenz objects) couldn’t be debugged on an emulator even though it’s a fairly simple tricked up video mode and a bunch of fairly ordinary assembly code doing VRAM writes that are not timing critical for the screaming fast 3D.
I'm a little older and spent a nontrivial amount of time on CGA, so this demo absolutely blew my mind.
Of course, it's never too late to write some wares for XT... I'd prefer to get an actual XT for that, though. I'd fear that if I only ever tested on emulators or clone machines, I would end up writing code that doesn't work on any actual XT :)
Getting the samples to output at the correct time during the end titles required a painstaking amount of cycle-counting, measuring, and iteration.
Use DOS 3.30 and FORMAT /S a blank floppy, copy APPEND.EXE to the floppy, and copy as many of the AREA5150 demo files as will fit. Then copy the remaining files to a second floppy. Put first floppy in A: and boot off it, put second floppy in B:, and then run APPEND B: followed by AREA5150. Behold, it works!
You absolutely do need the full 640K of RAM though, refuses to run with only 512K.
If that exceptional talent and art-code were distributed in the 1980's, obvioulsly they would have had a large effect in many extends (inspiration to others on the platform, definition of new compatibility levels...), but what about distribution?
I feel the demo would have had very limited distribution due to the very restricted platform target: real IBM 5150/5155/5160 with original IBM CGA.
I think people of the time would probably have tried to make it work on a larger base since maybe 80% of XTs were not IBM's...
My question: what video modes and tricks are solid across most XTs and CGA cards of the era? I guess the 640x200 text mode with 8x2 chars is solid, but what about the other tricks? How portable are they?
Why not making a selection of 3 or 4 very popular and very different hardwares of the time as a target platform. For instance I think of IBM 5150 CGA + Tandy 1000 + Amstrad PC1512...
I have a VGA XT clone (4.77/8 MHz) and an ATI Small Wonder CGA clone board. I will try to bind them together and run Area 5150.
Although while working on this one, I couldn't help noticing that the IBM CGA (5153) monitor wasn't showing things quite as expected. That led me down another rabbit hole: https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
This can also be automated with pattern-matching, where you convert an image to glyphs by algorithmically selecting the nearest match.
Or even take a modern computer, use an fb driver and just make the best demo you can. No 3D graphics, just a framebuffer
I guess as capacity of the machine increase, so does the exponent on the required effort to move limits beyond the obvious. In some way this demo demonstrates that.. The Commodore64 was/is ahead of the 5150 in the demoscene stuff in multiple ways, for instance, it has a more capable soundchip, (I have a hard time imagening better sound coming out of a pc speaker, but again, this is an "obvious" limit, and there's no saying that someone can't hack the pc speaker to do cooler stuff than what's currently being done on the SID chip), other "obvious" advantages of C64 is that the VIC has sprites and scroll registers, but this demo blows some of that out of the water..
In other words, there will be the "obvious" solutions that anyone can see (and their related limits).. More advanced thinking leads to less obvious solutions (moving the known limit), and even more advanced thinking leads to even less obvious solutions (and so again, moves the known limit).
There is definitely a place for the types of demos that you are talking about. Some of them are being made, though the introduction of artificial constraints is common (e.g. the size is limited to 64 kB or 4 kB). There is even value in creating the best demo you can, even if it doesn't impress the demoscene, simply because showing what you can do will likely exhibit skills beyond those of a run-of-the-mill developer.
I suppose there's a wee bit of physics if you want to fine-tune the results for a particular CRT monitor... not that we've really done much of that for the party-version, but there's some research on the original IBM 5153 CGA monitor at https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale....
Our toolset for this demo did include an image converter (CGAArt), which can in fact use several version of the CIELAB formulas for its metric, among others. That's by reenigne from our team, who has commented here so I'll let him elaborate on it if he wishes. Personally when I do this sort of artwork, I prefer to tailor it by hand to the target video mode; as you noted, certain parts were indeed converted programmatically, but a lot of that was down to time constraints prior to the party release. In the final version, I plan to rework/redo those.
However, for the purposes of Area 5150 I think the differences between sRGB interpolation and linear RGB interpolation would have been too subtle to notice since there are only 6 * 16 * 16 = 1536 dithered colour/pattern combinations to choose from in the first place - the error introduced by that quantisation is likely larger than the sRGB vs. linear RGB difference. But I used linear RGB anyway, just to be correct about it.
Could you explain how linear interpolation is different from sRGB interpolation? I would have thought they were the same thing. If by sRGB you mean interpolating but being lazy about gamma, I'll be the first to admit that's just plain old incorrect, even though laziness is sometimes a virtue.
Also are you one of the demo authors? If so we could probably move this conversation to Discord or email and we could try some more blending methods!
I'm not sure what you're doing with the colour mixing on that page but I'm wondering if you're just applying a gamma curve to the mixed result. This is what I meant:
sRGB interpolation:
r_final = r_1*x + r_2*(1-x)
g_final = g_1*x + g_2*(1-x)
b_final = b_1*x + b_2*(1-x)
linear RGB interpolation: r_final = 255*((((r_1/255)^2.2)*x + ((r_2/255)^2.2)*(1-x))^(1/2.2))
g_final = 255*((((g_1/255)^2.2)*x + ((g_2/255)^2.2)*(1-x))^(1/2.2))
b_final = 255*((((b_1/255)^2.2)*x + ((b_2/255)^2.2)*(1-x))^(1/2.2))
The real gamma correction formula is actually slightly more complicated than that because it's linear up until the sRGB value is about 10 then then follows a ^2.4 curve but the difference is too small to notice.https://www.bricklink.com/v3/studio/design.page?idModel=4450
Thus not XT class, but PC class.
The main differences between 5150 and 5160 are: 5160 upgraded from 5 to 8 ISA slots (also changing the size of the bracket, which has been the standard ever since, even today with PCI-e 5.0). 5160 removed the cassette port. 5160 came with a harddisk as standard (and as a result, a more powerful PSU, as the stock PSU of a 5150 was insufficient for a HDD, and generally required an upgrade).
Memory-wise, there are various different revisions of 5150 and 5160 boards, which can take different amounts of memory onboard. For the 5150, the early revisions took 16k-64k, the later revisions took 64k-256k. For the 5160, the early revisions took 64k-256k, the later revisions took 256k-640k. In all cases it is possible to add additional memory up to 640k via an ISA card. So it is possible to have a 5150 configuration with the full 640k that the most high-spec 5160 had.
Then there is also the IBM 5155, the 'portable' PC. This is essentially a 5160 motherboard in a modified case, with an integrated CRT. As such, it is also fully compatible with the 5150 and 5160, and can run these demos flawlessly.
This was true at release but the 5160 was eventually available in a configuration with no hard drive and dual floppies.
Was there any performance difference if you added memory in an ISA card as opposed to directly on the motherboard?