Any of you RLP experts want to lend me a hand? I’ve got the emulator working perfectly in regular NETMF and as far as I can see my RLP port’s methods [em]seem[/em] fine but the result is a blank screen. I’m sure there some small error in the way I’m passing variables or something.
Post a bit of your code, then we see.
Heh, it’s 4k lines in RLP alone. But, let’s say we take a look at one of my Ref replacements. 
C#
case 0x01: // LD BC,NN
LoadImmediate(ref B, ref C);
break;
[...]
private void LoadImmediate(ref int rh, ref int rl)
{
rl = ReadByte(PC++);
rh = ReadByte(PC++);
ticks += 10;
}
RLP
case 0x01: // LD BC,NN
LoadImmediate2(&B, &C);
break;
[...]
void LoadImmediate2(int *rh, int *rl)
{
*rl = ReadByte(PC++);
*rh = ReadByte(PC++);
ticks += 10;
}
If I remember right, only arrays are treated like ref.
just put the two ints into an int[].
in C it is an int* then.
actually all C functions need to look like this:
int YourFunc(void** args)
to get an int do like this:
int arg1 = (int)(args[0]);
an int array (which can act as ref) is like this:
int* arg1 = (int*)(args[0]);
This document helps actually a lot:
https://www.ghielectronics.com/docs/50/rlp#461
These are not being passed into RLP but are defined in RLP itself and modified by RLP. I can’t just put the 2 ints into an array because they could be any two ints. One could be the result of a read request for example or the value on an interrupt.
If we think it’s that I can change every ref to do a return result and in the case of multiple refs use global temp values.
Hmm, if its from C to C then it actually looks fine.
What is the return type of ReadByte()?
if it’s not int, then try to add an actual cast to int like:
@ Reinhard Ostermeier - Yes, it is an int. I also tried removing all refs, no help.
Again, the file is huge. Is there a specific portion that would be good to post?
Really hard to say why the variable values are not returned.
Have you somehow checked if this is really the case?
I know debugging RLP is not easy. You need to get creative.
@ Skewworks - The function you posted is just fine.
What I have done in the past with large RLP developments (I did a ZX Spectrum emulator on the Spider, also a Z80 CPU) is write the code in VC++ as a desktop application isolating all the hardware specific pieces (screen access etc.) into separate functions. That way I can test and debug as required then once I am certain the core works I move the code over to my RLP project with the hardware specific pieces replaced with implementations for the target device.
For most things however what I do is just have a little utility function that writes out to the serial port and then sprinkle calls to that throughout my code to debug it. I open the serial port etc. in managed code so the routine to write to the serial port is just a matter of writing to the serial transfer register.
I do not have any code in front of me now, but I have posted some samples of this on these forums.
Unfortunately I’m in CA again and don’t have a serial with me. I’m doing this the very long.
I have a full NETMF version and a full RLP version. I’m replacing NETMF with RLP one opcode at a time. I know read and write work beyond a doubt (and dear lord did that test take forever). So I’m guessing the issue must lie in the ref methods somewhere.
On we go…
You’re a sick person…
1 Like
The only cure is more cowbell.
On another note…
You sum of which!
*r++ is bad, [em]umkay[/em]. *r += 1 is just fine. But never, ever, ++.
I guess it’s because I was using C instead of C++.
[I’m a dad, I will make Dad jokes as often and as poorly as I like]
*r++ equals *(r++): ++ has a higher priority, and therefor you 1st move the pointer and then access the value at the new position.
what should be able to write instead of *r += 1 is (*r)++ I guess.
Fun with pointers: Once I was really good at this, but with excessive C#ing I forget a lot. ???
*r++ means get the value (return it if it’s used in an expression) and after that increment the pointer (not the value!).
(*r)++ means get the value (return it if it’s used in an expression), increment it (not the pointer) and set it back in memory at that pointer.
Being a post increment operator both *r++ and *(r++) will dereference the current pointer and then move the pointer address in ‘r’.
I know. With the brackets in this sample I wanted to make more clear to @ skewworks what this does.
Later in my post I wrote “(*r)++” is the working one.
Thanks for the info! Turns out, I had actually already done that on my full port and just missed it during the step by step testing.
I’m more than half way through the 512opcodes and have yet to find anything that stops it running. Of course I did have to lit stuff in arrays to test this way that I normally didn’t. If that turns out to be the issue in going to same some rather harsh things under my breath…and the play a lot of gameboy games on my Raptor.
I had no doubt that you knew that, it is just that others might be confused because your wording is incorrectly indicating that the new position is dereferenced, which is not the case with the post increment operator.
Every OpCode passed…
3 Likes
@ taylorza - You are right. ++ is always executed after everything else in the statement.
So the “only” problem with *r++ is that instead of the value of r, the pointer is incremented.
So a general rule should be: If you’re not sure, use braces.