Oldskooler Ramblings

the unlikely child born of the home computer wars

An experiment: Should I put on a show?

Posted by Trixter on October 11, 2015

I’m trying to gauge whether it would be worthwhile to produce a podcast dedicated to the IBM PC and other compatibles of the 1980s. (The actual date range may slip slightly later than 1989 on rare occasions for special topics.) Rather than go into a long diatribe of what I’m looking for and what would be covered, I’ve created a short survey you can take instead. The data collection is anonymous (no logins/accounts or personally-identifiable information is required), and you also get to see the aggregated results after you complete the survey. For anyone who knows me and my work who is interested in both vintage IBM PCs and podcasts or YouTube channels/videos, it would help me out if you took a minute to give me your opinion via the survey.

The survey link is: https://www.surveymonkey.com/r/RK6Q25S

If you’d rather just give me your thoughts in the comments below, that’s fine too, although it may help to glance at the survey text first to see what I’m going on about.

Posted in Uncategorized | Leave a Comment »

Solving an IBM PS/2 Model 25-286 Chicken and Egg CMOS problem

Posted by Trixter on September 4, 2015

I solved something recently and thought others (read: vintage computer nerds) might be interested in the write-up. I recently acquired an IBM PS/2 Model 25-286 and wanted to read data off of the hard drive.  The 25-286 relies on configuration data stored in CMOS, however the battery-backed CMOS is dead, leading to the error codes 161 and 163 on boot-up. The system miraculously boots from the hard drive just fine in this condition (documentation suggests the hard drive table is fixed to a single entry). But, you can’t transfer data off of a system in this condition because 1. The floppy drive table is wrong and thinks the 1.44MB drive is a DSDD drive and can’t read/write a 1.44MB diskette, and 2. There are no entries in the BIOS table for the built-in serial and parallel ports, so they don’t show up, can’t use MODE COM1, etc. Short of physically moving the hard drive into another system, there’s no way to get data in/out of it.

The obvious fix is to write the 8525-286 diag and setup diskette somewhere and boot it to set proper CMOS values, but the diag/setup diskette image is a 1.44MB image, and the system can’t read it because the scrambled-CMOS configuration only reads/writes DSDD disks. So this is where the chicken-and-egg problem lies: To fix the system, you need to boot a diskette — but the diskette isn’t bootable until the system is fixed. (There’s another issue: Since the battery is dead, the setup disk will set proper values, perform a warm reboot — and then the values are gone again since the battery is dead.)

Armed with the knowledge that that the system can read 720KB diskette media just fine if formatted in another computer, I was able to follow this procedure to temporarily force a functional system:

  1. Use tweener system to write out the 8525-286 diag/setup diskette from diskette image
  2. Copy resulting setup/diag files onto a 720KB DSDD diskette (NOT a 1.44MB diskette formatted as 720KB).
  3. Boot Model 25-286 from internal hard drive
  4. Run the “SC.EXE” program from the setup/diag disk
  5. Using SC.EXE, force correct values, then save them.
  6. Hit <ESC> to back out to DOS (do NOT hit enter to reboot the system)
  7. Perform an immediate, non-cold, non-warm reboot by issuing INT 19H (instructions below) — do not have bootable diskette in the drive, and for safety have an empty config.sys and autoexec.bat

Doing this will leave the system in a correct state until you perform a warm (ctrl-alt-del) or cold (power) reboot. DOS will reload and parse the new temporary CMOS values.  The floppy drive reads/writes 1.44MB in this state, and the serial and parallel ports are recognizable and function. While I wrote this, I was archiving the entire hard drive to another system using FastLynx and a parallel-port cable.

The proper fix, of course, is a Dallas 12887+ replacement battery/clock chip. Three are already on their way to me from China (hope they aren’t pulls!).

To issue INT 19H, you can use DEBUG.COM. Start DEBUG, then type:

a <enter>
int 19 <enter>
g <enter>

Posted in Vintage Computing | Tagged: | 6 Comments »

Converting a newer CGA card to an older one

Posted by Trixter on August 28, 2015

I don’t normally just reblog stuff, but Great Hierophant’s blog entry on how to convert a “new-style” CGA card to an “old-style” card is worth taking a look at.

Why would you want to do this?  Slightly brighter output is a plus, and to run the most earliest games that support composite color output as their authors intended.

Posted in Vintage Computing | Leave a Comment »

See you at the Vintage Computer Festival Midwest 2015!

Posted by Trixter on August 27, 2015

The tenth edition of VCF Midwest takes place this weekend!  Admission is free, so if you’re west of Chicago or anywhere near Elk Grove Village, IL, please join us as we once again coax vintage electrons into motion!  For full information, consult www.vcfmw.org.

My contribution this year is a vintage IBM set up running 8088 MPH on continuous loop, and I’m also giving a talk on how 8088 MPH came together.  It’s less of a technical talk and more of a “how did you guys find each other and decide to work on a demo?” talk.  If the video stream works, I’ll publish a link to the stream and the slide deck after the show.

Posted in Uncategorized | Leave a Comment »

Still no love for the IBM PC

Posted by Trixter on August 23, 2015

It’s been 2.5 years since I talked about how there’s no love for the IBM PC, and not much has changed.  I’ve discovered one more youtube channel that covers 808x-era games (dfortae’s game reviews), but that’s it.  There are still no podcasts that cover the first decade of the PC; even the Retro Computing Roundtable hardly mentions it.

What has changed in 2.5 years is my understanding of why that is.  I think the 808x-based era (8088 or 8086 computers that are IBM PC compatible, 1981-1989) is mostly overlooked because both the system and its users are stuck between worlds.  Let’s start with the IBM PC itself:

  • Is it a home computer or a business computer?  It was a business computer for the home, so try classifying that one.  It definitely had business-class power and expandability (and price tag), but also had BASIC in ROM, cassette tape support, and could connect to home televisions.
  • Is it an 8-bit or 16-bit computer?  It came out squarely in the middle of the 8-bit era, and had an 8-bit bus and an 8-bit path to memory.  But, the 8088 is internally a 16-bit CPU, with 16-bit registers and a 16-bit ALU,  Most people categorize it as a 16-bit computer and part of the 16-bit era, but considering the Atari ST and Amiga are the poster children for the 16-bit era, it doesn’t feel like it should be in that category as it is significantly less capable than those systems.
  • When was the system considering viable for gaming?  There were games available for the system in the same year it was launched, but many people consider games with ugly CGA graphics or text-only adventures a party trick and not actual games.  I disagree, but ask most online people what “DOS games” are and you’ll get a picture painted in a VGA palette.

The users/fans/retrohobbyists of the PC are also stuck between worlds:

  • Generation Y Millennials grew up with the web, blogging, social media, YouTube… but the IBM PC was not their system, so they don’t cover it.  Most old PC gaming channels on YouTube, for example, consider “MS-DOS Gaming” as starting in the era of 386+VGA+soundcard systems.  These are good channels, don’t get me wrong (Pushing up Roses, Lazy Game Reviews, Ancient DOS games, DOS Nostalgia come to mind), but they only rarely cover the first decade of PC gaming.  That’s 10 years of games not getting coverage — quite a gap.
  • So that leaves us Generation X’ers to cover it, because we did grow up with the PC… but, there are two forces working against early PCs getting coverage.  The first is that Gen X people also grew up with other systems.  The second is that not every Gen X’er is comfortable doing a podcast or video channel.  So out of the few that are, the attention is spread across all 1980s systems (including consoles), leaving a tragically small slice of people who are both capable and motivated to do so for the early PC.

Come on, I can’t be the only one.  Won’t someone start a 1980s-era PC podcast or YouTube channel?

(I thought the original classic Mac would have this problem too, but a cursory search of the interwebz shows a plethora of websites dedicated to classic macs, and even a retro mac podcast coming up on its 376th episode.  Yikes!)

Posted in Vintage Computing | Tagged: | 19 Comments »

Rave Movie Rundown

Posted by Trixter on August 14, 2015

I was a clubber in Chicago from 1988-1990.  (Medusa’s on Sheffield, anyone?)  I exited right when rave music was overtaking house music, but I caught the first wave for a tragically brief period and loved it: The transition from Kraftwerk to New Beat to Acid to Techno to EDM; chillout rooms; bringing the DJ from behind the booth to front and center… it was a great time to lack responsibilities.  (Before you ask:  No drugs.  The whole ecstasy movement was primarily a UK thing that wasn’t very prevalent in the USA.)

Rave culture peaked at the end of the 1990s.  There were a lot of films made for and about raves back then (and one recently) that try to capture what that period was like.  Unfortunately, most of them use raves as a backdrop instead of a character, but there are two notable standouts that are worth your time if you have any interest in raves:

  • Pump Up The Volume: The History Of House Music, 2001:  A BBC 3-part documentary that takes great pains to interview everyone involved in the birth and growth of House, which obvious had a lot of overlap with raves.  An excellent piece of research with tons of interviews and stock footage.  Out of all factual pieces that try to cover this period, this documentary gets just about everything right.
  • Groove, 2000: A fairly predictable story of several people trying to get to a rave, what happens when they get there, and how their lives intertwine… but unlike most fictional films that feature raves, Groove gets the feel of rave culture almost exactly right.  People aren’t dressed like caricatures, the music is great, raves are busted by the police, only to spring up somewhere else the same night, the light drug use is portrayed accurately, etc.  Most importantly, the DJs are played by actual local DJs who spin their own music (Digweed shows up at the end to drop the entire place to the ground with Heaven Scent).  The characters are a little cliched, but is the most accurate (fictional) portrayal of American Rave culture I’ve seen.

If you want entertainment, see Groove; if you want historical accuracy, see Pump Up The Volume.  I highly recommend both.

There are other rave culture movies.  They range from interesting to mostly bad.  Here is a partial list, in descending order of quality, with my subjective comments:

  • Weekender, 2011:  A fictional account of the early 1990s rave scene as rave migrated from Ibiza to the UK.  This particular movie centers around the Manchester scene as two friends try to turn raves into a business.  While this movie got bad reviews, I actually enjoyed it.  More importantly, the early 1990s house music choices are mostly period-correct.
  • A Midsummer Night’s Rave, 2002:  An attempt to tell Shakespeare’s A Midsummer Night’s Dream via rave culture.  The rave sections are fairly true, but the sound mixing is somewhat awful and a little distracting: The music mix isn’t loud enough during the dance scenes, so you hear their voices echo off the walls; just as distracting, the music is completely non-existent in the chillout room (there is always a dull thoom-thoom-thoom in the chillout room).  The actual storytelling is competent, being copied from Shakespeare.  An acquired taste.
  • Rave, 2000:  An amateur effort.  Plot and characterization are cringe-worthy, as is most of the acting.  Despite the title, the rave is essentially a club with bouncers.  Avoid this one.

Stark Raving Mad, Human Traffic, Sample People, and One Perfect Day were initially on the list, but I took them off because they portray clubs instead of traditional raves.  Go is not on the list because I haven’t seen it yet.

Did I miss any?  Disagree with my picks?  Leave me a comment.

Posted in Uncategorized | 3 Comments »

Comedy gold in the Handy specification

Posted by Trixter on August 12, 2015

The Atari Lynx is my favorite handheld console.  Planning and design started in 1986, long before the Nintendo Game Boy, but development took long enough that it was actually released half a year after the Game Boy.  Whether or not that makes it the first or second handheld console is up for discussion, but it was definitely one of the first two.

History shows that the Lynx had an unsuccessful run compared to other handheld consoles of the time, which includes the Game Boy, Game Gear, and TurboExpress.  Lynx’s failure in the market was split fairly evenly between three culprits:

  1. Price: $179 vs. Game Boy’s $100
  2. Battery life: It took 6 AAs to power the unit for only 4 hours
  3. A lack of compelling licensed or original titles

The first hardware revision was also somewhat large, but as a guy with large hands, that never bothered me.

There were some killer arcade ports to the Lynx that really showcased what the system was capable of, such as Road Blasters, Stun Runner, and Klax.  But these were ports of Atari games; Lynx never got the “big” licensees such as Mortal Kombat or Street Fighter (a double shame considering the Lynx supported true hardware multiplayer linkups).

I recently sought out the Lynx hardware specification so that I could reminisce, sadly, about all of the untapped power Lynx had that was never realized.  The Lynx was so powerful that it shamed other handhelds for nearly a decade after it was discontinued:

  • 4096-color palette
  • Unlimited sprites with scaling, clipping, and collision (multiple modes!) all performed in hardware
  • 4-channel stereo sound supporting both algorithmic and sampled waveforms (in other words, it could play both pure-hardware chiptunes and Amiga mods)
  • Multiplayer cable connections up to 8 simultaneous players/units
  • Supported left-handed play via the ability to flip the screen

There were other cool bits for the time it came out too, like a limited 32-bit math-coprocessor (used for some true 3-D polygon games like Hard Drivin’ and Steel Talons).  It wasn’t perfect; the system would slow down if you pushed it too hard (too many sprites, too many sampled sounds playing simultaneously), but it was creative and ambitious.

The Lynx started life as a hardware project by Epyx, initially called “Handy” (because it was to be the first handheld console).  Ex-Amigans RJ Mical and Dave Needle were involved in the design, which is why Handy feels like a tiny Amiga.  The initial specification was written in June of 1987 by Dave Needle.  Reading through it, two things are immediately evident:

  1. The designers of Handy had a passion for creating a fun device with as many progammer assists as possible
  2. Dave had a wry sense of humor

I will now reproduce for you some of the comedy gold hiding in the Handy specification.  I’ve truncated some sequences for brevity, but the words are all Dave’s:

The human input controls consist of a 4 switch (8 position) joy stick, two sets of 2 independent fire buttons, game pause button, 2 flablode buttons. power on, and power off….Flablode is a Jovian word meaning a device or function that we know is required or desired but for which we don’t have an actual definition (noun: flabloden, verb: to flablode).

3. Software Related Hardware Perniciousness
(or why some software people hate some hardware people)

There are certain things that the software ought not to do to the hardware. While these things are not physically destructive on their own, they will cause the hardware to act unpredictably strange, which may cause the user to be physically destructive. While we certainly could have protected the system from many of the following problems, I doubt that we would have found them all. In addition, the act of software doing one of these things means that there is a problem in the software anyway and the intended function would probably not happen. Additionally, this is only a toy. If this unit were a bio-medical device I would have found a safer solution.

3.1 Don’t Do These Things.

If you do any of the things that I tell you not to do, the hardware will act unpredictably and will not be expected to recover without a complete system initialization. So don’t do them.

3.1.5 Palettes and Page Breaks

This one is an actual hardware bug of mine…(much technical info removed)…Pen index numbers C,D,E, and F will be incorrectly unchanged. Sometimes I am such a jerk.

3.2 Please Don’t Do These Things.

There are also things that software people do that merely annoy the hardware people rather than annoy the end user. This includes seemingly harmless activities like sub-decoding bit values from byte descriptions (sprite types, for instance), or assuming address continuity between areas of hardware…Please don’t do them. It would be difficult to list all of the possibilities, so I will list the general considerations and ask you to be sensible about them. In addition, please feel free to submit a request for an exemption-on a specific case. If it is granted, we will change the specification so as to make the special case forever legal. The price will be small.

3.3 Do It This Way

Some of the hardware functions, as designed by us mindless brutes, require special handling. As we discover these requirements, I will list them here.

4.3 CPU Sleep

BIG NOTE: Sleep is broken in Mikey. The CPU will NOT remain asleep unless Suzy is using the bus. There is no point in putting the CPU to sleep unless you expect Suzy to take the bus. We will figure out how to save power some other way.

All hardware collision detection is done with the data in the collision buffer, not the data in the video buffer. This has obvious advantages and will be explained at seminars and in newsletters forever….In addition, the software can either do its own collision detection, or use the contents of the collision buffer for some weird collision detection algorithm. In either event, I will be mortally offended.

In addition, this means that when some of the bytes are not reloaded, the length of the SCB will be smaller by the number of bytes not used. If I have said this in a confusing manner, then I have.

Well, I finally found the bug that required a pad byte of 0 at the end of each scan line of data. But, It is actually 2 bugs. I have fixed one of them, but the other requires an extensive change. Too bad, I am out of time. Therefore: There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all Os. Don’t forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry.

This bit can be used to pause the sprite engine. The ‘unsafe’ condition of the internal registers is not directly affected by this bit.

I need to think about how to use it.

Receive parity error can not be disabled. If you don’t want it, don’t read it….We have just discovered that the calculation for parity includes the parity bit itself. Most of us don’t like that, but it is too late to change it.

11.7 Unusual Interrupt Condition

Well, we did screw something up after all. Both the transmit and receive interrupts are ‘level’ sensitive, rather than ‘edge’ sensitive. This means that an interrupt will be continuously generated as long as it is enabled and its UART buffer is ready. As a result, the software must disable the interrupt prior to clearing it. Sorry.

11.8 left out

I left something out. I know what it is but by the next time I revise this spec, I may have forgotten.

I have forgotten.

12.1.4 Bugs in Mathland

BIG NOTE: There are several bugs in the multiply and divide hardware. Lets hope that we do not get a chance to fix them.
1. In signed multiply, the hardware thinks that 8000 is a positive number.
2. In divide, the remainder will have 2 possible errors, depending on its actual value. No point in explaining the errors here, just don’t use it. Thank You VTI.

12.4 Qbert Root

As a compromise between the square root and qube root desires of the software people, and the schedule desires of the management, we have decided to incorporate the function of QbertRoot. The required steps are:
1. Start a 16 by 16 multiply.
2. Immediately write to ‘E’ which will try to start a divide.
3. Read the result from “D,C,B,A’.

(editor’s note:  I can’t tell if QbertRoot is an actual function, or trolling.)

16. Known Variances From Anticipated Optimums
This is a list of the known bugs in the hardware.

…It will be OK to write to the twentyfour 16 bit registers of the Suzy SCB PROVIDING that you only do it via the MACRO PROVIDED TO YOU BY RJ MICAL. In addition, you must understand that the contents of this macro may change if future revisions of the hardware so require. In addition, you must understand that future hardware may make the process not work and therefore the macro will be changed to be a warning that you can’t use it anymore.

Don’t cheat.

My personal favorite, saved for last:

7.3 Stereo

The 4 audio channels can be individually enabled into either of the two output drivers. This is not now in the hardware. It may never get into the hardware. After all, I hate music. However, since I acknowledge that I am wrong about some kinds of music (in the right circumstances, with me not present) I have graciously allocated one entire byte for the possible implementation of another useless and annoying sound feature.

(For the record, that feature did go into the hardware, in the second hardware revision of the Lynx.  If you have the later hardware, some audio is in true stereo.)

If all hardware/technical documentation was written this way, I’d be an embedded systems programmer by now.

I’ve scanned and OCR’d the full Handy specification for anyone wanting to learn more about the Lynx.  There’s a compo-winning demo hidden in the hardware, just waiting to be found.

Posted in Gaming, Programming, Technology, Vintage Computing | Tagged: | 1 Comment »

Final version of 8088 MPH released

Posted by Trixter on August 2, 2015

The crew is happy to announce a final version of 8088 MPH. Primary changes are improved compatibility with hardware, and some effects have vastly improved graphics.

And yes, it still breaks all your emulators.

Posted in Uncategorized | Leave a Comment »

The Great Irony

Posted by Trixter on July 26, 2015

I am very active in one area of the electronic entertainment digital archival movement.  Prior to that, I co-founded MobyGames, and prior to that, I was a major factor in getting abandonware off the ground.  For two decades, I’ve spent more time handling games than playing them.  This is the great irony of working in this field, like the composer who is so busy writing music that he doesn’t have time to listen to any new music.  It is a quick way to become myopic.

When my team won the oldskool compo at Revision, I felt like I could finally exhale and relax in my hobby time.  So, what happens when you’ve been putting off games for several years while you work on other projects?  This happens:

capture_26072015_221547 capture_26072015_221557 capture_26072015_221606 capture_26072015_221610

The game archivist finally spent 210 hours of free time playing games.  Felt really good to use those muscles again.

Now that that is out of my system, time to return to more traditional projects!  (At least, until Fallout 4 is released.)

Posted in Uncategorized | 2 Comments »

Aftershocks and future plans

Posted by Trixter on June 23, 2015

After dropping the mic in April, I’ve been suspiciously quiet, haven’t I?  Truth be told, I got a little burnt out.  Winning Revision was a dream come true, but afterwards my free time and I really needed a break.  I ended up playing a LOT of games on the bucket list (Skyrim, Broken Age, replayed Fallout a 7th time) and generally caught up on movies.  So, sorry I’ve been quiet.

Some random interesting things that happened between then and now:

Since 8088 MPH, the crew has been working slowly but steadily on a final version that improves the sound and video quality a little, but more importantly, works on a wider range of hardware (ie. you should be able to use any CGA card instead of the first IBM revision).  Clone 6845 chips might also be compatible with the final version; we’re working on it.

As for me specifically: Before the end of the summer, you will see at least one of the following three things from me:

  1. An article series exploring the PC speaker and how to thoroughly abuse it (has information relevant for other platforms too, most notably lightweight compression/decompression schemes)
  2. A method to much more easily enjoy vintage games on vintage systems
  3. A vintage PC podcast (I’m still flabbergasted there aren’t any!)

Suggestions welcome if you’d like to nudge me in a particular direction.

Posted in Uncategorized | Leave a Comment »


Get every new post delivered to your Inbox.

Join 554 other followers