dwl10@amdahl.uts.amdahl.com (Dave Lowrey) (03/15/88)
I have a question regarding 1541 programming. I have been studying the ROM
listings, and examples of programming the 1541 yourself, and have come
upon an interesting bit of code that I don't fully understand.
The scenerio is that we are in "Executed" code (JOB code 0xe0), and have
JSR'ed to a subroutine that finds a header for a specific sector.
Upon return from the subroutine, the following code is executed:
(Note...addresses are not actual addresses from the ROM)
c100 CLV
c101 BVC $c101
..
..
..
I assume that the disk controller interrupts the 6502 when "something"
happens, and the IRQ/NMI interrupt handeler sets the Overflow flag, so
our "endless" loop ends.
My question is: exactly why/when is the oveflow flag set, and who is
setting it?
There are several occurances of this code in the ROM. I also have
sample programs from a book that do this, with the comments such as
"Wait for header" and "wait for data". I would like specific info
on what is happening here.
Thanks.....
--
-------------------------------------------------------------------
"Familiarity breeds attempt"
Dave Lowrey
Amdahl Corp.
Houston, Texas
(713)-850-8828
...!{ihnp4,cbosgd,hplabs,oliveb}!amdahl!dwl10
[ The opinions expressed <may> be those of the author and not necessarily
those of his most eminent employer. ]erd@tut.cis.ohio-state.edu (Ethan R. Dicks) (03/15/88)
In article <24611@amdahl.uts.amdahl.com> dwl10@amdahl.uts.amdahl.com (Dave Lowrey) writes: >I have a question regarding 1541 programming. I have been studying the ROM >listings, and examples of programming the 1541 yourself, and have come >upon an interesting bit of code that I don't fully understand. > > >c100 CLV >c101 BVC $c101 > >I assume that the disk controller interrupts the 6502 when "something" >happens, and the IRQ/NMI interrupt handeler sets the Overflow flag, so >our "endless" loop ends. > >My question is: exactly why/when is the oveflow flag set, and who is >setting it? > >There are several occurances of this code in the ROM. I also have >sample programs from a book that do this, with the comments such as >"Wait for header" and "wait for data". I would like specific info >on what is happening here. > >Thanks..... Specifically, the overflow flag is set by _hardware_, not software. There is a pin (I can't remember which one) which sets the overflow flag. In the 1541, this pin is tied to the output of a Nand, which checks the byte stream from the heads. If the pattern is $FF, then the line gets pulled. The SYNC pattern is several real (not GCR) one bits, which will pull the overflow set line and permit the processor to continue. The comments which say "waiting for..." are waiting for the data header or the sector header to sync up. This is necessary because the 1541 does not read the index hold and consequently needs a different way to find the beginning of headers on the disk. Check "inside the 1541" by Abacus software and "inside Commodore DOS" by someone else. I have both books and they are great, although I admit I had to read each one cover to cover over 12 times to fully understand how the drive works. These books, while they do have sections for the novice, are quite useful for the experienced programmer (You know, like the guys who can write a 6502 program in hex, directly) Hope this helps. Send me e-mail if you need any further clarification. -ethan > Dave Lowrey > Amdahl Corp. > Houston, Texas > (713)-850-8828 > ...!{ihnp4,cbosgd,hplabs,oliveb}!amdahl!dwl10 > -- Ethan R. Dicks | ###### This signifies that the poster is a member in Specialized Software| ## good sitting of Inertia House: Bodies at rest. 2101 Iuka Ave. | ## Columbus OH 43201 | ###### "You get it, you're closer."
leblanc@godzilla.ele.toronto.edu (Marcel LeBlanc) (03/16/88)
In article <8301@tut.cis.ohio-state.edu> erd@tut.cis.ohio-state.edu (Ethan R. Dicks) writes: >In article <24611@amdahl.uts.amdahl.com> dwl10@amdahl.uts.amdahl.com (Dave Lowrey) writes: >>I have a question regarding 1541 programming. I have been studying the ROM ... >>c100 CLV >>c101 BVC $c101 ... >>My question is: exactly why/when is the oveflow flag set, and who is >>setting it? ... > >Specifically, the overflow flag is set by _hardware_, not software. There is >a pin (I can't remember which one) which sets the overflow flag. In the >1541, this pin is tied to the output of a Nand, which checks the byte stream >from the heads. If the pattern is $FF, then the line gets pulled. The SYNC ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^ > ... >-ethan > The OVERFLOW bit is indeed set by hardware, but not as a result of a SYNC character being detected. The Overflow bit is set when a byte is ready to be read (from $1C01). When eight bits have been read from the disk surface, the processor is signalled by setting the .V bit. A SYNC character is detected by polling bit 7 of $1C00: waitsync bit $1C00 bpl waitsync ... >> Dave Lowrey > >-- >Ethan R. Dicks | ###### This signifies that the poster is a member in >Specialized Software| ## good sitting of Inertia House: Bodies at rest. Marcel A. LeBlanc University of Toronto -- Toronto, Canada also: LMS Technologies Ltd, Fredericton, NB, Canada UUCP: {decvax,ihnp4,linus,utzoo,uw-beaver}!utcsri!godzilla!leblanc ARPA: leblanc%godzilla.ele.toronto.edu@relay.cs.net CSNET: leblanc@godzilla.ele.toronto.edu CDNNET: leblanc@godzilla.ele.toronto.cdn BITNET: leblanc@godzilla.ele.utoronto (may not work from all sites) -- Marcel A. LeBlanc University of Toronto -- Toronto, Canada also: LMS Technologies Ltd, Fredericton, NB, Canada