i2cdetect shows unknown addresses and addresses don't change when new I2C device plugged in. What are these addresses? - microcontroller

How do I know which I2C is an actual I2C device and what are these addresses?
My system/ my computer is an Nvidia Jetson AGX Xavier and I have no I2C devices plugged in to it at the time I am running all these i2cdetect commands below. I do have a Gy-521 gyro connected over I2C that I have plugged in and looked for. The problem is when this gyro is plugged in that nothing looks any different with i2cdetect from 0 through 8.
I have 0 through 8 options on I2C to look for addresses. I will go through each of them with i2cdetect starting with 0.
$ i2cdetect -r -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
An address at 50 and 56 it would seem.
$ i2cdetect -r -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- UU -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- 74 -- -- --
$ i2cdetect -r -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$ i2cdetect -r -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: ^Z^X^C
When I get to 3 it hangs when it would otherwise print out the addresses.
$ i2cdetect -r -y 4
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$ i2cdetect -r -y 5
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- ^C^X^Z
$ i2cdetect -r -y 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: ^C^X^Z
5 and 6 also hang and do not print all the addresses.
$ i2cdetect -r -y 7
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$ i2cdetect -r -y 8
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- 74 -- -- --
As I've said. There are no I2C devices plugged in and when there are I2C devices plugged in they don't look any different than this.

Related

How do you correctly debug A/D convertor code in MPLAB X v5.05 simulator

This is a continuation of the question posed in How do you run a SCL file in MPLAB without a "Run SCL" button
I have an assembly code for PIC18F458 that gets data from channel 0 (RA0) of ADC and displays the result on PORTC and PORTD.
Although, I have managed to verify that the code operates as desired within Proteus, I am struggling to do the same within the MPLAB X simulator environment using a SCL file, and I suspect that this is due to the way that the text files, referred to by it, are laid out. (Please see below)
testbench for "pic18f458" is
begin
process is
file datafile : text;
variable intVar : integer;
variable sampling_voltage : integer;
variable fileStatus : file_open_status;
variable fileLine : line;
begin
loop
report("Analog injection started...");
file_open(fileStatus, datafile, "text2.txt", read_mode);
if fileStatus == open_ok then
report("Reading the values file...");
while endfile(datafile) == false loop
wait until ADCON0.GO_nDONE == '1';
report("Conversion started");
readline(datafile, fileLine);
wait for 400 ns;
read(fileLine, intVar);
sampling_voltage := intVar; -- sample input voltage
wait until ADCON0.GO_nDONE == '0';
report("Conversion ended");
if ADCON1.ADFM == '0' then -- left justified
ADRESH <= sampling_voltage / 4;
ADRESL <= sampling_voltage * 64;
else -- right justified
ADRESH <= sampling_voltage / 256;
ADRESL <= sampling_voltage;
end if;
end loop;
file_close(datafile);
end if;
end loop;
wait;
end process;
end testbench;
The SCL file refers to 1 of 2 text files during my debugging session (text.txt and text2.txt) laid out differently. The first consists of decimal numbers from 0 to 255 and the second consists of decimal numbers representing voltages in mV.
txt.txt
128
192
238
255
238
192
128
64
17
0
17
64
128
text2.txt
250 mV
500 mV
750 mV
1000 mV
1250 mV
1500 mV
1750 mv
2000 mV
2250 mv
2500 mv
2750 mv
3000 mv
3250 mV
3500 mV
3750 mV
4000 mV
4250 mV
4500 mV
4750 mv
5000 mV
In both cases, the ADC seems to just be churning out the numbers that it is receiving, instead of converting them. (Please see images below)
This is obviously no good, as I am getting values within the ADRES register that are greater than 10-bits, in particularly, with regards to my text2.txt values.
ADC Results with text.txt
ADC Results with text2.txt
Therefore, my question is how do I correctly debug my A/D convertor code in MPLAB X v5.05 simulator using a SCL file or any other methods?

Decrypt Word document knowing part of its content

I have a ciphered .docx document I would like to recover and I don't remember the password. I'm trying brute-forcing it but it's taking way too long, so it's not going to be option. However, I know the exact content of part of it (296 characters). Any help?
Unfortunately, part of the document wouldn't help.
To get to the cleartext, any cracker would still need to go through trying to crack the password hash that is exported from the document, and with your logic try to decrypt the file and interpret it's content, compare it to the known cleartext. There is no such funcitonality, especially for specialized document formats.
Here is an example how to approach it:
Document: encrypted_doc.docx
Password: 123horse123
You will have to use office2john to export the hash to be cracked from the document.
wget https://raw.githubusercontent.com/magnumripper/JohnTheRipper/bleeding-jumbo/run/office2john.py
python office2john.py encrypted_doc.docx > doc_pass_hash.txt
cat doc_pass_hash.txt
encrypted_doc.docx:$**office$*2013***100000*256*16*e77e386a8e68462d2a0a703718febbc9*08ee275ccf4946ae0e5922e9ff3114b7*0ab5fc00964f7ed4be9e45c77a33b441b2c4874d28e4bc30f38e99bfb169fcf4
Remembering some information about the password(complexity, some chosen words if any, character set etc.) mask attack could help you run a more effective way to uncover the document.
Run hashcat --help to see which document file are you dealing with:
9700 | MS Office <= 2003 $0/$1, MD5 + RC4 | Documents
9710 | MS Office <= 2003 $0/$1, MD5 + RC4, collider #1 | Documents
9720 | MS Office <= 2003 $0/$1, MD5 + RC4, collider #2 | Documents
9800 | MS Office <= 2003 $3/$4, SHA1 + RC4 | Documents
9810 | MS Office <= 2003 $3, SHA1 + RC4, collider #1 | Documents
9820 | MS Office <= 2003 $3, SHA1 + RC4, collider #2 | Documents
9400 | MS Office 2007 | Documents
9500 | MS Office 2010 | Documents
9600 | MS Office 2013 | Documents
Based on what you can recall from the password, you can choose from the following:
- [ Attack Modes ] -
# | Mode
===+======
0 | Straight
1 | Combination
3 | Brute-force
6 | Hybrid Wordlist + Mask
7 | Hybrid Mask + Wordlist
Here are the options for hashcat to specify the password:
?l = abcdefghijklmnopqrstuvwxyz
?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d = 0123456789
?h = 0123456789abcdef
?H = 0123456789ABCDEF
?s = «space»!"#$%&'()*+,-./:;<=>?#[\]^_`{|}~
?a = ?l?u?d?s
?b = 0x00 - 0xff
You can also create your own dictionary, which then will be used when generating the passwords, if you remember at least part of the password. This can be the most efficient help.
So in my example, let's run a brute force attack with mask(3 digits, 5 alphabetical characters, and another 3 digits):
hashcat -m 9600 -a 3 doc_pass_hash.txt --username -o cracked_pass.txt ?d?d?d?l?l?l?l?l?d?d?d --force
You can hit [s] for status:
[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit => s
Session..........: hashcat
Status...........: Running
Hash.Type........: MS Office 2013
Hash.Target......: $office$*2013*100000*256*16*e77e386a8e68462d2a0a703...69fcf4
Time.Started.....: Sat May 30 16:59:30 2020 (3 mins, 41 secs)
Time.Estimated...: Next Big Bang (17614 years, 157 days)
Guess.Mask.......: ?d?d?d?l?l?l?l?l?d?d?d [11]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 21 H/s (7.50ms) # Accel:128 Loops:32 Thr:1 Vec:8
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 4608/11881376000000 (0.00%)
Rejected.........: 0/4608 (0.00%)
Restore.Point....: 0/1188137600000 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:9-10 Iteration:24672-24704
Candidates.#1....: 623anane123 -> 612kerin123
As you see, this one doesn't seem to be very effective (Time.Estimated...: Next Big Bang (17614 years, 157 days)), however, adding a wordlist is a good idea:
cat wordlist.txt
dog
horse
cat
hashcat -m 9600 -a 6 doc_pass_hash.txt wordlist.dict ?d?d?d?l?l?l?l?l?d?d?d --username -o cracked_pass.txt --forces
Session..........: hashcat
Status...........: Running
Hash.Type........: MS Office 2013
Hash.Target......: $office$*2013*100000*256*16*e77e386a8e68462d2a0a703...69fcf4
Time.Started.....: Sat May 30 17:15:34 2020 (1 min, 25 secs)
Time.Estimated...: Next Big Bang (734631 years, 226 days)
Guess.Base.......: File (wordlist.dict), Left Side
Guess.Mod........: Mask (?d?d?d?l?l?l?l?l?d?d?d) [11], Right Side
Guess.Queue.Base.: 1/1 (100.00%)
Guess.Queue.Mod..: 1/1 (100.00%)
Speed.#1.........: 2 H/s (0.47ms) # Accel:128 Loops:32 Thr:1 Vec:8
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 129/35644128000000 (0.00%)
Rejected.........: 0/129 (0.00%)
Restore.Point....: 0/3 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:43-44 Iteration:32000-32032
Candidates.#1....: dog360verin123 -> cat360verin123
As we see this is not yet correct, as the candidates generate prior the mask. So this needs some more tweaking.
Masks you can define specific characters as well, for instance:
hashcat -m 9600 -a 3 doc_pass_hash.txt ?d?d?dhorse?d?d?d --username -o cracked_pass.txt --force
Session..........: hashcat
Status...........: Cracked
Hash.Type........: MS Office 2013
Hash.Target......: $office$*2013*100000*256*16*e77e386a8e68462d2a0a703...69fcf4
Time.Started.....: Sat May 30 17:24:32 2020 (28 secs)
Time.Estimated...: Sat May 30 17:25:00 2020 (0 secs)
Guess.Mask.......: ?d?d?dhorse?d?d?d [11]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 18 H/s (8.21ms) # Accel:128 Loops:32 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 512/1000000 (0.05%)
Rejected.........: 0/512 (0.00%)
Restore.Point....: 0/100000 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:99968-100000
Candidates.#1....: 123horse123 -> 112horse778
cat cracked_pass.txt
$office$*2013*100000*256*16*e77e386a8e68462d2a0a703718febbc9*08ee275ccf4946ae0e5922e9ff3114b7*0ab5fc00964f7ed4be9e45c77a33b441b2c4874d28e4bc30f38e99bfb169fcf4:123horse123
Cracked password in the end of the file: 123horse123
There is more to be read about rules and cracking with increased password lenght (--incremental) and combined attacks, but you get the idea.
Here are the official basic examples to get you started:
- [ Basic Examples ] -
Attack- | Hash- |
Mode | Type | Example command
==================+=======+==================================================================
Wordlist | $P$ | hashcat -a 0 -m 400 example400.hash example.dict
Wordlist + Rules | MD5 | hashcat -a 0 -m 0 example0.hash example.dict -r rules/best64.rule
Brute-Force | MD5 | hashcat -a 3 -m 0 example0.hash ?a?a?a?a?a?a
Combinator
| MD5 | hashcat -a 1 -m 0 example0.hash example.dict example.dict

How to print git history in rmarkdown?

I am writing an analysis report with rmarkdown and would like to have a "document versions" section in which I would indicate the different versions of the document and the changes made.
Instead of writing it down manually, I was thinking about using git history and inserting it automatically in the markdown document (formatting it in a table).
How can I do that? Is it possible?
Install git2r, https://github.com/ropensci/git2r then you can do stuff like:
> r = repository(".")
> cs = commits(r)
> cs[[1]]
[02cf9a0] 2017-02-02: uses Rcpp attributes instead of inline
So now I have a list of all the commits on this repo. You can get the info out of each commit and format as per your desire into your document.
> summary(cs[[1]])
Commit: 02cf9a0ff92d3f925b68853374640596530c90b5
Author: barryrowlingson <b.rowlingson#gmail.com>
When: 2017-02-02 23:03:17
uses Rcpp attributes instead of inline
11 files changed, 308 insertions, 151 deletions
DESCRIPTION | - 0 + 2 in 2 hunks
NAMESPACE | - 0 + 2 in 1 hunk
R/RcppExports.R | - 0 + 23 in 1 hunk
R/auxfunctions.R | - 1 + 1 in 1 hunk
R/skewt.r | - 0 + 3 in 1 hunk
R/update_params.R | - 1 + 1 in 1 hunk
R/update_params_cpp.R | -149 + 4 in 2 hunks
src/.gitignore | - 0 + 3 in 1 hunk
src/RcppExports.cpp | - 0 + 76 in 1 hunk
src/hello_world.cpp | - 0 + 13 in 1 hunk
src/update_params.cpp | - 0 +180 in 1 hunk
So if you just want the time and the commit message then you can grab it out of the object.
> cs[[3]]#message
[1] "fix imports etc\n"
> cs[[3]]#committer#when
2017-01-20 23:26:20
I don't know if there's proper accessor functions for these rather than using #-notation to get slots. Need to read the docs a bit more...
You can make a data frame from your commits this way:
> do.call(rbind,lapply(cs,function(cs){as(cs,"data.frame")}))
which converts the dates to POSIXct objects, which is nice. Creating a markdown table from the data frame should be trivial!
You can manually convert git log to markdown with pretty=format [1]
Something like
git log --reverse --pretty=format:'| %H | %s |'
This will output something like this:
| a8d5defb511f1e44ddea21b42aec9b03ee768253 | initial commit |
| fdd9865e9cf01bd53c4f1dc106ee603b0a730f48 | fix tests |
| 10b58e8dd9cf0b9bebbb520408f0b342df613627 | add Dockerfile |
| d039004e8073a20b5d6eab1979c1afa213b78fa3 | update README.md |
1: https://git-scm.com/docs/pretty-formats

Can somebody explain dbms_sql.number_table [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I tried to search this but could not get a satisfactory answer hence posting here . somebody please explain
Better to understand DBMS_SQL itself to some extent, before understanding NUMBER_TABLE.
( I do this for My Learning!)
NUMBER_TABLE
is Actually,
TYPE number_table IS TABLE OF NUMBER INDEX BY BINARY_INTEGER;
So, only numbers are allowed!
FlowChart on How DBMS_SQL Works! :
Your interested area comes in bind variable box
-- | open_cursor |
-- -----------
-- |
-- |
-- v
-- -----
-- ------------>| parse |
-- | -----
-- | |
-- | | ---------
-- | v |
-- | -------------- |
-- |-------->| bind_variable | |
-- | ^ ------------- |
-- | | | |
-- | -----------| |
-- | |<--------
-- | v
-- | query?---------- yes ---------
-- | | |
-- | no |
-- | | |
-- | v v
-- | ------- -------------
-- |----------->| execute | ->| define_column |
-- | ------- | -------------
-- | |------------ | |
-- | | | ----------|
-- | v | v
-- | -------------- | -------
-- | ->| variable_value | | ------>| execute |
-- | | -------------- | | -------
-- | | | | | |
-- | ----------| | | |
-- | | | | v
-- | | | | ----------
-- | |<----------- |----->| fetch_rows |
-- | | | ----------
-- | | | |
-- | | | v
-- | | | -----------------
-- | | | | column_value |
-- | | | | variable_value |
-- | | | -----------------
-- | | | |
-- | |<--------------------------
-- | |
-- -----------------|
-- |
-- v
-- ------------
-- | close_cursor |
--
------------
Example:
In a DELETE statement, for example, you could bind in an array in the WHERE clause and have the statement be run for each element in the array:
DECLARE
stmt VARCHAR2(200);
dept_no_array DBMS_SQL.NUMBER_TABLE;
c NUMBER;
dummy NUMBER;
begin
dept_no_array(1) := 10; dept_no_array(2) := 20; /* Put some values into the array */
dept_no_array(3) := 30; dept_no_array(4) := 40;
dept_no_array(5) := 30; dept_no_array(6) := 40;
stmt := 'delete from emp where deptno = :dept_array'; /* A Dynamic SQL String with a bind variable */
c := DBMS_SQL.OPEN_CURSOR; /* Open a Cursor! */
DBMS_SQL.PARSE(c, stmt, DBMS_SQL.NATIVE); /* Parse the Dynamic SQL , making it happen on the native database to which is connected! */
DBMS_SQL.BIND_ARRAY(c, ':dept_array', dept_no_array, 1, 4);
/* Bind only elements 1 through 4 to the cursor Happens 4 times */
dummy := DBMS_SQL.EXECUTE(c);
/* Execute the Query, and return number of rows deleted! */
DBMS_SQL.CLOSE_CURSOR(c);
EXCEPTION WHEN OTHERS THEN
IF DBMS_SQL.IS_OPEN(c) THEN
DBMS_SQL.CLOSE_CURSOR(c);
END IF;
RAISE;
END;
/
P.S. Pure rip-off, with some more commments ,from Oracle

Z80 DAA instruction

Apologies for this seemingly minor question, but I can't seem to find the answer anywhere - I'm just coming up to implementing the DAA instruction in my Z80 emulator, and I noticed in the Zilog manual that it is for the purposes of adjusting the accumulator for binary coded decimal arithmetic. It says the instruction is intended to be run right after an addition or subtraction instruction.
My questions are:
what happens if it is run after another instruction?
how does it know what instruction preceeded it?
I realise there is the N flag - but this surely wouldnt definitively indicate that the previous instruction was an addition or subtraction instruction?
Does it just modify the accumulator anyway, based on the conditions set out in the DAA table, regardless of the previous instruction?
Does it just modify the accumulator anyway, based on the conditions set out in the DAA table, regardless of the previous instruction?
Yes. The documentation is only telling you what DAA is intended to be used for. Perhaps you are referring to the table at this link:
--------------------------------------------------------------------------------
| | C Flag | HEX value in | H Flag | HEX value in | Number | C flag|
| Operation | Before | upper digit | Before | lower digit | added | After |
| | DAA | (bit 7-4) | DAA | (bit 3-0) | to byte | DAA |
|------------------------------------------------------------------------------|
| | 0 | 0-9 | 0 | 0-9 | 00 | 0 |
| ADD | 0 | 0-8 | 0 | A-F | 06 | 0 |
| | 0 | 0-9 | 1 | 0-3 | 06 | 0 |
| ADC | 0 | A-F | 0 | 0-9 | 60 | 1 |
| | 0 | 9-F | 0 | A-F | 66 | 1 |
| INC | 0 | A-F | 1 | 0-3 | 66 | 1 |
| | 1 | 0-2 | 0 | 0-9 | 60 | 1 |
| | 1 | 0-2 | 0 | A-F | 66 | 1 |
| | 1 | 0-3 | 1 | 0-3 | 66 | 1 |
|------------------------------------------------------------------------------|
| SUB | 0 | 0-9 | 0 | 0-9 | 00 | 0 |
| SBC | 0 | 0-8 | 1 | 6-F | FA | 0 |
| DEC | 1 | 7-F | 0 | 0-9 | A0 | 1 |
| NEG | 1 | 6-F | 1 | 6-F | 9A | 1 |
|------------------------------------------------------------------------------|
I must say, I've never seen a dafter instruction spec. If you examine the table carefully, you will see that the effect of the instruction depends only on the C and H flags and the value in the accumulator -- it doesn't depend on the previous instruction at all. Also, it doesn't divulge what happens if, for example, C=0, H=1, and the lower digit in the accumulator is 4 or 5. So you will have to execute a NOP in such cases, or generate an error message, or something.
Just wanted to add that the N flag is what they mean when they talk about the previous operation. Additions set N = 0, subtractions set N = 1. Thus the contents of the A register and the C, H and N flags determine the result.
The instruction is intended to support BCD arithmetic but has other uses. Consider this code:
and 15
add a,90h
daa
adc a,40h
daa
It ends converting the lower 4 bits of A register into the ASCII values '0', '1', ... '9', 'A', 'B', ..., 'F'. In other words, a binary to hexadecimal converter.
I found this instruction rather confusing as well, but I found this description of its behavior from z80-heaven to be most helpful.
When this instruction is executed, the A register is BCD corrected using the contents of the flags. The exact process is the following: if the least significant four bits of A contain a non-BCD digit (i. e. it is greater than 9) or the H flag is set, then $06 is added to the register. Then the four most significant bits are checked. If this more significant digit also happens to be greater than 9 or the C flag is set, then $60 is added.
This provides a simple pattern for the instruction:
if the lower 4 bits form a number greater than 9 or H is set, add $06 to the accumulator
if the upper 4 bits form a number greater than 9 or C is set, add $60 to the accumulator
Also, while DAA is intended to be run after an addition or subtraction, it can be run at any time.
This is code in production, implementing DAA correctly and passes the zexall/zexdoc/z80test Z80 opcode test suits.
Based on The Undocumented Z80 Documented, pag 17-18.
void daa()
{
int t;
t=0;
// 4 T states
T(4);
if(flags.H || ((A & 0xF) > 9) )
t++;
if(flags.C || (A > 0x99) )
{
t += 2;
flags.C = 1;
}
// builds final H flag
if (flags.N && !flags.H)
flags.H=0;
else
{
if (flags.N && flags.H)
flags.H = (((A & 0x0F)) < 6);
else
flags.H = ((A & 0x0F) >= 0x0A);
}
switch(t)
{
case 1:
A += (flags.N)?0xFA:0x06; // -6:6
break;
case 2:
A += (flags.N)?0xA0:0x60; // -0x60:0x60
break;
case 3:
A += (flags.N)?0x9A:0x66; // -0x66:0x66
break;
}
flags.S = (A & BIT_7);
flags.Z = !A;
flags.P = parity(A);
flags.X = A & BIT_5;
flags.Y = A & BIT_3;
}
For visualising the DAA interactions, for debugging purposes, I have written a small Z80 assembly program, that can be run in an actual ZX Spectrum or in an emulation that emulates accurately DAA: https://github.com/ruyrybeyro/daatable
As how it behaves, got a table of flags N,C,H and register A before and after DAA produced with the aforementioned assembly program: https://github.com/ruyrybeyro/daatable/blob/master/daaoutput.txt

Resources