Mini 486 PC: Unisys CWD 4001

A couple weeks ago or so, I came across a forum post with someone showing off a mini 486 PC by Unisys. After a bit of searching, I discovered that there was a seller on eBay who had a bunch of these for sale so I would easily be able to get one. When I saw this, I instantly thought to myself "I must get one of those!"
EDIT: It seems a video someone posted about these got a bunch of people buying them from this eBay auction which in turn caused the seller to bump up the price considerably. I only paid $97 CAN for mine!

However, I decided to sleep on it and wait a few days first and see if afterwards I still wanted it. I had originally decided that I did probably want to either buy or build a 486 PC at some point -- actually scratch that. While I had initially thought it would be cool to go as far back as a 486, when I thought about it some more I realized that getting at least a Pentium would probably make more sense. This was because in addition to wanting to use it for some "old school" development purposes, I'd also definitely want to use it to play games. And a 486 wouldn't cut it for that use for me personally. And with this thought in my mind, the question of what exact hardware specs I should go for was left unanswered and I realized that I had to do more thinking on it all. And regardless, I wasn't in any rush as I was still having fun fiddling with Amiga-related things.

Well, after a couple days passed by I still found myself thinking about it quite a lot. Space is at a bit of a premium for me as lately I keep buying random electronics toys that I don't really need. But what other small 486 PCs am I likely to find or be able to build myself anyway? Plus it wasn't that expensive (well, shipping to Toronto cost more than the PC itself, but even so, I can afford it ... meh). So I bought one!

It arrived pretty quick (4 days). And my god, it is small!


There's little information out there about these that I was able to find, just a few web pages with spec lists and some French videos on Youtube from some guy doing both an overview and a tear-down. Evidently, the exact hardware that these come with can vary a bit, but mine was:

  • Model: Unisys CWD 4001-ZE, Manufacture date: Sept 10, 1995.
  • CPU: Am486DX2-S 66MHz, socket 1 LIF PGA 169-pin with star-shaped heatsink.
  • RAM: 16MB (2x 8MB) DRAM 72pin.
  • Graphics: Cirrus Logic CL-GD5424, 1MB VRAM
  • Network: Accton/Unisys UK0022 (based on Novell NE2000)
  • Sound: PC speaker
  • Hard Disk: Fujitsu M1612TAU (545MB) IDE
  • Floppy Disk: Teac FD-05HG-4684-U (Slim)
  • Expansion: One unused ISA slot
  • Ports: 15-pin VGA, DB25 parallel port, 2x DB9 serial port, 2x PS/2 port (keyboard/mouse), RJ45 network port
  • PSU: Built in (proprietary).

Total dimensions: 29cm x 22cm x 6cm (width/depth/height).

Here's what the motherboard looks like for those curious (click for full picture):

In the above picture, the floppy drive, hard disk, and ISA riser have all been removed of course. But with them all in there it's packed in pretty tight! I was a little bit concerned about what the temperature might be like when it's been running for a while, especially since the only fan in the whole computer is a small one for the PSU only.

Honestly, I'm quite happy with these specs! I knew it was possible that these could come with anything from a 486DX2 33MHz to a 486DX4 100MHz, and I was hoping for at least a DX2 66MHz since it's what's largely regarded as a minimum spec necessary for playing games like Doom at a decent speed (you can do it with less of course, but then it all depends on your tolerance for lower framerates). 16MB of RAM is plenty and for a 486, you won't need any more at all. I was a little bit unfamiliar with the graphics cards of this era since I was younger at the time and had no money anyway, so I just used whatever was available to me (heh), but a GD5424 with 1MB VRAM is not too shabby either. Not amazing, just average really. Onboard LAN is quite nice, means I don't have to use floppy disks to transfer stuff to it since it's obviously lacking a CD-ROM drive.

Aside from the lack of a CD-ROM drive, the other big thing that is missing is sound. With no onboard sound capabilities aside from the lovely PC speaker and with a single ISA port available, getting a Sound Blaster card seemed like the obvious next step.

Of course, since this is such a small computer, one needs to take into account whether any given expansion card will actually fit into the case. Most of the better Sound Blaster card options are unfortunately too long.

I eventually settled on two possible options: a Sound Blaster AWE64 or a Sound Blaster Vibra 16XV. The few people I could find that had these computers all seemed to go with the AWE64 (something like a CT4520 is small enough to fit). I ended up going with a Vibra 16XV CT4170 mainly because I found one locally for cheaper, but would've gone for an AWE64 otherwise myself.

The only other thing of note was that within a few days of having this computer, the Fujitsu hard disk it came with died. I didn't intend to use that disk over the long term and had already ordered a CF-to-IDE adapter to replace it with. However, since the adapter hasn't arrived yet, I ended up replacing the drive temporarily with an 8.4GB Maxtor drive I still had sitting around. The BIOS only recognizes 2GB and is only able to boot from a partition that is 504MB (max) however.

For the first several days I was using an old SyncMaster 943N 19" 4:3 LCD monitor but grew tired of the poor upscaling of low MS-DOS resolutions. Picked up a cheap CRT monitor (a 15" Sony Trinitron CPD-100SX) from someone on Kijiji and now I really feel like it's all come together as a real old-school DOS PC!

In the above picture, the text editor on-screen is RHIDE for use with DJGPP. I was fiddling with some VGA Mode 13h C code... a nice trip down memory lane.

Overall, I'm glad I got it. It runs great, it's quiet, for a 486 it's decently specced and runs pretty much any games I throw at it from up until about 1996 or so (then you start getting into games really intended for Pentiums). Even Duke Nukem 3D is playable at 320x200, though barely. I actually think that the CF-to-IDE hard disk would help here as I do notice the game does load stuff from disk during game play here and there, and it seems like those disk accesses usually correspond with a slow down.

After the computer has been running for a while, the PSU does heat up quite a bit and the case does get warm to touch on that side. It still does concern me a little and I might investigate to see if I can get a better fan. Also, I would hope that once I remove the "big" hard disk and replace it with a much smaller CF card that it might help improve airflow inside the case and possibly reduce the internal temperature a little bit. However, from what I can tell from the few other forum posts that I've found from others who own this computer, heat doesn't seem to be a problem. So, fingers crossed that it remains that way as I'm not sure what else I could do (nowhere inside the case that I could install an additional fan or anything like that).

Shmup Game First Steps

After playing with both AMOS and Blitz Basic, I initially had an overall poor impression of Blitz Basic mostly due to stability issues. This was disappointing to me because it seemed pretty clear that AMOS was a little bit slower, but at least it did seem more approachable.

Ultimately though, when I reflected on the various game ideas I had floating around in my head, I really figured I would end up quickly outgrowing AMOS from a performance perspective. So I decided I would look at Blitz Basic again, but try to see what I could do (if anything) to work around the stability issues I had run into earlier. I should note at this point that yes, I did have the runtime debugger enabled, so I don't think that was the cause of any of the crashes I was seeing. That was the first thing I checked when I was having issues. Some of the crashes weren't even occurring while a program was running anyway...

First, I decided that I would not use the "mousable labels" support. Blitz's editor "TED" pops up a side navigation pane showing your program's labels for quick navigation only if your program has any. A "mouseable label" is just an ordinary label that you would use with GOTO or GOSUB with the exception that it should start with a period, e.g. .renderPlayfield: instead of renderPlayfield:. I had noticed some random crashing that would occur when I was fiddling around with some of the sample programs that included these types of labels. Additionally, I had encountered a severe problem with the updated TED version included in the Blitz Support Suite ("SuperTED" I believe it was called? Or might have been the update before that?) where it would immediately crash when opening a program with any of these types of labels. Definitely seemed to me that the editor support for it was at least partially broken... at least for me, though I'm not sure what I could have done to cause these issues, heh.

Second, I had finished completely reading through the user guide (which is honestly a quick read, less than 100 pages) and had run across the recommendations and warnings for using "Blitz mode" (which you will undoubtedly want to use for performance reasons). Most importantly, any disk access or other concurrent OS processing that occurs while a program is running in Blitz mode (or as it first enters Blitz mode) can cause crashes! How about that. I suppose it's possible that this accounts for at least some of the instability I was encountering before. The user guide recommends doing something like VWait 120 just before a BLITZ call to ensure that any disk buffers have had time to be flushed (evidently the OS does so every two seconds?). It notes that there is no software method to check for whether stuff like disk activity has completed so this seems like the only way to protect against this kind of crash. Also it is important to note that none of the sample programs that use Blitz mode do this, thus furthering my belief that this was at least part of the problem I had run into when previously toying about with Blitz Basic.

Anyway... so far so good! I've only had one crash all weekend, and I believe that actually was related to my misuse of Blitz mode and/or of some dual playfield slice functionality. For most of the weekend, I was booted up into a Blitz Basic 1.7 floppy and not using the hard disk functionality provided by my ACA500plus. I wanted to remove as much other possible factors as I could and that seemed like a big one. Late this afternoon I resumed using the ACA500plus and CF card hard disk and have so far been running completely stable as well with that configuration. Fingers crossed that it stays that way.

Without having to worry about crashes, I was able to get a lot of experimentation and learning done and got some very preliminary work done on a basic vertical shmup type game. Nothing fancy, but I'm happy for a few hours work with lots of flipping around through manuals slowing things down (really want to get a physical copy of the Blitz Basic Reference Manual... I hate having to constantly look up commands in PDFs).

I'll try not to make posting big code dumps a habit on this blog, but here's what I've got so far:

; shmup test

#KEY_ESCAPE = $45
#KEY_UP = $4c
#KEY_DOWN = $4d
#KEY_LEFT = $4f
#KEY_RIGHT = $4e
#KEY_SPACE = $40

#SPEED = 2
#STATUSBAR_HEIGHT = 32
#PLAYFIELD_HEIGHT = 256 - #STATUSBAR_HEIGHT

#PAL_GAME = 0

#BMP_STATUSBAR = 0
#BMP_PLAYFIELD = 1

#SLICE_STATUSBAR = 0
#SLICE_PLAYFIELD = 1

#SHAPE_LRG_ENEMY = 0
#SHAPE_MED_ENEMY = 2
#SHAPE_SML_ENEMY = 4
#SHAPE_PLAYER = 6
#SHAPE_BULLETS = 16
#SHAPE_EXPLOSION = 20
#SHAPE_POWERUPS = 25

ASSET_ROOT$ = "Projects:resources/"  
ASSET_SHAPES$ = ASSET_ROOT$ + "shmup.iff"  
ASSET_STARS_BG$ = ASSET_ROOT$ + "shmup_stars_bg.iff"

DEFTYPE .w

Statement ASSET_LoadPalette{pal}  
  SHARED ASSET_SHAPES$
  LoadPalette pal,ASSET_SHAPES$
End Statement

Statement ASSET_LoadStarsBg{destBmp}  
  SHARED ASSET_STARS_BG$
  BitMap destBmp,320,512,5
  LoadBitMap destBmp,ASSET_STARS_BG$
  Scroll 0,0,320,256,0,256,destBmp
End Statement

Statement ASSET_LoadShapes{}  
  SHARED ASSET_SHAPES$
  BitMap 0,192,256,5
  LoadBitMap bmp,ASSET_SHAPES$

  GetaShape #SHAPE_LRG_ENEMY,0,0,32,32
  GetaShape #SHAPE_LRG_ENEMY+1,32,0,32,32

  GetaShape #SHAPE_MED_ENEMY,64,0,32,16
  GetaShape #SHAPE_MED_ENEMY,96,0,32,16

  GetaShape #SHAPE_SML_ENEMY,64,16,16,16
  GetaShape #SHAPE_SML_ENEMY,80,16,16,16

  For i=0 To 4
    GetaShape #SHAPE_PLAYER+i,0+(i*16),32,16,24
    GetaShape #SHAPE_PLAYER+i+5,0+(i*16),56,16,24
  Next i

  GetaShape #SHAPE_BULLETS,80,32,16,16
  GetaShape #SHAPE_BULLETS+1,96,32,16,16
  GetaShape #SHAPE_BULLETS+2,80,48,16,16
  GetaShape #SHAPE_BULLETS+3,96,48,16,16

  For i=0 To 5
    GetaShape #SHAPE_EXPLOSION+i,0+(i*16),80,16,16
  Next i

  GetaShape #SHAPE_POWERUPS,80,64,16,16
  GetaShape #SHAPE_POWERUPS+1,96,64,16,16
  GetaShape #SHAPE_POWERUPS+2,80,80,16,16
  GetaShape #SHAPE_POWERUPS+3,96,80,16,16

  Free BitMap 0
End Statement

Statement ASSET_Load{}  
  NPrint "Loading palette ..."
  ASSET_LoadPalette{#PAL_GAME}
  NPrint "Loading stars background ..."
  ASSET_LoadStarsBg{#BMP_PLAYFIELD}
  NPrint "Loading shapes ..."
  ASSET_LoadShapes{}
  NPrint "Done loading assets!"
End Statement

; -------------------------------------------------------------------

Statement GAME_Init{}  
  VWait 120
  BLITZ

  Buffer #BMP_PLAYFIELD,16384

  BitMap #BMP_STATUSBAR,320,#STATUSBAR_HEIGHT,5
  Slice #SLICE_STATUSBAR,44,320,#STATUSBAR_HEIGHT,$fff8,5,8,32,320,320
  Use Palette #PAL_GAME

  Slice #SLICE_PLAYFIELD,44+#STATUSBAR_HEIGHT,320,#PLAYFIELD_HEIGHT,$fff8,5,8,32,320,320
  Use Palette #PAL_GAME
End Statement

Statement DRAW_StatusBar{}  
  Use Slice #SLICE_STATUSBAR
  Use BitMap #BMP_STATUSBAR
  BitMapOutput #BMP_STATUSBAR

  Cls 14
  Print "TODO: Awesome statusbar here"

  Show #BMP_STATUSBAR
End Statement

Statement DRAW_Playfield{}  
  SHARED scrollY, playerX.q, playerTiltOffset, animateOffset
  Use BitMap #BMP_PLAYFIELD
  Use Slice #SLICE_PLAYFIELD

  UnBuffer #BMP_PLAYFIELD

  Show #BMP_PLAYFIELD,0,scrollY

  tile = #SHAPE_PLAYER+2+playerTiltOffset+(animateOffset*5)
  y = #PLAYFIELD_HEIGHT-32+scrollY
  BBlit #BMP_PLAYFIELD,tile,playerX,y

End Statement

;
; -------------------------------------------------------------------
;

ASSET_Load{}

GAME_Init{}

animateFrame = 0  
animateOffset = 0

playerTiltOffset = 0  
playerHorizAccel.q = 0  
playerX.q = 320/2-32/2

scrollY = 0

DRAW_StatusBar{}  
DRAW_Playfield{}

While NOT RawStatus(#KEY_ESCAPE)

  scrollY = QWrap(scrollY - #SPEED, 0, 256)

  animateFrame = QWrap(animateFrame+1, 0, 5)
  If animateFrame = 0
    animateOffset = QWrap(animateOffset+1, 0, 2)
  EndIf

  If RawStatus(#KEY_LEFT)
    playerHorizAccel - 1
  EndIf
  If RawStatus(#KEY_RIGHT)
    playerHorizAccel + 1
  EndIf
  playerHorizAccel = playerHorizAccel * 0.7
  playerX = QLimit(playerX + playerHorizAccel, 0, 320-16)
  playerTiltOffset = Int(playerHorizAccel)

  VWait
  DRAW_Playfield{}

Wend

End  

So yeah, very basic and/or crude for now. It doesn't look very impressive running yet either:

All you can do is fly the ship back and forth (but hey, it animates and the ship tilts a bit from side-to-side as you move left and right... exciting, right!?). I'm using the art assets from this package on OpenGameArt. Packaged everything together with a separate simple star background and exported as an IFF.

Actually the asset management has been a slight bit of a pain so far. I first noticed that Photoshop has the ability to save as Amiga IFF, so I would pre-convert the image I was working with to indexed colour mode and set up a 32 colour table and then save as an IFF. This seems to produce something that always is loadable by Blitz Basic (and AMOS for that matter), but occasionally produces a file that Deluxe Paint says is "mangled." Also sometimes, when loaded in Blitz Basic, the palette is somewhat off. Some colours will be totally different, but most will be correct. In this case, I've noticed I can fix the problem by opening the IFF in Deluxe Paint, and if it doesn't complain that it's mangled, I can simply re-save the file and the problem goes away. My suspicion is that Photoshop saves the palette information in a different way then what Blitz Basic is expecting, but I have not investigated this fully yet. I also tried using XnConvert by exporting from Photoshop as a indexed colour PNG or GIF and then converting to Amiga IFF with XnConvert, but still have run into the same issue (I think? I might also have mixed up my working files, heh, so will need to confirm that first I guess). At any rate, I definitely still have lots to do to nail down my asset preparation process.

Next steps will be putting together some custom font routines (I'm not sure how to generate the "Blitzfonts" that Blitz Basic supports, but at any rate, I don't think that supports bitmap fonts which is what I really want to use anyway). Following that will be adding the ability for the player to shoot and then adding enemies. I'm really curious to see how quickly I run into slowdowns.

Bad eBay Seller Experience: szubaark

I've just concluded a pretty terrible experience with an eBay seller szubaark who is either known as Wes Szuba or Arek Szuba and is either from Florida or Michigan (the confusion is because my PayPal transaction was with an "Arek Szuba", but the return address on the two packages I ended up getting from him was from a "Wes Szuba." Both shipped from Florida, but the eBay auction's location clearly said Michigan. I don't really know what's going on there to be honest. Maybe two people, possibly family members, sharing the same eBay account?). This individual sold me some a Commodore 64 system that was not as described (it didn't work properly right from the get-go) and ended up blaming me saying that I had someone broken it. And to top it all off, he ended up getting away with it.

I don't like to write stuff like this that has such a negative tone, but this experience has left such a sour taste in my mouth and the fact that he ended up getting away with it scot-free... I feel like I have no other recourse now but to write about it. In the very unlikely chance that someone in the future is considering dealing with him and happens to google his name first and finds this, well, I hope it helps them out. Since he essentially runs a shop on eBay (over 1000 feedback), consider this a review of his shop just like any other review of a store you may find elsewhere.

On May 6th, I bought a Commodore 64 "complete system" package from szubaark on eBay. This was fairly expensive for such a system, but when you look at Commodore 64 systems for sale, they very typically are not "complete" and even if they are, they often have not been tested at all, or at the most someone has plugged it in and verified that the power light turns on... not even verifying functionality by plugging it into a TV. These types of auctions go for far less than the one I bought. But I was willing to pay a premium for a fully working and tested unit. There weren't many on eBay at the time and this one from szubaark was even modded with JiffyDOS which seemed like a nice perk (saves me the trouble from doing such a mod myself down the road!).

I can hear you now: "Yikes! That's expensive!" Yup, but again, when you look at complete systems for sale that have been tested and verified working, they are all typically around that ballpark (though this was definitely near the top-end of that range).

On May 17th, it arrived. Packaging all looked good to me, no need to believe it had been beaten around during shipping or anything of the sort. I opened up the package and everything that was mentioned in the auction was present and exactly as pictured.

I proceeded to plug it in (just the Commodore 64, I actually to this day have not tried the floppy drive at all). It powered on and looked to be all good. I had previously bought the Commodore 64 user's guide and programmer's reference guide and had them both in hand and excited to be able to try fiddling around with old school BASIC for the first time in many, many years I began typing in some simple examples from the user's guide. I was in the middle of typing in one such example (to do with sound) and it froze. The screen didn't change, it just froze completely. Uh oh. I power cycled (waiting several seconds between powering off and then on) and it booted up fine again. I once again tried typing in the same BASIC program. Froze again. Much quicker this time (within 30 seconds or so). Though this time the screen cleared to a simple blue with blue border screen without any text or other characters visible at all. After several more crashes like this and power cycles, it began booting up to a plain blue with blue border screen and nothing else.

Annoyed, I contacted szubaark via eBay:

Hello,

I just received this today and it's become quite clear to me that it's not in working order (packaging was fine btw)

It powers on and sometimes seems to work alright (I was able to run a few short BASIC programs successfully after typing them in). But somewhat frequently it seems to crap out and freezes on an empty screen as seen here: http://imgur.com/IBO4Ezg

It doesn't crash consistently. Once it did while I was in the middle of typing a small program in from the user guide and I simply turned it on and off again and re-tried to type it in and was able to finish it successfully the second time.

When it does crash like this, I have no option but to power cycle it. Nothing else (pressing any keys, etc) has any effect whatsoever. However, sometimes when it has crashed and I power cycle it doesn't power on correctly. It boots up to that same blank screen as shown in the picture I linked above. In fact right now it's doing that.

Anyway, let me know your thoughts.

Thanks

A couple hours later I got a response:

hi

I was testing it all week and worked every time but this is 35+ year electronics and anything can go wrong at anytime..

Do you have a cartridge? can you put it in and see if boots?

also plug/unplug Video cable and PSU

Not exactly an encouraging way to start out a reply from a seller who claims to have sold me a "tested and working" Commodore 64. Sure, it's quite old, but you supposedly had tested it. It randomly failing a mere 2-3 minutes after I take it out of the box seems unlikely to me. I would suspect that the simpler and far more likely explanation is that it simply was not tested very thoroughly (if at all).

We exchanged a few more messages and he reiterated that he had tested it and mentioned that "never had any complaints until now from you...so im curious what could have gone wrong with it and right out the box"

In between waiting for responses, I had been googling for more information about common failures with Commodore 64's and what possible fixes there might be and really just trying to get a better idea of what was going on. Of course, there's a wealth of information out there and I discovered many helpful sites and forum posts, etc. In my case it was hard to be 100% certain because I unfortunately did not have a cartridge to try booting from, but it did seem like either the BASIC ROM or PLA was the culprit and would need to be replaced. To quote from one such source

U3 901226-01 BASIC ROM
Blank screen w/ border. Cartridge works.

...

U17 906114-01 (82S100PLA) PLA
Blank screen, no border. It can produce colored screen or flashing color garbage instead of startup screen. It can cause intermittant loss of cursor, screen freeze and/or program crashes after warmup and it can put random characters on screen. This chip normally runs hot. It is the most common chip to fail in the C64 because it runs hot normally, like the SID.

I've bolded the parts that were relevant to what I had seen.

I sent him the following:

Given that I had to pay a $50 customs fee which I wouldn't be able to get back without a lot of time and effort (I looked up the process just now), plus the cost of re-shipping it back to you, PLUS the fact that the C64 at least does power on and the sound does seem to work (the little power on "chime" is audible), I've been considering the feasibility of replacing something that is broken / gone bad inside it.

I did some quick googling about possible problems when you get a blue screen on power on and it seems like some likely culprits are the BASIC ROM or PLA IC's might need to be replaced?

I'm curious if you know anything about this? Figured I'd ask you since (I guess?) you did the JiffyDOS mod on this? Figure you know a thing or two about repairing C64s.

It's been a while since I've done any soldering but it would probably come back quick, but I'd want to practice first.

Obviously goes without saying that if I were to go the self-repair route, that is all at my own risk. Still considering the idea anyway.

First off, regarding that last paragraph, I want to emphasize right now that I never even got around to trying to replace the ROM. Even now as I write this. The Commodore 64 system he sold me has sat entirely unmodified by me from the time he sold it to me until today as I write this very post. The most I've done with it is plug it in and power it on to try using it normally.

Second off, I want to say that I realize now in hindsight what an absolute mistake it was for me to send this. I should have requested a return and refund instead and have been done with it. All the googling and reading I had done though while waiting for his responses had unfortunately planted the idea in my head that it would be a simple repair and that it would be no problem at all and certainly a lot less effort for both of us. Also at this time I did not know what eBay's policies were regarding returns. I wish I had spent the time to look it up, but I incorrectly assumed that I would have to pay return shipping (which would be expensive and a pain in the ass). Thus it really did seem like the most logical course of action was to do a simple ROM replacement. How wrong I was...

Anyway... he seemed positive about this course of action and even offered to send me a replacement BASIC ROM and Kickman cart. Note that I didn't ask for this at all, he was the first to offer it. In fact, when I received his message offering to send me that stuff I was in mid-search looking for places where I could buy those items. I accepted his offer and that was that... for a while.

I continued to do a bit of reading on the side now and then while waiting for the package to arrive. I eventually read about diagnostic cartridges that people had created for diagnosis hardware issues with Commodore 64s. I ended up buying one from COREi64 figured that it would probably be much more useful to have then having to guess at what is wrong from weather a Kickman cart does or does not boot when it arrived.

On May 25th, I received another smaller package from him, but didn't get a chance to open it until the 27th. The diagnostic cart I had bought also arrived that same week luckily. When I opened the package szubaark sent, I found 3 EPROM chips, a BASIC ROM chip and a Kickman cart. There was a note included which said "some spare EPROMs for you :)".

I have no idea why he would send me spare EPROM chips. I don't own an EPROM programmer, nor had either of us even mentioned anything about EPROMs in any of our correspondence to that point. Him sending me EPROMs was ultimately not helpful at all and served no purpose.

Confused, I plugged in the Kickman cart and turned on the Commodore 64. It booted straight to Kickman as one would expect, though the audio was not working 100% right. There was a somewhat loud constant tone that never ceased right from bootup. The game's sounds would continue to play over it, but clearly it was not working perfectly.

Now somewhat annoyed, I plugged in the brand new diagnostic cart I had bought. I became even more annoyed. It indicated that the Kernel ROM was bad, that the CIA chips (U1 and U2) were bad and that the SID (U18) was bad. As if that wasn't bad enough, over the course of five or so minutes each time I re-ran the tests some new chip came up as bad. This was the final test result that it seemed to "stabilize" at:

Ignore the "bad" test results shown on the right. They show bad because I do not have a test harness hooked up that is required to test those ports. The only test results that really matter are the ones on the left and bottom.

So we can see that eventually the BASIC ROM did also come up as bad, and that now also the PLA was coming up as bad. Also the fact that the tests seemed to "get worse" as the system was turned on for longer seemed to prove that at least some components were probably failing at least in part due to heat (maybe?). At least that was one of my theories. Certainly heat does seem to be a common cause for a PLA failure. And if szubaark's lousy testing was only comprised of a 30 second power on test or something similar, he definitely would not have noticed a problem. Thus bringing me back to my original conclusion that he did not at all thoroughly test a 35+ year old "tested and working" Commodore 64 before selling it to me.

I sent the following:

Hello,

The cart and rom chips you sent arrived the other day and I finally had a chance to try it out today and the cart did boot fine, though the audio seems off compared to what I'm seeing from looking at Youtube videos of the same game. There is a constant loud tone that never goes away (and is there immediately from power-on), but the rest of the game's sounds play fine despite this.

A couple days after you sent that package, I came across forum posts mentioning a "C64 Diagnostic Cart (586220)" and was able to find someone selling one near me and bought one. That also arrived the other day too, and this is the result: http://i.imgur.com/TgMJSqd.jpg

Ignore the casette, control, serial, and user ports as from what I understand they'll show as "bad" simply because I do not have the diagnostic hardware hooked up that is required to test those.

However, the remaining tests are pretty grim. The Kernel and BASIC ROMs are bad, in addition to the PLA, CIA and SID. (Please note that at this point I've NOT touched the replacement ROM chip you sent, I've done no modifications to the C64 at all and it has simply sat in a box since the day it first arrived and I discovered the problems with it originally).

Frankly this seems to be a lost cause. It's obvious that there are numerous issues with this C64 you sold me and I'm sorry to be blunt, but I seriously call into question the quality of your pre-sale tests. I'm going to have to scrounge around for other C64's looking for replacements which is not something I really wanted to be doing from the get-go at least. That was the whole reason I was willing to pay your somewhat-above-average price for a tested and working unit.

Please confirm for me if the return address on the package you sent is ok for me to send back the Kickman cartridge to.

He sent me two replies in a row. The first:

Hi The diagnostic cartridges are barely 50\50..and if you have a bad chip other chips like kernal,pla,mcu will show bad also How can u have bad pla when the cartridge boots?

U just need to replace the chip i sent you and you will be fine

Just ignore the diagnostic cartridges they are worthless in my opinion

And the second:

The sound issue will be fine once u replace the basic chip and load from disk drive

Again how can u have bad pla.kernal.cia when the computer boots fine now with kickman cartridge?

At this point I was seriously starting to question his knowledge level when it came to Commodore 64 repair and modding. He had some correct information, but even I knew he was saying some incorrect things, probably because he was starting to realize he had sold me something that he had not tested that well (or perhaps not at all).

I turned to the Lemon64 forums and posted the full story so far and asked for a second opinion. I got replies saying roughly what I expected, people logically suggesting to verify the power supply and mentioning that socketed IC chips could potentially cause problems. I proceeded to open up the Commodore 64 simply to see what I was dealing with internally, not to make any changes yet:

Not exactly what I had expected. A very "homebrew" looking modding job. When I posted this picture to the forum topic on Lemon64, I got a couple replies which confirmed my fears:

That board shown has a (imo crappy) EPROM PLA replacment as well as a SID replacement. I'd be quite mad if I got that in an ebay sale for a fully working unit. It basically has a old junk SwinSID SID chip replacement and a not-fully-compatible PLA replacement chip in it. The Kernal ROM is also a hacked replacement. This may explain the problems you are having. You may want to contact the seller about getting a proper PLA chip (or PLAnkton) and a new kernal at the very least. That SID chip will work but not 100%.

And:

The KERNAL is hacked up for the JiffyDOS install. I bet the 1541 looks much the same.

It's extremely shady to sell a C64 without disclosing that it has a fake SID.

Given your situation with shipping, I'd open an "item not as described" dispute and ask for enough money back to get a real SID and good quality repro PLA.

*sigh*

I was really angry at this point. I slept on it and woke up the next morning, still upset and wrote this message to szubaark (based partially on the advice I had gotten from the users on Lemon64) that I'm not particularly proud of. Re-reading it now, it has a waaay more negative and demanding tone then I really intended:

Hello,

After talking with multiple people knowledgeable about C64 hardware and modding, I've received unanimous agreement that I should open an eBay case for this as an item "not as described" (defective) and get a full refund so there is overwhelming evidence that this is the case. I was not aware that eBay's policy was that the seller pays full shipping in this case (see http://pages.ebay.com/help/policies/money-back-guarantee.html).

However, I don't think that's necessary IF AND ONLY IF you're willing to pay for replacement chips that are all obviously not working. Since the diagnostic tests (which are not worthless as you claim, but do need to be taken in proper context) indicate that the Kernel ROM, PLA and SID have problems, I would ask that you provide a partial refund to cover the costs of getting replacements for these chips. This comes from multiple recommendations from my discussions with other people about this issue.

Replacement chip costs (all in USD):

PLAnkton - $17.50
JiffyDOS Kernel ROM - $20.00
Original SID - $40.00

Total $77.50 US

Keep in mind that YOU advertised this sale as for a "tested and working" Commodore 64. It is QUITE CLEARLY not working. Not only that, but you explicitly advertised working sound and shipped it with a SwinSID without mentioning so, which is pretty sketchy honestly. SwinSID is not well regarded and I suspect that that is exactly why you didn't mention it in the auction description.

I'm not willing to do a bunch of back and forth with you on this. The solution I've provided you with is cheaper than you paying for my return shipping. I am probably foolish for offering you this alternative, but I figure it will save us both a lot of time.

If you provide a partial refund for the amount indicated above, I will leave you positive feedback and that will be that.

If you refuse I will be forced to open an eBay case. If I don't receive a response from you in a couple days, I will also then be forced to open an eBay case.

Again, this is really not one of my better moments. It reads more like a demand then anything. I don't think what I was asking for was unreasonable at all considering that if I had done what I should have done right from the start, he would have had to pay more then what I was asking (the return shipping would have been a fair bit more than the amount I quoted in my message). However, there is a correct way to ask for that and then there is what I wrote above... not good.

Unbeknownst to me, this message of mine was actually against one of eBay's policies: feedback extortion. We'll come back to that later.

I received three replies in a row a few hours later:

Look im trying to be nice here. I already send you extras such as extra chips and cartridge. Now you asking me to send you even more chips(money).

I never did any modifications to that computer except FIX It and added new power supply. The Sid or as you call it swinsid and pla were already there. All i know you could have another defective commodore 64 and you trying to fix with me paying for it.

I have 100% feedback on my sales so when you started complaining i realized you could he trouble.

At this point i dont know what you did to this computer or what chips you switched and stop blaming me That computer wad 100% functional when i shipped it to you and you just trying to get it for free You keep asking me to ship you extra chips which i did and now asking for refund money..

I really just want to be done with you and move on

I'll give him that he did always come across as nice-ish. I was the only one of us writing mean sounding messages, though frankly, given that he had sold me a broken Commodore 64, I feel at least a tiny bit entitled to have a bit of a bad mood. I think any disgruntled customer would feel the same. But even still, I was going overboard in some of my messages and I do feel badly about that.

That said, this first reply of his does not inspire me with confidence. He now claims that he didn't do all of the modifications that are present in this system and seems to not even know what one of the modified chips (a SwinSID) was. Which is obviously a lie I found out as a bit later a user on Lemon64 found an old post of his which clearly shows he does in fact know what a SwinSID is and seems to just be trying to play dumb here.

Then he continues on now trying to blame me for breaking it. Wow. I should have honestly expected it from the way his very first message to me started (quoted near the beginning of this post).

He mentions his 100% feedback rating, and honestly based on my experience with him and how he was trying to deflect blame, I honestly had no idea how he has maintained that rating. Luck, I imagine.

Second response from him:

Also you never asked to open up this computer nor did i state anywhere in my description anything about modifications or different chips...

Well, actually, he did really give me permission to open it up. Even though I never actually got to the point where I was going to do the BASIC ROM replacement, we had both discussed it and agreed that that was the correct course of action and he had offered and then willingly sent me a BASIC ROM chip so I could replace it! If I was not supposed to open the Commodore 64 up, then what was I supposed to do with the ROM replacement had sent me? Just sit there and look at it? There isn't exactly any complex mental gymnastics going on here to arrive at this conclusion, this is all pretty simple stuff I think!

And actually he is kind of wrong when he says he didn't state anywhere in his description about modded chips. The auction was clearly for a system with JiffyDOS installed, which is by definition a mod and must be installed via a modded chip. Again, this is not rocket science here.

He's really reaching low to try and shove the blame back on me.

Third and final reply from him:

This is a hobby for that allows me to buy other Commodore hardware like cmd harddrives and you really need to stop sending me messages every week asking for more stuff or money..
I see the game you trying to play...
Im done with you..

I sent him exactly one message asking for money. He also sent me the BASIC ROM and Kickman cart for free and without me requesting it. When he offered to send it to me I was already googling around for places I could buy them from. And aside from an overly nasty tone as I've mentioned previously that I'm not proud of, I actually think that my request for a partial refund was not unreasonably considering that I was well within my right to request a full refund which would have cost him more. The only things I ever asked him explicitly for was a partial refund to repair the broken chips that were not working in this "tested and working" Commodore 64 and also for confirmation of his address so I could return the Kickman cart to him! (see a bit above if you missed that part in one of my responses to him). I never got that confirmation by the way.

So I ended up opening a case for an "item not as described."

Then about 40 minutes later I stupidly closed the case. I had mulling over it and was feeling really angry overall at how szubaark had been trying to shift the blame back on me to weasel his way out of this. It suddenly occurred to me that even if I did initiate a return he would probably eventually receive the returned package and make up something along the lines of how I broke it somehow or switched it with another broken Commodore 64 or some other made up thing and initiate a claim himself with eBay. Basically, I figured a return would just start a whole bunch more issues. So I closed the return.

I then left him negative feedback and even managed to squeeze in a URL to the Lemon64 forum post I had made describing the whole ordeal. And that was that... or so I thought.

Every couple days, I took a peek at his eBay feedback page to see if he ever posted a response to my negative feedback, figuring that he would and try to claim I had broke it instead and it was all my fault or something.

Well, yesterday, I discovered the feedback I left him had been removed! What? I called eBay to find out what had happened. I found out that he had reported me! The irony! I don't know exactly what he reported me for, but eBay's findings were that I had violated their policy on feedback extortion. I guess technically I had given that really terribly worded message I sent to him, but I find it really quite disappointing that eBay will essentially allow a seller like szubaark who had obviously sold something "not as described" get away with it scot-free. I don't know how eBay looks at user reports such as in this case, but it does seem like cherry picking key phrases out of context and "resolving" the case prematurely.

Well, that is that then. Nothing more to be done. As I said above, I can only hope that at some point in the future someone either a) does a random search by name for this guy and finds my post before decided to engage in a transaction with him and ultimately decides not to, or b) learns something from my experience about how to better deal with cases like this as a buyer: When you buy something and it arrives broken or otherwise "not as described" don't entertain the idea of fixing it or any other alternative. Return it and be done with it. Save yourself the headache!

This post has been extremely long and I honestly hope to never post anything like it again. I've been an eBay user since 2003 and this is the first bad experience I've had on it. Strangely, I actually do think I feel better for having written this all out even though it ultimately will accomplish nothing. Or maybe lightening my mood was the whole point after all. Heh.

Initial-ish Impressions: AMOS Pro vs Blitz Basic 2

I find the plethora of programming languages available for the Amiga fascinating. Especially so, the large amount of BASIC variants. The top two options for games specifically are definitely AMOS and Blitz Basic from what I can see.

Some other options such as HiSoft BASIC also seem to be of good quality (HiSoft BASIC actually does interest me quite a bit as it was advertised as being QuickBASIC compatible while not being mostly shit like Amiga BASIC from what I understand... but I will explore it later). However, it seems most people at the time settled with either AMOS or Blitz.

I've personally spent more time with AMOS so far, but this weekend I spent a bit of time with Blitz Basic and figured I'd jot down my initial thoughts about each.

None of the points below are listed in any particular order, and it is all just based on my impressions, opinions and experiences from only a limited amount of time looking at each thus far. Also note that the below screenshots show my own customizations, they are not how the "out of the box" experience is exactly.

AMOS Pro

  • Editor looks very polished. Especially as compared to the earlier (non-pro) versions. Lots of customization available with the ability to load "accessories", which, due to AMOS's overwhelming popularity back then, there are a great many to choose from.
  • The editor is not without it's quirks. For one I dislike the automatic formatting (which you cannot turn off, and is likely a result of the fact that the editor is obviously tokenizing your code as you type it in). More specifically, I don't like how it removes excess whitespace and uppercases variable names, e.g. if I type ship_x = foo + bar, it will always auto-format to SHIP_X=FOO+BAR.
  • AMOS Pro thankfully added INCLUDE support for modularizing your code, but even so, you'll probably end up with big source files. Luckily the editor allows you to collapse Procedures (though you might not actually want to use them in all cases, since this is a platform where the performance difference between GOSUB and a Procedure call can really matter!)
  • Following up on the above mentioned "accessories", the developer of AMOS provided some that serve as tools for sprite/image editors, map editors, font editors, and more. These are easily accessible from within the IDE.
  • Lots of documentation in the forms of a beefy user manual and many other published books and sample code. Even built in fully-browseable help within the editor itself.
  • Easily accessible "direct mode" available from the editor to allow quick experimentation (it also doubles as a debugging tool when your program encounters an error).
  • Very extensive set of functions with what looks like a decent abstraction over the underlying hardware (from my early impressions anyway). I personally think this is a pro and a con (a pro for when you're starting out as it's easier to jump into and a con because I suspect it won't help you that much if you move onto e.g. C/assembler later on). This abstraction covers things like asset loading as well which is certainly convenient.
  • The AMOS BASIC dialect is overall good, though lacking in some key areas. For example, no SELECT and TYPE. Somewhat odd syntax for calling Procedures (SUBs and FUNCTIONs from QBasic) and accessing the return value (if any). You cannot put comments just anywhere (well, unless you use REM I guess, though in my opinion, REM makes the code a bit harder to read). A comment written using ' must be on it's own line.
  • Quirky / annoying support for accessing system libraries, but it is somewhat workable.
  • Doesn't integrate with the OS, kind of does it's own thing with it's own totally custom GUI. This also extends to programs developed with it if they do things like pop up file requestors which will be quite alien-looking.

Blitz Basic 2

  • Much more powerful language that is clearly built to enable high performance as a primary goal. Blitz's BASIC dialect is excellent for the time in my opinion. Support for TYPE's, pointers, inline assembly, and more.
  • The language is built for a compiler and there doesn't appear to be any interpreter at all (even when running from the IDE, you can't just choose "Run" unless you've already compiled your program). Thus performance is higher from the get-go.
  • The editor is minimal, which is nice. Though it definitely is unique in a number of ways, and I don't mean that in a good way, at least not if you like me are accustomed to modern text editor standards. You cannot always hit Return to insert a new line (only if you're at the end of the current line), else you need to press Amiga+I to insert a new line or hit Shift-Return. Using the Backspace or Delete keys to remove lines is not possible, you instead must use a menu command (or press Amiga+D) to delete lines. Selecting text for copy+paste is kind of quirky, requiring you to select the text to be copied then go and find the location where you want it copied to (the paste location) and place the cursor there (moving the cursor does not unselect text) and then issue the menu copy command (or Amiga+C). There is a specific menu command for unselecting text. I'm sure you can get used to all this, but I point it out only as it's pretty different from what most people would be used to.
  • The editor has syntax highlighting! Only two colours though: regular text and tokens.
  • The editor has a side pane that pops up when your program has labels (for GOTO/GOSUB only, doesn't show Statement or Function names for some weird reason). Clicking the names in this pane scrolls immediately to that label. Thusly you can also use this as a "bookmark" list of sorts.
  • The editor is incredibly unstable. It crashes a lot, in a lot of different situations, forcing you to do a Ctrl-Amiga-Amiga reset. I've had the editor crash when clicking Project -> New, when switching back to the Workbench, when compiling a program, many times when debugging code with direct mode (in all cases, this was incredibly simple code, not even using "blitz mode"). Worth noting, I've tried four different versions of Blitz2, the 1.6 Amiga Format disk release, a 1.7 release, 2.0 and 2.1. I actually also tried installing Workbench 3 temporarily just so I could try the updated Ted version and also the "SuperTed" update, hoping that these would improve things. However, all of these also were incredibly unstable for me.
  • The standard library appears to be a bit "closer to the metal" then AMOS, but it still abstracts the hardware quite a bit. I suspect that moving from Blitz Basic to C/assembly would be a bit easier. In fact, the mere ability to use inline assembly with such ease basically anywhere in your code means that you possibly wouldn't even need to switch to C or go full-out with pure assembly unless your performance requirements were quite extreme.
  • The editor has built in help which is either limited to parameter lists only, or in later versions even has a browseable function index with descriptions and (few) examples.
  • There is not nearly as much documentation out there for Blitz Basic as there is for AMOS. A common complaint about Blitz Basic from what I've read is that it's harder to get started with, though I think for an experienced programmer that this difference is moot. Probably the smaller amount of example code that's out there would be the biggest annoyance.
  • The debugger and direct mode support looks a fair bit more unpolished than AMOS at first glance, but is definitely more advanced. Especially with a debugger update that is available for release 2.1 (though coincidentally I found this debugger update appeared to reduce stability somewhat).

Some Upgrades

A number of nice upgrades arrived over the past week or so.

The most significant honestly is the Amiga RGB cable. I'm no stranger to using RGB video for game consoles, but having been stuck with only Composite video on my Amiga 500 for the first two weeks that I had it, and then suddenly switching to RGB reminded me of what a huge difference in quality that switch is. Awesome.

Next up is an accelerator I bought, the ACA500plus:

This is honestly quite overkill for what I really want out of it, but it's probably nice to have all of it's features available anyway.

I primarily wanted a hard disk or some other non-floppy disk storage medium available. This is really just because we all know that floppy disks aren't super reliable over the long term. I've bought a few boxes of sealed double density 880K (1MB raw) floppy disks as well, but it is nice to have some more reliable storage medium available.

Getting something like an A590 would probably cost at least as much as the ACA500plus, and wouldn't offer any of it's other features. The Amiga 500 doesn't really have any other hardware options for adding hard disk-like storage (as it doesn't have any kind of IDE controller built in).

The ability to have a full 8MB of RAM is also nice as an option, especially so once I get into using C compilers. And the CPU overclocking ability (14MHz guaranteed stable, higher without the guarantees) is nice too, though I will probably keep at it the base 7MHz, as my goal has always been to work on projects that are targeted for the Amiga 500 specifically.

I have mixed feelings about the extra RAM being enabled or not. One thing I hadn't realized about Amigas (at least in Workbench 1.3, not sure if this changed with newer versions) is that when you have large partitions mounted, the system ends up using larger amounts of RAM (probably for some caching purposes? not sure exactly). So if I'm using the hard disk ability of the ACA500plus, leaving the extra RAM also enabled is a very good idea else the base 1MB (with 512KB trapdoor expansion) gets used up super fast. However, I need to make sure I don't get lazy with memory usage in my projects and make them incompatible with the baseline spec.

Final upgrade that was a nice change was a new power supply for both an Amiga 500 and Commodore 64, custom made by Ray Carlsen:

Since the Amiga 500 I got is from the UK, it came with a European power supply which of course is 220V which means I was forced to use a step up voltage transformer in conjunction with it. This was kind of annoying, and both the original Amiga power supply and the step up transformer ran a bit hot which I wasn't a big fan of. This new power supply runs on 120V of course and runs quite a bit cooler. Plus it physically takes up less space (one unit versus two).

Other then that, I've been toying about with AMOS here and there. It's been fun, and a real blast to the past for me which I'm enjoying so far. Not much to say other then that yet really, as I've just been continuing to work through the user guide for an hour or two each night, as well as consulting some other books I've picked up as I go along while learning the ins-and-outs of the hardware. Once I finish up going through the user guide (which is fairly thick, almost 400 pages), I'm thinking I may start with a vertical scrolling 'shmup type of game just to get my feet wet. It'll probably take awhile to get going as it'll obviously be my first AMOS project. Overall though I'm finding AMOS easy to get into. I think what will be difficult at first is optimizing for the limited hardware. And that's the challenge I was after in the first place.