23 replies to this topic

[Vorticon]

Hi.

In order to jump start the use of Turbo Forth and give TI'ers an appreciation of how powerful that language is, I am launching a Turbo Forth game competition, where the competitors will have till the 2012 Chicago Faire in October to create a game in Turbo Forth. The only restriction will be that no embedded assembly language be used in order to level the field for those who do not have assembly skills. Judging will be by a yet to be determined panel during the Chicago Faire event, and there will be only one grand prize: a brand new in box 6K CC40 handheld computer.

Since I plan to also run, I will of course exclude myself from the judging. I am hoping that we will get at least 6 people to join so we can have a healthy competition. If you are interested, please let me know here. If you don't know forth, well you have plenty of time to learn it still! And you don't even need to own the Turbo Forth cart because it's already fully implemented in the Classic 99 emulator.

What say you?

[Willsy]

Wow this is really cool! If there's any interest I'll accelerate the completion if the book.

I'll also help out with Turboforth questions.

One if these days i'll pick up my manic miner source code again!

[JonnyBritish]

So in playing with TurboForth 1.1 under the awesome classic99 I tried this code after plugging in a PC Xbox controller

: TEST BEGIN 0 JOYST . AGAIN ;
TEST

As this takes the joystick 0 value, puts it on the stack then prints to the screen i would expect to see nothing but zeros when i am not pushing the stick or pressing fire.
What actually happens is that while mostly I see zeros...mostly..:-) I also see the value 28062 scroll by.

Apart from this I can press all combinations and fire and see the correct values as pre this from the docs.
actually just tried same code again and now i see 31's..weird!

Scans the selected joystick. For joystick #1 use a unit# of 0. For joystick 2

use a unit# of 1. The returned value is a bit code which can be decoded as

follows:

1=Fire

2=Left

4=Right

8=Down

16=Up

Since each direction has its own bit, combinations are possible: for

example, UP+LEFT+FIRE=19

Edited by JonnyBritish, Fri Feb 10, 2012 12:01 AM.

[sometimes99er]

JonnyBritish, on Thu Feb 9, 2012 11:48 PM, said:

: TEST BEGIN 0 JOYST . AGAIN ;
TEST

I went and tried out your code. Did about 20 tests, restarting, resetting and scrambling Classic99 without any specific controller other than standard arrow keys. Only saw zeros and 28062 (>6D9E), no 31. When TurboForth crashed, and it did several times, I started to try and measure the time before a crash, but nothing conclusive, in fact I've got it running now without any crash (more than 20 minutes). I turned on the HeatMap and it looks fine, right until the crash, which has been different every time - anything from complete freeze, garbage on screen etc.

Should probably hold my breath for a simple explanation ...

[Willsy]

No simple explanations... its a bug in JOYST caused by a last minute change that I didn't test properly. I'm pretty sure I published a replacement JOYST routine on this forum somewhere. It's just a few bytes of assembler. The version of JOYST in the TF Kernal corrupts the stack under some circumstances it's related to when/if an interrupt occurs - which was a nightmare to track down!

Sorry for the hassle guys....

[Willsy]

Guys, the issue with JOYST in V1.1 is discussed (and a fix given) here.

Just put this in a block somewhere, and load it when you need it. It replaces the JOYST routine built into the EPROM.

HEX
CODE: JOYST
C054 0221 0006 06C1 020C 0024 30C1 020C 0006 3541 06C1 0541
0241 001F C501 020C 8328 C80C 83D6 0300 0002 0300 0000 ;CODE
DECIMAL

[GroovyBee]

Good luck to the people that enter the contest. I'd love to enter but its been a long time since I programmed in FORTH and I have a ton of other retro project project commitments this year so realistically I won't have time to pick up the language again.

[kl99]

Great idea! This contest should be communicated to the yahoo groups as well.
I am interested. Are all versions of TurboForth legit? I have a preorder on v1.2 from Mark Wills - that's why I am asking.

Are there any other restrictions/limitations? I guess the need to have 32K to play the game is okay.

[sometimes99er]

kl99, on Fri Feb 10, 2012 5:31 AM, said:

Are there any other restrictions/limitations? I guess the need to have 32K to play the game is okay.

As I understand, TurboForth does not function without the 32K.

[JonnyBritish]

Wondering if Mark would consider a release of V1.2 now. If a bunch of people start hammering on it during their game development it would also function as a great test of the 1.2 release. Idea would be that by the TI Faire a bunch of games (hopefully) will have been tested on 1.2 and any bugs worked out.

Just a thought

[JonnyBritish]

Thanks Mark,

your new JOYST routine works perfectly and I do not even have to load the assembler!

[Willsy]

Hmmm.... That's not a bad idea... I wouldn't want to release it on EPROM though, as it's just too much to ask people to send their EPROMs back to Bob or myself for re-programming - they're likely to get annoyed!

I'll look into doing a 1.2 "pre-release" or beta release... Perhpas fold it into the next classic99 release...

[Vorticon]

kl99, on Fri Feb 10, 2012 5:31 AM, said:

Great idea! This contest should be communicated to the yahoo groups as well.
I am interested. Are all versions of TurboForth legit? I have a preorder on v1.2 from Mark Wills - that's why I am asking.

Are there any other restrictions/limitations? I guess the need to have 32K to play the game is okay.

Great! That's 2 of us so far. Any version of TF should be fine, and there are no other restrictions. Willsy, are you going to participate as well?

[Vorticon]

Well, I can't say that the response to this contest was overwhelming... It's still 2 of us as of yet, even after posting on the Yahoo listserv. I guess this is going to be DOA unfortunately. I'm still planning on developing a project in Forth regardless, although I'm not sure if it's going to be a game or yet another geeky demo

I feel that there is a lot of reluctance from TI ers to learn a new programming language, and I honestly can't blame them given the effort involved and the limited hobby time each of us has. Just look at the list of unfinished projects cluttering this forum, starting with Ultimate Planet which is still in limbo and in bad need of CPR...

Edited by Vorticon, Mon Feb 20, 2012 4:48 PM.

[idflyfish]

I would also be interested in this if it isn't DOA.

[JonnyBritish]

Count me in,

need a good excuse to dive into Forth and this is it.

[Tursi]

I'm interested, I just can't commit to it, at least unless I manage to get to a point where I have something to show.

Don't DOA it, let's see who jumps in at the last minute.

[idflyfish]

Tursi, on Mon Feb 20, 2012 11:19 PM, said:

I'm interested, I just can't commit to it, at least unless I manage to get to a point where I have something to show.

Don't DOA it, let's see who jumps in at the last minute.

Its ok. The only thing I can guarantee is an honest effort. Not sure the end product will be worth real consideration.

[Willsy]

I can throw something together if you want

Here's an example of what can be done in about half an hour.

Note how each routine (a 'word' in Forth speak) is 'factored', such that each word is self-contained. This means you can test a word as you write it, and when it's working, you move onto the next one. At the end, when you come to pull all these words together to make up your application, you're pulling in already de-bugged, isolated words, so the whole thing should 'just work'. Of course, it's not quite that simple in real life, but not far off. Once you have had some practice at it it is very natural. If you have only programmed in BASIC or XB then yeah, it's gonna hurt, but if you have programmed in C or PASCAL or VB etc then you will already be familiar with factoring your code into subroutines.

Just paste this into Classic99...

HEX
CODE: JOYST
C054 0221 0006 06C1 020C 0024 30C1 020C 0006 3541 06C1 0541
0241 001F C501 020C 8328 C80C 83D6 0300 0002 0300 0000 ;CODE
DECIMAL

FORGET segments
10 CONSTANT segments	  \ number of snake segments
50 CONSTANT obstacles	 \ number of obstacles
152 CONSTANT wall		  \ wall character
144 CONSTANT sBody		 \ snake body character
42 CONSTANT obstacle	  \ obstacle character
  8 CONSTANT bGround	   \ background character

CREATE charArray segments CELLS ALLOT
CREATE posArray segments CELLS ALLOT  \ segment positions
CREATE HArray segments CELLS ALLOT	\ segment horiz direction
CREATE VArray segments CELLS ALLOT	\ segment vert direction
0 VALUE segAddr  \ address of segment
0 VALUE HDir	 \ segment H direction
0 VALUE VDir	 \ segment V direction

1 $83D6 !	  \ prevent screen blanking

HEX
CREATE wallData
  22FF , 88FF , 22FF , 88FF , 22FF , 88FF ,
CREATE BGData  
  8142 , 2418 , 1824 , 4281 , 8142 , 2418 , 1824 , 4281 ,

wallData VALUE wallP \ pointer to wall data
0 VALUE wallOS	   \ wall data offset

BGData VALUE BGP	 \ pointer to background data
0 VALUE BGOS		 \ background data offset

: UDGs
  DATA 8 390F 7FFF FF7F 0F39   9CF0 FEFF FFFE F09C sBody DCHAR
  DATA 4 8040 2010 0804 0201 bGround DCHAR
  [ wall 8 * 800 + LITERAL ] wallData 8 VMBW
  [ bGround 8 * 800 + LITERAL ] BGData 8 VMBW
  ; UDGs
DECIMAL

: initColors
  18 7 0 COLOR  19 11 6 COLOR  1 13 0 COLOR ;

: border PAGE
   0 0 bGround [ 32 24 * LITERAL ] HCHAR
   0  0 wall 32 HCHAR   0 31 wall 24 VCHAR
  23  0 wall 32 HCHAR   0  0 wall 24 VCHAR ;
  
: initArrays ( -- )
  segments 0 DO
	1  charArray I CELLS +  !
	1  HArray I CELLS +  !
   32  VArray I CELLS +  !
  LOOP ;

: initPos ( -- )
  segments 0 DO 33 I +  posArray I CELLS +  ! LOOP ;

: renderObstacles ( -- )
  19 1 DO
	4 0 DO
	  J  29 RND 1+  [ obstacle LITERAL ] 1 HCHAR
	LOOP
  LOOP ;

: moveWall
  [ wall 8 * $800 + LITERAL ] wallData wallOS + 8 VMBW
  wallOS 1+ 4 MOD TO wallOS ;

: moveBG
  [ bGround 8 * $800 + LITERAL ] BGData BGOS + 8 VMBW
  BGOS 1+ 8 MOD TO BGOS ;

: moveSegments ( -- )
  segments 1- FOR
	charArray I CELLS +  @ IF
	  posArray I CELLS +  TO segAddr
	  HArray I CELLS + @  TO HDir
	  [ bGround LITERAL ]  segAddr @  V!
	  segAddr @  HDir +  V@
	  DUP [ bGround LITERAL ] = IF
		DROP  HDir segAddr +!
	  ELSE
		sBody = IF
		  HDir segAddr +!
		ELSE
		  HDir NEGATE  HArray I CELLS +  !
		  HDir 0> IF 144 ELSE 145 THEN TO sBody
		  segAddr @ [ 21 32 * 2- LITERAL ] >= IF
			VArray I CELLS +  @ TO VDir
			VDir 0> IF VDir NEGATE  VArray I CELLS +  ! THEN
		  ELSE
			VArray I CELLS +  @ TO VDir
			segAddr @ [ 63 32 + LITERAL ] < IF
			  VDir 0< IF VDir NEGATE  VArray I CELLS +  ! THEN
			THEN
		  THEN
		  VDir segAddr +!
		THEN
	  THEN
	  sBody  segAddr @  V!
	THEN
  NEXT ;

: mainLoop
  TRUE
  BEGIN
	moveSegments  moveWall  NOT DUP IF moveBG THEN
  0 JOYST 1 = UNTIL ;

: RUN ( -- )
  1 GMODE  1 SCREEN
  initColors  initPos  initArrays  border  renderObstacles  
  mainLoop  DROP ;

Type RUN for retro goodness. Press TAB (simulates joystick fire button) to quit.

[Willsy]

I'll also make V1.2 available for Tursi to put into the next Classic99 build. If no bugs come to light, I'll 'formally' release it and do an EPROM upgrade for cart owners. Note that EPROM upgrades are free (you pay postage).

[Vorticon]

Great! That makes 6 contestants so far, which should be enough to keep the contest alive This should be interesting.

[Vorticon]

Willsy, on Tue Feb 21, 2012 3:05 AM, said:

I can throw something together if you want

Here's an example of what can be done in about half an hour.

Note how each routine (a 'word' in Forth speak) is 'factored', such that each word is self-contained. This means you can test a word as you write it, and when it's working, you move onto the next one. At the end, when you come to pull all these words together to make up your application, you're pulling in already de-bugged, isolated words, so the whole thing should 'just work'. Of course, it's not quite that simple in real life, but not far off. Once you have had some practice at it it is very natural. If you have only programmed in BASIC or XB then yeah, it's gonna hurt, but if you have programmed in C or PASCAL or VB etc then you will already be familiar with factoring your code into subroutines.

This is really impressive! The possibilities are huge here.

[Lee Stewart]

I am thinking about participating.

I just have never been that interested in gaming (playing or programming). My programming interests since 1963 have almost always been about solving other kinds of problems, many of which are most assuredly related to game programming. It is not that I do not enjoy playing computer games. Rather, I avoid them because they are so addicting that they take time I would prefer spending in other ways.

Let's say that, for the moment, I am a definite maybe!

...lee

[Vorticon]

Lee Stewart, on Tue Feb 21, 2012 10:14 AM, said:

I am thinking about participating.

I just have never been that interested in gaming (playing or programming). My programming interests since 1963 have almost always been about solving other kinds of problems, many of which are most assuredly related to game programming. It is not that I do not enjoy playing computer games. Rather, I avoid them because they are so addicting that they take time I would prefer spending in other ways.

Let's say that, for the moment, I am a definite maybe!

...lee

In my book, game programming can be extremely challenging because not only do you have to struggle with the limited hardware resources, but you also have to make the end product fun! On the other hand, systems programming or scientific demos, while still challenging, can usually leave the fun part out. I love games, but my programming heart has always had a leaning towards scientific and mathematical projects (Model Rocket Simulator, Pi Calculator, SkyChart, Chaos Musings), and this is frequently reflected in my games as well where I rarely create arcade games (actually I only have one which is TI Puck from 1981!) and focus more on simulations.
I other words, I know where you're coming from, but I still think you should give it a shot. You might surprise yourself!