According to the GameBoy manual, these instructions are as follows:
rla 17 4 000c rotate akku left through carry
rl r CB 1x 8 z00c rotate left through carry
However, I'm having hard time understanding the difference between them from the implementation point of view. Can someone clarify?
RL sets Z flag depending on the result.
RLA clears Z regardless of the result.
Other than that they're identical in their implementation.
Related
I am trying to write a simulator for a RISC-V CPU and can not find a definitve answer to my question.
Let's say I want to use
ANDI rs1, rd, 0xFFF
with rs1 containing 0xFFFFFFFF and the immediate value being 0xFFF.
Does the ANDI operate on the full register and just fill the remaining 20 bit of the immediate with zeros so the result in rd will be 0x000000FFF?
Or are the higher 20 bits ignored and the result in rd will still be 0xFFFFFFFF?
Same question for XORI and ORI commands.
The Immediate value is sign extended,
12 bit FFF will translate to 32'hFFFFF_FFF for RV32
so the values being AND-ed will be
rs1_data & 0xFFFFF_FFF
I am interested in knowing correlation in points between 0 to 2km on a linear network. I am using the following statement for empirical data, this is solved in 2 minutes.
obs<-linearK(c, r=seq(0,2,by=0.20))
Now I want to check the acceptance of Randomness, so I used envelopes for the same r range.
acceptance_enve<-envelope(c, linearK, nsim=19, fix.n = TRUE, funargs = list(r=seq(0,2,by=0.20)))
But this show estimated time to be little less than 3 hours. I just want to ask if this large time difference is normal. Am I correct in my syntax to the function call of envelope its extra arguments for r as a sequence?
Is there some efficient way to shorten this 3 hour execution time for envelopes?
I have a road network of whole city, so it is quite large and I have checked that there are no disconnected subgraphs.
c
Point pattern on linear network
96 points
Linear network with 13954 vertices and 19421 lines
Enclosing window: rectangle = [559.653, 575.4999] x
[4174.833, 4189.85] Km
thank you.
EDIT AFTER COMMENT
system.time({s <- runiflpp(npoints(c), as.linnet(c));
+ linearK(s, r=seq(0,2,by=0.20))})
user system elapsed
343.047 104.428 449.650
EDIT 2
I made some really small changes by deleting some peripheral network segments that seem to have little or no effect on the overall network. This also lead to split some long segments into smaller segments. But now on the same network with different point pattern, I have even longer estimated time:
> month1envelope=envelope(months[[1]], linearK ,nsim = 39, r=seq(0,2,0.2))
Generating 39 simulations of CSR ...
1, 2, [etd 12:03:43]
The new network is
> months[[1]]
Point pattern on linear network
310 points
Linear network with 13642 vertices and 18392 lines
Enclosing window: rectangle = [560.0924, 575.4999] x [4175.113,
4189.85] Km
System Config: MacOS 10.9, 2.5Ghz, 16GB, R 3.3.3, RStudio Version 1.0.143
You don't need to use funargs in this context. Arguments can be passed directly through the ... argument. So I suggest
acceptance_enve <- envelope(c, linearK, nsim=19,
fix.n = TRUE, r=seq(0,2,by=0.20))
Please try this to see if it accelerates the execution.
On the page 87 of the Game Boy CPU Manual it is claimed that the CP n instruction sets the carry flag when there was no borrow and that it means that A < n. This seems to conflict itself, because the carry flag is set when A > n.
An example: If A=0 and B=1, CP B sets the flags like SUB A, B, which is 0 - 1. This becomes 0 + 255 = 255 and the carry flag is not set, even though A < B.
I came across this same issue in other Z80 documents as well, so I don't believe this is a typo.
Am I misunderstanding how borrow and SUB work or is there something else going on? Is SUB not equal to ADD with two's complement in terms of flags?
The GameBoy CPU manual has it backwards. SUB, SBC and CP all set the carry flag when there is borrow. If SUB/SBC/CP A,n is executed then carry is set if n > A otherwise it is clear.
This is consistent with Z-80 (and 8080) operation. As well MAME and MESS implement carry the same way.
The Game Boy Z80 CPU has a half-carry flag, and I can't seem to find much information about when to set/clear it.
What I understand so far is that any 8-bit add, subtract, shift, or rotate operation (and maybe others?) set it to bit 4 of the result(?), and the DAA instruction sets/uses this somehow. What I'm not sure is how 16-bit instructions affect it and whether it's affected or not by the use of certain registers.
It's the carry from bit 3 to bit 4, just like the normal carry flag records carry from bit 7. So, e.g. to get the half carry bit in an add:
((a&0xf) + (value&0xf))&0x10
Which gives 0x10 if half carry should be set, 0 otherwise. Getting half carry from the other relevant ops follows naturally - the questions is whether there was carry from the low nibble to the high.
To put things in perspective, the z80 has a 4bit ALU and performs 8bit ops by doing two 4bit ops. So it gets half carry very naturally, as an intermediate result.
DAA is interested in the flag because if half carry is set then two digits that add up to more than 16 were added in the low nibble; that will have correctly produced carry into the upper nibble but will have left the low nibble 6 lower than it should be, since there were six more values between 10, when it should have generated carry, and 16, when it did.
For 16-bit operations, the carry from bit 3 to bit 4 in the register's high byte sets the flag. In other words, bit 11 to bit 12.
(Note the above bits are labeled 0-15, from least to most significant)
See here: http://www.z80.info/z80code.htm
16 bit arithmetic
If you want to add numbers that are more than the 0-255 that can
be stored in the A register, then the HL, IX or IY registers can
be used. Thus LD HL,1000H:LD BC,2000H:ADD HL,BC will give
A CZPSNH BC DE HL IX IY A' CZPSNH' BC' DE' HL' SP
00 000000 2000 0000 3000 0000 0000 00 000000 0000 0000 0000 0000
The flags are set as follows.
C or carry flag 1 if answer >65535 else 0
Z or zero flag not changed
P flag not changed
S or sign flag not changed
N flag 0
H or half carry flag 1 if carry from bit 11 to bit 12 else 0
Since the half-carry flag is one of the most common stumbling blocks for Game Boy emulator makers, I'll take the liberty to post a link to a recent question of mine regarding the subject as an answer:
Game Boy: Half-carry flag and 16-bit instructions (especially opcode 0xE8)
A summary of the above thread (answer by #gekkio):
It depends on the instruction, but the flags are always updated based on the same bit positions if you think in terms of 8-bit values...it just varies whether we're talking about the high or low byte of the 16-bit value. Bit 11 is just bit 3 of the high byte.
ADD SP, e: H from bit 3, C from bit 7 (flags from low byte op)
LD HL, SP+e: H from bit 3, C from bit 7 (flags from low byte op)
ADD HL, rr: H from bit 11, C from bit 15 (flags from high byte op)
INC rr: no flag updates (executed by the 16-bit inc/dec unit)
DEC rr: no flag updates (executed by the 16-bit inc/dec unit)
I am taking a class in microprocessing, and having some trouble writing a program that will hold a value in a port for two seconds before moving on to the next port.
Can any one help this make more sense?
I have thought of using NOP but realized thats a bit unrealistic, I have tried ACALL DELAY but for some reason its pulling up as an unknown command.
I am stumped at this point and would appreciate any help I could get.
I am using the DS89C450 With a clock of 11 MHz, i've tried asking the professor and he tells me its a peice of cake you should have this no problem, but reading and writing code is breand new to me ive only been doing it for two weeks. when i look at the book its almost like it written in chinese its hard to make sense of it, my fellow class mates are just as stummped as i am, i figured my final resort would be to ask someone online that might of had a similar problem or someone who has a little more insight that might be able to pont me in the right direction.
I know i need to load each port with the specified value my problems lies in the switching of the ports giving them the 2 second delay.
My program look likes this MOV P0, #33H MOV P1, #7FH MOV P2, B7H MOV P3, EFH so with these four ports being loaded with these values i need P0 to go to P1, P1-P2 and so on when getting to P3 its value needs to go to P0 and loop it all. i was going to use SJMP to loop it back to the start so the program is always running
While doing this there is the two second delay where each value only stays in each port for only two seconds thats what still fuzzy, does the rest sound right ?
i have done something similar in PIC 16f84 micro-controller
to make a delay you have 2 ways either use interrupts or loops
since you know the Instructions_per_second you can use a loop to generate the required number of instructions that takes the required time
this link illustrates how to determine the loop indexes (as you might need nested loops if the number of instructions required is required .. in PIC i had to make 1 million instruction to make a delay of 1 second)
I've never done this with that particular chip (and I don't know the assembly syntax it supports), but a pseudocode approach would be something like this:
Load initial values into ports
Initialize counter with (delay in seconds * clock ticks per second) / (clock ticks in loop)
While counter != 0
Decrement counter
Swap port values:
P3 -> temp, P2 -> P3, P1 -> P2, P0 -> P1, temp -> P0
Loop (4 times?)
I think this is all you really need for structure. Based on my 10 minute reading on 8051 assembly, the delay loop would look like:
MOV A, b6h ; ~91 ticks/sec # 11 ms/tick
DELAY: DEC A
JNZ DELAY ; NOP-type delay loop