kl99 Posted June 27, 2019 Share Posted June 27, 2019 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? Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2019 Share Posted June 28, 2019 (edited) 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 June 28, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 28, 2019 Share Posted June 28, 2019 (edited) 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 June 29, 2019 by Asmusr Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 28, 2019 Share Posted June 28, 2019 As Rasmus just said (I was preparing my answer in parallel), here is the matrix. You have to set the CRU lines P2-P4 first and then check the input on CRU bit 4. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 28, 2019 Share Posted June 28, 2019 (edited) 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 June 28, 2019 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2019 Share Posted June 28, 2019 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2019 Share Posted June 28, 2019 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. Quote Link to comment Share on other sites More sharing options...
Casey Posted June 29, 2019 Share Posted June 29, 2019 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted June 29, 2019 Author Share Posted June 29, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 29, 2019 Share Posted June 29, 2019 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 29, 2019 Share Posted June 29, 2019 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 29, 2019 Share Posted June 29, 2019 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 30, 2019 Share Posted June 30, 2019 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). 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 30, 2019 Share Posted June 30, 2019 @mizapf, I get 151 250 244 224 ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 30, 2019 Share Posted June 30, 2019 (edited) 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 June 30, 2019 by mizapf 2 Quote Link to comment Share on other sites More sharing options...
Casey Posted June 30, 2019 Share Posted June 30, 2019 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 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 1, 2019 Share Posted July 1, 2019 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 2, 2019 Share Posted July 2, 2019 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 2, 2019 Share Posted July 2, 2019 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 2, 2019 Share Posted July 2, 2019 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? Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 3, 2019 Share Posted July 3, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 3, 2019 Share Posted July 3, 2019 (edited) 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 July 3, 2019 by RXB Quote Link to comment Share on other sites More sharing options...
Asmusr Posted July 3, 2019 Share Posted July 3, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 4, 2019 Share Posted July 4, 2019 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.