19 replies to this topic

[jchase1970]

Ok So I was looking though some programs on the gamebase files and I come across one that got me thinking about this. First off I know nothing about how to imbed ML in XB, the only time I have done it is with a loader that loads in the compiled basic progams I make.

So Im looking at the file DRAGON[fix].zip in the disks folder in gamebase and the XB LOAD file on that disk is this program

0 !**********************
1 !*				    *
2 !*    Generated By    *
3 !*    SysTex  V1.0    *
4 !*	  (C) 1985	  *
5 !*   By Barry Boone   *
6 !*				    *
7 !**********************
8 CALL INIT :: CALL LOAD(8196,254,0)
9 CALL LINK("SLOAD")
100 CALL CLEAR :: CALL SCREEN(9) :: FOR I=0 TO 12 :: CALL COLOR(I,16,5) :: NEXT I :: CALL LINK("CHARDF")
120 DISPLAY AT(1,1):"This program may be freely  distributed. I translated itfrom Microsoft Basic to TI  Extended Basic. Although"
130 DISPLAY AT(5,1):"many hours of typing and    translation were expended,  I do not ask for money.": :"I would ask, however, if you"
140 DISPLAY AT(10,1):"have any programs which you have written or translated, and would like to share,":"I would appreciate a copy.  I am particularly interested"
150 DISPLAY AT(15,1):"in UTILITY type pgms. in anylanguage(Basic, Assembly,   Forth, Pascal)."
160 DISPLAY AT(20,1):"Ken Woodcock":"4701 Atterbury St.":"Norfolk, Va. 23513": :"	 <press any key>"
170 CALL KEY(0,K,S) :: IF S THEN RUN "DSK1.STORY0" ELSE 170

The CALL LINK("CHARDF") is a program to redefine the char sets.
So the question is, is there a way to pull that out save it and reuse it in another program?


 DRAGONfix.zip   30.34K   1 downloads

[marc.hull]

jchase1970, on Tue Dec 27, 2011 1:03 PM, said:

Ok So I was looking though some programs on the gamebase files and I come across one that got me thinking about this. First off I know nothing about how to imbed ML in XB, the only time I have done it is with a loader that loads in the compiled basic progams I make.

So Im looking at the file DRAGON[fix].zip in the disks folder in gamebase and the XB LOAD file on that disk is this program

0 !**********************
1 !*					*
2 !*	Generated By	*
3 !*	SysTex  V1.0	*
4 !*	  (C) 1985	  *
5 !*   By Barry Boone   *
6 !*					*
7 !**********************
8 CALL INIT :: CALL LOAD(8196,254,0)
9 CALL LINK("SLOAD")
100 CALL CLEAR :: CALL SCREEN(9) :: FOR I=0 TO 12 :: CALL COLOR(I,16,5) :: NEXT I :: CALL LINK("CHARDF")
120 DISPLAY AT(1,1):"This program may be freely  distributed. I translated itfrom Microsoft Basic to TI  Extended Basic. Although"
130 DISPLAY AT(5,1):"many hours of typing and	translation were expended,  I do not ask for money.": :"I would ask, however, if you"
140 DISPLAY AT(10,1):"have any programs which you have written or translated, and would like to share,":"I would appreciate a copy.  I am particularly interested"
150 DISPLAY AT(15,1):"in UTILITY type pgms. in anylanguage(Basic, Assembly,   Forth, Pascal)."
160 DISPLAY AT(20,1):"Ken Woodcock":"4701 Atterbury St.":"Norfolk, Va. 23513": :"	 <press any key>"
170 CALL KEY(0,K,S) :: IF S THEN RUN "DSK1.STORY0" ELSE 170

The CALL LINK("CHARDF") is a program to redefine the char sets.
So the question is, is there a way to pull that out save it and reuse it in another program?


DRAGONfix.zip

Yes...... that's the easy part....

The rest is hard .....

It would be object code so pretty useless for other programs unless you know exactly how it does it's magic. Systex is really cool and eliminates the load..... after the load..... Other than that is isn't much different than "CALL LOAD."

I would strongly suggest that you write your own routines and THEN figure out the best way to get them in.....

[jacquesg]

Paolo Bagnaresi wrote a program named ACE that appears in the April 1994 issue of MICROpendium. It will convert loaded object code into CALL LOAD statements. It has been a long time since I last used this program and it may not be exactly what you are looking for. Since it creates CALL LOAD statements it is not as efficient as using SYSTEX.

Jacques

[RXB]

?

Edited by RXB, Wed Dec 28, 2011 6:16 AM.

[sometimes99er]

marc.hull, on Tue Dec 27, 2011 7:25 PM, said:

jchase1970, on Tue Dec 27, 2011 1:03 PM, said:

So the question is, is there a way to pull that out save it and reuse it in another program?

Yes...... that's the easy part....

The rest is hard .....

It would be object code so pretty useless for other programs unless you know exactly how it does it's magic.

Right now I don't know how to pull it out.

I suspect it to be embedded EA5, simply from code and loading times achieved by this, SysTex, tool and documentation by Tursi in the Bitmap image conversions thread and compiler by Wilhelm.

Now the program in question (dragon), just manipulates the character set (I think), no need for any input or output, so it should indeed be useful for other programs.

If you're especially interested in the font, you can rip the data with F10 in Classic99, extract with my Limelight and generate Basic code in Codex' Magellan or my Grapefruit. Bring your own code together with the generated font code, and maybe finally use the compiler by Wilhelm. Alternatively you can grap the graphics using F9 in Classic99 and of course a graphic application (like PaintShopPro).

[jchase1970]

Well the character set is real nice, but it is just that, a character set and it's not hard to code in basic or assembly. I just thought this would be a good clean example to use for my question. I have never tried to embed anything in an XB program but can see how nice it would be to have the charset definitions in assembly would be. especially the way I normally need to sets, one for graphics and one for letters at the end of the game.

john

[jacquesg]

Barry Traver has a nice series of article called Basic Assembly in MICROpendium from June 1990 to November 1991 that also describes how to embed assembly routines in an Extended Basic program. He also put together many useful assembly routines on a disk named XXB. These routines are also part of XB v2.5 by Tony Knerr.

Jacques

[jchase1970]

Ok, so I ripped out the charset from this program, cause I do like it. I then created a assembly program to load from XB.

 CHARDF.zip   1.08K   1 downloads

A demo program

10 CALL INIT
20 CALL LOAD("DSK1.CHARDF")
30 CALL LINK("CHARDF")
40 FOR I=30 TO 126
50 PRINT CHR$(I);
60 NEXT I
70 GOTO 70

Now I have a few questions about linking.
I know when I use CALL LINK("CHARDF") then charset will define much faster then if written in XB. and this is a plus as I normally use 2 sets and switch between them. But this file is 3456 bytes. So where is that loaded at in basic. Is it in the stack and does that give more space to the code? Depending on how much stack you needed that could be good or bad.

I was going to ask about if it mattered if the user didn't have the PE but then I realized that it is on disk and I guess they have to have a PE to have a disk drive .

So 2nd question is about embedding. I don't know how to for one. But bigger question is, is there any advantage to embedding if we are planing the program to be ran from a disk. I'm guessing embedding saves no space and only difference is a longer load time up front as opposed to loading the assembly after you run the XB program?

No matter what I did learn some new stuff from this project. I never wrote a assembly sub for XB before and I understand alot more about that now.

Edited by jchase1970, Sat Dec 31, 2011 5:05 PM.

[sometimes99er]

jchase1970, on Sat Dec 31, 2011 5:03 PM, said:

So 2nd question is about embedding. I don't know how to for one.

Explained by Tursi here. Go and read from "How does it work??.

jchase1970, on Sat Dec 31, 2011 5:03 PM, said:

But bigger question is, is there any advantage to embedding if we are planing the program to be ran from a disk.

I believe embedding is much faster. That's both down to XB's handling, EA3 against EA5, and not needing CALL INIT. Well, as far as I've put it together until now.

[InsaneMultitasker]

Your load time is partially dependent on the size of the code. A short program may load in roughly the same amount of time whether DF80 or embeded. However, even with a RAMdisk, the larger the DF80 the longer the load time whereas the same code embedded into a program image file will load nearly instantaneously. SYSTEX is the first program for which I sent a fairware donation, and I've never regretted that decision

[jchase1970]

I'll have to look at SYSTEX, as I spent a fair amount of time trying to figure out how to embed and so far for it I have no more of an idea now then I did when I started.

John

[RXB]

I looked at the idea of imbedding Asssembly Code into XB and came up with RXB version that does a better job and is faster.

11 ! BOOT TRACKING IN RXB   MERGE this program frist    so your program knows which drive it loaded from last.  *NOTE: NO ASSEMBLY USED!!
12 CALL PEEK(-31792,R,I,C,H) :: CRU=128*R+I :: CPU=256*C+H+5 :: CALL IO(3,8,CRU,255) :: CALL MOVES("R$",4,CPU,D$) :: CALL IO(3,8,CRU,0)
13 CALL MOVES("V$",20,2086,E$)
14 CALL BLOAD(D$&".MYASSEMBLY")
100 ! Rest of your XB program here...

It Boot tracks from DSK, SCS, WDS, RD, HD, or even a secondary device you add as long as it has a standard DSR.

[sometimes99er]

jchase1970, on Sat Dec 31, 2011 9:00 PM, said:

I'll have to look at SYSTEX, as I spent a fair amount of time trying to figure out how to embed and so far for it I have no more of an idea now then I did when I started.

I suspect you did not go and read the link in post #9. It's surprisingly easy - and without SysTex, whatever it is SysTex do.

[jchase1970]

I read the link but didnt see how to do it, I guess I need to go read it again. Maybe I over looked it.

[sometimes99er]

jchase1970, on Sun Jan 1, 2012 9:05 AM, said:

I read the link but didnt see how to do it, I guess I need to go read it again. Maybe I over looked it.

I tried to cut it down (haven't tried it out though) ...

1. NEW
2. Set pointers, >8330 and >8332, to point just below where assembly is to be loaded. You can use CALL INIT/CALL LOAD to set these pointers, or set them through the Debugger in Classic99.
3. Enter XB program. MERGE it, type it, or paste it. Don't use OLD.
4. Get the assembly into place, just CALL INIT::CALL LOAD("DSK1.ASM/O"). The assembly program has to use AORG to be placed near top of memory.
5. Update REF/DEF table manually ?
6. SAVE DSK1.PROGRAM.

Done (?)

Edited by sometimes99er, Sun Jan 1, 2012 2:15 PM.

[jchase1970]

Lets break this down, cause I am lost.
1st can we use the object code I posted above for the charset, or does it have to be saved special?

		  DEF CHARDF,VMBW
VMBW EQU >2024
CHARS	 DATA for all the char patterns

CHARDF    LI R0,1008
		  LI R1,CHARS
		  LI R2,768
		  BLWP @VMBW

2 set pointers. Lets do this in XB not thru classic 99 cause I want to see how to do it and not short cuts that are above my understanding.
This step here just confuses me.
I loaded the patterns at decimal 1008. But I dont think that is where we point to? Maybe I have to write a AROG at the beginning of the code to set it to a hard location?

So help me with this first step and then we will see about the rest of it.

Thx John

[sometimes99er]

Yeah, let's try something out. Top of memory is >FFFF. 4K block should be enough for your program. 4K is >1000. So new top of memory is >FFFF - >1000 = >EFFF or just >F000. Let's AORG in the code at >F002 then. The assembler will then produces object code that loads there.

So first there's NEW, then CALL INIT, and then CALL LOAD.

E/A, page 276:
The address is a numerical expression or variable from -32768 through 32767. Addresses from 0 through 32767 represent >0000 through >7FFF. Addresses from -32768 through -1 represent >8000 through >FFFF expressed in two's-complement form. To access an address above 32767, subtract 65536 from it.

65536 = 256 * 256.

>8330 = 33584, above 32767, so we have to substract 65536, 33584 - 65536 = -31952.

>F000 is separated into >F0 and >00. >F0 = 240.

So if my calculations are correct, we have

CALL LOAD(-31952,240,0,240,0)

I guess the above reserves something like >F002 - >FFFF. And a SAVE from XB would embed this area.

Edited by sometimes99er, Sun Jan 1, 2012 2:11 PM.

[sometimes99er]

Starting XB and it has >FFE7 stored at >8330 and at >8332. Using Classic99 Debugger to verify.

CALL LOAD without a prior CALL INIT will return a * SYNTAX ERROR. CALL INIT with a soft reset (QUIT) and then the LOAD without INIT does not produce an error. Expansion memory survives a soft reset.

CALL INIT does not change the values mentioned above.

CALL LOAD(-31952,240,0,240,0) does indeed place >F000 at the correct addresses. Calculations were correct then.

I load a small program that has been assembled with AORG >F002. Loaded fine and executes fine too. Made one simple XB program (100 REM) and saved it. Reset Classic99, start and load XB program, and yes, apart from the XB program, the assembler instructions are indeed found there at >F002.

Now I think we have to make our own entry into the REF/DEF table. - Actually not. Looked at Wilhelm's compiler, and this is a hack into the utilities loaded with INIT.

10 CALL INIT
20 CALL LOAD(8192,240,2)
30 CALL LINK("RUN")

Yes, it all works. Nice.

The above code is just the minimal code you have to include in your XB program to execute the embedded area.

Edited by sometimes99er, Sun Jan 1, 2012 3:40 PM.

[InsaneMultitasker]

jchase1970, on Sat Dec 31, 2011 9:00 PM, said:

I'll have to look at SYSTEX, as I spent a fair amount of time trying to figure out how to embed and so far for it I have no more of an idea now then I did when I started.

John

Systex does more than embed the assembly code into an executable file. It is intended to save what you loaded as DF80 into an executable program, which then can be loaded/run to quickly 'restore' that assembly code. Once the systexed loader has been executed, subsequent programs can be loaded which make use of the code in the lower 8k. Contrast this with code you embed directly into your executable program - once you load another program, the assembly routines are no longer accessible.

[Tursi]

InsaneMultitasker, on Sun Jan 1, 2012 4:22 PM, said:

Systex does more than embed the assembly code into an executable file. It is intended to save what you loaded as DF80 into an executable program, which then can be loaded/run to quickly 'restore' that assembly code. Once the systexed loader has been executed, subsequent programs can be loaded which make use of the code in the lower 8k. Contrast this with code you embed directly into your executable program - once you load another program, the assembly routines are no longer accessible.

True, but nothing stops the code you've stored in with the program from copying down into the 8k block in the same manner.

That's interesting though, I never knew Systex did that.