dreamcast development • homebrew software • hardware hacking • indie games • emulators • and more!
Back to main site
It is currently Sun Feb 25, 2018 6:55 pm

All times are UTC - 8 hours [ DST ]

Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Sun Sep 24, 2017 7:37 am 
Insane DCEmu
Insane DCEmu

Joined: Sat Jul 27, 2013 11:16 am
Posts: 165
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 :
   XOR R2, R2
      XOR R1, R1
      ADD R2, R1     
      ADD R8, R1     
      MOV.L R1, @R1
   ADD R3, R2         
   CMP/EQ R10, R2

With those parameter values :

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 + 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 :)


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

QUESTION.JPG [ 99.14 KiB | Viewed 257 times ]
Reply with quote  
PostPosted: Sun Sep 24, 2017 9:38 pm 
The Crabby Overlord
The Crabby Overlord
User avatar

Joined: Mon May 27, 2002 9:31 am
Posts: 5235
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.

Reply with quote  
PostPosted: Wed Sep 27, 2017 9:50 am 
Insane DCEmu
Insane DCEmu

Joined: Sat Jul 27, 2013 11:16 am
Posts: 165
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 :)

Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 8 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

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:  
Powered by phpBB® Forum Software © phpBB Group