BASIC on CART Contest (BoCC)

[unhuman]

I think a compiled version would be nicer... I should learn how to do that

[+retroclouds]

unless we compile the winning game into an EA5 and then do a cartridge conversion, I believe "yes", it will jump to command prompt... I'm thinking more and more that we should compile the winning game, but it's not up to me... this is y'all's contest, so you let me know what you think. =)

 

Compiled programs are more efficient and fast... of course it might take modification of the BASIC code a few times to get the timing correct in the assembly version. For full-on turn based games, they may compile just fine without modification.

 

There's a small disadvantage to the compiled version from my point of view.

The thing is that it will not run on a bare TI-99/4A console, you will need 32K memory expansion, even when put on cartridge.

 

For the original TI basic program that won't be the case.

Tursi's loader just copies it into VDP memory and the TI basic interpreter will execute it from there.

[+OLD CS1]

hehehe Was not my intention to cause such a dilemma with the FCTN-4 thingie. Is there no special bit to set to prevent the console interpreter from interpreting a BREAK? I know you can at least disable FCTN-= (QUIT) with a CALL LOAD, but that is handled by the operating system, and of course XB has the ON-BREAK, but that is a different interpreter altogether.

 

While I doubt protection is an issue, I do know that I have crashed the console BASIC interpreter by attempting to list XB programs before.

[unhuman]

hehehe Was not my intention to cause such a dilemma with the FCTN-4 thingie. Is there no special bit to set to prevent the console interpreter from interpreting a BREAK? I know you can at least disable FCTN-= (QUIT) with a CALL LOAD, but that is handled by the operating system, and of course XB has the ON-BREAK, but that is a different interpreter altogether.

 

While I doubt protection is an issue, I do know that I have crashed the console BASIC interpreter by attempting to list XB programs before.

 

Ummm... Could not the loader put the correct byte in memory before loading? Hrmmm See, that's what happens when someone who doesn't know jack starts thinking.

[+OLD CS1]

Ummm... Could not the loader put the correct byte in memory before loading? Hrmmm See, that's what happens when someone who doesn't know jack starts thinking.

 

I am certain this would be possible, but I am not so certain that the console TI BASIC interpreter has the ability to ignore BREAK. Any gurus to speak on this matter?

[+retroclouds]

For sure no guru. I did find a snippet of Basic interpreter code (written in GPL) that seems to handle break.

Check Page 192 in the TI-Intern book (see development resources thread).

 

Don't think there's a chance to prevent FNCTN-4 from breaking the program.

One thing that comes to mind, is that Tursi's loader could set a hook for the ISR routine

which executes some assembly code in the cartridge space which in turn could mess with the memory locations where the keycode is stored.

 

Dunno if something like that would be doable, since I don't know the ISR routine and keyscan routine that well.

Also could imagine that jumping between GPL and assembly on an unexpanded TI can be cumbersome (depending on what the assembly program does).

Guess, we'll need some input from Tursi.

 

Just for fun, here's the GPL code I found in the TI intern book.

 

Break:
4E2E : CZ    @>8389                                GROM flag?
4E31 : BR    GROM@>4DEA                            Yes, then go on in Basic, since not permitted
4E33 : AND   VDP*>832E,>7F                         Remove break point
4E37 : SCAN                                        Keyboard scanning
4E38 : DST   VDP@>03EC,@>832E                      Save pointer for continue
4E3C : CZ    @>8389                                GROM flag?
4E3F : BR    GROM@>4DC6                            Yes, then continue
4E41 : CALL  GROM@>56CD                            Scroll
4E44 : CALL  GROM@>0036                            Bad tone
4E47 : MOVE  >0010 TO VDP@>02E2 FROM GROM@>20E9    Text "Breakpoint in"
4E4E : DST   @>8320,>02F2                          Pointer for output of the line number
4E52 : CALL  GROM@>5645                            Write line number
4E55 : CALL  GROM@>201C                            Load VDP
4E58 : B     GROM@>2012                            Basic return

 

EDIT: My 2 cents, I'd rather leave the FNCTN-4 in place. It's cool to list a TI-basic program stored in ROM

and seeing the first remark line say 'Game written by xxxxx'

[kl99]

My knowledge is limited but as far as I know there are two official cartridges made, which uses Ti Basic.

Personal ??? and ??? .

Maybe we can check out their code for preventing FCTN+4 breaks the code.

[Opry99er]

Those cartridges modify the console BASIC in GROM to allow for extra calls, but to my knowledge--- they're written in GPL.

[+adamantyr]

Those cartridges modify the console BASIC in GROM to allow for extra calls, but to my knowledge--- they're written in GPL.

 

I could break out of Hyper Racer, which is a cartridge-based BASIC launch. So yeah, other than cutting the pre-load, it operates like any other BASIC game.

 

Adamantyr

[Tursi]

Oi...

 

Let's see if I can catch all the points...

 

For one, I think compiling the game defeats the purpose of having a contest where the goal is a game that plays well in TI BASIC.

 

As for FCTN-4, we could probably find some memory addresses to screw with that will prevent the game from being listable (ie: crash if someone tries - I have seen such hacks before) -- but why? It's BASIC, and for that matter, only three people will possess the cartridge, IIRC. The author being one of them! I think it'd kind of cool if you can list it.

 

A console interrupt probably won't work - it only fires once per video blank - it's possible for TI BASIC to execute several instructions in that time (it's also possible for several frames to go by in one instruction, but I digress...) the point is, that if you did hack something in there, it has a good chance of missing the keypress. In truth I think it would never see the keypress anyway, because interrupts are disabled at the point in time where the interpreter checks the keyboard.

 

I suspect that TI BASIC running from GROM probably goes through a slightly different loop than TI BASIC from VDP, since it's not intended to return to the command prompt. I have not looked too deeply into that (but the code that Retroclouds posted backs that up). We could load the BASIC program on my GROM chip, but we don't have a production board for that yet, which is why I made the 16k cart loader program.

 

Looking into the code Retroclouds posted, it looks like that actually handles the BREAK itself.. the code that scans the keyboard is a little earlier:

 

1982 06A0 BL @>0020 Clear key scan
1984 0020
1986 134F JEQ >1A26 End

 

The actual test for FCTN-4 is here (after a vector at >0020):

 

CLEAR keyboard scanning(status EQU, if pressed):
04B2 020C LI 12,>0024 Load CRU keyboard select
04B4 0024
04B6 30E0 LDCR @>0012,3 >00
04B8 0012
04BA 0B7C SRC 12,7
04BC 020C LI 12,>0006
04BE 0006
04C0 360C STCR 12,8 Fetch CRU
04C2 2720 CZC @>0036,12 Right key?
04C4 0036
04C6 160A JNE >04DC
04C8 020C LI 12,>0024 CRU 2nd key
04CA 0024
04CC 30E0 LDCR @>0074,3 >03
04CE 0074
04D0 0B7C SRC 12,7
04D2 020C LI 12,>0006
04D4 0006
04D6 360C STCR 12,8 Fetch CRU
04D8 2720 CZC @>0036,12 Right key
04DA 0036
04DC 045B B *11 Back

 

It looks like all immediate code and ROM bytes, I think we're out of luck for disabling it. Protection is an XB concept, BASIC doesn't have it.

 

 

The bigger problem with the console interrupt idea is there's no RAM to store it in. We would have to find a few bytes of scratchpad RAM as that's the only place it CAN exist. It just occurred to me, there is enough room in the cartridge ROM for the interrupt routine. One way that this COULD work, then, would be to check whether the program is still running. If it has stopped, then reset the console. This would take more code than I like, though, as the interrupt would need to stop itself before rebooting to prevent an infinite loop (an infinite loop would take less code though!). Something like this:

 

 MOV @>8344,R0    * Test state - 0=not running
JNE OK
CLR @>83C4     * Disable interrupt
BLWP @>0000    * reset
OK
B *R11

 

I tested this and it works - the breakpoint still happens, so you know it's BASIC unfortunately, but as soon as you press enter on any command the run flag is cleared and the interrupt fires. Attached is a modified version of my Hyper Racer with this changed header.

 

HyperRacer_NoList.zip

[Opry99er]

Thanks for this work, Tursi!!! I'm happy with your conclusions.

 

Seems very reasonable and harmless---- what you say guys?

[sometimes99er]

First of all it is great to have this as a first price. A TIB game in a cart ? Cool !

 

Secondly it's also cool, after inserting a cartridge, selecting it, having it start faster than normally - and that's even after "loading", and also being able to break and list.

 

The new facility is cool too. You can break, but you can't do much else.

 

Lastly, wouldn't the user interrupt hook be available for a hardcoded check of FCTN-4 ? Even though it might not check every frame, it can't be much more worse than ordinary TIB FCTN-4. If I remember correctly I hold FCTN-4 to break !?

 

[unhuman]

I remember using Pre-Scan It! by Asgard (and I bought it) to inject various directives / pre-initialize stuff so that they started near instantly (XB required).

[sometimes99er]

Would you believe it, I've already scrapped 4 BoCC projects and started 2 new. All of them being puzzle games (bah!). Got some in-game-graphics for all of them ranging from a bit mediocre to somewhat pleasant. Haven't got anything to show - since it might all be recycled for some later assembler or compiler versions. If or when I find a game concept worth bringing further, I'll try and spice it up (with a bit of action, effects and super graphics).

 

[Tursi]

Lastly, wouldn't the user interrupt hook be available for a hardcoded check of FCTN-4 ? Even though it might not check every frame, it can't be much more worse than ordinary TIB FCTN-4. If I remember correctly I hold FCTN-4 to break !?

 

Yeah, I think you're right - I considered this after I went to bed last night. In fact we could just call the ROM-based test code, since it runs in 16-bit ROM it'll be fast and we only need a BL. The odds are that nobody can hold FCTN-4 for less than 1/60th of a second, so it would catch it (but I'd still check the run flag too, just in case). That way, you get the Master Title Page just for pressing FCTN-4.

 

So the changed code looks like this:

 

PROTECT
MOV @>8344,R0	* Test state - 0=not running
JEQ REBOOT
MOV R11,R0      * Save return address (CLEAR test only uses R12)
BL @>0020	* use the console routine to check CLEAR
JEQ REBOOT
B *R0		* all okay

REBOOT
CLR @>83C4	* Disable interrupt
BLWP @>0000	* reset

 

Tested this, and it works too. I'll make it an optional part of my cartridge conversion tool.

 

hyperracer_NoClear.zip

 

I think this just proves that even the "impossible" can usually be accomplished.

Edited November 27, 2010 by Tursi

[Opry99er]

Great stuff Tursi. =) I like this concept a whole lot. Glad you came up with the solution we needed. =)

[sometimes99er]

I was afraid the console routine to check CLEAR would run into the infamous Time Delay @>0498, but it doesn't seem so. I guess your solution will be a handful of bytes shorter than a more direct CRU hit approach. Bravo.

 

Only thing is, you're going from TIB to cart faster than I can say Strawberry.

Edited November 27, 2010 by sometimes99er

[+retroclouds]

Just gave it a try, works like a charm!

 

Hmmm, just getting some crazy thoughts here. You could take this idea a step further and use ROM code to implement

some kind of "basic" sprite functionality. The question is how you would "interface" with the sprite code, in other words

tell it what to do.

 

Ofcourse development of such TI-Basic game wouldn't be very practical on a real TI-99/4A, but with

a hacked/enhanced classic99 emulator, why not ?

And then you just generate the cartridge ROM using the windows tool.

 

Dunno if that's the way to go, but the idea is kinda cool anyway

Edited November 28, 2010 by retroclouds

[Tursi]

Just gave it a try, works like a charm!

 

Hmmm, just getting some crazy thoughts here. You could take this idea a step further and use ROM code to implement

some kind of "basic" sprite functionality. The question is how you would "interface" with the sprite code, in other words

tell it what to do.

 

Ofcourse development of such TI-Basic game wouldn't be very practical on a real TI-99/4A, but with

a hacked/enhanced classic99 emulator, why not ?

And then you just generate the cartridge ROM using the windows tool.

 

Dunno if that's the way to go, but the idea is kinda cool anyway

 

hehe.. I think just use XB at that point.

[+adamantyr]

Okay, so mine's done... how's everyone else doing? The top 3 doesn't mean much if there was only three entries!

 

Adamantyr

[unhuman]

Okay, so mine's done... how's everyone else doing? The top 3 doesn't mean much if there was only three entries!

 

Adamantyr

 

I sort of got bogged down at work + motivational issues, but I pretty much only have to do levels now. I think I currently have ~15. There are 33 total that I can "easily" steal. They each get more complicated, so I need to test all the nuances of the buttons, etc, to ensure they behave properly. I should probably add other features first - score tracking - perhaps level skips..... And maybe instructions since I don't want to write a document...

 

I guess at this point it's all about whether or not I feel it's worth completing completely...

 

-Howie

Edited December 3, 2010 by unhuman

[InfernalKeith]

Okay, so mine's done... how's everyone else doing? The top 3 doesn't mean much if there was only three entries!

 

Adamantyr

 

Not sure if I'm finishing mine or throwing in the towel. Slowness issues aside, I dunno if I have what it takes and/or the memory space to put in good enough AI to make the computer worth playing against. And without that, the game has no point at all. If I'd been paying attention to how limited IF-THEN statements were in TI BASIC, I might not have bothered with this idea at all.

[+adamantyr]

Not sure if I'm finishing mine or throwing in the towel. Slowness issues aside, I dunno if I have what it takes and/or the memory space to put in good enough AI to make the computer worth playing against. And without that, the game has no point at all. If I'd been paying attention to how limited IF-THEN statements were in TI BASIC, I might not have bothered with this idea at all.

 

Best way to deal with it is to scale back the features in the game. I had to ditch what I thought was a pretty nifty title sequence to make room for level data and code changes in Aperture. And to be honest, I got pretty lucky I could squeeze my desired level count (16) into the game... I was ready to have to stick with 10 or 12 levels if need be.

 

AI is really hard to write, in ANY form of BASIC. Most AI relies upon vast amounts of stored data to make weighted decisions, and a lot of calculations.

 

Heck, I started to write out my design for a turn-based strategy game... but even at a glance, I suspect it's way too much for TI BASIC to do.

 

Adamantyr

[InfernalKeith]

Not sure if I'm finishing mine or throwing in the towel. Slowness issues aside, I dunno if I have what it takes and/or the memory space to put in good enough AI to make the computer worth playing against. And without that, the game has no point at all. If I'd been paying attention to how limited IF-THEN statements were in TI BASIC, I might not have bothered with this idea at all.

 

Best way to deal with it is to scale back the features in the game. I had to ditch what I thought was a pretty nifty title sequence to make room for level data and code changes in Aperture. And to be honest, I got pretty lucky I could squeeze my desired level count (16) into the game... I was ready to have to stick with 10 or 12 levels if need be.

 

AI is really hard to write, in ANY form of BASIC. Most AI relies upon vast amounts of stored data to make weighted decisions, and a lot of calculations.

 

Heck, I started to write out my design for a turn-based strategy game... but even at a glance, I suspect it's way too much for TI BASIC to do.

 

Adamantyr

 

 

 

I'm gonna old-school it over the weekend and sit down with some graph paper, and try to come up with any possible scenarios for the AI to run into, and maybe even do a half-assed flowchart of outcomes. I thought this game would work because it's total simplicity - you move on colored tiles, you shift tiles, you get from point A to B to C. But I hadn't counted on stuff like the AI getting stuck behind a certain configuration of colors and just walking back and forth between two tiles, over and over... or getting stuck and not having the sense to back out and go around.

 

On the plus side, play-testing the game as-is did show me that there's potential for great conflict IF the AI is good. The computer player racks up a lot more points than you, as he scores the most when he walks on black tiles, and the game generates more and more of them as the round progresses. You have to not only beat the computer to the final portal, but have a higher score than it, to win -- so there's blocking and tile-shifting strategies that the player will have to use to help close the gap and pull ahead to win before he gets to the portal.

 

I may finish it in BASIC just to say I did it, even if it ends up needing overdrive to be playable, and then rig it to work in XB. If I get it finished. Hopefully once I get it all down on paper it won't seem quite so formidable.

[Tursi]

oooh.. you wusses. Get coding!

 

(says the guy without an entry... )