I am working on getting an old DarkStar BSS up and going, which was powered by a decent collection of hardware. I have an SFD-1001 that has been working for a long time, but has fallen prey to the floppy motor board leaking capacitors. A problem that is common now to most of the Commmodore IEEE drives.
Initially I thought it was IC related problems — I swapped out a 6432 RIOT with a known working one from an Atari. A have a friend who would scream if he knew I tore apart a 2600 to get this drive going 🙂
In the end the drive was reporting: Status on reset: 73, cbm dos v2.7,00,00,0 Detected as “9: 8250 dos2.7” A dir on the device throws : 74,drive not ready,00,00,0 and the drive Drive motor doesn’t spin.. but the head moves…
So the Commodore side of the circuitry was working fine, I could download the ROM’s using the ZoomFloppy. So if everything is talking but the disk isn’t spinning — you have this problem.
A little scraping and cleaning, with a capacitor replacement and everything goes amazing. Back up and running — UHH No.
I was pretty happy when my format tester ran without issue.. but if you run it again.. and again.. it has problems. After some discussion with another SFD user/restorer and a parts list, I’ve order some more capacitors and decided to go after few more possible culprits. When the parts come in, I’ll give it a whirl.
I had BBS in the day, well I ran a few. The first one was on a C64 called Cybertron and my alias was Optimus Prime. There were a few BBS programs out there, but my fave was DarkStar, I also used its companion terminal Darkterm. I spent a lot of time doing PETSCII art (using font letters and shapes) to make the BBS look good. Other BBS’s were The Crypt and SDF1.
PETSCII/ASCII art is great for people like me, who need the colours written on the markers and crayons. Colour by numbers 🙂
I’ve been reading for last week 6502 Software Development by Scanlon. I’ve been sick and its been keeping me company. It is weird reading a technical programming book which is “by the book” and then read some of the code I’ve been using/borrowing/suggesting recently. My code has been riddled with so many intentional bugs/glitches to get amazing side effects. I really wonder what Scanlon would have said after reading what went on below… it is a great read for people into 6502 asm.
Yes… It is in a state for review –so download it here: Trogue.
You’ll need VICE or compatible emulator. It runs best in NTSC, but I spent a lot of time getting it stable under various PAL systems.
Sometime in the ’80s, a zombie outbreak plagued the local town. A daring group of heroes lured the undead to an abandoned mine. On the 64th level, they blocked the trogue (drain) and flooded the mine.
Recently, a depth alarm has gone off — the mine is draining. Someone has popped the Trogue!
Start from the lowest part of the mine, activate 9 pumps to flood the ravenous undead before they can escape. Each pump raises the water level, so move fast — or join the ranks of the undead!
All the levels are randomly generated, with a basic AI for the monsters and turn-based movement/combat. You level your character up through combat, which in turn boosts your maximum hitpoints. There is a timer though, water rushing in as the player activates the pumps on various levels. Too many pumps at once and risk drowning, not enough (say 9) by the end and you can’t escape.
There is a crowbar for extra damage, a medkit to heal, oxygen tanks for those water moments and a holy hand grenade when the denizens of the mine overwhelm you. Sometimes there is a clue that a pump exists on a level or just an old plan for that area is just lying on the floor (it might be a little outdated).
Watch the border water meter, it shows the current water level and the mine level.
Finally, I moved the site over to a new server. There was so much hassle with the old provider. It took a few hours — to get everything backed up and moved over. I get to pay half as much for 10 times the performance. I wish I had moved years ago.
There were a lot of things that I learned in the process of making this game. I can’t imagine making something like this back in the day. I’ve always had a lot of respect for the games and software developed for the machine on the machine. Without emulation, this would have been a real mess.
I’ve never made MultiColor GFX (serious ones) and it was always this mystery to get a koala painter image going with a scroller. I always wanted to make an ESI Intro (that eagle one). Draw a cool picture, make a custom font scroller and bang out a simple tune. I could do everything but the picture.. there was always something getting in the way.
Cross Development is really hard in the MC Picture side of things. I’m used to Photoshop or Deluxe Paint for source material.. but getting it looking ok on the commie was a royal pain. At the end after piles of crashing plugins and ageing software, I found something that works great:
Photoshop could be replaced by any other bitmap software, but it is what I am comfortable with. GangEd is great for the conversion and troublesome as an editor. I would love to help clean up that application.
I’m colour blind ( Protanopia ), so having some colour conversion or colour by numbers is really helpful. So the tool/dev chain above really helps.. if I had to come up with gradients by eye… well that is not going to happen. Also having the commodore palette files for photoshop is really helpful.
I can do sprites and fonts ala code, which in the day I also had a nice editor from Compute! Gazette — but SpritePad and CharPad are awesome tools. It’s also handy to load snapshots from VICE and see charsets that have been modified by code or have as a reference for where things are.
One of my “like to have” addons for Trogue64 is fade/pattern wipe for the intro graphic. It’s not hard but I had to draw the line somewhere to get this to Beta.
I bought one; Acer’s X34P. There are people that love them and others that have RMA’d them multiple times.
There are a few caveats; not only did this work (not right away either) but it’s in a KVM config which really should be the kiss of death for this to work correctly.
Initially, the display was connected via DP to a KVM (GCS1934), to 4 machines (Win10/Nvidia670M, Win10/Nvidia980ti, Win10/Nvidia1060 and MacOSX). All of these connect at 60hz. All of these display full-screen native resolution.
On the 980ti machine, I ramped the display up to 100hz and random intervals I’d get the DP port resetting (brief blackout screen and DP Logo in the upper right corner). It was annoying. Running the overclock made it worse @ 120hz. Games or desktop. A lot of config fiddling led to slightly better results but still flickering. I turned off the audio (which was my plan from the start as I dislike monitor sound).
A lot of reading later, I unplugged the KVM from the mix. Surprise — worked. I need that KVM. So I pulled the segment of DP cables that that particular machine was using. I had the heavy duty (well made) and worked in my non-KVM test as the monitor. This cable was really long. I had a few 3 footers that were decent quality. Once I made the run smaller, the KVM and the display worked at 120hz.
There are a lot of thoughts about cable quality — but sometimes length throws things out of whack. I tested this with 10 cables. Only the short ones (except for one) worked.
Now that it works with everything — I love this monitor. The first thing I am doing is replacing the base stand with a desk arm.. man those feet are huge.