[Jman]

tvrfan,

I want to understand this better and have a lot of questions so I'm starting a new topic. I downloaded the AA.BIN and the XDT2.BIN to look at. I use HHD Software's Hex Editor Neo to open up the BIN file and search around.

I noticed your address references appear to be the using the point of view of how the 8061 CPU sees things (adding 0x2000 to the addresses of the downloaded binary files). This makes sense but should I just add 0x2000 to the top of the binary files and fill them with zeros to help me keep things as the 8061 would see it?

AA_Checksum_range.JPG (65.76 KiB) Viewed 3393 times

I could not understand the address references for the XDT2 when you say

An example subroutine is 0434a in 22CA for 4 banks (notice the rombank calls).
shown here is xdt2, shorter one as it has only 2 banks (1 and 8 ) ...

subroutine 0434a in 22CA confused me. I searched the XDT2 binary and found the HEX vales a1,00,20,3e in two places it starts at 0x164a9 and again at 0x164c0. Adding 0x2000 to theses address didn't help me in this case.

Is there a certain way to break the XDT2 into two seperate binary files that would help me match up the address references?

Thank you
J.W.S.


Re: FORD Custom EPROMs and Address range information
Post by tvrfan » Mon Nov 18, 2024 8:57 pm

Just a clarification on checksum. In all bins there is a start and an end address stored, and this defines what range the checksum uses. in A9L this is at 0x786a and 786c (two words, 0x2000 and 0x9ffe).

in AA bin, it's at 0x2050 and 0x205e. (0x2000 and 0x3fff).

Older bins like AA use a byte based add, later ones use word based. It's just a 'wrap around' addition calculation and end result should be zero.

In multibanks, addresses seem to be embedded in the code more, the checksum is calculated over all valid banks with a range for each bank. Code/hardware cannot do a 'global' pass of all addresses in one loop.

An example subroutine is 0434a in 22CA for 4 banks (notice the rombank calls).
shown here is xdt2, shorter one as it has only 2 banks (1 and 8 ) ...
Code: Select all


Sub_8a4a7:
8a4a7: 01,40 clrw R40 R40 = 0;
8a4a9: a1,00,20,3e ldw R3e,2000 R3e = 2000;
8a4ad: b1,ff,77 ldb R77,ff R77 = ff;
8a4b0: 10,08 rombk 8
8a4b2: 66,3f,40 ad2w R40,[R3e++] R40 += [R3e++];
8a4b5: 89,fe,ff,3e cmpw R3e,fffe
8a4b9: d3,f2 jnc 8a4ad if (R3e < fffe) goto 8a4ad;
8a4bb: 10,08 rombk 8
8a4bd: 66,3e,40 ad2w R40,[R3e] R40 += [R3e];
8a4c0: a1,00,20,3e ldw R3e,2000 R3e = 2000;
8a4c4: b1,ff,77 ldb R77,ff R77 = ff;
8a4c7: 66,3f,40 ad2w R40,[R3e++] R40 += [R3e++];
8a4ca: 89,fe,fe,3e cmpw R3e,fefe
8a4ce: d1,f4 jleu 8a4c4 if (R3e <= fefe) goto 8a4c4;
8a4d0: 88,00,40 cmpw R40,R0
8a4d3: df,02 je 8a4d7 if (R40 != 0) {
8a4d5: 17,44 incb R44 R44++; }
8a4d7: f0 ret return;

So you can see it does checksum from 0x2000 - 0xffff in bank 8 and 0x2000 - 0xfeff in bank 1.
(Yes, it's not directly obvious how to deal with the nailed on bank extension design.)

[jsa]

22CA

22CA.bin

(256 KiB) Downloaded 42 times

[tvrfan]

.bin file layout

This is one of those things which takes a bit of work to get the hang of, until you know what to look for -
The layout of the .bin file depends on which EEC reader was used. There is no official standard layout, as all the readers were written as someone's project.

A single bank EEC file (.bin) optionally has a 'filler block' of 8k at the front (0x2000). A filler block typically is all 0xff. So a single bin file can be 56k (no filler block) or 64K (with filler block at front) , or smaller if it is like AA with less than 0xffff as its end address.

Multibank 8065 may be 1, 2 or 4 banks. The bank numbering is..um.. strange. 2 bank bins have 1 and 8, and 4 bank bins have 0,1,8,9.
in the .bin files, these banks can also be in different orders, and EACH BANK in the file has an optional 0x2000 filler block at its front.

That's already a PITA to decode, and SAD hasn't even started doing anything yet !!

so - for AA.bin yes effectively add 0x2000 to those file addresses shown in Neo.

If the xdt2.bin is same as mine (which isn't always true) then it too needs 0x2000 adding to the .bin file, but when you get to file address 0xe000 it's a second bank ALSO needing another 0x2000 adding from there. You can spot the jump (0x20-27 or 0xe7) at the front of the bank.

If it helps you to break the file into 2 for understanding, for xdt2 you would cut 0xe000 to end of file and create a new file with it.

It's like mapping 'address range windows' onto the single file, if that helps.

SAD produces a "<name>_msg.txt" file, and at the front of it SAD shows how it mapped the banks, as a comment.
e.g.
AA # bank 8 0 2000 3fff this is , file address, ROM address start, ROM address end.
XDT2
# bank 1 0 12000 1ffff bank 1 begins at file address 0, (2000-0xffff)
# bank 8 e000 82000 8ffff bank 8 begins at file address e000 (2000-0xffff)

Note - Because of the way my SAD disassembler works, it treats a single bank as if it was bank 8 of a multibank to make it simpler. I can explain why !

I treat banks as a single 5 digit hex, so bank+0000 to bank+ffff to make it neater. This isn't official either by the way...

[tvrfan]

further...

My copy of 22CA however DOES have the filler blocks in front of each bank, so the 'map' of banks to file addresses is -

<bank no>, <file address>, <rom start>, <rom end>

# bank 0 2000 02000 0ffff
# bank 1 12000 12000 1ffff
# bank 8 22000 82000 8ffff
# bank 9 32000 92000 9ffff

so no fiddling with extra 0x2000 anywhere....
Separately I can explain the bank and how codes work, but get familiar with file layouts first....then binary tools like Neo make sense.

[Jman]

Thank you Tvrfan, that information helps a lot. I was searching for address 22CA at one point not knowing that was another BIN file. I'll do some digging around now that I have this big chunk of info and see how things look to me.

Thank you again
J.W.S.

[Jman]

I'm quickly noticing with my squirrel like thought patterns, I'm jumping down one rabbit hole after another, not keeping a consistent focus on figuring out one thing at a time. At this moment I'm starting at ground zero and looking at the beginning of the 22CA.BIN just looking at the first few program instructions. FF, FA, 27, FE looking up the OP codes I see its NOP, Disable Interrupts, then Short Jump.

I've been studying the short jump and using scratch paper and the windows calculator in programming mode. I think I finally understand what's this is doing. We are recognizing 20 thru 23 and short jumps that will be applying a positive displacement to the PC and 24 thru 27 as applying a negative displacement to the PC. I'll spare some of my typing and because this seemed hard for me to understand let alone try to regurgitate an understandable explanation without charts and visual aids.

So, if I have this right, we take the least 2 significant bits of the 7 (from 27) and put those in front of the FE so we get a displacement of 0x3FE and the PC is at 0x2002. Since this is a 27 short jump it's a negative displacement and that's where I get lost. How can we subtract when we are so close to the start? It will put the PC at 0x1C04 or 0x1C05 not quite sure if I apply the displacement when the PC is pointing to the 27 or the FE.

Please Advise
J.W.S.

[jsa]

You just stepped into the bottomless rabbit hole, LOL, welcome to disassembly.
Thankfully, there's a handy little program developed by TVRfan called SAD that will save doing some signed binary math on a calculator.

You can find it here;
https://github.com/tvrfan/EEC-IV-disass ... ment/Win32
Save version 4.012 to your computer.
Help files for it are here;
https://github.com/tvrfan/EEC-IV-disass ... aster/Docs

Drag and drop the 22CA bin onto SAD 4.012 exe.
All going well it will generate a 22CA_lst.txt file in the same place as the bin.
Open the lst file and you should see similar to this near the top of the file for Bank 0;

Code: Select all

02000: ff                 nop                    
02001: fa                 di                     interrupts OFF;

     # SJump from L02002
02002: 27,fe              sjmp  02002            goto 02002;

And similar to this at he beginning of Bank 8;

Code: Select all

     # Call  from L8D344                                                           Sub_8d303
82000: ff                 nop                    
82001: fa                 di                     interrupts OFF;
82002: e7,74,05           jump  82579            goto 82579;

0x82000 is the boot/reset default start address for all EEC's. If it ever runs the code 0x02002 something has gone terribly wrong so it has the loop of death.

Trouble is calculators don't do 11bit signed math, they want to do multiples of 8bit.
To cheat a bit, take just the FE as a signed byte and convert to decimal and you'll get -2 from the calculator.
The PC is 0x02004.
Convert unsigned word 2004 to dec 8196.
Dec8196-dec2=dec8194
Convert dec8194 back to hex2002.
Sjmp target address is 0x02002.

[tvrfan]

What jsa said ....

Welcome to coding. Have a look at the Ford software programming manual (in OpenEEC) .

What you described is right, the short jump uses the lowest three bits of the jump instruction and adds it to the TOP of the 8 bit following value to give a *SIGNED* offset. By default the top (most significant) bit of any field is the sign. Also all jumps (and calls to subroutines) are calculated from the beginning of the NEXT opcode. Those jsa examples should give you a good start...and...
e.g. AA start

Code: Select all

2000: e7,1d,00            jump  2020             goto 2020; 
2003: ff,ff,ff,ff,ff,ff   fill  

Calc is 0x2003 + 0x1d = 2020

So a jump of 27,fe (effectively 'jump -2' ) is a loopstop 'panic' in EEC code. It jumps to itself.

As a safety feature, all banks except 8 have a 'loopstop' jump at the start of each bank. Only bank 8 will have a real jump, which can be short (0x20-27) or long (0xe7) 0xe7 has a word offset. I forgot to add that some bank starts have 0xff, 0xfa before the jump, some don't.

Note - the short jump really is a special, because for words (2 bytes) everywhere else, the most significant byte is always SECOND, not first. I had to write a special bit of code in SAD to handle short jumps correctly. e.g.

2026: a3,01,50,20,30 ldw R30,[R0+2050]

and this also applies to pointers....(interrupt handler subroutines in AA)

Code: Select all

2010: 04,d0               word  d004                                               # HSO Port Output 2 = cal console (external)
2012: a0,2c               vect  2ca0             I_Timer_OVF                       # I/O Timer Overflow
2014: b2,2c               vect  2cb2             I_Ignore                          # A/D End of Conversion
2016: b3,2c               vect  2cb3             I_HSI_Data                        # HSI Port Input Data Available
2018: b2,2c               vect  2cb2             I_Ignore                          # External Interrupt Vector
201a: b0,2d               vect  2db0             I_HSO_1                           # HSO Port Output  1
201c: b2,2c               vect  2cb2             I_Ignore                          # HSI 1 Interrupt Vector
201e: b2,2c               vect  2cb2             I_Ignore                          # HSI 0 Interrupt Vector

I'll leave an explanation as to why jumps calc from the next opcode until later, and there's a whole other thread on here about signed versus unsigned values, and so on.

I wrote SAD for Linux and Windows, so you can also run it from a console and it will ask for a filename (with or without the .bin)