Jump to content
swapd0

Another jaguar bug?

Recommended Posts

I've the following code in my sound engine, it's using u253se. The d0 has a sound channel (4 to 7) and d1 holds a sample number. It always hangs.

 

; register sound
	move.b d1,channel_sound(pc,d0.w)
	move.b d0,sound_channel(pc,d1.w)

Even this version hangs, WTF!?!?!

; register sound
	moveq #0,d0
	moveq #0,d1
	move.b d1,channel_sound(pc,d0.w)
	move.b d0,sound_channel(pc,d1.w)

As you can see I'm writing bytes so there are no problems about alignment, anyway I've a .long directive before channel_sound definition.

 

But, I've done a quick test with this code and it works...

 

; register sound
	moveq #0,d0
	moveq #0,d1
	move.w d1,channel_sound(pc,d0.w)
;	move.b d0,sound_channel(pc,d1.w)

There are any problem with byte memory access from the 68000? I don't understand why it hangs, if I comment the code it works.

 

Share this post


Link to post
Share on other sites

VASM and 68000

error 9 in line 1 of "test.s": instruction not supported on selected architecture
>       move.b d1,channel_sound(pc,d0.w)

error 9 in line 2 of "test.s": instruction not supported on selected architecture
>       move.b d0,sound_channel(pc,d1.w)

 

  • Like 2

Share this post


Link to post
Share on other sites

Yeah, he's clearly not using vasm. 😄

It's generating something and silently dropping the errors. That can be a pain if you aren't fluent in 680x0 and don't realize what you're doing wrong.

 

  • Like 2

Share this post


Link to post
Share on other sites

If you want to check functionality of 68K and be able to step through it to make sure it's doing what you expect I highly recommend Easy68K.. it's a full featured 68000 simulator, and you can step through instructions, monitor memory etc.  Really handy.

I assume you are building up a SE command, would it not be faster to combine the values with or and only write to memory once (well 2x 16bit words) rather than a bunch of individual 8 bit writes.

  • Like 1

Share this post


Link to post
Share on other sites

Just for the record, I find it really hard to believe rmac is assembling that code without errors given that here I get "Error: inappropriate addressing mode" when I try to assemble the snippets above.

 

The only assembler I've seen assembling code even if it has errors is GNU AS (which is horrible!).

 

One thing to check, are you sure you're not getting errors and using an older .o file produced by rmac?

Share this post


Link to post
Share on other sites
23 hours ago, LinkoVitch said:

If you want to check functionality of 68K and be able to step through it to make sure it's doing what you expect I highly recommend Easy68K.. it's a full featured 68000 simulator, and you can step through instructions, monitor memory etc.  Really handy.

I assume you are building up a SE command, would it not be faster to combine the values with or and only write to memory once (well 2x 16bit words) rather than a bunch of individual 8 bit writes.

Nope, I'm not building a SE command, that comes a bit later in the code, but it's executed each time that I play a new sounds.

 

Maybe I'm using an older version of rmac, mine it's 1.13.6.

Share this post


Link to post
Share on other sites
23 hours ago, swapd0 said:

Maybe I'm using an older version of rmac, mine it's 1.13.6.

This is weird because there has never been v1.13.6: version went from 1.13.5 to 2.0.0 ;). But I reverted to roughly that point in the repository and built rmac - sure enough it is perceived as legit code. You are encouraged to update to the latest version here as we fixed this and added a bunch more fun stuff like the ability to assemble a binary without header at a fixed address (-fr)!

Share this post


Link to post
Share on other sites
2 hours ago, ggn said:

This is weird because there has never been v1.13.6: version went from 1.13.5 to 2.0.0 ;). But I reverted to roughly that point in the repository and built rmac - sure enough it is perceived as legit code. You are encouraged to update to the latest version here as we fixed this and added a bunch more fun stuff like the ability to assemble a binary without header at a fixed address (-fr)!

Maybe I changed the version from 1.13.5 to 1.13.6 because a few months ago I had to compile it and change the line number from short to int because I was checking a disassembled file and I got errors with weird line number.

Share this post


Link to post
Share on other sites
11 hours ago, swapd0 said:

Maybe I changed the version from 1.13.5 to 1.13.6 because a few months ago I had to compile it and change the line number from short to int because I was checking a disassembled file and I got errors with weird line number.

Okay, makes sense! Please feel free to submit an issue and fixes in our [url=http://rmac.is-slick.com/contact/contact/]bug tracker[/url] so that everyone would benefit from your fixes :).

Share this post


Link to post
Share on other sites
8 hours ago, ggn said:

Okay, makes sense! Please feel free to submit an issue and fixes in our [url=http://rmac.is-slick.com/contact/contact/]bug tracker[/url] so that everyone would benefit from your fixes :).

I'm a bit busy now and not I'm sure how to upload a patch and if I can do it, anyway I've changed the following, tested and work with huge files.

 

File token.c line 25 -> uint16_t curlineno; -> uint32_t curlineno;

File token.h line 157 -> uint16_t curlineno; -> uint32_t curlineno;

 

Share this post


Link to post
Share on other sites
13 hours ago, LinkoVitch said:

Wow, that must be a huge file to need more than 65535 lines :)

9.2MB and 153,798 lines

Edited by swapd0
  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites
23 minutes ago, swapd0 said:

9.2MB and 153,798 lines

OUCH!

I'd hate to work on something like that, much prefer chopping my source into smaller more manageable chunks and using include to combine them.  I find it makes it easier to find the bits I am looking for.  Would also make VCS like git store more data as it will save the whole file for a single character change.

  • Like 1

Share this post


Link to post
Share on other sites

Just to avoid to open a new topic.

 

Sometimes when I load a partial CLUT I got some colors wrong, anyone has the same problem? Sometimes it works, others it fails. This is the source code.

 

void set_palette(int16_t index, int16_t items, uint16_t *color)
{
	volatile uint16_t *clut = (uint16_t *)CLUT + index;
	while ( items-- )
		*clut++ = *color++;
}

Maybe it's better to update the CLUT on the vbl interrupt?

Edited by swapd0

Share this post


Link to post
Share on other sites
8 hours ago, swapd0 said:

Just to avoid to open a new topic.

 

Sometimes when I load a partial CLUT I got some colors wrong, anyone has the same problem? Sometimes it works, others it fails. This is the source code.

 

void set_palette(int16_t index, int16_t items, uint16_t *color)
{
	volatile uint16_t *clut = (uint16_t *)CLUT + index;
	while ( items-- )
		*clut++ = *color++;
}

Maybe it's better to update the CLUT on the vbl interrupt?

Well, I would check the index value...

Do you have the "Sometimes when I load a partial CLUT I got some colors wrong" calling code?

 

 

Share this post


Link to post
Share on other sites

What I don't understand its that I call that code at the beginning of the game to upload the palette, I have a 128 color palette and some 16 colors palette, the same code it's called with the same values at the start, but sometimes I get some colors wrong (usually it works fine). WTF!?

 

I change the correct color index but sometimes the RGB color it's wrong.

 

Tomorrow I'll try to log all palette changes to see what happened, but the code it's too simple to be wrong.

Share this post


Link to post
Share on other sites

I've included the log code and I get this, as you can see I upload the same palette for both images, but I get different result, the good one it's with the dark blue sky, the other one I got a black sky (sometimes with vertical blue lines WTF!?!?).

 

Sorry for the bad quality of the images.

first picture
palette 144 (16)
1302 0ac2 0c06 1f0e 472d def6 2608 2649 2fca 2f49 2588 c9b2 0081 09c2 1304 1c86 
palette 160 (16)
0000 0981 00c0 ffff 0040 12c1 1241 0000 f800 12c2 1302 cfc0 fe80 fc00 f800 f81f 

second picture
palette 144 (16)
1302 0ac2 0c06 1f0e 472d def6 2608 2649 2fca 2f49 2588 c9b2 0081 09c2 1304 1c86 
palette 160 (16)
0000 0981 00c0 ffff 0040 12c1 1241 0000 f800 12c2 1302 cfc0 fe80 fc00 f800 f81f

 

 

 

IMG_1528.thumb.JPG.0e9e36052030f5dc23b41cf8b1aeed5f.JPGIMG_1527.thumb.JPG.c20e79b0e26fa59e6cc444282205168b.JPG

 

Edited by swapd0

Share this post


Link to post
Share on other sites
16 hours ago, Welshworrier said:

Looks more like a 16 bit addition issue - you've got a pointer that will be 32 bit (even if it is a pointer to an unsigned integer) and are then adding a 16 bit value to it.

IIRC with pointer maths (it's been a while :) ) but whilst a pointer is itself 32bit, an increment with ++ will increment the pointer by it's type size (assuming it's a typed pointer).  So a Uint16_t* will increase by 2 bytes irrespective of if the pointer itself is 32 or 64bit.

 

I *think* that's correct :D

  • Like 1

Share this post


Link to post
Share on other sites

I don't understand that usually it works, but some times I get some colors bad, for example the buildings in blue instead of black. It should work always or never, because I upload the same palette on the same color index.

 

Share this post


Link to post
Share on other sites

I have no idea what is happening under your code (the assembly the compiler generates).. I wonder if there is some issue with making word (16bit) length writes to the CLUT? Or perhaps the compiler is using long writes and sometimes either the source or destination is not fully long aligned?  I have had weird corruption with misaligned longs on the DSP RISC.

In your picture examples I see no differences in the palette codes, are these values being read from the CLUT? or your source palettes?  I assume they are the source palettes.. can you read the values from the CLUT and see how it has been corrupted?  Might help identify what is going on.

The index value you are passing in I assume is a multiple of 2?  Otherwise you are going to end up with a target address that is odd.. if not then I would suggest you add on

 

 (index << 1)

 

rather than just index when setting the CLUT pointer.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...