Jump to content
Sign in to follow this  
Lee Stewart

TurboForth Joystick Word, JOYST

Recommended Posts

Mark (or anyone)...

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




[indent=1][b]JOYST [/b]( jstick# -- value) modified to invert the returned value, making decoding much simpler. [b]JOYST [/b]also resets the screen blanking counter in the console interrupt routine to prevent screen blanking.[/indent]

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., [b]1 JOYST[/b] . I am trying to use the keyboard emulation of joystick #1 (Q,W,E,R,S,D,Z,X,C).

...lee Edited by Lee Stewart

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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:

[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
;]
[/code]

[CODE]: TEST BEGIN 0 JOYST . AGAIN ;[/CODE]

Share this post


Link to post
Share on other sites
[quote name='Willsy' timestamp='1323474142' post='2421459']
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.
[/quote]

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

...lee

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:[list]
[*]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
[/list]
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:

[code]
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
[/CODE]

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:

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

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]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
[/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

Share this post


Link to post
Share on other sites
[quote name='Willsy' timestamp='1323515819' post='2421730']
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:[list]
[*]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
[/list]
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:

[code]
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
[/CODE]

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:

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

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]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
[/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
[/quote]

Brilliant. Thanks for the how-to Mark.

Share this post


Link to post
Share on other sites
Having problems saving the block after I import the new JOYST definition from a file into a block.

[media]http://www.youtube.com/watch?v=6sN1XtwUGGg[/media] Edited by idflyfish

Share this post


Link to post
Share on other sites
[quote name='idflyfish' timestamp='1323561766' post='2422110']
Having problems saving the block after I import the new JOYST definition from a file into a block.
[/quote]

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 ( [b]51 EDIT[/b] ), "Paste" from the Classic99 "Edit" menu, exit the edit screen (F9) and execute [b]FLUSH[/b] . Now that I think about it, perhaps you should have executed the [b]FLUSH[/b] before the [b]LIST[/b] , 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 [b]HEX [/b]mode just prior to the [b]LOAD[/b] .

...lee

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!! :_(

Share this post


Link to post
Share on other sites
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).

[attachment=227589:TurboForth Words.pdf]

Share this post


Link to post
Share on other sites
[quote name='Willsy' timestamp='1323596639' post='2422368']
[b]...[/b]
Oh when will it ever end!! :_(
[/quote]

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. :P

...lee

Share this post


Link to post
Share on other sites
[quote name='Lee Stewart' timestamp='1323611856' post='2422467']
[quote name='Willsy' timestamp='1323596639' post='2422368']
[b]...[/b]
Oh when will it ever end!! :_(
[/quote]

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. :P

...lee
[/quote]

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

Share this post


Link to post
Share on other sites
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 by idflyfish

Share this post


Link to post
Share on other sites
[quote name='idflyfish' timestamp='1323621537' post='2422530']
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.
[/quote]

You're getting there!

...lee

Share this post


Link to post
Share on other sites
[quote name='Willsy' timestamp='1323597311' post='2422373']
The good news is, after a quick test, DIRTY seems to be working, which implies the fault is in BLK>FILE.
[/quote]

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 [b][font=courier new,courier,monospace]16 TO lc flush-blk[/font][/b] 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)
[font=courier new,courier,monospace]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 [color=#ff0000][b]16 TO lc flush-blk[/b][/color] ;[/font]

[attachment=227619:BLOCKS.zip]

Share this post


Link to post
Share on other sites
Good catch, Mark!

But, I am back to thinking about the [b]BASE[/b] thing. I am beginning to appreciate the [b]BASE-[/b][b]>R[/b] and [b]R->BASE [/b]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

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...