Maxwells’ Silver Doofer: Dead in the Water

Count this as the biggest of big fails for Retrochallenge 01/2016… Maxwells’ Silver Doofer just never really got going.

January was way too busy with

  • massive amounts of commercial overtime,
  • attempting to swim a distance equivalent to a lap of the TT course (for charitable porpoises),
  • sorting out personal tax affairs (jeez, the govt make the process way more complex than necessary, I had to take a vacation to get it done!),
  • disproving a bogus public claim that an RPi-B was 40 times faster than an SS20 model 612 (hint: not when both are using a recent C compiler – a lot of the observed difference was really that between an ancient C compiler and a modern one),
  • getting obsessionally distracted by the idea of building a homebrew 8-bit expandable computer using a CPU that has AFAIK never been used for that before,
  • planning how to transport a set of heavy very bulky goalkeepers’ all-body protectors, leg/chest pads, gloves, kickers and helmet for an overseas hockey away-trip – without breaking the bank or my back, et al, et al.

Let’s just say I had way too much other stuff going on, most of it my fault!

I did get as far as writing a DOS program that could decode the header of any Idris executable file, and extract (with byte-order conversion when needed) the code-section, initialised-data section, and relocation information. However, the key task of splitting the code-section into separate x86 startup-code and compiled-C-object-code pieces never even got started (it would have taken quite a bit of research and experimentation, not to mention the necessary enthusiasm which unfortunately just dribbled away).

I guess this is par for my course: I seem to be able to manage only an average of one proper RC project a year… Perhaps this kind of endeavour should be reserved for a younger generation? You never know, they might even learn something about “The Good Old Days”.


Maxwells’ Silver Doofer: Episode 2: Reasonable Gratuitous Incompatibility

The Idris Users Manual is a tutorial-plus-reference-manual for “plain-old” users of an Idris system: Excellent tutorials on logging-in, how to enter commands, use of files and directories, text-editing, using the command-shell, and so on; plus reference manpages for the commmand-line programs, specific file-formats (password file, /dev/null, timezone, login-history file, mounted-filesystems list-file, etc); plus a system-administration guide.

Table of Contents:

Given my long-time UNIX experience, what am I going to need this manual for? Well, for the Maxwells’ Siler Doofer project I need to be able to inspect binary files in various ways, thus I am going to need the reference manpages for the “od” (Octal Dump) and “dd” utilities: the Idris utilities are not completely command-line-compatible with 6th Ed. Unix, nor 7th Ed, nor indeed any other UNIXen – but there is a very good reason for that…

Back in The Day:
Idris was a clean-room reimplementation of the ideas of 6th Edition UNIX, binary compatible with UNIX on the PDP-11, but improved in the following ways (of the ones that I can remember):

  • intentionally coded for easy portability
    Idris was ported to a lot of very different systems, including most models of PDP-11 (yes, even the LSI-11), a whole slew of different 68K-based minicomputers, Apple Macintosh, Atari ST, DEC VAX, IBM 370, IBM PC and compatibles, the multi-Transputer-based Parsys SN1000, an even an Intel 8080 system using bank-switched memory!

    This meant that the manner in which Idris was coded differed at the implementation level from AT&T UNIX – it could not just rely on the oddball PDP-11 double-word byte-order, or particular PDP-11 register-usage – it was much more modular, and used accessor functions to cover (most) low-level portability issues such as data-alignment, byte-order, cross-system binary compatibility of on-disk filesystem structures, etc.

  • carefully designed to not absolutely require memory-management hardware,

    …but to be able to take advantage of such should it be present.

    This alone means that the internals and structure of Idris are in places very different from the AT&T design. Note that AT&T UNIX for the LSI-11 and PDP-11/23 was quite different than that for the PDP-11s that included memory-management hardware – almost more like reimplementations; conversely, Idris used the same codebase for all the ’11s, and apart from the tiny CPU-context-switching and stack-munging assembly-code segment, used the same (conditional) C codebase for all different types and families of CPUs.

  • a hybrid process-scheduler

    …providing both “real-time” fixed-priority and “fair-share” adaptive-priority scheduling (this was a later addition, not present in the very first 1979 version which was “fair-share”-only).

  • Consistent command-line options for the provided utility programs.

    Most AT&T UNIX commands of the time each used their own somewhat idiosyncratic command-line options and filename-selection criteria, which could be a royal nuisance for users, especially when learning how to use the system.

This last reason is why I need the Idris manpages for “od” and “dd” – they have different command-line options than the UNIX versions.

Reasons: Back In the Day
Given that gratuitous although slight command-line incompatibility with UNIX could be seen as a disadvantage (as well as an advantage) for users, why did Whitesmiths do that? There was of course the “beauty and consistency” reasoning, but there was also the “legal threat” reason: at the time, AT&T were starting to think of UNIX as a potential commercial product, and were presumed to be open to the possibility of using the judiciary to attack and confound any “deliberately interface-compatible” commercial potential competitor. Yes, even well before the late-80s tsunami of look-and-feel lawsuits that later plagued the IT industry.

This reasoning meant that it would be wise to sacrifice absolute user-interface compatibility with AT&T UNIX in the (purported and real) name of user-interface consistency. Although it was a cosmetic change, the utility of the changes (easier use and training) was a point that could reasonably be argued in court as a rational technical difference should the need arise.

The Henhouse:
The same reasoning applied to Whitesmiths C Runtime Library, which was famously API-incompatibly with the UNIX C “stdio” library: again, it was presumed that AT&T might just apply legal pressure against any interface-compatible competitor; the C language proper was not thought to be at the same risk, as the core language had been described in detail (without assertion of formal intellectual property) in several freely-available publications, including of course the K&R book. The runtime library on the other hand, was more of a grey area, which did not get resolved until the 1989 ANSI C Standard was published, at which point “reimplementation” lawsuits became moot.

Famously, when Whitesmiths’ founder was appointed in charge of the Library Subcomittee of the ANSI X3.159 standardisation effort for the C language, one commentator made the dry observation that, due to that deliberate historical incompatibily, it was like “putting the fox in charge of the henhouse”.

Next episode, I’ll pick up on another key Idris manual needed for the project.

Maxwells’ Silver Doofer: Episode 1: How Not to Start a Project

Sheesh! January so far has been insanely busy with overtime at work, and if you add in the start of the Mens’ hockey season and the first Firemans’ Run of 2016, I am turning up a little late to this months’ Retrochallenge event.

My original intent was to get started 10 minutes after the start of 2016, not 10 days after. However, as is often the case, as well as paid work, some hardware distractions took over from the supposedly software project: dreaming of HY6264 parallel SRAMs, 74HC138 address-decoders, MC6850 ACIA serial-interface chips, 74HC373 bus demultiplexers, micro OLED screens, 28HC64 parallel EEPROMs, and also what on earth to do with a shed-load of serial RAM chips. Get a grip, man!

Of course, there was also the (strangely recurring) task of repairing an acquaintances’ “dropped it down the stairs and smashed the screen and internal disk-drive” laptop. No, of course there isn’t any recovery-/reinstallation-disc, nor any backups. I might have to cut down on doing these kind of favours!

Restart and Restatement:

My project-introduction posted last month was a bit of a rambling discourse written in the style of a disjointed rant (!), so perhaps I had better restate the task in a rather more direct way:

“To retarget an ancient closed-source MSDOS C compiler to generate programs for a proprietary closed-source 6th Edition UNIX clone (8086-based).”

I do not have any of the runtime libraries or C-runtime-startup object-code files for the target system (Whitesmiths Co-Idris/86), nor any documentation of the system-call sequence. So part of this project is going to be low-level reverse-engineering and general cheating.

The Dead Trees Society:

I come to the project armed with some old paper-only Whitesmiths’ manuals, which were much better than the old AT&T 6th Edition UNIX manuals – actually organised properly by topic and are-of-interest, with useful tutorial sections as well as the reference pages. I have had these since March 1991, gathering a copious layer of dust over the last 24 years, so I guess now is a good time to make at least a little use of them!

The following posts will summarise the contents of these manuals, as it might just be at least a little illuminating. As always, of course, I am missing the one manual that would make the task possible: the “Whitesmiths 8086 C Interface Manual”. The PDP-11 and 68k C interface manuals that I have are not going to be much help here!

Small Things Come In Big Packages

During December 2015, Digi-Key Electronics have been running a Christmas Draw; by posting to Twitter or Facebook with an appropriate keyword (“#DigiWish”), you can wish for parts from their catalog, and if you are drawn out of the hat, Digi-Key would gift them to you for no charge and with free delivery.

Of course, to prevent abuse, the offer is limited to parts costing less than $100 and also only parts shown as “in-stock” on their website. Perfectly reasonable!

So far so good, but there is a little tale to tell…

Being Fair
I know some people who, when faced with such an offer, would automatically pick the most expensive eligible item they could find, whether they needed it or not. I’m not a fan of such behaviour, it is a form of abuse, so I was of course only #DigiWish-ing for parts that I really needed and could use.

I have been toying with the idea if building my own miniature old-fashioned 8-bit computer using a 68hc11 CPU (I have a few of these), so around the 2nd week of December, I #DigiWish-ed for a (single) memory chip – an MT 23K256-I/P: an asynchronous 32-Kbyte SRAM chip with a serial SPI interface and through-hole mounting. 8-DIP_sml

I wanted to play with the SPI capabilities of the 68hc11 and had some ideas for using SPI-based storage for an editor-buffer and filing-system-index cache, assuming I get as far as building the computer!

Such an SRAM chip is listed on the Digi-Key website at $1.08 each.

Information Requested
For non-USA residents who win one of the draws, Digi-Key require a little information from the winner, to keep the US export authroities happy: (1) what is the item going to be used for, and (2) where is the ultimate destination of the resulting “product”.

I dutifully emailed them with a brief description of my home-brew old-fashioned 8-bit computer project, and asserted that the result would not be travelling any further abroad than my home. ie: this is a one-off construction, for my own enjoyment only.

That’s One Heck of a Big Matchbox
It turns out I won that days’ draw, and had thus been eagerly anticipating a matchbox-sized parcel from the postman.

However, what turned up was a large parcel over 2 feet long! The contents were even more amazing:

Yes indeed – the package contained 90 SRAM chips – $100 worth of chips, in fact!


Even allowing for me breaking a couple whilst soldering, I’m going to have to dream up some other uses for all these! Maybe a multi-drop multi-slave SPI circuit so I can have a dozen or so attached to the single 68hc11 SPI port at the same time?!! Mind you, a 2MHz 68hc11 would take some time to read or write the equivalent of 6 times its’ main-memory address-space across an SPI interface…

So a big thank-you is due to Digi-Key, even though their generosity has overwhelmed me and given me a little headache trying to find a use for the other 2848 Kbytes of serial SRAM I now have to hand…

Merry Christmas!

Maxwells’ Silver Doofer: Crass-Compiling

Once more unto the breach: Retrochallenge 2016/01 draws near and it is time to decide what my entry project should be.


This time it is really hard to decide what on Earth to do – as outlined previously, the “Galaxy Pressed” project is just too expensive (although there has been a recent post on the sun-rescue mailing-list of a Sun 3-slot 9U VME deskside enclosure available for postage cost only, an SS600 mainboard is still out of reach due to “museum prices”). After all the severe stress and strain of my 2015/01 PSU project “Watts Up“, I am not ready to take on a similar task for my SGI Indigo R3000 just yet – I still need time to cool off (I’m still furious at that darned crimp-tool)! In principle, my last project, “Evie Beer“, equipped me with enough electronics knowledge to better tackle the previously-aborted “Fraggle Jock“, but I just get the feeling that doing another 68hc11-based hardware task straight away, would be soooo “last year” – something a little topically different is needed.


I have toyed with the idea of mucking about with a Cambridge Z88 microcomputer (micro by 1988 standards that is – “The iPad of the 80s!”), but there are way too many Sir Clive fanbois involved in retrochallenge already, and it’s best not to encourage them! So scratch the Z88. Besides, I just missed the cheap one on eBay complete with add-in 128Kb RAM cartridge and 128Kb EPROM cartridge (£10.50 all-in).

The Norse Godess of Tools:

So let’s go for something utterly different… bear with me, this might take quite some explanation… this time around, I am going to be attempting to write and compile a small C program to run on Whitesmiths’ Co-Idris operating-system – a 1978 clean-room reimplementation of 6th Edition UNIX, that runs on top of PCDOS/BIOS (see, and

Writing a pretty minimal C program that does a tiny bit of I/O doesn’t sound like such a big deal, does it?

Yes, But No, But Yes, But No, But…

However, the only copy of Co-Idris I have is “runtime only” – without the C compiler, libraries, Idris header-files, assembler, linker, etc, etc, etc. Way back then (1985), I just needed a small shell-script playground – small enough to fit on a single 1.44Mb diskette, so I ditched the SDK bits and all the manpages. At the time, I had access to a complete Co-Idris/x86 cross-compiler running on a 68000-based minicomputer, so I didn;t need the native C compiler then, but that was 30 years ago and the minicomputer is long gone.

Without the Idris header-files and Co-Idris link-time libraries, it would traditionally not be possible to write a program that makes any system-calls. And without a C compiler and assembler it would only be possible to write a program in raw binary, except that that wouldn’t be possible either – unless there is some way of decoding and deconstructing the required executable file-format (remember, this is waaaaaaay before ELF, and even before NMAGIC file-format!).

Package Lackage:

Making the task trickier is that being a 6th Ed. UNIX workalike, there are no “modern” tools like bash, Bourne Shell,  disassembler, object-file inspector, find, vi, ex, file, more, basename, cut, paste, join, expr,  make, m4, strings, touch, nm, and so on, and so on. This is about as minimal a UNIX-like system as you could find.

There isn’t even ed – rather the Idris line-editor is called e, and operates merely “similarly”. I’m sure the usage will come back to me… ah, yes: having to memorise line-numbers just to edit a text-file.

The Idris shell is a faithful workalike of the 6th Ed. UNIX shell, which is not a good thing: no if/else, no while, no shell-functions, only 26 variables (limited to single-letter names!), no environment-variables, but at least it has “goto” and logical “&&” and “||”.

Bless the Gods, Co-Idris also has “od”, so hex-dumping files is possible, and it has “dd”, so extracting/replacing hand-computed portions of binary files can be done natively, with effort.

Of course Co-Idris doesn’t have Ethernet or graphics capability. Take your multiple serial-ports and just be grateful, dammit. It is the late 70s, after all.

A Possible Way Round:

I do have a binary distribution of a Whitesmiths C compiler and assembler for PCDOS, which produces PCDOS executables, but fortunately it does so by first producing a “Whitesmiths-format” executable file, and then running it through an external utility that converts it to a .EXE file; so the intermediate file is in the right format for direct execution under Co-Idris, except that it is linked against the PCDOS runtime libraries (ie: contains stubs that use specific x86 INT instructions to call on PCDOS services where needed, instead of stubs that invoke Idris system-calls). Hand-crafting Idris stubs to link against isn’t going to be easy – I will need to determine the Idris system-call method and numbers by inspecting the existing binary Idris program files (eg: a hex-dump and manual disassembly of “cat” etc). I do have a two-page description of the Idris relocatable object file-format in dead-tree form (that relocatable object-format is also the Idris executable format, strange as that may seem), so hand disassembly is at least in principle possible, even though it will be a royal pain in the ass:-)

So after considerable effort at reverse-engineering, I might just be able to customise the (binary) PCDOS C compiler into a cross-compiler targetting Co-Idris. I’ll also have to write my own C function library if I want to do anything beyond system-calls, but for this project, system-calls alone should suffice.

Finally, I am going to have to craft up my own assembly-code (or binary) C runtime-startup object-file (Idris-specific), to pre-open the standard input/output/error file-descriptors, initialise the stack, and convert the top-of-stack parameter data into C-style arguments to main(); all based on what I can glean from the few paper manuals I have left, or perhaps by extracting the right bytes from an existing Co-Idris binary executable (“/bin/cat”, probably)! Not a trivial exercise, by any means.

So, welcome to project “Silver Doofer”; January is going to be… well, interesting? The best feature of this project is that the results will be utterly useless, its’ just a voyage of retro-masochism. For the fun! For the fun!

Evie Beer: Episode 9 – Doh! and Happy Ending

As we saw last time, I had been having trouble getting meaningful measurements of joystick position using the ADC. It only goes to show few many readers this blog has, because the circuit diagram showed exactly what the problem was, quite clearly, yet no-one commented!

And of course all that impedance-limit waffle I spouted last time was just that – waffle. Google to the rescue.

World Record?
Given that the X pot of the very old and battered joystick I had was iffy, I decided to call on eBay to get another PC analogue joystick.

I placed the order at 09:00am on the dot, and got a message from eBay at 09:02am stating that the item had shipped. Jeepers, that’s quick! Even though what it really means is “we’ve handed it off to a delivery agent, so it’s out of our hands now”, that speed is still darned impressive.

Even more amazingly, the joystick turned up at my front door on the Isle of Man the following day – now *that* is a world record, it usually takes 2 days minimum from UK for a courier delivery, with an overnight stop off in Liverpool…

Ground Dog
In a PC analogue-interface joystick, the axis potentiometers are wired as variable-resistors (ie: with one of the outer pins completely unconnected), rather than as a variable-voltage-divider, which would be the more traditional use of a potentiometer. You would have thought I might have noticed that only two of the three lugs were connected when I disassembled the old joystick, but no, I was just too slow on the uptake. Doh!

Thus there is a “missing” ground connection that I must provide myself on the external breakout board. This makes sense, as in the PC analogue joystick interface, the host is (effectively) an RC timer circuit used to trigger a 555 timer, for which a variable-resistor is exactly what is needed. For a hook-up to an ADC, that of course won’t do.

Note that most PC joysticks are wired with 5V power to the *center* pin of the pots, and output signal on an outer pin, which is exactly the reverse of what would be needed to wire it as a voltage-divider by adding a ground wire to the unused pin.

Convert to Voltage-Divider
Digital voltmeter showed the new joystick with a resistance-to-power-line of between zero and 80Kohms, on both axes. Thus to get the widest most-nearly-linear spread of voltages to measure, I added a 40Kohm (80/2) resistor to the breakout board from each axis-pin to ground. There are be a lot of resistors piling up on that little board!

Of course, using a fixed external resistor means the stick response is not going to be linear, you would have to take the joystick apart and wire the unconnected pot pins directly to ground to get a truly linear response (assuming linear pots of course). But with a *half-range* fixed resistor, its’ as close as we’re going to get without opening up the joystick.

So does the measurement-circuit/ADC work now?
It sure does! Let’s end with the usual gratuitous video to demonstrate how well it works.

Retrochallenge Project Conclusions
This “muck about with a 6811 SBC” project turned out to be both fun, illuminating and very frustrating – I learned quite a bit about electronics, after some stupid mistakes. But there are some important conclusions about working in such a constrained minimal environment:

Debugging with LEDs
…is way useful, I’ll be sure to add at least a couple of LEDs to my next electronic hardware.
Learning an Assembly-Code
…is not really much easier for having learned a different one a long time ago: each has its’ own idiosyncracies and cute op-code wierdnesses.
68hc11 Good
It is easy to see why the 68hc11 was so popular in its’ day, it is a very cleverly thought-out MCU. The shed-load of on-chip devices (SCI, SPI, 8-channel ADC, 8-bit parallel-I/O, 8 timer-I/Os, on-chip RAM, EEPROM, ROM and monitor, etc, etc), the fact that it can program its’ own EEPROM (even external EEPROM) without needed strange supply voltages, it all adds up. The other beauty is the on-chip ROM monitor (in bootstrap mode) – this means that you don’t need any special “Development Environment” package or kit: just an assembler, a C or BASIC compiler if you really have to, and a dumb-terminal emulator that can blindly “cat” a file via the serial-port. My development environment was Solaris “tip” on an old Sun workstation, together with the public-domain command-line 68hc11 assembler: pretty minimal, but no less effective for that. I suppose the most telling facet is that the official Motorola “universal” evaluation board contains *only* a 68hc11 MCU and a combined RTC/low-voltage-reset chip and a dozen or so resistors and capacitors: quite literally, nothing else is needed built-in, for smallish systems.

68hc11 Bad
As a small self-contained 8-bit MCU, there are of course some compromises: the lack of stack-indexed addressing can take some getting used-to, as can the lack of computed-offset indexed addressing and the very limited 16-bit arithmetic instructions. For larger programs, there is the I/O compromise: if your program is large enough to require external RAM or ROM then you lose two of the I/O ports. Finally, the fact that most 68hc11 chips are packaged PLCC-52, PLCC-68 or PLCC-84 rather than DIP makes amateur hand-construction of SBC boards somewhat harder.
Squeezing It In
I was surprised how much program functionality you can squeeze into 364 bytes of RAM and 512 bytes of EEPROM. Honestly, I just wasn’t expecting it.
Although the EVBU SBC is a great board for learning embedded system interfacing, my basic electronics knowledge was the limiting factor – but I’ve learned quite a bit doing the project, and will be in much better shape next time around.

I originally expected to use this SBC for the month of retrochallenge, than pass it on to someone else. But no, I have instead added the EVBU and documentaion to my “permanent collection” – there’s plenty more mucking about that can still be accomplished!

And finally, the most promising thing to come out of it all is that I have convinced myself that it *is* possible, in the far future, for a klutz like me to successfully build a “StickyMouse“…

Evie Beer: Episode 8 – RTFM!

This time, we’re looking at the built-in analogue-to-digital convertor on the 68hc11. In principle, this should be quite easy, but in practice there turned out to be some caveats.

First problem was that I had assumed that the breakout connector on the evaluation board SBC had port E wired in the same sequence as ports B and C, so it might not be all that surprising that I was only able to get stable results from one ADC channel – the other was always a bit arbitrary… because I had connected one jumper to the wrong pin. I spent a couple of days testing with the ADC inputs shorted to ground, to +5V supply, swapped over; checked and rechecked the wiring and soldering on the breakout board; tested with a single-channel program and a multi-channel sampling program. It all seemed very mysterious and inexplicable!

Eventually, having exhausted all other possibilities, I was skipping through the EVBU manual just looking for *something*, *anything*, when I noticed that the CPU port E pins are not pinned-out on the connector in the same sequence as the other ports. Darn!!!

Rule two of electronic tinkering: RTFM!

Iffy Levels
Mind you, even when connected to the right pins, I was still unable to get meaningful ADC results for the X- and Y-axes of the external joystick. When the ADC inputs were connected directly to +5V or GND, I got solid repeatable 0xFF or 0x00 (sometime 0x01) results, on both channels and on each independantly.
How about measuring an intermediate voltage? A 1.5V battery might be interesting…
Even without a current-limiting resistor (EEK!), that actually works fine: a solid reliable 0x51 value. OK, so the ADC response is not perfectly linear with my circuit, but it’s darned close.

So why wasn’t the joystick output giving meaningful values? After all, it’s just a simple varistor between +5V and GND, should be no problem at all… was there something wrong with the very old joystick?

Desperation Will Tear Us Apart
Have you ever noticed that the amount of gratuitous hardware disassembly is directly proportional to the amount of project desperation? Thus:

Although the small internal straight-through junction-board inside this joystick was mislabelled (Fr and Fr2 were not the button lines, “X” was not the X-axis output, and so on), the wiring inside was correct and sound – no solder breaks, the wires from the plug pins go where they really should do.

A digital meter showed that the Y-pot was fine: in centre-adjusted trim setting, resistance varies between 140K and 0, with a centre at roughly 65K – it’s one of those 150Kohm slightly-more-recent joysticks, not the original 100Kohm IBM one.

However, the X-pot was a bit of a mess: resistance varies between 110K and 174K with a centre at 164K. Holy Cow!!

As you may have noticed, this joystick has “trimmers” on it – to adjust the true centre-position. Analogue joysticks were notorious for requiring calibration, often painfully done in host software in the early days – in the latter half of the 80s, joysticks with trimming-sliders became more common, to handle calibration on the hardware side without needing the host software (every game, etc) to have its’ own calibration routines.

Careful inspection shows that the X trimmer on the joystick was centred, and had not “slipped” inside the case. In the process of testing response to the trim setting, I twisted the pot a bit too far and managed to break the spot of factory-melted plastic that held the pot body in a fixed rotational position on the trimmer-slider.
However, this allowed me to play even further with the trim setting, which comes into play later on.

Impy Dance
Somewhat naively, I had assumed I could read voltages directly off the joystick outputs:
It turns out that the maximum source impedance for the 68hc11 ADC is (quote) 10Kohms, not the 100K or more that an analogue PC joystick uses. I could get correct and repeatable 0xFF,0xFF reading of X and Y when the stick was at top-right, but it would never read less than 0xFD,0xFD nomatter how the stick was positioned. Needless to say a swing count of 3 (at best, with a following wind) is a pretty poor resolution, compared to the 256-count swing I was hoping for.

A False Hope
I toyed with the idea of a fixed series 10K resistor input to the ADC, with the joystick varistor in parallel to ground (in turn with a series 1K current-limitor) – some of the current would go each way, right? Ah, but I’m measuring voltage, not current, so even that ain’t gonna work:
At this point it becomes clear that I am going to need an *active* external component: either a unity-gain op-amp impedance-reduction circuit (with caps and resistors et al et al), or revert to the PC-style 555-based capacitor-charge polled-timing circuit – which would be *way* more complex on the software-side.

And that’s after fixing the iffy X-axis potentiometer in the joystick.

A bit of extreme over-rotation of the X-axis pot body, as hinted at above, in an attempt to reduce the total resistance-swing, showed that wouldn’t do either: once past the factory default spotted position, the thing goes massively non-linear. From a centre-position 10K, minimum is 0K (good!) but maximum-displacement resistance is still 160K (bad, way to high!). Either this pot is compleletly stuffed, or an active external circuit would be needed.

Looks like this project may have reached its’ natural end, due mainly due to my lack of electronics experience and knowledge.

But with two days to go, the fat lady hasn’t sung the Wonder Woman theme-tune just yet. I am going to rummage in my box of old scavenged circuit-boards to see if there are a couple of low-range-resistance potentiometers in there somewhere…

And of course, there’s always the project summary to write.

Evie Beer: Episode 7 – It’s A Stick-Up

The Other End
Now that RetroChallenge is in the closing week, it is time to take a look at the *other* end of my breakout-board:
That thar be a retro “Gameport” socket. I guess that gives a good indication of the next piece of hardware that I am attempting to interface to the 68hc11 SBC…
Yes, I’m afraid so – an old-style 1980s PC analogue joystick.

Button Down
First job was the “fire” buttons. On this kind of joystick, the buttons are wired as simple “direct-short-to-ground” SPST. So there need to be external pull-up resistors on the breakout board for the buttons.button_schematicI had originally used 10M pull-ups, thinking that would minimise the “idle” current-flow, but that turned out to be a bad idea.

Initially, when reading the PORTC pins on the 68hc11, I was getting alternative correct values then zero, tick-tock tick-tock. Even with a 1-second delay between each read. What on Earth was going on? After spending quite a while double- and triple-checking the wiring on the breakout board (it was correct, if messy, and no unintentional breaks or shorts), and wading through the copious Motorola 68hc11 technical manuals, there still didn’t seem to be any logical explanation.

Eventually, on a hunch, I figured that there was interference between the pin-buffers on PORTC, and the only plausible explanation was that those pull-up resistors were too high-impedance (too weak a pull-up effect). Although I wasn’t sure, I eventually bit the bullet and replaced the 10M pull-ups with 10K ones: a quick calculation indicated that the idle voltage would still be high enough to read as a valid high level on the MCU pins…

Desoldering partially-obscured resistors and patch-wires is one heck of a job to tackle with a cheap hand-iron, it took *ages* and plenty of sweat, but eventually I got there at the cost of an even more messy-looking breakout-board.

With the stronger pull-ups, the buttons now read reliably! The minimal program to read the button-states, and then display the results on the LEDs is:


        ORG     HIRAM
; X points to control-register block
sysinit: ldx    #CSREGS

; to avoid floating CMOS-input (near-short to ground),
; configure PORTC for *output*, except those pins that
; we have pull-ups on: C4-C7 for buttons 1-4
        ldaa    #$0f
        staa    DDRC,X

; continuously read buttons and display
main:   ldaa    PORTC,X ; read raw button state
        lsra            ; shift high-nibble to low-nibble
        eora    #$ff    ; invert bits to get 1=on 0=off
        staa    PORTB,X ; show button-state on the LEDs

        bra     main    ; repeat until bored

Those “include” statements pull in static definitions for the EVBU, the MC68HC11E-series MCUs, the BUFFALO monitor (which isn’t used by this program) and my EEPROM-resident library routines (which also aren’t needed here). Let’s see whether it works… check the Button Show video. To please those readers disappointed by the previous video, this one does feature 1970s Wonder Woman in the background audio.

Note that this particular joystick has a hardware “auto-repeat-mode” switch, and both one-shot and auto-repeat operation show nice and clearly.

Of course, the buttons are not debounced in any way, so there may be more programming work to do, but due to the slow semi-synchronous final application I have in mind for this circuit, I believe that debouncing may be completely unnecessary! I know, that seems crazy, but… we will see how that works out in a later episode.

Fingers Crossed!

Evie Beer: Episode 6 – An Illuminating Debugging Method

Now that loading into on-chip EEPROM is working, I have written a few standalone utility routines so that the final program will not need to
rely on the BUFFALO monitor (which isn’t available in some operating modes).

Simple things, such as output via the serial-port, analogue-to-digital sampling, digital input port reading and so on. This allows me to test and debug other parts of the program in the (measly) 326 bytes of available RAM, without having to download the utility routines: once debugged, I load them into EEPROM where they remain even across power-cycles.

However, this assembly-code lark is not as easy as it could be – I am making very few mistakes, but when you make one it can take ages to track it down – no GUI debuggers here, and I still haven’t quite adjusted to this level of programming. Getting there, but still occasionally dropping into inappropriate “high-level programming” habits.

The BUFFALO monitor has some debugging facilities: line-by-line assembler/disassembler, single-step, trace-until-address, register-dump to terminal, line-by-line interactive memory-modify, interactive register-tweaking, and even a breakpoint facility. Given that the on-chip BUFFALO ROM also includes the downloader, terminal routines, 4 different host-port device-drivers (SCI, SPI, ACIA, DUART), command-parser, EEPROM programming routines, S-record decoder, et al, it really is a remarkably compact program.

Whilst writing a standalone function to convert binary register contents into ASCII hexadecimal, I needed to be able to inspect the ALU condition-codes at specific points, which would have been somewhat cumbersome. Fortunately, the LEDs on the breakout board I built earlier can be used for exactly this, even though I had originally intended them just for playing about with, for fun. It only takes a couple of instructions to dump a nibble to the 4 LEDs, so I could use a technique a little like the old “insert a few printf() calls” method (which I cannot use here as there is no printf() in this deliberately minimal environment), but instead of printing trace messages to the terminal, we display bit-patterns on the LEDs. Of course, it also required inserting the occasional delays, otherwise the patterns would flash by too quickly to be seen: but that was easy too thanks to the programmable-delay routine I wrote earlier (which now lives permanently in EEPROM)… this “illuminating” debugging technique is quite useful, and has the advantage of a certain amount of prettiness, it’s almost hypnotic. Reminds me of watching the changing front-panel lights on an old huge PDP-11 I timeshared in the early 80s…

A 68hc11 Idiosyncracy
trying to squeeze 68hc11 program-code to the smallest size possible, so that it will fit into the small on-chip memory, led to an interesting discovery: indexed addressing using the Y index-register makes instructions 1 byte bigger than when using the X index-register.

One of the “selling points” of the 68hc11 was that it had *two* index-registers (block-pointer registers) instead of the single one available on the older 6800 and 6805 processors. Experience had shown Motorola that a single index-register on the older parts had been quite limiting and inconvenient to application programmers…

On the 68hc11, Y-register indexing is signalled by a constant instruction-prefix byte, which can be very wasteful of memory-space in a highly-constrained environment. Thus I have discovered the 68hc11 “rule-of-thumb”: use Y-register for indexed addressing only sparingly, try to get all the frequently-accessed data either in zero-page RAM (8-bit absolute address) or within range of an 8-bit offset from the X register (8-bit offset address).

Of course, I had initially used Y-indexed addressing everywhere, so was running out of RAM… now fixed to do it the “other way around”, amazing how much smaller everything has become!

Evie Beer: Episode 5 – EEPROM Tribulations

The last week of fiddling with the 68hc11 EVBU SBC has been a bit of a slog, with not much productive output…

Bicycle Count
The first task was to write a reliable parameterised “delay” routine, so I could ditch the awful mechanical workaround (wedge a keyboard key down!) I had previously used for the LED-flasher program.

This took a bit of trial-and-error, but made it in the end: a routine that sleeps for the number of milliseconds passed in the 16-bit X index register. The timing is based on a cycle-counted loop rather than the on-chip hardware-timers, but it is accurate, reliable, and scales from 1ms to over a minute. It was quite fun to play with programmable delays for the LED-flasher program, you can get some funky visual effects that way.

The 68hc11 has a *very* nice feature – on-board EEPROM, which can be used for program storage, static data, dynamic data or all three. On the 68hc11E1, there is 512 bytes of EEPROM, plenty for what I have in mind, given that 68hc11 object-code can be very “dense” if you avoid floating-point or excessively 16-/32-bit operations.

The 68hc11 was the first commercial CPU/MCU to contain on-chip EEPROM, and Motorola implemented it very well. Unlike Flash memory, EEPROM can be erased/written a byte at a time, but requires quite a bit more than 5V to do so. Many early EEPROM-containing CPUs required the chip to have auxiliary 9V (or 12V or even 20V) power-supply lines to provide the voltage needed to erase/write/rewrite EPPROM cells.

Motorola avoided the need for wacky power voltages by implementing on-chip charge-pumps, so the 68hc11 chip can directly program both internal and even external parallel EEPROM, using the chips’ normal 5V power input line. Neat!

The slight drawback is that there is a specific sequence of events needed to program an EEPROM cell, particularly a 10ms delay needed for the charge-pumps to charge on each erase/write operation. Fortunately, Motorola had the sense to make the EEPROM erase/write operations controllable directly under program control, so you can write a 68hc11 subroutine to perform EEPROM-modification operations – no special auxiliary hardware needed, it’s all internal.

So, armed with a mini-application that runs from on-chip RAM, the next step for me was to get the program into EEPROM, so that I don’t have to keep downloading it to the chip, which can become very tiresome after a while…

The on-chip BUFFALO ROM monitor can in principle directly load a download into EEPROM, but the BUFFALO implementation is quite slow, and as the 68hc11 built-in serial (5V RS-232) interface has *no* flow-control, when downloading at the default slow speed of 1200 baud, the BUFFALO S-record-conversion-and-EEPROM-rewrite routine stalls hard, requiring a reset.

For very small programs, such as the LED-flasher from the last episode, I was able to use the BUFFALO “modify memory” command to program the EEPROM bytes one at a time by typing each MM command “by hand” at the terminal. This worked OK, but there is no way such a method is going to be feasible for anything but utterly trivial programs.

A common alternative is to download a (custom) EEPROM-programming program into RAM, and execute it there. Such a program can be written in such a way as to read address/data values from eg: the serial-port, and to then program the requested bytes from that data.
Of course, you are still faced with the “no-flow-control” and potential serial-overrun problem, and would also have to code-up your own “protocol”, such as an S-record decoder, for the download format. Although there are examples of such 68hc11 programs around on the ‘net, none of the ones I could find could deal with the flow-control issue without requiring custom or special host-resident software or full UART external hardware; plain-old terminal-emulator host software talking to an EVBU just isn’t going to cut it for EEPROM programming. It’s fine for RAM programming using BUFFALO, as that is very fast, way fast enough to keep up with download speed.

Time to look for other alternatives…

The EVBU comes with Motorola-written DOS software that provides a character-mode GUI (!) for talking to the 68hc11, including download-to-EEPROM commands. These download a special program to RAM, that then uses a mysterious (undocumented) protocol to sequence the download of EEPROM data. Let’s give it a bash!

First problem: PCBUG11 is only provided on 800k Mac Classic floppies or 5.25-inch DOS floppies – and I do not have such ancient drives. Fortunately, it can also be found on third-party sites on the ‘net, so one quick download later and I was ready to rock.

I had planned to use an old 1998 Toshiba laptop to run PCBUG11, but it has no Ethernet interface. No problem, let’s use 3.5-inch sneakernet to get the software over… ouch, the diskette drive on my SPARCstation is dead. Plan B: I have a USB 3.5-inch diskette drive, so could copy over from the modern home PC. OK!

Unfortunately, the ancient PCBUG11 software was written using 8086 blind timing-loops for synchronising communication with the EVBU, and therefore fails utterly on any PC running at more than 80MHz.
I suppose that in 1985, the idea of a PC running at more than 16MHz seemed pretty remote, and speeds above 200MHz was surely several decades away (ha!); I’m still upset with Motorola about this daft way PCBUG11 was written.

On the ‘net, from a 1998 Motorola listserv, there is a binary patch for the PCBUG11 executable that relieves the issue, and allows PCBUG11 to work on 166MHz PCs, but it was still no-go on my 233MHz Pentium-II.

As Dick Dastardly would say: “Drat! And double-drat!”

Back to The Job
OK, we’ll defer the bulk-load-to-EEPROM for now, and get back to a bit of assembly-language programming again.

Although the 68hc11 is quite a capable 8-bit CPU, the lack of stack-indexed addressing is a royal pain: the only explicit stack-relative memory-operations available are PUSH/PULL of an 8-bit acculumulator or 16-bit index-register. For someone like me, coming from a C background, it required quite a head-switch to get used to passing function-parameters in registers or even fixed memory, rather than “just push it all on the stack and access it from there”. The very few registers available (A, B, X, Y), and the “syntax style” of the 68hc11 standard assembly language made it all the more confusing at first.

Obvious examples are that “inc b” and “incb” are not the same operation at all: the first increments an 8-bit memory-location, the other (implicitly) increments the B register, and I frequently got it the wrong way around. I’m just not used to that kind of thing: in SPARC-land, general registers are *always* explicit, and direct memory operands typically use explicit register-indirect index-notation. I should not have been troubled by this head-switch, because I used to program in Z80, 7809, 68000, NS32016, and a few other assembly languages, all with their own idiosyncratic ways of looking at things: but that was all over 25 years ago, and I have just become unacclimatised!

Lesson: having programmed in a couple of 8-bit assembly-languages a few decades ago does not mean you’ll pick up a new one at all quickly.

The other “Doh!” moment I kept having when using the BUFFALO “load” command, was downloading the assembly-code file instead of the assembled object-code, which of course sends BUFFALO into fits, requiring a reset. The tell-tale sign is when the terminal emulator reports “123 lines downloaded” for what should be a tiny program (compiled to 7 object-code S-records)… “Darn! I didn’t mean to do that… again!”

More Progress At Last
Back in RAM-land, the next task was to write a program to demonstrate (1) ability to report binary byte-values in ASCII hex to the terminal, and (2) a sounder grasp of conditional logic in assembly: a program to output a formatted, line-wrapped, block of all 8-bit binary values in ASCII hex.

NOLF    EQU     1       * if host is tip or minicom, then
                        * we don't need line-feeds
putc    EQU     $ffb8
getc    EQU     $ffcd

CR      EQU     $0D
LF      EQU     $0A

        ORG     $0100
init    ldab    #$0
        bra     body
loop    pshb
        anda    #$FF
        beq     nextblk
        anda    #$0F
        beq     nextlin
body    pshb
        anda    #$07
        bne     report
        ldy     #3
loopy   ldaa    #' '
        jsr     putc
        bne     loopy
        ldx     #500
        jsr     delayms
report  pshb
        jsr     puthex
        ldaa    #' '
        jsr     putc
        jmp     loop
nextlin jsr     newline
        bra     body
nextblk jsr     newline
        ldx     #750
        jsr     delayms
        jsr     newline
        bra     body
newline ldaa    #CR
        jsr     putc
        ldaa    #NOLF
        bne     skiplf
        ldaa    #LF
        jsr     putc
skiplf  ldx     #333
        jsr     delayms
* print register A value to terminal as 2 hex-digits
* NOTE: the BUFFALO nibble-hexification routines
* trash the A register!!!
puthex  psha
        jsr     $ffb2
        jsr     $ffb5

This went quite quickly, although it still leans on BUFFALO subroutines more than I would ideally like, rather than being more self-contained. However, the conditional bits are good, as can be seen in the video (the background sound is “Special Ops Force” on TV, but count yourselves lucky – earlier on today it was 1977-vintage “Wonder Woman“…)

Stop Press!
Breakthrough: we have reliable download to EEPROM, even using dumb terminal emulator (Solaris “tip”)!

The trick is to use a BUFFALO “modify memory” command to update one of the 68hc11 memory-mapped control-registers to set the on-chip SCI baud-rate to just 300 baud. It means having to connect at the default baud-rate (1200), then switch, disconnect then reconnect at 300 baud, before downloading, but that’s way easier than typing the object-code bytes in by hand one at a time:

sol% tip evbu

>MM 102B

102B 30 35@^%^[
sol% tip evbu -300

>load t
^[>Local file name? eel.s19
4 lines transferred in 0 seconds 


As shown, this slow speed gives the BUFFALO “load” command has enough inter-byte time to program each EEPROM location. The LED-flasher is now running directly from EEPROM without having to type in the object-code a byte-at-a-time.