[cgrey8]

...Also assume that somewhere there is a CALL 3695 instruction to get here...

I think sailorbob's update clarified this to show how code might've entered your example. I just assumed the point of your example was NOT to educate people on the concept that CALL/SCALL does an implicit push to the stack and RET does an implicit pop. I took it that your example was to show how when words are passed, they are still pulled 1 byte at a time. Wasn't that your point in the example? Or were there multiple points intended to be discussed?

...Autoincrement - a lot of CPUS have this feature, basically because it's a time saver, as it already has the target register in its processing unit, it's quicker to increment it whilst it's
there, before writing it back to RAM. Autoincrement adds 1 if it's a byte instruction or 2 if it's a WORD instruction...

The auto-increment includes the operands of the opcode too. So if the opcode is 1 byte, but its operand is 2 bytes (i.e. a call), it increments the value in the program counter by 3 before putting it on the stack. Right?

...If anyone needs some more explanation of the symbols (e.g. the square brackets) just ask, and I will do that.

It wouldn't hurt. I remember when I was learning HC11 assembly, it was enlightening to me to see that, the same mnemonic actually resolved to a number of different opcode values depending on how it was being used. The brackets and the ++ pointer increment play into that...IIRC.
This spreadsheet might also be useful to others reading this:

8061-5 Opcodes.xls

One thing the spreadsheet points out is the opcode range for each mnemonic.

[tvrfan]

...Also assume that somewhere there is a CALL 3695 instruction to get here...

I think sailorbob's update clarified this to show how code might've entered your example. I just assumed the point of your example was NOT to educate people on the concept that CALL/SCALL does an implicit push to the stack and RET does an implicit pop. I took it that your example was to show how when words are passed, they are still pulled 1 byte at a time. Wasn't that your point in the example? Or were there multiple points intended to be discussed? .

All true, but jsa's comment on his post showed he thought the stack was empty, and said "the code gets here somehow" (more or less), so it was a specific response/help to that analysis.

...Autoincrement - a lot of CPUS have this feature, basically because it's a time saver, as it already has the target register in its processing unit, it's quicker to increment it whilst it's
there, before writing it back to RAM. Autoincrement adds 1 if it's a byte instruction or 2 if it's a WORD instruction...

The auto-increment includes the operands of the opcode too. So if the opcode is 1 byte, but its operand is 2 bytes (i.e. a call), it increments the value in the program counter by 3 before putting it on the stack. Right?

Um...not really. Think of the program counter (points to the opcode it's executing) as being added to by the length of that particular opcode as soon as it is read in.
That's a separate thing really.

...If anyone needs some more explanation of the symbols (e.g. the square brackets) just ask, and I will do that.

It wouldn't hurt. I remember when I was learning HC11 assembly, it was enlightening to me to see that, the same mnemonic actually resolved to a number of different opcode values depending on how it was being used. The brackets and the ++ pointer increment play into that...IIRC.
This spreadsheet might also be useful to others reading this:

8061-5 Opcodes.xls

One thing the spreadsheet points out is the opcode range for each mnemonic.

True. Some 8061 mnemonics have multiple 'flavours' and values.
e.g LDW can have 4 actual opcode values, for different address modes.
JNB can have 8 values, for the 8 different bits it can check.
But this is really part of the 'base' study for each CPU and its particular features.

Symbols - I have used some 'C' like symbols, as that's where I came from, but I decided not to go the whole hog as its pointer representation can be very un-obvious sometimes. Mpaton has stuck to the traditional assembler symbology. There isn't any big difference really.

R34 is the value held in that register.
[R34] says the value in the register is used as a pointer. (pointers are ALWAYS words)
R34++ means autoincrement the value in R34 after it is used.
[R34++] is the combination of the two - the increment happens after the value is used as an address

Mpaton's version only has a single '+' postfix for increment, but otherwise is the same (as far as I know !).

For comparisons it's pretty obvious standard maths, <, >, =, >=, <=, less than, greater than, equals, greater than or equal, etc, but I did let a != (not equals) slip through on SAD.

[sailorbob]

Code: Select all

0x5656     call  3695								
											Call places x5659 from the program counter on the stack
											The address WORD is odd, contravening the EVEN requirement
											Then program counter receives x3695, so the processor executes line x3695
0x5659     word  $0020

This does not contravene the requirement for word sized data to be placed on an even byte boundary in memory.

Quoting from the Why are there inline parameters ? topic:

But remember that for inline params, the value on the stack is an ADDRESS, and that address may be odd, because opcodes have different byte sizes...
This is why the extraction of the inline params is always byte by byte.....even if the param is a word.

[cgrey8]

...Um...not really. Think of the program counter (points to the opcode it's executing) as being added to by the length of that particular opcode as soon as it is read in.
That's a separate thing really.

So "auto-increment" is the terminology used to describe ++?

[tvrfan]

Well, that's what I am calling it.....

to explain -
I just want to keep things separate whilst we get more people up to speed. Yes, there are all sorts of processes going in inside the CPU core, but I reckon it's best to keep those things as separate for now, so as not to cause any confusion with opcodes. It's hard enough to deal with the different addressing modes and opcodes !

I've handed out some 'shiny bits' to whet the appetite, and I think they are enough for now. But happy to answer any questions about those examples.

In future, we will certainly get to some CPU 'core engine' stuff later, as we need it.

mpaton reminded me that we had Tom Cloud's original document to start with, I will post a pdf copy of it in the related disassembly thread....it's a good read for foundation stuff.

[jsa]

Code: Select all

 
3e2b: 08,01		     dcw   0108

According to the documents I have;
Opcode 08 is Shift Word Right
Opcode 05 is Decrement Word

Is this supposed to be
3e2b: 05,08,01

[decipha]

its an inline param, its data not an opcode

this thread has gone so far off topic its almost impossible to follow

chris can u split this into a bunch of threads with mpatons request hes waiting for jsa or ironman to reply to and move sailorbobs and tvrfans chats to

[jsa]

its an inline param, its data not an opcode

So the text DCW should not be there ?

this thread has gone so far off topic its almost impossible to follow

mpatons request hes waiting for jsa or ironman to reply to

When I understand these examples I'll move on to that.

[decipha]

no its arguments if anything it should say args

to simplify, the stack is basically a que list of addresses to go back to, what part of that above were uou having trouble with?

[jsa]

to simplify, the stack is basically a que list of addresses to go back to, what part of that above were uou having trouble with?

That concept of the stack being a list of addresses is resolved in my mind.

Code: Select all

3e2b: 08,01           dcw   0108

I must be thick , I can't see how 08,01 gets to be disassembled as DCW 0108, where'd the DCW magically come from if 0108 is an address off the stack.

All I see from that code fragment is it must be a typo or just plain wrong.

[sailorbob]

Code: Select all

3e2b: 08,01           dcw   0108

The dcw is a pseudo opcode (Declare Word)used to indicate the next byte is the start of word sized data and not an instruction.

chris can u split this into a bunch of threads with mpatons request hes waiting for jsa or ironman to reply to and move sailorbobs and tvrfans chats to

Please do not split the topic, you will end up with multiple duplicate posts or otherwise it will be impossible to make sensible topics if you try this.

to simplify, the stack is basically a que list of addresses to go back to

The stack can hold data as well as addresses.

[tvrfan]

DCW as a pseudo opcode....hmmm...that's an interesting way to cover inline pars.
I didn't think of that at all..... I put an '# args' comment in SAD after the data instead.

Either way works of course, not saying it's wrong or anything like that.

The STACK is just that, a stack, like a pile of papers - First in, Last out. It can have anything in it, either PUSHED directly, or something added as part of an opcode. Again, knowinf how the opcodes work gives you the overview on how the stack works.

[jsa]

Right I think I get it.

Code: Select all

3e28: ef,29,f8        call  3654
			EF is LCALL. The operand is a 2 byte long signed integer.
			3E2B is placed on the stack.
			The signed operand 0xF829 evaluates to Decimal -2007
			0x3E2B evaluates to D 15915
			15915-2007=13908, D 13908 evaluates to 0x3654
			D 2007 evaluates to 0x7D7
			0x3E2B-0x7D7=0x3654
			So the processor runs the code at 0x3654
.
.
.
3e2b: 08,01           dcw   0108
			Ignore the dcw
.
.
.
3654: 28,3f           scall 3695
			28 is SCALL, the operand is 11 bits long. See link below.
			3656 is placed on the stack.
			The signed opcode/operand 0x283f evaluates to Decimal 63
			0x3656 evaluates to D 13910
			13910+63=13963, D 13963 evaluates to 0x3695
			So the processor runs the code at 0x3695
.
.
.
3695: cc,38           popw  R38    
			CC is POP DIRECT
			0x3656 is taken from the top of the stack and stored at 0x0038

3697: cc,3a           popw  R3a          
			CC is POP DIRECT
			0x3E2B is taken from the top of the stack and stored at R3A
			R3A has the byte 2B & R3B has the byte 3E

3699: b2,3b,3c        ldb   R3c,[R3a++]  
			B2 is LDB INDIRECT
			The address at R3B/R3A is 0x3E2B. 0x3E2B has the byte 08
			08 is copied to R3C
			The address at R3B/R3A increments by 1 to 0x3E2C

369c: b2,3b,3d        ldb   R3d,[R3a++]
			B2 is LDB INDIRECT
			The address at R3B/R3A is 0x3E2C. 0x3E2C has the byte 01
			01 is stored at R3D
			The address at R3B/R3A increments by 1 to 0x3E2D

369f: c8,3a           pushw R3a
			C8 is PUSH DIRECT
			R3A holds address 0x3E2D
			3E2D is placed on the stack
             
36a1: c8,38           pushw R38
			C8 is PUSH DIRECT
			R38 holds address 0x3656
			3656 is placed on the stack

Link to SCALL discussion.
viewtopic.php?f=8&t=21730

[tvrfan]

jsa - Excellent ! That looks right to me from your comments.

So the RETs (would be further down in the subroutines) return to addresses ?? (just to complete the picture)

and so the routine at 3695 does what, at a higher level description ?

A related thing - jump calculations.
What I did for SAD was to have a little routine which did the address calc based upon a given size (and hence where the sign bit is). There are 4 (5 ?) different jump calculations in the 806x. It's a PITA as the offsets are signed and as you just found out, some weird sizes.....

[jsa]

Thanks tvrfan, sailorbob, cgrey, decipha & mpaton.

jsa - Excellent ! That looks right to me from your comments.

Spotted an error with fresh eyes today, edited the above post.

So the RETs (would be further down in the subroutines) return to addresses ??

It would be return to line 3656. The last address placed on the stack by SCALL, popped from the stack and and pushed back on later.

Thanks for the prompt.

and so the routine at 3695 does what, at a higher level description ?

Well, it could be taking a word from an odd address 1 byte at a time, and placing it at an even registry address for word opcodes to work on.

It's a PITA as the offsets are signed and as you just found out, some weird sizes.....

Yeah the inner workings of SCALL were a head scratcher for a bit . All seems obvious once understood, sign bit is zero pad with zero, sign bit is 1 pad with 1. Helps to learn beforehand how signed integers are represented in binary.

The other tricky things are the endianess of the source address operand and the source and destination operands are opposite to the intel literature.

[sailorbob]

Code: Select all

369c: b2,3b,3d        ldb   R3d,[R3a++]
         B2 is LDB INDIRECT
         The address at R3B/R3A is 0x3E2C. 0x3E2C has the byte 01
         01 is stored at R3C
         The address at R3B/R3A increments by 1 to 0x3E2D

         The Byte content of 0x003D is stored at 0x003B
         The value of the content of 0x003D increases by 1

You need to look again at this.

[jsa]

Indeed, R3D, thanks.

[sailorbob]

Still not quite there.

[jsa]

[mpaton]

Let me try for one more, and possibly last time, to steer this back to the explanation of how to disassemble 8061 code.
This is the second time I've had to quote a big chunk of my own post to try and get it back on track.

Now, I hope we can go back to my earlier simpler example from HHX0, specifically

So now ironman has "fixed" all the calls to the 1D lookups, what are they doing?

Here's the first call

Code: Select all

3F3B  EF6006                     call  L459E
3F3E  8E00                       word  $008E
3F40  B600                       word  $00B6

or maybe we have
3F3B  EF6006                     call  L459E
3F3E  8E                         byte  $8E
3F3F  00                         byte  $00
3F40  B6                         byte  $B6
3F41  00                         byte  $00

depending on whether we used word or byte for the directives. That didn't matter when we did it, because our goal was just to disassemble code as code. Now we're going to look at the data.

So what's the code at $459E look like? We know it's going to look up a 1D table (single input, single output),we know there will be interpolation code. So there are 2 inputs to this routine, and one output. The inputs are the input to the table, or more likely the address of the input, and also the table, or more likely the address of the table.

So the code at $459E is

Code: Select all

459E  91209D        L459E   orb   REG_9D,#$20           
45A1  2006                  sjmp  L45A9
45A3  91209D                orb   REG_9D,#$20               
45A6  91109D                orb   REG_9D,#$10                  
45A9  CC36          L45A9   popw  REG_36
45AB  B23732                ldb   REG_32,[REG_36]+
45AE  B23733                ldb   REG_33,[REG_36]+
45B1  AC3334                ldzbw REG_34,REG_33
45B4  710F33                an2b  REG_33,#$0F                  
45B7  080434                shrw  REG_34,#$04
45BA  6735F00032            ad2w  REG_32,$00F0[REG_34]
45BF  B23734                ldb   REG_34,[REG_36]+
45C2  B23735                ldb   REG_35,[REG_36]+
45C5  C836                  pushw REG_36
45C7  B23434                ldb   REG_34,[REG_34]
45CA  9B320234      L45CA   cmpb  REG_34,$02[REG_32]
45CE  3D9D04                jb    REG_9D,BIT_05,L45D5
45D1  DB0A                  jc    L45DD
45D3  2002                  sjmp  L45D7
45D5  D606          L45D5   jge   L45DD
45D7  65020032      L45D7   ad2w  REG_32,#$0002
45DB  27ED                  sjmp  L45CA
45DD  71DF9D        L45DD   an2b  REG_9D,#$DF                   
45E0  B23336                ldb   REG_36,[REG_32]+
45E3  B23338                ldb   REG_38,[REG_32]+
45E6  7A3236                sb2b  REG_36,[REG_32]
45E9  7A3334                sb2b  REG_34,[REG_32]+
45EC  7A3238                sb2b  REG_38,[REG_32]
45EF  3C9D04                jb    REG_9D,BIT_04,L45F6
45F2  DB09                  jc    L45FD
45F4  2002                  sjmp  L45F8
45F6  D605          L45F6   jge   L45FD
45F8  91209D        L45F8   orb   REG_9D,#$20                  
45FB  1338                  negb  REG_38
45FD  7C3438        L45FD   ml2b  REG_38,REG_34
4600  9C3638                divb  REG_38,REG_36
4603  359D02                jnb   REG_9D,BIT_05,L4608
4606  1338                  negb  REG_38
4608  763238        L4608   ad2b  REG_38,[REG_32]
460B  1139                  clrb  REG_39
460D  71DF9D                an2b  REG_9D,#$DF                 
4610  71EF9D                an2b  REG_9D,#$EF                  
4613  F0                    ret

So we see that after 45A9, it's going to execute the instructions at
45A9
45AB
45AE

Ironman, or jsa, would you like to explain what those 3 instructions do? you'll need to have downloaded the 8061 instruction guide.

Michael

This is simpler than the previous example, as there is only one pop instruction in those 3 instructions.

Once we have those decoded, it will get interesting, as we'll discover one of the Ford coding conventions.

Michael

While I am fine with discussing the nuances of the 806x processors, and I would like to help people understand assembly programming, I am arriving at the conclusion that if you don't know what an assembly call instruction does, or you don't understand assembly addressing modes, then you should go off and learn those things, elsewhere, because there is too much other stuff to learn before you can even think about making yourself a def file.

Disassembling my 3 simple instructions, this thread.

Anything else, have at it in another thread.

Michael

[jsa]

10-4

[cgrey8]

It seems what those lines are doing was discussed in previous examples. Load bytes that are embedded inline in the stack into contiguous local registers (R32 & R33). But more importantly, the bytes are pulled into registers word-aligned so the 2-bytes can be treated and processed as a word. And, indeed, you can see R32 is being used as a word by line 45ba.

45c5 shows R36's pointer value being pushed back to the stack after it was "bumped" past the 2 bytes discussed above (thanks to 45ab & 45ae) and another 2 more bytes (45bf & 45c2).

There's some data processing to the values that I don't fully understand. The content of R33 is being put in R34 (45b1). And since R34 is being treated as a word and the instruction is zero-extended, it's clearing R35 to zero. It appears R33 has it's upper nibble masked off leaving only the lower nibble (45b4, don't know why yet). R34 is shifting out the lower nibble (45b7). Now 45ba is where I'm getting confused. It appears the upper nibble of the value that was in R33 was actually a pointer to a register (specifically a register in the R0-R15 range). So the value of that register is added to 0x00F0 and stored in R32. But didn't this just overwrite whatever value was stored in R32 at 45ab? So yeah...I'm confused. Did I misinterpret something or is this exactly what's happening up to this point?


Moving on to something else I need help with, you did give hints as to what this code is doing...a table with 2 inputs, 1 output. Although you used the term 1D which I'm assuming is 1-dimensional? At first, I thought that might indicate a function. Or maybe a 1-dimensional table is a table with only 1 row and no scaling function (e.g. Injector Firing Order table). Can you clarify?

[mpaton]

OK, here's some elaboration of exactly the form of replies I need to see.

I want to identify the registers and memory of interest for the example 9code fragment),
and I want to see the contents of each register before and after each instruction.

The relevant registers here are

Code: Select all

PC    the Program Counter
SP    the Stack Pointer
REG_32
REG_33
REG_34
REG_35
REG_36
REG_37
memory address ZZZZ

At the start of our example, the PC contains 353B and the SP contains ZZZZ, a 16 bit quantity whose value is unknown. Even though this value is not known, how it changes is important. It is important also because we want to know what data is at address ZZZZ and above.
XX is used to signify a value which is unknown and which we don't care about.

Here's the previous example. I've changed the call destination to L45A9 so I don't have to deal with the code between L459E and L45A9 just yet.

Code: Select all

3F3B  EF6006                     call  L45A9
3F3E  8E00                       word  $008E
3F40  B600                       word  $00B6

or maybe we have
3F3B  EF6006                     call  L45A9
3F3E  8E                         byte  $8E
3F3F  00                         byte  $00
3F40  B6                         byte  $B6
3F41  00                         byte  $00

depending on whether we used word or byte for the directives. That didn't matter when we did it, because our goal was just to disassemble code as code. Now we're going to look at the data.

The code at $45A9 is

Code: Select all

                  
45A9  CC36          L45A9   popw  REG_36
45AB  B23732                ldb   REG_32,[REG_36]+
45AE  B23733                ldb   REG_33,[REG_36]+
45B1  AC3334                ldzbw REG_34,REG_33
45B4  710F33                an2b  REG_33,#$0F                  
45B7  080434                shrw  REG_34,#$04
45BA  6735F00032            ad2w  REG_32,$00F0[REG_34]
45BF  B23734                ldb   REG_34,[REG_36]+
45C2  B23735                ldb   REG_35,[REG_36]+
45C5  C836                  pushw REG_36
45C7  B23434                ldb   REG_34,[REG_34]
45CA  9B320234      L45CA   cmpb  REG_34,$02[REG_32]
45CE  3D9D04                jb    REG_9D,BIT_05,L45D5
45D1  DB0A                  jc    L45DD
45D3  2002                  sjmp  L45D7
45D5  D606          L45D5   jge   L45DD
45D7  65020032      L45D7   ad2w  REG_32,#$0002
45DB  27ED                  sjmp  L45CA
45DD  71DF9D        L45DD   an2b  REG_9D,#$DF                   
45E0  B23336                ldb   REG_36,[REG_32]+
45E3  B23338                ldb   REG_38,[REG_32]+
45E6  7A3236                sb2b  REG_36,[REG_32]
45E9  7A3334                sb2b  REG_34,[REG_32]+
45EC  7A3238                sb2b  REG_38,[REG_32]

So here's what I wanted to see prior to the instruction at 3F3B

Code: Select all

PC           contains           3F3B
SP           contains           ZZZZ
ZZZZ         contains           XXXX
REG_32       contains           XX
REG_33       contains           XX
REG_34       contains           XX
REG_35       contains           XX
REG_36       contains           XX
REG_37       contains           XX

Then we execute
3F3B EF6006 call L45A9
Then the relevant register template or block becomes

Code: Select all

PC           contains           45A9
SP           contains           ZZZZ-2
ZZZZ         contains           XXXX
ZZZZ-2       contains           353E
REG_32       contains           XX
REG_33       contains           XX
REG_34       contains           XX
REG_35       contains           XX
REG_36       contains           XX
REG_37       contains           XX

Then we execute
45A9 CC36 L45A9 popw REG_36
Then the relevant register template or block becomes

So please continue this.
Take the provided template of relevant registers and memory location, and fill it in, instruction by instruction.

Like this, except that YY or YYYY means YOU need to fill this in:

Code: Select all

PC           contains           YYYY
SP           contains           YYYY
ZZZZ         contains           YYYY
ZZZZ-2       contains           YYYY
REG_32       contains           YY
REG_33       contains           YY
REG_34       contains           YY
REG_35       contains           YY
REG_36       contains           YY
REG_37       contains           YY

This is what you need to do to UNDERSTAND what is going on, and to show others that you do understand it, ad allow them to understand it. I'll just have to hope I got it right so far :-)

Michael

[tvrfan]

...
There's some data processing to the values that I don't fully understand. The content of R33 is being put in R34 (45b1). And since R34 is being treated as a word and the instruction is zero-extended, it's clearing R35 to zero. It appears R33 has it's upper nibble masked off leaving only the lower nibble (45b4, don't know why yet). R34 is shifting out the lower nibble (45b7). Now 45ba is where I'm getting confused. It appears the upper nibble of the value that was in R33 was actually a pointer to a register (specifically a register in the R0-R15 range). So the value of that register is added to 0x00F0 and stored in R32. But didn't this just overwrite whatever value was stored in R32 at 45ab? So yeah...I'm confused. Did I misinterpret something or is this exactly what's happening up to this point?

Clue - "OK Ladies and Gentlemen, this way please !"

There are several ways to do maths in CPU cores, some are a lot faster than others. For example, dividing by 4 is SLOW, shifting right by 2 places is much faster, and gives the same answer. LDZBW effectively turns an unsigned byte value into an unsigned word if you think about it, and LDSBW does the same for a signed byte. That fact that the LZBW reads an upper byte of a word therefore means from a maths point of view that it is ...... ?

Second - I did mention that A9L and others have a particular kind address system setup in various other threads - I believe this is so that debuggers/cal console etc can change the 'base' registers to move to an alternate calibration dataset. Aren't those 'base' registers Reg F0 through to FE ??

That's enough from me .....

[decipha]

dividing by 4 is SLOW, shifting right by 2 places is much faster, and gives the same answer......... That fact that the LZBW reads an upper byte of a word therefore means from a maths point of view that it is ...... ?

Given your target audience, I don't think they are quite that far along to infer an 8 bit shift >> [/256] assuming they lack the fundamental knowledge of how bits function considering they have no background in programming

you might want to dumb it down a little more

[mpaton]

dividing by 4 is SLOW, shifting right by 2 places is much faster, and gives the same answer......... That fact that the LZBW reads an upper byte of a word therefore means from a maths point of view that it is ...... ?

Given your target audience, I don't think they are quite that far along to infer an 8 bit shift >> [/256] assuming they lack the fundamental knowledge of how bits function considering they have no background in programming

you might want to dumb it down a little more

Decipha is quite correct, and I have been trying to make it very simple.
However, it's just not working, when Chris is always there telling us what he thinks seems to be happening, and Andy comes along with new stuff that is way past he point I'm trying to get across.

I guess I give up, people here really DON'T want to learn how to do disassembly, nd I now know I don't have the patience to teach it.

Good luck wit it Andy, it's all yours now, take it where you will.

Michael

[decipha]

mpaton,

I know it can be frustrating at times but I wouldn't throw in the towel just yet, there are a few willing to learn and I really believe your teachings will help them significantly.

If you want to continue this on the other forum I'll personally see to it that no misc banter clogs up the thread

http://forum.efidynotuning.com/viewforum.php?f=30

[cgrey8]

...when Chris is always there telling us what he thinks seems to be happening...

I say what I think so I can be corrected. I don't care if I'm wrong and am proven so in public if I eventually get corrected. However it does nobody any good for me to be wrong and nobody tells me how I'm wrong.

[tvrfan]

I don't know whether to LOL or throw my hands up and swear.....

Whilst I understand the comments, That was sort of the point to get people up to speed...

Too advanced ?? Sorry all, but how the hell are we supposed to go forwards without this step ? How can we go forwards without basic knowledge of binary arithmetic ?

The EEC code is full of it, and even 1D and 2D lookups use binary arithmetic tricks to get their answers.

I don't understand. I thought I was helping.

<confused>

[tvrfan]

Here is how SAD prints that code from HHX0, with the psuedo source -

Code: Select all

45a9: cc,36              pop   R36            R36 = pop();
45ab: b2,37,32           ldb   R32,[R36++]    R32 = [R36++];
45ae: b2,37,33           ldb   R33,[R36++]    R33 = [R36++];
45b1: ac,33,34           ldzbw R34,R33        R34 = (uns)R33;
45b4: 71,0f,33           an2b  R33,f          R33 &= f;
45b7: 08,04,34           shrw  R34,4          R34 = R34 / 10;
45ba: 67,35,f0,00,32     ad2w  R32,[R34+f0]   R32 += [R34+f0];
45bf: b2,37,34           ldb   R34,[R36++]    R34 = [R36++];
45c2: b2,37,35           ldb   R35,[R36++]    R35 = [R36++];
45c5: c8,36              push  R36            push(R36);
45c7: b2,34,34           ldb   R34,[R34]      R34 = [R34];

My argument - How anyone can go forwards to get what's in R32 at 0x45bf without knowledge of shifts and binary arithmetic (or some help) beats me.....and what's in that register is crucial to the next step...... That's my point.

If it's 'too complicated for now' then like I said, I'm baffled.

Anyone want to have a go and prove me wrong ?