TurboForth Joystick Word, JOYST

[+Lee Stewart]

Mark (or anyone)...

 

I cannot find any documentation about using the TurboForth word JOYST except in the TF v1.1 Release Notes:

 

 

 

 

JOYST

( jstick# -- value) modified to invert the returned value, making decoding much simpler.

JOYST

also resets the screen blanking counter in the console interrupt routine to prevent screen blanking.

 

Unfortunately, this is not very helpful to me. In TI Forth, three values are left on the stack (ASCII, xpos, ypos). I have no idea how to use TF's word. I cannot even get it to respond with a value other than 0 when I use it in a loop in the emulators for joystick #1, i.e., 1 JOYST . I am trying to use the keyboard emulation of joystick #1 (Q,W,E,R,S,D,Z,X,C).

 

...lee

Edited May 21, 2012 by Lee Stewart

[JonnyBritish]

It should be 0 JOYST for #1 and 1 JOYST for #2 if I remember correctly.

 

I.e:

 

: TEST BEGIN 0 JOYST . AGAIN ;

 

The code *should* work, but it has never been tested, as I don't own any joysticks.

 

Just for reference, you will not get the same values as BASIC/XB, but you should get a different value for up, down, left & right, and sums for diagnals (i.e. up & left should be the sum of up and left).

=================

 

The joystick stuff works like this:

 

MSB LSB

0 0 0 0 0 0 0 0 0 0 0 x x x x x

| | | | |

| | | | Fire

| | | Right

| | Left

| Down

Up

 

Note: The bits default to 1 (they are 'active' low) so when nothing is going on, you'll get >1F (31) returned.============

i have classic99 set to PC JoyStick 1 for joy stick 1 and a xbox 360 pc usb controller plugged in.

 

running your code I get these values - awesome - now we have sprites+joystick control = game!

 

N - 15

NE - 11

E - 27

SE - 19

S - 23

SW - 21

W - 29

NW - 13

Fire with no direction - 30

n+fire - 14

nw+fire - 10

e+fire - 26

se+fire - 18

s+fire - 22

sw+fire - 20

w+fire - 28

nw+fire - 12

[+Lee Stewart]

I would actually expect it to work like TMS9900 Assembler; but, Assembler uses 1 and 2 for joysticks #1 and #2, respectively. And, like I said, nothing seems to work. I'll keep trying.

 

...lee

[Willsy]

Left=4

Right=2

Up=16

Down=8

Fire=1

 

Make sure "enable joysticks" is enabled in Options in Classic99 and set Joystick #1 to PC Keyboard. Then you can use the cursor keys for joystick #1 and TAB for fire.

 

Note: JOYST does not use KSCAN. It uses CRU and monitors the joystick lines directly.

 

Unfortunately, there is an evil evil bug in V1.1 in JOYST. It was only discovered a few days ago. I have fixed it already in V1.2 but that's really gonna piss the 1.2 people off.

 

The only solution for now would be a CODE word 'fix'.

 

Here is the corrected assembler code:

 

;[ JOYST ( joystick# -- value )
; Scans the joystick returning the direction value
_joyst	mov *stack,r1	; get unit number
	ai r1,6			; use keyboard select 6 for #0, 7 for #1
	swpb r1
	li r12,36
	ldcr r1,3
	li r12,6
	stcr r1,5
	swpb r1
	inv r1
	andi r1,>001f
	mov r1,*stack
	li r12,_next
	mov r12,@>83d6  ; defeat auto screen blanking
	mov @bank1_,@retbnk	; return to bank 1
	LIMI 2
	LIMI 0
	b @retb0
;]

 

: TEST BEGIN 0 JOYST . AGAIN ;

[+Lee Stewart]

Make sure "enable joysticks" is enabled in Options in Classic99 and set Joystick #1 to PC Keyboard. Then you can use the cursor keys for joystick #1 and TAB for fire.

 

Note: JOYST does not use KSCAN. It uses CRU and monitors the joystick lines directly.

 

So, what happens on the real iron for keyboard emulation of joysticks?

 

...lee

[idflyfish]

Thanks for the patch Willsy

[idflyfish]

I patched 1-02-Console.a99 with the code above (replaced the previous definition of JOYST) and recompiled with no errors. However, when I try to start the patched version of TurboForth as a user cart in Classic99 I get the TF blue screen but nothing else. I tried compiling without the patch and those binaries work fine as a user cart.

[Willsy]

Sorry idfly - there are more changes than JOYST in V1.2 - such that if you try to add that code to V1.1 it won't actually fit in the ROM!

 

What I mean was (but was prevented from elucidating further due to a power outage in our village) we'll have to take the de-bugged JOYST code from V1.2 and create a CODE word equivalent for V1.1 that can be loaded from a block, either at start-up, or just when required.

 

CODE words are strings of hex numbers that represent machine code. There is a utility on the blocks disk (available on the TF yahoo list - I'll also upload it to the TF website soon - I'm working on the web site right now) called ASM>CODE which takes a previously assembled ASM word (assembled with the TF assembler) and converts it into a code word. The benefit of a code word is two-fold:

• They take up a LOT less space in blocks
  
• You don't need to load the assembler; The CODE: and ;CODE words are in ROM
  

So, basically, CODE words take assembly code, and represent them as HEX. Its kind of like representing machine code in XB with DATA statements and poking the code into RAM.

 

Here is the (corrected) TF assembler code for JOYST:

 

ASM: JOYST ( JOYSTICK# -- VALUE)
  *SP R1 MOV,
  R1 6 AI,
  R1 SWPB,
  R12 36 LI,
  R1 3 LDCR,
  R12 6 LI,
  R1 5 STCR,
  R1 SWPB,
  R1 INV,
  R1 $1F ANDI,
  R1 *SP MOV,
  R12 $8328 LI,
  R12 $83D6 @@ MOV,
  2 LIMI,
  0 LIMI,
;ASM

 

So, what you do is load the assembler (block 9) and paste the above code into Classic99 - it will instantly give you an assembled JOYST routine (in RAM) ready to run. Now all calls to JOYST use this NEW routine, not the bugged old one in ROM. We could just store that ASM source code in a block and load it whenever we need it, but we'd also have to load the assembler first whenever we need it and that's a pain.

 

So, we'll convert it to a CODE word:

 

http://www.youtube.com/watch?v=zuZ_UOv6Y48

 

Instead of giving a disk file for ASM>CODE you can just enter a device of CLIP and it will write the CODE word to the windows clipboard (Classic99 only) and you can paste it straight into a document...

 

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

 

Like I just did

 

So, you just put that in a block somewhere - and load it when you want it.

 

This will be (already is) fixed in V1.2 but I don't see the point in releasing V1.2 yet - I want to see if any other bugs shake out first. It would be silly to release V1.2 'knee-jerk' fashion... It wouldn't be a problem if this weren't an EPROM based project!

 

Anyway, I'd like to apologise to V1.1 owners... I was confident that V1.1 was bug free... I should have known better... The mods to JOYST in V1.1 were the very last changes to go into that release; I should have tested it more thoroughly. Apologies.

 

Finally, here are the codes that JOYST returns:

 

1=Fire

2=Left

4=Right

8=Down

16=Up

 

+ combinations (obviously). So, for example, UP+LEFT+FIRE=19

 

Mark

[Willsy]

Note (for Lee) exactly the same codes are returned on real iron

[idflyfish]

Sorry idfly - there are more changes than JOYST in V1.2 - such that if you try to add that code to V1.1 it won't actually fit in the ROM!

 

What I mean was (but was prevented from elucidating further due to a power outage in our village) we'll have to take the de-bugged JOYST code from V1.2 and create a CODE word equivalent for V1.1 that can be loaded from a block, either at start-up, or just when required.

 

CODE words are strings of hex numbers that represent machine code. There is a utility on the blocks disk (available on the TF yahoo list - I'll also upload it to the TF website soon - I'm working on the web site right now) called ASM>CODE which takes a previously assembled ASM word (assembled with the TF assembler) and converts it into a code word. The benefit of a code word is two-fold:

• They take up a LOT less space in blocks
  
• You don't need to load the assembler; The CODE: and ;CODE words are in ROM
  

So, basically, CODE words take assembly code, and represent them as HEX. Its kind of like representing machine code in XB with DATA statements and poking the code into RAM.

 

Here is the (corrected) TF assembler code for JOYST:

 

ASM: JOYST ( JOYSTICK# -- VALUE)
  *SP R1 MOV,
  R1 6 AI,
  R1 SWPB,
  R12 36 LI,
  R1 3 LDCR,
  R12 6 LI,
  R1 5 STCR,
  R1 SWPB,
  R1 INV,
  R1 $1F ANDI,
  R1 *SP MOV,
  R12 $8328 LI,
  R12 $83D6 @@ MOV,
  2 LIMI,
  0 LIMI,
;ASM

 

So, what you do is load the assembler (block 9) and paste the above code into Classic99 - it will instantly give you an assembled JOYST routine (in RAM) ready to run. Now all calls to JOYST use this NEW routine, not the bugged old one in ROM. We could just store that ASM source code in a block and load it whenever we need it, but we'd also have to load the assembler first whenever we need it and that's a pain.

 

So, we'll convert it to a CODE word:

 

http://www.youtube.com/watch?v=zuZ_UOv6Y48

 

Instead of giving a disk file for ASM>CODE you can just enter a device of CLIP and it will write the CODE word to the windows clipboard (Classic99 only) and you can paste it straight into a document...

 

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

 

Like I just did

 

So, you just put that in a block somewhere - and load it when you want it.

 

This will be (already is) fixed in V1.2 but I don't see the point in releasing V1.2 yet - I want to see if any other bugs shake out first. It would be silly to release V1.2 'knee-jerk' fashion... It wouldn't be a problem if this weren't an EPROM based project!

 

Anyway, I'd like to apologise to V1.1 owners... I was confident that V1.1 was bug free... I should have known better... The mods to JOYST in V1.1 were the very last changes to go into that release; I should have tested it more thoroughly. Apologies.

 

Finally, here are the codes that JOYST returns:

 

1=Fire

2=Left

4=Right

8=Down

16=Up

 

+ combinations (obviously). So, for example, UP+LEFT+FIRE=19

 

Mark

 

Brilliant. Thanks for the how-to Mark.

[idflyfish]

Having problems saving the block after I import the new JOYST definition from a file into a block.

 

http://www.youtube.com/watch?v=6sN1XtwUGGg

Edited December 11, 2011 by idflyfish

[+Lee Stewart]

Having problems saving the block after I import the new JOYST definition from a file into a block.

 

I haven't yet tried your procedure in Classic99; but, what I have tried that I know works is to block and copy the text, edit the relevant screen ( 51 EDIT ), "Paste" from the Classic99 "Edit" menu, exit the edit screen (F9) and execute FLUSH . Now that I think about it, perhaps you should have executed the FLUSH before the LIST , though it doesn't seem that it should matter and, hence, your (and my) confusion .

 

You will, however, have a problem actually loading that code as is if you are not in HEX mode just prior to the LOAD .

 

...lee

[idflyfish]

Thanks Lee

 

I played with it some more. Whether I use copy and paste in Classic99 or if I use the WORD FILE>BLK I lose the data in the block if I do not go into HEX mode on line 1. I presume this is by design since the block would be useless without first going into HEX mode.

 

All is well. It seems I am just going through a few growing pains while learning TurboForth.

[Willsy]

No. All is not well.

 

It appears that FILE>BLK (or something it relies on (like DIRTY)) is broken. FILE>BLK should flush the file for you. It does this via the built in word DIRTY. DIRTY sets the status of block that is holding your imported data to dirty, so that FLUSH will actually flush it. Something is busted.

 

The reason it works when you edit the file (by adding HEX) is because the editor does the same thing - as soon as you change the block with the editor, the editor sets the blocks' status to dirty for subsequent flushing.

 

It could be FILE>BLK itself... That code is probably 18 months old and had little use; it could be that something in TF has changed which requires FILE>BLK to be tweaked. I'll have to investigate...

 

Oh when will it ever end!!

[Willsy]

The good news is, after a quick test, DIRTY seems to be working, which implies the fault is in BLK>FILE.

 

Anyone interested in the block-buffer manipulation words should check out the words BUF? CLEAN DIRTY DIRTY? & SETBLK in the attached (see the Block IO section).

 

TurboForth Words.pdf

[+Lee Stewart]

...

Oh when will it ever end!!

 

Not that it's much consolation, but it's this sort of online activity that may tweak other folks to try TurboForth, thus broadening the TF user base and all the benefits new eyes and hands can proliferate.

 

...lee

[jacquesg]

...

Oh when will it ever end!!

 

Not that it's much consolation, but it's this sort of online activity that may tweak other folks to try TurboForth, thus broadening the TF user base and all the benefits new eyes and hands can proliferate.

 

...lee

 

It can also work in the opposite direction. However, I still admire those who can get down into the inner workings of a program. I doubt that I will ever get to be that proficient but I try to follow what is happening.

 

Jacques

[idflyfish]

Well...I for one am learning a lot from the discovery of bugs. Additionally, TF's facility for correct these bugs using CODE words makes squashing them a lot easier.

 

I just wish I knew enough to help fix them.

Edited December 11, 2011 by idflyfish

[+Lee Stewart]

Well...I for one am learning a lot from the discovery of bugs. Additionally, TF's facility for correct these bugs using CODE words makes squashing them a lot easier.

 

I just wish I knew enough to help fix them.

 

You're getting there!

 

...lee

[+Lee Stewart]

The good news is, after a quick test, DIRTY seems to be working, which implies the fault is in BLK>FILE.

 

So far the only potentially buggy thing in the Forth source code I see is the use of numbers expected to be treated as decimal without insuring that is the case.

 

...lee

[Willsy]

I don't have the FILE>BLK code in front of me but I think I know what the problem is. The program adds lines from the input file to the block 1 line at a time. When It's done 16 it flushes the current block and begins a new one. And there's the problem. The input file was less than 16 so it didn't set the buffer dirty and flush.

 

Some cleanup/exit code is required at the end to flush the last block to disk.

[Willsy]

Yep. It's as I thought. Hmmm... that bug must have been there since day one... Strange that I never noticed it.

 

Just add the phrase 16 TO lc flush-blk to the end of the code, as shown below, to force the last block worked on to be flushed.

 

Phew! I'm glad it wasn't a problem with the kernal. Also, I've attached an updated classic99 BLOCKS file with the bug already corrected.

 

Mark

 

(Block 21)

CR 16 CLOAD file-type

.( FILE>BLK - imports a text file into a block file.)

.( e.g. 50 FILE>BLK DSK2.STUFF imports to block 50 onwards)

 

0 VALUE lc 0 VALUE blknum 0 VALUE blkaddr

: clrbuf HERE 66 32 FILL ;

: new-blk FLUSH blknum BLOCK TO blkaddr 1 +TO blknum ;

: read-line clrbuf HERE file #GET ABORT" Cant read file" ;

: put-line blkaddr HERE 1+ 64 VMBW 1 +TO lc 64 +TO blkaddr ;

: flush-blk lc 16 = IF blknum 1- BUF? DROP DIRTY FLUSH 0 TO lc

new-blk THEN ;

: FILE>BLK TO blknum 0 TO lc get-filename open-file

file #OPEN ABORT" Can't open input file" new-blk

BEGIN file #EOF? 0= WHILE read-line put-line flush-blk

REPEAT file #CLOSE 16 TO lc flush-blk ;

 

BLOCKS.zip

[+Lee Stewart]

Good catch, Mark!

 

But, I am back to thinking about the BASE thing. I am beginning to appreciate the BASE->R and R->BASE words of TI Forth more and more. It's a good thing not to assume the number base is anything in particular when loading screens. That can bite you when you least expect it. And, you cannot really anticipate the user's preferred base. There was a time in the late 70s when I actually preferred octal for some computer programming!

 

...lee