Jump to content
IGNORED

Extended BASIC G.E.M.


senior_falcon

Recommended Posts

2 hours ago, senior_falcon said:

 

Just curious to know what part of the statement you disagree with. 

That CALL LOAD is not usable for strings. Loops work just fine in XB. ;) Accessing the original string, sure, but on other systems where you have to poke arguments, people* just allocate a fixed memory space for the string to be copied to by the caller. It's slightly wasteful, not terribly convenient, but it's not the end of the world for simple functions.

 

However, I wouldn't want to do that for the many string functions in Missing Link, thus I agreed with your second statement. ;)

 

(* - people - well, okay, me. Once. ) ;)

 

Edited by Tursi
Link to comment
Share on other sites

18 hours ago, senior_falcon said:

If this can be made to work, then The Missing Link, T40XB and others could be used with a compiled XB program.

Pronouns can be tricky devils. Just to be clear, here my use of  "this"  means if the utilities NUMASG, STRREF, etc. can be made to interface with a compiled program. That way in the compiled program the assembly subroutines would be used exactly the same as they would be used in XB. So CALL LINK("CIRCLE", 100,100,50) would work the same when compiled as it does when running TML.

The more I ponder this the more hopeful I become.

  • Like 7
Link to comment
Share on other sites

14 hours ago, RXB said:

Hmmm RXB has CALL MOVES that does exactly that.

Moves hex strings or strings to or from any memory to or from any String Variable.

To bad so much resistance to RXB, it has most of the solutions.

 

 

Well, my baseball sim is on hold for the next version of RXB which will hopefully allow me to utilize SAMS in a simpler way. It's fully functional right now but doesn't have nearly the statistical depth that I'd like for it to have.

 

I'm using T40XB for my Choose-You-Own-Adventure style game because it makes accessing 40 columns easy, along with screen formatting subprograms which make it ideal for this type of a game.

 

I've attempted learning FB-Forth as suggested by that language's author, but just learning it and implementing it is a pretty huge task for what I am trying to accomplish, especially with limited time to dedicate to this & other projects I'd like to work on. Oh if only I was independently wealthy with all the time in the world... ?

  • Like 5
Link to comment
Share on other sites

1 hour ago, senior_falcon said:

Pronouns can be tricky devils. Just to be clear, here my use of  "this"  means if the utilities NUMASG, STRREF, etc. can be made to interface with a compiled program. That way in the compiled program the assembly subroutines would be used exactly the same as they would be used in XB. So CALL LINK("CIRCLE", 100,100,50) would work the same when compiled as it does when running TML.

The more I ponder this the more hopeful I become.

 

Perhaps you could get at the passed parameters without using NUMASG, STRREF, etc. as I did in this post.

 

...lee

Link to comment
Share on other sites

15 hours ago, senior_falcon said:

If I am running a compiled program (i.e. an XB program that has been converted to assembly language) exactly how would MOVES be of any use in transferring a string from the compiled program into an assembly language support subprogram?? 

So this does not run from a XB module using CALL LINKS?

(If you can do a CALL LINK you can do a CALL MOVES using RXB, up to you which one saves code.)

If it is totally Assembly with no XB access good luck that looks like a ton of more code to make.

Edited by RXB
comment added
Link to comment
Share on other sites

60FONTS.gif.2249b7c071be2b6653178669019b22bf.gif

Back to making good progress on XB 2.8 G.E.M. Thanks to Sometimes99 I was able to expand the fonts to a total of 60. You can see that I chose complete fonts - i.e. both upper and lower case characters except for fonts 33 and 34. It was tough having to eliminate 87 percent of those fonts, but more than 60 seems obsessive compulsive.

The Missing Link has been expanded to include Missing Link extras (plus a few more subroutines) which are now available at any time without having to load them into high memory and embed them with your program. It took a while to create the tools needed to test and debug this change. This seems to work perfectly. Now to go back to the start menu and make some revisions to my code. Then to add XB256, T40XB. I want to have XB 2.8 + XXB as an entry in the menu instead of doing it with CALL XXB. After that I hope to be able to add the assembly language loader for CALL LOAD to replace the slow GPL one that is normally with XB.

 

 

 

  • Like 6
Link to comment
Share on other sites

5 hours ago, senior_falcon said:

Nope. I suppose it could be done (not by me), but then your program size would necessarily have to be smaller. There's the trade-off. More features vs less program space.

Using SAMS this would not be a issue in XB or RXB, but then XB has no SAMS support so that is a big problem.

I do suppose it would best attack long term as if memory is lacking, using 1Meg added memory is the best approach.

  • Like 1
Link to comment
Share on other sites

I am excited by some performance improvements I've been making to The Missing Link. I've taken out some VSBW and VSBR routines and replaced them with faster routines. The short video below shows the original TML on the left and the improved version on the right. Both are running the start of the TMLDEMO program. Although I start the left program first, the right hand one quickly overtakes it. I think you'll agree that this is a nice performance improvement. 

 

TMLSPEED.gif.428de49881ce965769d285870b6f9da4.gif

 

 

  • Like 10
  • Thanks 1
Link to comment
Share on other sites

27 minutes ago, Vorticon said:

Nice! Will programs created with the original TML still work with the GEM version? I'm thinking of Orbital Rendez-vous which is very slow and could definitely benefit from performance improvements.

 

 

Orbit.dsk 180 kB · 2 downloads

Should work fine. The only thing that could cause problems is if you use direct PEEKs or POKEs. Because the memory locations of the code are different the addresses would be wrong. Once this is done I will give your program a try. 

  • Like 1
Link to comment
Share on other sites

1 hour ago, senior_falcon said:

Should work fine. The only thing that could cause problems is if you use direct PEEKs or POKEs. Because the memory locations of the code are different the addresses would be wrong. Once this is done I will give your program a try. 

Sounds good. Thanks! Here's a video of the program for speed comparison: 

 

  • Like 1
Link to comment
Share on other sites

You probably won't see much difference with this. It looks like you are plotting single pixels. The calculations for the pixels are in XB and there would be no speed gain there. And the bottleneck with PIXEL is the CALL LINK which is way slower than a couple of VSBW operations. I have hopes that it will be possible to use your own CALL LINKs with compiled code and that would be a big help for a program like this.

  • Like 2
Link to comment
Share on other sites

1 hour ago, senior_falcon said:

You probably won't see much difference with this. It looks like you are plotting single pixels. The calculations for the pixels are in XB and there would be no speed gain there. And the bottleneck with PIXEL is the CALL LINK which is way slower than a couple of VSBW operations. I have hopes that it will be possible to use your own CALL LINKs with compiled code and that would be a big help for a program like this.

You are probably right. The largest factor affecting performance is likely the many floating point calculations required for each pixel plot and not so much the plotting process itself although it would be nice to speed that up as well.

Link to comment
Share on other sites

  • 2 weeks later...

XB 2.8 G.E.M. is coming along nicely. The Missing Link and The Missing Link Graphic Adventure  have been adapted to the new environment and seem to work fine.

I do have a problem with XB256, which uses the interrupt routine to see if the character set is being loaded. Now the
XB code is loading the font from cartridge ROM instead of using the console GPL routines. If the font is being loaded, XB256 knows that the program has broken for some reason (Fctn 4, an error, a break point) and checks whether the program was using Screen2. If so then Screen2 is stored to RAM and replaced with Screen1.

There is an XML routine in cartridge ROM that moves the selected font to VDP ram. I think this problem can be fixed if I can find a way to ensure that upon return to GPL the LIMI 2 at >0070 always executes the interrupt routine pointed to by >83C4. One way might be to put in a delay loop before returning. Perhaps checking VSYNC would work. For example:

VDPSTA    EQU   >8802

VSYNC     CLR	R12
VSYNC1    TB	2		* Test CRU bit for VDP interrupt
	  JEQ	VSYNC1	        * Loop if not set
	  MOVB	@VDPSTA,R0      * Need to clear the status register
	  ANDI R0,>2000         * Isolate collision flag
	  MOV	R0,@COINC	* Save collision flag
          B	*R11

COINC     DATA  >0000

When TB 2 is set will that force LIMI 2 to always perform the interrupt routine?

Or better yet, could I set the CRU bit and force the interrupt routine to happen?

Any ideas??

  • Like 2
Link to comment
Share on other sites

3 hours ago, senior_falcon said:

When TB 2 is set will that force LIMI 2 to always perform the interrupt routine?

Or better yet, could I set the CRU bit and force the interrupt routine to happen?

 

If you set bit 2, you enable the interrupt sense of the 9901. Setting the bit does not trigger an interrupt.

 

The VDP interrupt output is routed to the interrupt 2 input of the 9901. If bit 2 is set to 0, no interrupt will be triggered. However, you can still read the value via TB (as it is the level of the VDPINT line). If you set it to 1, the 9901 will trigger an interrupt at the CPU (hardcoded level 1) when the VDPINT line becomes active.

 

You can disable the VDPINT line using video register 1. When disabled, no VDP interrupts will ever occur, independent of LIMI and bit 2.

  • Thanks 1
Link to comment
Share on other sites

The interrupts of the 9900 are level-triggered, which means that as long as the input line is asserted, the interrupt will occur as soon as the interrupt mask allows it.

 

Suppose the VDP asserts the VDPINT* line; this line goes to the 9901. If bit 2 has been set before, lowering to 0 means that the 9901 will trigger an interrupt. This interrupt goes via the EXTINT* line to the 9900, and the level is set to 1 by the ICx lines.

 

This EXTINT* line is continuously pulled down until you clear the interrupt in the VDP. If you have LIMI 0, the interrupt is not sensed by the CPU. As soon as you set the mask to 2, this is higher than the actual interrupt level, and this will trigger the interrupt microprogram as soon as the current microprogram (current instruction) has completed.

 

The interrupt is triggered by the asserted EXTINT* line. If you do a LIMI 2 without this line being asserted (0), no interrupt will occur.

 

You could do the following:

- Do a LIMI 0

- Poll bit 2

- As soon as it cleared, do a LIMI 2.

 

 

  • Like 1
Link to comment
Share on other sites

This test program seems to do what I want. The LIMI2L loop is performed until the interrupt routine sets the flag in R1 so it is no longer zero. The LIMI2L loop is exited and the loop counter sent back to XB.

When you run the program 10 CALL LINK("LIMI2T",X)::PRINT X the loop counter shows that LIMI 2 has been performed many times, usually in the hundreds. 

Uncommenting the 3 lines at LIMIL1 makes that loop happen until bit 2 is set. Then the LIMI 2 is performed and the interrupt routine is executed first time, every time, which you know because X is always 1.

Many thanks to Mizapf for your help on this! (Mizapf's suggestion was to loop until bit 2 was cleared, then do the LIMI 2. That did not work, but it does work if you loop until bit 2 is set.) All's Well That Ends Well, as the bard said. 

 

I think I read that this method does not work with the F18A. Any truth to this? 

XMLLNK EQU >2018
NUMASG EQU >2008
	DEF LIMI2T
WKSP 	BSS 32		WKSP IS AT >24F4
LIMI2T	LWPI WKSP	CALL LINK("LIMI2T",X)
	LI R2,ROUTIN
	MOV R2,@>83C4		start interrupt routine
	CLR R0			loop counter
	CLR R1			flag-will loop until r1<>0
LIMI2L	INC R0			increment counter
*LIMIL1 CLR R12
*       TB 2			read cru bit
*       JEQ LIMIL1		loop until not zero
	LIMI 2			
	LIMI 0
	MOV R1,R1		r1 will remain zero until interrupt routine has run
	JEQ LIMI2L		still zero, keep looping
LIMI3	MOV R0,@>834A		move the counter to FAC 
	BLWP @XMLLNK
	DATA >0020	cif	convert to floating point
	CLR R0
	LI R1,1
	BLWP @NUMASG		send loop counter back to XB
	LWPI >83E0
	B @>006A		return to XB
***************************
ROUTIN	INC @>24F6		interrupt routine-increments R1 to be <>0
	B *R11
	
	END

 

Edited by senior_falcon
Link to comment
Share on other sites

Seems inverted to me, but then I never had a good grasp of CRU stuff.

 

From the thread F18A MK2, post #593:

 

"The AVPC can allow motherboard writes to the 9918  within the first 16K?

Interrupts are no longer synchronized with VSYNC if the 9918 generates them."

 

I am not sure what this means, but since the AVPC is not the F18A, it sounds as if my method in post #146 above should work fine with the F18A.

Link to comment
Share on other sites

Many, many thanks to Mizapf and Tursi for their assistance! XB256 is now working properly with XB 2.8. The problem was solved this way:

1 - at the end of the font loading assembly routine in cartridge ROM I added:

LOOP  CLR R12

          TB 2

          JEQ LOOP

          B *R11

When this returns to the XB GPL code, it is set up to run the interrupt routine at the first LIMI 2

2 - Then in my interrupt routine I added:

    LI R8,>8300
    MOVB @>8373,@MONWS+17    (lsb of R8) now r8 has the stack pointer
    MOV *R8,R8            see what the stack is pointing to
    CI R8,>981A            if it is >981a then Xb is loading a font due to break, end or ??
    JNE MONIT1            XB is not loading font, so go on

 

    Now check if we're in screen 2 and if so then swap the screens.

Edited by senior_falcon
  • Like 3
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...