Granted, the task ahead of you is rather daunting.
I believe that you have to take a leap of faith and don't look backwards.
Sit down and write down the functional specifications of the device and then move forward. Attempting to port ASM code from one machine to another is counter productive and you will be forever stuck in the past.

 

Just looking at the specs for a representative sample of the 9S12 family and seeing what it has to offer makes me think that may be a suitable one-chip solution. The timer and PWM generators together look like they could replace the 6840 and having an I2C port means I can ditch the 8279 and LEDs completely in favor of an LCD, and of course all kinds of on-board memory.

But first things first. I still need a safe working copy of the fixture (the original is cramped and has a bad 'hot chassis' design). I have two different approaches I can take, I just need to make a decision and get the copy working, then I can turn my attention to the 9S12.

The EEPROM can be moved. I would suggest setting it to $4E00 (get it out of the way) before enabling it by writing to the Config Reg. This must be done in the first 64 BUS cycles out of RESET.

The S12 and many of the of the S08 parts support IIC. I use SPI because (if I remember correctly) it was first introduced on the HC11 and I haven't
had any problems with it. Yes, it does require 1 more data signal and 1 Chip Select for each device but the S12 has a lot of I/O pins and because it came first I find more devices using SPI and I find it simpler to program.

 

The Config register on the HC11 is implemented as an EEPROM cell and apparently requires a special process to write (the same process as writing data to the EEPROM).

 

MrChips: I've made a decent effort at rewriting a good chunk of the code into C, but some of the opcodes are proving to be a challenge to reinterpret (ROL / ROR, carry operations, signed number evaluations).

 

The Config register on the HC11 is implemented as an EEPROM cell and apparently requires a special process to write (the same process as writing data to the EEPROM).

If you want to change the config register, there is sample code the the HC11RM (Reference Manual).
If you are concerned about the EEPROM being enabled, the HC11F1 Manual, Section 4.4.1 EEPROM, "The 512-byte on-board EEPROM is initially located from $FE00 to $FFFF after reset in single chip modes."

It wouldn't make much sense in Expanded Mode to have the EEPROM enabled by the factory unless there was code in the EEPROM because of the RESET vector.
I can't find any thing stating that there is code in the EEPROM. If you don't need the EEPROM to just get a working copy, you can ignore the EEPROM to start with.
There was no internal COP in the 6801, so you should be able to ignore that also.

 

Oh, okay. I missed that part regarding whether the EEPROM is in play in expanded mode. Good to know!

I've got an order in for the updated board and will start getting the rest of the parts ordered.

Thank you for taking the time to help me. Knock on wood that the last of the bugs have been shooed away...

 

I cut my teeth on Z80, went 6809, then 68HC08 / 68S08. When NXP got the 68xx, the free asm IDE went away. So I changed to STM8 and Way happier for it. Huge family of variants (pre-supply chain BS). Very good implementation of Eclipse IDE framework and I find the peripheral functions easier to understand and configure.

That you're writing assembler now, I'd give you a week to get comfy. that's how long it took me.
G.H <<<)))

 

Hrm. (drumming fingers on table)

So I had the board redone and no go. I'd forgotten I needed to change the EPROM due to the different firmware, and I did so. While the board lit up with 0s in the reading with the incorrect EPROM, nothing lights up at all with the 'revised' EPROM.

 

I know, I know, necro-posting and all that (even though it is my thread).

In the end, other priorities pushed this onto the back burner, but MrChips' post (#21 above) is the approach I ultimately need to take. I have acquired some additional information that should help me write out what each section does in plain English, then it should be relatively simple to write that into C code.

That point was driven home when I had a sudden realization that one particularly long block of assembly language was just a simple equation to multiply a stored value by a constant.