swapd0 Posted July 3, 2020 Share Posted July 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted July 3, 2020 Share Posted July 3, 2020 The destination EA cannot be PC relative, only the source. No telling what the assembler is generating for the opcodes. Quote Link to comment Share on other sites More sharing options...
Cyprian Posted July 3, 2020 Share Posted July 3, 2020 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) 3 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted July 3, 2020 Share Posted July 3, 2020 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. 3 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted July 4, 2020 Author Share Posted July 4, 2020 I'm using rmac. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 4, 2020 Share Posted July 4, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Cyprian Posted July 4, 2020 Share Posted July 4, 2020 or just use the latest Steem SSE Debuger with nice windowed GUI Quote Link to comment Share on other sites More sharing options...
ggn Posted July 5, 2020 Share Posted July 5, 2020 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? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted July 5, 2020 Author Share Posted July 5, 2020 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted July 6, 2020 Share Posted July 6, 2020 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)! Quote Link to comment Share on other sites More sharing options...
swapd0 Posted July 6, 2020 Author Share Posted July 6, 2020 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted July 7, 2020 Share Posted July 7, 2020 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 :). Quote Link to comment Share on other sites More sharing options...
swapd0 Posted July 7, 2020 Author Share Posted July 7, 2020 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; Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 7, 2020 Share Posted July 7, 2020 Wow, that must be a huge file to need more than 65535 lines Quote Link to comment Share on other sites More sharing options...
swapd0 Posted July 8, 2020 Author Share Posted July 8, 2020 (edited) 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 July 8, 2020 by swapd0 1 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 8, 2020 Share Posted July 8, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 28, 2020 Author Share Posted December 28, 2020 (edited) 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 December 28, 2020 by swapd0 Quote Link to comment Share on other sites More sharing options...
matmook Posted December 28, 2020 Share Posted December 28, 2020 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? Quote Link to comment Share on other sites More sharing options...
Welshworrier Posted December 28, 2020 Share Posted December 28, 2020 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. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 29, 2020 Author Share Posted December 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 29, 2020 Author Share Posted December 29, 2020 (edited) 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 Edited December 29, 2020 by swapd0 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 29, 2020 Author Share Posted December 29, 2020 I've added some routines to delay the palette changes to the vbl irq and for now it looks that it works. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted December 29, 2020 Share Posted December 29, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 29, 2020 Author Share Posted December 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted December 29, 2020 Share Posted December 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.