Recent Posts

Pages: 1 ... 8 9 [10]
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by Ricardo on July 25, 2018, 08:00:19 PM »
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! :-)
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 25, 2018, 12:10:15 PM »
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???
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by Ricardo on July 25, 2018, 10:54:10 AM »
Sounds just like an old computer game ;-)
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 24, 2018, 10:49:29 PM »
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.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by Ricardo on July 19, 2018, 05:18:47 PM »
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.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 19, 2018, 02:23:50 PM »
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.
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by Ricardo on July 19, 2018, 07:19:08 AM »
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.
CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by jerryw200 on July 18, 2018, 10:59:03 PM »
That's brilliant, thanks
I have made a lot of progress in reverse engineering the code. Once I got the ROM code into a single file and identified how it controlled parts of the hardware I was able to start replacing Address and data values with labels to make the code readable such as the following block that I have fully reversed.
;*** READER STEPPER DRIVE *******************************************************************************************
;This function drives the Reader stepper motor
;It uses 16 passes to cycle the stepper through a full cycle 10, 00, 01, 11
;Bits 0, 1 of the Reader PORT A (READER CONTROL) are used to drive the stepper
;0X0055 is used to store READER_STEP_PHASE It is incremented every 4 cycles 

325D : 0E      " "      cli                                    ;Clear int flag to enable interrupts
325E : 96 55      " U"      ldaa   READER_STEP_PHASE    ;Load value at RAM address 0055 into Acc A
3260 : 4C      "L"      inca                                    ;Increment Acc A
3261 : 81 14      "  "      cmpa   #$14                 ;Too many steps without an INT?
3263 : 2B 13      "+ "      bmi   L3278                         ;Yes so branch to L3278
3265 : 4F      "O"      clra
3266 : 97 4F      " O"      staa    SEARCHING_FOR_SPROCKET_FLAG         ;
3268 : 97 05      "  "      staa   X0005
326A : B6 80 22      "  ""      ldaa   READER_DATA_PORT   ;Clear int flag
326D : B6 80 20      "   "      ldaa   READER_CONTROL_PORT
3270 : 8A 0C      "  "      oraa   #$0C
3272 : 84 F7      "  "      anda   #$F7
3274 : B7 80 20      "   "      staa   READER_CONTROL_PORT   ;Step the reader motor
3277 : 4F      "O"      clra
3278            L3278:
3278 : 97 55      " U"      staa   READER_STEP_PHASE   ;Store Acc A in RAM at 0055
327A : 96 56      " V"      ldaa   READER_LAST_PORT_VALUE   ;Load the value in RAM at 0056
327C : 84 03      "  "      anda   #$03
327E : 85 02      "  "      bita   #$02
3280 : 27 02      "' "      beq   L3284
3282 : 88 01      "  "      eora   #$01
3284            L3284:
3284 : F6 80 20      "   "      ldab   READER_CONTROL_PORT
3287 : C4 FC      "  "      andb   #$FC         ;Clear lower 2 bits of PIA-11 PA port (Reader Stepper bits)
3289 : 1B      " "      aba                            ;Add this value to Acc A
328A : B7 80 20      "   "      staa   READER_CONTROL_PORT   ;Write value back to PIA-11 PA port
328D : 7C 00 56      "| V"      inc   READER_LAST_PORT_VALUE   ;Increment the last port value

It is formatted better in my editor but you can get the idea. The capital labels are names I have assigned to the identified RAM addresses.
I have also worked out what are data lookup tables and what is code.
However as in my previous post it seems that the ROM that drives the Reader was never fitted so the code just spins round the main loop when the reader is put into run mode without doing much.
It looks like I will need to write code for the missing ROM but I need to fully understand how the entire code works first.
I was actually thinking that an emulator would be good for doing this so I will certainly give it a go.
The main difficulty is that the code was compiled with some form of optimisation and space saving tricks so it is a real maze to unravel.
An emulator would allow me to try to unravel blocks of code. I have been using a logic analyser to capture blocks of code under different trigger settings but this is slow.
I do have a Fluke 9010a with a pod for the 6800 but the main difficulty with using it on an old piece of equipment like this is that you have to be really careful what values are written to the various ports because it would be very easy to do a lot of damage if the wrong values are combined.
If I can work out what all the RAM locations are used to control the state machines then an emulator would be useful to write a block of code to drive the reader without having to mess with ROMS until I was close to a solution.
What further adds to the complexity and what had me confused for a long time is that it uses the 6821 PIA's in very odd ways. For example it uses ports set as outputs to also read as inputs without changing the configuration registers to redefine the pins as inputs. It took a while studying the 6821 datasheet for me to figure that one out.
I will post updates as I make progress. I am really hoping that someone with a ZIP30 reads this and confirms what ROM's they have fitted and even possibly send me images of them. It is even possible that the manufacturer never wrote the code to control the reader but that seems unlikely so just confirmation that the reader ever worked on these machines would be useful.

CODING AREA / Re: Reverse Engineering a 6800 system
« Last post by Ricardo on July 18, 2018, 10:30:45 PM »
Interesting read, well done.

If it helps, I am in the process of creating an emulator for a car engine ECU based on the 6803. You can load code, disassemble it, write new code and save it etc. Plus, single step and run at varying speeds, set breakpoints, watch specific locations etc. Feel free to use it if its any help.

There's plenty of documentation on there, but its a work in progress.
« Last post by Sunshine Boy on July 17, 2018, 01:32:22 PM »
Download files from

A 40 track bootable disk, it is 16 sectors. 

You need a 40 track drive (360k) on the PC to write the disk.  If you have a 1.2MByte drive you can do it but need to add the -d option and start from a new 5.25 inch 40 track disk - or use a bulk eraser.

You will need SAMDisk, available on the internet
then the commands are like

SAMdisk format -c40 -h2 -s16 -z1 -b1 -g54  b: 

SAMdisk copy newsys.imd b:

Pages: 1 ... 8 9 [10]