+kheller2 Posted October 1, 2018 Share Posted October 1, 2018 What binary/src are you using for the FLOPOS? There was a cleaned/fixed version by candle. ; ATARI 1050 DISK DRIVE OPERATING SYSTEM ; ; based on listings of Michael Pascher (Abbuc-Buch) ; and W. Derks ; ; mads conversion by Candle'O'Sin ; few "bugfixes" were made - now it compiles into 1050 ROM ver B - original version by Michael Pascher and W. Dereks did not work with my drive ; hope it helps someone Quote Link to comment Share on other sites More sharing options...
dhinson919 Posted October 1, 2018 Share Posted October 1, 2018 What binary/src are you using for the FLOPOS? There was a cleaned/fixed version by candle. ; ATARI 1050 DISK DRIVE OPERATING SYSTEM ; ; based on listings of Michael Pascher (Abbuc-Buch) ; and W. Derks ; ; mads conversion by Candle'O'Sin ; few "bugfixes" were made - now it compiles into 1050 ROM ver B - original version by Michael Pascher and W. Dereks did not work with my drive ; hope it helps someone I'm using the FLOPOS.ROM found at one of the common sources (don't remember which). I can't vouch for its authenticity but the MD5 is in the diff text. If your .ROM has a different digest then if you post it I can diff it too. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 1, 2018 Share Posted October 1, 2018 I'm using the FLOPOS.ROM found at one of the common sources (don't remember which). I can't vouch for its authenticity but the MD5 is in the diff text. If your .ROM has a different digest then if you post it I can diff it too. All of my copies, including the compiled one I just did are 5acf59fff75d36a079771b34d7c7d349 flops.obx flops.asm Modified for 2797, not tested, checksum could be wrong, and I could be messing this all up flopsL.obx flopsL.asm 1 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted October 1, 2018 Share Posted October 1, 2018 Modified for 2797, not tested, checksum could be wrong, and I could be messing this all up flopsL.obx flopsL.asm At least one of my drives has a 2797, I will try to find it and test this. Next minor change could be to speed up the stepper timings like Speedy, and the 'not recommended' USDoubler ROM hack uses. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 2, 2018 Share Posted October 2, 2018 At least one of my drives has a 2797, I will try to find it and test this. Next minor change could be to speed up the stepper timings like Speedy, and the 'not recommended' USDoubler ROM hack uses. I don't think I have the ROM checksum correct. I need to look into where that is computed. Quote Link to comment Share on other sites More sharing options...
1050 Posted October 3, 2018 Share Posted October 3, 2018 PAGE 4 ATARI 1050 DISK DRIVE OS D8:FLOPOS1.M65 F07A 2091F1 2130 JSR DELAY1 ; wait another time F07D AD0004 2140 LDA FCNTRL F080 2901 2150 AND #1 ; now it must by ok F082 D019 2160 BNE FAIL ; otherwise it't wrong F084 A9F0 2170 LDA #$F0 ; get checksum of PROM F086 8501 2180 STA SEKBUF+1 ; start address F088 A900 2190 LDA #0 F08A 8500 2200 STA SEKBUF F08C 18 2210 CLC F08D A8 2220 TAY F08E 2230 PCHECK F08E 7100 2240 ADC (SEKBUF),Y ; add PROM bytes F090 C8 2250 INY F091 D0FB 2260 BNE PCHECK F093 E601 2270 INC SEKBUF+1 ; next page F095 D0F7 2280 BNE PCHECK F097 0900 2290 ORA #0 ; result must be zero F099 8500 2300 STA SEKBUF F09B F001 2310 BEQ TSTOK ; if so, everything is fine 2320 ; 2330 ; fatal error, break 2340 ; F09D 2350 FAIL F09D 00 2360 BRK ; hardware defect 2370 ; 2380 ; hardware test ok, do RAM test 2390 ; F09E 2400 TSTOK F09E A200 2410 LDX #0 ; write to RAM F0A0 2420 RAMTST F0A0 8A 2430 TXA F0A1 9500 2440 STA SEKBUF,X F0A3 E8 2450 INX F0A4 D0FA 2460 BNE RAMTST OS ROM test begins at line 2170 with actual rom addressof 0xF084. But the 8 bit checksum of the FLOPOS.ROM project is 0xF1 and will fail this test for zero checksum. Maybe it's defeated and made irrelevant in this manner? Maybe I don't understand? I did 8 bit checksum on the roms posted in #13 and none of them are zero checksum either so I don't think this section of code could ever work as designed... So they all pile up on the BRK instruction at line 2360? I am to understand that we have a bug with the BRK instruction, it does not operate as designed is about all I've been able to gather despite reading about it a lot. http://atariage.com/forums/topic/273221-dd-disc-track-structure-kryoflux-image/?do=findComment&comment=3917681 Quote Link to comment Share on other sites More sharing options...
dhinson919 Posted October 4, 2018 Share Posted October 4, 2018 PAGE 4 ATARI 1050 DISK DRIVE OS D8:FLOPOS1.M65 F07A 2091F1 2130 JSR DELAY1 ; wait another time F07D AD0004 2140 LDA FCNTRL F080 2901 2150 AND #1 ; now it must by ok F082 D019 2160 BNE FAIL ; otherwise it't wrong F084 A9F0 2170 LDA #$F0 ; get checksum of PROM F086 8501 2180 STA SEKBUF+1 ; start address F088 A900 2190 LDA #0 F08A 8500 2200 STA SEKBUF F08C 18 2210 CLC F08D A8 2220 TAY F08E 2230 PCHECK F08E 7100 2240 ADC (SEKBUF),Y ; add PROM bytes F090 C8 2250 INY F091 D0FB 2260 BNE PCHECK F093 E601 2270 INC SEKBUF+1 ; next page F095 D0F7 2280 BNE PCHECK F097 0900 2290 ORA #0 ; result must be zero F099 8500 2300 STA SEKBUF F09B F001 2310 BEQ TSTOK ; if so, everything is fine 2320 ; 2330 ; fatal error, break 2340 ; F09D 2350 FAIL F09D 00 2360 BRK ; hardware defect 2370 ; 2380 ; hardware test ok, do RAM test 2390 ; F09E 2400 TSTOK F09E A200 2410 LDX #0 ; write to RAM F0A0 2420 RAMTST F0A0 8A 2430 TXA F0A1 9500 2440 STA SEKBUF,X F0A3 E8 2450 INX F0A4 D0FA 2460 BNE RAMTST OS ROM test begins at line 2170 with actual rom addressof 0xF084. But the 8 bit checksum of the FLOPOS.ROM project is 0xF1 and will fail this test for zero checksum. Maybe it's defeated and made irrelevant in this manner? Maybe I don't understand? I did 8 bit checksum on the roms posted in #13 and none of them are zero checksum either so I don't think this section of code could ever work as designed... So they all pile up on the BRK instruction at line 2360? I am to understand that we have a bug with the BRK instruction, it does not operate as designed is about all I've been able to gather despite reading about it a lot. http://atariage.com/forums/topic/273221-dd-disc-track-structure-kryoflux-image/?do=findComment&comment=3917681 This has puzzled me as well. It seems none of the roms should pass this test based on the checksums I've calculated yet they all appear to do it. I figured either I was not calculating them correctly for some reason or this simple bit of code is being deviously crafty by exploiting some microcode weirdness. A clue might be why ORA is used instead of CMP since only the Z flag is tested, and why the STA SEKBUF at F099 since that location doesn't appear to be modified since it is zeroed at F08A. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 4, 2018 Share Posted October 4, 2018 Yes, I was wondering the same thing that maybe I'm just missing some obscure thing with the way the CPU in the 1050 works. For those following along, I spent a good portion of this morning trying to figure out the differences between Candle's MADS source code I'm using: http://atariage.com/forums/topic/158129-1050e-and-icd-us-doubler/?p=1942848 and the the actual binary files sitting on ftp.pigwa.net (FLOPOS.ROM) and the binary sitting the DISASM.ZIP file (FLOPOS.COM). COM has 68 more bytes (After stripping the header) and looks very different from ROM. MD5 (FLOPOS.ROM) = ad4b6ec7de5f3fe165df02d832e31be4 Now, this file when compared to RevK (aka B in the text files) does have changes in areas of the code. Specifically the ones Candle called out in the above post. The one line I'm looking at is "AND #$F7 ; motor on" vs "0590 AND #$7F motor on" in the original sources at pigwa. Long story short... if you use Candle's MADS code you will compile an exact copy of K (or L after a few changes). This is not what the src on Pigwa compiles into (I haven't compiled that yet) and this is nothing at all like the FLOPOS.COM in the DISASM zip file. So the upshot of all of this is we can compile exact copies of Atari's ROM's with all the bugs... the downside is, I have no idea what Pascher/Derks "fixed" nor have a mads version of that. Quote Link to comment Share on other sites More sharing options...
dhinson919 Posted October 5, 2018 Share Posted October 5, 2018 Yes, I was wondering the same thing that maybe I'm just missing some obscure thing with the way the CPU in the 1050 works. For those following along, I spent a good portion of this morning trying to figure out the differences between Candle's MADS source code I'm using: http://atariage.com/forums/topic/158129-1050e-and-icd-us-doubler/?p=1942848 and the the actual binary files sitting on ftp.pigwa.net (FLOPOS.ROM) and the binary sitting the DISASM.ZIP file (FLOPOS.COM). COM has 68 more bytes (After stripping the header) and looks very different from ROM. MD5 (FLOPOS.ROM) = ad4b6ec7de5f3fe165df02d832e31be4 Now, this file when compared to RevK (aka B in the text files) does have changes in areas of the code. Specifically the ones Candle called out in the above post. The one line I'm looking at is "AND #$F7 ; motor on" vs "0590 AND #$7F motor on" in the original sources at pigwa. Long story short... if you use Candle's MADS code you will compile an exact copy of K (or L after a few changes). This is not what the src on Pigwa compiles into (I haven't compiled that yet) and this is nothing at all like the FLOPOS.COM in the DISASM zip file. So the upshot of all of this is we can compile exact copies of Atari's ROM's with all the bugs... the downside is, I have no idea what Pascher/Derks "fixed" nor have a mads version of that. I believe I got my copy of FLOPOS source from atari.fox-1.nl, although it appears to be offline at this time. When I compare that source to the diff between FLOPOS.ROM which I got from somewhere else and revK the differences match the source. But I have not compared all lines of that source to the disassembly of the ROM. I do think the Pascher/Derks "fix" at line 0590 AND #$7F is not correct. Port A bit 3 is identified as the "motor off" bit in the top comments and is used that way within the subroutine MOTOFF. That is also how the revK code uses it (AND #$F7). Quote Link to comment Share on other sites More sharing options...
1050 Posted October 5, 2018 Share Posted October 5, 2018 I'm with Candle's take on the AND #$7F deal, it must be a typo for AND #$F7. But why did they think that needed changing? Mysterious. Other fixes may or may not be worthy as well? And I've never tried the FLOPOS.ROM file in a real 1050 - it may not work at all. Just as Candle states. The last 5 of the 9 fixes are wrong move at wrong time deals. Team Pascher/Derks must have been burnt out to a slightly crispy level at that point? They did a brilliant job of commenting somebody else's code. What we do know is that the Atari code works, so somehow the BRK command must be falling thru and has no effect for setting an ERROR condition as it is used for in many other places within this code. Because of the wasted floundering about in post #56 there is room for a real jump to busy light flashing routine, along with checksum corrector byte for a zero checksum result too. Interesting possibilities exist to learn a bit more about the BRK bug among other twists. For kheller2 and others here is a mads version of Pascher/Derks version of FLOPOS made from Candle's K version file. Changes from K version will be found by searching for ;** comments made by me to note the 9 changes from K version. I don't use mads so it's a shot in the dark from here. Good luck with it. flopos_asm.zip Don't forget kheller2, mac/65 will use file segments always and the output then must always be stripped of those - say 68 extra bytes worth? First clue is the first header, it should be FF FF 00 F0 FF FF and if it isn't that then there are extra segments within the file. 1 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 6, 2018 Share Posted October 6, 2018 Thanks for the new asm file. I'll integrate these back into the mads source I'm using. Right now the code i'm working with compiles directly into L and has a few more notes added. After integration, we'll have two versions L and L w/fixes. 2 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 6, 2018 Share Posted October 6, 2018 Some typos in the comments for the 9 revisions: 480: STA STATUS ;** was STA ERROR in K version 516: JSR DELAY1 ; 20 ms delay after SEEK ;** was JMP DELAY1 in K verison -> should be "version" 526: LDA #0 ;** was LDA #1 in K version 1127:RSTAT JSR FORCE ; stop controller ;** was JSR DFORCE in K version 1756: INC SBUF+1 ;** was INC SBUF in K version 1757: DEC SBUF ;** was INC SBUF+1 in K version -> should be "DEC SBUF+1" 1786: INC SBUF+1 ;** was INC SBUF in K version 1787: DEC SBUF ;** was INC SBUF+1 in K version -> should be "DEC SBUF+1" 2236: AND #$7F ; motor on ;** was AND #$F7 in K version Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 8, 2018 Share Posted October 8, 2018 I'm tired this morning, so I have a code question that is eluding me.. ; ; force IRQ, interrupt floppy command ; DFORCE JSR FORCE ; two times force IRQ FORCE LDA #$D0 STA FCNTRL ; command force IRQ LDX #7 ; short delay FORC1 DEX BNE FORC1 LDA #0 ;** was LDA #1 in K version FORC2 BIT FCNTRL ; wait until BNE FORC2 ; controller ready RTS Why would you change the LDA to 0 instead of 1. If I'm reading this BIT FCNTRL correctly for the FORC2 loop: AND the FDC status register with 0 (also copy bits 7 and 6 from FCNTRL into N and V flags) set Z to 1 if result is 0. Isn't 0 AND anything going to be 0 so basically this does nothing. If LDA #1, and the 2797 status register was all zero's then drop out of the loop... but then I get confused with the status register because TRACK00 and Write Protect could be status 1 and then we would never leave this loop. But Busy is only bit 0, so if FCNTRL is 01010101 (random stuff, but bit 0 busy is 1) and Busy is high, then 1 and 1 would be 1 and we would wait until busy went to 0. Quote Link to comment Share on other sites More sharing options...
1050 Posted October 8, 2018 Share Posted October 8, 2018 Ok, we now know I can't spell so good on the fly and my cut and paste technique only worked for the first line of those changes. I concur with post #63, AND with 0 will not work as wait for busy bit to zero itself, it will always fall thru with no waiting. Pascher/Derks were wrong to change this one too. I can't imagine why they would do that. Unless as I've stated before they were just fried to a frazzle after the exhaustive work already done in commenting the code so fully. Just for double checking some of these operations I came across this and found it quite nice to have examples from which to see the logic of it. Back in the hectic days I would just fire up BUG/65 type in a bit of assembler and step thru it for conformation of bitwise operations. https://en.wikipedia.org/wiki/Bitwise_operation I didn't double check the INC VS DEC part of my added comments and I had only nine to do right. As it is I corrected a lot - amazed I was still so wrong there. 3 out of 9 wrong is a failing grade if this were grade school. I am sadly beginning to suspect that none of the Pascher/Derks fixes are valid at all as I see no fire that needed putting out, the fixes seem not so needed or outright wrong as the third and last 5 of them clearly are wrong so far. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 8, 2018 Share Posted October 8, 2018 I'm actually suspecting that the ROM they dumped might have been faulty at this point. I went and looked at some of the "Raw" disassembled code and found some mistakes in there.. so either the disassembler was flawed, the PROM was flawed or I don't have a copy of the original original original work they did. The earliest files I have are dated in 1998 I believe, that's great for the Internet time wise, but pretty poor if this work was done a decade earlier. I'll continue to make notes as I go through the code and see what Pascher/Derks did and try to understand. I'm getting more interested in see what changes were done from J to K. Known versions: E or F (1700 Units) to be replaced by J. K (mucho fixes?), L (2797 support) 1 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted October 8, 2018 Share Posted October 8, 2018 I'm getting more interested in see what changes were done from J to K. Known versions: E or F (1700 Units) to be replaced by J. K (mucho fixes?), L (2797 support) I'm working on getting a good dump of DavidMil's what appears to be rev H. (he's sending me the eprom) E & F are mentioned in a 1050 service manual technote, which claims eE & F failed some copy protection checks on the 1050 in some software as it reported different errors compared to the 810. Would be interesting if analysis of the H code is consistent with this description. I'm not sure what changed from J to K. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 8, 2018 Share Posted October 8, 2018 I'm working on getting a good dump of DavidMil's what appears to be rev H. (he's sending me the eprom) E & F are mentioned in a 1050 service manual technote, which claims eE & F failed some copy protection checks on the 1050 in some software as it reported different errors compared to the 810. Would be interesting if analysis of the H code is consistent with this description. I'm not sure what changed from J to K. H? H?!? Wonder where that came from. Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 8, 2018 Share Posted October 8, 2018 Ok, so after building some silly tables in Excel I'm 100% convinced of the following: STA STATUS ;** was STA ERROR in K version [Hmm, maybe this is right.. but.. need to validate] JSR DELAY1 ; 20 ms delay after SEEK ;** was JMP DELAY1 in K version [Hmm.. maybe this is right] LDA #0 ;** was LDA #1 in K version [Wrong, see above post] RSTAT JSR FORCE ; stop controller ;** was JSR DFORCE in K version [Double vs single force, wonder if there was a reason for that] INC SBUF+1 ;** was INC SBUF in K version [Read routine test, VERY VERY wrong, You stored track 39 in SBUF+1, how you gonna INC that?!?] DEC SBUF ;** was DEC SBUF+1 in K version [Read routine test, VERY VERY wrong, You stored track 0 in SBUF, how you gonna DEC that?] INC SBUF+1 ;** was INC SBUF in K version [Write routine test, wrong, just a copy of the above wrongness] DEC SBUF ;** was DEC SBUF+1 in K version [wrong] AND #$7F ; motor on ;** was AND #$F7 in K version [We all agree this is wrong] Quote Link to comment Share on other sites More sharing options...
Nezgar Posted October 8, 2018 Share Posted October 8, 2018 H? H?!? Wonder where that came from. I know, right? DavidMil's initial dump of it: http://atariage.com/forums/topic/275166-one-last-eprom/?p=3960139 The first byte is corrupt, but the rest may be intact. Here's my previous post looking at the diffs compared to rev J. http://atariage.com/forums/topic/275166-one-last-eprom/?p=4118950 Maybe you can discern the actual functional difference? Pictures of the prototype-looking 1050 PCB it came from: http://atariage.com/forums/topic/275166-one-last-eprom/?p=3959877 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 9, 2018 Share Posted October 9, 2018 I know, right? DavidMil's initial dump of it: http://atariage.com/forums/topic/275166-one-last-eprom/?p=3960139 The first byte is corrupt, but the rest may be intact. Here's my previous post looking at the diffs compared to rev J. http://atariage.com/forums/topic/275166-one-last-eprom/?p=4118950 Maybe you can discern the actual functional difference? Pictures of the prototype-looking 1050 PCB it came from: http://atariage.com/forums/topic/275166-one-last-eprom/?p=3959877 I'm just starting to look at J code. At first I thought there were major differences between J and K, but while there are several differences, the big one is a few routines just moved around (I think someone had mentioned that before to me). I THINK the differences in H, J and K you were asking about are in this routine: read serial byte.... K rev... W32B1 DEX ; to get first bit in the middle BNE W32B1 NOP NOP NOP BIT DRB ; bit 1 or 0? BVC BIT1 CLC ; got a zero BCC NXTBIT In J they are D0 FD 46 B6 2C 82 02, H is D0 FD EA EA 2C 82 02 .... in K they are D0 FD EA EA EA 2C 82 02 ... I haven't looked into what the exact differences are to the 6507. Quote Link to comment Share on other sites More sharing options...
dhinson919 Posted October 9, 2018 Share Posted October 9, 2018 I'm tired this morning, so I have a code question that is eluding me.. ; ; force IRQ, interrupt floppy command ; DFORCE JSR FORCE ; two times force IRQ FORCE LDA #$D0 STA FCNTRL ; command force IRQ LDX #7 ; short delay FORC1 DEX BNE FORC1 LDA #0 ;** was LDA #1 in K version FORC2 BIT FCNTRL ; wait until BNE FORC2 ; controller ready RTS Why would you change the LDA to 0 instead of 1. If I'm reading this BIT FCNTRL correctly for the FORC2 loop: AND the FDC status register with 0 (also copy bits 7 and 6 from FCNTRL into N and V flags) set Z to 1 if result is 0. Isn't 0 AND anything going to be 0 so basically this does nothing. If LDA #1, and the 2797 status register was all zero's then drop out of the loop... but then I get confused with the status register because TRACK00 and Write Protect could be status 1 and then we would never leave this loop. But Busy is only bit 0, so if FCNTRL is 01010101 (random stuff, but bit 0 busy is 1) and Busy is high, then 1 and 1 would be 1 and we would wait until busy went to 0. LDA should be #1 for the reason you say. When the $D0 ("soft" interrupt) command is issued bit 0 of the command/status register must be tested until it's clear before another command can be accepted. Maybe P&D incorrectly thought A contained the number of the bit to test. Quote Link to comment Share on other sites More sharing options...
dhinson919 Posted October 9, 2018 Share Posted October 9, 2018 I'm just starting to look at J code. At first I thought there were major differences between J and K, but while there are several differences, the big one is a few routines just moved around (I think someone had mentioned that before to me). I THINK the differences in H, J and K you were asking about are in this routine: read serial byte.... K rev... W32B1 DEX ; to get first bit in the middle BNE W32B1 NOP NOP NOP BIT DRB ; bit 1 or 0? BVC BIT1 CLC ; got a zero BCC NXTBIT In J they are D0 FD 46 B6 2C 82 02, H is D0 FD EA EA 2C 82 02 .... in K they are D0 FD EA EA EA 2C 82 02 ... I haven't looked into what the exact differences are to the 6507. I've been working on a tool to help reverse-engineer 6502 roms. It's a long way from being finished but it can produce a code/data segments report that can help with this sort of thing. Attached are reports for the J, K and L revisions. There's an attempt to identify each separate segment of code or data based on a few heuristics and then each one is fingerprinted to help identify code that's common to multiple sets. It also attempts to recognize "dark code" segments that may be unused or called by non-standard means. 1050-revJ.rom.seg.txt 1050-revK.rom.seg.txt 1050-revL.rom.seg.txt 1 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted October 9, 2018 Share Posted October 9, 2018 Fixed the bad first byte from DavidMil's dump (it's consistent across J, K, L) , burned it to an EPROM, and it seems to work just dandy in a real 1050 with 2793 controller. Booted a few disks, formatted one in ED, and it passed the simple tests on the 1050 diag disk. Didn't try anything heavily copy protected yet. Attached! 1050-revH 6D9D589B.BIN Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 9, 2018 Share Posted October 9, 2018 Fixed the bad first byte from DavidMil's dump (it's consistent across J, K, L) , burned it to an EPROM, and it seems to work just dandy in a real 1050 with 2793 controller. Booted a few disks, formatted one in ED, and it passed the simple tests on the 1050 diag disk. Didn't try anything heavily copy protected yet. Attached! Is this a new copy of the eprom with the first byte fixed, or just a patch to the already dumped version? I want to make sure I don't start any heavy work on something that might be changing later. Quote Link to comment Share on other sites More sharing options...
Nezgar Posted October 9, 2018 Share Posted October 9, 2018 Correct, I only patched the first byte of the first dump. Will be a week or 2 before I receive it to verify it for sure. Quote Link to comment Share on other sites More sharing options...
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.