Interview with JOHN KOWALSKI

 

John Kowalski is the wizard behind many of the CoCo3's most spectacular "Demos". John has literally pushed his machine to the limits, doing what many previously believed to be impossible on a stock CoCo3. For John, it's a case of, "possible unless proven otherwise"! John has a very informative web site featuring many of his CoCo achievements. Most of his programs are shareware and are available for download via his web site. With enough support from the CoCo community, John will continue to amaze us with his programming expertise and continue to remind us how powerful our favourite "8-bitter" really is!

Programming Achievements

Note: Jeff Vavasour was the main programmer of Williams Arcade

Why are you referred to as "Sock Master"?

I've written programs under several pseudonyms in the past, Dave Osborne, and most notably Sock Master. The Sock Master name is still more famous than my real name, so I tend to use that one a lot. They originate from the old days of BBSing, when most users had aliases rather than real names on the BBS.

Where do you live?

Montreal, Quebec, Canada. Montreal isn't technically accurate anymore since I moved into the suburbs a couple of years ago. I'm really in St-Hubert, but nobody's heard of St-Hubert.

How and when did you become interested in computers?

It all started when I was still a kid. School was close enough to home to be walking distance, and there was a Radio Shack along the way. Back then, Radio Shack was a friendlier place and I used to hang out there after school or during lunch (when I wasn't at the arcade, instead). Anyway, I got along well with the people there, and they didn't mind if I stayed in the store for hours just tinkering with the TRS-80, especially since I ran errands for them now and then or made demos on the computer or something. When the TRS-80 Model III came out, I convinced my parents to get me one. Interestingly enough, when I first saw a CoCo, I didn't think much of it because of it's blurry (TV) no-lowercase 32 column display. I didn't get a CoCo 2 until years later. Lucky for me that I did get one. Machine language was less imtimidating on the 6809 and I learned how to program it myself. My first Machine language programs were hand coded and poked into memory from BASIC.

What computers have you owned and currently own?

I've got a fair pile of them, though I've lost a few over the years. Most of them are not hooked up, and just sitting in the attic. I don't have my TRS-80 Model I or III anymore, but I still have a Model 4D. I also owned a VIC-20 for 3 days when they came out before returning it to the store, and got another one recently and had it for a week before giving it away to someone who actually LIKED it! I have an Atari 130XE, an Atari 520 ST, and a 1040 ST (I used to use the ST regularly). Also have a couple of Apple IIs and a Mac SE. My wife has a Mac LC475. There's a Tandy 1000, and enough spare parts to put together a few 8088, 386 and 486 PCs. I'm typing this on my K6 (Pentium clone) PC. Most importantly, I have a 64K CoCo 1, 64K CoCo 2, and about six CoCo 3s in various states of functionality and configurations. I also have a few odds and ends like a Timex/Sinclair ZX81(??) and a Seiko computer watch (with printer and keyboard!) which can run games/programs off a rompack, or typed in BASIC.

What was your favourite computer and why?

My favourite computer is the CoCo 3. Yes, it's obsolete now, but it's one of the few computers out there that is FUN to use, easy to program, and has tons of hidden potential. Yes, I have a PC and use that a lot too, but when it comes to making computers do something specific that you want done, I use the CoCo 3. For things like that, the only real disadvantage the CoCo 3 has is that it's slower than a modern PC. The fact that it's more fun makes up for it, especially if you're making it do something that it was never envisioned as being capable of doing.

What products have you developed?

I worked on Arcade's Greatest Hits - The Atari Collection 1 and Williams Arcade's Greatest Hits for the Super Nintendo. I've made a ton of CoCo programs, but many of those are free or shareware. (I haven't recieved any registrations in months! hint!hint!) The most notable ones being Twilight Terminal because of it's 20 color 640x225 graphics and proper Extended ASCII font set, and CoCo-Tracker because it finally lets the CoCo play 4 voice MOD files. I also wrote a number of BBS programs over the years. The only one still up is mine, Twilight BBS which you can call 300 to 14400 baud at (450) 926-8444. I also made a number of demos that show off some things a CoCo3 can do. I was hoping that by showing that some neat things CAN be done, maybe people would start writing programs that actually used them. So far, not many people have tried using those ideas. One of these days, I'd like to write a game that incorporates as many neat effects as possible and just wow everybody. Wouldn't it be great if there was a CoCo game that had hundreds of colors on the screen, 4 voice digitized sound, raster video effects (graphics scaling, on-the-fly palette changes, multiple layer smooth scrolling...), and maybe really fast 3D graphics?

Your 'Boink' bouncing ball demo looks fantastic! How does it work?

The Boink bouncing ball demo is one of my more interesting programs. It doesn't specifically push the CoCo's hardware to the limits or anything, but it combines a number of hardware tricks all together in one elegant 'package'. Along with probably most CoCo users out there, I found Vaughn Cato's bouncing ball demo very interesting. The only problem I had with it, was that the background was empty. The original Amiga demo had a checkerboard background, so why couldn't the CoCo? The problem was that when you scroll the ball around the screen, you're scrolling the whole screen - including the background. Can't have a checkerboard background if it's just going to bounce along with the ball...

So, I wanted to make a demo that somehow kept a steady background. Unfortunately, the only legal way to do that would be to redraw the ball over the background every time it moved. There are a couple of demos out there that do it that way, but they end up with low frame rates (choppy movement), because it takes the CPU a long time to draw the ball every frame (unless you want to have a very small ball).

I came up with the idea of just putting vertical stripes in the background. This would allow the ball to move up and down without affecting the background (though, that's not a checkerboard yet), but the stripes still follow the ball when you move it left & right. To fix that, I rigged the program to generate four copies of the graphics screen in memory, each with the stripes in the background offset by a few pixels. Now I could rig the demo to 'select' which of the 4 backgrounds to use depending on the horizontal position of the ball itself. Technically, it would have required 8 copies of the screen to cover all ball positions for the width of the stripes, but I could eliminate half of them by reversing the palette settings of the background to 'fake' the other 4 screens.

Well, that gives us solid stripes in the background. Where's the checkerboard? There actually isn't any checkerboard in the background of my demo. It just looks like there is because I alternate the palette settings every 12 scan lines - color 1 is black and color 2 is white, and then 12 lines later, I switch color 1 to white and color 2 to black...and on. I decided that since I was switching palettes every few scan lines on the screen anyway, I might as well use that to my advantage. Instead of just black & white checkers in the background, I made it do a rainbow effect. If you find that it looks familiar, it's because it's actually modeled after the colors on the cover of the CoCo3 BASIC manual!

At that point, I decided that it would still be too easy to guess what the trick behind the demo was, so I wanted to add something to throw people off. I wanted to put some non-moving graphics at the bottom of the screen that were more than just checkers to convince people that the background really WASN'T moving. The problem is, if you're scrolling the whole screen up, down, left & right, the bottom of the screen will scroll right along with the ball. A long time before this, I looked into the possibility of fooling the GIME chip into retriggering a graphics screen in mid-frame. Some way of forcing a new memory address to the video after it's already begun being displayed. That's how other systems did things like split screen two player games and other stuff. I gave up, I concluded that there was no way the GIME could be tricked into doing that.

I came up with another way to keep the graphics at the bottom of the screen from moving. The GIME has a lot of odd graphics modes that never get used. One mode keeps repeating the same line over and over across the whole screen - essentially a 320x1 resolution. It was time to use it! Instead of making the stripes behind the ball extend all the way to top and bottom of the screen, I rigged it so that there was only ONE pixel of stripes above and below the ball. Since the demo was already syncronised with the video so that it could update the palettes at specific scan lines without causing palette glitches on the screen, it wasn't hard to add some extra code to also set the video mode at specific scan lines.

What it does, it sets the resolution to 320x1 for the first 'however many pixels the ball is away from the top of the screen' scan lines, then set the resolution to 320x225 for the next 'however many pixels the ball is tall' scan lines, then switch back to 320x1 for the next 'however many pixels the ball is away from the bottom of the screen' scan lines. Once that was done, it just switched it back to 320x225 to display the last 9 scan lines that held the 'non-moving' graphics at the bottom of the screen. Oh, and while it was at it, set the horizontal scroll register back to zero so that the bottom doesn't move left & right along with the ball either.

All that was left to do was to make sure that the program always kept track of how many pixels were above the ball, and how many were below, and the whole graphics screen would end up rock-stable while the ball is bouncing all over the place.

What about the transparent ball shadow? That just got added in as an afterthought. I figured it wouldn't be any harder to switch palettes for four background colors than it would be to do two. The shadow under the ball is just drawn in two extra colors, one for when the shadow is over a stripe, and one for when the shadow is over black. The palette switching that creates the illusion of a checkerboard background also switches the shadow palettes to create the illusion that the shadow is darkening the checkerboard pattern. The only drawback to reserving 4 colors for the background was that it left only 12 to do the ball's palette animation rotation. That's why the ball seems to turn faster than the other demos - it's because it's cycling through less palettes.

Oh yeah, that's about everything except the ball itself. I didn't want to actually draw it, because I figured anything I would draw would look more fake. So, I took a blue rubber ball I had and drew lines on it and painted checkers on it. I used that as a model, and then wrote a basic program to try to generate that ball on the screen. I still have that ball sitting in a drawer in the attic. After some experimentation, I fixed up most of the mathematical glitches that gave me all sorts of  screwed up looking balls on the screen. There was one glitch I never fixed, and I decided it was 'good enough'. If you look at the top of the ball, where all the lines join together, you notice that the center point is a bit warped, or off-center. I figured it wasn't distracting enough to be too much of a problem. I just never did figure out the proper math to do a '3D' ball on the screen! If you're wondering, it took that program about an hour to run before completing the image.

What motivates you to make another groundbreaking demo?

Time. If I had free time, I'd make another demo!

You have also designed a 4Mhz accelerator for the CoCo3. Can you tell us more about this?

The 4Mhz accelerator came about after having a few separate ideas that ended up fitting together. I wanted to try speeding up the CoCo3, so I tried the usual stuff of changing the clock crystal - that works to an extent, but it has side effects. Boosting the clock beyond 2Mhz (normal is 1.79) would push the video rate enough for my CM-8 not to sync with video anymore and also cause my RS232 card to malfunction. After a certain number of tests with varios crystals, I concluded that the CPU ITSELF could be overclocked significantly - without blowing up! But the rest of the CoCo could not.

The next idea came when I looked at the 6809 cycle-by-cycle operation flow charts. There are a fair number of CPU cycles that execute without addressing memory. If I could only run those cycles faster, I could speed up the CPU without affecting any other part of the CoCo. Looking at the 6809 data sheets, I saw that the AVMA pin on the CPU always gave early warning wether the CPU would or would not be addressing memory in the next cycle.

So, the plan was to build a circuit that knew when the CPU wouldn't use memory, and run 'non-memory' cycles at a faster clock. That's actually not too hard, but there's a hitch. If you run one cycle twice as fast, you still have to WAIT for the next cycle to resyncronise with the 1.79Mhz bus. You'd only get any speed increase if there were two 'non-memory' cycles in a row because you could run both within one bus cycle.

The next thing I did was actually build something. I just wanted to screw around with the CPU clock and see how dangerous it was to the rest of the hardware to do so. I built a clock divider. For every two E and Q pulses being generated by the GIME, the circuit would only send ONE to the CPU. I booted it up, and PRESTO! It ran as slow as molasses. My CoCo3 just booted up at 0.45Mhz, and the fast poke switched it to a fantastic 0.89Mhz! Other than some jittery video in .45Mhz sometimes, it ran fine. I concluded that you could 'bend' CPU & memory timing quite a bit without it failing.

The final idea that made the 4Mhz accelerator possible was this : Instead of 'just' running non-memory cycles at 4Mhz, I could try bending the previous and following cycle's timing to make room for a sneak (burst) cycle. This way, any single non-memory cycle could be executed BETWEEN two normal cycles without the rest of the CoCo ever knowing it happened! What it does is cut the ending phase of the 'before' cycle short, sneak in a burst cycle that doesn't address memory, and then clip the beginning of the 'after' cycle.

The result meant that the CPU ran 5 different 'sizes' of cycles, depending when it's using memory and when it isn't, but it also means that it can run FLAT OUT double speed if there is at least one non-memory cycle happening every two CPU cycles.

Well, it doesn't happen that there are that many non-memory cycles occuring, so it doesn't actually perform at twice the speed. On average, it runs about 40% faster than stock. Later on, I got a 6309 CPU and the clock doubler also works with that. A 6309 in native mode is already faster than a 6809, and it's faster still with the clock doubler. It's really neat seeing CoCo programs run faster than they were intended to, especially with games. The speed, though is a bit program dependent. Any program that uses few opcodes with non-memory cycles in them won't speed up much, but programs that do have a lot of those opcodes will speed up a lot.

What companies did you work for?

I'm currently working for Digital Eclipse. They develop console video games. Before that, I did programming for a medical company, MedNet. The rest wasn't computer related, unfortunately.

Can you tell us any interesting "stories" of your past development days?

Most of my experiments were deliberate. I had an idea that something should be possible and I tried it. There was some random hunting for effects - keep poking all sorts of numbers into all sorts of registers (especially video registers) in all sorts of 'times' and see if anything neat happened. By times, I mean things like during the horizontal or vertical video border, or at the end of a scan line or the last line of the screen, etc.. A few neat but fairly useless discoveries were that the 1987 GIME could be tricked into displaying overscan graphics (graphics WITHIN the border) and that the 1986 GIME could be tricked into displaying interlaced video (640x450). I also found out that the interrupt timing between both versions of the GIME is very different, and that's a regular annoyance that interferes with special effects. Luckily, I also found out how to detect which GIME your CoCo has so I could make it so that a program works on both of them.

One interesting story is about writing the sound code the Williams Arcade's Greatest Hits. I wrote a translator that converted the original arcade sound program from 6800 to Super Nintendo (SNES) Sound CPU assembly. I made sure that it generated code that ran exactly at the same frequency because all the sounds were algorythmic (A program loop that generated numbers that got fed to a DAC - timing is everything!) and it turned out that everything ran way too slow. Why? Turned out to be a combination of a typo and a half truth in the Nintendo manual. What they meant to write as 2.048Mhz got written as 2.48Mhz, and 2.048 itself was sort of a lie because every 2nd cycle was stolen by DMA so the CPU really ran at 1.024Mhz when the manual said it was 2.48Mhz! Lets just say it was a lot of trouble to go through all the code by hand and make it go 242% faster.

Are you still developing for the CoCo and why?

Yep, I got into it too late to have quit while I was ahead, I guess. The reason I program the CoCo is because I enjoy it. There's a big feeling of satisfaction when you finally get your CoCo to do something really neat. It's also nice when you can program whatever it is you want to program, in any time frame you want.

What are some of your favourite CoCo products of all time?

There are a lot of programs that I really liked, either because they were fun, useful or technically impressive. The standards have gone up since the early CoCo days, but that doesn't make some of the older programs any less impressive. Some of my favourites are Zenix, Shanghai, Gantelet II, V-Term, CoCoMax III, VIP Library, ADOS-3, Dungeons of Daggorath, Wildcatting and Dino Wars. Dragonfire wasn't the best game in the world, but it gets an honourable mention because it managed to coax 8 REAL colors out of the PMODE3 display on a CoCo1. The 8 colors in the CoCo version weren't artifacted. The game switched between the two PMODE3 'palettes' a few times in almost every scan line of the screen. So you had all 8 colors simultaneously on the screen. The trick backfired on the CoCo3 because the GIME had different video timing, and the color changes happened around 8 pixels later than they should have and it made a messy looking screen.

What is your opinion of the CoCo2 and CoCo3 hardware platform?

The CoCo 2 was nice in it's day, but it's seriously out of date now. It's still useful for number crunching and interfacing with the real world (measuring and/or controlling things), but as a desktop computer, it's not very useful.

The CoCo 3 is pretty cool. The CPU isn't fast enough and the graphics aren't good enough, but with a little bit of work you can still do quite a lot of things with it. The only serious thing that it's lacking today is Internet ability - and even that could be overcome with some work. As far as I'm concerned, the CoCo can do ANYTHING, only slower or not as well as a new machine. It's just a shame that there aren't many programmers left. The CoCo 3 hasn't reached anywhere near it's potential yet.

If you were asked by "Mr.Tandy" to create a CoCo4, what would you include?

Some people might think I'm crazy, but I'd keep the 6809 - or rather, the 6309 CPU. My vision of a CoCo4 is a three 6309 CPU machine, where each CPU runs at 4 (not 3.58) Mhz. With three CPUs, this CoCo4 would be slighly more than 8 times faster than a stock CoCo3. The neat thing about 3 CPUs is that you can specifically program each one to do a different task. A game could use one CPU for sound & music, another to draw all the graphics, and the last to process game data. It would be like having one processor and two completely customizable co-processors. Want a sound chip? Write it! Want a graphics processor? Write it! Want a JAVA interpreter? ..you get the idea. It's very versatile, and could do a lot of neat things while still being cheap to make. I wrote a text file describing my vision of a CoCo4, it's on my web page.

Have you any "words of wisdom" to pass on to any budding CoCo programmers?

Learn 6809 assembly. Count CPU cycles when programming important sections of your program - the most obvious way to program something usually isn't the fastest. Find an idea that has never been properly taken advantage of on the CoCo and just do it, whether it seems impossible or not - If you think about it for a while, you might be surprised at some of the solutions you can come up with. Oh, use lots of self-modifying code, it's faster!