tregare Posted April 12, 2010 Share Posted April 12, 2010 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 Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 12, 2010 Share Posted April 12, 2010 Would IDA Pro be of any help? http://www.hex-rays.com/idapro/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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 12, 2010 Share Posted April 12, 2010 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-online.de/al/mcs-48/mcs-48.pdf Quote Link to comment Share on other sites More sharing options...
Simius Posted April 22, 2010 Share Posted April 22, 2010 Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address. xf551.txt Quote Link to comment Share on other sites More sharing options...
tregare Posted April 30, 2010 Author Share Posted April 30, 2010 Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address. Thank you! Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted August 14, 2010 Share Posted August 14, 2010 Here is proper XF551 firmware disassembly. All labels are valid and also contain a current address. Thank you! Bump How is this going? James Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted January 29, 2012 Share Posted January 29, 2012 Bump again. Any news? James Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 31, 2012 Share Posted January 31, 2012 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. xf551-rom.txt Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 1, 2012 Share Posted February 1, 2012 (edited) 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. xf551-rom.txt Edited February 1, 2012 by phaeron Quote Link to comment Share on other sites More sharing options...
+JAC! Posted February 1, 2012 Share Posted February 1, 2012 >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). Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted February 18, 2012 Share Posted February 18, 2012 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 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. Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted February 19, 2012 Share Posted February 19, 2012 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 19, 2012 Share Posted February 19, 2012 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. Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted February 19, 2012 Share Posted February 19, 2012 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 Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted February 21, 2012 Share Posted February 21, 2012 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 21, 2012 Share Posted February 21, 2012 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. xf551-rom.txt Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted February 21, 2012 Share Posted February 21, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
eightbitter Posted September 6, 2013 Share Posted September 6, 2013 Bump phaeron, have you any good news? Jerzy Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 7, 2013 Share Posted September 7, 2013 Er, no... were you expecting something? I haven't looked at the XF551 listing in a while since I got the answers I was looking for. Quote Link to comment Share on other sites More sharing options...
Defender II Posted January 24, 2015 Share Posted January 24, 2015 Has anyone recompiled the code with the errors mentioned fixed? I noticed someone noted a CSS version with something fixed. Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted March 13, 2015 Share Posted March 13, 2015 Has anyone recompiled the code with the errors mentioned fixed? I noticed someone noted a CSS version with something fixed. Not that i am aware of. The css version is very much upgraded tho it has a dongle for copy protection (single drive version). It can be easily bypassed however if you look in the right spot James Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted March 14, 2015 Share Posted March 14, 2015 Well, now that you know the Intel 8048, you should get yourself a Korg Polysix synthesizer, they used a multi-MCS48-microcontroller approach with the design of this synth. These synths were amazing sounding, and very controllable. You could probably add all sorts of new features, now that you know how to code for it. Check out the pages here, for a full technical look at it. Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted May 24, 2015 Share Posted May 24, 2015 Not that i am aware of. The css version is very much upgraded tho it has a dongle for copy protection (single drive version). It can be easily bypassed however if you look in the right spot James Do you have a version of that James? Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted December 24, 2021 Share Posted December 24, 2021 This is a bit of a necropost, but actually I did a pretty good disassembly of the XF551 only a year or so after that last post. Here it is in case anyone is interested. I set things up to diff the binary after assembly, so I know it's "correct" for the ROM I was working with. It has to do some crazy things trying to deal with 256-byte sectors in a CPU that only has 256 bytes of register memory plus the accumulator. Stuff like storing program state flags in unused I/O port bits. And yes, it screws up that subroutine call yet still manages to work. (I tried to upload it as plain text, but cloudflare had a shit fit thinking it saw an sql exploit somewhere. Fine, I'll zip it.) xf551.asm.zip 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.