16 replies to this topic

[tregare]

is there anyone on here that has a disassembler and the skills to properly disassemble XF551 firmware? the 8051 (MCS51) architecture micro controllers are source-code compatible with MCS48 but not binary compatible. I am starting to work on a PCB for an XF551 work-alike controller and it would make it easier if I could use an 8051 compatible micro controller, they are likely to be available longer than 8040/8050s and cheaper to boot.

I found one "PD" 8040 disassembler a while back, but it didn't work

[Rybags]

Would IDA Pro be of any help?

http://www.hex-rays....pro/idaproc.htm

8051 is listed but not the others you mention.

Do you have an instruction set sheet? Is it a simple 1 byte instruction format, if that's the case then I might be able to modify an ancient 6502 Disassembler I wrote to work with it.

[Rybags]

Found some more stuff... no idea if it's any help:

http://www.8052.com/users/disasm/
http://coprolite.com/art16.html
http://home.mnet-onl...s-48/mcs-48.pdf

[Simius]

Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address.

Attached Files

•  xf551.txt   35.16K   135 downloads

[tregare]

Simius, on Thu Apr 22, 2010 2:27 PM, said:

Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address.

Thank you!

[sup8pdct]

tregare, on Fri Apr 30, 2010 1:28 PM, said:

Simius, on Thu Apr 22, 2010 2:27 PM, said:

Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address.

Thank you!

Bump

How is this going?

James

[sup8pdct]

Bump again.
Any news?

James

[phaeron]

I started tearing apart the ROM based on Simius' disassembly (attached), and although I managed to find several critical routines, I found a couple of problems:

• There are critical command data tables that were not identified as such and munged during the disassembly. In my partially commented listing, they are at A0C9, A0D1, and A0E4. Note that the dispatch table stores low address bytes of labels, so as-is it will not survive any rebuild that shuffles addresses.
  
• There a couple of branches into no man's land at AEC7 and AFEE. I don't know what these were supposed to be as those regions appear blank in the raw dump, too.

Attached Files

•  xf551-rom.txt   72.41K   24 downloads

[phaeron]

Newer version of XF551 listing, about half commented. I figured out why there were incorrect branches to the end of the ROM: the 8048 has a screwy 2K bank switching algorithm for external code, and the disassembler mis-identified several branches as going to the wrong bank. In the case of the command table, the format command branch was listed as going to AD00 instead of an A500 because it saw a bogus SEL MB1 instruction prior to the jump table. There were a couple of broken branches in the read/write sector path because of an even more devious problem, which is that Atari reused bits of the stack pointer to hold data and this apparently also has the effect of switching banks (!).

It should be noted that if you're planning on extending the XF551 ROM, it could be difficult to do so since the code not only uses bits of the stack pointer for storage, but also most of the port 2 bits and ALL of the internal RAM. Some of the stuff going on in here is much crazier than what you find in the 810 and 1050 firmware.

Attached Files

•  xf551-rom.txt   88.41K   22 downloads

Edited by phaeron, Wed Feb 1, 2012 2:43 AM.

[JAC!]

>which is that Atari reused bits of the stack pointer to hold data and this apparently also has the effect of switching banks (!>
Haha, that's great. Reminds my of the VCS cardridge which put all the subroutines in bank 2 and used the SP to indicate the active bank.

I'm not familiar with the instructions set but all that "MOV A,R7" looks like blank space which could be used (of course considering all of the above and the resulting alignment problems).

[bob1200xl]

Tell me about it... I wrote a disassembler in BASIC and waded thru just enough code to make a 3.5 work. The XF551 is an excellent example of why we should stick to 65xx processors.

What is it that you want to do?

Bob

phaeron, on Wed Feb 1, 2012 2:43 AM, said:

Newer version of XF551 listing, about half commented. I figured out why there were incorrect branches to the end of the ROM: the 8048 has a screwy 2K bank switching algorithm for external code, and the disassembler mis-identified several branches as going to the wrong bank. In the case of the command table, the format command branch was listed as going to AD00 instead of an A500 because it saw a bogus SEL MB1 instruction prior to the jump table. There were a couple of broken branches in the read/write sector path because of an even more devious problem, which is that Atari reused bits of the stack pointer to hold data and this apparently also has the effect of switching banks (!).

It should be noted that if you're planning on extending the XF551 ROM, it could be difficult to do so since the code not only uses bits of the stack pointer for storage, but also most of the port 2 bits and ALL of the internal RAM. Some of the stuff going on in here is much crazier than what you find in the 810 and 1050 firmware.

[sup8pdct]

One part of the rom code has always got me stumped.
According to the specs I have. the only way the 8040 (mcs-48) can jump rom banks (2K boundary) is to use SEL MBx they use either jump or call. Also, if the program reaches the end of a 2k boundary, it loops back to the beginning of said bank. So code JMP FEE (used 3 times) in the 2nd bank jumps to nowhere where the rom is blank (FF or MOV A,R7), then loops round to 800.
I believe it was ment to go to 7EE But it cannot as no SEL MB0 command is used prior. The PSW bits that are changed are only the stack pointer.
The following code from 7EE to 7FF according to the specs is never used. If this code is run, it will loop back to 000!!!!
So is this a rather bad error in the code?? And what that little bit do anywhy???

The xf single rom from CSS has the same code that is listed at 7ee moved to 800 so perhaps he saw the error and fixed it?



;==========================================================================
; Track/sector division routine
;
A7EE MOV A,R0 ;save R0-R5 to 075-070H
MOV R0,#75H ;...
MOV @R0,A ;...
DEC R0 ;...
MOV A,R1 ;...
MOV @R0,A ;...
DEC R0 ;...
MOV A,R2 ;...
MOV @R0,A ;...
DEC R0 ;...
MOV A,R3 ;...
MOV @R0,A ;...
DEC R0 ;...
MOV A,R4 ;...
MOV @R0,A ;...
DEC R0 ;...
MOV A,R5 ;...
; 2k Boundry 800 hex
MOV @R0,A ;...
MOV R0,#77H
MOV A,@R0
ADD A,#0FFH
MOV R2,A
DEC R0
MOV A,@R0
etc

Please note that code at 070, 251, 252,2a5 and 2a6 are also not used. This is the serial timing changes required to get xf to work properly with PAL. When caculated out, 1 cycle is added to the timing.

James

[phaeron]

I never thought about that possibility, but yes, I think you're right -- the branches to AFEE *are* actually correct and it's a horrible bug on Atari's part. This means that the register save/restore code doesn't actually work and instead a couple of the registers get stacked to random locations. It probably didn't cause problems in practice because the following routines don't actually use the contents of R0-R5.

It also looks like the branch to A022 in that routine is wrong and should actually point to A822 instead, as the disassembler didn't catch the 2K program bank crossing.

I was wondering about those stublets of code that weren't called. NTSC/PAL adjustment makes perfect sense.

I do have to say that I don't think the choice of an 8048 family chip here was a bad idea. Despite the quirks, it avoided the need for two external chips from earlier designs (RAM and RIOT) and it's ability to AND/OR directly into a port saved a lot of instructions. It's also quite competitive in instruction rate as it executes mostly single cycle instructions at 555KHz and has register-to-register operations. It's a lousy general purpose CPU, but a good microcontroller.

[sup8pdct]

phaeron, on Sun Feb 19, 2012 1:19 PM, said:

I never thought about that possibility, but yes, I think you're right -- the branches to AFEE *are* actually correct and it's a horrible bug on Atari's part. This means that the register save/restore code doesn't actually work and instead a couple of the registers get stacked to random locations. It probably didn't cause problems in practice because the following routines don't actually use the contents of R0-R5.

It also looks like the branch to A022 in that routine is wrong and should actually point to A822 instead, as the disassembler didn't catch the 2K program bank crossing.

I now have an answer. thanks.
The A022 part on the dissembler i used shows that to be correct at 822. Must be a 'feature' of the program you used.

James

[sup8pdct]

Just stepping through your listing comparing comments (yours has much more) and noted the following.

MOV A,R2 ;load index of matching command
ADD A,#0E4H ;offset to handler table
JMPP @A ;jump to command

A0E4 DB B3H ;
DB EDH ;cmd 21H (format)
DB EFH ;cmd 22H (format med)

When compared to mine.

MOV A,R2 ; 00e1 - fa get command number
ADD A,#0E4H ; 00e2 - 03 e4 add ofsett
JMPP @A ; 00e4 - b3 jump to routine this page
;jump address table for each command
DB 0EDH ; 00e5 - ed format
DB 0EFH ; 00e6 - ef format


Yours has an extra B3H where it shouldn't. The B3 is the JMPP @A instruction.

James

[phaeron]

Ah, thanks, fixed that. In case it isn't clear, this is based off of the disassembly that Simius posted above.

I've attached the latest version... it doesn't yet have the 2K bank snafu noted, but I did mostly comment the status command handler. At some point I need to go back and finish going through all the remaining little bits of voodoo that are scattered about.

Attached Files

•  xf551-rom.txt   91.9K   19 downloads

[sup8pdct]

One bit of voodoo i do know about is when 256 bytes are buffered (full dd sector), one byte is stored in T (timer) leaving R0 free for delay/pointer etc.

James