+TheBF Posted June 9, 2022 Share Posted June 9, 2022 5 minutes ago, GDMike said: I tried using DBF0(R5) and changing the value of R5 as a pointer during an incrementing of R5 for 4 increments pushing a different value into DBF0, which is a memory EQU label. But when I tested to view the memory addresses manually, they did not show the values that I stored at DBF0 + the value of R5, or the next address of DBF0 which is pointing to>79D6, I dunno why. But I have an idea to just move the 4 bytes that happen Prior to my larger loop that isn't mentioned here, straight to high ram. The only difference here is that I was gonna do the move after gathering the complete loop iterations, but I can handle it this way. From your writeup it sounds like you are trying to change an EQU. You need to be sure there is "DATA" at that specific address named with an equate. It might be better to use a label at the DATA or BSS statements? So the code needs to be something like: (not tested) DBF0 DATA 0000,0000,0000,0000 INITS LI R1, >994A CLR R5 LOOP1 MOV R1,DBF0(R5) INCT R5 CI R5, 6 JNE LOOP1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 9, 2022 Share Posted June 9, 2022 16 minutes ago, GDMike said: I tried using DBF0(R5) and changing the value of R5 as a pointer during an incrementing of R5 for 4 increments pushing a different value into DBF0, which is a memory EQU label. But when I tested to view the memory addresses manually, they did not show the values that I stored at DBF0 + the value of R5, or the next address of DBF0 which is pointing to>79D6, I dunno why. But I have an idea to just move the 4 bytes that happen Prior to my larger loop that isn't mentioned here, straight to high ram. The only difference here is that I was gonna do the move after gathering the complete loop iterations, but I can handle it this way. You need to insure that DBF0 is not being changed by something else. It might be better to make DBF0 the label for the block of data you are writing: DBF0 BSS 1024 reserve 1 KiB block for data [I see @TheBF beat me to my recommendation so it must be good advice!] ...lee 1 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 9, 2022 Share Posted June 9, 2022 Just now, Lee Stewart said: You need to insure that DBF0 is not being changed by something else. It might be better to make DBF0 the label for the block of data you are writing: DBF0 BSS 1024 reserve 1 KiB block for data [I see @TheBF beat me to my recommendation so it must be good advice!] ...lee Some code would help!! ...lee 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted June 9, 2022 Share Posted June 9, 2022 1 minute ago, Lee Stewart said: You need to insure that DBF0 is not being changed by something else. It might be better to make DBF0 the label for the block of data you are writing: DBF0 BSS 1024 reserve 1 KiB block for data [I see @TheBF beat me to my recommendation so it must be good advice!] ...lee I've been hanging around you long enough now that I'm starting to catch on. 3 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 9, 2022 Share Posted June 9, 2022 35 minutes ago, GDMike said: I tried using DBF0(R5) and changing the value of R5 as a pointer during an incrementing of R5 for 4 increments pushing a different value into DBF0, which is a memory EQU label. But when I tested to view the memory addresses manually, they did not show the values that I stored at DBF0 + the value of R5, or the next address of DBF0 which is pointing to>79D6, I dunno why. But I have an idea to just move the 4 bytes that happen Prior to my larger loop that isn't mentioned here, straight to high ram. The only difference here is that I was gonna do the move after gathering the complete loop iterations, but I can handle it this way. 19 minutes ago, TheBF said: From your writeup it sounds like you are trying to change an EQU. I agree with @TheBF. You cannot change what DBF0 points to. If it points to >79D6 at assembly time, it will always point to >79D6. We need code to assess what it is you are attempting! ...lee 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 9, 2022 Share Posted June 9, 2022 46 minutes ago, GDMike said: ... I dunno why. But I have an idea to just move the 4 bytes that happen Prior to my larger loop that isn't mentioned here, straight to high ram. The only difference here is that I was gonna do the move after gathering the complete loop iterations, but I can handle it this way. It is certainly fine to try a different tack, but you really do need to track down your errors and misconceptions. That is what makes you a better programmer. So, once again, we need the code. ...lee 2 Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 9, 2022 Share Posted June 9, 2022 What Lee said! Post a snippet of the code in question! 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 (edited) I'd have to figure a good way to snippet. I can screen shot easily, but cutting and pasting actually text is cumbersome . Ill just type it here Edited June 9, 2022 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 (edited) DBF0 EQU >79D6 ... ... BLWP @VSBR CLR R5 Movb R1,@DBF0(R5) * 1st byte into address >79D6 INC R5 SWPB R0 * move to MSB MOV R0,@DBF0(R5) * 2nd byte, cursor location into address >79D7 INC R5 SWPB R2 * move to MSB MOVB R2,@DBF0(R5) * R2 value of field length into address >79D8 And that's the gist of it. Edited June 9, 2022 by GDMike Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 9, 2022 Share Posted June 9, 2022 I had hoped that by just you meant... 3.PRINTING having been adjusted so that the print fills a space evenly or forms a straight line at one or both margins. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 9, 2022 Share Posted June 9, 2022 This, I can attempt to understand at a glance... DFBO EQU >79D6 BLWP @VSBR CLR R5 MOVB R1,@DBF0(R5) * 1st byte into address >79D6 INC R5 SWPB R0 * move to MSB MOV R0,@DBF0(R5) * 2nd byte, cursor location into address >79D7 INC R5 SWPB R2 * move to MSB MOVB R2,@DBF0(R5) * R2 value of field length into address >79D8 And that's the gist of it. ---------------------------------------------------------------------------------------------- What you posted above, I must attempt to recognize ...leaving far less of the expanse of my mind available for comprehension. Thus, arriving at a level, beneath that which I can determine is reasonably befitting of my serious consideration. Many lines of spacing between code, disorderly alignment, and NeeDleSs case variations, can itself, seem diffusing to the point of abandon. ...Just me... 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 (edited) It's not a snipet. It's just typed in on my phone. Just remember, li is the same as LI or load immediate and mov in this scenario is really the same as MOV, and etc. I might not have capitalized each instruction, and I might not have exactly the recommended spacing between operands. I'm not needing a part of code rebuilt, just trying to understand the incrementing of the address for my next move instruction. Yes. Just you..I guess because I think I said I was just going to type in what I was essentially trying to accomplish without getting and making it too complicated, guess I made it complicated. Edited June 9, 2022 by GDMike 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 9, 2022 Share Posted June 9, 2022 Maybe MOV R0,@DBF0(R5) should be MOVB R0,@DBF0(R5) ? 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 9, 2022 Share Posted June 9, 2022 Oh, and... as for constantly editing the code that is currently under consideration. ...(no comment) Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 (edited) I did try Both, the non swapping of registers and doing a mov but of course that's going to be 2 bytes, so I expected to read every other byte in my test to verify, Yes tried that. Edited June 9, 2022 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 First let me say, it's really hard to explain by typing... but with that said, I do have a work around by just creating 4 equate statements instead of trying to move 4 individual bytes this way. And of course that puts my data directly into the addresses I need. But like willsy said, it be nice to know why something doesn't work. Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 Someone mentioned doing a BSS would accomplish this, I haven't tried but I agree, I think I could get my data pushed that way too. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 9, 2022 Share Posted June 9, 2022 MOV R0,@DBF0(R5) won't work because it will write MSB to >79d6 (overwriting the first byte you wrote) and LSB to >79d7. What do you have in R0 anyway, the address you just used for BLWP @VSBR? 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 Thx for trying to understand this, I understand having a look at the code would help too. I'll just do 4 equates and press on. Thank you.. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 (edited) 7 minutes ago, Asmusr said: MOV R0,@DBF0(R5) won't work because it will write MSB to >79d6 (overwriting the first byte you wrote) and LSB to >79d7. What do you have in R0 anyway, the address you just used for BLWP @VSBR? That's probably the issue, because I was hoping (R5) was pointing to address>79D7 and I didn't care about the LSB because the next Instruction would take care of that by pushing into>79D8. Edit: I mean (R5) would allow for pointing to the next address. Edited June 9, 2022 by GDMike Edit for clarity Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 I'll try to upload the file section, but it won't be a snipet. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 9, 2022 Share Posted June 9, 2022 (edited) 9 minutes ago, GDMike said: That's probably the issue, because I was hoping (R5) was pointing to address>79D7 and I didn't care about the LSB because the next Instruction would take care of that by pushing into>79D8. If you try to write to an odd address using MOV you will write to the (one lower) even address instead. If you want to write the MSBs of R0, R1 and R2 to >79D6, >79D7, and >79D6 you can also do it like this: LI R5,DFB0 MOVB R0,*R5+ MOVB R1,*R5+ MOVB R2,*R5 Edited June 9, 2022 by Asmusr Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 heres the file the issue is located at label INT2, this is where the main loop will be. in the file im using MOV R0,@DBF0+R5+ a number, but was looking at trying to do a (R5) as my address pointer, i just didnt change it in this file... EXTR 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 2 minutes ago, Asmusr said: If you try to write to an odd address using MOV you will write to the (one lower) even address instead. If you want to write the MSBs of R0, R1 and R2 to >79D6, >79D7, and >79D6 you can also do it like this: LI R5,DFB0 MOVB R0,*R5+ MOVB R1,*R5+ MOVB R2,*R5 didnt think about it that way. Ill have to study it. that is prob what I want! ty Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 9, 2022 Author Share Posted June 9, 2022 1 minute ago, GDMike said: didnt think about it that way. Ill have to study it. that is prob what I want! ty i was just going to intentionally write to MSB and not care about the odd byte because I was hoping to write to the MSB of the even byte in each case, so I knew that part, BUT when I read the locations manually I didnt get the MSB of what i wrote. possibly I wasnt reading the address correctly as well. But i see what your saying here 1 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.