RXB Posted April 7, 2019 Share Posted April 7, 2019 (edited) We must be looking at the wrong thing, cause 83A0 is not listed in there... >83A0 is the value stack or Register 0 as that is in the source code showing it fetches a value from XB and puts it there. From what I can figure out the issue I am having is without name for passing values from XB to Assembly it crashes. CAlL LINK(address) from RXB works perfect but once any value is passed/received it locks up computer. When I run this: 10 CALL INIT 20 CALL LINK("RASMUS") the value "RASMUS" can be found at >082A in VDP RAM. You also get a SUBPROGRAM NOT FOUND error, of course. The error is caused in Assembly not in GPL or VDP. When only a CALL LINK(address) is used it just returns fine and no problems in my new CAlL LINK written in GPL. When CALL LINK(address,variable) is used it locks up computer and as I can not look at >83A0 (value Data Stack) I can not tell what is wrong? Also there is NOTHING AT >0958 the VDP value stack so what the hell is going on? Edited April 7, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 7, 2019 Author Share Posted April 7, 2019 Right... but I don't see any emulation issues. I'm sure you're looking in the wrong place. In regular XB, you read your CALL LINK arguments using the list at >8300. I would expect that's the same in RXB. Have a look at the attached - it's a rough disassembly of the XB utilities. I know I've used STRREF for sure. I don't think I've ever tried to pull LINK arguments without the utilities. XBDUMP.TXT 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 8, 2019 Share Posted April 8, 2019 Right... but I don't see any emulation issues. I'm sure you're looking in the wrong place. In regular XB, you read your CALL LINK arguments using the list at >8300. I would expect that's the same in RXB. Have a look at the attached - it's a rough disassembly of the XB utilities. I know I've used STRREF for sure. I don't think I've ever tried to pull LINK arguments without the utilities. XBDUMP.TXT I am pretty sure I have done it without the utilities. If I find the thread, I will let you know. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 8, 2019 Share Posted April 8, 2019 I am pretty sure I have done it without the utilities. If I find the thread, I will let you know. ...lee Here it is: TI MiniMemory programs and the post that follows it. I used the VRAM argument stack pointer >8310 to dereference the arguments in the CALL LINK() argument list. ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted April 8, 2019 Share Posted April 8, 2019 Right... but I don't see any emulation issues. I'm sure you're looking in the wrong place. In regular XB, you read your CALL LINK arguments using the list at >8300. I would expect that's the same in RXB. Have a look at the attached - it's a rough disassembly of the XB utilities. I know I've used STRREF for sure. I don't think I've ever tried to pull LINK arguments without the utilities. XBDUMP.TXT I am pretty sure this is a problem with Assembly return to XB, it assumed NAME LINK ONLY. The reason why my CALL LINK(adddress) works is upon return to XB value stack is empty so no crash. But if variables follow address it crashes as no name is on stack to remove it locks up as there is no Assembly solution. Assembly is looking for something not needed, and assumes any call uses a name. I would have to fix CALL INIT source Assembly as it can not deal with change. Quote Link to comment Share on other sites More sharing options...
RXB Posted April 8, 2019 Share Posted April 8, 2019 (edited) Here it is: TI MiniMemory programs and the post that follows it. I used the VRAM argument stack pointer >8310 to dereference the arguments in the CALL LINK() argument list. ...lee Thanks but I am in XB not Mini Memory. The problem is in XB Assembly CALL INIT that handles link variables by assuming a name not address was used. Thus a lock up of computer it just gets in a loop of black screen. Name search is way slower and wastes 6 bytes for a name, my solution was just 2 bytes address only. With 30 names that would be (6+2)*30=240 bytes, my solution was address only 2*30=60 bytes. Normal XB is CALL LINK("name") uses 8 bytes, while RXB 2019 is CALL LINK(address) uses 2 bytes. This is like most other computers that use address not names for doing a assembly link. Edited April 8, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 8, 2019 Share Posted April 8, 2019 Thanks but I am in XB not Mini Memory. You obviously did not read the referenced posts. Unfortunately, the code is for TI Basic, so it will not work as written for XB. However, with the right EQUates, it should work just fine for XB. I am reasonably sure I did it for XB, too. I will post the code if I find it. And—Rich, considering that this CALL LINK() problem is not a Classic99 problem, we probably should create another topic to work on its solution to avoid further hijacking @Tursi’s “Classic99 Updates”. ...lee 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 8, 2019 Share Posted April 8, 2019 You obviously did not read the referenced posts. Unfortunately, the code is for TI Basic, so it will not work as written for XB. However, with the right EQUates, it should work just fine for XB. I am reasonably sure I did it for XB, too. I will post the code if I find it. And—Rich, considering that this CALL LINK() problem is not a Classic99 problem, we probably should create another topic to work on its solution to avoid further hijacking @Tursi’s “Classic99 Updates”. ...lee Right, I kept getting a Classic99 lockup so assumed it was Classic99 as no keys in Classic99 worked. Even when you clicked on anything it would not work except closing Classic99 window. So it broke something so badly I could not even get Classic99 to stop it. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 8, 2019 Author Share Posted April 8, 2019 Unfortunately for a lockup, you need to give me exact steps to reproduce it, otherwise there's nothing I can do about it. :/ 1 Quote Link to comment Share on other sites More sharing options...
twoodland Posted April 9, 2019 Share Posted April 9, 2019 Tursi, Would it be difficult to add an FG99 cart option using a FG99 folder that we could copy our SD card files to? Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted April 9, 2019 Share Posted April 9, 2019 One question, do you plan to update Classic99 to be able to run Dragon's Lair? Or is there a license issue with distributing a digital copy? Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 9, 2019 Author Share Posted April 9, 2019 Tursi, Would it be difficult to add an FG99 cart option using a FG99 folder that we could copy our SD card files to? How would this be different from what it does now? FG99 carts are no different than any other cart image? 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 9, 2019 Author Share Posted April 9, 2019 One question, do you plan to update Classic99 to be able to run Dragon's Lair? Or is there a license issue with distributing a digital copy? Classic99 can run Dragon's Lair, but I'm not able to distribute the ROM. I considered it and decided that tracking the ROM was too close to impossible to meet my license obligations. Since my license is expired, any questions about future distributions are moot - they won't happen. 2 Quote Link to comment Share on other sites More sharing options...
twoodland Posted April 9, 2019 Share Posted April 9, 2019 How would this be different from what it does now? FG99 carts are no different than any other cart image? I was thinking that it would help speedup the management and organization of the FG99 menu/filesystem. It would be faster/easier than moving the SD card to the PC, load the .bin to verify which program on the menu it is, make a change and then move it back to the cart to test it on real iron. Plus, it would make it easier in classic 99 to have many carts setup and available. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 9, 2019 Author Share Posted April 9, 2019 I was thinking that it would help speedup the management and organization of the FG99 menu/filesystem. It would be faster/easier than moving the SD card to the PC, load the .bin to verify which program on the menu it is, make a change and then move it back to the cart to test it on real iron. Plus, it would make it easier in classic 99 to have many carts setup and available. You're going to have to tell me what needs to change in the emulator. I don't use the FG99 routinely, so I'm not familiar with what you are trying to achieve or why you can't as-is. If you want me to run the FG99 menu software in Classic99, that's not likely to happen. Subfolders and the like already work fine, as does loading ROMs. I even put in a hack to support the fact that nobody ever puts the type extension character on FG99 files. 4 Quote Link to comment Share on other sites More sharing options...
twoodland Posted April 10, 2019 Share Posted April 10, 2019 You're going to have to tell me what needs to change in the emulator. I don't use the FG99 routinely, so I'm not familiar with what you are trying to achieve or why you can't as-is. If you want me to run the FG99 menu software in Classic99, that's not likely to happen. Subfolders and the like already work fine, as does loading ROMs. I even put in a hack to support the fact that nobody ever puts the type extension character on FG99 files. Good points! I will use it as is. No need to change anything. Thanks for considering it. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted April 23, 2019 Share Posted April 23, 2019 64-page thread, no search results, so I apologize if anyone has seen this already. These are filtered video captures screen shots from Classic99. Filter is TV mode and the emulator is paused. How odd! Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 23, 2019 Author Share Posted April 23, 2019 I actually love how that looks. I guess I didn't know that was broken, though it doesn't surprise me. The video record function expects a certain buffer size, and TV mode and 80 column mode both use larger buffers, so don't capture right. I haven't used the built in record for many years, myself. OBS works better 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 23, 2019 Share Posted April 23, 2019 It's also broken for filtered screenshots. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted April 23, 2019 Share Posted April 23, 2019 Shoot, sorry, I did not mean what I actually said. Cannot brain today. Those are actually filtered screen shots. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 23, 2019 Author Share Posted April 23, 2019 Same system captures screenshots as captures frames for video. Disable TV mode, or use an external capture tool (I just alt-printscreen myself) is the only advice I have for you. That's the problem, when the developer doesn't use the feature, it never sees updates. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted April 24, 2019 Share Posted April 24, 2019 Same system captures screenshots as captures frames for video. Disable TV mode, or use an external capture tool (I just alt-printscreen myself) is the only advice I have for you. That's the problem, when the developer doesn't use the feature, it never sees updates. I use alt-printscreen for static screens and with Windows 10 I have begun using the "GAME" record function. (Windows key + G) With that I can record video and audio including the microphone for narration. I like it. It records 80 column mode no problem as seen in the video clip. 80COL SUPER EAGLE.mp4 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted April 25, 2019 Share Posted April 25, 2019 I use alt-printscreen for static screens and with Windows 10 I have begun using the "GAME" record function. (Windows key + G) With that I can record video and audio including the microphone for narration. I like it. It records 80 column mode no problem as seen in the video clip. That's a neat idea. -- But what special settings are needed to get classic99 working on windows 10 64bit. -- ever since i upgraded from win7, i not been able to get classic99 running smoothly on win10. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted April 25, 2019 Share Posted April 25, 2019 That's a neat idea. -- But what special settings are needed to get classic99 working on windows 10 64bit. -- ever since i upgraded from win7, i not been able to get classic99 running smoothly on win10. I have Classic99 on both my Windows 10 tablet and Surface Pro... I did not need any special configs. Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted April 25, 2019 Share Posted April 25, 2019 I have Classic99 on both my Windows 10 tablet and Surface Pro... I did not need any special configs. I think my is outdated, i was able to get 'about to work' and its showing '389' as version. -- I not using TI99 roms, but my SOB ones on bootup, and it says 'READY TO START' very grabled as speech, and then just freezes, and i can't change any settings, but when i was using win 7 it worked perfectly. I guess i will have to delete it, update it to latest, and start fresh with new config stock ti99 and then if it works switch in my SOB roms. 2 Quote Link to comment Share on other sites More sharing options...
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.