Been browsing through some assembly tonight. The instruction set has almost no surprises - your basic 16-bit RISC machine with 24-bit addresses.
The precise memory map depends on some pin settings (MD0,MD1,MD2) that select whether the CPU has external ram, and if so what the address space looks like. Without cracking open my machine (again, I'm such a hardware slut) I can't tell which mode the machine is set to use, but it has to be one of 5,6 or 7 as the BIN file writes ROM to the jump tables and ROM. I'm guessing it's using mode 7, the super-special chip-only design with no external RAM, just 8K internal Static RAM and heaps of ROM, but that's just a guess.
The address maps are on page 95 of 845 in the 3052.pdf document (I had to shorten the PDF name to save my sanity). The other PDF, the "h8300.pdf" file has a useful list of instructions in section 2.2. Having both docs open to crossreference works well.
So, back to the code. I'm using the 1.3 code to start with as I know there has to be a crucial decision point when the OS chooses between the 1.2 and 1.3 codebases, and that's what I'm looking for initially. It's an exercise in familarize myself with the code layout. The jump table at address 0x0000 says the code starts at 0x3FD2 - slap bang in the middle of the ROM in the memory map.
Some notes on the code.
Code:
003FD2 7A07 00FF FF10 MOV.L #H'00FFFF10,ER7
003FD8 7A00 0000 8000 MOV.L #H'00008000,ER0
003FDE 7A01 00FF EF10 MOV.L #H'00FFEF10,ER1
003FE4 7A02 00FF F296 MOV.L #H'00FFF296,ER2
Moving some fixed 32-bit addresses to the extended registers. 0x008000 is the end of the ROM area, 0xFFFF10 is the beginning of the External Address Space, 0xFFEF10 is an address that was important on the old 3048 chip - maybe they're testing which processor is being used? 0xFFF296 is a point in RAM that, on boot, hasn't been initialised yet.
Code:
003FEA 1F92 CMP.L ER1,ER2
003FEC 5870 0008 BEQ H'003FF8:16
If ER1 and ER2 are the same, skip the next bit.
Code:
003FF0 6C0B MOV.B @ER0+,R3L
003FF2 689B MOV.B R3L,@ER1
003FF4 0B71 INC.L #1,ER1
003FF6 40F2 BRA H'003FEA:8
Get a byte from 0x8000 (increment the pointer afterwards)
Write that byte to 0xEF10, add 1 to the pointer.
Branch always to somewhere above this starting point...
Code:
003FF8 5E00 3952 JSR @H'003952:24
003FFC 5670 RTE
Jump to the routine at 0x3952, pushing the Condition register (CC) and PC to the stack.
When you return, pop the CC and PC from the stack. (strange. The SP contains nothing at this pooint, so the function above had better fill it with something)
Code:
003FFE 0100 6DF0 MOV.L ER0,@-ER7
004002 0100 6DF1 MOV.L ER1,@-ER7
004006 0100 6DF2 MOV.L ER2,@-ER7
00400A 0100 6DF3 MOV.L ER3,@-ER7
00400E 0100 6DF4 MOV.L ER4,@-ER7
004012 0100 6DF5 MOV.L ER5,@-ER7
004016 0100 6DF6 MOV.L ER6,@-ER7
00401A 5E00 5AF2 JSR @H'005AF2:24
00401E 0100 6D76 MOV.L @ER7+,ER6
004022 0100 6D75 MOV.L @ER7+,ER5
004026 0100 6D74 MOV.L @ER7+,ER4
00402A 0100 6D73 MOV.L @ER7+,ER3
00402E 0100 6D72 MOV.L @ER7+,ER2
004032 0100 6D71 MOV.L @ER7+,ER1
004036 0100 6D70 MOV.L @ER7+,ER0
00403A 5670 RTE
Looks like ER7 is the stack pointer then, judging by the pre-decrement and post-increment ops it's a the top of memory growing downwards. This is a typical memory layout and function call as generated by a C compiler - push all the registers on the stack, jump to a routine, on return, restore the work. So the caller does the work, good to know. Looks like the RTE recovers the CC and mangles the PC? Not quite understanding that bit...
So that's the beginning of work. The function we jump to at 0x3952 is interesting.
Code:
003952 7A03 00FF F052 MOV.L #H'00FFF052,ER3
003958 7A05 0000 37BE MOV.L #H'000037BE,ER5
00395E 7906 0001 MOV.W #H'0001,R6
Load some constants into the registers.
Code:
003962 1900 SUB.W R0,R0
003964 0B50 INC.W #1,R0
003966 7920 7FFF CMP.W #H'7FFF,R0
00396A 4DF8 BLT H'003964:8
Clear R0(subtract it from itself)
Add 1 to R0
Compare R0 to 0x7FFFF
If it's less then branch to the increment - it's a loop that does nothing!
Maybe it creates a necessary delay? 0x7ffff is a typical value. Who can say.
Next comes a BIGASS block of function calls.
Code:
00396C 5E00 3B4E JSR @H'003B4E:24
003970 5E00 3F02 JSR @H'003F02:24
003974 5E00 4F0C JSR @H'004F0C:24
003978 5E00 0200 JSR @H'000200:24
00397C 5E00 2AA4 JSR @H'002AA4:24
003980 5E00 3636 JSR @H'003636:24
003984 5E00 0870 JSR @H'000870:24
003988 5E00 4FDE JSR @H'004FDE:24
00398C 5E00 54CE JSR @H'0054CE:24
003990 5E00 59C2 JSR @H'0059C2:24
003994 5E00 413A JSR @H'00413A:24
003998 5E00 372A JSR @H'00372A:24
00399C 5E00 3B76 JSR @H'003B76:24
0039A0 5E00 4178 JSR @H'004178:24
Yup. That's where the machine gets initialised! Someone had a function here that calls a bunch of functions one after the other, each one with no arguments. Looks like the program map is filling out nicely. The "JSR 0x0200" in that block is jumping to the first instruction in the ROM after the Vector addresses. Interesting..
Also notehow all the JSRs so far are to addresses less than the starting address - a typical layout for functions inside the same C file, jumping to functions that have already been defined. This won't hold for much longer.
OK, bedtime.
Bookmarks