Jump to content

Photo

Classic99 Updates


1590 replies to this topic

#1576 RXB OFFLINE  

RXB

    River Patroller

  • 3,583 posts
  • Location:Vancouver, Washington, USA

Posted Sun Apr 7, 2019 1:48 AM

 

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, Sun Apr 7, 2019 1:53 AM.


#1577 Tursi OFFLINE  

Tursi

    Quadrunner

  • Topic Starter
  • 5,638 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Apr 7, 2019 3:58 PM

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.

 

Attached File  XBDUMP.TXT   33.06KB   4 downloads


  • RXB likes this

#1578 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,966 posts
  • Location:Silver Run, Maryland

Posted Sun Apr 7, 2019 7:47 PM

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


  • RXB likes this

#1579 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,966 posts
  • Location:Silver Run, Maryland

Posted Sun Apr 7, 2019 9:29 PM

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



#1580 RXB OFFLINE  

RXB

    River Patroller

  • 3,583 posts
  • Location:Vancouver, Washington, USA

Posted Mon Apr 8, 2019 3:08 AM

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.



#1581 RXB OFFLINE  

RXB

    River Patroller

  • 3,583 posts
  • Location:Vancouver, Washington, USA

Posted Mon Apr 8, 2019 3:11 AM

 

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, Mon Apr 8, 2019 3:25 AM.


#1582 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,966 posts
  • Location:Silver Run, Maryland

Posted Mon Apr 8, 2019 6:09 AM

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



#1583 RXB OFFLINE  

RXB

    River Patroller

  • 3,583 posts
  • Location:Vancouver, Washington, USA

Posted Mon Apr 8, 2019 10:24 AM

 

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.



#1584 Tursi OFFLINE  

Tursi

    Quadrunner

  • Topic Starter
  • 5,638 posts
  • HarmlessLion
  • Location:BUR

Posted Mon Apr 8, 2019 12:41 PM

Unfortunately for a lockup, you need to give me exact steps to reproduce it, otherwise there's nothing I can do about it. :/
  • RXB likes this

#1585 twoodland OFFLINE  

twoodland

    Moonsweeper

  • 265 posts
  • Location:Delaware, OH

Posted Tue Apr 9, 2019 10:12 AM

Tursi,

 

Would it be difficult to add an FG99 cart option using a FG99 folder that we could copy our SD card files to?



#1586 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,483 posts

Posted Tue Apr 9, 2019 10:49 AM

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?



#1587 Tursi OFFLINE  

Tursi

    Quadrunner

  • Topic Starter
  • 5,638 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Apr 9, 2019 11:46 AM

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?

#1588 Tursi OFFLINE  

Tursi

    Quadrunner

  • Topic Starter
  • 5,638 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Apr 9, 2019 11:48 AM

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

#1589 twoodland OFFLINE  

twoodland

    Moonsweeper

  • 265 posts
  • Location:Delaware, OH

Posted Tue Apr 9, 2019 12:13 PM

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.  



#1590 Tursi OFFLINE  

Tursi

    Quadrunner

  • Topic Starter
  • 5,638 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Apr 9, 2019 2:51 PM

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

#1591 twoodland OFFLINE  

twoodland

    Moonsweeper

  • 265 posts
  • Location:Delaware, OH

Posted Tue Apr 9, 2019 9:16 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users