• Please review our updated Terms and Rules here

Area 5150 for IBM PC 4.77MHz

For more traditional demoscene demos for Apple II, look up productions by French Touch. Some nice cycle counting and use of a mockingboard for music.

The Apple IIGS did have a demoscene back in the 1990s, those are nice too (some 3-D taking advantage of the special fill mode in the IIGS, and some crude modplaying).
 
thanks I will check out french touch.

I have seen the iigs demos and they are quite good.. I just dont categorize them with standard apple ii.
 
The extreme simplicity of the Apple II is a challenge to pull off something that will *wow* a crowd (try finding many TRS-80 Model 1 demos). Add some hardware and you might have something, but I'm not sure how the demo scene judges enhanced platforms. The IIGS has a lot more to work with but is a completely different machine than the original Apple II.
 
try finding many TRS-80 Model 1 demos

I dunno, another take on it might be that it’d be hard to make a better “demo” for the Model I than the best video games by companies like Big 5. It’s kind of shocking how well they play considering the hardware they run on… but I guess they do depend on actually *playing* them to be impressed, IE, the ‘feel’ has to make up for the visuals.

The Apple II does have some potential at least for tricks like mixing video modes on different scan lines, etc, but its lack of features like a vertical interrupt to reliably pace them by is a problem. CGA doesn’t have one either, of course, but there are ways to suss out the timing to cycle count it, I don’t *think* an unmodified Apple II even has that?

(* FWIW, a vertical interrupt happens to be about the only major advantage a non-CRTC PET has over a Model I, and the Model III *does* have a way to indirectly figure out how to cycle count frames, so maybe it’s just a matter of time before a demo coder takes on the challenge.)
 
[...] original IBM PC demos seem to be sucking up so much oxygen in the room lately

...if only!

The relative scarcity of hardware-pushing demos for the Apple II may also have something to do with the machine's design philosophy. Woz made it extremely economical, with a focus on reducing discrete component counts and tailoring the design to the desired capabilities with the absolute minimum amount of fluff possible. It's a testament to his skills, but maybe it also meant there wasn't all that much the hardware could do that it wasn't already doing. IBM on the other hand threw the PC together from 3rd party components, and didn't really concern themselves with the full capability range of Intel's 8253, 8259 or Motorola's 6845 for instance.
 
...if only!

Hah! To be clear, that was intended as a compliment; it at least seems like from the outside things like 8088mph have left everyone gobsmacked in a way that no yet-another-Amiga-or-whatever demo could. ;)

And yeah, I agree with your technical assessment; for what it has to work with the Apple II working at all is practically a killer demo. And on the PC side of the fence, I kind of feel like what happened there is in part people simply forgetting/not ever knowing about all the obscure tricks the original hardware has hidden in it. There were early game programs for the PC that pioneered at least some of this stuff, but between compatibles not necessarily being *completely* compatible and, post-286, the rapid evolution of the platform and throwing new hardware at the problem, the motivation to squeeze the original (specifically) for everything its got has been lacking until fairly recently.
 
Bill Budge made some great programs early on. I think I sold his California PAcific games trilogy disk a few years ago. Still worked and played great. I could see how his stuff would have come across in the late 70's early 80's.
Sorta off topic, but I have to share my Bill Budge history. I had a copy of his Apple II 3D package as a teenager and it set my career direction in motion. In the late '90s I had the opportunity to work with him. Nicest, most humble guy in the world. I tried to convince him to come work with us, but he declined. Years later we chatted and he regretted not joining. Oh well, woulda been awesome.
 
I've tested the demo with the latest MAME 0.246 and the result is not very good, but the demo gets to the late parts:
Hopefully the MAME maintainers will continue to improve the IBM 5150 emulation...

Tested it on DOSBox SVN on my AmigaOS 4.1 machine where it is heard only sound, but the demo is unwatchable.

Thanks for the 720 KB disk image. It helped me a lot for testing it on different emulators.
 
The MiSTer PCXT under development, which uses my MCL86 core, is making steady progress. Check it out:

 
So far, some 8088 CPU-based emulators show that it is very difficult to match the actual 8088 CPU.
As I mentioned briefly earlier, all emulators except for the PCE 5150 do not get close to the 4.77 MHz speed of the 8088 CPU, rather than 20-30% faster, or reproduce the bug features unique to the 8088 CPU, rather than reproduce the bugs. state is being emulated.
Another is that the smooth scrolling function (60 fps, 60 frames) in the CGA card is not implemented properly in the emulator, and it shows a little hard scrolling.
Next is the overscan resolution of the CGA card, which is implemented in the 86box emulation.
 
Just another technical questions about the Marble Madness part, if someone from the team wants to answer it:

- What text mode is used here? 80 or 40 columns? Maybe the 40 column mode has some advantages for this kind of work? I think of things like an effective resolution of 320x200, faster to draw if only because less memory data is moved, no snow at all... Just speculating...

- Could at least some parts of the demo be made compatible with EGA/MCGA/VGA, first detecting the adapter and then, with conditionals or, better, different tables, manipulating the different registers according to each card?

Thanks again!
 
- Could at least some parts of the demo be made compatible with EGA/MCGA/VGA, first detecting the adapter and then, with conditionals or, better, different tables, manipulating the different registers according to each card?
I really have to ask again: what is the point? The demo shows what a CGA-equipped 5150 can do. Doing this on hardware that can show 16 colors (or even more) by default anyway would kill the purpose of the demo.
 
As I mentioned briefly earlier, all emulators except for the PCE 5150 do not get close to the 4.77 MHz speed of the 8088 CPU, rather than 20-30% faster, or reproduce the bug features unique to the 8088 CPU, rather than reproduce the bugs. state is being emulated.
The MCL86 is cycle accurate and emulates these Intel 8088 bug "features". It can even replace the CPU in the motherboard.
 
Just another technical questions about the Marble Madness part, if someone from the team wants to answer it:

- What text mode is used here? 80 or 40 columns? Maybe the 40 column mode has some advantages for this kind of work? I think of things like an effective resolution of 320x200, faster to draw if only because less memory data is moved, no snow at all... Just speculating...

- Could at least some parts of the demo be made compatible with EGA/MCGA/VGA, first detecting the adapter and then, with conditionals or, better, different tables, manipulating the different registers according to each card?

Thanks again!
Some of the effects could be done that way, but a lot of them rely on the fact that the CGA uses the same crystal for a timebase as the CPU and/or the PIT. VGA uses a totally different crystal so the demo would have to spend a lot more time figuring out where the raster beam is.
 
VGA uses a totally different crystal so the demo would have to spend a lot more time figuring out where the raster beam is.

One of the oddities of VGA (and EGA) is they technically support a vertical refresh interrupt on IRQ2/9, but it's rarely used and often isn't even connected on later cards. *If* you had a system where it worked then that would give you a slam dunk way to pace your beam-racers (would even give you a pretty simple basis for correcting your timing loops for CPU speed), but since you can't really rely on it being there a demo that uses it might only work on a small-ish subset of VGA-equipped PCs.

And, as has driven into the ground, it would be really pointless to incorporate as an alternate code path into a demo that's specifically supposed to demo the fixed configuration of a 4.77mhz 5150 or exact compatible with CGA. Maybe if someone wants to write *THE* killer demo for IBM PS/2s it'd be a trick that'd come in handy.

(I'm curious what kind of "beam racing" you could actually do on VGA; is it actually feasible to do some of the same kinds of manipulations mid-frame? Would it be possible to do things like mixing video modes/resolutions?)
 
Looking at the MiSTeR PCXT output, I think I can spot what's causing some of those display issues...
  • 6845 start address latching isn't implemented; on the real chip (and all clones) new start addresses don't take effect until the next CRTC cycle.
  • The ±VIDEO bit in the Mode Select register is also not implemented (port 3D8h bit 3); when it's clear all VRAM reads should be treated as 0s, i.e. black in text mode and the background color in graphics mode.
  • No overscan, although as far as I'm aware no other CGA emulator handles this properly either. Resizing and repositioning the active raster won't work as intended.
And nope, 86box certainly does not implement CGA's overscan resolution, or the H/V sync position registers for that matter...
 
Back
Top