Jump to content
IGNORED

Classic99 Updates


Tursi

Recommended Posts

 

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 by RXB
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

 

attachicon.gifXBDUMP.TXT

 

I am pretty sure I have done it without the utilities. If I find the thread, I will let you know.

 

...lee

  • Like 1
Link to comment
Share on other sites

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.

 

attachicon.gifXBDUMP.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.

Link to comment
Share on other sites

 

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 by RXB
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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. :)

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. ;)

  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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 ;)

  • Like 1
Link to comment
Share on other sites

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. ;)

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

 

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.

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...