Skip to content

Real instructions on getting a Lantronix UDS-10 serial-to-Ethernet bridge working

CommodoreTI-99/4A (edited to add data from IM for accuracy -- want this to be correct and complete)

The Lantronix UDS-10 is rather popular among the AtariAge TI-99/4A crowd. It's basically one port of a Cisco 2511; it's a bidirectional telnet-to-serial bridge. The TI folks use it to connect to the outside world, because it is extraordinarily unlikely that the TI will ever get even a ten-megabit PEB card, due to the screwed-up interrupt handling on the TI. It's also a fantastic alternative to the Commodore 64NIC+, without any of the compatibility problems that go along with it.

A fellow named "Omega" (or "Ohm"; real name elided here) put together a document that purports to describe configuration. I'll be right up front here and say that I don't care much for "Omega" (and he doesn't like me much, either). His antics were a large contributing factor to my departure from AtariAge. I see him as an "ideas man" ... not a guy that actually produces anything, but constantly chirps up with "wouldn't it be cool if somebody did X" and doesn't understand anything about engineering or technical design. I also suspect that he was the author of an anonymous nastygram to yours truly awhile back; I can't respect anyone who hides behind anonymity while engaging in armchair psychology.

His UDS-10 document, which I will not link to here, is a good example of that. It's about 80% correct, but like most things that Omega "creates", that 20% will kill you. Not a word in the document about what one would do with a UDS-10 fresh off of eBay, with completely incorrect network configuration. No, Omega would have the UDS-10 purchaser install a Windows program to search for the unit, then try to configure it via telnet.

As usual with things that Omega writes, that'll only work in specific limited cases (i.e., the eBay seller resets the UDS-10 to factory default before shipping) and doesn't mention the existence of newer/better firmware. But no worries, as the official documentation and firmware is still available from Lantronix. I've put up a mirror here, but here's the general gist of what you want to do:

  • Do not buy a UDS-10-IAP. It will not work properly due to fatal firmware bugs. You want a plain UDS-10. Thanks, IM, for the pointer -- I didn't know there was a difference between the two.
  • Plug the UDS-10 into a serial port (USB, onboard, whatever) connected to a real computer running a real terminal program. Settings are 9600 8N1. Hold down the "x" key ...
  • ... while attaching the UDS-10 to power. That'll force the UDS-10 into setup mode on the serial interface.
  • Hit 0, and set it up for an IP address of to make it do DHCP. Or set the proper IP address for your LAN. I assume that you know your own network better than Omega does.
  • Set whatever other parameters you want here. The important one is the IP address. Once back at the main menu, save and exit.
  • If you are doing DHCP, watch your DHCP server logs for the DHCP lease. If you're doing static IP, then wait about a minute for things to stabilize.
  • Grab "ltx5805.rom" from either the official Lantronix site or my mirror referenced above.
  • tftp to the UDS-10 IP address. Set binary mode. Execute "put ltx5805.rom 3L". The UDS-10 will upgrade to the latest firmware and reboot.
  • Hold down the "x" key in the serial terminal while rebooting to get back into setup mode.
  • Choose option 1.
  • Port speed maximum 2400 for TI (9600 for Commodore 64 over user port with UP9600 and so forth), I/F mode 4C, flow 02, port 0, connect mode D6, auto-increment. That's mostly the same as Omega's doc, except you want to use 0 for the source port (to randomize) and auto-increment (again, to randomize).
  • That should do it. Read the official docs for more information on how to use this device; don't rely on a random shiny PDF floating around AtariAge as an official source-of-truth.

    When you get your unit working on your TI, please patronize IM's resurrected HeatWave BBS at (port 9640). It's all well and good to telnet into your *NIX boxes to transfer files, but the real fun is the BBS experience.

    (Omega, I replied to your comment via the email address you broadcasted on AA. I'd like to continue that dialog with you, but lack of response tends to support my hypothesis as set forth in the first few paragraphs of my email. The ball is in your court)

    Upgrading a Super Snapshot V5.xx to 32k

    Commodore So I've been in China for the past several weeks, trying to get ${EMPLOYER}'s crash production project back on track and mostly failing.

    Having returned to Tokyo for a couple of days' rest, I'm not feeling up to doing anything heavy on the TI EE front. Feeling that I needed to do *something*, though, I decided to take a look at upgrading one of my Commodore bits-and-bobs.

    Freezer cartridges were very popular in the Commodore ecosystem in the mid-nineties. A lot of people (mostly Europeans) swear by the Action Replay cartridge, but I always preferred the Super Snapshot. It was more geared towards the cracker than the Action Replay (which was geared towards the "infinite lives" gamer demographic).

    I still have an original Super Snapshot v5.22 cartridge. I've left behind the original console, drives, and 100% of my software library over the years ... but somehow, that cartridge was always packed away somewhere in my seabag.

    The Super Snapshot came with 8k (in the form of a 6264) on board, and was upgradeable (via returning it to the vendor) to 32k. I used the multimeter on a few traces, and determined that not only could it be field-upgraded, but it was built to use the 62256 as an upgrade.

    Those who have been following this 'blog have probably figured out that I have roughly a billion 62256s lying around as part of my TI HRD+ experiments. So I fired up the soldering iron, unrolled the desoldering braid, and had at it.

    Pro tip: the original manufacturer didn't clean up the left-over flux from the original FATP process, so it's best just to clip the 6264 off of the board, pull the leftover pins, and clean up the holes with the braid. Scrub well with isopropyl alcohol, let it dry, and put a 28-pin socket in.

    There's an unsoldered jumper block right next to the SRAM chip marked J1. It's hard-wired for a 6264. Cut the trace between position 2 and position 3 of the jumper block, put a wire between position 1 and position 2, and emplace a 62256. I recommend the Alliance CMOS 62C256, but whatever is available is fine.

    If you're wondering what J2 on the board does, it's for the C128 kill switch. If you have a C128 and you want to keep it from going into C64 mode when the cartridge is plugged in, cut the trace between the poles on J2 and use a switch to bridge the now-isolated poles.

    So there you go ... if you have an original SS, this is how you upgrade it to 32k. Hope this helps someone.

    EasyFlash Infocom images

    Commodore It turns out that EasyFlash support was a hell of a lot easier than I thought it would be, and it is very fast.

    I am reluctant to implement saving games to flash; there's not enough free memory to include EasyAPI for all three official interpreter versions (three pages needed? Really?) and I do not want to bang on the hardware directly.

    I have combined the games into three EasyFlash images, roughly sorted by type or genre.

    The first v3 image contains:

  • Zork I
  • Zork II
  • Zork III
  • Enchanter
  • Sorcerer
  • Spellbreaker
  • Deadline
  • Witness
  • Suspect

  • (i.e., the Zork double-trilogy and the murder mystery trilogy)

    The second v3 image contains:

  • Planetfall
  • Stationfall
  • Starcross
  • Suspended
  • Hitchhiker's Guide To The Galaxy
  • Leather Goddesses of Phobos
  • Seastalker
  • Wishbringer

  • (i.e., the science-fiction games, although "Seastalker" and "Wishbringer" sort of stretch that definition)

    The third v3 image contains:

  • Ballyhoo
  • Cutthroats
  • Hollywood Hijinx
  • Infidel
  • Lurking Horror
  • Moonmist
  • Plundered Hearts

  • (i.e., everything else v3)

    The v4 image contains:

  • Nord and Bert
  • Bureaucracy
  • Trinity
  • AMFV

  • There are no real functional changes between the standalone images I made last night and these images -- they're just consolidated, with a very simple pre-game selection menu.

    They can be downloaded at:


    Saving game files to EasyFlash will not be implemented, at least not by me. Here's why:

    The EAPI requires three pages. With careful pruning, I think I can free up enough memory between the end of the interpreter and the beginning of the resident data to accomodate that. I'd remove the printer transcript routine (which I suspect wouldn't be missed), relocate the story selection menu to ROM (where it should be anyway), and a couple of other optimizations.

    The self-imposed constraint that I'm working with here is that there will be one executable per version that handles all hardware cases -- uIEC-only, uIEC/REU, uIEC/GeoRAM, uIEC/EasyFlash, EasyFlash-only. This is to make my life easier, as I was having a hell of a time keeping things straight when everything was selectively #ifdef'ed for specific hardware.

    I believe that I can bump up the resident start address a page or two. I've tested this with the v3 interpreter with no apparent ill effects, and I don't believe that there are any v3 story files floating around that even come close to hitting the $D000 cutoff. I haven't tried this with v4 or v5 yet.

    The second bullet point is a bit more troublesome. The save files are essentially a memory dump of the entire Z-machine state. That's 52 blocks for v3 (so 13k), 66 blocks for v5 (so 16k), and a whopping 131 blocks for v4 (so 32k). Setting aside three to five extra banks per game for savefiles is doable but would permit fewer story files per image.

    I honestly think it's better/safer to keep the EasyFlash as a read-only REU substitute, keeping save game functionality on the serial bus. This project started as a way to play Infocom games on the uIEC (with the nice side-effect of removing the need for RAM expansion); since the EasyFlash and the GeoRAM share identical paging schemes, read-only EasyFlash support was easy. Writing save game files to EasyFlash will significantly shorten the lifespan of the EasyFlash and severely reduce the number of games per image. Sorry.

    Commodore 64 Infocom uIEC interpreters

    Commodore I have disassembled, dissected, and modified the latest officially-released C64 interpreters to work with the uIEC without REU, and high-storage Commodore drives with REU or GeoRAM. The v4 interpreter allows the C128-only games to work on a C64.

    Infocom games, as released for the Commodore 64, are very tied to the 1541 disk format. Commodore didn't believe that random-access files had any purpose, so the Infocom engineers were forced into using raw-sector access schemes to jump around in the story file. When the REU was released, Infocom modified the interpreter to load the entire story file into RAM, but continued using the raw-sector disk format to maintain backwards compatibility for non-REU owners.

    This, naturally, makes playing these games on non-1541 drives somewhat unpleasant. One would have to use d64 emulation, swap virtual floppy images to save games, and so forth.

    I have an uIEC. In fact, I have several. I love the uIEC. And I wanted to be able to play Infocom games on it, with as little effort as when I play on a UNIX workstation.

    To that end, I have disassembled, dissected, and modified various revisions of the C64 v3/v4/v5 interpreter to work with the uIEC (and other large storage devices). It requires a REU.


    To use these interpreters:
  • Create a directory on the uIEC for each separate v3 game,
  • Create the binaries by running "make" in the directory sourced from GitHub. You'll need exomizer2 from here, and xa65/printcbm from here.
  • Copy the story file into that directory as "STORY.DAT"
  • Load and run "INFOCOM3", "INFOCOM4", or "INFOCOM5"

  • Notes:

  • The 1541/1571 fastload routines were removed.
  • The story file is loaded from "STORY.DAT" instead of raw blocks.
  • To accomodate the above, an REU is now required.
  • The number of save slots has been increased from five to nine.
  • Save games are 49-block seq files named "SAVEn", where n is 1 through 9
  • The game can be run from any device number, not just device 8.
  • REU mirrored register access has been fixed.
  • TODO: use George Hug's 2400bps RS232 routines to replace printer code
  • TODO: C128 80 column support

    The source code (no binaries, sorry) can be found on GitHub here.


    The v4 interpreter, as sourced from the "Nord and Bert" d64, does something really interesting with the resident size when setting up the virtual memory scheme. If you look at a non-C64-sourced version of N&B with infodump, you'll see that the resident size is hardcoded to $AEFF.

    Forcing that value with all other v4 games results in a working game, even if the resident size overflows available physical memory. The interpreter already assumes that anything over $F900 (start of $3A00, skipping $D000-DFFF) needs to be paged in from REU/DISK, even if it is "resident".

    This implies that the lack of support for v4 on a stock C64 was not due to lack of physical memory, but rather lack of available disk space. Infocom could have supported the C64 on all of the eight-bit titles that it released, if they'd embraced the 1581 or went to a multi-disk scheme.

    There's a fair amount of weird stuff in these interps. There's orphaned code fragments in v3/v4, a "Test1" string referenced nowhere in v5, and I'm still trying to understand why the author(s) went to separate hi/lo jump tables in v4/v5 rather than continuing with the unified tables in v3.

    I have read that the fabled Infocom backup drive that surfaced a few years ago includes complete source code to the various interpreters, including the ones I'm reverse-engineering. I'd very much like to see that source code.

    They made a mistake with the latest official version of the v3 interpreter ... since the $DF00 range isn't completely decoded by the 64, there are mirror registers every thirty-two bytes. The v3 interpreter uses $DF28 instead of $DF08 in several places. This isn't a problem with original hardware, but things that emulate the Commodore REU (particularly the 1541-Ultimate) fully decode that memory page. People needing fixed d64 images (i.e., those using the 1541-Ultimate or an emulator) can obtain fixed images here.

    The interpreter source code has been sanitized; it lacks all of the #ifdef'ed code that made it possible to generate the original unmodified interpreters from these sources. That means that the weirder original implementation oddities aren't included. I can/will make that available later ... it was interesting reading.

    I've concluded that the Apple ][ target was the reference platform, and other 6502 ports were derived from it with differing degrees of Apple-specific code accidentally left in the Commodore versions.

    Also, the guy(s) who hacked the Commodore code into the v4 (and by extension v5) interpreter was probably an intern, not terribly familiar with rational code flow. And I do mean "hacked" -- subroutines will suddenly jump past a bunch of unrelated code, the elegant word-based jump tables were deprecated in favor of split-byte jump tables, and there was some unholy stuff going on in the virtual-to-physical-address logic. Most memorable was the bit that asked which of seven slots the printer was at.

    While I was looking at the SD2IEC docs to see if UI or UJ was the preferred way of getting a 73 status for identification, I noticed this:

    Positioning doesn't just work for REL files but also for regular files on a FAT partition. When used for regular files the format is "P"+chr$(channel)+chr$(lo)+chr$(midlo)+chr$(midhi)+chr$(hi) which will seek to the 0-based offset hi*2^24+midhi*65536+256*midlo+lo in the file.

    ... which means that running from the uIEC doesn't require any RAM expansion. We can just seek to the proper offset in the story file. It'll be a tad slower than running from REU/EasyFlash/GeoRAM, but it'll work.

    The banking/addressing scheme for GeoRAM is exactly the same as for EasyFlash, so I have implemented that also. It's actually slightly faster than the Commodore REU.
  • Project: Space Station (Commodore 64)

    Commodore One of my favorite games was Project Space Station. The game was fun, but the implementation had a couple of deficiencies ...

    ... first, the programmer(s) decided to put the splash screen into raw sectors and load it in via a bunch of block-reads. Although the game could be copied to another floppy by regular file copy, the splash screen would be missing.

    Second, the disk wasn't write-protected. Players would commonly forget to save games to separate disk, and thus corrupt the splash screen (and incompletely create the save file). This might be why many images floating around on the net have either a corrupted splash screen, one or more splat files, or both.

    Third, a fastloader was incorporated. This fastloader wasn't very fast and didn't work well (or at all) with anything that wasn't a first-flight 1541.

    When I was much younger, I fixed my copy to do the following:

  • load the splash screen from a regular file,
  • disable the fastloader so that better (hardware) methods could be used,
  • use $BA instead of a hardcoded 8 so the game could be run from other drives,
  • load all files into and from a REU if detected to dramatically speed I/O.

    To accomplish this, I removed the save files to make room for the splash screen. That seemed to be a decent compromise at the time.

    I sold my Commodore in the late eighties, and with it went this version of the game. It probably doesn't exist anymore ...

    ... but I decided to recreate it. The new version leaves out the REU support, though it would be trivial to re-add. I used Exomizer to shrink "TITLE" and the splash screen data so that the example save files wouldn't have to be removed.

    This version works very well (and very fast!) on a uIEC; I expect it would do well on any JiffyDOS-equipped machine. It recreates the original playing experience (i.e., without annoying "cracking scene" intro) and fixes issues with new hardware.

    The .d64 image and various files modified from the original can be downloaded here.
  • SSI Dungeons & Dragons Forgotten Realms games modified for uIEC usage


  • Pool of Radiance (sourced from original, uIEC fixed, protection removed)
  • The Curse of the Azure Bonds (sourced from original, uIEC fixed, protection removed) (uIEC XE2 fixed, thanks to blaupunk)
  • The Secret of the Silver Blades (sourced from original, uIEC fixed, protection removed)

  • The entire directory is here.

    These zipfiles should be extracted into directories on the uIEC SD card, cd'ed into, then execute "00boot". The uIEC is set at runtime to extended mode 2 (i.e., executing @"XE2") to enable support for wonky character filenames.