Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for the ‘Programming’ Category

« Previous Entries
Next Entries »

At a disadvantage

Posted by Trixter on June 4, 2011

Quick, without doing any research: What early 1980s computer was faster, the IBM PC or the Commodore 64? The IBM PC ran an 8088 at nearly 5MHz, whereas the C64 ran a 6502 variant at 1MHz. The PC cost thousands of dollars, the C64 hundreds. The PC had a 1 megabyte address space; the C64 only 64K. Is this a trick question?

It is!  The C64 was faster.  The original IBM PC, despite appearances and bias on the part of both consumers and marketing, was actually the slowest popular personal computer on the market at the time of its release, even compared to the Apple II and Atari 400.  Here’s why.

The 8088 holds an uncomfortable position between the realm of 8-bit and 16-bit personal computing; while the internal word size was indeed 16-bit, the 8 in 8088 means that its external data bus was only 8 bits wide.  This means that the 8088 could only access one byte of data in a single bus operation, giving it speeds much more like an 8-bit personal computer than a 16-bit one. Normally this is no big deal; the 6502 used in the C64 had the same limitation.  But unlike the 6502, which could access a byte in a single cycle, the 8088 took 4 cycles to access that same byte.  Another way of looking at this: every time memory is touched, the 8088 wastes 75% of its cycles, effectively turning the IBM PC from a 4.77MHz computer into a 1.1925MHz computer.  This gave it a “lead” of only 0.1695 MHz over the C64.

If it still had a slight lead, then why was it slower?  While the 8088 could indeed operate on 16 bits at a time, the machine instructions were between 2-4 bytes large, and only the simplest instructions took 2 cycles to execute.  Contrast that with the 6502, where most instructions are 1 byte large and most execute in 1 cycle.

Let’s illustrate this with a fun example:  Rotating a byte of memory once using ROR (rotate right). We’ll keep it fair by treating the PC like it only has a single 64K segment of memory. First, the 6502 version using ROR:

Cycle Operation
1 fetch opcode, increment program counter
2 fetch low byte of address, increment program counter
3 fetch high byte of address, increment program counter
4 read from effective address
5 write value back and do operation
6 write the new value to the effective address

6 cycles. Now the 8088 version:

Cycle Operation
1 ROR BYTE PTR [1234],1 expands to “D0 0E 34 12” so let’s get to fetching the opcode:
2 (still fetching…)
3 (still fetching…)
4 (still fetching…)
5 (still fetching…)
6 (still fetching…)
7 (still fetching…)
8 (still fetching…)
9 Fetch lowbyte of address
10 (still fetching…)
11 (still fetching…)
12 (still fetching…)
13 Fetch hibyte of address)
14 (still fetching…)
15 (still fetching…)
16 (still fetching…)
17 Perform operation, which takes 15 cycles + EA calculation (6)
… …
37 Final cycle of calculation, we’re done, yay :-/

What took 6 cycles on the C64 takes 37 cycles on the IBM PC, no thanks to the slow memory access of 4 cycles per byte. Taking both machine’s clock speeds into account, this means the operation takes about 6 microseconds on the C64 and about 8 microseconds on the IBM PC.  It can get much worse than that, especially if you’re foolish enough to access more than a single 64K memory segment.  IBM PC is teh suck! (*)

The gap between the IBM PC and the Atari 400 is even wider, if you can believe that, because the Atari 400 ran the 6502 faster (1.78MHz) than the C64 (1.026 MHz).  The BBC Micro?  2MHz!  It’s painful to think about!

Ever wonder why there hasn’t been a true demoscene demo on the original IBM PC aside from three scrollers (all Sorcerers releases, btw)? Well, now you know one major reason. (Lack of decent graphics is another; in fact, I’d be willing to argue that only the Apple II had slower graphics.)

(*)Yes, I know the 8088 has 4-byte prefetch queue that sometimes speeds things up.  That comes in handy, oh, almost never.

Posted in Demoscene, Programming, Uncategorized, Vintage Computing | 43 Comments »

When you reach the top, keep climbing

Posted by Trixter on March 15, 2011

(Rather than break up the discussion, I’ve edited this entry with the promised timing information at the end of the post.)

First off, you owe it to yourself to check out Paku Paku, the astonishingly great pac-man clone written by Jason Knight.  Why astonishingly great?  Because, as a hobbyist retrogaming project, it does everything right:

  • Uses a 160×100 16-color tweakmode on CGA, PCjr/Tandy, EGA, VGA, and MCGA, despite only VGA being capable of a truly native 160×100 resolution
  • Plays multi-voice sound and music through the PC speaker, Tandy/PCjr 3-voice chip, Gameblaster CMS, and Adlib (yes, CMS support!)
  • Runs on any machine, even a slow stock 128K PCjr
  • Has convincing game mechanics (ghosts have personalities, etc.)
  • Comes will full Pascal+ASM source code

This is just as good a job, if not better, than I like to do with my retroprogramming stunts.  Very impressive work!

One of the things I love about coding for the 8088/8086 is that all timings and behavior are known. Like other old platforms like the C64, Apple II, ZX Spectrum, etc. (or embedded platforms), it truly is possible to write the “best” code for a particular situation — no unpredictable caches or unknown architectures screwing up your optimization. Whenever I see a bit of 808x assembly that I like, I try to see if it can be reworked to be “best”.  I downloaded Paku Paku just as much for the opportunity to read the source code as for the opportunity to play the game (which I did play, on my trusty IBM 5160).

On Mike Brutman’s PCjr programming forum, a discussion of optimizing for the 8088 broke out, with Jason giving his masked sprite routine inner loop as an example of how to do things fast:

lodsw
mov  bx,ax
mov  ax,es:[di]
and  al,bh
or   al,bl
stosw

It takes advantage of his sprite/mask format by loading a byte of sprite data and a byte of the sprite mask with a single instruction, then it loads the existing screen byte, AND’s the sprite mask out of the background, OR’s the sprite data into the background, then writes the background data.  It takes advantage of many 808x architecture quirks, such as the magic 1-byte LODS and STOS instructions (which read a word into/write a word out of AX and then auto-increment the SI or DI registers, setting up for the next load/store) , and the 808x’s affinity for the accumulator (AX, for which many operations are faster than for other registers).  In the larger function, it’s unrolled, specialized for the size of the sprite.  It’s pretty tight code.

However, one line (“MOV BX,AX”) bugged me, as it also bugged the author:

The sprite data format is stored as byteMask:byteData words which I point to with DS:SI for LODSW… which I then move to BX (which sucks, but is still faster than MOV reg16,mem; add SI,2) so I can use bh as the mask and bl as the data.

So, was that code “best”?  Is there no faster way to write a masked sprite in 160×100 tweaked text mode on the 8088?

First, let’s look at his original code, with timings and size:

lodsw            16c 1b
mov  bx,ax       2c  2b
mov  ax,es:[di]  10c 3b
and  al,bh       3c  2b
or   al,bl       3c  2b
stosw            15c 1b
--------------------------
subtotal:        49c 11b
total cycles (4c per byte): 93 cycles

On 8088, reading a byte of memory takes 4 cycles, whether it’s “MOV AX,mem” or the MOV instruction opcode itself. That’s why smaller slower code can sometimes win over larger faster code on 808x. So it’s important to take the size of the code into account when optimizing for speed.

Some background knowledge of how Paku Paku works can help us:  The game does all drawing to an off-screen buffer that mirrors the video buffer, and when the screen needs to be updated, only the changed memory is copied to the video buffer.  Because Jason does all drawing to an off-screen buffer in system RAM, and the video buffer is smaller than the size of a segment, you have room left over in that segment to store other stuff. So if you store your sprite data in that same segment after where the video buffer ends, you can get DS to point to both screen buffer AND sprite data. Doing that lets us point BX to the offset where the sprite is (it was originally meant to be an index register after all), and use the unused DX register to hold the sprite/mask. We can then rewrite the unrolled inner loop to this:

mov  dx,[bx]     8+5=13c 2b ;load sprite data/mask
lodsw            16c     1b ;load existing screen pixels
and  al,dh       3c      2b ;mask out sprite
or   al,dl       3c      2b ;or sprite data
stosw            15c     1b ;store modified screen pixels
inc  bx          3c      2b ;move to next sprite data grouping
--------------------------
subtotal:        53c     10b
total cycles (4c per byte): 93 cycles

Although we saved a byte, it’s a wash — exactly the same number of cycles in practice.  However, since he is already unrolling the sprite loop for extra speed, we can change INC BX to just some fixed offset in the loop every time we need to read more sprite data, like this:

mov dx,[bx+1]
(next iteration)
mov dx,[bx+2]
(next iteration)
mov dx,[bx+3]

By adding a fixed offset, we can get rid of the INC BX:

mov  dx,[bx+NUM] 12+9=21c 3b ; "NUM" being the iteration in the loop at this point
lodsw            16c      1b
and  al,dh       3c       2b
or   al,dl       3c       2b
stosw            15c      1b
----------------------------
subtotal:        58c      9b
total cycles (4c per byte): 94 cycles

We shaved two bytes off of the original, but we’re one cycle longer than the original.  While the smaller code is most likely faster because of the 8088’s 4-byte prefetch queue, it’s frustrating from a purely theoretical standpoint.

Reverse-engineer extraordinaire Andrew Jenner thinks two steps ahead of me and provides the final optimization that not only gets the cycle count down, but frees up two registers (DX and SI) in the process.  He writes only what is necessary, and since we need to skip over every other byte when writing in 160×100 mode, manually updates the DI index register to do so.  The end result is obtuse to look at, but undeniably the fastest:

mov ax,[bx+NUM]  12+9=21c 3b ; “NUM” being the iteration in the loop at this point
and al,[di]      9+5=14c  2b
or al,ah         3c       2b
stosb            11c      1b
inc di           3c       1b
----------------------------
subtotal:        52c      9b
total cycles (4c per byte): 88 cycles

…successfully squeezing blood from a stone.

Is this truly “best”?  I think so.  But to prove it, we have to time the code running on the real hardware.  Thanks to Abrash’s Zen Timer, we have the following results:

  • Jason’s original code as listed above, repeated three times to plot a 5×5 sprite:  48 microseconds
  • My code block, three times with [bx], [bx+1], [bx+2]: 41 microseconds
  • Andrew’s optimization, also written with [bx], [bx+1], [bx+2]: 37 microseconds

And just to make your head spin, check the comments for this entry — the resulting discussion shows that if you’re willing to rearrange both your sprite data and your thinking, you can get things even faster!

Posted in Gaming, Programming, Vintage Computing | 24 Comments »

It’s been a long time

Posted by Trixter on March 21, 2010

I was explaining my demoscene “heyday” activity to someone and thought that what I wrote might be interesting to about four people.  Four qualifies as a blog post, plus I’ve been neglecting the blog because I’ve been completely decimated by my day job.  So here we go.

My demoscene background was always the PC.  I did some cracktro programming — badly — in the late 1980s, but the American cracking scene didn’t have a concept of cracktros->demos until roughly 1992 (hi Tony!).  I officially discovered the demoscene proper with The Space Pigs Megademo in late 1990.  (The page has a demoscene.tv link to the video I did of it for MindCandy volume 1 (although the video is out of sync; it’s perfect on the DVD itself).  I had seen other demos before, like ATOM by Sourcerers but I had never been exposed to the concept of an underground scene dedicated to demos until I saw Megademo/TSP.

My demo productions were all PC, targeted to a 386-40MHz, with later prods targeted to a Pentium.  I coded in Turbo Pascal with inline assembler for parts that needed optimization.  I learned a lot about how VGA could be tweaked to display more than 256 colors, or higher resolution, or both.  (Or lower resolution.  I’m particularly proud of figuring out a true chunky 160×100 mode that works on stock VGA.)

In recent years, I’ve been coding for fun on even slower hardware than I started with, like the original 4.77MHz IBM PC from 1981, and also the PCjr/Tandy to take advantage of their 16-color graphics and 3-voice sound.  This slide backwards is intentional, because it’s more of a challenge, and challenges are fun.  I enter these little experiments into North American demo competitions (there are actually two this year, a record!  Block Party in Cleveland in April and at-party near Boston in June) and have even won 1st, 2nd, or 3rd place for everything I’ve ever entered, but I don’t do it for prizes or placement; I do it for these reasons:

  1. To relax (yes, programming can be relaxing)
  2. The excitement of manifesting something you saw in your head into reality using the computer as a tool
  3. Most important:  To make my demoscene friends laugh

For me, the demoscene was always about getting computers to things they weren’t typically designed to do, through clever programming and techniques.  (For example, realtime 3-D graphics on old 8-bit machines still amaze me, simply because those old machines weren’t just slow, they also lacked the ability to do floating-point math — they couldn’t even multiply or divide!)  Presentation, creativity, and flair helped.  Don’t get me wrong; I liked the art and tracked music too.  Especially the music.

As the demoscene moved to Windows, I saw the use of 3-d accelerators as “cheating” and didn’t move my skills or desire to Windows.  Unfortunately for me, I have since learned that there are still ways to push the envelope in Windows for that same kind of “that should be impossible, how are you doing that?” thrill.  64k and 4k intros are one obvious area; others include complex techniques like ambient occlusion, shading via radiosity, complex geometry transformation, figuring out how to get the graphics card to offload as much as possible, etc.  But even if I had known that then, I’m not sure I would have learned windows programming anyway, since my life was getting more complex (in 1997, I had been married for three years and just had a baby).  Real Life(tm) tends to get in the way.  I only got back into democoding, going to demo compos, getting back in touch with the scene, etc. in 2004 when taking care of the kids wasn’t as difficult.

Someday I hope to go out with a bang, a magnum opus that does 3d on an IBM with an 8088 and maybe some hardware/tweak effects.  I was really hoping to do it at Breakpoint, the party I have worshipped since its inception eight years ago, but alas, this is their last year and I cannot go.  Even if I were suddenly flush with cash and quit my day job to work on a demo for 14 hours a day, 7 days a week for three weeks, I still wouldn’t be ready.  And there’s no way I’d go to Breakpoint without a prod to show.

As hard as it is to do decent demos (with or without 3-d) on a c64, it’s even harder on an 8088 PC with CGA for several reasons:

  • Memory on 8088 is four times as slow as C64
  • Graphics are bitmapped only and graphics memory is even slower due to a necessary wait state
  • Even if you wanted to cheat and use character/tile-based “graphics”, the font is not redefinable

The only thing that makes democoding on an 8088 PC interesting is a real MUL and DIV (although they’re slow so you have to weigh the tradeoffs) and access to eight times the memory of a C64.  I’ve toyed with the idea of writing a JIT that could use the extra memory to speed up screen display… One can dream.

I’ll be at both NA parties mentioned above, probably with some very old hardware, older effects, and even older person at the keyboard.  Feel free to say hi.

Posted in Demoscene, MindCandy, Programming, Uncategorized, Vintage Computing | 2 Comments »

If you focus your energy like a laser, you can do anything!

Posted by Trixter on December 13, 2009

It has taken me decades to understand my own behavior.  Saving you the lengthy self-analysis, I can sum up most of my actions as a reaction to negative stimuli.  No control over my social environment?  Learn to program computers, who always do what I say.  Can’t afford games?  Get a job at the local software store, then learn to crack and courier warez.  And so on.  Most of my hobbies can be traced to events like this.

So what happens when the negative stimulus is gone?  It depends on the hobby.  I don’t pirate (new) games; like movies, I can now afford to purchase or rent them.  I’ve stopped collecting hardware and software because I no longer have a need for the comfort and security that familiar things bring.  As I get older, I find I am finally able to let go of everything that gave me short-term benefits but led to longer-term detriment (collecting software is easy; collecting hardware takes up a ton of space!)

Finally, some of my championed causes have come to fruition and matured:  MobyGames remains the only organized, normalized database of computer and videogames, run by many volunteers.  MindCandy 1 and 2 have taken a small slice of hidden skill and wit and preserved it forever.  DOSBOX exists, and does a (nearly) fantastic job of making DOS games playable, and my efforts combined with others have gotten the games out there.  I’ve made some of my friends laugh with my programming ideas.  That’s a lot of personal accomplishment for someone who has to put family first and work first, and I’m happy thus far.

So.  The time has arrived to shore up and buttress the hobbies.  Here’s the Trixter 5-year pledge, to me as much as to you, in order of project start date:

  1. Finish up MindCandy 3.  Four hours of home theater showcase material on tasty Blu-ray (DVD too).  It’s 80% done and should be ready by March or April.
  2. Complete The Oldskool PC Benchmark, a project I’ve been tossing around for a while.  I’m unhappy that no PC emulator is cycle-exact for any model, not even known fixed targets like the 5150/5160, so this benchmark should help emulator authors get that taken care of.  It will maintain a database of systems that have been tested, so that users and authors of emulators can target a specific model to run programs in.  As each system I own is benchmarked, it will be donated back into the collector community, save for a handful of machines that I need for further development work (see below).
  3. Gutting and rewriting MONOTONE.  Adding features people actually need (like volume and frequency envelopes, or an interface that doesn’t suck ass) as well as a few only I need, like flexible hardware routing.  Remember, kids: You’re never going to wow the pants off of people unless you can drive seven(*) completely different soundcard technologies all at the same time.
  4. Bootable diskette PCjr demo, using the PCjr’s enhanced graphics and sound.  Hopefully presented at a euro party.  You best step aside, son.
  5. Build the Soundcard Museum, another project I’ve been tossing around for quite a while.  (Now you see why MONOTONE enhancements came before this.)  This will take up many months of free time, but I promise it will be worth it for the soundcard otaku.
  6. …and that’s it.  I have nothing else planned.  If they’ll have me, I’ll return to working at MobyGames, with maybe another MindCandy project in the works, if the project doesn’t run out of money.

And between all of these projects, I will play longform games that I’ve been meaning to get to (Mass Effect, Red Faction: Guerrilla, Fallout 3, etc.).  Because I’m good enough, I’m smart enough, and doggone it, people like me.

A keyboard exclusively for programming in binary

Air-cooled coding keyboard for professional use

(*) It is technically possible to put a Sound Blaster 1.0/1.5 (CMS+Adlib), Bank Street Music Writer card (essentially a PC Mockingboard), LAPC-1, IBM Music Feature Card, and SCC-1 into a Tandy 1000-series computer if you take the cover and metal frontplate off to allow room for the full-length cards and configure the LAPC-1 and SCC-1 so that they don’t share the same port and IRQ.   That’s six technologies — the seventh is the Tandy 1000 itself, with its SN76496 3-voice squawker.  If I had a 5161 expansion unit for the 5160, I could become more evil — it adds 7 additional ISA slots to the 7 already in the 5160.  I’d lose the 3-voice Tandy, but the additional slots would allow for adding up to three more IBM Music feature cards and an additional Sound Blaster Pro 2.0, and maybe even an additional SCC-1 (I’d have to check what settings it supports).  But I don’t have a 5161; they’re ludicrously difficult to find complete.  And besides, once you have two SCC-1s in a machine, what is the point of driving anything else?

Posted in Demoscene, Digital Video, Gaming, Lifehacks, MindCandy, MobyGames, Programming, Vintage Computing | 11 Comments »

Crushed under the weight of my own fun

Posted by Trixter on June 11, 2008

I find myself, routinely, in the odd position of having so many fun things to work on that all I can do is sit motionless, trying to pick one. Most of the time I look forward to it; other times I feel confused or overwhelmed, watch TV for four hours, go to bed, then watch more TV in bed.

But still: Most of the time I look forward to it.

So, what is running around in Trixter’s head at any given time? What is the nerd nectar he drinks to keep him going? What electronic dreams keep him awake?

Here is a list of projects that I am working on. Some you already know about, some I have hinted about, and others I haven’t mentioned yet until now. Some have very close completion dates; others I am scheduling to start in 2009 and 2010. No, I’m not going to tell you which ones have which dates! You’ll just have to wait until I announce their start… or completion. (Hint: I’m not even sure when some will start.) And lest you think me a monster, I only work on these after the kids are in bed (and usually after the wife is in bed too).

MONOTONE V1. Most people know about this, but probably haven’t heard much about it since Block Party. I’m still working on finishing up my original milestones for the project, which were PC speaker and IBM PCjr/Tandy 1000 support, a serviceable interface, and an open architecture. Of all my projects, this one really is close to completion (mostly because I want to move on).

MONOTONE V2: Volume control, more device support, more effects, more capable file format. While I’m mostly happy with MONOTONE, the interface was the most irritating to program, especially since I was patently aware of how much wheel reinventing was going on. Since I’ve always wanted to give Turbo Vision a whirl, MONOTONE V2 will probably be converted over to Turbo Vision (if the memory requirements aren’t rediculous).

Halving my collection. I have too much hardware and software, period. I’m holding onto a lot of it needlessly, so I need to pick my priorities and sell/donate at least half of it. Some of the machines will be easy to give up: I have a few 1984-era Macs because I wanted to show my kids what the dawn of personal graphical computing looked like; they’ve seen them, so I don’t need them any more (the Macs, not the children).

Soundcard Museum. The aspect of personal computing that has fascinated me the most during the first decade of my hobby was the multitude of ways you could produce audio with a computer. While I’ve had my share of Apple IIgs and C64 gawking, the history of the IBM PC’s awkward attempts to produce audio holds a special place in my heart because there were so many different ways to do it. Some were flawed (CMS), some odd (msound), some ahead of their time (IBM Music Feature). So, I would like to open up a Soundcard Museum, with history, pictures, audio clips (recorded with a much better card than the one producing the audio, obviously!), programming information, example programs that can really show off what the card(s) can do, etc.

An oldskool PC demo. While there have been tens of thousands of demos released for the C64, Atari ST, Amiga, 386-era DOS, and Windows platforms, I can count the total number of 4.77MHz 8088/CGA demos ever released on one hand. I can count the total number of Tandy 1000 demos on one finger (hi Joe Snow!). There has never been an IBM PCjr demo. That’s where I come in.

Oldskool PC Profiler. I love DOSBox but am frustrated by how it isn’t anywhere close to being cycle-exact, for any CPU that ever supported DOS. I also love my fellow vintage computing community, but am frustrated by how they rely on benchmarks like Landmark CPU Speed and Norton SI to compare machines, which are just plain buggy and inaccurate. I feel it’s time for a utility that can serve two purposes: 1. Accurately determine what hardware a machine is made of (8086? NEC V30? 80386? etc.) and profile CPU, memory, and video adapter to come up with a metric, and 2. Provide a continuous display of how fast DOSBox is running by doing said benchmarks realtime and outputting what machine the reported metric is closest to. By running this utility on your classic machines, you can compare like machines to see how fast they are. By running this utility inside DOSBox, you can “dial” the speed of DOSBox up and down by hitting the emulator keys F11/F12 so you can FINALLY get DOSBox to closely match, a 386sx-16, or 486-33, or 80286-12.

Convert oldskool.org to a real content management system. I built oldskool.org in Zope almost a decade ago. I never quite liked python programming (not because python sucks, but because I suck) so I think it’s time I ditch my nice little code (it automatically builds the navigation tree, puts headers/footers on stuff, etc.) and commit to something like Plone.

Convert all my high-school era cassette tapes to CD. This is more than just every nostalgic adult’s hobby. I hit my darkest time as a human around my junior year of high school, where I was deeply depressed, contemplated suicide on a weekly basis, and attempted it once (which I somehow managed to hide from my parents — hope they don’t read this) I credit three things for keeping me alive during that time: Royally screwing up the dosage, gaming and programming on my AT&T PC 6300, and The Wave. I made many recordings of music I heard on my local Wave affiliate (106.7 here in Chicago until around 1990 when it got switched to Christian talk), and I really want to preserve them. (Plus, they had cute little station IDs, where the time was announced with a little sketch, which I’d like to make available.)

Finish at least one text adventure game. I have started at least 15, but the only one I’ve ever finished was Tass Times in Tonetown, and that was kind of a hybrid, and it took me 11 years (I got stuck from 1986 until 1997 — seriously). So I guess the real goal is Finish at least one Infocom game. Any suggestions?

Convert my rare videotapes to DVD. I have some rare tapes, like some Missing Persons concerts, Urgh! A Music War, The Best of Sex and Violence, and Gadget, that will probably never see release on DVD due to rights wars and lack of interest. I want to give these the full video noise-removal inverse-telecine enhancment treatment.

MindCandy 3. Well, you knew this had to be on the list somewhere. While I dearly love the work our team has done, and I love all of the admiration of fans, I simply don’t have the motivation to think about volume 3 right now. Hint: Cheaper technology will probably raise this motivation.

BLAZE. I have written what I believe to be the very fastest LZSS decompressor for 8086, utilizing all segment and offset registers and using 1-byte opcodes without any segment override prefixes. My decompressor is less complex than LZO and should significantly outperform it on 808x. I just need to write the compressor…  I call this system BLAZE, because I am pretentious to think that I have created the very fastest decompressor and the project should have a similarly pretentious name :-).

8088 Domination.  I have some more animation systems I’d like to pursue.  I have thought of a compression mechanism for the 8088 Corruption video system that guarantees realtime decompression (mainly because REP STOSW is faster than REP MOVSW, and REP nothing is fastest of all of course).  I would also like to adapt the concept of compiled sprites into compiled differential sprites (like Autodesk Animator FLICs but compiled) to see if graphical animation is possible at high speeds.

I think I’ll go watch some TV now.

Posted in Demoscene, Programming, Vintage Computing | 7 Comments »

Collecting and Programming

Posted by Trixter on May 25, 2008

Just a quick note that Slashdot posted a main-page post about software collecting, one of my oldest hobbies.  I personally weighed in, of course.

For those not following MONOTONE, I released another alpha yesterday with Adlib support and more effects.  Still not finished, but it’s starting to become usable and interesting now :)

Posted in Programming, Software Piracy, Vintage Computing | 3 Comments »

MONOTONE Party Release

Posted by Trixter on April 16, 2008

It’s very basic, but it functions. Leech.

I’ll be working on MONOTONE very lightly until May, when I’ll dedicate more time to it. Why? Because I’m editing together the Block Party compo/awards footage for online release.

Posted in Demoscene, Programming | Leave a Comment »

It’s Alive

Posted by Trixter on March 25, 2008

I’ve finished what I consider to be a workable alpha of MONOTONE and am distributing it to a few testers. I hope they forgive me :-)

It is functional enough to compose tunes on, but the real work will be done at Block Party next week, hopefully in the demo room if we have enough space there. I’m bringing a PCjr and am hoping to add support to what will be the world’s first PCjr tracker. If you’re attending, please stop by and feel free to mock me :-) or just talk about hacking, programming, the demoscene, whatever. But no heckling me during my talk Saturday afternoon!

Video for the curious and bored:

Posted in Programming, Vintage Computing | 15 Comments »

More Procrastination

Posted by Trixter on March 24, 2008

I have one major and two minor things to add to MONOTONE and then I simply can’t work on it any more before the party (I have to work on my presentation). So what do I do? More procrastination!

Today’s experiment is in HD; while the encoding didn’t work quite the way I wanted it to, you can still make out the text on the screen.  View it full-screen for your best chance at doing so.

Posted in Programming, Vintage Computing | Leave a Comment »

Progress… I think

Posted by Trixter on March 20, 2008

The good news: MONOTONE made some noise last night.  The bad news:  It was noise.

Now begins a complex series of compile-time debug DEFINEs so that I can try to get a handle on what is going on.  Step one is probably turning the 60Hz interrupt code into a single-step manual advance so that I can debug it.

The worst part?  50% of the notes were correct.  The rest were wrong.  And it wasn’t consistent.

Argh.

Posted in Programming | 2 Comments »

« Previous Entries
Next Entries »