The Missing Link + Extended BASIC

[Gazoo]

Lowly Gazoo? You've always been "The Great Gazoo" to me!

Being able to call TML from a running program could have it's advantages. Suppose you wanted a LOAD program to load and activate TML, then run an XB program, such as this:

10 CALL TML::RUN "DSK1.PROGRAM" !must be in same line as CALL TML

When it starts, TML erases the XB program, but it should finish the line it is running.

Not sure if CALL TML in the middle of a program would crash or just exit to the command line.

 

Well, your example does work. As you know I've tested it. It causes a screen glitch but works otherwise. But only in a real short program such as the one you listed.

 

My preference is to not allow the user to f--k things up. That's why I put in the 'Rules'.

 

A CALL TML crashing would depend on the size of the program. The one in the example that runs another program right off the bat would always work. But there would be a case where it wouldn't and someone would call it a 'bug' and complain to all hell about what a POS software this is. And then I'd have to kill him, and we'd have a real mess with the police showing up and all that crap. So should we take our chances on people using the software conscientiously and not complaining, or do I take out the 'Don't do that, stupid!' error checking, and go to the electric chair?

 

Gazoo

[+Ksarul]

Actually, your last set of comments makes a nice tongue-in-cheek introduction to the capabilities of this fine product, Gazoo.

[+OLD CS1]

The Great Gazoo with a healthy collection of new avatars, no less!

[senior_falcon]

 

Well, your example does work. As you know I've tested it. It causes a screen glitch but works otherwise. But only in a real short program such as the one you listed.

 

My preference is to not allow the user to f--k things up. That's why I put in the 'Rules'.

 

A CALL TML crashing would depend on the size of the program. The one in the example that runs another program right off the bat would always work. But there would be a case where it wouldn't and someone would call it a 'bug' and complain to all hell about what a POS software this is. And then I'd have to kill him, and we'd have a real mess with the police showing up and all that crap. So should we take our chances on people using the software conscientiously and not complaining, or do I take out the 'Don't do that, stupid!' error checking, and go to the electric chair?

 

Gazoo

Imagine a menu program that lets you choose from several programs, some written in standard XB and some requiring The Missing Link. It would be nice to be able to have the program load and activate TML, then run the program. Those color blotches happen when you run the TML loader and then run a program from that. I wish it didn't happen, but don't think it is all that troubling.

My loader for TML will erase itself when it activates TML and then finish up the line it is running before exiting the program. You do not have CALL TML erase the program because there is no program to erase. One advantage of this is that if you started writing a program and then realized you forgot to load TML you can do it without erasing your work.

There is no way you can start up a program in XB, then CALL TML and expect the program to continue, other than something simple like RUN "DSK1.Program" in the same line. Have you experienced crashing when CALL TML is in a program? The few tests I did just spit out an error message, but not what I would call a crash.

And for what it's worth, I don't think you have to worry about riding the lightning. With the amount of time we spend on this foolishness, I'm sure an insanity plea would be successful!

[RXB]

RXB 5.55 used to have a Phoney DSK DSR to save and load program from lower 8K, but could be installed at upper 24K and change the pointers to leave it there.

Only difference was I put this into GRAM and made it a GRAM disk, but if you changed a pointer could be used in RAM or VDP too.

 

Here is the original program that may solve your problem.

100 !Saved program will stay in memory as long as you do not CALL INIT or turn memory expansion off.
110 !It will ever stay in memory when switching cartrides with a WIDGET.
200 CALL CLEAR
220 CALL CHAR(42,"AA55AA55AA55AA55",91,"7E8199A1A199817E")
230 CALL CHAR(45,RPT$("0",&"FF"&RPT$("0",10)&"10387CFEFE")
240 CALL CLEAR :: CALL HCHAR(2,4,42,26)
250 CALL VCHAR(3,4,42,5) :: CALL VCHAR(3,29,42,5)
260 DISPLAY AT(5,9)SIZE(12):"RAM-DISKETTE"
270 CALL HCHAR(8,4,42,26)
280 DISPLAY AT(12,4):"[ MARTIN KOTULLA 1985"
290 CALL HCHAR(13,6,45,22) :: DISPLAY AT(17,7):"DATAs CHECK?   Y"
295 DISPLAY AT(20,4):"CALL LINK("SAVE") store prog"
296 DISPLAY AT(22,4):"CALL LINK("LOAD") retrieve"
300 ACCEPT AT(17,22)BEEPSIZE(-1)VALIDATE("YN"):JN$
310 IF JN$="N" THEN 360
320 FOR I=8192 TO 8458 STEP 2 :: READ A,B :: SUM=SUM+A+B :: NEXT I
330 DISPLAY AT(20,5):"THE DATA-LINES ARE"
340 IF SUM<>20638 THEN DISPLAY AT(22,10):"INCORRECT!" :: END
350 DISPLAY AT(22,11):"CORRECT!"
360 CALL INIT :: RESTORE
370 FOR I=8192 TO 8458 STEP 2 :: READ A,B :: CALL LOAD(I,A,B) :: NEXT I
380 CALL CLEAR :: STOP
390 DATA 032,068,255,255,000,000,170,085,000,000,041,097,032,056,033,126
400 DATA 032,056,033,226,032,056,035,076,032,056,036,050,032,056,036,110
410 DATA 032,056,036,132,032,056,036,144,247,147,248,118,255,231,247,146
420 DATA 255,255,076,079,065,068,032,032,032,196,083,065,086,069,032,032
430 DATA 032,122,000,000,002,001,032,050,002,129,032,066,027,014,192,001
440 DATA 002,002,131,074,140,176,022,006,140,176,022,004,140,176,022,002
450 DATA 192,048,004,080,002,033,000,008,016,239,002,000,037,000,200,000
460 DATA 131,034,002,224,131,224,004,096,000,206,002,224,032,008,192,032
470 DATA 131,132,096,032,131,048,002,032,033,012,002,128,064,000,026,003
480 DATA 002,000,011,000,016,236,007,032,032,048,192,032,131,048,002,001
490 DATA 033,012,220,112,136,000,131,132,018,252,200,032,131,048,032,040
500 DATA 200,032,131,050,032,042,200,032,131,132,032,044,200,032,131,134
510 DATA 032,046,016,029,002,224,032,008,200,032,032,048,032,048,022,003
520 DATA 002,000,029,000,016,204,192,032,032,040,002,001,033,012,220,049
530 DATA 136,000,032,044,018,252,200,032,032,040,131,048,200,032,032,042
540 DATA 131,050,200,032,032,044,131,132,200,032,032,046,131,134,004,192
550 DATA 216,000,131,124,002,224,131,224,004,096,000,112
560 END

Edited April 8, 2015 by RXB

[Tursi]

This is fantastic, I definitely want to make a cart for myself on this one. TML was always my favorite extension back in the day, it's awesome that we have new versions kicking around.

[JamesD]

Awesome work!

If I had known someone could implement this so fast I probably would have asked sooner.
But seeing as how I only used TML for the first time for drawing the Fedora image plot a few weeks ago it wouldn't have made much difference.

[Tursi]

Tested with the only app I still have (my old TMNT game), and it works fine, although I had to make a slight change to the start up code. (Nothing wrong with TML - the code installed a sample audio playback by overwriting one of TML's functions, and it turns out that they moved around a bit and it now overwrites one it needs ).

[Opry99er]

TEENAGE MUTANT NINJA TURTLES game on the TI?!?!?! Wha.whaaaaat??

[Gazoo]

Imagine a menu program that lets you choose from several programs, some written in standard XB and some requiring The Missing Link. It would be nice to be able to have the program load and activate TML, then run the program. Those color blotches happen when you run the TML loader and then run a program from that. I wish it didn't happen, but don't think it is all that troubling.

My loader for TML will erase itself when it activates TML and then finish up the line it is running before exiting the program. You do not have CALL TML erase the program because there is no program to erase. One advantage of this is that if you started writing a program and then realized you forgot to load TML you can do it without erasing your work.

There is no way you can start up a program in XB, then CALL TML and expect the program to continue, other than something simple like RUN "DSK1.Program" in the same line. Have you experienced crashing when CALL TML is in a program? The few tests I did just spit out an error message, but not what I would call a crash.

And for what it's worth, I don't think you have to worry about riding the lightning. With the amount of time we spend on this foolishness, I'm sure an insanity plea would be successful!

 

Ok, I took out the requirement of not being able to use a CALL TML(xxx) in a program. The Grom file to do so is attached to this message.

Be aware that if you already have TML loaded and do a CALL TML(xxx) in a program, the error routine that TML is already loaded will kick in, and not in a good way as you will be joining Peter Pan in never-never land.

 

Gazoo

 

[DELETED attachment=386821:XBtmlOKinPROGRAMg.bin]

Edited April 9, 2015 by Gazoo

[+Vorticon]

Harry, I am running into a couple of issues with TML:

 

- When using CALL LINK("INPUT"...) with a prompt string, the input cursor is placed over the beginning of the string instead of at the end, so any input will overwrite the string

 

- When clearing the screen with CALL LINK("CLEAR") after loading a bitmap image with CALL LINK("LOADP"...), the screen does not completely clear

 

Any thoughts on this?

[senior_falcon]

Harry, I am running into a couple of issues with TML:

 

- When using CALL LINK("INPUT"...) with a prompt string, the input cursor is placed over the beginning of the string instead of at the end, so any input will overwrite the string

 

- When clearing the screen with CALL LINK("CLEAR") after loading a bitmap image with CALL LINK("LOADP"...), the screen does not completely clear

I guess calling it a "prompt string" is not quite right; maybe "suggested string" would be a better description. If you want a prompt like "Enter your name: " you can put it on the screen with CALL LINK("PRINT"...) and then use CALL LINK("INPUT"...) to accept the name.

 

CALL LINK("CLEAR") will only clear out the pattern table; the color table is left alone. So to totally clear the screen you should CALL LINK("CLEAR")::CALL LINK("COLOR",FG,BG) and this will clear the pattern table and set the colors to FG and BG.

 

Gazoo wrote:

Ok, I took out the requirement of not being able to use a CALL TML(xxx) in a program. The Grom file to do so is attached to this message.

Be aware that if you already have TML loaded and do a CALL TML(xxx) in a program, the error routine that TML is already loaded will kick in, and not in a good way as you will be joining Peter Pan in never-never land.

I see what you don't like about this; In a running program CALL TML does indeed send you off the edge of the world. Maybe have CALL TML check if it is already loaded and if a program is running then skip the error message and go on with the XB program. Or maybe you could break the program, (as in Fctn 4), return to the command line, and then print the error message.

Edited April 9, 2015 by senior_falcon

[+Vorticon]

I guess calling it a "prompt string" is not quite right; maybe "suggested string" would be a better description. If you want a prompt like "Enter your name: " you can put it on the screen with CALL LINK("PRINT"...) and then use CALL LINK("INPUT"...) to accept the name.

 

CALL LINK("CLEAR") will only clear out the pattern table; the color table is left alone. So to totally clear the screen you should CALL LINK("CLEAR")::CALL LINK("COLOR",FG,BG) and this will clear the pattern table and set the colors to FG and BG.

 

 

Got it. Thanks.

[Tursi]

TEENAGE MUTANT NINJA TURTLES game on the TI?!?!?! Wha.whaaaaat??

 

It's not very good. But I guess now that TML is available in distributable forms, I can go ahead and post it! Maybe this weekend.

 

But it's not very good.

[Opry99er]

I'm sure it is amazing. Cant wait.

[Tursi]

You expect too much from me 30 years ago.

 

http://harmlesslion.com/software/tmnt (tested on all three versions of TML).

 

Video here (will take another hour to upload): http://youtu.be/GZy95VYyeJY

[Opry99er]

Hey man, that is pretty impressive for a game written with no modern tools!!! I'll be DLing it later today... Just watched the video.

 

Thanks for posting!

[JamesD]

I just looked at the TMNT game video and it looked great for BASIC.

[Opry99er]

^^YUP

[Gazoo]

Gazoo wrote:

Ok, I took out the requirement of not being able to use a CALL TML(xxx) in a program. The Grom file to do so is attached to this message.

Be aware that if you already have TML loaded and do a CALL TML(xxx) in a program, the error routine that TML is already loaded will kick in, and not in a good way as you will be joining Peter Pan in never-never land.

I see what you don't like about this; In a running program CALL TML does indeed send you off the edge of the world. Maybe have CALL TML check if it is already loaded and if a program is running then skip the error message and go on with the XB program. Or maybe you could break the program, (as in Fctn 4), return to the command line, and then print the error message.

 

Here's the solution I like the best, and you don't ever have to be forced to transport to a far away place.

 

If TML is already loaded and you attempt to load it again in a running program, you will be honked at. There will be no warning message to mess up the display, though, and the program will continue running without executing the CALL TML(xxx) command again.

 

The normal command line warning with honk and text if you attempt to load TML twice has been left in place.

 

This should suffice, I hope. Anyway, I like it.

 

Gazoo

 

[DELETED attachment=386951:XBTML.zip]

Edited April 9, 2015 by Gazoo

[Gazoo]

Ok, already found a bug. The previous upload won't work on a real TI. This one does.

 

Gazoo

 

 

XBTML.zip

 

 

P.S. I had to make a cartridge to test this. The cartridge on a real TI is pretty cool.

Edited April 9, 2015 by Gazoo

[senior_falcon]

That seems like a good way to do the error checking. Will test it out later.

[Tursi]

I just looked at the TMNT game video and it looked great for BASIC.

 

It's like Hyper Racer, makes good screenshots, but gameplay will let you down. Still, TML made it easy to make it look good.

[+Vorticon]

Yes, unlocking the power of bitmap graphics for the XB programmer is awesome, particularly backgrounds. That said, in the early days, creating such backgrounds was very labor intensive, which may have discouraged users from taking full advantage of TML. Nowadays, particularly with Tursi's image conversion tool, it's a snap

Looking back, I could easily have programmed my Chaos Musings program in XB under TML rather than painfully in assembly and the speed of calculations would have been pretty similar. Take foot, kick butt...

[Retrospect]

I don't know of any other micro where you could knock out a game like that in BASIC. I know it's extended, but still - Basic .... look at the C64 and Vic 20 for example ... they would take at least a minute to generate the characters let alone attempt the game. One up for TI and a good show from Tursi. Brilliant stuff.

 

Also cheers to Harry W. for providing us with this great extension. After my horse racing game is done with I'll be having another look into TML to see what I can or can't do.

Edited April 10, 2015 by Retrospect