FromOrbit.com

Alan's Wishlist

Fri, 25 Apr 2025 00:00:00 +1000

Wish List

45W IRF510 HF Linear Amp

Mon, 23 May 2022 00:00:00 +1000

45W IRF510 HF Linear Amp

Boy it’s been a long time between posts. Sorry about that. I got real lazy and just starting pumping my content into twitter and really just never took the time to document things.

Anyway, here is a project I built to get me out of QRP land and being heard my frequently on the 20M and 40M bands.

“CQ CQ CQ”

Finally getting around to sitting for my HAM license I started off with my first HF radio, the very useful uBitX v6. It’s a great radio to start with for a tinker like me. It’s open sourced schematic and firmware allows fiddling and updating and there is always a wealth of ideas and projects on the internet for it.

With it’s mighty 5W output and using my home-brew EFHW antenna I would make countless “CQ” calls hoping someone would hear me. I went on for weeks if not months tweaking this, and tuning that but nobody seemed to ever hear me. So I set about creating my first linear amplifier. Inspired by a design in “Experimental Methods in RF Design” EMRFD I set about building myself a linear amplifier to get above the noise.

“Oh the things you learn”

So, I at first figured I’d bash together a prototype on some copper clad and see how it would go…

I got some output! 4dBm (2.5mW) input netted me 31dBm (1.2W) output from 12V!

Suffice to say I was stoked…. then it started oscillating.

Speaking with my Elmer he suggested my crappy hacked together layout wasn’t conducive to a high power amplifier with fairly high gain, and that perhaps I should do a cleaner layout. So I cracked out my CNC mill and Kicad and made a prototype.

“There ain’t no thang like a CNC”

Layout done, board turned out nice. Time to build it.

Using a large chunk of heat-sink I cut down from an old stage lighting dimmer, I mounted the MOSFETs with insulators onto the heat-sink. The PCB was then mounted on top and the board mounted on stand-offs.

It was about this time I realised I screwed up the schematic and had the gate and drain on one MOSFET arse about. Dutifully I hacked in a modification and continued.

All the components and coils were wound, and the moment of truth

Power up time!

Powered it up, connected it to my uBitX and whistled into the mic and received 46dBm (39.8W) of output from 24dBm (250mW) of input! I was very very pleased. No oscillations, nice clear output and all looked very good and pleasing.

Now let’s make a proper version this time

A new layout was made, a new board was milled on the CNC and the components transferred across to the new board

Worked perfectly. Pushing the input power up to 30V @ 3A the amp will easily get to 50W into 50 ohms, but I limit the supply to 28V and that seems to keep it around 45W output.

Time for an TX/RX switcher

I needed a way to interface the linear with the uBitX. I pulled 12V from the TX/RX relay inside the uBitX and brought it outside to control a relay block I made for the linear. I really should just create a TX sensor on the input of the linear and have it handle the switching itself (future project) but for now this works.

Put it in a box!

An old ATX PSU steel case was used to house the amplifier. It was handy because it had a 80mm fan already in the box and it was steel, so provided good shielding. Not much to look at though.

So, how’s it going?

After using it on air for a while and having finally breaking through the noise I have had many successful QSOs from all over Australia, NZ and the USA.

Suffice to say I’m really very very happy with it.

More fun with the m68k

Fri, 19 May 2017 00:00:00 +1000

The last days of the Retro Challenge

The Retro Challenge behind me, and not actually achieving my goal I was pretty disappointed that work/life commitments stacked against me in getting there. That didn’t stop me from completing my goal, just wasn’t in the time frame of the competition.

Where I left off lasted I had my bootloader working and a basic assembler environment working, but I wanted a high level language to create my Mandelbrot set. I didn’t want to write it in assembler.

The first steps

I got the idea that since I had a linker script, etc setup it wouldn’t be a long stretch to get GCC and libc working. So I set out to do just that.

After a few nights fiddling around and hitting a bug in the version of GCC and libc where the compiler would crash because I was missing a linker directive, but even when fixed the compiler would still bomb. After much research it seemed to be a bug that I really wasn’t in the mood to research and fix, or to update the environment. Also the output I got was really large and inefficient, so I started looking for an alternative.

Enter crosstool-ng

Not looking forward to the prospect of compiling GCC and all the rest manually I started looking for tool-chains I could get that wouldn’t require a lot of fiddly setup, another thing is that a lot of m68k is getting long in the tooth and the tool-chains and tools are deteriorating at an alarming rate. After a few nights looking around I stumbled upon (crosstool-ng)[http://crosstool-ng.github.io/].

An unassuming utility that builds tool-chains for various processors and setups, one of which is m68k based systems. During my search for a new tool-chain I also stumbled upon Newlib, a libc alternative that is much lighter than standard libc and has abstracted I/O functions out to basically eight system calls.

After about 20 minutes with crosstool-ng I had a new Newlib based tool-chain ready. Here are the basic steps I took to build the tool-chain:

# Get the latest crosstool-ng
$ git clone https://github.com/crosstool-ng/crosstool-ng
$ cd crosstool-ng
$ ./bootstrap

# Build the crosstool-ng
$ ./configure --prefix=/opt/crosstool-ng
$ make
$ make install
$ export PATH="${PATH}:/opt/crosstool-ng/bin"

# Make a working dir
$ mkdir work-dir
$ cd work-dir

# I used the m68k-unknown-elf "sample" as it had all I needed
$ ct-ng m68k-unknown-elf
$ ct-ng menuconfig
$ ct-ng build

After a little while you’ll end up with a x-tools directory with all the tools you need!

Time to test the compiler

I made a simple project that simply setup the UART and output “Hello world”, the linker was setup to operate purely from RAM so the .data didn’t need to be copied and the .bss was already cleared. I needed to implement the basic functions that Newlib mandates :

int close (int fd);
int fstat (int fd, struct stat *buf);
int getpid();
int isatty (int fd);
int kill (int pid, int sig);
off_t lseek (int fd, off_t offset, int whence);
int open (const char *buf, int flags, int mode);
void print (char *ptr);
void putnum (unsigned int num);
void *sbrk (int nbytes);
int stat (const char *path, struct stat *buf);
int unlink (char * path);
int write (int fd, char *buf, int nbytes);

You don’t need to implement all these functions, initially I just implemented each one I needed as the compiler complained. I found for a simple UART output I only needed four.

It compiled just fine and when I copy and pasted the srec data into my bootload I was happily presented with a “Hello world!”

F%^& YEAH! gcc and Newlib work! This is a `printf()` compiled with GCC output as srecord data and pasted into my bootloader. WORKED! YAY! pic.twitter.com/PpjcL73qq1
— Alan Garfield (@alangarf) May 9, 2017

Suffice to say I was pretty damn happy

Mandelbrot now?

Even though I now was ready to build a Mandelbrot set I was still unhappy with the fact my init code and the required Newlib system calls weren’t implemented that well. Plus I had a bug I noticed where the CPU would crash if I called too many subroutines. This last one was pretty easy to fix but it did require me to clean up my linker script and create something more complete. The issue with the crash was my heap space and stack space was colliding. I was artificially reducing the heap space to make the upload to the board smaller. I was having race conditions in the silly terminal I was using that was causing my bootloader to miss characters etc.

So, rather than make a Mandelbrot I set about to build a “BSP” (Board Support Package) for this board.

An AMX AXC-EM BSP

To start with this seemed like it would be much harder until I found the source for Newlib itself, and the libgloss library. Inside the source for the m68k in libgloss it had implementations of BSPs for other m68k based boards.

Using the details of a few of these boards I was able to piece together what was required to make a BSP for this board. With a little bit of testing and poking around I managed to make a support library that made compiling things for this board almost trivial!

I’ve pushed this BSP to github: (AMX AXC-EM BSP)[https://github.com/alangarf/axc-em-bsp]

To use it all you need to do is point the linker of your project to the resulting libamx.a and use the linker script for linking and you project should just work.

I’m slowly adding more details for the peripherals of the MC68340 as I go, but so far it has what is needed for the UART.

Now a Mandelbrot?

You bet. Being lazy I looked around on github.com for a C-based ASCII Mandelbrot routine. The first one I found seemed simple, but turned out to be extremely inefficient. I build and tested it on the board, but initially I thought the board crashed. Just luckily I left it running and after a few minutes a single line of a Mandelbrot had been output.

Leaving it for another 20 minutes only another 5 lines where added. Thinking that the CPU had slipped out of it’s 16MHz clock mode I reconfirmed that the clock was at the right speed. It was just very inefficient code.

Looking for another source of laziness I found asciibrot. It was designed to do animation etc, but really all I wanted was a single rendering of a Mandelbrot. So I tore the routines apart and finally got myself this output:

Yay I finally achieved my @retrochallenge goal. I can render a mandelbrot set written in C on this m68k board! Better late than never. :D pic.twitter.com/wDoZAdDz2H
— Alan Garfield (@alangarf) May 17, 2017

Gosh I was so happy when I finally saw that. Over a month on and off mucking around with this and finally achieved my goal, plus along the way I learned so much more (and relearned a bunch of stuff I’d long forgotten). It was an awesome challenge and also the biggest possible reward of entering the Retro Challenge itself.

Any more examples?

Here is a real-time display of the board rendering a larger Mandelbrot set.

An here is a better example showing the actual CPU speed by character. I removed the line buffering so each character can be seen as it is rendered.

So now I have a really good tool-chain, a working linker script and can basically compile anything I like. I think the next test is to get the on board I/O devices sorted out (eg. the clock/calendar, the DIP switches and the I/O pins I’ve found) and make it do something more fun. A clock? A vector display controller with some ADCs? You’ll have to wait and see.

m68k Environment - Retro Challenge 2017/04

Wed, 26 Apr 2017 00:00:00 +1000

So, for this post I want to talk about my development environment and where I’m up to as far as the Retro Challenge.

I’ve had a lot of issues with this project. Initially I was cruising well and looking well on track to make something really cool, but then I damaged the board.

The board started to exhibit a fault with it’s ability to load bytes from ROM. This became apparent as I started porting the TS2 ROM Monitor. When the fault occurred I started to gradually break the application down to the point of just the minimal initialization stuff for the CPU and UART and printing a string from ROM to the UART.

As I was doing this testing, the CPU would appear to crash or not properly enter into any exception handler (even when forced too by using an illegal instruction!). After many, many days of trial and error and screaming at the board I finally broke it down to the point of it was either a faulty CPU or I’m a complete idiot and can’t write five m68k assembly instructions.

So, I cut my losses and switch to my fall back board that was a little newer and based on a MC68340 CPU. My main hesitation initially for not using this board to begin with was that it was a peripheral integrated CPU, which meant the board was basically ROM, RAM, CPU, and power related parts.

The AMX AXC-EM board.

As it stands I’ve had a much more enjoyable time working with this board and so have progressed much further with the software, rather than staring at a blinking LED and hoping it blinks just right this time (if you follow me on Twitter you’ll know what I mean)..

The Software Environment.

At the moment I’m writing everything in assembler for the m68k. I’m on a Macbook Pro and I run the m68k development environment in a Ubuntu Xenial VM using Vagrant. Rather than trying to setup the cross compiler in OSX, I just opted to use Linux and the Ubuntu m86k deb packages.

So, to edit the code I use a Vagrant share and access the files in OSX using Vim in iTerm, and in another panel I have an open SSH session into the VM to do the compilation.

To get the code onto the EEPROMs I use a TL866a MiniPro programmer, which I’ve compiled the open source command line tool for it in OSX. This means to program the EEPROMs I run the commands in OSX.

Sounds difficult but it’s really not. I have a Makefile which handles all the compiling and ROM images, plus outputting dump files. It also has the recipe for programming the even and odd ROM images to the EEPROMs via the MiniPro tool.

The flow sorta looks like this:

Makes changes to the source code in vim inside one iTerm pane.
Switch to the VM pane that’s SSH’d into the VM. Run the make compile command.
Switch back to the editor pane in iTerm.
Put the even EEPROM in the programmer.
From inside vim run the make commands to program the even EEPROM
Rinse repeat for the odd ROM

Here is the Makefile I’m using, you can see it here on Github too.

M68K=m68k-linux-gnu
AS=$(M68K)-as
LD=$(M68K)-ld
COPY=$(M68K)-objcopy
DUMP=$(M68K)-objdump

ASFLAGS=-m68340 --warn --fatal-warnings
LDFLAGS=-T m68k.ld
DUMPFLAGS=-m68020 -x -D

EEPROM=AT28C256
PREFIX=m68k-

FMT=binary

SRCS=loader.s
OBJS=$(SRCS:.s=.o)
MAIN=loader

.PHONY: dump clean

all:	$(MAIN)

.s.o:
	$(AS) $(ASFLAGS) -o $@ $<

$(MAIN): $(OBJS)
	$(LD) $(LDFLAGS) -o $(MAIN).a $(OBJS)
	$(COPY) -b 0 -i 2 --interleave-width=1 -O $(FMT) $(MAIN).a $(PREFIX)$(MAIN)-even.bin
	$(COPY) -b 1 -i 2 --interleave-width=1 -O $(FMT) $(MAIN).a $(PREFIX)$(MAIN)-odd.bin

clean:
	rm -f *.o $(PREFIX)$(MAIN)-even.bin $(PREFIX)$(MAIN)-odd.bin $(PREFIX)$(MAIN).bin $(MAIN).a

prog_even:
	@echo Programming $(MAIN)-even onto $(EEPROM)
	minipro -p "$(EEPROM)" -w $(PREFIX)$(MAIN)-even.bin -s

prog_odd:
	@echo Programming $(MAIN)-odd onto $(EEPROM)
	minipro -p "$(EEPROM)" -w $(PREFIX)$(MAIN)-odd.bin -s

dump:	$(MAIN)
	$(DUMP) $(DUMPFLAGS) $(MAIN).a

Compilation and Linking

As you can see from the Makefile above I’m using m68k-linux-gnu-as to assemble the object files from the source files. I am then using m68k-linux-gnu-ld to link the object file(s) into the .a archive object file. Which is then split into the even and odd ROM binary images needed for the two 8 bit EEPROMS to make the 16bit wide program data.

I have a small linker script to handle the vector mapping, the stack and RAM locations etc. This step makes moving the resources around very easy, which I’m now thankful for because the two boards I have are vastly different in memory map to each other.

MEMORY
{
    ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x10000
    RAM (xrw) : ORIGIN = 0x00040000, LENGTH = 0x10000
}

/* stack location */
stack_size = 1024;

_stack_start = ORIGIN(RAM)+LENGTH(RAM)-0x10;
_stack_end = _stack_start - stack_size;

/* ram location */
_ram_start = ORIGIN(RAM);
_ram_end = ORIGIN(RAM)+LENGTH(RAM);

/* system integration module */
_sim40 = 0x80000;
_timers = _sim40 + 0x600;
_uarts = _sim40 + 0x700;
_dma = _sim40 + 0x780;

SECTIONS {
  .vectors 0x00 :
  {
    . = ALIGN(4);
    KEEP(*(.vectors))
    . = ALIGN(4);
  } > ROM

  .text 0x400 : {
    . = ALIGN(4);
    *(.text)
    . = ALIGN(4);
  } > ROM

  .data : { *(.data) } > RAM
  .bss :  { *(.bss)  *(COMMON) } > RAM
}

OUTPUT_ARCH(m68k)

I’ve been trying to get an .rodata section working, but for whatever reason my sections end up with the wrong alignment and any strings I put there are in the ROM image, but don’t appear to work. Maybe when I get some times I’ll figure out why that is, for now I’m happy to just put the strings at the end of the .text section.

Initializing the MC68340 CPU

The MC68430 is a great CPU, it has a lovely set of peripherals, and some very nice features. However getting it going can be a little trick as both the RAM and ROM positions are controlled completely by the System Integration Module. The “SIM40” is a peripheral module in the MC68340 that basically handles all the address decoding and glue logic the other board had in 74 series ICs. This allows cool things like loading the START and SP registers from the ROM, and then moving the ROM up high in the memory map and replacing where the ROM would be with RAM. All with just a few instructions. Done in hardware you’d need complex gating or a GAL to achieve something similar.

So to start with here is a chunk of code that configures the ROM and RAM locations in the memory map, and configures the CPU speed and interrupt maps.

*************************************************************************
*
*  Init the CPU and System Integration Module - Configs module options
*
.init:
            move.w      #0x2700, %sr                    | mask interrupts and set supervisor mode

            moveq       #7, %d0
            movec       %d0, %dfc
            move.l      #_sim40 + 1, %d0
            moves.l     %d0, 0x3ff00                    | move sim40 base address to 0x80000

            /* setup ROM chip select CS0 */
            move.l      #0x03fffd, _sm_csam0 + _sim40   | 16 bit port, three wait, mask FC bits, 256KB in size
            move.l      #0x000001, _sm_csbar0 + _sim40  | starting at 0x00000

            /* setup RAM chip select CS1 */
            move.l      #0x03fff1, _sm_csam1 + _sim40   | 16 bit port, zero wait, mask FC bits, 256KB in size
            move.l      #0x040001, _sm_csbar1 + _sim40  | starting at 0x40000

            /* setup system protects and clock */
            move.b      #0x06, _sm_sypcr + _sim40       | turn off watchdogs, bus fault, bus monitor
            move.w      #0x7c00, _sm_syncr + _sim40     | set clock to 15.991 MHz
            move.w      #0x420f, _sm_mcr + _sim40       | set MCR, no interrupts etc

In this project I’ve just kept the memory map really simple.

0x000000 is ROM
0x040000 is RAM
0x080000 is the SIM40 peripherals

I may switch the RAM and ROM around later as this would allow me to dynamically change the interrupt and trap vectors. Otherwise I have to hard code jumps to RAM locations inside the ROM where the vectors are in order to make them dynamic. At the moment I’m not really using interrupts, but I can see myself wanting too in the near future (also breakpoints etc in my ROM Monitor).

Initializing the MC68340

The MC68340 has a great suite of peripherals, from UARTs, Timers, System protection devices and DMA.

The SIM40 modules can move the addresses of these devices where ever you choose, but the layout is:

As you can see in the code above I’ve set it to the address of 0x080000. For this project at the moment I’m turning more stuff off than I’m turning on. By default all these peripherals are available and running, you have to disable them if you’re not using them. Realistically this is more about power reduction than anything, but like unused logic gates, I feel they must be put into a known state. :)

So I turn off all watchdogs, and system protection peripherals (eg. double bus fault monitors, bus monitors, reset etc), the timers, and the DMA. Since I need a UART I configure one and disable the other.

The boot-loader

Initially I was just going to port across an existing ROM monitor for the m68k, there are plenty of quality ones out there but given the time I lost on the faulty CPU/board I quickly realized I won’t be able to port the monitor quickly enough if I had to burn EEPROMs each time to make any actual application with the board. I set out to make an Mandelbrot set with this board, so debugging a monitor wasn’t something I had time to do.

So speaking to my friend @trc_wm he suggested getting just something dumb that dumps binary into RAM and jumps to it, then write some python to push the binary at the serial port.

I started implementing that until I saw a few pieces of code that would load srec format into RAM. I decoded the logic and wrote my own implementation in a few hours, I figured this would be all round simpler in the long run as I wouldn’t need to write the python. Instead I could just cut and paste the srec records straight into the terminal, or at the very least cat them out to the serial port.

Here is an example showing altering the code, compiling, copying the srecord data and running it:

Demo showing updating code and pushing it to the bootloader

Enough for today

That ought to do me for today. To achieve my goal of generating a Mandelbrot set with the board for the Retro Challenge, I’m going to work on either getting compiling C to run on the m68k, or port a BASIC/FORTH tomorrow and then write a Mandelbrot set generator in the chosen language.

We’ll see…

Rinse Repeat. :( - Retro Challenge 2017/04

Tue, 18 Apr 2017 00:00:00 +1000

Apart from work and family commitments over Easter I’ve been stuck in a rinse repeat cycle with this board.

I am still trying to iron the bugs out, and I’m having weird issues with the firmware. I started thinking about porting the TS2 “monitor” to this board, but was having weird issues trying to get the UART to output a string from ROM.

I’m doing something wrong …

I then set up a new project just to do a simple test of blinking the LED in a sequence stored in ROM. It was about this time I started to suspect there was something wrong with the CPU or the board. Reading a byte from RAM with post decrement addressing would work, but trying to do the same in ROM would crash the CPU. After much stuffing around I finally put out a cry on Twitter and @brouhaha mentioned that the CPU could be double faulting and asserting it’s HALT line. I hadn’t realized this CPU had bidirectional RESET and HALT lines!

Looking at the schematic I made, I did wonder why the RESET and HALT lines had resistors in them. It now makes sense given they can drive the lines as well as take input. So anyway, I stuck my multimeter into the HALT pin when a crash happened and yes the CPU was double faulting.

The 7 Stages of Grief …

At this point I doubted everything I spent a week or more trying to solve why this was happening. I questioned my understanding of m68k assembler, and kept breaking my testing program down till all I had was basically three instructions and the problem still existed. I questioned the assembler. I questioned the linker. I whinged on Twitter, I complained constantly to @trc_vm via Slack. I then questioned the new EEPROMs I had bought.

Which this last one may or may not be a real issue, but the previous EPROMs were 90nS speed rated, and the RAM is 100nS speed rated. These new AT28C256 EEPROMs are a fair bit slower at 150nS, so I desoldered the 12MHz crystal and under-clocked the CPU to 8MHz to see if that made any difference. In the end it did, in some small way in that at least now it would appear to fall into the exception handlers and not just double bus fault all the time. But I still had my problem with byte loading values from ROM.

I then started to question “can the m68k actually address bytes, I’m sure it can” so I scoured all possible resources to confirm it. Then I altered my program to use words instead of bytes and the damn thing started working!

Time to crack out the logic analyzer.

So now I’m to the point I’m questioning the board or the CPU. So I drag out the logic analyzer and since I can’t find more than 5 chip clip leads I’m forced to stuff around to get what I want. I set up my simple small test program to blink the LED in a sequence stored in the ROM. First blink the LED twice, pause, then blink the LED three times, pause, etc etc. Eventually up to 8 blinks.

Run this, I get my two blinks then a locked up LED. I wanted to see what the ROMs were doing on the 8 bit address read. So I clipped up the RAM/ROM chip select lines, the even and odd enable lines and the LED output.

What the logic analyser saw…

You can easily see the ROM is doing an 8bit read on even, then an 8bit read on odd.

Damn it, this looks OK … :(

Suffice to say, I’m at a loss. I re-installed the original factory firmware to finally see if I wasn’t going bananas. It too failed and entered a double bus fault. So if the original firmware now fails I’ve somehow damaged the CPU or the board.

I’ve found on eBay a few replacement CPU’s for every little money, but they won’t be here in time for the end of the Retro Challenge. But it does mean I will get this board going again. I’ve learnt so much playing with it, and my understanding of GNU binutils etc is so much richer because of it. So perhaps I can’t get anything going this year for the challenge…

… or can I?

When I rescued this board from the dumpster I also recovered a few others with it. I picked this board for the Retro Challenge because it seemed the most approachable; generic MC68HC000; external UARTs and I/O. But it wasn’t the only board I recovered with a m68k processor on it.

Enter the AMX AXC-EM with an MC68340RP16 on board!

Why didn’t you use this one first?

To be honest I wasn’t sure what I wanted, and I was familiar with the MC68HC000. I also thought having the UARTs and I/O all on chip was cheating. This board is basically the same thing functionally-wise to the other. It’s just newer and with an ‘020 based CPU. Basically all the same hardware is on board. Two UARTs, an LED, 8 DIP switches, battery backup RAM, clock/calendar, etc etc. It’s still from 1992 so it fits the Challenge. :)

So yeah, now I start again basically. I have to figure out the memory map, the device layout and the differences with an ‘020 versus a vanilla 68000. Dear god I hope it can read bytes from ROM!

Now we're get'n somewhere! - Retro Challenge 2017/04

Sat, 08 Apr 2017 00:00:00 +1000

After the UV fiasco I’ve finally managed to get around the issue. I did that by ditching EPROMs and instead replaced them with EEPROMs!

Rummaging around in the shed I found two other cards from the system this controller was in originally. They were for controlling infrared devices and what not and used a M68HC11 CPU. They had 27C64 EPROMs and 28C64s EEPROM each.

My guess is that rather than adding battery backed up RAM on these smaller cards, AMX opted just to use the 28C64 as SRAM since the write performance etc of them are pretty good. These smaller cards really didn’t store much other than configuration data and they would’ve just used the internal 768 bytes of RAM on chip and just set the 28C64 up as an external 8KB of non-volatile RAM.

Anyway, I found them and thought “Hmmm a blinking LED doesn’t need 64KBs (2x32KB) of ROM to work, 16KBs (2x8KB) should be ample”. The only real issue I had was that I only had two and they were from different manufacturers. I wasn’t sure if this would cause an issue or not but I figured it would be worth a try.

A try …

The 28C64s are basically almost pin compatible with the 27C256s (obviously missing the two additional address lines.

So apart from A14, A13 and the VPP signal these would plug straight in. Woo hoo I was thinking, this’ll be easy!

I set to work. I wanted to replace the crappy single leaf sockets that are on this board, but I wasn’t willing to do all of them in one hit. The PCB traces on the thicker tracks have started that weird bubbling/lifting thing that things of this vintage start to do. I figured it would be safer if I just did one set at a time. So I carefully desoldered the two sockets and replaced them with machine pin sockets…

Old sockets be gone!

It was at this time that I noticed pin 1 on these sockets had traces. Given these are the VPP lines I thought that was strange. It turns out they’re actually connected to A16! This isn’t a problem (yet) as the VPP lines require high voltage to do anything.

The solution I came up with to make the 28C64s work without their write enable line being connected to A14 was to add another layer of machine pins with the sockets missing.

Adapters in place

I opted to pull out the VPP, A13 and A14 pins just to make sure. I then programmed my blink routine into the two mismatched 28C64s and expected great things to happen… And they did… briefly…

THE LED BLINKED!… sometimes.

After all the hassle with the EPROMS and UV light etc I finally had the little LED blink. The only issue was that it wouldn’t do it consistently. Sometimes it would blink 4 or 5 times then stop, other times it would blink once and stay on, and others it just wouldn’t blink at all. :(

I started to suspect that possibly different timings with the EEPROMs vendors and that the CPU was only sometimes getting it’s stars to align well enough for the LED to blink for a few cycles etc before it got all jammed up. I wasn’t too disappointed as I knew my element14 delivery was arriving in the morning with my new AT28C256’s and the fact I got the board to do anything was a total win in my book at this point.

I posted on twitter about my success and went to bed late, trying not to disturb my lovely wife once again.

Something fishy is going on.

Through my following working day I kept being suspicious of the timing conclusion I’d drawn myself into. It was odd that the CPU would process hundreds of thousands of instruction reads from these EEPROMs inside the delay loop code before “magically” the timing of the EEPROMs would became an issue and ruined the whole thing. That started to sound very very unlikely to me. It just didn’t make sense.

I then started thinking about the code, and how the interrupt and error vectors where not set correctly in the early part of the ROM code. So if the CPU had an external interrupt triggered by some of the other uninitialized hardware, the CPU could be falling into an ISR that didn’t exist and lock up.

This started to sound more and more likely to me, so once I finished work for the day I set about properly configuring the interrupt vector table and cleaning up my horrible testing code.

I wanted the code to be relocatable and the vector table be properly configured using a linker script so that I can link up a bunch of objects and have the magic of linking work with me rather than it just being a dumb copy-it-here type deal.

Building the code environment.

https://github.com/alangarf/amx_axc_m68k

After much frustration trying to figure out why ld was overwriting my new .vector section and my general lack of understanding of a lot of what the linker does I enlisted the help of my dear friend Niels to help point me in the right direction.

Together we figured out my .section in my assembly code didn’t have the right flags set so ld wasn’t loading the .vector section into the output. Rightly so because it thought it didn’t have to. After we figured that out the vectors where properly being set, and I had a workable development setup to continue on with.

I later discovered that objcopy also can generate interleaved binary files just for the purpose of creating ROM files for systems like this one. So rather than using some dodgy python I wrote quickly to split the resulting binary ROM image in half, I simply made objcopy create an even and an odd ROM image!

Suitably chuffed with myself at this point.

AT28C256s arrive!

Again, element14 in Sydney amaze me. My AT28C256s were ordered at 5:30PM the day before, and arrived at my door in country NSW Australia by lunch time the next day. I’m about 5 hours drive away from their warehouse (I used to live near their warehouse and boy it was useful), so it’s truly amazing how quickly I can get parts from them.

Anyway, deciding for a quick win I didn’t bother creating a pin swapping socket for these new chips. I figured I’d just use only the first 8KB of them and drop them into the existing sockets I had for the 28C64s.

AT28C256s in place

I realized after plugging them in that had I not removed the VPP lines from these sockets that I would’ve connected A16 to the A14 pin on these EEPROMs, which would’ve allowed for 16KBs of ROM split across 0x0000 -> 0x3FFF and 0x8000 -> 0xBFFF.

But more importantly when I do properly do the pin swap to make these into a continuous 64KB address space the write enable pin would end up at the VPP position which now I know has A16 attached to it!

This could’ve had all sorts of weird consequences had I not known that now!

So did it work?

I powered up the board with the new EEPROMs and the updated code and success it blinked perfectly, a nice solid consistent blink…

Blink you good thing!

… until I lifted the board.

UGH, you’re kidding me.

It seems like the issue I had with the other 28C64s wasn’t timing or bad code, it was a plain and simple dry joint somewhere on this board causing all the issues. :(

I mean expecting a 27 year old board that spent at least 10 years bouncing around my garage to have no damage after all this time probably was a little naive.

When testing the manufacturers firmware via a serial terminal I remember noticing initially that sometimes the board wouldn’t boot properly or it would crash sometimes. But even then I attributed this to a bad serial lead or the shitty terminal emulator I had on my Windows machine in the shed.

So, now I have a treasure hunt on my hands. Is it a bad solder joint, or a cracked trace somewhere on the board. I’m going to start with resolding all the connections first, then I’ll start looking more closely at the traces. The main issue I have is that a lot of the traces are hidden under sockets and immovable devices so that could be fun. BUT at least now I have a working board with a known issue. If I giggle the board just so I can make it work reliably. So that’s a win in my book!

What else have you done though, what about that schema?

Yeah I’ve updated the schematic some more, apart from the level conversion of the RS232 port I’ve got the entire schematic done now. You can get the KiCAD files from: https://github.com/alangarf/amx_axc_kicad.

Is that all?

Yeah I think that’ll do for today. :)

Ugh! I need UV - Retro Challenge 2017/04

Thu, 06 Apr 2017 00:00:00 +1000

So I set out to make the LED blink a merry blink tonight, but was finally thwarted when I came to the realisation I’d need UV light to erase the EPROMs to load my code in. Suffice to say this was mighty frustrating.

I’m getting ahead of the story, so let’s start from the beginning

The beginning

Starting tonight with a goal to have “something” running on this board before I went to bed I started sorting out my development environment. Setting up the required software and tools to get the job done so to speak.

I installed all the GNU m68k tools. I made a nice little Makefile to assemble my assembly…

M68K=m68k-linux-gnu
AS=$(M68K)-as
LD=$(M68K)-ld
DUMP=$(M68K)-objdump

START=0x00
FMT=binary
#FMT=ihex
CPU=-m68000

SRCS=blink.s
OBJS=$(SRCS:.s=.o)
MAIN=blink.bin

.PHONY: dump clean

all:    $(MAIN)
        @echo Builds blink.bin

$(MAIN): $(OBJS)
        $(LD) -e $(START) --oformat $(FMT) -o $(MAIN) $(OBJS)

.s.o:
        $(AS) $(CPU) -o $@ $<

clean:
        rm *.o $(MAIN)

dump:   $(MAIN)
        $(DUMP) $(CPU) --disassemble-all --target=$(FMT) --start-address=$(START) $(MAIN)

I even bashed together a little test program to twiddle the LED bit of the 74LS259…

/*
 * Blink LED connected to 74LS259 output.
 *
 * ROM is at 0x00000-0x0FA00.
 * RAM is at 0x20000-0x2FA00
 * 74LS259 is at 0x60000.
 */

.equ PORT, 0x60000

/* Iterations of delay loop before updating output value */
.equ DELAY, 50000

.org 0
    /* set initial SSP (supervisor stack pointer) */
    .byte 0, 0, 0, 0

    /* set the program counter */
    .byte 0, 0, 4, 0

.org 0x400
    move.l #PORT, %a0

.top:
    move.b #0x0E, %d0   /* set Q7 to low in the addressable latch mode */
    move.b %d0, (%a0)   /* write to 'LS259 */

    move.l #DELAY, %d1
.delay1:
    tst.l %d1
    beq .delay1end
    subq.l #1, %d1
    jmp .delay1

.delay1end:
    move.b #0x0F, %d0   /* set Q7 to high in the addressable latch mode */
    move.b %d0, (%a0)   /* write to 'LS259 */

    move.l #DELAY, %d1
.delay2:
    tst.l %d1
    beq .delay2end
    subq.l #1, %d1
    jmp .delay2

.delay2end:
    jmp .top

.org 0xFFFA
    jmp .top

And like a late night TV shopping channel ad I’ll even throw in a ~~free set of steak knives~~ tool to split the resulting binary into 32KB interleaved chunks so they’d work on the board.

#!/usr/bin/python3

import os
import argparse

parser = argparse.ArgumentParser()
parser.add_argument("src")
args = parser.parse_args()

even_fn = "even-{}".format(args.src)
odd_fn = "odd-{}".format(args.src)

with open(args.src, 'rb') as src:
    with open(even_fn, 'wb') as even:
        with open(odd_fn, 'wb') as odd:

            src.seek(0, os.SEEK_END)
            src_size = src.tell()

            src.seek(0)

            for c in range(0, src_size):
                src.seek(c)

                if c % 2:
                    odd.write(src.read(1))
                else:
                    even.write(src.read(1))

Also buy one get one free; I upgraded the software for the Minipro TL866 on OSX. I even figured out the magic device type for my EPROMs.

Then it happened…

I went and tried to write the first “even” binary to the EPROM…

$ minipro -p "27C256 @DIP28 #2" -w even-blink.bin
Found Minipro TL866A v03.2.72
Chip ID OK: 0x298c
Writing Code... OK
Reading Code... OK
Verification failed at 0x200: 0x20 != 0x00

COMPUTER SAYS NO...

Beware, losing all hope…

Damn it! I forgot I need to erase these things first.

Hunting around the garage for any source of UV I knew my search was futile. I even resorted to madness when I found a big bag of “UV” LEDs.

UGH, my world for some UV

So, now what…

Well I’ll need to figure out a source of UV. However I also figured I’d just buy some newer flash based EEPROMs in the mean time. Element14 have them in stock locally and I should see them before the weekend hopefully.

I ordered two AT28C256s, which are 98% pin compatible and fast enough for this board. I need to hack a pin swap between pin 1 and 27, but that’s a small price to pay I guess.

Still very disappointed, and my wife is likely to kill me when I sneak into bed at 1:00am. Wouldn’t be so bad if I had the taste of victory instead of the bitter pill of defeat.

I put up a good fight.

But UV got the better of me.

Here’s to tomorrow!

Got together a schematic today - Retro Challenge 2017/04

Wed, 05 Apr 2017 00:00:00 +1000

Quick one today, I worked on the schematic a little more. Still a few unknowns and a couple of holes I’ve not filled in yet, but the schematic is 80% complete. At least to a point where I can get a ROM monitor etc running and know where all the hardware is and have a good certainty I’m not talking in the breeze when I start trying to control the hardware.

I’ve also been working on a simulator for this board using the Musashi 68000 core in C. I’ve built up the address map, and started writting modules to simulate the hardware. This will help me greatly in development as I won’t need to be burning ROMs so often to try things out initially. A ROM monitor would help a lot too, so I’m weighing up options given the time I have for the competition and my already terrible work/life balance.

Here is a snippet of the UART core I’ve written for the simulator, it sets up the internal registers etc of the UART so the firmware can read and write state to configure the registers. The only bit I’ve not successfully worked out yet is the interrupt priorities, there is something wonky on this boards layout I’ve not figured out with the interrupt. But that’s another days problem.

scc2691_core uarts[2];

void scc2691_reset(void)
{
    for(int i = 0; i < 2; i++) {
        uarts[i].id = i;

        uarts[i].m1 = 0x0;
        uarts[i].m1_flag = 0x0;
        uarts[i].m2 = 0x0;

        uarts[i].csr  = 0x0;
        uarts[i].cr   = 0xA;
        uarts[i].thr  = 0x0;
        uarts[i].acr  = 0x0;
        uarts[i].imr  = 0x0;
        uarts[i].ctur = 0x0;
        uarts[i].ctlr = 0x0;

        uarts[i].sr  = 0x0;
        uarts[i].rhr = 0x0;
        uarts[i].isr = 0x0;
        uarts[i].ctu = 0x0;
        uarts[i].ctl = 0x0;

        uarts[i].cnt_flag = 0;
        uarts[i].cnt_value = 0;

        uarts[i].tx = 0;
        uarts[i].tx_last = time(NULL);
        int_controller_clear(1);
    }
}

The schematic so far …

Beeping out the board - Retro Challenge 2017/04

Mon, 03 Apr 2017 00:00:00 +1000

I first started with this board by pulling off the ROMs and dumping their contents. Being a m68k CPU generally the ROMs are split into odd and even byte streams, and in order to dissassemble them the two ROM images need to be interleaved again. I achieved this with a little bit of python:

#!/usr/bin/python3

import os
import argparse

parser = argparse.ArgumentParser()
parser.add_argument("odd_file")
parser.add_argument("even_file")
parser.add_argument("output")
args = parser.parse_args()

with open(args.output, 'wb') as out:
  with open(args.odd_file, 'rb') as odd:
    with open(args.even_file, 'rb') as even:

      odd.seek(0, os.SEEK_END)
      odd_size = odd.tell()

      even.seek(0, os.SEEK_END)
      even_size = even.tell()

      if (odd_size != even_size):
        exit("ROM images aren't the same size!")

      odd.seek(0)
      even.seek(0)

      for c in range(0, odd_size):
        odd.seek(c)
        even.seek(c)

        out.write(odd.read(1))
        out.write(even.read(1))

ROMing around like it’s 1995

I took the two ROM images I dumped and merged them back together using the following:

$ merge.py rom_odd.bin rom_even.bin rom_out.bin

After verifying the rom_out.bin using objdump for the m86k I knew I was on my way.

$ m68k-linux-gnu-objdump --disassemble-all --target=binary --architecture=m68k --start-address=0x00 rom_out.bin

This gave me the disassembled output of the m68k ROM image:

rom_out.bin:     file format binary


Disassembly of section .data:

00000000 <.data>:
       0:	0002 0ff0      	orib #-16,%d2
       4:	0000 0400      	orib #0,%d0

[SNIP]

The first value is the preset value the CPU uses for the SP (stack pointer). So it looks like it’s up in 0x20000 address space. That’s a good start, looks like some RAM is up around 0x20000.

The second address is the init jump point, so the first instruction the CPU will load is at location 0x400.

The stuff you see in ROM dumps …

Further digging through the assembly and looking at hex dumps you can start to see strings (even some funny stuff) and loops testing devices and memory etc.

00009140: 3131 2100 2a21 3132 2100 5041 5353 0053  11!.*!12!.PASS.S
00009150: 454e 4420 434f 4d4d 414e 4400 5345 4e44  END COMMAND.SEND
00009160: 2053 5452 494e 4700 5055 5348 0056 414c   STRING.PUSH.VAL
00009170: 5545 204f 4600 4445 5649 4345 2053 5441  UE OF.DEVICE STA
00009180: 5455 5300 5245 4345 4956 4520 5052 4f47  TUS.RECEIVE PROG
00009190: 5241 4d00 4841 5645 2050 524f 4752 414d  RAM.HAVE PROGRAM
000091a0: 0053 484f 5720 4445 5649 4345 0043 4f4d  .SHOW DEVICE.COM
000091b0: 5041 5245 2044 4556 4943 4500 5348 4f57  PARE DEVICE.SHOW
000091c0: 2049 4e50 5554 204f 4e00 5348 4f57 2049   INPUT ON.SHOW I
000091d0: 4e50 5554 204f 4646 0041 4d58 2042 5547  NPUT OFF.AMX BUG
000091e0: 003f 0048 454c 5000 4441 5445 0054 494d  .?.HELP.DATE.TIM
000091f0: 4500 5345 5420 4441 5445 0053 4554 2054  E.SET DATE.SET T
00009200: 494d 4500 5645 5253 494f 4e00 4d45 4d4f  IME.VERSION.MEMO
00009210: 5259 0053 4c4f 5400 4841 5645 2043 4f4e  RY.SLOT.HAVE CON
00009220: 5452 4f4c 0053 5953 5445 4d20 5245 5345  TROL.SYSTEM RESE
00009230: 5400 4543 484f 204f 4e00 4543 484f 204f  T.ECHO ON.ECHO O
00009240: 4646 0053 4849 5400 4655 434b 0048 454c  FF.SHIT.FUCK.HEL
00009250: 4c4f 003e 004f 4b00 434f 4e4e 4543 5400  LO.>.OK.CONNECT.
00009260: 5249 4e47 0043 4152 5249 4552 0045 5252  RING.CARRIER.ERR
00009270: 4f52 0044 4941 4c54 4f4e 4500 4255 5359  OR.DIALTONE.BUSY
00009280: 0000 4e56 fffe 422e ffff 4a39 0002 140b  ..NV..B...J9....
00009290: 6712 7000 1039 0002 140b 41f9 0002 140c  g.p..9....A.....

Beep, beep, beeeeeeeeeep …

After much looking through the code I had some good ideas where things were but I still didn’t fully understand the address map of the CPU and what devices were going where. So being all DIP packages and only a dual layer board I set out with my Fluke 87 and my pointest of pointy probes and started beeping out traces on the board to get a true account of where all the devices are and what they do.

I start building up a picture in KiCad of the schematic. Not taking values of components etc, but just the general connections so that many things can become much clearer. I first tackled the address decoding.

So after a lot of beeping and probing I got the address map out:

| 0x00000       | ROM                    |
| 0x10000       | ROM (addr alias?)      |
| 0x20000       | RAM BANK 1             |
| 0x30000       | RAM BANK 2             |
| 0x40000       | UARTs (2 x SCC2691)    |
| 0x50000       | INPUTs via a 74LS373   |
| 0x60000       | OUTPUTs via a 74LS259  |
| 0x70000       | INPUT via a 74LS373    |

The first INPUT and OUTPUT addresses are related to the OKI M5832 clock calendar chips 4 bit I/O bus and control lines, and the on-board green status LED. So that’s a good start.

Need to understand the UARTs a little better, one is standard RS232 the other is a weird RS485 like interface (called AXLink in AMX speak).

Anyway, that’s all for today. I’ll crack on with more tomorrow!

Retro Challenge 2017/04

Fri, 31 Mar 2017 00:00:00 +1100

After working with a friend on a Z80 based project I spoke about some SCC2691 UARTs I had from an old board I had saved from a skip bin some 10 years ago. He asked questions about the board and I described it to him..

“Yeah it’s got a 68000 on it, with what looks like 64KBs of RAM and I don’t know 32KB or ROM. Looks like there is a clock chip, dual batteries probably for the clock maybe the RAM, and what looks like a standard RS232 port.”

He quickly said I’d be nuts to tear the board apart and it would make a good candidate for the RetroChallenge competition. So after very little thought I considered this as something that might be fun to do. So of course…

Retrochallenge

My already busy life schedule has just gotten busier for the next month. I have successfully entered the 2017/04 challenge and intend to set to work on the 1st of April.

My goals for this project are:

Reverse engineer the board.
- Work out the memory map and the devices and peripherals on the board.
- Build enough schematic of the board to understand all the little trick it might hold.
Build a software simulator for the board using a m68k simulator CPU.
- This will include getting the boards own firmware running.
- Setup a ROM monitor.
Get a ROM monitor going on the board.
- Get the onboard the devices working (calendar, UARTs, LED).
- Get either BASIC or a FORTH interpreter working.
- Write a Mandelbrot set program.

I’d like to see what can be done with the battery backed up RAM. Perhaps getting a small OS running would be interesting. Adding additional hardware will be difficult as there is no “bus expansion” onboard so any additional hardware would have to sit ontop of the board and replace the RAM or something to access the address and data lines. But that’s not really going to be part of the challenge. Just getting a ROM monitor etc will be hard enough. :)