• Please review our updated Terms and Rules here

Area 5150 for IBM PC 4.77MHz

I watched the demo from the Composite connector on my CGA card. My 5160 has a vga card in it so I had to swap it out to see the demo. You know it may be possible to connect a 2 wire CGA composite connector to your cga card. You would need a composite input CRT monitor or a modern LCD TV with a composite input. Worth a shot. Start a thread for it.

Emulation is a complete waste!!!
For DOS computers....
I have been in the console emulation scene since the 486 days.. Back then the most advanced/modern thing I could run would be the Gameboy emulators.... I like emulation.. Certain types.. DOS emulation is pointless.. Because I own several hundred computers.. And DOS computers can be had cheaply.
You really have several hundred vintage computers? I have about 20 and sometimes feel that's too many. I can't even imagine storing hundreds. :oops:
 
This brings up an interesting point: how to develop such a demo. I'm sure most of it was written using modern tools, but does everyone on the team have to have a stock IBM PC where they test their code? Makes for a long development cycle.

I prototyped my portions in dosbox for convenience. Development environment was Turbo Assembler 3.2 (the one that comes with Borland Pascal 7), Turbo Debugger, make, etc. For testing time-critical portions (for example, the loader initializes the 120Hz music with the first interrupt firing just beyond the active display area), I FTP'd code over to my 5160 using mTCP and an Intel Etherexpress 8/16. I chose a period-accurate assembler because I wanted to maintain the ability to debug symbolically on the actual hardware. (I learned later that one modern assembler (fasm?) may have the ability to output symbolic debug info in a TD or codeview-friendly format, but I still like TA for some of its high-level convenience features.)

Other team members did similar things, using open watcom, fasm, nasm/yasm, etc. on a fast system for compilation, assembly, precalc, data manipulation, etc... but then transferred to a 5150 or 5160 for testing. Some used a zip drive, some sneakernet'd a CF card from their Windows laptop to their XTIDE card, and reenigne trumped us all using his xt server.

When you write programs that break emulators, there's no substitute for real hardware. (That said, some portions during development were executable on PCem, so that was used when it supported what we were doing). Heck, part of the development process was figuring out how to get a 5160 to Viler (international shipping) without it showing up in fine metal shards.
 
Last edited:
You really have several hundred vintage computers? I have about 20 and sometimes feel that's too many. I can't even imagine storing hundreds. :oops:

Planning, building shelves, and buying wire metal racks on large coasters is how I have 90+ systems and 40+ monitors taking up a basement crawlspace and about 20 cubic feet of basement space. The coasters on the racks means I can sokoban them around to get access to what I need to pull out. It's doable, although I consider myself at capacity and am looking to downsize one system a month for a few years.

Would be curious to know Verault's layout and situation. That many systems means he probably has a shed, store, or warehouse space.

This is off-topic for this thread, so might be worth starting a new thread, "How you manage your collection" or something. I'm sure there are plenty of prior threads that go into it.
 
You really have several hundred vintage computers? I have about 20 and sometimes feel that's too many. I can't even imagine storing hundreds. :oops:
yeah. about 160. Having a house and lots of shelves helps. I have an office dedicated to alot of them.

I have already started selling off and giving away some to shrink it down. Alot of pickups require you to take everything or nothing. Its easy to get this many. And i dont know how many I fixed up and sold over the years. Maybe 50 to 60. The last few years have been far quieter. Not many purchases.
 
For a couple of additional compatibility data points, it ran on my Compaq Deskpro V-30 but had corruption in the rotating object city scene (only slight at 4.77 MHz), the interlaced Charlie Chaplin/goblin characters and the ending credits. My Compaq Portable locked up after the opening scene with a Tiny Turbo286 enabled but completed everything correctly with the 4.77 MHz 8088.
 
This brings up an interesting point: how to develop such a demo. I'm sure most of it was written using modern tools, but does everyone on the team have to have a stock IBM PC where they test their code? Makes for a long development cycle.
For me it was mostly fasm on my modern desktop, then PCem for quick testing (as far as my own parts of the code are concerned it mostly does the trick), then onto the CF card and into the 5160. For troubleshooting I mainly relied on the internal DOSBox debugger - display rendering may be way off there, but if there were any problems running in PCem or on the real hardware, that was the most convenient/quickest way for me to find out why.

Naturally I had to do some auxiliary development in C or Python for a couple of helper utilities to generate or massage some data. Maybe the least orthodox thing in my toolset was Excel, which I actually used as a dev tool, and probably more often than I should admit - I'm a visually oriented type, and it allowed me to visually "play-test" CRTC settings, bitmap manipulation techniques, etc. on the worksheet itself before translating them into code. It helped me do the latter too in at least one case, by generating a series of assembly instructions for a long unrolled render loop. There's a distinct possibility that I'm nuts, but I still maintain that Excel is demotool #1. 😄
 
The rotating 3D object scene has a couple of IRQ handlers where long sequences of NOPs are used to fine-tune the timing of certain critical code. That's probably why it glitches on a V30 or on a faster 8088 (and in emulators).
 
I prototyped my portions in dosbox for convenience. Development environment was Turbo Assembler 3.2 (the one that comes with Borland Pascal 7), Turbo Debugger, make, etc. For testing time-critical portions (for example, the loader initializes the 120Hz music with the first interrupt firing just beyond the active display area), I FTP'd code over to my 5160 using mTCP and an Intel Etherexpress 8/16. I chose a period-accurate assembler because I wanted to maintain the ability to debug symbolically on the actual hardware. (I learned later that one modern assembler (fasm?) may have the ability to output symbolic debug info in a TD or codeview-friendly format, but I still like TA for some of its high-level convenience features.)
Nice strategy! I guess it's more agile, less tedious than copying trhough CF cards. Do you prefer FTP instead of network drives? (net use et al)
 
Do you prefer FTP instead of network drives? (net use et al)

Yes, because the only way I can seem to get mslanman working is to dedicate 120KB of RAM to TSRs. On a 386+ with upper memory, not terrible, but on 8086-class systems it can be crippling. (And while my 5160 has 704KB RAM and upper memory now, it didn't 12+ years ago when I was developing workflows, so I've stuck to them.) I don't use etherdfs.

For bulk-loading a hard drive after it's been partitioned and formatted on the target hardware, I use a CF card reader on a modern system for speed and convenience.
 
I don't use etherdfs.

FWIW EtherDFS is a good solution with a much lower memory requirement than either MS networking or NFS, but it is a little clunky and you have to be happy with using a Linux server, of course. (If you're developing on a Windows machine you'll have to jump through hoops like sharing the same directory through both EtherDFS to the DOS machine and Samba or whatever to Windows.)

When I want to just shoot a single file to my DOS machine I usually use Netcat, because I'm just that lazy and it doesn't require running a server of any sort. (If it's multiple files I'll package it with ZIP.)
 
EtherDFS doesn't work for my workflow because I thought it used a hard drive image as a backing store, so trying to add files to it is an extra (complex) step I didn't want to go through. Even if that's not the case, I also have some issues with its implementation (doesn't work over wireless, silent corruption is still possible, the TSR is written in C and was very buggy up until the very last iteration, etc.).

Anyway, back to Area 5150 :)
 
Area 5150 is a program that takes full advantage of the features of 8088 CPU (4.77MHz) and original CGA.
No DOS emulator (even DOSBox and 86box) can fully mimic Area 5150.

In particular, smooth scrolling (60fps, 60 frames) is not implemented properly in existing DOS emulators so far.

And the cycle speed of the CPU (4.77MHz) is also the closest to the PCE IBM 5150 emulator so far, and other emulators are slightly faster or do not properly implement the 8088 bug.
(Although PCE implements the bug part closest to the actual performance)

Even if the 8088 MPH runs in the emulator, the degree of perfection feels a lot lower than the actual performance. degree.
In the future, like Area 5150, we are looking forward to more practical programs that are difficult to do perfectly in emulators.
 
EtherDFS doesn't work for my workflow because I thought it used a hard drive image as a backing store, so trying to add files to it is an extra (complex) step I didn't want to go through.

Not exactly. It highly recommends that the source filesystem be formatted as FAT because the server code isn't very smart about attribute handling, but the FAT filesystem is still mounted on the Linux kernel and shared as a directory, so you can definitely copy stuff to it the normal way and potentially share it by some protocol as well. (* To satisfy the FAT thing I was generating FAT-formatted disk images and mounting them with -o loop like the docs suggest when I played with it, but again, once they're mounted you can just copy stuff to them like they're normal disks.)

Strictly speaking there's also nothing explicitly stopping it from being carried over a wireless link, but that's going to depend on how friendly your WAP is to non-IP protocols. (If it works with, say, classic Appletalk DDP then I would think it should carry EtherDFS? *Pretty sure* it worked for me although I guess it's been long enough since I last messed with it I can't say for sure?) It is definitely not routeable, though, so you'll be SOL if you try to use it with, say, a LAN extender-type adapter for your DOS machine that uses NAT or routes to a different subnet. Layer 2 only!

But yes, off topic.
 
In the future, like Area 5150, we are looking forward to more practical programs
Next thing will be a demo dedicated to Olivetti M24 / AT&T 6300 / Xerox 606x / Logabax Persona 6300, Ok? And for those lucky guys having a DEB you can do something in 640x400 @ 16 colors or dual monitor setup...

Oukay? :):cool:
 
Layer 2 only!

Yes, which is why it never worked over a wireless bridge. And other solutions are much faster and cheaper than buying new hardware and reconfiguring my network. Also, I had file access errors when I wasn't using a FAT-formatted filesystem. It's a cute hobby project, but when I am iterating several times a night, I need something reliable.

Next thing will be a demo dedicated to Olivetti M24 / AT&T 6300 / Xerox 606x / Logabax Persona 6300, Ok? And for those lucky guys having a DEB you can do something in 640x400 @ 16 colors or dual monitor setup...

Oukay? :):cool:

Don't hold your breath :) Any demo that wants to be seen will need to run on either emulators or common hardware (I consider the IBM PC common hardware in this hobby). An M24 demo that uses the DEB can be run by only one person that I know of, and there's no point to that. Even using the 640x400x2 mode isn't that appealing because there's only one page of it.
 
I love all vintage hardware demos.. Whats amazing to me is how Apple II and the demoscene just dont seem to have a relationship at all.. I mean the PET now has real demoscene CRED and the APPLE II... yeah not so much. Is it hard to program Demo like stuff on the Apple II?
 
I love all vintage hardware demos.. Whats amazing to me is how Apple II and the demoscene just dont seem to have a relationship at all.. I mean the PET now has real demoscene CRED and the APPLE II... yeah not so much. Is it hard to program Demo like stuff on the Apple II?

Nah, there are tons of demos out there for Apple II family machines. Honestly I think the reason PET and original IBM PC demos seem to be sucking up so much oxygen in the room lately is because both of them seem to have more in the way of "undiscovered talents" compared to more mainstream Demo platforms, in part because of historical neglect.

(I mean, sure, there are a lot fewer Apple II demos than Commodore 64 demos, but I think that reflects both the perceived technical potential of the two platforms and their substantially different user bases.)
 
I guess i could just be naive. Whenevet i search for apple ii demos i find a couple by Deater whom has made tgose recebt demakes like myst and out of this world for apple ii.. anything else i guess i just havent seen anything at all really good to call itself a real "demo" on the apple ii. Be hapoy to have anyone open my eyes to aomething really good.
 
Back
Top