6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Sep 23, 2024 10:32 pm

All times are UTC




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Visual 6502 Question
PostPosted: Tue Mar 19, 2013 9:24 pm 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
I analyzed the data by tracing two instructions.

LDA #C1
ADC #12

The DP Control shows #DAA, ~DAA, #DSA, ~DSA. Can you please clarify more details what are the symbol on the first character as # and ~? If decimal flag is cleared, DAA should not be gated to ALU before data is sent to the accumulator register.

I tried the following below.

SED
LDA #12
ADC #34
CLD

#DAA and ~DAA disappeared when second clock cycle of ADC is reached.

The data is in BCD register. The BCD register checks the decimal flag. If decimal flag is cleared, the data passes to the accumulator register, otherwise if decimal flag is set, the data is added 6 before it passes to the accumulator register. What are four pins on the left register and right register prior accumulator register? Please look at the 6502 diagram.

Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Wed Mar 20, 2013 7:12 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Hi Bryan
Here's a simulation which should help. Breaking down the URL, we have:
Code:
http://www.visual6502.org/JSSim/expert.html?
graphics=f&   # suppress the chip layout image
a=0&  # place the following code at address 0000
d=a9c16912f8a9126934e933ea&  # our test program
steps=28&  # run for 28 steps (14 clock cycles)
logmore=idb,sb,alua,alub,alu,dasb,dpc18_~DAA,dpc22_~DSA,DPControl  # trace these signals (and a pseudo-signal)

As you note, the decimal control signals DAA and DSA are only active in the single cycle after an add or subtract respectively. As they are active-low, they have a prefix of # or ~. We chose # at first, and then added ~ as an alias because of difficulty putting # in a URL.
These signals appear in the 'DPControl' collection. It's a bug that both of the aliases are listed.
The actual names of the signals is more obscure: there's a prefix. A good resource here is the nodenames.js which is loaded by the simulator:
http://www.visual6502.org/JSSim/nodenames.js
where we see comments for many of the signals together with their full names:
Code:
"dpc18_#DAA": 1201,  // decimal related (inverted)
"dpc18_~DAA": 1201,   // automatic alias replacing hash with tilde
"dpc22_#DSA": 725,   // decimal related/SBC only (inverted)
"dpc22_~DSA": 725,    // automatic alias replacing hash with tilde



Note the 'dasb' is the decimally adjusted special bus:
Code:
      // datapath signal: decimally adjusted special bus
dasb0: 54,      // same node as sb0
dasb1: 1009,
dasb2: 450,
dasb3: 1475,
dasb4: 1405,    // same node as sb4
dasb5: 263,
dasb6: 679,
dasb7: 1494,


Finally, then, we can look at the tabulation, which shows the values passing over the various busses and landing in the appropriate registers:
Code:
cycle  ab   db  rw  Fetch      pc    a    x    y    s          p  idb   sb alua alub  alu dasb dpc18_~DAA dpc22_~DSA
 0   0000   a9   1   LDA #   0000   aa   00   00   fd   nv‑BdIZc   00   ff   ff   00   00   ff   1         1
 0   0000   a9   1   LDA #   0000   aa   00   00   fd   nv‑BdIZc   ff   ff   ff   00   ff   ff   1         1
 1   0001   c1   1           0001   aa   00   00   fd   nv‑BdIZc   ff   ff   ff   ff   ff   ff   1         1
 1   0001   c1   1           0001   aa   00   00   fd   nv‑BdIZc   ff   ff   ff   ff   fe   ff   1         1
 2   0002   69   1   ADC #   0002   c1   00   00   fd   Nv‑BdIzc   c1   c1   c1   c1   fe   c1   1         1
 2   0002   69   1   ADC #   0002   c1   00   00   fd   Nv‑BdIzc   82   82   c1   c1   82   82   1         1
 3   0003   12   1           0003   c1   00   00   fd   Nv‑BdIzc   82   82   82   82   82   82   1         1
 3   0003   12   1           0003   c1   00   00   fd   Nv‑BdIzc   ff   ff   82   82   04   ff   1         1
 4   0004   f8   1   SED     0004   c1   00   00   fd   Nv‑BdIzc   12   c1   c1   12   04   c1   1         1
 4   0004   f8   1   SED     0004   c1   00   00   fd   Nv‑BdIzc   d3   d3   c1   12   d3   d3   1         1
 5   0005   a9   1           0005   d3   00   00   fd   Nv‑BdIzc   d3   d3   d3   d3   d3   d3   1         1
 5   0005   a9   1           0005   d3   00   00   fd   Nv‑BdIzc   ff   ff   d3   d3   a6   ff   1         1
 6   0005   a9   1   LDA #   0005   d3   00   00   fd   Nv‑BDIzc   ff   ff   ff   ff   a6   ff   1         1
 6   0005   a9   1   LDA #   0005   d3   00   00   fd   Nv‑BDIzc   fe   fe   ff   ff   fe   fe   1         1
 7   0006   12   1           0006   d3   00   00   fd   Nv‑BDIzc   fe   fe   fe   fe   fe   fe   1         1
 7   0006   12   1           0006   d3   00   00   fd   Nv‑BDIzc   ff   ff   fe   fe   fc   ff   1         1
 8   0007   69   1   ADC #   0007   12   00   00   fd   nv‑BDIzc   12   12   12   12   fc   12   1         1
 8   0007   69   1   ADC #   0007   12   00   00   fd   nv‑BDIzc   24   24   12   12   24   24   1         1
 9   0008   34   1           0008   12   00   00   fd   nv‑BDIzc   24   24   24   24   24   24   1         1
 9   0008   34   1           0008   12   00   00   fd   nv‑BDIzc   ff   ff   24   24   48   ff   1         1
10   0009   e9   1   SBC #   0009   12   00   00   fd   nv‑BDIzc   34   12   12   34   48   12   0         1
10   0009   e9   1   SBC #   0009   12   00   00   fd   nv‑BDIzc   46   46   12   34   46   46   0         1
11   000a   33   1           000a   46   00   00   fd   nv‑BDIzc   46   46   46   46   46   46   1         1
11   000a   33   1           000a   46   00   00   fd   nv‑BDIzc   ff   ff   46   46   8c   ff   1         1
12   000b   ea   1   NOP     000b   46   00   00   fd   nv‑BDIzc   33   46   46   cc   8c   46   1         0
12   000b   ea   1   NOP     000b   46   00   00   fd   nv‑BDIzc   12   12   46   cc   12   12   1         0
13   000c   00   1           000c   12   00   00   fd   nv‑BDIzC   12   12   12   12   12   12   1         1
13   000c   00   1           000c   12   00   00   fd   nv‑BDIzC   ff   ff   12   12   24   ff   1         1


The test program:
Code:
Address  Hexdump   Dissassembly
-------------------------------
$0000    a9 c1     LDA #$c1
$0002    69 12     ADC #$12
$0004    f8        SED
$0005    a9 12     LDA #$12
$0007    69 34     ADC #$34
$0009    e9 33     SBC #$33
$000b    ea        NOP


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Thu Mar 21, 2013 5:28 pm 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
Hi,

Thanks for the information. I try to understand how transistor works. I looked at the visual 6502's graphic. Dark red is turned on as bit 0 or low and dark gray is turned off as bit 1 or high. They are driven from address bus lines and data bus lines. If you click any line, dark red line will be bright red or dark gray line will be bright gray.

What is the purple line? Is it from PLA outputs?

What is the green line? Is it from ground?

What is the yellow line? Is it from VSS or VCC or clock 0 / clock 1?

How can I understand if red line is connected to yellow line or purple line before on / off is driven to another line?

Please clarify little more details.

Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Thu Mar 21, 2013 7:19 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
(here's a better simulation which actually shows decimal adjustment of 99+1)
Bryan Parkoff wrote:
Hi,
Thanks for the information. I try to understand how transistor works. I looked at the visual 6502's graphic.

Attachment:
File comment: Screenshot of Visual6502
visual6502-colours.png
visual6502-colours.png [ 130.19 KiB | Viewed 1530 times ]

Quote:
Dark red is turned on as bit 0 or low and dark gray is turned off as bit 1 or high. They are driven from address bus lines and data bus lines. If you click any line, dark red line will be bright red or dark gray line will be bright gray.

Looking at the screenshot I took, you'll see two horizontal metal lines, coloured a reddish purple - a plum colour - with white edges. They are translucent. The reddish colour indicates a logic 1, a high. They go to full red when you click on them. Above and below them you see translucent grey horizontal metal lines: these are low. They go to hard white when you click on them.
Quote:
What is the purple line? Is it from PLA outputs?

Purple is polysilicon. It's the next layer down from metal, and it can contact to metal (upwards, towards you) or to diffusion (downwards, towards the chip). When it's logic zero, it's a bluish purple and when it's logic one it's a reddish purple. It's not translucent. Poly tracks are generally narrower than metal. Contacts are not shown, but if the poly track ends in a squarish shape there's likely to be a contact there.
In the screenshot most of the poly is running vertically. There are 12 vertical strips at the top of the frame, all are at logic 1. There's a horizontal poly section just below those, that's a bluish purple and it's at logic 0.
Quote:
What is the green line? Is it from ground?

Green is actually tied to ground: the metal lines which take power and ground around the chip are not shown in visual6502. If you look at the metal alone (using the Show selection buttons below the chip image) you'll see obvious gaps - these gaps are for the rails. Green is diffusion. In the selection buttons it's called (grounded diffusion)- try toggling the button.
Quote:
What is the yellow line? Is it from VSS or VCC or clock 0 / clock 1?

Yellow and orange are both diffusion: logic 0 or logic 1 respectively. Basically all colours go more red when they are logic 1. As it happens, the diffusion towards the top of my screenshot is all at logic 0 and the diffusion towards the bottom is all at logic 1.
Quote:
How can I understand if red line is connected to yellow line or purple line before on / off is driven to another line?

Eventually you can visually infer the connections between layers. If poly stops where it overlaps active, then there's most likely a connection. The horizontal poly in the top left quadrant connects to the yellow active. Until you can infer it reliably, just select one or other shape, and see which shapes light up: all the shapes on the same signal will light up.
Quote:
Please clarify little more details.

I hope that helps.
Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 3:49 am 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
Are dasb register supposed to have eight wires from adder hold register to dasb register through special bus path prior accumulator register? Visual 6502 shows dasb1, dasb2, etc, but it does not show dasb0 and dasb4. dasb0 and dasb4 look like to be labeled as sb0 and sb4. Are labels mistaken?

Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 11:08 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Hi Brian
as I recall, dasb is only a bus, not a register. Indeed, if you check the nodenames.js file, you'll see that dasb0 and dasb4 are the same as sb0 and sb4 - that's because decimal adjustment never touches those bits.

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 12:55 pm 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
This may explain why dash0 and dash4 go to accumulator register directly from adder hold register because even / odd digits are still the same as binary mode and decimal mode. If bit 3 through bit 1 and bit 5 through bit 7 are hexadecimal, then they need to be adjusted to decimal mode while bit 0 and bit 4 remain unchanged. Correct?

Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 1:09 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Yes!


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 1:40 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
Bryan Parkoff wrote:
This may explain why dash0 and dash4 go to accumulator register directly from adder hold register because even / odd digits are still the same as binary mode and decimal mode. If bit 3 through bit 1 and bit 5 through bit 7 are hexadecimal, then they need to be adjusted to decimal mode while bit 0 and bit 4 remain unchanged. Correct?

Take care,
Bryan Parkoff

Surely bit 4 can change?

$06 + $09 = $0f => $15 dec

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Fri Mar 22, 2013 1:51 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Indeed... in this case the SB contains $1F and the DASB contains $15 (when in decimal mode) - so the SB value already takes into account the extra half-carry needed for decimal operation.
Good example!

Edit: note that ~C34 is the not-carry from bit 3 to bit 4, and DC34 is the decimal force-half carry signal.


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Sat Mar 23, 2013 6:43 pm 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
Visual 6502 does not implement to include data bus input register's bus enable pins. I will like to trace below.

"dpc41_DL/ADL": 1564,// pass-connect adl to mux node driven by idl
"dpc42_DL/ADH": 41, // pass-connect adh to mux node driven by idl
"dpc43_DL/DB": 863, // pass-connect idb to mux node driven by idl

They need to be without double quote marks so that I can test them to find out if they are 0 or 1 before internal data bus can show the data value.

Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Sat Mar 23, 2013 8:24 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Hi Bryan
Those signal names are fine: just ignore the quote marks - they are just there for the JavaScript parser. You don't need them in the Trace These Too box, in the URL, or in the Find box.
Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Sun Mar 24, 2013 3:25 am 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
I try to figure out why data bus and special bus show "FF" value instead of current data value. Look at second clock cycle 3 between 24 and 34 in internal data bus. More "FF" values show while internal data latch register is disabled during NOPs. It is supposed to be floating from internal data bus to special bus. When ALU do sum FF and FF to become FE, they restore back to FF. Do not make any sense.

Do you have idea what is going on?

Code:
cycle   ab   db   rw   Fetch   pc   a   x   y   s   p   cp1   cclk   DL/DB   DL/ADL   DL/ADH   idl   idb   adl   adh   SBDB   sb   nDBADD   DBADD   ADLADD   alub   0ADD   SBADD   alua   alu   ADDSB06   ADDSB7   ADDADL   ACSB   SBAC
0   0   a9   1   LDA #   0   aa   0   0   fd   nv BdIZc   1   0   1   0   1   0   0   0   0   0   ff   0   1   0   0   0   1   ff   0   0   0   1   0   0
0   0   a9   1   LDA #   0   aa   0   0   fd   nv BdIZc   0   1   0   0   0   a9   ff   1   0   1   ff   0   0   0   0   0   0   ff   ff   1   1   0   0   0
1   1   12   1       1   aa   0   0   fd   nv BdIZc   1   0   0   0   0   a9   ff   1   0   1   ff   0   1   0   ff   0   1   ff   ff   1   1   0   0   0
1   1   12   1       1   aa   0   0   fd   nv BdIZc   0   1   1   0   0   12   ff   2   0   1   ff   0   0   0   ff   0   0   ff   fe   0   0   0   0   0
2   2   69   1   ADC #   2   12   0   0   fd   nv BdIzc   1   0   1   0   0   12   12   2   0   1   12   0   1   0   12   0   1   12   fe   0   0   0   0   1
2   2   69   1   ADC #   2   12   0   0   fd   nv BdIzc   0   1   0   0   0   69   24   3   0   1   24   0   0   0   12   0   0   12   24   1   1   0   0   0
3   3   34   1       3   12   0   0   fd   nv BdIzc   1   0   0   0   0   69   24   3   0   1   24   0   1   0   24   0   1   24   24   1   1   0   0   0
3   3   34   1       3   12   0   0   fd   nv BdIzc   0   1   1   0   0   34   ff   4   0   0   ff   0   0   0   24   0   0   24   48   0   0   0   0   0
4   4   ea   1   NOP   4   12   0   0   fd   nv BdIzc   1   0   1   0   0   34   34   4   0   0   12   0   1   0   34   0   1   12   48   0   0   0   1   0
4   4   ea   1   NOP   4   12   0   0   fd   nv BdIzc   0   1   0   0   0   ea   46   5   0   1   46   0   0   0   34   0   0   12   46   1   1   0   0   0
5   5   ea   1       5   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   46   5   0   1   46   0   1   0   46   0   1   46   46   1   1   0   0   1
5   5   ea   1       5   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   ff   5   0   0   ff   0   0   0   46   0   0   46   8c   0   0   0   0   0
6   5   ea   1   NOP   5   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   ff   5   0   0   ff   0   1   0   ff   0   1   ff   8c   0   0   0   0   0
6   5   ea   1   NOP   5   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   fe   6   0   1   fe   0   0   0   ff   0   0   ff   fe   1   1   0   0   0
7   6   ea   1       6   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   fe   6   0   1   fe   0   1   0   fe   0   1   fe   fe   1   1   0   0   0
7   6   ea   1       6   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   ff   6   0   0   ff   0   0   0   fe   0   0   fe   fc   0   0   0   0   0
8   6   ea   1   NOP   6   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   ff   6   0   0   ff   0   1   0   ff   0   1   ff   fc   0   0   0   0   0
8   6   ea   1   NOP   6   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   fe   7   0   1   fe   0   0   0   ff   0   0   ff   fe   1   1   0   0   0



Take care,
Bryan Parkoff


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Sun Mar 24, 2013 8:19 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Hi Bryan
The reason is a form of precharge: do a Find on transistor t36 for example:
transistor: t36 on node: 943 cclk
and also on t3504
transistor: t3504 on node: 943 cclk
and you'll see that the special bus and the internal databus are always charged up to 1 in phi2. That gives us two things: a constant value of FF which is I think sometimes used by the machine as a constant, and also by putting all 16 wires of the two busses to a strong logic 1, it means the pass gates which conditionally connect the two busses only have to pass zeros. It's an analogue fix, to make best use of the NMOS transistors.

You might find it useful generally to your trace dpc25_SBDB which is the control signal to connect and disconnect the special bus (sb) and the internal databus (idb), and also dpc27_SBADH which controls the (dis)connection between sb and adh (address bus high), by means of these 16 pass transistors.

Cheers
Ed

BTW, tidied up your tabulation - feel free to paste this into your message and I'll delete it here.
Bryan Parkoff wrote:
Code:
cycle                                                           DL/DB   DL/ADH                        nDBADD   ADLADD   0ADD             ADDSB06  ADDADL
   ab   db   rw  Fetch   pc   a   x   y   s        p     cp1 cclk  DL/ADL    idl  idb adl  adh SBDB sb     DBADD   alub     SBADD alua alu    ADDSB7   ACSB SBAC
0   0   a9   1   LDA #   0   aa   0   0   fd   nv BdIZc   1   0   1   0   1    0    0   0   0   0   ff   0   1   0    0   0   1   ff    0   0   0   1   0   0
0   0   a9   1   LDA #   0   aa   0   0   fd   nv BdIZc   0   1   0   0   0   a9   ff   1   0   1   ff   0   0   0    0   0   0   ff   ff   1   1   0   0   0
1   1   12   1           1   aa   0   0   fd   nv BdIZc   1   0   0   0   0   a9   ff   1   0   1   ff   0   1   0   ff   0   1   ff   ff   1   1   0   0   0
1   1   12   1           1   aa   0   0   fd   nv BdIZc   0   1   1   0   0   12   ff   2   0   1   ff   0   0   0   ff   0   0   ff   fe   0   0   0   0   0
2   2   69   1   ADC #   2   12   0   0   fd   nv BdIzc   1   0   1   0   0   12   12   2   0   1   12   0   1   0   12   0   1   12   fe   0   0   0   0   1
2   2   69   1   ADC #   2   12   0   0   fd   nv BdIzc   0   1   0   0   0   69   24   3   0   1   24   0   0   0   12   0   0   12   24   1   1   0   0   0
3   3   34   1           3   12   0   0   fd   nv BdIzc   1   0   0   0   0   69   24   3   0   1   24   0   1   0   24   0   1   24   24   1   1   0   0   0
3   3   34   1           3   12   0   0   fd   nv BdIzc   0   1   1   0   0   34   ff   4   0   0   ff   0   0   0   24   0   0   24   48   0   0   0   0   0
4   4   ea   1   NOP     4   12   0   0   fd   nv BdIzc   1   0   1   0   0   34   34   4   0   0   12   0   1   0   34   0   1   12   48   0   0   0   1   0
4   4   ea   1   NOP     4   12   0   0   fd   nv BdIzc   0   1   0   0   0   ea   46   5   0   1   46   0   0   0   34   0   0   12   46   1   1   0   0   0
5   5   ea   1           5   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   46   5   0   1   46   0   1   0   46   0   1   46   46   1   1   0   0   1
5   5   ea   1           5   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   ff   5   0   0   ff   0   0   0   46   0   0   46   8c   0   0   0   0   0
6   5   ea   1   NOP     5   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   ff   5   0   0   ff   0   1   0   ff   0   1   ff   8c   0   0   0   0   0
6   5   ea   1   NOP     5   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   fe   6   0   1   fe   0   0   0   ff   0   0   ff   fe   1   1   0   0   0
7   6   ea   1           6   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   fe   6   0   1   fe   0   1   0   fe   0   1   fe   fe   1   1   0   0   0
7   6   ea   1           6   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   ff   6   0   0   ff   0   0   0   fe   0   0   fe   fc   0   0   0   0   0
8   6   ea   1   NOP     6   46   0   0   fd   nv BdIzc   1   0   0   0   0   ea   ff   6   0   0   ff   0   1   0   ff   0   1   ff   fc   0   0   0   0   0
8   6   ea   1   NOP     6   46   0   0   fd   nv BdIzc   0   1   0   0   0   ea   fe   7   0   1   fe   0   0   0   ff   0   0   ff   fe   1   1   0   0   0


Top
 Profile  
Reply with quote  
 Post subject: Re: Visual 6502 Question
PostPosted: Tue Mar 26, 2013 1:33 am 
Offline

Joined: Tue Dec 25, 2007 4:57 am
Posts: 109
When I test decimal mode, half carry does not look right. Let me give you an example.

9 + 0 = 9 half carry clear
9 + 1 = 10 half carry set
9 + 2 = 11 half carry set
9 + 3 = 12 half carry set
9 + 4 = 13 half carry set
9 + 5 = 14 half carry set
9 + 6 = 15 half carry set
9 + 7 = 16 half carry set
9 + 8 = 17 half carry clear ( does not sound right )
9 + 9 = 18 half carry clear ( does not sound right )

I try to figure out how bit 3 to bit 1 in dasb can be gated from half carry set and DAA. Look at my picture below. You will see red square mark. Tell me what is this? I know that if 'A' is greater than '9', then '6' is summed to become 0. I wonder dasb is not supposed to use sum since alu already summed in binary mode before bit 3 through bit 1 have something to do with DAA and half carry.

Take care,
Bryan Parkoff


Attachments:
6502 DAA.png
6502 DAA.png [ 38.03 KiB | Viewed 1403 times ]
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: