1050 ROMs

[+kheller2]

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

[dhinson919]

 

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.

[+kheller2]

 

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

[+Nezgar]

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.

[+kheller2]

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.

[1050]

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 address

of 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

[dhinson919]

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 address

of 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.

[+kheller2]

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.

[dhinson919]

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).

[1050]

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.

[+kheller2]

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.

[+kheller2]

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

[+kheller2]

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.

[1050]

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.

[+kheller2]

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)

[+Nezgar]

 

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.

[+kheller2]

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.

[+kheller2]

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]

[+Nezgar]

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

[+kheller2]

 

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.

[dhinson919]

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.

[dhinson919]

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

[+Nezgar]

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

[+kheller2]

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.

[+Nezgar]

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.