810 and CHIP 810 (Archiver) code

[ebiguy]

I would like to share my work on the 810 disk drive and ask for your help to fill the holes.

 

This is a work in progress which started with the disassembly of the stock 810 rom code to understand how the floppy disk controller was used. But the next step is to understand how the CHIP 810 works, how to program it and how to use its extended (hidden ?) capabilities.
I always wanted to get a complete reference of the CHIP (Archiver) commands.
I could work on the Super Archiver 1050 but I started with the 810, assuming it would be easier to understand.
I finished disassembling and commenting the stock 810 rom code and I almost finished the same work on the CHIP 810 rom code.
Using this disassembly listing, a document can be written to explain all the details of the CHIP commands.
For those of you who only have a CHIP 1050 (Super Archiver), all the commands for the 810 are supported in the 1050 except one.
In this first post, I upload the disassembly of the 810 rom.
In future post, I am planning to publish the Archiver command reference and some sample codes using the Archiver commands.

Here is the source for the 810 rom (no CHIP here).

It can be assembled using MADS with a command line like : mads -o:Std810.bin Std810.asm

Std810.zip
You will find many comments throughout the source but I still have a few questions. This is where you can help me finish this work.
1) Do you understand thee meaning of the value $40 of LAUTOM (called AUT40 in the souce code) ? Is this bit really used (read and written) ?
2) Why is the 64T timer set when the drive head is moved (step/seek) near label LSTEPTRK ? It seems that the wait for the operation completion is achieved using loops.
3) Do you understand how is used the IRQ counter (variable LNBIRQ) ?
4) What are the tracks read after a format commands (near label LCPTSEC) ? It seems the check starts with track 39 by reading sectors in a specific order (commented in the source code). I am not sure of which tracks are then being read.
5) What is the purpose of reading the RIOT timer in the loop which checks for FDC DRQ before reading/writing data ? I don't see any previous timer initialization before.
6) Why is a seek command issued with $16 in the track register each time the motor is turned on (near label LMOTORON) ?

And a final 'legal' question: I could upload the CHIP 810 disassembly listing but I don't want to do it if it violates any copyright. Can someone tell me if I can do it safely or if I should keep the disassembly listing private. Or if I should contact the author or the current right owner (who ?) to have permission to do so ?

Thank you for your contribution !

[+Larry]

AFAIK, the Archiver and "Scan-It" rights are owned by Bruce Coslet (sp?) of B&C Computervisions. One clouded part -- not sure that his ownership includes the 810 versions, but I think so.

 

www.myatari.com

 

-Larry

[ijor]

This is a work in progress which started with the disassembly of the stock 810 rom code to understand how the floppy disk controller was used.

1) Do you understand thee meaning of the value $40 of LAUTOM (called AUT40 in the souce code) ? Is this bit really used (read and written) ?

2) Why is the 64T timer set when the drive head is moved (step/seek) near label LSTEPTRK ? It seems that the wait for the operation completion is achieved using loops.

3) Do you understand how is used the IRQ counter (variable LNBIRQ) ?

4) What are the tracks read after a format commands (near label LCPTSEC) ? It seems the check starts with track 39 by reading sectors in a specific order (commented in the source code). I am not sure of which tracks are then being read.

5) What is the purpose of reading the RIOT timer in the loop which checks for FDC DRQ before reading/writing data ? I don't see any previous timer initialization before.

6) Why is a seek command issued with $16 in the track register each time the motor is turned on (near label LMOTORON) ?

 

Don't we have the original commented source code of the 810 firmware? I seem to recall it was released by Atari, and included in some version of the 810 Field Service Manual ... anyway ...

 

2) No software loop. Timer is checked at your LWSTIM label.

3) I think it is the motor off timer.

4) Don't understand what you are asking?

5) Timer is initialized at the end of the LSETTRK sub.

6) I think it is not important.

[ijor]

AFAIK, the Archiver and "Scan-It" rights are owned by Bruce Coslet (sp?) of B&C Computervisions.

 

Are you sure? I always had the impression that the rights for the original Archiver and CHIP are (were) in some kind of limbo ...

 

The original copyright holder was Spartan software. Which I understand it closed down, or went bankrupt? I don't know exactly what was the situation of Mike Gustafson, the actual author of the software and the firmware. Was he an employee at Spartan, or one of the owners as he was at ICD?

 

If you check the Super Archiver and Scan-It software, by CSS, they included the original Archiver software. The SA menu selects among which Archiver (or Super Archiver) to load. Some versions of this menu mention Mike Gustafson as the copyright holder for the original versions, some don't. But CSS, AFAIK, never claimed copyright for the original version, neither for the CHIP firmware.

 

I read this as CSS knew nobody would bother nor complain (because Spartan closed down). May be they asked for some kind of informal permission from Mike, may be not. It certainly doesn't look like they bought the rights or received formal permission (they would have mentioned if they did).

 

Bruce from B&C sound like a similar situation. I don't think he claims any kind of rights. When you buy his Archiver reproduction, you don't get any notice as he has the rights, do you?

 

It is possible (any lawyer here?) that the rights, originally owned by the employer, returned to Mike, the original author.

[ebiguy]

 

Don't we have the original commented source code of the 810 firmware? I seem to recall it was released by Atari, and included in some version of the 810 Field Service Manual ... anyway ...

 

2) No software loop. Timer is checked at your LWSTIM label.

3) I think it is the motor off timer.

4) Don't understand what you are asking?

5) Timer is initialized at the end of the LSETTRK sub.

6) I think it is not important.

 

Thank you very much, Ijor, for answering my questions.

 

I did not know the existence of the source code of the 810 firmware.

I only have the scan of the field service manual which does not contain the source code.

Do you mean it was given on diskette along with the manual, or printed in the manual ?

 

For the question number 4, I mean that after the format of track 0 to 39 the firmware starts reading sectors on the last track. I don't know if the head is moved to read sectors on another track. Does the firmware consider that the diskette is OK if the sectors of the track 39 are OK ?

[+Larry]

Hi Ijor-

 

No, as with many of the questions about rights through transfers of ownership, it is difficult to be sure. But, in a conversation with Bruce some years ago, he specifically said that he had purchased the rights to the Archiver stuff. CSS was licensed to produce the Super Archiver.

 

Safest thing is to ask Bruce if he does claim ownership (etc.), and if so, does he mind if a disassembly is posted.

 

-Larry

[ijor]

 

I did not know the existence of the source code of the 810 firmware.

I only have the scan of the field service manual which does not contain the source code.

Do you mean it was given on diskette along with the manual, or printed in the manual ?

 

For the question number 4, I mean that after the format of track 0 to 39 the firmware starts reading sectors on the last track. I don't know if the head is moved to read sectors on another track. Does the firmware consider that the diskette is OK if the sectors of the track 39 are OK ?

 

I don't remember exactly how the 810 source code was released and I can't find it right now. I seem to remember it was included with the FSM, as some kind of addendum? I know that the available scans don't include it, but possibly it is just missing from that scan.

 

All tracks are verified, every single sector on the disk is tested.

[ebiguy]

A little quiz for the programmers reading the 810 disassembly...

 

1) First, an easy question

The 810 has an undocumented command. Did you find it in the source code ?

 

2) Second, a more difficult question

There is a kind of protection in the source code. Well, sort of...

I am talking about an ugly programming trick that would make the code buggy as soon as you try to disassemble, modify and reassemble it.

Did you find that in the source code ?

 

I will give you both solutions in a couple of days but with all the 6502 experts out there, I guess it won't be necessary.

[Rybags]

With only a short look:

1. Couldn't find it but isn't there a Diag command like 1050 has?

 

2. I don't quite get it. It's easy to have binary code that won't disassemble properly since there's no way to know absolutely where data, code, null sections begin and end. The only sure thing is that there should be valid code pointed to by the Reset vector. On 6507, no NMI so no point populating that vector, same with external IRQs but you'd need that vector populated to handle BRK.

[ebiguy]

With only a short look:

1. Couldn't find it but isn't there a Diag command like 1050 has?

 

2. I don't quite get it. It's easy to have binary code that won't disassemble properly since there's no way to know absolutely where data, code, null sections begin and end. The only sure thing is that there should be valid code pointed to by the Reset vector. On 6507, no NMI so no point populating that vector, same with external IRQs but you'd need that vector populated to handle BRK.

 

Thanx for "playing". I give you some hints

 

1. No diag in the 810 rom code.

Hint : Look at the code which checks which command has been received

 

2. The code I disassembled has all the labels instead of addresses as if it was the real source code and it can be modified safely. Of course, it should still be 2048 byte long with the 2 vectors at the end of the rom. But even in this case, a modification near the beginning of the code will prevent the rom from working well.

Hint : did you find something strange when browsing the code (without trying to understand all details) ? There is some code that you would not write this way. If I say more, I give you the solution...

Edited June 14, 2016 by ebiguy

[AtariGeezer]

 

Thanx for "playing". I give you some hints

 

1. No diag in the 810 rom code.

Hint : Look at the code which checks which command has been received

 

2. The code I disassembled has all the labels instead of addresses as if it was the real source code and it can be modified safely. Of course, it should still be 2048 byte long with the 2 vectors at the end of the rom. But even in this case, a modification near the beginning of the code will prevent the rom from working well.

Hint : did you find something strange when browsing the code (without trying to understand all details) ? There is some code that you would not write this way. If I say more, I give you the solution...

2). Do you mean the BIT $2C opcode?

[flashjazzcat]

Command $4F (write PERCOM block) jumps to the same address as write with verify (because the command code lets command $4F through then jumps on the lower 3 bits).

 

The only unusual code I noticed is:

 

LDA (LSECPTR+1,X)

 

i.e. use of indexed indirect. Too lazy to figure out if the tables are easily broken.

[ebiguy]

Command $4F (write PERCOM block) jumps to the same address as write with verify (because the command code lets command $4F through then jumps on the lower 3 bits).

 

The only unusual code I noticed is:

 

LDA (LSECPTR+1,X)

 

i.e. use of indexed indirect. Too lazy to figure out if the tables are easily broken.

 

Hi Jon,

 

Very good for the first point. You are right. The $4F is the same as the $57 : Write with verify. But I guess nobody used this "bug/feature" in his program as it was not documented

 

For the second point, you are very very close as you found the vector that is tricky (but not because of this addressing mode).

Another hint: Find the use of spare bytes in the code...

[flashjazzcat]

OK. Bytes from the sector list are stored immediately after LSECPTR, and since the byte is loaded from LSECPTR+1 (plus X), I guess it relies on $FFFF wraparound because of the X register?

[ebiguy]

OK. Bytes from the sector list are stored immediately after LSECPTR, and since the byte is loaded from LSECPTR+1 (plus X), I guess it relies on $FFFF wraparound because of the X register?

 

This is a boundary trick. I show you the code :

 

lda #AUTTRK0

jmp LOVERTBL

;

:25 .byte 0

;

LFMTTAB ; $086E

.byte $00,$FE,$FC,$FA

.byte $F8,$F6,$F4,$F2

.byte $F0,$EE,$FD,$FB

.byte $F9,$F7,$F5,$F3

.byte $F1,$EF

;

LOVERTBL ; $0880

jsr LORAUT

 

The strange thing in this code is that you have a table (inverted sector numbers used to format a track) which sits in the middle of the code.

So a Jmp is needed to get over it. That is quite unusual. And what is the use of these 25 spare bytes ? The answer is in the code using this table :

 

LSKIPSTP

lda #<LFMTTAB

sta LSECPTR

lda #>LFMTTAB

sta LSECPTR+1

;

LNXTSEC

;

<some code to write sector ID and sector DATA in the track>

;

inc LSECPTR

bmi LLASTSEC

;

jmp LNXTSEC

;

LLASTSEC

rts

 

You can see that the way to get out of the loop is highly dependent of the fact that the table (LFMTTAB) is just below $880 so that the low byte goes from $6E to $80.

When it becomes negative, it means the end of the table has been reached.

 

The problem in the disassembly is the way the padding is done - with a static number of bytes (:25)

Is there a way using MADS syntax to change this line to compute dynamically the number of bytes so that the table always fits before the next $xx80 ?

Of course, the objective is to keep the output bytecode untouched once assembled.

[Rybags]

I'm not sure you can tuck a table hard up against the "next $80 boundary".

 

Doing alignment to start on a certain boundary is usually easy with most assemblers. But basing location counter on length of a block of code/data before it's assembled can sometimes be tricky since you need the length before it's a known quantity.

Possibly some sort of kludge where it's in a macro then the value is generated. Assemble first to an area that will be overwritten to get the length, then use it later as basis of an ORG directive.

 

Or... doesn't MADs have some sort of DSECT (Dummy section) ability? As in you can assemble a block of code such that no object is created but the labels and such resolve to locations and lengths.

Edited June 15, 2016 by Rybags

[ijor]

Is there a way using MADS syntax to change this line to compute dynamically the number of bytes so that the table always fits before the next $xx80 ?

Of course, the objective is to keep the output bytecode untouched once assembled.

 

 

I'm not familiar with MADS, but I wouldn't bother. Some assembler do support some kind of alignment, but only beyond (after) the point of the alignment directive. Here you want padding to be added before the point of the alignment.

 

Again, even when some multi pass tricks might be possible, I wouldn't bother. Just leave the original code like it is, with a static precomputed value. For the cases that you or somebody else would like to modify the ROM, then provide an alternate code that doesn't depend on this padding.

 

Please note that there are multiple original Atari versions of the 810 ROM. I think yours is the earliest one.

[flashjazzcat]

You can see that the way to get out of the loop is highly dependent of the fact that the table (LFMTTAB) is just below $880 so that the low byte goes from $6E to $80.

When it becomes negative, it means the end of the table has been reached.

Ah - got it now. I was really distracted by that (ZP,X) addressing mode. I mean, I know how it works, but it still makes my brains overheat.

 

Thanks for the explanation!

 

The problem in the disassembly is the way the padding is done - with a static number of bytes (:25)

Is there a way using MADS syntax to change this line to compute dynamically the number of bytes so that the table always fits before the next $xx80 ?

Of course, the objective is to keep the output bytecode untouched once assembled.

.ALIGN address,fill would probably be the way to proceed here:

 

;
           JMP LOVERTBL
;
; Spare bytes never addressed
;
	.align $086E,$00
;
; 18 inverted sector numbers
;
LFMTTAB    .BYTE $00,$FE,$FC,$FA
           .BYTE $F8,$F6,$F4,$F2
           .BYTE $F0,$EE,$FD,$FB
           .BYTE $F9,$F7,$F5,$F3
           .BYTE $F1,$EF

You could add some macros to check for overshooting of the address, or even to work things so that they align to the nearest half-page boundary (I thought ALIGN could do nearest page alignment inherently, but I forget how).

 

 

I'm not sure you can tuck a table hard up against the "next $80 boundary".

Knowing the size of the table in advance definitely simplifies matters, but since MADS is a multi-pass assembler, I guess you can align on the fly. I've got one project which uses inter-bank JSR macros which expand differently depending on whether the target is in the same bank as the JSR call. Of course the assembler requires one pass to figure out the target banks, and then all the equates will change again on the second pass depending on how the macros expand, forcing another pass to fix up forward references.

 

This works:

;
	JMP LOVERTBL
;
; Spare bytes never addressed
;
	.align $0880-[.len[LFMTTAB]],$00
;
; 18 inverted sector numbers
;
.local LFMTTAB
	.BYTE $00,$FE,$FC,$FA
	.BYTE $F8,$F6,$F4,$F2
	.BYTE $F0,$EE,$FD,$FB
	.BYTE $F9,$F7,$F5,$F3
	.BYTE $F1,$EF
.endl

With a little help from a macro, I guess this could be adapted to simply align the end of the table to the nearest $xx80.

Edited June 15, 2016 by flashjazzcat

[ebiguy]

Thank you very much to all of you.

 

@ijor : could you PM or drop here other 810 ROM versions ? I would be very interested in disassembling them. It will be very easy now that I have finished the first one. We could then compare what fixes have been applied in each version. I will also upload the new version of this disassembly now that I have updated comments with your answers to my first questions.

 

@flashjazzcat : I will try .align as soon as I come back home.

 

EDIT: I finally choose this version of the line which works in every page

 

.align [*&$0F00]+$80-[LOVERTBL-LFMTTAB],$00

PS: no need for a macro to check for overshooting as you won't end up with a 2Kb rom !

 

Thank you for your help !

Edited June 15, 2016 by ebiguy