Joystick reading code

After ripping some code from a Devpac2 programming tutorial by Bullfrog, printed in Amiga Format at the end of '92/beginning of '93 and studying it I have some questions.
Mind you: i'm just starting out to understand 68k assembly on the Amiga.

Here's the code:

; Translate joystick into delta values

_dx_joy     ds.w    1                       ; delta x value
                                            ; -1 for move LEFT,
                                            ;  1 for move RIGHT,
_dy_joy     ds.w    1                       ; delta y value
                                            ; -1 for move UP,
                                            ;  1 for move DOWN 
_fire1      ds.w    1                       ; firebutton 1 value
                                            ; 0 = not pressed
                                            ; 1 = pressed
_fire2      ds.w    1                       ; firebutton 2 value
                                            ; 0 = not pressed
                                            ; 1 = pressed

_joy_tableX
   dc.w 0, 0, 1, 1, 0, 0, 0, 1,-1, 0, 0, 0,-1,-1
_joy_tableY
   dc.w 0, 1, 1, 0,-1, 0, 0,-1,-1, 0, 0, 0, 0, 1


joystick_test:
    move.l  d0,-(sp)                        ; save d0 to stack

    move.w  $dff00c,d0                      ; put JOY1DAT value into d0
                                            ; Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 = HI byte
                                            ; X7 X6 X5 X4 X3 X2 X1 X0 = LO byte
    and.w   #$0303,d0                       ;  0  0  0  0  0  0  1  1
                                            ; only work with Y1, Y0, X1, X0
                                            ; so clear bits Y7-Y2, X7-X2
    bclr    #8,d0                           ; clear Y0
    beq.s   .zero1                          ; if Y0 = 0 goto .zero1 ???
        bset    #2,d0                       ; set X2 to 1 ???
.zero1:
    bclr    #9,d0                           ; clear Y1
    beq.s   .zero2                          ; if Y1 = 0 goto .zero2 ???
        bset    #3,d0                       ; set X3 to 1 ???
.zero2:
    add.w   d0,d0                           ; multiple d0 by 2
    move.w  _joy_tableX(PC,d0.w),_dx_joy    ; lookup and set _dx_joy
    move.w  _joy_tableY(PC,d0.w),_dy_joy    ; lookup and set _dy_joy

.fire1_test:
    btst.b  #7,$bfe0ff                      ; check if firebutton 1 is pressed
    bne.s   .no_fire1                       ; not pressed
       add.w    #1,_fire1                   ; pressed !
       bra.s    .fire2_test
.no_fire1:
    move.w  #0,_fire1

.fire2_test:
    move.w  #$c000,$dff034                  ; set POTGO to correct status
    move.w  $dff016,d0                      ; put POTINP value into d0
    btst.l  #14,d0                          ; check DATRY in POTINP
    bne.s   .no_fire2                       ; not pressed
        add.w   #1,_fire2                   ; pressed !
        bra.s   .fire2_done
.no_fire2:
    move.w  #0,_fire2
.fire2_done:
    move.w  #$000,$dff034                   ; set POTGO to correct status
    cmp.w   #255,_fire1                     ; check if fire1 is released ?
    blt.s   .end
        move.w  #255,_fire1
.end

    move.l  (sp)+,d0                        ; restore previous value of d0

As you can see I put in a lot of comments in trying to understand what the code is doing, but some parts are a bit 'magical'

    bclr    #8,d0                           ; clear Y0
    beq.s   .zero1                          ; if Y0 = 0 goto .zero1 ???
        bset    #2,d0                       ; set X2 to 1 ???
.zero1:

- After clearing bit 8 (Y0) of the JOY1DAT register it checks if the result is 0; is this result the value in bit 8 of JOY1DAT or the result of the clearing command (if it went ok or not) ?
- Will this code ever reach the bset #2,d0 ? And why set bit 2 (X2) at all if only Y1,Y0,X1 and X0 are important?

    add.w   d0,d0                           ; multiple d0 by 2

- Why multiply d0 and use add.w? And is a lsl.w #1,d0 not faster?

    move.w  _joy_tableX(PC,d0.w),_dx_joy    ; lookup and set _dx_joy
    move.w  _joy_tableY(PC,d0.w),_dy_joy    ; lookup and set _dy_joy

- This part is the real magical part; how does this work at all? What does the PC (Program Counter?) do here ?

    btst.b  #7,$bfe0ff                      ; check if firebutton 1 is pressed

- Why test bit 7 of $bfe0ff and not $BFE001 ?

    cmp.w   #255,_fire1                     ; check if fire1 is released ?
    blt.s   .end
        move.w  #255,_fire1

- Why check _fire1 for value #255, when it's can only be 0 or 1?
Is this a 'rogue' value? Or does it indeed mean the fire1 button was released?

- Isn't this whole piece of code a bit overengineered/overkill?
Can it be done much simpler?

[Leffmann]

Originally Posted by borchen

- Isn't this whole piece of code a bit overengineered/overkill?
Can it be done much simpler?

It does look a bit over-engineered. This one returns the state of the buttons in bits 8 and 9, and the lower byte holds the direction of the stick:

ciaa_pra  = $bfe001
joy1dat   = $dff00c
potgor    = $dff016
bit_joyb1 = 7
bit_joyb2 = 14

ReadJoystick   btst     #bit_joyb2 & 7, potgor
               seq      d0
               add.w    d0, d0

               btst     #bit_joyb1, ciaa_pra
               seq      d0
               add.w    d0, d0

               move.w   joy1dat, d1
               ror.b    #2, d1
               lsr.w    #6, d1
               and.w    #%1111, d1
               move.b   (.conv, pc, d1.w), d0
               rts

.conv          dc.b      0, 5, 4, 3, 1, 0, 3, 2, 8, 7, 0, 1, 7, 6, 5, 0

[Toni Wilen]

Originally Posted by borchen

- Why test bit 7 of $bfe0ff and not $BFE001 ?

For some reason original "official" CIA addresses changed from $BFExFF and $BFDxFE to $BFEx00 and $BFDx01 (Both "old" and "new" map to same registers, CIA address bits 1 to 11 are no-care).

(or it is a typo. But CIA addresses did change, for example very first HRM CIA chapter has "old" addresses)

Wow...talk about fast response...great!

@Leffman (with double n)
Thanks for the code, it's certainly a lot shorter, but i'm just trying to understand what the Bullfrog code does.

I see you also use "add.w d0,d0"; is this line neccesary to move/shift some bits to the left? If yes; is add.w faster than lsl.w #1,d0 ?

@Toni (with single n)
$bfe0ff is not a typo, because the complete program, of which the joystick code is just a small part, compiles/assembles&runs fine. A lot of the code in the tutorial is from a 'framework' Bullfrog used for several games, so some parts could be very old indeed.

B.T.W. I think I know what

    bclr    #8,d0                          ; clear Y0     
    beq.s   .zero1                         ; if Y0 = 0 goto .zero1 ???         
    bset    #2,d0                          ; set X2 to 1 ???
.zero1:

does: apparently bclr not only clears bit 8 of d0, but first tests if it needs to be cleared at all.
If bit 8 already was 0, the code jumps to .zero1, else bit 2 is set to 1 in d0.
Pfff...what a lot of text for this short piece of code.

[Mrs Beanbag]

Originally Posted by borchen

apparently bclr not only clears bit 8 of d0, but first tests if it needs to be cleared at all.

i just checked the 68k programmers manual and it's true. i did not know that.

it's a shame "clr" doesn't work as a "tst" as well, that could have come in useful

[matthey]

Originally Posted by borchen

    add.w   d0,d0                           ; multiple d0 by 2

- Why multiply d0 and use add.w? And is a lsl.w #1,d0 not faster?

In general, add is faster than shift which is faster than multiply. It's true of the 68000-68040 anyway.

Originally Posted by borchen

    move.w  _joy_tableX(PC,d0.w),_dx_joy    ; lookup and set _dx_joy
    move.w  _joy_tableY(PC,d0.w),_dy_joy    ; lookup and set _dy_joy

- This part is the real magical part; how does this work at all? What does the PC (Program Counter?) do here ?

The PC is the address of the currently executing instruction. The MOVE.W adds up all the effective address (EA) values and gets the address they are pointing to.

   move.w  _joy_tableX(PC,d0.w),_dx_joy
   move.w  (_joy_tableX,PC,d0.w),_dx_joy ; new style (68020+) syntax
   move.w  (_joy_tableX+PC+d0.w),_dx_joy ; not accepted by assemblers

_joy_tableX+PC is the offset to the _joy_tableX label the programmer created. The value in d0 is added to it to choose which word from the beginning (label) is copied to the absolute address at _dx_joy. The code is rather obfuscating for an early learning example.

Originally Posted by borchen

    btst.b  #7,$bfe0ff                      ; check if firebutton 1 is pressed

- Why test bit 7 of $bfe0ff and not $BFE001 ?

I'm not a hardware banging guru so I'll leave your question to others. I just wanted to point out that bit 7 is the sign bit of a byte. That means this code could be:

    tst.b  $bfe0ff                      ; check if firebutton 1 is pressed
    bmi.s .nofire1

The condition codes (CCR) are set different for TST.B so BMI (branch minus) is taken if the byte at the absolute address is negative. This saves 2 bytes of code and may be faster on some 68k processors.

Originally Posted by borchen

does: apparently bclr not only clears bit 8 of d0, but first tests if it needs to be cleared at all. If bit 8 already was 0, the code jumps to .zero1, else bit 2 is set to 1 in d0.

BCLR tests the bit before changing it. Most 68k instructions set the condition codes (CC) to reflect the data after the operation instead of before. Yes, it's sometimes useful to know what that bit was before changing it rather than after. BCLR is not avoiding clearing the bit if it's already zero.

[phx]

Originally Posted by Leffmann

               move.w   joy1dat, d1
               ror.b    #2, d1
               lsr.w    #6, d1
               and.w    #%1111, d1
               move.b   (.conv, pc, d1.w), d0
               rts

I never bothered to optimize my joystick code, but this looks like a real improvement, cycle-wise. I might switch to it when it proves working.

.conv          dc.b      0, 5, 4, 3, 1, 0, 3, 2, 8, 7, 0, 1, 7, 6, 5, 0

I assume that direction 0 is north, 2 is east and 7 is north-west?
But what about 8??

[robinsonb5]

Originally Posted by borchen

This part is the real magical part; how does this work at all? What does the PC (Program Counter?) do here ?

It encodes the address of the lookup table relative to the program counter, resulting in position-independent code, which will work no matter where in memory it's located. If the code referenced the table by its absolute address, then the load address for the routine would have to be known at compile-time, or such absolute references would have to be adjusted after loading the code.

    cmp.w   #255,_fire1                     ; check if fire1 is released ?
    blt.s   .end
        move.w  #255,_fire1

- Why check _fire1 for value #255, when it's can only be 0 or 1?
Is this a 'rogue' value? Or does it indeed mean the fire1 button was released?

I think it's couinting how long the fire button's been held down, with a maximum value of 255, to allowing things like the firepower-charging from R-Type when the fire button's held?

[Leffmann]

Originally Posted by borchen

B.T.W. I think I know what

    bclr    #8,d0                          ; clear Y0     
    beq.s   .zero1                         ; if Y0 = 0 goto .zero1 ???         
    bset    #2,d0                          ; set X2 to 1 ???
.zero1:

does: apparently bclr not only clears bit 8 of d0, but first tests if it needs to be cleared at all.
If bit 8 already was 0, the code jumps to .zero1, else bit 2 is set to 1 in d0.
Pfff...what a lot of text for this short piece of code.

What it does is effectively move bits 9 and 8 to bits 3 and 2, to get all 4 input bits in sequence for the lookup-table, just like I do with the simpler ROR+LSR sequence.

Originally Posted by phx

I assume that direction 0 is north, 2 is east and 7 is north-west?
But what about 8??

1 is north, 2 is north-east, and so on clockwise around the dial. 0 means centered. I think this table is more correct, which sets all illegal values to 0:

0, 5, 4, 3, 1, 0, 0, 2, 8, 0, 0, 0, 7, 6, 0, 0

I think two lookup-tables for X-direction and Y-direction may be more handy actually.

Thanks for the responses, it's much appreciated.

@matthey

_joy_tableX+PC is the offset to the _joy_tableX label the programmer created. The value in d0 is added to it to choose which word from the beginning (label) is copied to the absolute address at _dx_joy.

So if the move.w command is at, lets say, address $1000 and _joy_tableX at $1500, _joy_tableX+PC would be $500?
I already understood that d0 is basically an index into _joy_tableX.

The condition codes (CCR) are set different for TST.B so BMI (branch minus) is taken if the byte at the absolute address is negative. This saves 2 bytes of code and may be faster on some 68k processors.

I'm afraid I lost you there, but one day i might understand that.

@robinsonb5

I think it's couinting how long the fire button's been held down, with a maximum value of 255,

I just realised the line "add.w #1,_fire1 ; pressed !" contains an add-command..., so you're probably right about the holding of the firebutton.
Strangely the following code:

    cmp.w   #255,_fire2
    blt.s   .end
        move.w  #255,_fire2

was not present in the original code. Maybe Bullfrog never expect Amiga gamers to hold on to their second firebutton...

@all
If someone is interested in the complete tutorial I could upload a directory with all the code, which you can easily use as HD in Winuae, to the Zone. You'll have to lookup the right pages in AmigaFormat yourself on this website http://amr.abime.net/issues_4 The tutorial runs from October '92 to Februari '93.

[matthey]

Originally Posted by borchen

So if the move.w command is at, lets say, address $1000 and _joy_tableX at $1500, _joy_tableX+PC would be $500?
I already understood that d0 is basically an index into _joy_tableX.

You got it. In the example joystick code, the offset would be negative which works fine also. Some 68k instructions are implicitly PC relative like BRA and Bcc instructions. Using "JMP label" will be turned into "JMP $xxx" (using absolute addressing) but using "BRA label" just stores the offset from the current location and becomes like "JMP (label,PC)" but smaller and faster.

Originally Posted by borchen

I'm afraid I lost you there, but one day i might understand that.

You may need to read up on how the CCR, condition codes and branches work. You should probably know about two's complement binary numbers which is how negative numbers are stored on most modern computers including the 68k.

http://en.wikipedia.org/wiki/Two%27s_complement

The most significant bit of a two's complement signed number gives the sign of the number (0=pos 1=neg). The most significant bit of a byte is bit #7 using Motorola's bit counting system (least to most significant). A test of a byte sets the CCR[N] flag if bit #7 is negative (or minus). BMI (branch minus) branches if the CCR[N] bit is set because the tested byte is negative. It's not quite as simple as BTST but a trained eye will spot bit #7, bit #15 and bit #31 knowing that they are sign bits to a byte, word and longword .

There are some other optimizations that could be made by the way. Instructions like MOVE.W #0,EA could be CLR.W EA and ADD.W #1,EA could be ADDQ.W #1,EA. I didn't mention them because an optimizing assembler will usually take care of them and that is how some programmers prefer to write code (although the MOVE #0,EA->CLR EA may be disabled for the 68000 because of a bug that could cause problems with hardware registers).

@matthey

Thanks a lot for your explanation of the relative addressing.

I realise that I still have a lot to learn. My way of learning assembly is to just take/rip/steal a piece of code and start explaining it to myself using info from the web and then comment almost every line of code.

B.T.W. I got a great intro into Amiga assembly by watching the following tutorial on youtube: [ Show youtube player ]

In the late 80's I did have an assembler for my A500, but no clue whatsoever to do with it, due to a lack of access to information. All the people that I knew with an Amiga mostly played games, painted with Deluxepaint or were using Soundtracker, although one was using Wordperfect, because at that moment in time it was superior to the PC version.

[matthey]

Originally Posted by borchen

Thanks a lot for your explanation of the relative addressing.

There are several areas that need to be learned to understand assembly language.

1) CPU design and data types
2) ISA, ABI+API (OS), hardware register maps (hw banging)
3) assembler, linker, editor, debugger usage

Many programmers already know #1 when they start which is a big help. Much of this information can be found online as it's mostly generic and widespread in usage but it's important to know.

From above, #2 is the syntax, instructions and usage of #1 and is specific to a particular hardware and software (68k and Amiga in this case). The ISA (Instruction Set Architecture) is described in the 68000PRM originally from Motorola (now Freescale).

http://cache.freescale.com/files/arc...n&fileExt=.pdf

It's in this documentation that the addressing modes are explained like PC relative addressing. There are also user manuals for each CPU which give more specific information including timings but these manuals are for experienced programmers who understand the ISA, CPU design and datatypes. The 68k ABI (Application Binary Interface) is SysV.4 but not well published. I don't have any documentation besides the manuals of compilers and assemblers. It describes how parameters are passed in functions (stack) and how they are returned (D0), which registers are scratch (D0,D1,A0,A1), use A7=stack etc. Amiga functions pass values in registers defined in their own API (Application Programming Interface) but do scratch the same registers and return values in D0 while needing other details as described in the HKRM reference manuals of which there are 4 or 5. The HKRM Hardware reference manual describes the hardware registers and how they can be used while the others describe the AmigaOS APIs. They are out of print but can be found online.

From above, #3 is in the documentation for each developer tool used. They are usually technical as knowledge from #1 and #2 are needed but the best manuals will explain some aspects of them and give examples.

Originally Posted by borchen

I realise that I still have a lot to learn. My way of learning assembly is to just take/rip/steal a piece of code and start explaining it to myself using info from the web and then comment almost every line of code.

That's a good way to learn. You can use a debugger to watch what programs are doing to see if what changes in the debugger output is what you expect. You can either use a built in debugger from Asm-one or Devpac or a separate one. BDebug is a powerful debugger in the Barfly assembler package which shows more info than many other debuggers when each instruction executes by stepping.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

There is a learning curve to a debugger but it's worth learning early as a lot can be learned by simply stepping through programs. Amiga hardware/register hitting programs are generally not good candidates for debugging though. It's better to step through a simple string function, sort, or number converter for example.

Originally Posted by borchen

B.T.W. I got a great intro into Amiga assembly by watching the following tutorial on youtube: [ Show youtube player ]

That tutorial jumps right in. Hardware hitting programs can be fun because they don't take very much code to see results. It also gives a broad overview but a lot of basics are skipped over that should be learned to become a good assembler programmer.

Originally Posted by borchen

In the late 80's I did have an assembler for my A500, but no clue whatsoever to do with it, due to a lack of access to information. All the people that I knew with an Amiga mostly played games, painted with Deluxepaint or were using Soundtracker, although one was using Wordperfect, because at that moment in time it was superior to the PC version.

It's much easier now. Most of the documentation is online and many of the developer tools are free. The Amiga and the 68k are simple to get started and easy to learn. The knowledge scales up to modern computer systems but usually with the realization that they are too complex and not as fun .

[Thorham]

Originally Posted by matthey

Debug is a powerful debugger in the Barfly assembler package which shows more info than many other debuggers when each instruction executes by stepping.

http://aminet.net/dev/asm/BarflyDisk2_00.lha

Perhaps AsmOne/AsmPro is easier for a beginner. Barfly is nice, and I use it as my main assembler and debugger, but it's not very beginner friendly.

[matthey]

Originally Posted by Thorham

Perhaps AsmOne/AsmPro is easier for a beginner. Barfly is nice, and I use it as my main assembler and debugger, but it's not very beginner friendly.

Maybe. It would be easier to follow what was being used in tutorials. Personally, I think DevPac has a better integrated environment. The best development pieces are probably not part of an integrated environment though. I use:

assembler: vasm
linker: vlink
editor: CED with AREXX
debugger: BDebug (from Barfly package)

I wouldn't be able to use vasm on a low spec Amiga. It's not the easiest setup to start with but I doubt any integrated environment can match it.

[Thorham]

Originally Posted by matthey

I wouldn't be able to use vasm on a low spec Amiga. It's not the easiest setup to start with but I doubt any integrated environment can match it.

That's why I use Barfly with FrexxEd and a self written real time memory viewer. Much more powerful than those integrated environments, but not so nice for beginners. Beginners should really stick with AsmOne, AsmPro or DevPac.

[Photon]

I'm a bit late to the thread, so sorry if some of this has already been answered.

Originally Posted by borchen

- Isn't this whole piece of code a bit overengineered/overkill?
Can it be done much simpler?

Yes and yes, Leffman has already shown a neat routine.

Originally Posted by Mrs Beanbag

i just checked the 68k programmers manual and it's true. i did not know that.

it's a shame "clr" doesn't work as a "tst" as well, that could have come in useful

It might. Answering borchen: the confusing (if you don't read the Motorola manual) bclr works exactly that way: It's an instruction to poll signal bits. It tests the bit value (settings the condition code flags), then clears it. bset has the same property.

Originally Posted by Toni Wilen

For some reason original "official" CIA addresses changed from $BFExFF and $BFDxFE to $BFEx00 and $BFDx01

Old addresses are weird. New addresses are in all books but one edition of one book

I put useful snippets on coppershade.org: here is an old snippet, #ChkJoy, that I used in my as yet unreleased collection of not-quite-finished games that reads both joysticks and gives the values in a useful form.

@Photon
You're probably Photon "Hello amiga coders" from Scoopex?

...the confusing (if you don't read the Motorola manual) bclr works exactly that way...

I actually use that manual already (I do, in general, RTFM) and discovered what bclr does.

I also consult this site http://mrjester.hapisan.com/04_MC68/ alot, because this guy explains stuff clearly with a lot of examples, although his explanation of the bclr did not mention the bit-testing part of this command...bummer

Old addresses are weird. New addresses are in all books but one edition of one book

This only means the joystick-reading-code of Bullfrog was really old, maybe not even developed by them, but by someone that had this legendary/mythical "one edition of one book". (This someone probably also had the original copy of the bible)

B.T.W. the skeleton of my code I took from your Amiga Hardware Programming tutorial on Youtube. I inserted this joystick reading code into it.

@matthey
Thanks for the tip about Barfly, but I'll stick with ASMone for now.
When I followed the tutorial of Bullfrog I used the Devpac installation that came with it. I do not feel like switching to yet another development-tool.

Hardware hitting programs can be fun because they don't take very much code to see results

That's exactly why I'm fooling around with assembly on the Amiga; I made enough string,sorting and conversion code already (in basic, C, Java etc).
Now I want to discover why the Amiga was so great in the late 80's.

@Thorham
Dus ik ben niet de enige computer-nerd, die zit te pielen met 68k assembly voor de Amiga.
Google translation: "So I 'm not the only computer nerd, who sits fiddle with 68k assembly for the Amiga."
"...sits fiddle..."

@all
When I use

move.w  _joy_tableX(PC,d0.w),_dx_joy    ; lookup and set _dx_joy

I get the following error: ** Out of Range 8 bit
Probably because the table _joy_tableX is too far away from the move.w command.
So I replaced this line with:

lea _joy_tableX,a0
move.w (a0,d0),_dx_joy

and this works (after some trial and error) like a charm!

I still have one question about the index-value d0:
Right before the lookup-code I write this value into a variable called _joyIndex to check it's value and apparently d0 has the following values:
$0018 for LEFT,
$0006 for RIGHT,
$0008 for UP and
$0002 for DOWN.

_joy_tableX: 0, 0, 1, 1, 0, 0, 0, 1,-1, 0, 0, 0,-1,-1
_joy_tableY: 0, 1, 1, 0,-1, 0, 0,-1,-1, 0, 0, 0, 0, 1

How can it find the value -1 for _dx_joy with index-value $0018 ? Which -1 does it find, because there are only 14 entries in the table. Or must $0018 be divided by 2, because the 9th entry in the table is -1?

B.T.W. I use this http://www.sinchai.de/index.php?main...11b4f2e614eb9c interface in combination with my (t)rusty old Wico http://www.ntrautanen.fi/computers/o...mages/wico.jpg ,which is probably even older than the joystick-reading-code from Bullfrog, because I already used this joystick with my CPC464.

[Thorham]

Originally Posted by borchen

Dus ik ben niet de enige computer-nerd, die zit te pielen met 68k assembly voor de Amiga.
Google translation: "So I 'm not the only computer nerd, who sits fiddle with 68k assembly for the Amiga."
"...sits fiddle..."

Nee, dat ben je zeer zeker niet.

Google translation: No, you are most certainly not.

[robinsonb5]

Originally Posted by borchen

How can it find the value -1 for _dx_joy with index-value $0018 ? Which -1 does it find, because there are only 14 entries in the table. Or must $0018 be divided by 2, because the 9th entry in the table is -1?

The offset is the number of bytes that will be added to the address, but the table is declared as 16-bit words using dc.w, so each entry is two bytes in size. $18 is 24 in decimal, so you'll get the 12th entry in the table (or rather, the 12th entry after the first one, since the first one has an offset of zero!)
(If you wanted to declare a table with single-byte entries, you'd use dc.b, and dc.l if you wanted longword entries.)