Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for August, 2015

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.

Advertisements

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

casIt’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, many people like to try the online slots for casino gaming, they usually visit nj online casinos but like to have a previous experience.

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. By the way check out Gaming Headset Reviews which will help you decide which one is the best for you.  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?

(We were having a chat with a friend from the OnBlast blog, and I too 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 »