Jump to content
IGNORED

Help with linking XB and assembly


Vorticon

Recommended Posts

Hi.

 

I am trying to create an XB loader for my chaos programs for ease of use, but I have never done this before. I have 3 object code programs that I want to run from a menu, so I tried a little test from XB to load one of them, and I kept getting a syntax error on line 20

 

10 CALL INIT

20 CALL LOAD("DSK1.LOGISTIC")

30 CALL LINK("START")

 

The Logistic program uses the full bitmap screen as well as the usual VDP utilities (VSBW etc... along with GPLLNK , XMLLNK and KSCAN). The program entry label is START.

Where is the issue here?

Link to comment
Share on other sites

Take a look at the sound player thread I did for Owen's game. I can't remember the details right this moment, but it should all be there. Also, if you use GM2 you won't be able to return to XB (just something to keep in mind.)

 

Setting up the programs to run as a cartridge might be easier. If you use asm994a in conjunction with Classic99, this probably makes the fastest code, assemble, run, debug cycle available. If you are coding on real hardware, well, that's a different story.

 

I'll go see what I can dig up and remember.

 

Matthew

Link to comment
Share on other sites

Can you post your code from the DEF through to your START label? Also, how are you assembling?

 

The sound player code is pretty straight forward. It is assembled like normal and the XB loader fixes up the addresses (meaning you DO NOT code with any AORG.) You have to DEF your entry points, but that is pretty much it. Assemble the object code and use it in CALL LOAD.

 

Matthew

Link to comment
Share on other sites

Three thoughts come to mind:

1. Unlike EA option 3, XB won't load Compressed object code. If you assembled with the "C" option, reassemble without.

2. Your program must be relocatable and fit within the confines of the lower 8K together with the utilities and the REF/DEF table.

3. Something in the back of my mind says the GPLLNK routine is not part of the XB utilities and to use it, you'll need to include your own. Your syntax error may be generated by GPLLNK or a utility that can't be referenced by the CALL LOAD loader.

Link to comment
Share on other sites

Can you post your code from the DEF through to your START label? Also, how are you assembling?

 

The sound player code is pretty straight forward. It is assembled like normal and the XB loader fixes up the addresses (meaning you DO NOT code with any AORG.) You have to DEF your entry points, but that is pretty much it. Assemble the object code and use it in CALL LOAD.

 

Matthew

 

Here it is:

 

*****************************
      DEF  START
      REF  VWTR,VSBW,VMBW,VSBR,VMBR,XMLLNK
      REF  GPLLNK,KSCAN
GPLSTS EQU  >837C
KEYADR EQU  >8374
KEY    EQU  >8375
FAC    EQU  >834A             * FLOATING POINT ACCUMULATOR
ARG    EQU  >835C             * FLOATING POINT ARGUMENT
STACK  EQU  >836E             * POINTER TO VDP RAM
SUBRTN BSS  2                 * SUBROUTINE RETURN ADDRESS
FPZL1  BSS  8
FPZL2  BSS  8
FPTMP1 BSS  8
FPTMP2 BSS  8
FPTMP3 BSS  8
SAVLOC DATA >B000,>C800,>E000
GXDAT  DATA 0,0,0
GYDAT  DATA 0,0,0
GX     DATA 0
GY     DATA 0
ZX0    DATA 0
ZY0    DATA 0
ZX1    DATA 0
ZY1    DATA 0
SPRTY  DATA >5300             * INITIAL WINDOW Y COORDINATE
M      DATA >8040,>2010,>0804,>0201
WFLAG  DATA >0000             * WINDOW FLAG
PFLAG  DATA >0000             * CALCULATIONS PROGRESS FLAG
ZFLAG  DATA >0000             * ZOOM FLAG
ZFLAG1 DATA >0000             * ZOOM LEVEL 2 FLAG
EFLAG  DATA >0000             * ENTER KEY FLAG
ZLEVEL DATA >0000             * ZOOM LEVEL
COUNT1 DATA >0000             * CALCULATIONS ITERATIONS
ONE    DATA >0001
TWO    DATA >0002
DEC3   DATA >0003
ASCW   BYTE >57               * ASCII W
ASCE   BYTE >45               * ASCII E
ASCX   BYTE >58               * ASCII X
ASCS   BYTE >53               * ASCII S
ASCD   BYTE >44               * ASCII D
ASCB   BYTE >42               * ASCII B
ASCF   BYTE >46               * ASCII F
ASCQ   BYTE >51               * ASCII Q
ENTER  BYTE >0D               * <ENTER> KEY
SPACE  BYTE >20               * <SPACE> KEY
ANYKEY BYTE >20
P      BYTE >3F,>28,>00,>00,>00,>00,>00,>00  * 0.4 - INITIAL VALUE
R      BYTE >40,>02,>32,>00,>00,>00,>00,>00  * 2.5 - INITIAL VALUE
FP1    BYTE >40,>01,>00,>00,>00,>00,>00,>00  * 1.0
FP170  BYTE >41,>01,>46,>00,>00,>00,>00,>00  * 170.0
FP191  BYTE >41,>01,>5B,>00,>00,>00,>00,>00  * 191.0
FCONST BYTE >40,>02,>32,>00,>00,>00,>00,>00  * 2.5
FCNST  BYTE >3F,>28,>00,>00,>00,>00,>00,>00  * 0.4
FCNST1 BYTE >3F,>0A,>00,>00,>00,>00,>00,>00  * 0.1
COEF   BYTE >3E,>01,>00,>00,>00,>00,>00,>00  * 0.0001 - INITIAL VALUE
NEGONE BYTE >BF,>FF,>00,>00,>00,>00,>00,>00  * -1.0
THREE  BYTE >40,>03,>00,>00,>00,>00,>00,>00  * 3.0
FOUR   BYTE >40,>04,>00,>00,>00,>00,>00,>00  * 4.0
FP10   BYTE >40,>0A,>00,>00,>00,>00,>00,>00  * 10.0
FP64   BYTE >40,>40,>00,>00,>00,>00,>00,>00  * 64.0
TITLE  TEXT 'Chaos Demonstration - Logistic Equation'
CREDIT TEXT 'By Walid Maalouli - October 2010'
PRESSK TEXT 'Press Space Key To Continue'
      EVEN
START  LI   R0,>0200

 

I'm not using any AORGs. Any hints?

Link to comment
Share on other sites

Three thoughts come to mind:

1. Unlike EA option 3, XB won't load Compressed object code. If you assembled with the "C" option, reassemble without.

2. Your program must be relocatable and fit within the confines of the lower 8K together with the utilities and the REF/DEF table.

3. Something in the back of my mind says the GPLLNK routine is not part of the XB utilities and to use it, you'll need to include your own. Your syntax error may be generated by GPLLNK or a utility that can't be referenced by the CALL LOAD loader.

 

I did assemble using the RC options. I'll see if not using C makes any difference. If it is a GPLLNK issue, then that's the end of it... How big is 22 sectors?

Link to comment
Share on other sites

Not sure how doable this would be - but would it be possible (useful) to develop an assembly library that did simple things....

 

AKA instead of writing a bunch of XB to say - get joystick input and move a sprite - move that code to a single CALL statement... Perhaps restricting vertical/ horizontal movement - and then also setting "edges" that either bounce or do some other action... I would expect parameter lists to be long.

 

Another thing that would be awesome would be to consolidate the CALL COINC a program would do - and behave in a specific manner based on parameters....

 

I know that sometimes things are hard to define in a generic-enough sense, however, I think most XB games could benefit greatly...

 

Another - perhaps an interrupt driven routine to play music (although I envision playing sounds might conflict with this - unless the library is smart enough to do such things as well)....

 

I think (since I can't do Assembly) that this would allow us to amp-up the quality of our games....

 

-H

Link to comment
Share on other sites

Howie have you played Honeycomb Rapture? It's available at the tigameshelf.net.

Our own Matthew180 did an ISR sound player to play in the background of an XB program. Turning the soundlist player "off" is easy... One simple BASiC command. Also, you can use the music channels for your song and the sound channel for FX. :). Visit my website and read the assembly tutorial Matthew wrote while coding that ISR sound player... Very cool stuff, man.

Link to comment
Share on other sites

I tried loading the compressed object code from TI Basic with the E/A cart plugged in, and I did not get any errors, and the screen cleared up and the background was black as intended, but then it started randomly filling up with characters. It looked as if the bitmap mode never kicked in, and the SIT was being written to randomly. My program sets the SIT at VDP address 0 for >1800 bytes, which obviously overlaps the graphics mode default SIT (>800 I believe). Does any of this shed any light?

Link to comment
Share on other sites

Since you are going to trash VDP RAM and not return to BASIC, the first thing you need to do is disable interrupts! If you don't, the console ISR will still run. Also, you probably need to set *all* the VDP registers to make sure the tables are set up where you think they are.

 

Those are the first two things that come to mind anyway.

 

Matthew

Link to comment
Share on other sites

Since you are going to trash VDP RAM and not return to BASIC, the first thing you need to do is disable interrupts! If you don't, the console ISR will still run. Also, you probably need to set *all* the VDP registers to make sure the tables are set up where you think they are.

 

Those are the first two things that come to mind anyway.

 

Matthew

Forgive my ignorance, but why are interrupts important here? How do they affect the loading of the code?

Link to comment
Share on other sites

Loading the code? The console interrupt would not affect loading, but I thought you said you got it to load now? The way your post sounded, you got it to load, but when it ran things went wrong. As soon as you CALL LINK to your code, you need to do a LIMI 0 and leave it that way. As soon as you enable GM2 you can never go back to BASIC.

 

Matthew

Link to comment
Share on other sites

I tried loading the compressed object code from TI Basic with the E/A cart plugged in, and I did not get any errors, and the screen cleared up and the background was black as intended, but then it started randomly filling up with characters. It looked as if the bitmap mode never kicked in, and the SIT was being written to randomly. My program sets the SIT at VDP address 0 for >1800 bytes, which obviously overlaps the graphics mode default SIT (>800 I believe). Does any of this shed any light?

 

 

Did you set the magic address in the scratch pad so that any key presses don't muck up your VDP register ? This trips me up all the time...

Link to comment
Share on other sites

I tried loading the compressed object code from TI Basic with the E/A cart plugged in, and I did not get any errors, and the screen cleared up and the background was black as intended, but then it started randomly filling up with characters. It looked as if the bitmap mode never kicked in, and the SIT was being written to randomly. My program sets the SIT at VDP address 0 for >1800 bytes, which obviously overlaps the graphics mode default SIT (>800 I believe). Does any of this shed any light?

 

 

Did you set the magic address in the scratch pad so that any key presses don't muck up your VDP register ? This trips me up all the time...

 

What is the magic address??? Maybe I know it by another name :)

Link to comment
Share on other sites

Loading the code? The console interrupt would not affect loading, but I thought you said you got it to load now? The way your post sounded, you got it to load, but when it ran things went wrong. As soon as you CALL LINK to your code, you need to do a LIMI 0 and leave it that way. As soon as you enable GM2 you can never go back to BASIC.

 

Matthew

That's what I thought... Yes, I did get it to load from BASIC, but what I really need is a load from XB so I can create an autoload menu. So far no dice there. I think Tim is right about GPLLNK needing to be loaded independently, and that's not going to work for me. This would have been a great problem to tackle at the pre-Faire get-together :) Between you, Tim and Marc, I had some of the best coders around!

Link to comment
Share on other sites

I tried loading the compressed object code from TI Basic with the E/A cart plugged in, and I did not get any errors, and the screen cleared up and the background was black as intended, but then it started randomly filling up with characters. It looked as if the bitmap mode never kicked in, and the SIT was being written to randomly. My program sets the SIT at VDP address 0 for >1800 bytes, which obviously overlaps the graphics mode default SIT (>800 I believe). Does any of this shed any light?

 

 

Did you set the magic address in the scratch pad so that any key presses don't muck up your VDP register ? This trips me up all the time...

 

What is the magic address??? Maybe I know it by another name :)

 

 

 

 

Sorry didn't have the Big Book of Magic" when I wrote that..... It's address >83D4. You need to change it's value to reflect what you write into VDP REG 1 or when ever KSCAN is called (such as in the ISR) VDP REG 1's value gets changed back to whatever it originally was before you changed it..... Hmmmmm that doesn't even make sense to me. Anyway that sound like what MAY be going on.....

 

invisibility cloak on..... ;-)

Link to comment
Share on other sites

It's address >83D4. You need to change it's value to reflect what you write into VDP REG 1 or when ever KSCAN is called (such as in the ISR) VDP REG 1's value gets changed back to whatever it originally was before you changed it..... Hmmmmm that doesn't even make sense to me. Anyway that sound like what MAY be going on.....

I'm pretty sure it has to do with the "screensaver". You know, when you don't touch the keyboard, the screen goes blank after some minutes (is it 5 or 10 minuttes ?). It simply enables the screen everytimes you press a key, and resets a counter. I guess it doesn't bother with present state. When the counter reaches something like zero it enables screen blanking. Page 21 and 34 in the "Intern".

 

:)

Edited by sometimes99er
Link to comment
Share on other sites

The XB loader does not understand the REF directive. Therefore you cannot REF the VDP utilities and things like KSCAN. :(

 

You must state their addresses with EQU directives. :mad:

 

Of course, all the utilities are at a different address to TI BASIC/ED-AS, and I'm afraid I don't have them for XB.

 

Anyway, that is the reason for the run-time error.

 

HTH

Edited by Willsy
Link to comment
Share on other sites

 

 

Sorry didn't have the Big Book of Magic" when I wrote that..... It's address >83D4. You need to change it's value to reflect what you write into VDP REG 1 or when ever KSCAN is called (such as in the ISR) VDP REG 1's value gets changed back to whatever it originally was before you changed it..... Hmmmmm that doesn't even make sense to me. Anyway that sound like what MAY be going on.....

 

invisibility cloak on..... ;-)

Oh that! Yes I did :) I actually have this fact highlighted next the the VR1 entry in my EA manual...

Link to comment
Share on other sites

The XB loader does not understand the REF directive. Therefore you cannot REF the VDP utilities and things like KSCAN. :(

 

You must state their addresses with EQU directives. :mad:

 

Of course, all the utilities are at a different address to TI BASIC/ED-AS, and I'm afraid I don't have them for XB.

 

Anyway, that is the reason for the run-time error.

 

HTH

Ah hah! Now that makes senses. Any idea where the XB addresses are listed?

  • Like 1
Link to comment
Share on other sites

The XB loader does not understand the REF directive. Therefore you cannot REF the VDP utilities and things like KSCAN. :(

 

You must state their addresses with EQU directives. :mad:

 

Of course, all the utilities are at a different address to TI BASIC/ED-AS, and I'm afraid I don't have them for XB.

 

Anyway, that is the reason for the run-time error.

 

HTH

Ah hah! Now that makes senses. Any idea where the XB addresses are listed?

Smart Programmer found on WHT has them -- I'd scan the page but I don't have access to them right now. Good thing Wills brought those up -- I had forgotten about those stupid EQUate requirements! DOH!

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