The Commodore AL-1000, which is akin to a mini-PET (heavy and boxy). It uses tubes to display the numbers. There was some roughhousing with this venerable calculator and it needed some TLC to get going. The calculator was abandoned a long while back and found after someone was cleaning out some buildings nearby. A tip from a friend helped save this new addition.
I’ve been asked for about a year now to head out to my brothers’ studio, where an unhappy tabletop Ms. Pacman has been sitting busted.
Three of the ROM’s on the board were loose, one had broken pins (3) and the processor board (z80 :)) cable had been stripped in some spots.
The real monster (after all the chip leg soldering – shaky hands) was the power switches. There are two; one for the main power and the other that shuts off parts of the game if you open the coin door. The coin door one was designed to prevent kids from sticking their hands in (if it was left open) and getting intimate with CRT discharging. This switch was so bad it was intermittent at best and kept the machine resetting or off (Not off, just the screen shut down).
Suggestions to others: remove the power switches, they are often crap and busted. then go to the fuses, then re-seat the chips. I should have imaged the ROM’s for a backup.
Oh, tabletops are awesome — they are convertible. Flip the internal latches and it swings open.
As of today, I made my first C64 cartridge. Most of my programming experience is either through floppy or tape-based storage. Making a ROM/BIN file and getting it to work was tougher than I thought. It was more problems with getting a CRT/BIN combo into the toolchain for testing in an emulator than to actually make a cart and burn an EEPROM. My first cart is nothing amazing, but it pumps out the INC $d021’s.
I have a few of these guys in a box, mostly for a long term project that I have been working on. I haven’t had much need for them in the last while as VICE has great networking support.
Lately, it has been crazy fun doing TCP/IP communications with the IP65 networking stack. It’s definitely the way to go for making games that need updates from time to time. Write a bootloader that fits in ROM, place it in the socket and off you go. Yes, there are issues with a ROM update later on and that you need to have internet access to enjoy the software. Oh well, it is a connected world.
One of these guys needs to get crossed with a 16 MB REU. It would be a pretty awesome combo. But for now; this thing is still great.
Yuri’s Goldfinger card was having some really strange issues — the PAS AUDIO 16 ISA card that was handling audio for the PC side of the computer was also throwing up in certain DOS configurations. The PC on a card PEAK650VLB2 ended up having BIOS corruption after finding a surface mounted resistor had popped off the card. I gave the card a hard look to see where the resistor was from, but it was next to impossible (the card has hundreds of them). If I had a card to compare against maybe, but its easier to pick up a new one. I managed to locate a replacement far far away for super cheap, which was a surprise when it actually powered up.
The card itself is a newer revision, PEAK650D4 type. The heatsink for the chipset required some ‘Mazzolla’ to let the processor heatsink slide into its spot. Whoever manufactured the card put the chipset heatsink on the wrong way. Oh well, I got it in (the processor) — with a little roughhousing.
I found a local source for a Soundblaster AWE64 ISA card. All my starting computers that were PC’s had a variety of soundcards, but never a real Soundblaster. I have a collection of the best soundcards of that era (PAS16, GavisUltraSoundPro, TurtleBeachOriginal) as I did audio work at that time. Soundblaster, though is the best card for video game support — which is why this machine is set up. Other than some funny hardware warnings from Creatives’ plug and Play loader — the card works perfectly. Doom2, Dune2 and CNC all love the config now. The PAS16 would get one or crash another.
Getting the right memory configs in DOS6.22 is such a pain. I conveniently forget the massive pain it was in that era to actually get different games to work… let alone mixing in mouse and a LAN stack for multiplayer action. Memories of NE2000 and IPX smells like burning toast.
I will say three things about Michal’s c64 programming series: his videos are fun, fast and packed with information.
I am not a bad assembly programmer, -not the best- but not bad. After watching a few seasons of his videos I started to notice subtle ways to improve my style.
There is a common problem with programmers in general. We need a problem to learn something and anything else in the way gets filtered out. So when Michal’s videos had Basic language sections, I was going to skip them for more interesting topics. I’m glad I didn’t. In fact, a few assumptions (over the years) that I’ve made were proven wrong (about the DATA statement in Basic). Suddenly, I wanted to know if there were other things that I was mistaken about.
Before you complain about it being a paid service; its worth it. It’s a good refresher and it’s interesting to see how he works and his logic. He even manages to get automated testing into the mix.. on an 8bit 64k machine. It’s worth the money and I’m happy when a new episode appears in my inbox.
I wish the drive face was at least the right size, to fit flush with the enclosure.
I’ve noticed a few problems here and there with some images; also when there isn’t a USB mounted you get a dead icon on the screen for drive DF0. I’m testing a variety of floppy images to put it through the paces. I’ve even made a 3.x Emergency ADF and mounted it.
I’ve had this one in the basement for a long time, never got it working correctly — until now.
Device = trackdisk.device Unit = 2 /* first external unit */ Flags = 1 /* important ! */ Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 Interleave = 0 LowCyl = 0 ; HighCyl = 39 Buffers = 20 BufMemType = 1 /* or 3 if you run OS 1.x */
The drive is formatting 🙂
GVP IOEtxender (high-speed serial an LPT)
BigRam+ (256MB fast ram)
X-surf-100 (network adapter)
Picasso IV with Audio add-on.
The mainboard initially had standard original custom chips (Ramsey 4, Super DMAC 2, Super Buster 7), which got upgraded to Ramsey 7, Super Buster 11. The WDC SCSI chip on the board was a type 04, which it’s now a type 08. The fast ram (8MB) was a mixed bag of chips and speeds, but they were all static column type which gave the 10% boost. A newish SCSI drive, 8.5GB which replaced a 200MB drive I found in it.
After installing the base OS, and the networking adapters — problems started to come out. Random checksum errors, enough to corrupt the drive a few times. After a few Disk Salv 4 sessions, I kept checking all the parts. I removed all the cards but the NIC and still got the errors. I had already upgraded the SCSI chip, which should have stabilized the SCSI chain. I checked the diode at D800, its direction and the voltage inside, on the port and through the cable. I double checked the drive to supply power and termination already and everything was terminated correctly.
Removing the BigRam+ for the remaining tests yielded a slightly more stable system, but the errors started coming back. I think I formatted the drive and installed the OS too many times, I was clicking and editing things while doing other things without thinking about it. The system would last a little longer with each tweak, then it would just get worse. It’s really strange, my Amiga 2000 with a GVP Accelerator installed without a problem, ever!. For some reason, I thought the A3000D was going to be open shut case once the repairs were done. This was not the case.
I had a batch of 514402AZ-60 ZIP modules, which are supposed to be static column RAM, but are not. I thought maybe a homogeneous block of chips might help the stability, also I had 16MB’s of it. A 10% fast ram speed loss for system stability I can live with.
I was reading through other people’s issues when an article about problems with Ramsey/Super DMAC revisions. The chips are paired, according to many. Others state that sometimes the mixed bag works. I pulled my Ramsey and returned the original Ramsey. Well +1 to the Paired Chips theory, the system is rock solid.
The A3000 was randomly deciding to output a proper signal to VGA. I know the monitor I was using (or LCD) was capable of displaying in the right frequency range — but only 1 out 5 power-ups would yield an active VGA display.
It was easy to tell when a good powerup would occur, as the VGA display would have some very dark gray vertical lines in the black screen.
Putting a scope on the VGA port showed signals on the RGB and H/V sync pins. Each signal looked okay from a casual inspection (comparing a good powerup versus bad). I checked all the pins around the board to see if there was anything missing on the way into the VGA… but if the VGA signals looked ok either way (on or off) then it must be a very slight signal variance.
The variable resistor on Amber was very touchy. I had a spare that would work, but I re-soldered the old part just to be sure.. it looked like there had been some work previously done on it. Using a metal screwdriver, I noticed the signals jumping around on the V/H pins. Removing the screwdriver would change the signal as well. I had a plastic screwdriver for altering TBC signals — TBC’s did the same thing with metal tools.
Without worrying about over turning the resistor, I swung it pretty far. I then noticed it was loose. After screwing it down for a while, I felt a bump and then the signal seemed to tune easier. I found the sweet spot, rebooted — VGA stable. I waited 30 minutes with the machine off tried again, still good. Off for two days, powered it up — still working fine. Nailed it 🙂