jchase1970 Posted December 27, 2011 Share Posted December 27, 2011 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 Quote Link to comment Share on other sites More sharing options...
marc.hull Posted December 28, 2011 Share Posted December 28, 2011 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..... Quote Link to comment Share on other sites More sharing options...
jacquesg Posted December 28, 2011 Share Posted December 28, 2011 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted December 28, 2011 Share Posted December 28, 2011 (edited) ? Edited December 28, 2011 by RXB Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 29, 2011 Share Posted December 29, 2011 (edited) Edited June 16, 2016 by sometimes99er Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted December 29, 2011 Author Share Posted December 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
jacquesg Posted December 29, 2011 Share Posted December 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted December 31, 2011 Author Share Posted December 31, 2011 (edited) 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 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 December 31, 2011 by jchase1970 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 31, 2011 Share Posted December 31, 2011 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??. 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 1, 2012 Share Posted January 1, 2012 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 Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 1, 2012 Author Share Posted January 1, 2012 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted January 1, 2012 Share Posted January 1, 2012 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. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 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. Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 1, 2012 Author Share Posted January 1, 2012 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. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) 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 January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 1, 2012 Author Share Posted January 1, 2012 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 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) 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 January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) 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 January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 1, 2012 Share Posted January 1, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 2, 2012 Share Posted January 2, 2012 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. 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.