[Coco] 6309 Division instructions

Gene Heskett gene.heskett at verizon.net
Tue Aug 2 23:12:29 EDT 2005


On Tuesday 02 August 2005 16:52, jdaggett at gate.net wrote:
>Robert
>
>I quote from the 6309 Technical Reference Guide by Chet Simpson
>
>"The  DIVD  (16  bit by 8 bit) instruction does a signed divide of
>the contents of the D register with a value from memory (or in
>direct  mode). The signed  result  is  stored  with  the  quotient
>in  W and the modulo (remainder) in D."
>
>
>Now if this is in error, then I am in error. From your posting then
> the above document must be in error.
>
>>From your example it appears that reg B has the quotient and reg A
> has the remainder. If this is so then there is something else going
> wrong in the instruction. Since the last time I checked, division
> of a negative integer by a positive interger should yield a
> negative integer quotient. According to reg A results this is a
> positive number.
>
>$BCEF  signed integer should be a negative -15599. Divide that by 24
> and you get -649 quotient of hex $8289 in word format.
>
>What still bothers me is the results still don't add up to being
> close.
>
>james
>
>On 2 Aug 2005 at 13:39, Robert Gault wrote:
>
>Date sent:       Tue, 02 Aug 2005 13:39:54 -0400
>From:            Robert Gault <robert.gault at worldnet.att.net>
>To:              CoCoList for Color Computer Enthusiasts
><coco at maltedmedia.com>
>Subject:         Re: [Coco] 6309 Division instructions
>Send reply to:   CoCoList for Color Computer Enthusiasts
><coco at maltedmedia.com>
> <mailto:coco-
>request at maltedmedia.com?subject=unsubscribe>
> <mailto:coco-
>request at maltedmedia.com?subject=subscribe>
>
>> Not on my system running under Disk Basic. If regD is loaded with
>> any number then DIVD # has no effect at all on regW but only regA
>> and regB. If your test was made under OS-9, the results may be
>> different and possibly misleading.
>>
>> For example using EDT6309 my version of EDTASM the following:
>>
>> START LDD #$BCEF
>>  DIVD #24
>>  SWI
>>  END
>> gives
>> A=$43 B=$11 DP=00 CC=$8A =ENV
>> X=0000 Y=0000 U=0000 S=$1579
>> PC=$56E2 V=0000 E=00 F=00
>>
>> Change to LDD #24 and regA=00 regB=01 CC=$81 =EC and regW is still
>> 0000.
>>
>> jdaggett at gate.net wrote:
>> > Sorry was a typo. Contents of D. W and D are the results.
>> >
>> > james
>> >
>> > On 1 Aug 2005 at 23:48, Robert Gault wrote:
>> >
>> > Date sent:       Mon, 01 Aug 2005 23:48:46 -0400
>> > From:            Robert Gault <robert.gault at worldnet.att.net>
>> > To:              CoCoList for Color Computer Enthusiasts
>> > <coco at maltedmedia.com>
>> > Subject:         Re: [Coco] 6309 Division instructions
>> > Send reply to:   CoCoList for Color Computer Enthusiasts
>> > <coco at maltedmedia.com>
>> >  <mailto:coco-
>> > request at maltedmedia.com?subject=unsubscribe>
>> >  <mailto:coco-
>> > request at maltedmedia.com?subject=subscribe>
>> >
>> >>Is that a typo? Why would regW be involved with DIVD?
>> >>
>> >>jdaggett at gate.net wrote:
>> >>>Tim
>> >>>
>> >>>from the 6309 documentation I h ave the DIVD does a 16 bit by 8
>> >>>signed division. The contents of W is divided by memory byte
>> >>> and the quotient is stored in W and the modulo (remainder) is
>> >>> in D.
>> >>>
>> >>>This yields +32,767/-32,768 divided by +127/-128 ranges.
>> >>>
>> >>>
>> >>>Initial thoughts on how to get an overflow condition would mean
>> >>> the modulo would overflow or the divisor is "one"?
>> >>>
>> >>>james
>> >>>
>> >>>On 1 Aug 2005 at 20:15, tim lindner wrote:
>> >>>
>> >>>To:              coco at maltedmedia.com (CoCo Mailing List)
>> >>>From:            tlindner at ix.netcom.com (tim lindner)
>> >>>Date sent:       Mon, 1 Aug 2005 20:15:58 -0700
>> >>>Organization:    Computers Suck, Inc.
>> >>>Subject:         [Coco] 6309 Division instructions
>> >>>Send reply to:   CoCoList for Color Computer Enthusiasts
>> >>><coco at maltedmedia.com>
>> >>> <mailto:coco-
>> >>>request at maltedmedia.com?subject=unsubscribe>
>> >>> <mailto:coco-
>> >>>request at maltedmedia.com?subject=subscribe>
>> >>>
>> >>>>I was testing the division instructions against my 6309 core
>> >>>> (in MESS) and found something unusual.
>> >>>>
>> >>>>My Burke & Burke 6309 documents say that result of DIVD is a
>> >>>>signed 8-bit value in register B and an unsigned remainder in
>> >>>>register A.
>> >>>>
>> >>>>Further more it says that if the quotient overflows, the value
>> >>>> of A and B will be unchanged and the V condition code will be
>> >>>> set.
>> >>>>
>> >>>>But this is not exactly the behiavior I am seeing on real
>> >>>>hardware.
>> >>>>
>> >>>>What I am seeing is a sort of two stage overflow. If the
>> >>>> quotient doesn't fit in an signed 8 bit container but would
>> >>>> fit in a unsigned 8 bit container, then the correct absolute
>> >>>> value is wirrten to B and the V condition code is set.
>> >>>>
>> >>>>If the value overflows an unsgined container, the registers A
>> >>>> and B set to the absolute value the the orginal numerator and
>> >>>> the V condition code is set.
>> >>>>
>> >>>>I have not seen this behiavor described anywhere and I would
>> >>>> be interested in other peoples thoughts on it.

In this case, I'm inclined to think about swapping that chip out for 
another, and see if the results are still fubar.  I recall I spent a 
couple of days once on a z-80 problem that was finally solved when I 
discovered I had a bad chip that would only execute the $EB command 
reliably on odd days of the moons cycle.  $EB for the frogs is the 
z-80's swap register sets command, causing the background set to 
become the forground set and vice versa.  Unforch, the chip had no 
means of tallying which set was in use.  Brain dead xilog stuff, good 
riddance.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.



More information about the Coco mailing list