Writing some values in memory using assembly

[Newbie]

Hello everybody,

I tried last week a code to compute some things and write result values sequentially using a loop to a field of bytes in main memory at a certain start address.

At the very beginning the field of bytes is full of garbage values.

After the code was uploaded via serial cable to Dreamcast, I dumped the ram location where the code wrote : I noticed weird results in some place.

I tried to investigate my code to find out what part of code produced errors.
Little by little I reduced the size of code when I realized that the problem occurred since the first main loop of code.

Here is some details to understand the topic :

The field of bytes the code try to write could be seen as an array of lines of N bytes starting at a certain address.

Thus the field of bytes that is modified in ram is defined by
- a start address
- the number of bytes per line
- the total number of bytes in the field

The code I use to test the "write to ram" code is a very simple code that make my field of bytes starting at 0x8C0102B4 and having 3696 (0xE70) bytes length dispatched in 77 lines of 48 (0x30) bytes.

Something like that :

Line number Address
Line 1 0x8C0102B4
....
....
Line 77 0x8C011024 = 0x8C0102B4 + 0xE70

The code is something like this :

Code: Select all

MOV.L START_ADDRESS, R8
	MOV.L BYTES_COUNT, R10 
	MOV.L BYTES_COUNT_PER_LINE, R3"); 
	XOR R2, R2
	
	LOOP:
		
		XOR R1, R1
		ADD R2, R1      
		ADD R8, R1      
		MOV.L R1, @R1
		
	ADD R3, R2         
	CMP/EQ R10, R2
	BF LOOP

With those parameter values :

START_ADDRESS : 0x8C0102B4
BYTES_COUNT : 0xE70
BYTES_COUNT_PER_LINE : 0x30

To debug, I write the value of R1 at the address pointing by R1 (MOV.L R1, @R1) :
as R1 = R8 (start address) + R2 ( N X BYTES_COUNT_PER_LINE), it will write START_ADDRESS + N * BYTES_COUNT_PER_LINE (N being index from 0 to 76).

So when I dump ram it should be :

Address -------------------------------------- Line number------Value written (R1)
START_ADDRESS -------------------------------line 0------------ 0x8C0102B4
START_ADDRESS + 1 * BYTES_COUNT_PER_LINE
START_ADDRESS + 2 * BYTES_COUNT_PER_LINE
START_ADDRESS + 3 * BYTES_COUNT_PER_LINE
START_ADDRESS + 4 * BYTES_COUNT_PER_LINE
...
START_ADDRESS + 76 * BYTES_COUNT_PER_LINE--line 76----------0x8C0110F4

But strangely, when I dump my bytes field from Dreamcast to see what happens,
I found that some locations are not updated and keep their original garbage value.

At line 59 and 60 there is no update : the code seems to not be able to write at those locations so garbage values are kept.

Then line 61 and 62 are updated with correct values.

Then line 63 and 64 are not updated : the code seems to not be able to write at those locations so again garbage values are kept.

Finally from line 65, all lines are updated to the end with correct values (line76).

I am confused because the code does not produce exception like odd address write or read,
it run with expected values since line 0 to line 58.

I do not see error on the loop code : it rather simple.

If the main loop code was bad, all values will be strange but written.

If the main loop code was bad from a specific line all values after this line should be bad but written.

I don't find why and how to correct it.

All information would be appreciated

Thanks.

I paste a shot with the first 4 bytes of each line of the field of bytes dumped from memory to illustrate.

[BlueCrab]

My guess would be that it's some sort of cacheing issue. Try reading/writing to addresses in the 0xAC range instead of 0x8C (just literally replace the 8s with As -- they're actually the same physical location in RAM).

I don't recall exactly how exiting from a running program back to dcload-serial proceeds, but it will probably disable the cache in the process to erase the operand and instruction caches in the simplest manner. Thus anything that didn't get flushed back out of the operand cache before that will forever be lost at that point, and unable to be fetched by way of reading memory through dcload/dc-tool.

[Newbie]

Well, replacing 0x8C0102B4 by 0xAC0102B4 in my code solves the issue.

Dumping either from 0x8C0102B4 or 0xAC0102B4 locations gave the same consistent result.

It is certainly, like you said, a data cache issue linked to the unknown behavior of serial upload tool about managing that.

Thanks again