Willsy Posted November 1, 2012 Share Posted November 1, 2012 Woohoo! :thumbsup: Let the bug-hunting begin! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 1, 2012 Author Share Posted November 1, 2012 Woohoo! :thumbsup: Let the bug-hunting begin! OK, this will obviously take longer than I thought. I can't even get past the initialization phase! I am trying to automate the loading of the FPLTF's object file (FPLTFO). When I run the following from a BLOCKS file via 10 LOAD , it appears to be doing something to VDP RAM because the screen starts changing colors and blinking. There's nothing loaded at 2000h in CPU RAM. And, the dictionary entry for FPLLNK following the E/A-option-3 loader is a constant with a blank name and a value of 0: S" DSK1.FPLTFO" #3LOAD Should I have known it would do this? How do I remedy this situation? ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 1, 2012 Author Share Posted November 1, 2012 (edited) Hey, @Willsy... ASM>CODE seems to be emitting signed code again. ...lee Edited November 1, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2012 Share Posted November 1, 2012 The value $A032 in ProcessWord (two instances) on block 30 should be changed to A03E. That should do it! A consequence of adding extra pointers etc... Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2012 Share Posted November 1, 2012 OK, this will obviously take longer than I thought. I can't even get past the initialization phase! I am trying to automate the loading of the FPLTF's object file (FPLTFO). When I run the following from a BLOCKS file via 10 LOAD , it appears to be doing something to VDP RAM because the screen starts changing colors and blinking. There's nothing loaded at 2000h in CPU RAM. And, the dictionary entry for FPLLNK following the E/A-option-3 loader is a constant with a blank name and a value of 0: S" DSK1.FPLTFO" #3LOAD Should I have known it would do this? How do I remedy this situation? ...lee No it shouldn't do that. It sounds like it's incorrectly decoding the tags in the object file. I wonder if there are any 0 length records? I wonder what #GET would make of that (0==65536) ? Can you please send me the object file? Also, try modifying this line in the ParseLine word of the loader: ASCII 9 OF @Num DUP $. H ! ENDOF That will show you where it's writing data. Something is very off, because it's hitting VDP ram... Well, of course the records are read into VDP ram first by DSRLNK... I'm wondering if it's going wrong before the loader (i.e. in #GET)... I thought the file words were pretty solid though. Are you using any other directives in your code other than AORG and DEF? RORG etc are not supported, as far as I know. I haven't examined the tags generated for RORG. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 1, 2012 Author Share Posted November 1, 2012 (edited) The value $A032 in ProcessWord (two instances) on block 30 should be changed to A03E. That should do it! A consequence of adding extra pointers etc... There are 3 instances. Change all of them? Edited November 1, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2012 Share Posted November 1, 2012 Yep. Sorry, 3 instances! One saves the current value, the other changes it, the last restores it. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 1, 2012 Author Share Posted November 1, 2012 No it shouldn't do that. It sounds like it's incorrectly decoding the tags in the object file. I wonder if there are any 0 length records? I wonder what #GET would make of that (0==65536) ? Can you please send me the object file? Also, try modifying this line in the ParseLine word of the loader: ASCII 9 OF @Num DUP $. H ! ENDOF That will show you where it's writing data. Something is very off, because it's hitting VDP ram... Well, of course the records are read into VDP ram first by DSRLNK... I'm wondering if it's going wrong before the loader (i.e. in #GET)... I thought the file words were pretty solid though. Are you using any other directives in your code other than AORG and DEF? RORG etc are not supported, as far as I know. I haven't examined the tags generated for RORG. I haven't checked your suggestions yet; but, I can tell you that it works just fine from the command line. I was thinking that the fact the input buffer is in VDP RAM when it's interpreting a block might have something to do with it. Object file is attached: FPLTFO.zip ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2012 Share Posted November 1, 2012 I haven't checked your suggestions yet; but, I can tell you that it works just fine from the command line. I was thinking that the fact the input buffer is in VDP RAM when it's interpreting a block might have something to do with it. Object file is attached: FPLTFO.zip ...lee :-o :-o That's worrying I'll have a look... Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2012 Share Posted November 1, 2012 Bah.... It's this sequence in block 49... #3fn DROP SWAP CMOVE As you correctly surmised, it fails to take account of the fact that the input buffer is in VDP while loading... Let's see... BLK @ 0> IF #3fn DROP SWAP CMOVE ELSE #3fn drop swap vmbr then Or something like that - unfortunately I'm out of time - I'm in Paris at the mo for a big meeting tomorrow so need to get some beauty sleep! Nearly midnight here! I jut tried the above but it changes the screen colour as you observed. Bloody strange! Looking in the debug window of classic99, it's putting the records read from the file in VDP at >1828 - so there's no reason I can currently see for it to change vdp registers and thus change the screen colour.... But I can clearly see VDP registers 6 and 7 changing... Very odd... I'll have to have a look tomorrow on the flight back! Sorry I can't be of further help this evening... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 1, 2012 Author Share Posted November 1, 2012 Bah.... It's this sequence in block 49... #3fn DROP SWAP CMOVE As you correctly surmised, it fails to take account of the fact that the input buffer is in VDP while loading... Let's see... BLK @ 0> IF #3fn DROP SWAP CMOVE ELSE #3fn drop swap vmbr then Or something like that - unfortunately I'm out of time - I'm in Paris at the mo for a big meeting tomorrow so need to get some beauty sleep! Nearly midnight here! I jut tried the above but it changes the screen colour as you observed. Bloody strange! Looking in the debug window of classic99, it's putting the records read from the file in VDP at >1828 - so there's no reason I can currently see for it to change vdp registers and thus change the screen colour.... But I can clearly see VDP registers 6 and 7 changing... Very odd... I'll have to have a look tomorrow on the flight back! Sorry I can't be of further help this evening... No prob. I can work around it for quite awhile. I really don't need it to work like that until testing is finished. It would just be more convenient. Thanks for all your efforts. It makes all my monkeying around worth the effort! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Hey Lee, I just looked at the object file you sent to me. It looks like it's a compressed object file. The loader doesn't compressed object files. The compressed files use a binary format, rather than a text format, so the loader will just see gobbledeegook! Edit: I've been looking at the file you sent to me... I don't know what type of file it is, but it doesn't look correct to me. Please see the attached screenshot. The file on the left is FPLTF which you sent on the 28th. The file on the right is the one you sent last night. When I look at last nights file in a hex editor (very nice free one here) I see it is in fact uncompressed, but all the record formatting is wrong, and there is a load of binary 0's at the start of the file. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 (edited) Hey Lee, I just looked at the object file you sent to me. It looks like it's a compressed object file. The loader doesn't compressed object files. The compressed files use a binary format, rather than a text format, so the loader will just see gobbledeegook! Edit: I've been looking at the file you sent to me... I don't know what type of file it is, but it doesn't look correct to me. Please see the attached screenshot. The file on the left is FPLTF which you sent on the 28th. The file on the right is the one you sent last night. When I look at last nights file in a hex editor (very nice free one here) I see it is in fact uncompressed, but all the record formatting is wrong, and there is a load of binary 0's at the start of the file. Here's another with both the TI file and the OBJ file. Both are re-assembled and emitted by TI99dir. FPLTFO was copied by TI99dir from the DSK image where Asm994a copied it. They are the same to Classic99 and TI99dir. FPLTFO is probably in V9T9 format. Sorry for the confusion, but I don't think that is the problem. FPLLNK, near the end of the file, gets put into the dictionary just fine and the first 2 bytes at 2000h are correct. ...lee FPLTFO.zip Edited November 2, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Why are you writing the object file to a DSK image and then using TI99DIR to copy it out again? Just have the assembler write object file *directly* into the desired DSK folder in Classic99. See how I have my test harness configured in the screen shot below. I press the START button in the ASM994A assembler, and the object file is written directly to Classic99. Classic99 can then load it with the editor assembler, or the TF loader. No intermediate steps. I'm sure that's where things are going wrong! Don't make me ask you for the source code!!! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 Why are you writing the object file to a DSK image and then using TI99DIR to copy it out again? Just have the assembler write object file *directly* into the desired DSK folder in Classic99. See how I have my test harness configured in the screen shot below. I press the START button in the ASM994A assembler, and the object file is written directly to Classic99. Classic99 can then load it with the editor assembler, or the TF loader. No intermediate steps. I'm sure that's where things are going wrong! Don't make me ask you for the source code!!! I respectfully disagree; however, I will do it your way. ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 Why are you writing the object file to a DSK image and then using TI99DIR to copy it out again? Just have the assembler write object file *directly* into the desired DSK folder in Classic99. See how I have my test harness configured in the screen shot below. I press the START button in the ASM994A assembler, and the object file is written directly to Classic99. Classic99 can then load it with the editor assembler, or the TF loader. No intermediate steps. I'm sure that's where things are going wrong! Don't make me ask you for the source code!!! I respectfully disagree; however, I will do it your way. ...lee Nope. That's not it. Loading with S" DSK1.FPLTF.OBJ" #3LOAD through a block LOAD , does the same thing to VDP RAM. ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Here's another with both the TI file and the OBJ file. Both are re-assembled and emitted by TI99dir. FPLTFO was copied by TI99dir from the DSK image where Asm994a copied it. They are the same to Classic99 and TI99dir. FPLTFO is probably in V9T9 format. Sorry for the confusion, but I don't think that is the problem. FPLLNK, near the end of the file, gets put into the dictionary just fine and the first 2 bytes at 2000h are correct. ...lee FPLTFO.zip Thanks for the files. The .obj file looks fine, the FPLTFO file is in a strange format (maybe V9T9, as you say)... I see a configuration option in classic99 for "treat files without extension as text files" but it doesn't seem to make any difference. In any case, the other file in the zip (the .obj) looks just fine, but it still goes banana's when I try to load it. Hmmm... This is interesting... Back to the source code! Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Nope. That's not it. Loading with S" DSK1.FPLTF.OBJ" #3LOAD through a block LOAD , does the same thing to VDP RAM. ...lee Yeah, it goes bonkers eh? ... Nice and colourful though! I'm bug hunting right now! Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Okay, just want to clear up some confusion (on my part). You're quite correct, Lee. The File that you got via TI99DIR is indeed a V9T9 file (Classic99 says so in the debug window). Whilst it looks strange in a text editor, Classic99 is happy to work with it. I just wrote a very quick problem to simply open the file and display it: block 51: ----------- fbuf: mybuf s" dsk2.fpltfo SIDF80" mybuf FILE \ SIDF80 = sequential input display fixed 80 : test mybuf #open abort" cant open file" begin mybuf #eof? not while pad mybuf #get drop pad count type repeat mybuf #close ; The above is able to read and display both types of files correctly. So it's not your files! Apologies! Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Bah! Spent hours going 'round in circles. The biggest problem is that I've forgotten a lot of how my stuff works! The "problem" wasn't a bug as such (no code changes in TF required). The problem is NUMBER. NUMBER is intelligent - if BLK <> 0 then it looks in VDP otherwise it looks in CPU. When launched from a block then of course BLK is !=0 and so it looked in VDP at the address that I gave it... However, the address I gave it was the address of PAD (because I read each line in from disk into PAD). PADs address is >A2xx. That would mean the most significant bit is on. NUMBER then treats this as a VDP address... The MSB being on meant that the write to the VDP address register was interpreted as a VDP register operation, and... well... the whole thing just fell on its arse! But the problem was between the chair and the keyboard. A victim of my own design and my own bad memory. I got around it by saving BLK to the return stack, zeroing it and restoring it just before #3LOAD exits. Works like a champ. I tried both the files that you sent today, both from a block and from the command line. Both worked and loaded into memory correctly. Blocks file attached. The loader is in blocks 48 and 49. Exhausted! BLOCKS.zip Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 Bah! Spent hours going 'round in circles. The biggest problem is that I've forgotten a lot of how my stuff works! The "problem" wasn't a bug as such (no code changes in TF required). The problem is NUMBER. NUMBER is intelligent - if BLK <> 0 then it looks in VDP otherwise it looks in CPU. When launched from a block then of course BLK is !=0 and so it looked in VDP at the address that I gave it... However, the address I gave it was the address of PAD (because I read each line in from disk into PAD). PADs address is >A2xx. That would mean the most significant bit is on. NUMBER then treats this as a VDP address... The MSB being on meant that the write to the VDP address register was interpreted as a VDP register operation, and... well... the whole thing just fell on its arse! But the problem was between the chair and the keyboard. A victim of my own design and my own bad memory. I got around it by saving BLK to the return stack, zeroing it and restoring it just before #3LOAD exits. Works like a champ. I tried both the files that you sent today, both from a block and from the command line. Both worked and loaded into memory correctly. Blocks file attached. The loader is in blocks 48 and 49. Exhausted! Thank you so much! Very much appreciated! :thumbsup: ...lee Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 (edited) Floating Point Library (FPLTF)--- I am starting to slog through the testing. If I set a breakpoint at 2000h in Classic99, I would expect the FPLLNK @@ BLWP, in the following code to stop Classic99 when the branch is taken: \ link to Floating Point Library for TurboForth \ ---expects FAC, ARG and _fpstr already set up ASM: goFPL ( FPL_fxn -- ) *SP+ R0 MOV, \ get function # to R0 R1 _fpstr LI, \ point R1 to FP string buffer whether we need it or not FPLLNK @@ BLWP, \ link to FPL R1 STST, \ get FP status R1 FPSTAT @@ MOV, R0 FPERR @@ MOV, \ get FP error ;ASM It doesn't. I must be doing something wrong. FPLLNK is a constant with a value of 2000h. Any ideas? ...lee Edited November 2, 2012 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 Execution doesn't "go to" 2000h - that's the address of the vector for BLWP. Yout need to set a breakpoint that matches the of address specified in your vector! Also ensure the debugger is fully enabled. Press scroll lock then home. That fully enables the debugger. In my experience just invoking the debugger from the menu does not enable breakpoints *unless* scroll lock is enabled. Hope this helps! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 2, 2012 Author Share Posted November 2, 2012 Execution doesn't "go to" 2000h - that's the address of the vector for BLWP. Yout need to set a breakpoint that matches the of address specified in your vector! Also ensure the debugger is fully enabled. Press scroll lock then home. That fully enables the debugger. In my experience just invoking the debugger from the menu does not enable breakpoints *unless* scroll lock is enabled. Hope this helps! Doh! Sometimes I feel so stupid. I knew that about scroll lock. It's just not automatic, yet. I had set breakpoints at 2000h and 2008h and, as you said, Classic99 didn't stop until it hit 2008h. Thanks, again! ...lee Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2012 Share Posted November 2, 2012 R1 STST, Is that what you want? You're fetching the status register from TurboForth's context, not your fp context. If you want the status register from the fp context then you need to save it somewhere prior to the return to tf context( I. E prior to the rtwp instruction on the FP side) Hope I'm not teaching you to suck eggs here! 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.