Jump to content
IGNORED

CALL IO (RXB) and Classic99


kl99

Recommended Posts

Hi,

 

If I put this in RXB in Classic99, I would expect it check for Keyboard L Line and Joystick Left Input.

I am interested in Joystick Input in this test case.

 

100 CALL IO(2,16,8,A,B)
110 CALL HPUT(2,1,"   ",2,1,A,4,1,"   ",4,1,B)
120 GOTO 100


I have connected an actual Gamepad to the USB Port and have configured it in Classic99 for Joystick #1.

 

According to Tech Data Manuals, the TMS 9901 has
Address: >0008
CruBit: 4

9901: INT4

Pin: 8

Function: Keyboard L Line, Joystick Left.

 

For me the result is that the Joystick movement and the Button has no impact on A and B values.

They keep showing 226 and 255.

 

So I wonder what am I doing wrong?

Or is it a limitation of the Emulation in Classic99 or a bug in CALL IO?

 

There are so many things to consider:

Alpha Lock Bug, 99/4 vs 99/4A Keyboard, 5 Keyboard Modes, Infrared Analog Joysticks in the System Software and Documentation, Wired Joysticks.

There is a SCAN Routine in GPL and one in Assembler, there are certain locations in Ram that store the XPOS and YPOS from the Joystick.

...

 

Can anyone give me some hints here?

 

 

 

Link to comment
Share on other sites

Yea as far as I can tell CALL JOYST 1 or 2 works fine along with my other new RXB routines that use GPL SCAN.

But as for IO I think Classic99 is just broken, will not see any USB Joystick or gamepad at all.

 

CALL IO works fine on a TI99/4A but the Classic99 emulation for CRU is broken I guess.

 

And YPT and XPT are GPL or assembly area of storage in Scratch Pad RAM.

Here is the RXB (XB) scratch pad address and what they do, (YPOS >8376 and XPOS >8377)

 

***********************************************************
*    Temporary workspaces in EDIT
* PAD   EQU  >8300            TEMPORARY
SP00   EQU  >8300            SPRITE value
PTFBSL EQU  >8300            Ptr to 1st byte in SPEAK list
PHLEN  EQU  >8300            PHrom data LENgth
PAD1   EQU  >8301            TEMPORARY
PHRADD EQU  >8301            PHRom ADDress
ACCUM  EQU  >8302            # OF BYTES ACCUMULATOR (4 BYTE
MNUM   EQU  >8302            Ussually a counter
SP02   EQU  >8302            SPRITE value
PTLBSL EQU  >8302            Ptr to last byte in SPEAK list
VARY   EQU  >8304
SP04   EQU  >8304            SPRITE value
PTEBSL EQU  >8304            Ptr to end byte in SPEAK list
* NOTE: PTEBSL points to the end of the temporary speak lis
*       whereas PTLBSL points to the last byte actually use
*       i.e.    PTFBSL <= PTLBSL <= PTEBSL
VARY2  EQU  >8306            Use in MVDN only
CCPPTR EQU  >8306            OFFSET WITHIN RECORED (1)
*                             or Pointer to current column
SP06   EQU  >8306            SPRITE value
PTFCIS EQU  >8306            Ptr to 1st character in string
PAD8   EQU  >8308
SPSAL  EQU  >8308            Location of sprite attribute l
PTCCIS EQU  >8308            Ptr to current character in st
STADDR EQU  >830A            Start address - usually for co
SPTMP  EQU  >830A            Temporary variable
PTLCIS EQU  >830A            Ptr to last character in strin
PADB   EQU  >830B
BYTES  EQU  >830C            BYTE COUNTER
*                             or String length for GETSTR
PTFCIP EQU  >830C            Ptr to 1st character in phrase
VAR4   EQU  >830E
PTCCIP EQU  >830E            Ptr to current character in ph
TOPSTK EQU  >8310            Top of data stack pointer
VAR5   EQU  >8310            VAR5 through VAR5+3 used in RA
PTLCIP EQU  >8310            Ptr to last character in phras
VAR6   EQU  >8311
PTFBPH EQU  >8312            Ptr to 1st byte in PHrom
VAR7   EQU  >8312            Used in CHARLY
STRPTR EQU  >8312            RXB PATCH CODE
PTCCPH EQU  >8314            Ptr to current byte in PHrom
VAR9   EQU  >8314             Used in CHARLY
XFLAG  EQU  >8316            SCAN FLAG-BITS USED AS BELOW
PTLCPH EQU  >8316            Ptr to last byte in PHrom
FNUM   EQU  >8317            Current file number for search
***********************************************************
*    Permanent workspace variables
SREF   EQU  >831C            Temporary string pointer
VARW   EQU  >8320            Screen address (CURSOR)
ERRCOD EQU  >8322            Return error code from ALC
STVSPT EQU  >8324            Value-stack base
RTNG   EQU  >8326            Return vector from 9900 code
NUDTAB EQU  >8328            Start of NUD table
PGMPTR EQU  >832C            Program text pointer (TOKEN)
EXTRAM EQU  >832E            Line number table pointer
STLN   EQU  >8330            Start of line number table
ENLN   EQU  >8332            End of line number table
DATA   EQU  >8334            Data pointer for READ
LNBUF  EQU  >8336            Line table pointer for READ
SYMTAB EQU  >833E            Symbol table pointer
FREPTR EQU  >8340            Free space pointer
CHAT   EQU  >8342            Current charater/token
PRGFLG EQU  >8344            Program/imperative flag
FLAG   EQU  >8345            General 8-bit flag
BUFLEV EQU  >8346            Crunch-buffer destruction leve
LSUBP  EQU  >8348            Last subprogram block on stack
* FAC  EQU  >834A            Floating-point ACcurmulator
CCHAR  EQU  >834A            Current character
FAC1   EQU  FAC+1
SPLFLG EQU  >834B            SPelL out phrase FLaG
FAC2   EQU  FAC+2
TOTTIM EQU  >834C            TOTal wait TIMe
* NOTE: DATAD must follow immediately after TOTTIM. The
*       routine STDATA is counting on this fact!
FAC3   EQU  FAC+3
DATAAD EQU  >834D            Speech DATA ADdress
FAC4   EQU  FAC+4
CCC    EQU  FAC+4
FFF    EQU  FAC+4
* FAC5   EQU  FAC+5          Was for original RNDX
PTLCIL EQU  >834F            Pointer To Last Character In L
FAC6   EQU  FAC+6
EEE    EQU  FAC+6
FAC7   EQU  FAC+7
TIMLEN EQU  >8351             TIMe LENgth of timing charact
FAC8   EQU  FAC+8
FAC9   EQU  FAC+9
FAC10  EQU  FAC+10
DDD1   EQU  FAC+10
TEMP1  EQU  >8354            TEMPorary CPU location 1
FAC11  EQU  FAC+11
FAC12  EQU  FAC+12
FFF1   EQU  FAC+12
TEMP2  EQU  >8356            TEMPorary CPU location 2
FAC14  EQU  FAC+14
EEE1   EQU  FAC+14
READ   EQU  >8358            Address of speech peripheral
*                             READ byte interface
FAC15  EQU  FAC+15
WRITE  EQU  >835A            Address of speech peripheral
*                             WRITE byte interface
* ARG  EQU  >835C            Floating-point ARGument
ARG1   EQU  >835D
PHDATA EQU  >835D            PHrom DATA
ARG2   EQU  ARG+2
PTCBED EQU  >835E            Ptr To Current Byte Ext Data
ARG4   EQU  ARG+4
LENCST EQU  >8360            LEN of Current ext data STring
ARG6   EQU  ARG+6
LENWST EQU  >8362            LEN of Whole ext data STring
ARG7   EQU  ARG+7
ARG8   EQU  ARG+8
STRLEN EQU  >8364            STRing LENgth
TEMP4  EQU  >8364
TEMP5  EQU  >8366
* NOTE: BYTE1, BYTE2, and BYTE3 must be in consecutive memo
*       locations, and in the following order for SPGET to
*       work!
BYTE1  EQU  >8366            BYTE 1
BYTE2  EQU  >8367            BYTE 2
BYTE3  EQU  >8368            BYTE 3
TEMP6  EQU  >8368
SPKSTS EQU  >8369            SPeaK StaTus
* FPERAD EQU  >836C          Value stack pointer
* VSPTR  EQU  >836E          Value stack pointer
***********************************************************
* MEMSIZ EQU  >8370           MEMORY SIZE
* DATSTK EQU  >8372           DATA STACK
* SUBSTK EQU  >8373           SUBROUTINE STACK
KEYBD  EQU  >8374             KEYBOARD SELCTION
RKEY   EQU  >8375             KEY CODE
JOYY   EQU  >8376             JOYSTICK Y POSITION
JOYX   EQU  >8377             JOYSTICK X POSITION
RANDOM EQU  >8378             RANDOM NUMBER GENERATOR
TIMER  EQU  >8379             TIMING REGISTER
NOMSPR EQU  >837A             NUMBER OF MOVING SPRITES
VDPSTT EQU  >837B             VDP STATUS REGISTER
* STATUS EQU  >837C            GPL STATUS BYTE
ERCODE EQU  >837C             STATUS REGISTER
CB     EQU  >837D             Character Buffer
* YPT    EQU  >837E            Screen Location Col 
* XPT    EQU  >837F            Screen Location Row 
***********************************************************
RAMTOP EQU  >8384            Highest address in ERAM
RAMFRE EQU  >8386            Free pointer in the ERAM
RAMFLG EQU  >8389            ERAM flag
PRTNFN EQU  >83CE            Sound - previous tone finished
***********************************************************

Edited by RXB
Link to comment
Share on other sites

 

18 hours ago, RXB said:

CALL IO works fine on a TI99/4A but the Classic99 emulation for CRU is broken I guess.

If it was broken then no programs reading the keyboard would work.

 

I'm not sure how CALL IO works, but to read the keyboard/joystick, first you load the column decoder at cru bits >12->14 with the column number 0-7 (6 for joystick 1). Then you read one of cru bits 3-10 to get the value of the row/key. Note that the row numbers in the table below are multiplied by 2 because it's showing the values you load into R12 in assembly language.

 

*       Column   0      1    2    3    4    5     6       7
*     Row
*     >0006      =      .    ,    M    N    /    Fire    Fire
*     >0008    Space    L    K    J    H    ;    Left    Left
*     >000A    Enter    O    I    U    Y    P    Right   Right
*     >000C             9    8    7    6    0    Down    Down
*     >000E    Fctn     2    3    4    5    1    Up      Up
*     >0010    Shift    S    D    F    G    A
*     >0012    Ctrl     W    E    R    T    Q
*     >0014             X    C    V    B    Z

 

 
Edited by Asmusr
Link to comment
Share on other sites

Tried the program in different emulators:

 

In Classic99 the values are 226,255 and the first changes to 238 when you access the joystick.

 

In JS99er the values are 226,255 and the first changes to 238 when you access the joystick if you have the option "Map arrow keys to Fctn+SDEX" enabled.

 

In MAME the values are 226,183 and they don't change when you access the joystick.

Edited by Asmusr
  • Like 1
Link to comment
Share on other sites

4 hours ago, Asmusr said:

 

If it was broken then no programs reading the keyboard would work.

 

I'm not sure how CALL IO works, but to read the keyboard/joystick, first you load the column decoder at cru bits 12-14 with the column number 0-7 (6 for joystick 1). Then you read one of cru bits 3-10 to get the value of the row/key. Note that the row numbers in the table below are multiplied by 2 because it's showing the values you load into R12 in assembly language.

 


*       Column   0      1    2    3    4    5     6       7
*     Row
*     >0006      =      .    ,    M    N    /    Fire    Fire
*     >0008    Space    L    K    J    H    ;    Left    Left
*     >000A    Enter    O    I    U    Y    P    Right   Right
*     >000C             9    8    7    6    0    Down    Down
*     >000E    Fctn     2    3    4    5    1    Up      Up
*     >0010    Shift    S    D    F    G    A
*     >0012    Ctrl     W    E    R    T    Q
*     >0014             X    C    V    B    Z

 

 

RXB uses the GPL IO routine built into the ROM 0 and GROM 0 so it should work as I did not change anything, it just plugs in the numbers to GPL IO routine.

Link to comment
Share on other sites

3 hours ago, Asmusr said:

Tried the program in different emulators:

 

In Classic99 the values are 226,255 and the first changes to 238 when you access the joystick.

 

In JS99er the values are 226,255 and the first changes to 238 when you access the joystick if you have the option "Map arrow keys to Fctn+SDEX" enabled.

 

In MAME the values are 226,183 and they don't change when you access the joystick.

That would confirm my suspicions that Classic99 has a issue. 

I ran RXB CALL IO since version 2000 so no changes to it really and now it does not work in Classic99 correctly. 

 

Real Iron I do not currently have to test it,  so we need someone to see if it does the same thing or something different.

Link to comment
Share on other sites

56 minutes ago, RXB said:

That would confirm my suspicions that Classic99 has a issue. 

I ran RXB CALL IO since version 2000 so no changes to it really and now it does not work in Classic99 correctly. 

 

Real Iron I do not currently have to test it,  so we need someone to see if it does the same thing or something different.

I tested this just now on my real TI.

 

The values I get are 224 and 159 - they do not change when the joystick is moved.

Link to comment
Share on other sites

Thanks for the many replies so far.

I thought it is just me being so stupid, but it seems there is a problem. The test program for CALL IO in the RXB Doc seems to work fine.

It is only covering hitting special keyboard keys though.

 

It could also be related that the GPL IO routine was written when there was a 99/4 only, and infrared analog controllers were in the supported list.

As far as I know even the actual real iron of the 99/4a emulates the 99/4 keyboard, so I wonder in which layer of emulation the joystick fails to work.

 

The description of the 9901 interrupt mapping is different for the 99/4 versus the 99/4A, as we know the keyboard was replaced:

Quote

Technical Data for TI Home Computer (1980)

Address CRU bit 9901         Pin Function
0006     3        INT3         9     Clock interrupt, Keyboard ENTER line, Joystick FIRE
0008     4        INT4         8     Keyboard L line, Joystick Left
000A     5        INT5         7     Keyboard P line, Joystick Right
000C     6        INT6         6     Keyboard 0 (zero) line, Joystick Down
000E     7        INT7 (P15)     34     Keyboard SHIFT line, Joystick Up
0010     8        INT8 (P14)     33     Keyboard SPACE line
0012     9        INT9 (P13)     32     Keyboard Q line
0014     10      INT10 (P12) 31     Keyboard 1 line

 

Quote

 

TI-99/4A Console Technical Data, 1049716-2

Address    CRU bit    9901        Pin    Function

0006     3         INT3         9     9901 Internal Timer Interrupt, Keyboard = (equals) line, Joystick FIRE
0008     4         INT4         8     Keyboard SPACE line, Joystick Left
000A     5         INT5         7     Keyboard ENTER line, Joystick Right
000C     6         INT6         6     Keyboard 0 (zero) line, Joystick Down
000E     7         INT7 (P15)     34     Keyboard FCTN line, Joystick Up
0010     8         INT8 (P14)     33     Keyboard SHIFT line
0012     9         INT9 (P13)     32     Keyboard CTRL line
0014     10         INT10 (P12) 31     Keyboard Z line

 

Further the 9901 I/O mapping for the 99/4A features a before unused CRU bit 21 for Alpha Lock, which could be by mistake always checked by a TI-99 Emulator, even on a 99/4 emulated machine.

Quote

 

TI-99/4A Console Technical Data, 1049716-2

9901 I/O mapping

Address    CRU bit    9901    Pin    Function

0024     18         P2         26     Bit 2 of Keyboard Select
0026     19         P3         22     Bit 1 of Keyboard Select
0028     20         P4         21     Bit 0 (MSB) of Keyboard Select
002A     21         P5         20     Keyboard (ALPHA LOCK) [this line shows as unused on the Technical Data manual for the 99/4]

 

Maybe the GPL Programmer's Guide give a clue on how to properly use the GPL IO routine to read the joystick.

Will have to read and try a bit further it seems.

  • Like 1
Link to comment
Share on other sites

Reading the keyboard/joystick using CRU from BASIC might be difficult because the ISR will interfere with your setting of the column decoder.

 

I think you would to do something like this:

 

Set the column decoder to column 6 (joystick 1):

CALL IO(3,3,18,6)

The first 3 means write to CRU. Next is number of bits, the CRU address and finally the value.

 

Read 8 bits from joystick 1 into A:

CALL IO(2,8,3,A)

The first 2 means CRU read. Next is number of bits, the CRU address, and finally the variable to read into.

 

Link to comment
Share on other sites

I actually spent about an hour on the initial question, but I couldn't figure out exactly what I/O was trying to do or why it would necessarily be expected to query the joystick. Without a better understanding of that, it's hard to know what's broken.

 

At the individual bit level, querying CRU /must/ work, otherwise nothing that reads joysticks or keyboard would work. Classic99 doesn't fake those reads. However, when the command executes it's pulling more than just the keyboard return bits (a full 16 bits are being asked for?), and I gave up trying to understand what was going on in hopes Rich would shed some light. :) It /is/ worth noting that Classic99 returns 1 for any unimplemented CRU bit. I think the whole second byte is beyond the keyboard bits, so that's why it's 255 on Classic99. ;)

 

As for 99/4 compatibility - the 99/4 and 99/4A keyboard wiring is completely different - the compatibility with 99/4 programs is done in software. You can't mix and match the CRU maps.

 

Link to comment
Share on other sites

Quote

IO subprogram PAGE I3
-------------------------------------------------------------
Format CALL IO(type,address[,...])
CALL IO(type,bits,cru-base,variable,variable
[,...])
CALL IO(type,length,vdp-address[,...])
Description
The IO subprogram allows access to and control of any chip in
the console or peripheral cards. The type refers to different
access methods like playing sound from GROM or VDP memory
automatically. The type can also specify reading or writing
directly to a Control Register Unit (CRU) address. Thereby
allowing direct chip control, or direct chip bypass if the
user wishes. The IO subprogram is a Graphics Programming
Language (GPL) command. So the function is exactly like GPL
despite being run from the XB environment. As most of XB is
written in GPL the user gains greater GPL like control.
After all the Operating System is written in GPL for a
good reason.*Note these docs are from GPL Manuals.
type address specifications
~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
0 ---------- GROM sound list address.
1 ---------- VDP sound list address.
2 ---------- CRU input.
3 ---------- CRU output.
4 ---------- VDP address of Cassette write list.
5 ---------- VDP address of Cassette read list.
6 ---------- VDP address of Cassette verify list.
The length specifies the number of bytes. The length can be
from -32768 to 32767 depending on the amount of VDP memory
that is available. Of course a value of -32768 is HEX >8000
and 32767 is HEX >7FFF and VDP normally in a TI is only 16384
or HEX >4000 of VDP. So be careful or lock-up will result.
The cru-base is the CRU address divided by 2 in decimal form
as the command automatically doubles the value input. The CRU
-base ranges from 0 to 8191 or HEX >0000 to >1FFF with a EVEN
address for 8 bits or more being scanned. That means that a
value of 8191 will lock-up the system as it is looking for a
bit in 8192 that does not exist.
IO PAGE I4
-------------------------------------------------------------
The variable can input or output values ranging from 0 to 255
as that is equivalent to a single byte value. As there are
two variables 16 bits can be represented in the two 8 bit
variables. If CRU input reads less than 8 bits, the unused
bits in the byte are reset to zero. If CRU input reads less
then 16 but more than 8 bits, the unused bits in the word
will be reset to zero. The bits range from 1 to 16 for input
or output.

 

Link to comment
Share on other sites

In order to clear any differences between the MAME emulation and the real iron, could someone of you with a real console please enter these lines in Extended Basic:

 


CALL INIT

CALL LOAD(12288,4,224,131,196,2,1,27,10,6,1,22,254,4,204,2,1,50,200,52,49,2,44,0,32,52,49,4,91)
CALL LOAD(-31804,48,0)
CALL PEEK(13000,A,B,C,D)
PRINT A;B;C;D

 

and tell me what has been printed.

 

The code is a small assembly code routine to read the first 32 bits of CRU space, store them at address (dec)13000, and the code is started by the interrupt hook (second LOAD line).

  • Thanks 1
Link to comment
Share on other sites

Thanks, Lee. The numbers show that there are only 2 deviations in MAME for the 9901 CRU bits:

 

- Bit 13: The cassette output bit is 1 in MAME but 0 on the real iron. This may be an undefined default.

- Bit 17: P1 delivers 1 in MAME but 0 on the real iron. P1 is not connected. I could not find information in the specs of the TMS9901 what is returned for open inputs.

- Bit 25: mirror of bit 13

 

Maybe someone else could check and approve these numbers, just to make sure.

 

Edit: Note that the bytes are reversed words; therefore the binary representation is  01011111 11101001 00000111 00101111.

Edited by mizapf
  • Like 2
Link to comment
Share on other sites

23 minutes ago, mizapf said:

Thanks, Lee. The numbers show that there are only 2 deviations in MAME for the 9901 CRU bits:

 

- Bit 13: The cassette output bit is 1 in MAME but 0 on the real iron. This may be an undefined default.

- Bit 17: P1 delivers 1 in MAME but 0 on the real iron. P1 is not connected. I could not find information in the specs of the TMS9901 what is returned for open inputs.

- Bit 25: mirror of bit 13

 

Maybe someone else could check and approve these numbers, just to make sure.

 

Edit: Note that the bytes are reversed words; therefore the binary representation is  01011111 11101001 00000111 00101111.

I got the same numbers as Lee:  151, 250, 244, 224

  • Thanks 2
Link to comment
Share on other sites

Ok guys I thought many years ago we would have this flair up.

Finally enough people have been testing RXB to find stuff like this for me explain.

 

So far no errors on my part have turned up so I feel relieved.

 

RXB CALL IO is after all 100% just the GPL version of IO with numbers plugged in from XB as stated in RXB documents from version 2001.

Link to comment
Share on other sites

I tested with Mizapf's program on Classic99 and broke out the results.. most of the different bits are unused or reserved in the console, suggesting my default values are just inverted. But, some of the keyboard pins do come back with unexpected results. The keyboard works, so I'm a bit at a loss to explain that. I'll dig into it more deeply in the future, in the meantime I took a lot of notes. ;)

 

Link to comment
Share on other sites

12 hours ago, Tursi said:

I tested with Mizapf's program on Classic99 and broke out the results.. most of the different bits are unused or reserved in the console, suggesting my default values are just inverted. But, some of the keyboard pins do come back with unexpected results. The keyboard works, so I'm a bit at a loss to explain that. I'll dig into it more deeply in the future, in the meantime I took a lot of notes. ;)

 

Sorry for extra work Tursi and Mizapf emulation is much tougher then what I do.

Link to comment
Share on other sites

On 6/29/2019 at 4:18 AM, Asmusr said:

Reading the keyboard/joystick using CRU from BASIC might be difficult because the ISR will interfere with your setting of the column decoder.

 

I think you would to do something like this:

 

Set the column decoder to column 6 (joystick 1):

CALL IO(3,3,18,6)

The first 3 means write to CRU. Next is number of bits, the CRU address and finally the value.

 

Read 8 bits from joystick 1 into A:

CALL IO(2,8,3,A)

The first 2 means CRU read. Next is number of bits, the CRU address, and finally the variable to read into.

 

From Classic99 I typed this line CALL IO(3,3,18,6) :: CALL IO(2,8,3,A)

I got 255 so does real Iron do the same and return 255 from this line in RXB?

Link to comment
Share on other sites

9 hours ago, RXB said:

From Classic99 I typed this line CALL IO(3,3,18,6) :: CALL IO(2,8,3,A)

I got 255 so does real Iron do the same and return 255 from this line in RXB?

The problem is that XB checked for FCTN-4 and the interrupt routine checks for FCTN-=, both of which will change the keyboard select between those operations (randomly, depending on the exact timing). (Well, I'm not 100% sure when FCTN-4 is checked, but FCTN-= is).

 

For now I think you're probably fine, MAME seems happy, and I need to characterize those bits for my own knowledge.

 

  • Thanks 1
Link to comment
Share on other sites

15 hours ago, Tursi said:

The problem is that XB checked for FCTN-4 and the interrupt routine checks for FCTN-=, both of which will change the keyboard select between those operations (randomly, depending on the exact timing). (Well, I'm not 100% sure when FCTN-4 is checked, but FCTN-= is).

 

For now I think you're probably fine, MAME seems happy, and I need to characterize those bits for my own knowledge.

 

Just now tried this line:

CALL ISROFF(X) :: CALL IO(3,3,18,6,2,8,3,A)

 

Still got A=255 even though Interrupts are turned off.

But maybe only works for Assembly Support and I know it works for that.

Edited by RXB
Link to comment
Share on other sites

I didn't know you could make multiple CRU read/write in one command. Then you don't need to turn off the ISR

 

Try to run this while moving the joystick/pressing the cursor keys:

 

10 CALL IO(3,3,18,6,2,8,3,A)

20 PRINT A

30 GOTO 10

 

It seems to be working OK. Note that the bits in the result are supposed to be reversed.

 

  • Like 1
Link to comment
Share on other sites

19 hours ago, Asmusr said:

I didn't know you could make multiple CRU read/write in one command. Then you don't need to turn off the ISR

 

Try to run this while moving the joystick/pressing the cursor keys:

 

10 CALL IO(3,3,18,6,2,8,3,A)

20 PRINT A

30 GOTO 10

 

It seems to be working OK. Note that the bits in the result are supposed to be reversed.

 

Cool RXB 2015 in Classic99 returned 239 from Joystick Left.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...