Reverse Engineering a 6800 system

[Ricardo]

The emulator expects to work with 16 or 32k binaries, located at either 0x8000 or 0xC000. It’s a while since I created the load code (I update the emulator each winter when things are quiet and started it 3 years ago) so I’m not sure about loading smaller files. After loading a routine recursively “walks” down all threads via the 6803 hardware vectors to try to work out what’s opcodes and data. The only bits it can’t resolve are jmp/jsr n,x but occurrences of these are recorded. Read the section on the Code Walker in the help pages.

If you have trouble loading a file let me know and i’ll look into a mod. Also trying “importing” your source text file as it will parse labels, code and comments although it may be sensitive to format etc

You probably already know but with the 6803 after reset the load of the stack pointer (LDS) enables the nmi so other code can start executing, the emulator doesn’t have an interrupt control system yet.

[jerryw200]

Thanks Ricardo
I won't need to use any INT's as I know exactly what the interrupt does in the teletype and I do not need to include it.

I can put the code block anywhere to test it.
It is really unravelling the jumps and branches that I would want to use it for and it looks like you have included some watches which is really what I was looking for. Trying to keep track of what each value is by looking at a logic analyser printout is really tedious as it only shows the CPU pin values and not the internal register values.
Seeing how the values change within each code block should simplify the process and also allow me to test any new code I write to make sure it does what I want.

[Ricardo]

The 10 watch panels on the right of the assembly display can be used to watch(!) memory locations and halt execution on a write (R/W), or when a condition is met (same as branch mnemonics).

Looks like the best way to use it is to click FETCH and select one of the EPROM images (HF4WD / top one) that will wake everything up and load data to 0x8000 to 0xFFFF.

You can then assemble code, poke bytes etc then click SAVE to save the chip image to your HD. To load it back use the LOAD CHIP button. These deal with the quantity of data which was originally FETCHED, so 16k from 0x8000.

I created the emulator on a Mac running Safari, it works best (fastest) in Safari or Chrome on a PC. IE and Opera arn't great, but I think MS Edge works.

[jerryw200]

Progress has been slow.
The code is organised as a huge loop of code blocks where each block handles different things such as moving the print head or firing the print pins or sending data out of the ASYNC or receiving data or punching data etc and they are ALL always run through on each loop so the code can see if anything in each function needs to be updated.
There are also a series of option switches and user switches that are used to modify certain code block functions.
In addition each code block requires different numbers of passes to complete each step of a task so there are numerous variables controlling each function. For example there are 4 timers just to handle the punch motor start and run times.
This makes reverse engineering it very complicated but I am finally getting each function documented.
The code to run the punch in continuous mode is definitely not present and so I am going to have to write my own handler for it but I need to understand more about how to integrate this into the code before I start.
To simplify this I have been editing copies of the ROM's to create jumps over parts of code that are not related to the reader or character handling.
For example I have added a jump over the punch handling code as the punch works so there is no point in examining the code for it.
I can then delete this code from the reverse engineering file that I am creating.
This shortens the main loop and makes capturing events easier.
Once I have removed as much as possible I can start work on the reader continuous run code ROM.

[Ricardo]

Sounds just like an old computer game ;-)

[jerryw200]

Hi Ricardo
Yes its is similar, just a lot more complicated as there are around 35 hardware inputs that are all asynchronous and change what each pass round the loop does so I am trying to isolate each piece of hardware that is not needed by the others and I can then begin writing the required code.
A big challenge is that I have no idea what the machine is supposed to do. eg echo locally or remotely depending on settings etc so I need to make sure that when I add reader code it includes all required targets based on what the existing code expects.
Unfortunately I have been totally unable to locate any technical information on it so everything was a total unknown.
Some of the option settings are just weird and I have to try to figure out if the unit has a hardware fault or the behaviour is intentional or just a old bug.
For example selecting one of the dip switches just continually feeds paper which seems pointless???

[Ricardo]

Sounds like it’s keeping your mind busy though ... “if you don’t use it you loose it” etc ;-)

It’s a bit like that with the ECU code I’ve been looking at, redundant code remnants, bugs, I’m stuck with working out what two inputs do and it took an age to work out why the fuel pump keeps getting turned off and on again in milliseconds repeatedly all over the code with the same routine which isn’t a subroutine, more of a macro. Better than doing crosswords in my old age! :-)

[jerryw200]

Maybe its just another way to lose my mind.

To be honest when I got it I thought it just needed repairing, it had loads of faults and nothing would run. I had no idea that a big part of the code would be missing so once I spent a long time looking for a hardware fault with the reader but finally realised that it was not broken (the only bit of the hardware that was not faulty).
I am seriously considering re-writing the entire software using a C compiler as this may be easier than trying to figure out what the hundreds of variables are for. I now know how to address and control all the hardware and I have identified and extracted all the lookup tables for the punch, ASCII, EAI, and print head pins so that may be a more realistic option.
Implementing this in a few C state machines would probably be a lot quicker.

Out of interest in my business I write code for critical systems and one fail safe technique that I use is to frequently switch things off that would be dangerous to leave running if something failed. They are quickly re-enabled if the code determines that they should be left running but the idea is that a failure leaves the system in a 'safe' mode rather than leaving it running. EG if a motorised syringe is being controlled then it is stopped every minimal increment and then restarted so that any failure results in it being off. If the system crashes then it is already stopped, fail safe.

[Ricardo]

The fuel pump line is attached to a hardware down counter external to the processor which resets the CPU when if reaches zero. The repeated toggle of the fuel pump line is keeping the timer going, the fuel pump has enough capacitance to not notice the toggles. Its a watch dog timer incase the CPU hangs in a loop. Not sure why they didn't use a subroutine though, stack doesn't get used much.

[jerryw200]

Yes that makes sense. As I mentioned in my last post I do exactly the same thing in critical systems to provide fail safe control.
If the processor fails then the pump is not left running so it has to be constantly 'poked' or it stops.
A subroutine could fail it any part of the processor circuit fails or a memory chip fails etc.
Also makes for an interrupt safe system. A dead processor or a bug and the pump will stop.

[Ricardo]

It’s nothing to do with the fuel pump, they just use that line because the fuel pump doesn’t notice and they had no spare lines. If the timer hits zero it triggers a hard processor reset. If any memory went down the ecu would be foo bar anyway. Amazing what’s going on re: interrupts when you consider an engine at 7000rpm with 4 spark plugs, 4 injectors and a 1MHz clock. It probably can’t cope with the JSR/RTS overhead.

[jerryw200]

OK normally critical hardware is run in failsafe modes. Yes the processor will fail if a memory chip goes down, that was my point. You cannot have fail safe in code because too many things can go wrong. Also if the pump and cpu are powered from different rails then it has to account for failure of a single rail. Sounds odd that they are using a control line as part of a counter.