Tursi Posted January 31, 2020 Share Posted January 31, 2020 (edited) 2 hours ago, senior_falcon said: Just curious to know what part of the statement you disagree with. That CALL LOAD is not usable for strings. Loops work just fine in XB. Accessing the original string, sure, but on other systems where you have to poke arguments, people* just allocate a fixed memory space for the string to be copied to by the caller. It's slightly wasteful, not terribly convenient, but it's not the end of the world for simple functions. However, I wouldn't want to do that for the many string functions in Missing Link, thus I agreed with your second statement. (* - people - well, okay, me. Once. ) Edited January 31, 2020 by Tursi Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 31, 2020 Author Share Posted January 31, 2020 18 hours ago, senior_falcon said: If this can be made to work, then The Missing Link, T40XB and others could be used with a compiled XB program. Pronouns can be tricky devils. Just to be clear, here my use of "this" means if the utilities NUMASG, STRREF, etc. can be made to interface with a compiled program. That way in the compiled program the assembly subroutines would be used exactly the same as they would be used in XB. So CALL LINK("CIRCLE", 100,100,50) would work the same when compiled as it does when running TML. The more I ponder this the more hopeful I become. 7 Quote Link to comment Share on other sites More sharing options...
majestyx Posted January 31, 2020 Share Posted January 31, 2020 14 hours ago, RXB said: Hmmm RXB has CALL MOVES that does exactly that. Moves hex strings or strings to or from any memory to or from any String Variable. To bad so much resistance to RXB, it has most of the solutions. Well, my baseball sim is on hold for the next version of RXB which will hopefully allow me to utilize SAMS in a simpler way. It's fully functional right now but doesn't have nearly the statistical depth that I'd like for it to have. I'm using T40XB for my Choose-You-Own-Adventure style game because it makes accessing 40 columns easy, along with screen formatting subprograms which make it ideal for this type of a game. I've attempted learning FB-Forth as suggested by that language's author, but just learning it and implementing it is a pretty huge task for what I am trying to accomplish, especially with limited time to dedicate to this & other projects I'd like to work on. Oh if only I was independently wealthy with all the time in the world... ? 5 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 31, 2020 Share Posted January 31, 2020 1 hour ago, senior_falcon said: Pronouns can be tricky devils. Just to be clear, here my use of "this" means if the utilities NUMASG, STRREF, etc. can be made to interface with a compiled program. That way in the compiled program the assembly subroutines would be used exactly the same as they would be used in XB. So CALL LINK("CIRCLE", 100,100,50) would work the same when compiled as it does when running TML. The more I ponder this the more hopeful I become. Perhaps you could get at the passed parameters without using NUMASG, STRREF, etc. as I did in this post. ...lee Quote Link to comment Share on other sites More sharing options...
+RXB Posted January 31, 2020 Share Posted January 31, 2020 (edited) 15 hours ago, senior_falcon said: If I am running a compiled program (i.e. an XB program that has been converted to assembly language) exactly how would MOVES be of any use in transferring a string from the compiled program into an assembly language support subprogram?? So this does not run from a XB module using CALL LINKS? (If you can do a CALL LINK you can do a CALL MOVES using RXB, up to you which one saves code.) If it is totally Assembly with no XB access good luck that looks like a ton of more code to make. Edited January 31, 2020 by RXB comment added Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 7, 2020 Author Share Posted February 7, 2020 Back to making good progress on XB 2.8 G.E.M. Thanks to Sometimes99 I was able to expand the fonts to a total of 60. You can see that I chose complete fonts - i.e. both upper and lower case characters except for fonts 33 and 34. It was tough having to eliminate 87 percent of those fonts, but more than 60 seems obsessive compulsive. The Missing Link has been expanded to include Missing Link extras (plus a few more subroutines) which are now available at any time without having to load them into high memory and embed them with your program. It took a while to create the tools needed to test and debug this change. This seems to work perfectly. Now to go back to the start menu and make some revisions to my code. Then to add XB256, T40XB. I want to have XB 2.8 + XXB as an entry in the menu instead of doing it with CALL XXB. After that I hope to be able to add the assembly language loader for CALL LOAD to replace the slow GPL one that is normally with XB. 6 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted February 7, 2020 Share Posted February 7, 2020 Any chance the compiler could support RXB in the future? 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 7, 2020 Author Share Posted February 7, 2020 52 minutes ago, Vorticon said: Any chance the compiler could support RXB in the future? Nope. I suppose it could be done (not by me), but then your program size would necessarily have to be smaller. There's the trade-off. More features vs less program space. 1 Quote Link to comment Share on other sites More sharing options...
+RXB Posted February 7, 2020 Share Posted February 7, 2020 5 hours ago, senior_falcon said: Nope. I suppose it could be done (not by me), but then your program size would necessarily have to be smaller. There's the trade-off. More features vs less program space. Using SAMS this would not be a issue in XB or RXB, but then XB has no SAMS support so that is a big problem. I do suppose it would best attack long term as if memory is lacking, using 1Meg added memory is the best approach. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 10, 2020 Author Share Posted February 10, 2020 I am excited by some performance improvements I've been making to The Missing Link. I've taken out some VSBW and VSBR routines and replaced them with faster routines. The short video below shows the original TML on the left and the improved version on the right. Both are running the start of the TMLDEMO program. Although I start the left program first, the right hand one quickly overtakes it. I think you'll agree that this is a nice performance improvement. 10 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted February 10, 2020 Share Posted February 10, 2020 Nice! Will programs created with the original TML still work with the GEM version? I'm thinking of Orbital Rendez-vous which is very slow and could definitely benefit from performance improvements. Orbit.dsk 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 10, 2020 Author Share Posted February 10, 2020 27 minutes ago, Vorticon said: Nice! Will programs created with the original TML still work with the GEM version? I'm thinking of Orbital Rendez-vous which is very slow and could definitely benefit from performance improvements. Orbit.dsk 180 kB · 2 downloads Should work fine. The only thing that could cause problems is if you use direct PEEKs or POKEs. Because the memory locations of the code are different the addresses would be wrong. Once this is done I will give your program a try. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted February 10, 2020 Share Posted February 10, 2020 1 hour ago, senior_falcon said: Should work fine. The only thing that could cause problems is if you use direct PEEKs or POKEs. Because the memory locations of the code are different the addresses would be wrong. Once this is done I will give your program a try. Sounds good. Thanks! Here's a video of the program for speed comparison: 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 10, 2020 Author Share Posted February 10, 2020 You probably won't see much difference with this. It looks like you are plotting single pixels. The calculations for the pixels are in XB and there would be no speed gain there. And the bottleneck with PIXEL is the CALL LINK which is way slower than a couple of VSBW operations. I have hopes that it will be possible to use your own CALL LINKs with compiled code and that would be a big help for a program like this. 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted February 10, 2020 Share Posted February 10, 2020 1 hour ago, senior_falcon said: You probably won't see much difference with this. It looks like you are plotting single pixels. The calculations for the pixels are in XB and there would be no speed gain there. And the bottleneck with PIXEL is the CALL LINK which is way slower than a couple of VSBW operations. I have hopes that it will be possible to use your own CALL LINKs with compiled code and that would be a big help for a program like this. You are probably right. The largest factor affecting performance is likely the many floating point calculations required for each pixel plot and not so much the plotting process itself although it would be nice to speed that up as well. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 11, 2020 Share Posted February 11, 2020 14 hours ago, Vorticon said: Sounds good. Thanks! Here's a video of the program for speed comparison: Nice program, but it seems... just a bit subliminal... I couldn't help but notice, the... seeming parallel to cellular biology. Even w/o considering the "pink syringe"! 1 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 25, 2020 Author Share Posted February 25, 2020 XB 2.8 G.E.M. is coming along nicely. The Missing Link and The Missing Link Graphic Adventure have been adapted to the new environment and seem to work fine. I do have a problem with XB256, which uses the interrupt routine to see if the character set is being loaded. Now the XB code is loading the font from cartridge ROM instead of using the console GPL routines. If the font is being loaded, XB256 knows that the program has broken for some reason (Fctn 4, an error, a break point) and checks whether the program was using Screen2. If so then Screen2 is stored to RAM and replaced with Screen1. There is an XML routine in cartridge ROM that moves the selected font to VDP ram. I think this problem can be fixed if I can find a way to ensure that upon return to GPL the LIMI 2 at >0070 always executes the interrupt routine pointed to by >83C4. One way might be to put in a delay loop before returning. Perhaps checking VSYNC would work. For example: VDPSTA EQU >8802 VSYNC CLR R12 VSYNC1 TB 2 * Test CRU bit for VDP interrupt JEQ VSYNC1 * Loop if not set MOVB @VDPSTA,R0 * Need to clear the status register ANDI R0,>2000 * Isolate collision flag MOV R0,@COINC * Save collision flag B *R11 COINC DATA >0000 When TB 2 is set will that force LIMI 2 to always perform the interrupt routine? Or better yet, could I set the CRU bit and force the interrupt routine to happen? Any ideas?? 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 25, 2020 Share Posted February 25, 2020 3 hours ago, senior_falcon said: When TB 2 is set will that force LIMI 2 to always perform the interrupt routine? Or better yet, could I set the CRU bit and force the interrupt routine to happen? If you set bit 2, you enable the interrupt sense of the 9901. Setting the bit does not trigger an interrupt. The VDP interrupt output is routed to the interrupt 2 input of the 9901. If bit 2 is set to 0, no interrupt will be triggered. However, you can still read the value via TB (as it is the level of the VDPINT line). If you set it to 1, the 9901 will trigger an interrupt at the CPU (hardcoded level 1) when the VDPINT line becomes active. You can disable the VDPINT line using video register 1. When disabled, no VDP interrupts will ever occur, independent of LIMI and bit 2. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 25, 2020 Author Share Posted February 25, 2020 (edited) I guess my question can be stated much more simply: 1 - How does LIMI 2 know when it is time to do the interrupt routine? 2 - Is there anything I can do to be sure the interrupt routine is performed at the next LIMI 2? Edited February 25, 2020 by senior_falcon Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 25, 2020 Share Posted February 25, 2020 The interrupts of the 9900 are level-triggered, which means that as long as the input line is asserted, the interrupt will occur as soon as the interrupt mask allows it. Suppose the VDP asserts the VDPINT* line; this line goes to the 9901. If bit 2 has been set before, lowering to 0 means that the 9901 will trigger an interrupt. This interrupt goes via the EXTINT* line to the 9900, and the level is set to 1 by the ICx lines. This EXTINT* line is continuously pulled down until you clear the interrupt in the VDP. If you have LIMI 0, the interrupt is not sensed by the CPU. As soon as you set the mask to 2, this is higher than the actual interrupt level, and this will trigger the interrupt microprogram as soon as the current microprogram (current instruction) has completed. The interrupt is triggered by the asserted EXTINT* line. If you do a LIMI 2 without this line being asserted (0), no interrupt will occur. You could do the following: - Do a LIMI 0 - Poll bit 2 - As soon as it cleared, do a LIMI 2. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 26, 2020 Author Share Posted February 26, 2020 (edited) This test program seems to do what I want. The LIMI2L loop is performed until the interrupt routine sets the flag in R1 so it is no longer zero. The LIMI2L loop is exited and the loop counter sent back to XB. When you run the program 10 CALL LINK("LIMI2T",X)::PRINT X the loop counter shows that LIMI 2 has been performed many times, usually in the hundreds. Uncommenting the 3 lines at LIMIL1 makes that loop happen until bit 2 is set. Then the LIMI 2 is performed and the interrupt routine is executed first time, every time, which you know because X is always 1. Many thanks to Mizapf for your help on this! (Mizapf's suggestion was to loop until bit 2 was cleared, then do the LIMI 2. That did not work, but it does work if you loop until bit 2 is set.) All's Well That Ends Well, as the bard said. I think I read that this method does not work with the F18A. Any truth to this? XMLLNK EQU >2018 NUMASG EQU >2008 DEF LIMI2T WKSP BSS 32 WKSP IS AT >24F4 LIMI2T LWPI WKSP CALL LINK("LIMI2T",X) LI R2,ROUTIN MOV R2,@>83C4 start interrupt routine CLR R0 loop counter CLR R1 flag-will loop until r1<>0 LIMI2L INC R0 increment counter *LIMIL1 CLR R12 * TB 2 read cru bit * JEQ LIMIL1 loop until not zero LIMI 2 LIMI 0 MOV R1,R1 r1 will remain zero until interrupt routine has run JEQ LIMI2L still zero, keep looping LIMI3 MOV R0,@>834A move the counter to FAC BLWP @XMLLNK DATA >0020 cif convert to floating point CLR R0 LI R1,1 BLWP @NUMASG send loop counter back to XB LWPI >83E0 B @>006A return to XB *************************** ROUTIN INC @>24F6 interrupt routine-increments R1 to be <>0 B *R11 END Edited February 26, 2020 by senior_falcon Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 26, 2020 Share Posted February 26, 2020 Looks good. By the way, my explanation was correct (wait until the bit is cleared), but this is a typical misunderstanding of TB. It sets the EQ bit to the value that it read. Hence, the comment should read "loop while the bit is 1". Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 26, 2020 Author Share Posted February 26, 2020 Seems inverted to me, but then I never had a good grasp of CRU stuff. From the thread F18A MK2, post #593: "The AVPC can allow motherboard writes to the 9918 within the first 16K? Interrupts are no longer synchronized with VSYNC if the 9918 generates them." I am not sure what this means, but since the AVPC is not the F18A, it sounds as if my method in post #146 above should work fine with the F18A. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 27, 2020 Share Posted February 27, 2020 There are no issues with F18A interrupts that I'm aware of, anyway. If it didn't work the same way as the 9918A does, it wouldn't work in all the various systems, cause they all abuse interrupts differently. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 27, 2020 Author Share Posted February 27, 2020 (edited) Many, many thanks to Mizapf and Tursi for their assistance! XB256 is now working properly with XB 2.8. The problem was solved this way: 1 - at the end of the font loading assembly routine in cartridge ROM I added: LOOP CLR R12 TB 2 JEQ LOOP B *R11 When this returns to the XB GPL code, it is set up to run the interrupt routine at the first LIMI 2 2 - Then in my interrupt routine I added: LI R8,>8300 MOVB @>8373,@MONWS+17 (lsb of R8) now r8 has the stack pointer MOV *R8,R8 see what the stack is pointing to CI R8,>981A if it is >981a then Xb is loading a font due to break, end or ?? JNE MONIT1 XB is not loading font, so go on Now check if we're in screen 2 and if so then swap the screens. Edited February 27, 2020 by senior_falcon 3 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.