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).
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
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.
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
;]
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?
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.
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:
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:
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...
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
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:
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:
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...
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
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 .
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.
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...
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).
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.
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.
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.
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.
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.
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.
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 ;
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!
0
.
All is not well.
