Twenty Twenty-two

It’s been far too long, almost an entire year in fact, since I’ve posted anything to this blog. While I wouldn’t say I’ve been inactive (for instance, I’ve done a lot more work on my Amigas and expanded my collection much more than detailed here) I’ve definitely been spending less time on BBS and other retro computing related pursuits in the last year or so. Fortunately, my lack of writing on these subjects reflects that more than a lack of interest in this blog.

That said, I still have tons of planned and half finished projects, and each one of those should produce at least one post, many of those are already half written as well. I also still have a lot of other content planned and even more beyond that I’d love to see make it here. It’s really been a matter of free time, energy, and the lack of motivation to push beyond those limitations. With the new year, I’ve decided to make one of my many informal New Year’s resolutions to improve that; I’ve made it a goal to make at least one significant post a month here.

Although I hate teasing anything that could wind up as vapor, I feel like I owe it to my few regular readers to give a glimpse behind the curtain. Here are some of the things in the pipeline:

  • More articles about BBS history from my perspective, including the long overdue overview of my BBS, various groups I’ve been a part of, etc.
  • Retro game and software overviews/reviews – mostly my favorite era of late 80s – mid 90s DOS and Amiga games.
  • The occasional article on misc. retro hardware, emulation, and other projects.
  • More updates on my Amiga 500 and related projects including upgrades, repairs, more acquisitions, software, and emulation.
  • Hopefully news on Darkness 2.1 and perhaps at least one more planned door game.
  • A series of deep dives into some of my favorite old BBS software packages and interviews with their authors.
  • An ongoing series of (currently accessible) BBS reviews and interviews with their SysOps.
  • Brief reviews of related books and movies, since I tend to ingest a lot of those.
  • More smaller updates about releases (such as art packs) and updates (such as Zer0net nodelist revisions.)
  • Possible compilations of this content into some old school text format zines.

Stay tuned!

REFDoor 1.2 Release

I’m publicly releasing version 1.2.0 of my REFDoor REF scripting engine door today!

This release contains all kinds of bug fixes, some new commands, and a slew of behind the scenes optimizations and improvements including changes which should greatly improve REFDoor’s performance when running on retro hardware. The most notable under the hood change is the addition of what I’m calling “memory mode” which behaves very similar to the original RTSoft RTReader by reading the entire script into memory for faster parsing and less disk activity. This may seem incredibly draft to the few of you who read my REFDoor 1.0 article and/or its included documentation and recall that the whole reason I developed REFDoor was specifically to see if I could mimic the entirety of the original parser’s behavior without reading the file into memory, but as I have vague aspirations to use REFDoor as the engine behind a future door game project of some sort, I want to implement as many options and improvements as possible.

Here’s the entire WHATSNEW.TXT file (which includes the unreleased 1.0.1 and 1.1.0 versions) for reference:

REFDoor v1.2 What's New?
---

 ! = Bug Fix
 + = Additions / Changes
 - = Removed
 * = Additional Notes


v1.2.0 - Released 02/12/2021
---

 + Added "DO CENTERPAD" command which works similarly to DO PAD and DO FRONTPAD
   but centers the string within the specified length (defaults to 80 if not
   specified) padding out the string with spaces on either side. Similar to
   "CENTER" but potentially more useful for things like title strings with
   different backgrounds, etc.
 + Added the "IS CHAR" function to the "DO" command. This function will allow
   you to return the character at the specified position from the provided
   string. Until now, you haven't been able to access characters from strings
   in REF. This should help with enable numerous string operations that would
   have previously only been possible with built-in REF commands.
 + The "SHOW SCROLL" command now optionally accepts a parameter pointing to
   an external file to display instead of parsing the "SHOW SCROLL" text
   inline.
 + Added a clean up procedure to REFDoor's startup to clean out any orphaned
   temporary file for the node being launched. In most cases this won't have
   fixed anything since most routines check for these files and remove them
   before generating a new one.
 + Added "memory mode" which loads the entire script into a memory buffer. On
   some systems this will be dramatically faster than the default line-by-line
   text parsing and with no IO hit, though on some it may not actually improve
   performance. Memory mode requires at least 64K of convential memory free
   and maxes out at around 640K per file. When using commands like "RUN" or
   "ROUTINE" to call other scripts, memory will be swapped. Memory mode is
   available by using the "/M" command line parameter.
 + Added label mapping when using memory mode - when a script is first launched
   (or reloaded after a swap) the label positions in the script are mapped into
   memory to make "DO GOTO" calls much faster on slow machines. The traceoff is
   that slow machines will also see a 1-2 second delay while this is happening.
   Semi-modern machines won't even notice.
 + As such, "NOCHECK" command as been made functional. This disables the memory
   mapping functionality from when it is encountered on. I'd highly recommend
   NOT using this for anything but very simple scripts (at least on slow
   machines - it shouldn't make much difference on semi-modern machines!)
 + Added an alternate version of "SHOW SCROLL" which parses a text file to
   memory when using memory mode. This version looks identically but allows
   line scrolling using the up and down arrows, has instant file export, and
   the find command results in the exact line of the next hit rather than just
   loading the page. The memory mode "SHOW SCROLL" should result in
   dramatically improved performance when loading massive amounts of text on
   slower machines.
 * If you're running into memory mode / memory usage issues, REFDoor logs some
   potentially helpful details about memory availability and usage. Use the
   new /V switch to see them.
 ! Fixed a display issue with the status bar in "SHOW SCROLL" when viewing a
   larger number of pages. Changed the entire layout of the status bar to
   compensate - while its no longer identical to RTReader, it still looks
   very similar.
 - The 16 bit DOS compatible executable no longer uses an overlay file. It was
   used before to leave the maximum amount conventional memory free but due to
   the way REFDoor is structured, resulted in extremely bad performance on
   older (386, 486, etc.) machines. I may revisit this in the future as it
   would allow for a larger buffer to be available when operating in memory
   mode, however, RTReader worked the same way, so this shouldn't be a massive
   negative. I would love to know if this change negatively impacts you!
 ! Fixed a bug related to page up/page down key detection, which particularly
   impacted the "SHOW SCROLL" commands.
 ! Fixed a very isolated bug where REFDoor's ANSI parser would process display
   codes if they were at the beginning of a line right after a CRLF on the
   previous line, *before* showing the MORE prompt for that line during a
   @DISPLAY or @DISPLAYFILE command, thus sometimes messing up the MORE
   prompt's display. This only fixes invalid codes - valid codes can still
   potentially be parsed this way, causing some odd behavior in rare instances
   - it's unlikely you'll be displaying files with control codes besides colors
   this way in the first place. Unfortunately a complete fix would require
   rewriting the ANSI parser (which I should probably do one of these days.)
 + Various logging changes including logging exit codes / error levels when
   a halt is issue, as well as a revised exit code scheme.
 + Added "SCROLLTOP" which lets you define where the SHOW SCROLL window starts.
 + Added "SCROLLSIZE" which lets you define how many lines long the SHOW SCROLL
   window is.
 + Added "SCROLLFOOTER" which lets you enable or disable the footer bar below
   your SHOW SCROLL window.
 + Added "SCROLLHEADER" which lets you enable or disable a header bar above
   our SHOW SHOW SCROLL window.
 + Added "SCROLLTITLE" which lets you define a title displayed in the SHOW
   SCROLL header, if used.
 + Added "SCROLLCOLOR" which lets you customize the color scheme of your
   SHOW SCROLL header and footer bars and pop-up windows.
 + Added "DO READYESNO" which will display a Yes/No lightbar prompt and set the
   provided string variable to the result.
 + Added "YESNOMAP" which allows you to define the strings of the yes and no
   selection prompts on the following two lines, respectively.
 + Included a silly little WHATSNEW.REF example script. The script's only
   function is to view the WHATSNEW.TXT file included in this archive, but it
   demonstrates several new-ish features, such as using SHOW SCROLL to view
   an external file, customizing SHOW SCROLL, using LIGHTBAR, using CENTER and
   CENTERPAD, and using DO READYESNO and YESNOMAP.
 + As mentioned earlier, there is now a /V command line parameter to enable
   more verbose logging. Generally, REFDoor will only log errors, warnings, and
   SysOp related events. If using verbose logging, you'll see additional
   information messages about loading and exiting, memory usage in memory
   mode, etc. This should improve performance, especially with memory mode on
   slow machines.
 + Modified main parser routine to more efficient handle parsing commands,
   though performance increases probably aren't noticible on anything but
   VERY old/slow machines.

v1.1.0 - Released 01/19/2021
---

 ! Added a range check to parsing string variables to prevent an invalid string
   variable reference from sometimes looping infinitly.
 - Removed some unnecessary variable / control code parsing passes from a
   several commands which might slightly improve performance in some cases.
   These commands were among the first I coded, before variables were parsed
   when read, meaning the separate parsing pass was necessary.
 * I added the following by request to assist with making BBS software specific
   doors. These are really only for specific use cases - DO STRIPALL/STRIPCODE
   should still be the primary command for stripping user input.
 + Added "DO STRIPPCBCOLOR" which strips PCBoard style @ color codes.
 + Added "DO STRIPWCCOLOR" which strips PCBoard style @ color codes.
 + Added "DO STRIPPIPECOLOR" which strips pipe style color codes.
 + Added "DO STRIPSETHCOLOR" which strips SethCode style color codes.
 + Added "DO STRIPWW4COLOR" which strips WWIV style heart color codes.
 + Added "DO STRIPALLCOLOR" which strips all known styles of color codes.
 * Likewise, added a few commands to convert BBS specific color codes to
   REFDoor's "SethCode" style color codes. Note that these only support the
   standard 16 color palette and do not support blinking or ICE colors.
 + Added "DO PCBCOLOR2SETH" to convert PCBoard style @ color codes.
 + Added "DO WCCOLOR2SETH" to convert Wildcat! style @ color codes.
 + Added "DO WW4COLOR2SETH" to convert WWIV style heart color codes.
 + Changed the REF parser version to "11". Starting from this release onward
   the versioning scheme will be based on the major+minor version of REFDoor
   itself. Since this number will always be more than RTReader and LORD 2's
   version of "2" this shouldn't break backwards compatibility, but it will let
   us use the VERSION command for its intended purpose going forward, with the
   assumption that any minor version will include changes/additions to the REF
   language.
 + Added "PAUSEMAP" command. Works exactly the same as MOREMAP but only affects
   the PAUSE command's pause string. This will let you have separate pause and
   more prompts, as long ase PAUSEMAP is defined after MOREMAP.
 + Changes to various SysOp side strings to make the aesthetic a bit more
   fitting for REFDoor rather than previous Darkness styling.
 + Futher changes to the local login to make it look a bit more like the local
   login in post RTReader doors like Planets:TEOS 2.00 and LORD 2.
 ! Fixed a various typos in the documentation.

v1.0.1 - Unreleased
---
 ! Fixed an issue where I was using a Integer instead of a LongInt for filesize
   in the REF picker menu. VP defaults to LongInt sizes for integers, but BP/TP
   uses smaller integer sizes which are too limited for this purpose.
 + Added new multinode sensitive open text file procedures similar to xDoor's
   but with remote output and logging of errors. Updated all text file read
   only and append opens (temporary files, mostly) to use the procedures. Many
   of our procs that were opening text files weren't opening them safely.
 ! Fixed a formatting issue where the time left was being set to a different
   color in Xdoor's updateTime proc than in the statusBar drawing proc. This
   usually manifested itself after the statusbar was redrawn by commands like
   DES and PROGNAME.

v1.0.0 - Released 06/19/2020
---
 Initial release.

Download v1.2.0 of REFDoor!

For the record, I’m planning on continuing work on REFDoor for as long as I continue to make any use of it. I was originally pretty wishy-washy on whether there would be any future work done on the engine, but I’ve finally decided that any work I do to it, even as part of another door, will be rolled into REFDoor proper and released. Stay tuned!

Getting into Amiga – Trouble in Paradise

Not long after the events of my last update I took the next logical step and obtained a set of Workbench 1.3 disks. For those reading who aren’t Amiga users, Workbench is the graphical interface part of AmigaOS and greatly expands the core functionality found within the so-called Kickstart portion of the operating system. While a great many of Amiga’s games and applications are bootable, for anything else you’ll be booting to Workbench. After a bit of a false start resulting from my disk drive being stone dead (which thankfully simply checking and reseating its cables seemed to correct) I was finally able to begin the process of actually learning how to use an Amiga.

Once in Workbench, I started poking around with the various utilities that make up this relatively early version of AmigaOS. As I aimlessly played, I started to encounter all manner of random issues. Sometimes the whole system would lock up or just restart, other times the caps lock light on the keyboard would come on or flash (which, similar to POST beeps on IBM compatible PCs, is one of a few ways Amigas can communicate hardware errors to the user) often with the keyboard totally unresponsive. Then this started happening at boot, before I’d even got past the Kickstart screen, and even when I got past it into Workbench it would happen within a few minutes, often when attempting to access a disk. I was perplexed, since from what I’d read many of the symptoms I’d experienced seemed to be caused by unrelated component failures. I managed to acquire an Amiga Test Kit 1.15 disk to run its numerous simple tests on things like RAM chips and CIA chip timings which all passed, easing my worries somewhat.

My very first Guru Meditation

I wondered if my fancy modern switching power supply was the issue, since I knew that the model of Meanwell I’ve got has very different minimum load requirements from the original Amiga 500 power brick, and if I wasn’t hitting that required minimum, it could be running a little out of spec. It seemed logical to guess that a misbehaving power supply could result in all kinds of odd behavior on an older, simpler computer like the Amiga 500, and of course this could easily explain any power loss and restarts I experienced. Still, after researching it more, and without a multimeter handy while catching it in the act, I couldn’t really confirm that this was the issue. I remained highly suspicious, and while this may be coincidence, I was doing most of my testing without my trapdoor memory expansion installed as I had intended to grab some before and after pictures of Workbench displaying my increased memory for my last post, and noted that when I installed it (and later, other, additional accessories) things seemed to stabilize considerably.

At one point near the peak of my paranoia about these issues, I decided to leave the machine up and running in Workbench with no activity to see how long it would take for it to crash on its own. At first it was happening within 5 or 10 minutes but it gradually seemed to go longer and longer until it stopped entirely. I wondered if perhaps Netsurge, who had given me this machine, hadn’t really used it beyond checking to make sure the Kickstart screen appeared, and that, maybe after what could be decades of not being used, some of its capacitors needed an extended “warm up”. Despite the capacitors in the Amiga 500s not being nearly as problematic as in some other models, at this age them being fully on their way to shuffling off this mortal coil was still a distinct possibility.

At that point I didn’t do anything noteworthy with the machine for a few weeks but upon my next longer session with it I immediately started to have stability issues again. This time they mostly seemed to present themselves when playing with the cables and connectors and/or moving the Amiga around, and mostly seemed to manifest themselves by way of lock ups and total power losses, resets, and odd video output behavior. Because of that correlation, I focused on the power supply once again and observed that even when things seemed to be working perfectly, rocking the supply connector ever so slightly would result in a power loss or a reset. Boys, I think we’ve got ourselves one or more broken solder joints! It’s not surprising that the some of those joints could have finally given out to the stress of 30+ years of pushing in and yanking out the Amiga’s beefy square DIN power connector, and it seems likely that inconsistent power on the rails could indeed result in all of my issues for the same reasons I outlined when talking about the minimum draw issues above, except now my symptoms coinciding with disk drive activity make even more sense. It’s also easy to imagine that the changes in stability I’d observed previously were actually just related to the port’s pins sitting just right in their joints between attempts, and the connector (indeed the whole machine) not being physically moved around too much.

Comparison of Amiga 500 Power Supply Connectors

As a quick aside, my Meanwell power supply conversion is based on an original Commodore Amiga 500 312503-02 power supply. When I plug it in to the Amiga the power connector doesn’t seem to want to sit flush with the outside of the port, though with some additional effort it will go more or less in all the way. I later compared it directly to a slightly older 312503-01 revision Amiga 500 power supply and noted that the connector is actually quite different. The newer 02 model has a fatter housing, with an embossed arrow and the word “TOP” on the top which actually hits up against the Amiga 500’s case somewhat, a longer shield and longer pins, and the “V” shaped cut out on the top of the shield is less distinct and doesn’t extend its entire length. Most significantly, the thinner, shorter 01 connector plugs in fully so that the housing sits completely flush with the outside of the port with ease. It’s quite possible that me attempting to force the longer 02 connector “all the way” in (which, I now know is unnecessary) and then later struggling to yank it free is what damaged the port’s solder joints. 🙁

Opening my Amiga and disassembling it entirely for the first time, which involves unscrewing every single rear connector from the bottom shield so you can see the underside of the motherboard, I confirmed my suspicion. It was fairly difficult to see, but one of the DS-215 connector’s eight pins (pin 1, which is the all important +5V rail!) seemed to have a cracked or broken joint, or, perhaps by the looks of it, maybe even a cold solder joint from a past repair. In any case, it was visibly moving ever so slightly when the connector was wiggled. Time to break out the soldering iron!

The solder joint of doom.

Somehow, despite both a hobbyist and professional computer nerd for 20+ odd years, I’ve always completely sucked at soldering and would typically avoid it in all but the simplest tasks. Still, I figured that simply “reflowing” the existing solder on the broken joints with my busted old cheap soldering iron and perhaps some fresh solder wouldn’t be too far outside of my comfort zone. After talking to a few friends with some degree of expertise in electronics, I was convinced that a vastly superior fix would be to completely desolder the connector and start fresh to guarantee that I had reliable joints that would last me for many years to come, even with my abuse. Scary, but “challenge accepted” I suppose. I mean, this is the age where there are dozens of tutorials on YouTube for even the most obscure tasks, after all.

***Cue an intense training montage of me unboxing and setting up a bunch of brand new soldering equipment and supplies, and practicing soldering and desoldering a variety of small practice kits until my joints were impeccable and I could desolder an entire motherboard in mere minutes. Eye of the fucking tiger!***

While the first part isn’t such an exaggeration, I assure you that the results definitely are. Still, I worked on practicing and improving my soldering skills for a couple of weeks before it was time to put my beloved Amiga 500’s precious motherboard under the iron. As planned, I applied a bit of liquid flux to each joint and used my soldering iron to heat them, then used a spring loaded “solder sucker” and some desoldering wick to remove the solder from each pin entirely. The shield ground pin and the three shield pins gave me some trouble, since, as I now know, they lack thermal pads which causes the heat from a soldering iron to dissipate much more quickly, but the rest went well enough and in the end I was satisfied. I then soldered each pin with a nice new joint, including making sure to be a little generous with the three shield pins, since they seem to provide the most support to the connector port itself. Simple enough!

The outcome? Well, I’m pleased to say that it seems my stability issues are now resolved. While rocking the power connector doesn’t cause any power loss or restarts, at least when fully inserted, I also haven’t observed any stability issues since making the fix. I’ll know more the more I use it of course, but for now I’m happy with the repair.

Time to RTFM

Now, about the whole “learning AmigaOS” thing, I guess I have some reading to do…


1. The infamous “guru meditation” error. This is actually the only one of these I saw during this ordeal, and probably not even related to my problem, but hey, it makes for a dramatic picture all the same!
2. A side by side comparison of the slightly different 312503-02 (top) and 312503-01 (bottom) power connectors.
3. The broken power connector solder joint on the bottom of my motherboard.
4. RTFM time? The original Amiga 500 user’s manual, chock full of basic AmigaOS tips and colorful pictures. Neat.