XB Game Developers Package

[+jedimatt42]

Oh, I see code in DSRLNK stashing values into those 2 memory addresses. 

 

-M@

[+mizapf]

No, 83C0. (83D0-F are R8..R15 of WS 83C0).

[+jedimatt42]

1 hour ago, mizapf said:

No, 83C0. (83D0-F are R8..R15 of WS 83C0).

I think no == yes...  >83C0 is the workspace used by part of the 4A console rom interrupt service routine. at >0A8A - I wasn't trying to say >83D0 was that workspace, but that they were (with)in that workspace.

Most of the console rom service routine uses the GPLWS >83E0, and >83C0 is referred to in TI99/4A INTERN as the INTWS.  The console rom interrupt service routine does a healthy amount of mucking in both blocks of memory, and uses both as WS value at different times.

 

Anyway, since the GPL DSRLNK is right after that in the book, I checked, and it also is stashing values into >83D0 and >82D2. 

 

-M@

 

 

[+TheBF]

On 6/22/2019 at 3:33 PM, senior_falcon said:

Yep, I found that later article with the SBO and SBZ. It seems to work fine for retrieving the disk number

 	MOV @>83D0,R12 		GET THE CRU BASE IN R12
	JEQ EXIT 			GET OUT IF 0
	MOV @>83D2,R9 		GET THE ROM ADDRESS FOR DEVICE
	JEQ EXIT 			GET OUT IF 0
	SBO 0 				ENABLE THE DEVICE ROM
	AI R9,8 			Now R9 points to disk number (ascii)	

What circumstances would lead to >83D0 or >83D2 being equal to zero?

 

This translates very nicely to Forth. I did not know how to do this.

Thanks!

(The error checking may be a little over kill but it is easily removed.)

 

NEEDS 0SBO   FROM DSK1.CRU

HEX
: DSK#  ( -- n)
         83D0 @ DUP 0= ABORT" No disk"
         CRU!                          \ store top of stack to R12
         83D2 @ DUP 0= ABORT" No ROM"
         0SBO                          \ turn the card on
         ( 83D2) @ 8 +  C@             \ fetch char from address on stack+8
         0SBZ                          \ turn the card off
         [CHAR] 0 -                    \ subtract ascii '0' to return integer
;

 

[+videofx]

Hi,

 

I just found Isabella5. I dont use emulators. I only use real hardware. Can I use Isabella5 on my Ti99 or is there anything I need to do to get it to work?

 

Thanks and sorry for the newbie questions

[+arcadeshopper]

1 hour ago, videofx said:

Hi,

 

I just found Isabella5. I dont use emulators. I only use real hardware. Can I use Isabella5 on my Ti99 or is there anything I need to do to get it to work?

 

Thanks and sorry for the newbie questions

 

yes you can.. just use TI FILENAMES instead of the emulator .txt files

[senior_falcon]

2 hours ago, arcadeshopper said:

 

yes you can.. just use TI FILENAMES instead of the emulator .txt files

There is a little more to it than that, but it is already done for you in the folder ISABELLA99. Page 12 of "Using XBGDP" has the information you need. 

[+videofx]

13 hours ago, senior_falcon said:

There is a little more to it than that, but it is already done for you in the folder ISABELLA99. Page 12 of "Using XBGDP" has the information you need. 

 

Thanks! I will read it and let you know how it goes

[+videofx]

I have a Gram Cracker. Anyway to load ISABELLA into GROM?

 

Thanks

[senior_falcon]

27 minutes ago, videofx said:

I have a Gram Cracker. Anyway to load ISABELLA into GROM?

 

Thanks

No, not without a total rewrite.

 

"I dont use emulators. I only use real hardware."

 

If you are developing programs to be compiled, you will be far less productive using real hardware. Once the program is completed and debugged in Classic99 the compiled program will run fine on real hardware.

[+videofx]

OK, Let me try out everything in Classic99 and see how it goes

 

[+videofx]

I got everything working in Classsic99. The first time I tried to go through compiling I got an error after I chose the 24K loader. I don't remember the error but I rebooted and ran it again and this time through it compiled and I Was able to execute the compiled version.

 

The only ling I noticed is that when is says ASSEMBLER EXECUTING there is nothing telling you its doing something. I thought that it locked up and was ready to reboot but then it completed with no errors.

 

Now I can start developing my first program

 

Thanks for Isabella!

[+mizapf]

1 hour ago, videofx said:

The only ling I noticed is that when is says ASSEMBLER EXECUTING there is nothing telling you its doing something. I thought that it locked up and was ready to reboot but then it completed with no errors.

This is what some people "hate" about MAME - that I added floppy drive sounds. ?

 

[Tursi]

27 minutes ago, mizapf said:

This is what some people "hate" about MAME - that I added floppy drive sounds. ?

Yes, yes, MAME is better than Classic99 in every way... maybe we should add floppy sounds to RAM disks too.

 

When I'm waiting on slow programs in Classic99, I like to pop up the heat map (Edit->Heatmap). You get a very quick view of just how busy the system is.

[RXB]

I have to say DO NOT DOWNLOAD AND INSTALL WINDOWS 10 UPDATE 1903 BETA

 

I made the mistake of doing this and can not get back to UPDATE 1809 again for some reason I can not explain.

 

This 1903 UPDATE no longer allows SANDBOX to work so now I am forced to put Classic99 in foreground to run it only.

 

In the old 1809 UPDATE Classic99 would run in background while I browsed web but no longer can I do that.

Edited July 1, 2019 by RXB

[senior_falcon]

Here is a slight revision to the XBGDP called Isabella6. This adds the ability to delete a file on a disk drive with the XB statement DELETE "DSKn.FILE". N.B. This does not work when using FIAD and Classic99.

Also boot tracking has been added so you can have the XBGDP on DSK1 to DSK9. If it is on DSK3 you would start it up with RUN "DSK3.LOAD". There is one case where boot tracking does not work - if you are using the TI assembler that comes with the package, the return will be to the start of XB which  tries to RUN DSK1.LOAD. There is no practical way to change this. You will have to type RUN "DSK3.LOAD" again or you could have a one line LOAD program on DSK1: 10 RUN "DSK3.LOAD". This does not happen if you use Asm994a.
 

ISABELLA6.zip

[Tursi]

Does delete make your system better? I could add an option to allow delete, I guess. I didn't envision such tools when I first created the file system code.

 

[wolhess]

4 hours ago, Tursi said:

Does delete make your system better? I could add an option to allow delete, I guess. I didn't envision such tools when I first created the file system code.

 

Hi Tursi,

the request for the function "delete" came from me (see post # 704). Since I work with temporary files, they should be deleted after editing. That did not go so far if I compiled my XB program with XBGDP. I usually practice on my real TI. Therefore the implementation in classic99 is not necessary for me. However, if it is not too much effort for you, I could also use classic99 for testing.

[Tursi]

10 hours ago, wolhess said:

Hi Tursi,

the request for the function "delete" came from me (see post # 704). Since I work with temporary files, they should be deleted after editing. That did not go so far if I compiled my XB program with XBGDP. I usually practice on my real TI. Therefore the implementation in classic99 is not necessary for me. However, if it is not too much effort for you, I could also use classic99 for testing.

I wasn't responding to a request - for the last twenty years I've responded to all requests for DELETE with "no, use Windows".  There's no technical reason for it, I was just trying to keep Classic99's ability to destroy data to a necessary minimum. There's no technical challenge - it's a moral challenge.

 

I was just starting to come around to the concept of temporary files - something I've never used on the TI. Why do you need to create files that need to be deleted? Could they just not be overwritten next time?

[senior_falcon]

For what it's worth, there is a file called MB in the XBGDP. There is one string in the file. Normally it is a null string. If you are putting the runtime routines into low memory and choose to use MiniMemory to load them, it copies 24 bytes from the mailbox into the MB file. Then you change cartridges from XB to MiniMemory and start up the loader with OLD DSK1.MM32 and RUN. The MM32 loader reads the mailbox from MB. After the compiled program is loaded the mailbox is saved again, just in case you made changes. Upon return to XB, LOAD reads MB. If it finds null string it just goes on using the default values. Otherwise it restores the mailbox and then writes a null string to MB. This is not quite the same as deleting the file but is pretty close.

 

[wolhess]

13 hours ago, Tursi said:

I wasn't responding to a request - for the last twenty years I've responded to all requests for DELETE with "no, use Windows".  There's no technical reason for it, I was just trying to keep Classic99's ability to destroy data to a necessary minimum. There's no technical challenge - it's a moral challenge.

 

I was just starting to come around to the concept of temporary files - something I've never used on the TI. Why do you need to create files that need to be deleted? Could they just not be overwritten next time?

Hi Tursi,

yes, my temp files are simply overwritten. It works. In my XB program Remind Alarm I simply use existing entries of the current day from the monthly file created by Remind Me. So that I do not destroy the original calendar file by a program interruption of my program I use a copy of the monthly file of Remind Me. If there is an alarm for the day and this was acknowledged, then I mark this in my tempfile. Is everything ok I copy my tempfile to the Remind Me monthly file and thus overwrite the original file. So far so good. So that the Remind Me directory contains no unnecessary files, I delete currently my tempfile with the XB command
CLOSE # 1: DELETE.
In XB, this works as intended. In the compiled version the tempfiles simply stay. With Isabella6 I can now use DELETE DSK1.Filename.
As I said before, for me, no change in classic99 is necessary, since I usually use only my real TI anyway.

[Opry99er]

I am getting ready to start work on a very basic, simple dungeon crawler in XB256 to see if this would be a viable platform for my large CRPG in the future.  I have downloaded the latest version of the package and I'm excited to see what is possible with the column and row scrolling.   I won't need pixel scrolling for this project. 

 

My question to those who use it is, who among you has used this package to scroll a static window over a large map?  The new XB commands seem pretty intuitive, and the games which have been produced using falcon's support routines are incredible.  Has anyone done a large map, scrolled under a small window?  If so, I'd like to run the program and see what it feels like. 

 

Thanks in advance!

[SteveB]

Hi senior_falcon,

 

your Isabella made me say "this is too fast" for the first time about a XB program I wrote. In fact I resumed writing an old game I abandoned in 1984 because it was too slow to be fun. After some crude hacks it compiled and started working with intergers within 2 hours. But some 36 years ago I had the brilliant idea of not storing level data and save the memory, but recreating it every time by using the RANDOMIZE X function, feeding the level-number as the seed to the randomizer. As stated in the manual, Isabella ignores the RANDOMIZE statement, with and without an argument. It might be strange at first, but I use RANDOMIZE and RND to do the exact opposite of random numer generation, I generate repeatable numbers. 

 

This code produces identical output on XB for the same seed, but (pseudo-) random numbers when compiled:

10 INPUT "SEED:":S
20 RANDOMIZE S
30 PRINT INT(RND*100)
40 GOTO 10

 

With the help of an old IEEE article "RANDOM NUMBER GENERATOR FOR 16-BIT MACHINES" by John J. Komo and William J. Reid (1989) I developed the following subroutine:

1000 SUB RAND(SEED,OG,ERG)
1010 XDQ=INT(SEED/144)
1020 XMQ=SEED-(XDQ*144)
1030 SEED2=(227*XMQ)-(61*XDQ)
1040 IF SEED2>0 THEN SEED=SEED2 ELSE SEED=SEED2+32749
1050 ERG=INT(SEED/(32749/OG))
1060 SUBEND

The Seed will be updated with every call and starts to repeat after some 30.000 calls. The ERG will be 0<= ERG < OG, i.e. SEED=13 ::  CALL RAND(SEED,100,X) will set X to a number between 0 and 99 and advances the seed. Consecutive calls will bring the same sequence each time it is executed.

 

Will there be an Isabella 7 with RANDOMIZE SEED function or should I rewrite my code to use my own RAND function?

 

Thank you and I LOVE working on my old projects again with ISABELLA. My wife starts getting jealous...

 

Steve
 

[senior_falcon]

This can be done with the compiled code. Two steps are required:

1-Modify the RUNTIME2 file by turning 3 lines of code into comments.(Should be line numbers 156,157 and 158)

*****************************
MLTPLY BL @GET3
 
	CI R4,RND
	JEQ RAND2
	CI R5,RND
	JEQ RAND1
 
	MOV *R5,R7
	MPY *R4,R7
	MOV R8,*R6
	B @RTN
 
RAND1	MOV R4,R5		pointer to limit goes to R5
RAND2	MOV @>83C0,R1
*	CI R1,>C800		\                                       \ 
*	JL RAND5		 attempt to auto randomize               COMMENT OUT THESE THREE LINES
*	MOVB @>8379,R1	/                                       /
RAND5	LI R2,>6FE5
	MPY R1,R2

Remember to uncomment those lines if you want to go back to auto randomizing

 

2 - In the program, set the random number seed with CALL LOAD(-31808,SEED1,SEED2)

Here is an XB program that shows this:

5 INPUT "SEED1 ":SEED1
6 INPUT "SEED2 ":SEED2
10 CALL LOAD(-31808,SEED1,SEED2)
20 FOR I=1 TO 10 :: PRINT RND*100 :: NEXT I

If you want to use a seed for your setup and then go back to randomizing, you can CALL PEEK(-31879,X)::CALL LOAD(-31808,X) before each RND.

(I don't remember why the CI R!,>C800 is there. You may have to duplicate that as well.)

Good Luck!

 

(Edit) I should add that the random numbers generated will not be the same as those in XB, so testing would not be possible in XB.

Edited April 15, 2020 by senior_falcon

[senior_falcon]

One advantage of compiled XB code is that you can test out the program running in XB before compiling it. It bothered me that SteveB  cannot test out his program in XB beacuse the random numbers produced are different in XB and in compiled code. After some thought I came up with a work around for this.

Start with some more modifications to RUNTIME2. 8 lines will be commented out with asterisks and 1 line will be added. Save the file.

MLTPLY BL @GET3
 
	CI R4,RND
	JEQ RAND2
	CI R5,RND
	JEQ RAND1
 
	MOV *R5,R7
	MPY *R4,R7
	MOV R8,*R6
	B @RTN
 
RAND1	MOV R4,R5		pointer to limit goes to R5
RAND2	MOV @>83C0,R1
*	CI R1,>C800		<<<<<MAKE THIS LINE AND THE NEXT 2 LINES INTO COMMENTS
*	JL RAND5			 attempt to auto randomize
*	MOVB @>8379,R1		/
RAND5	LI R2,>6FE5
	MPY R1,R2
	AI R3,>7AB9
	MOV R3,@>83C0
	MOV *R5,R5
 
*RAND3	C R2,R5		<<<<<MAKE THIS LINE AND THE NEXT 4 LINES INTO COMMENTS
*	JL RAND4
*	SRL R2,1
*	JNE RAND3		added Sept 12, 2018 to fix crash when limit is zero
*	CLR R3			return a zero when limit is zero
	CLR R2			<<<<<ADD THIS LINE
RAND4	SWPB R3
	DIV R5,R2
	MOV R3,*R6
	
IRND	C *R13,R15   See if next word is a number or an instruction
	JGT RANDBK	go back if next word is instruction
	BL @GET2
	JMP RAND2
	
RANDBK	B @RTN

With these changes, this is now functionally identical to the random number generator in the console (This starts at >027A).

 

Part 2: There is an assembly subprogram in XB256 called IRND. This lets you set the upper limit for the random number; and returns a random number integer that is from 0 to the limit - 1. The format is CALL LINK("IRND",limit,variable,.....). For example, CALL LINK("IRND",100,X) behaves the same as X=INT(RND*100). Both give a random number from 0 to 99.

It just so happens that IRND uses the same random number generator as the one we just changed above in RUNTIME2.

The simple program below asks for the 2 bytes of the random number seed, pokes them to >83C0 and >83C1 and then uses IRND to generate 10 random numbers. If you run it under XB256 and then compile it,you will see that the random numbers produced are the same. Bear in mind that the random numbers are not the same as would be produced by RND, but at least this way you can test the program in XB before compiling it.

5 INPUT "SEED1 ":SEED1
6 INPUT "SEED2 ":SEED2
10 CALL LOAD(-31808,SEED1,SEED2)
20 FOR I=1 TO 10 :: CALL LINK("IRND",100,X):: PRINT X :: NEXT I