Airshack Posted July 11, 2017 Share Posted July 11, 2017 (edited) ... it has comments from the original TI programmers for the same code. ...lee Wondering if any original TI Programmers are lurking about on AtariAge, or anywhere else? Just finished listening to a four part interview with Chuck Peddle the inventor of the 6502 CPU and Commodore PET. http://retrobits.libsyn.com/show-123-an-interview-with-chuck-peddle-part-i Wondering if any of our guys are still around and talking? Edited July 11, 2017 by Airshack Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 11, 2017 Share Posted July 11, 2017 (edited) edited link above Edited July 11, 2017 by Airshack Quote Link to comment Share on other sites More sharing options...
x24b Posted July 11, 2017 Share Posted July 11, 2017 Is there a video history of our beloved TI 99/4A? There are many youtube histories on every type of British computer, from the Speccy to Acorn Atom. Newbury New Brain, BBC micro, and Amstrad. They even show the C 64 from a British perspective and how that affected our machine here. I'd like to know more about the people that created it and their stories. 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 11, 2017 Share Posted July 11, 2017 To my knowledge, none of the designers of the 4 or the 4A have had any interaction with the "outside world" with the exceptions of (if my memory isn't faulty) Don Bynum, though he vanished decades ago, and didn't get involved much, and Mr. Bunyard (can't remember his first name). To my knowledge, we don't know who wrote the GPL interpreter, or any of the other system software. There are some names given in the Editor Assembler manual that could possibly turn up some interesting leads. These people could conceivably be in their 70s now. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted July 11, 2017 Share Posted July 11, 2017 That would be Michael L Bunyard, I presume. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 11, 2017 Share Posted July 11, 2017 To my knowledge, none of the designers of the 4 or the 4A have had any interaction with the "outside world" with the exceptions of (if my memory isn't faulty) Don Bynum, though he vanished decades ago, and didn't get involved much, and Mr. Bunyard (can't remember his first name). To my knowledge, we don't know who wrote the GPL interpreter, or any of the other system software. There are some names given in the Editor Assembler manual that could possibly turn up some interesting leads. These people could conceivably be in their 70s now. True in the GPL Source of XB some names are mentioned like Mike and Ted but other then that no full names are given. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 12, 2017 Share Posted July 12, 2017 The TI Forth manual credits the authors of the system. If they could be tracked down, perhaps they know the whereabouts of others who worked on the TI-99. (?) (only six degrees of separation for the whole planet) Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 (edited) As I go through Matthew's viewport code example I'm having a problem understanding his polling of joystick-1 technique: * Test the Joystick** First Test if moved Left LI R12,>0006 * base CRU address for joystick 1 TB 1 * Left JEQ PLY02 * Jump to test for Joystick 1 moved right < process a move left then return>PLY02 * Test if Moved rightFrom what I see in the E/A manual that 'JEQ PLY02' line should read 'JNE PLY02' since moving Joystick1 to the left would set the CRU line, and the following 'TB 1' should set the Statue Register EQ bit. So, the status (EQ) bit should be set after moving the joystick left. Then the following 'JEQ PLY02' should jump past the code where you process moving left ??? I've run and played with the viewport code which works flawlessly. I guess I'm missing something obvious here? Edited July 14, 2017 by Airshack Quote Link to comment Share on other sites More sharing options...
Stuart Posted July 14, 2017 Share Posted July 14, 2017 As I go through Matthew's viewport code example I'm having a problem understanding his polling of joystick-1 technique: * Test the Joystick** First Test if moved Left LI R12,>0006 * base CRU address for joystick 1 TB 1 * Left JEQ PLY02 * Jump to test for Joystick 1 moved right < process a move left then return>PLY02 * Test if Moved rightFrom what I see in the E/A manual that 'JEQ PLY02' line should read 'JNE PLY02' since moving Joystick1 to the left would set the CRU line, and the following 'TB 1' should set the Statue Register EQ bit. So, the status (EQ) bit should be set after moving the joystick left. Then the following 'JEQ PLY02' should jump past the code where you process moving left ??? I've run and played with the viewport code which works flawlessly. I guess I'm missing something obvious here? I suspect that moving the joystick to the left is pulling the left line low (you're making a contact in the joystick to connect 'left' to 0V), so the CRU line is *not* set (but the right/up/down lines *are* set). 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 14, 2017 Share Posted July 14, 2017 As I go through Matthew's viewport code example I'm having a problem understanding his polling of joystick-1 technique: * Test the Joystick** First Test if moved Left LI R12,>0006 * base CRU address for joystick 1 TB 1 * Left JEQ PLY02 * Jump to test for Joystick 1 moved right < process a move left then return>PLY02 * Test if Moved rightFrom what I see in the E/A manual that 'JEQ PLY02' line should read 'JNE PLY02' since moving Joystick1 to the left would set the CRU line, and the following 'TB 1' should set the Statue Register EQ bit. So, the status (EQ) bit should be set after moving the joystick left. Then the following 'JEQ PLY02' should jump past the code where you process moving left ??? I've run and played with the viewport code which works flawlessly. I guess I'm missing something obvious here? You'll probably find that the joystick lines are tied high, and when a contact is made, they are pulled low. 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 14, 2017 Share Posted July 14, 2017 I suspect that moving the joystick to the left is pulling the left line low (you're making a contact in the joystick to connect 'left' to 0V), so the CRU line is *not* set (but the right/up/down lines *are* set). ^^^^^^^ what Stu said 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 I clearly didn't consider this arrangement! Well hell! That's just what I needed with my morning coffee. Thanks guys! 1 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 14, 2017 Author Share Posted July 14, 2017 You will find that when dealing with real I/O signals, quite often the inputs are active low. That is because pulling the I/O high uses less current for signals that spend most of their time inactive (like keyboard and joystick inputs). This is similar to the "chip enable" discussion we had some weeks ago. "Active low" is very common in computers in general. 2 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 You will find that when dealing with real I/O signals, quite often the inputs are active low. That is because pulling the I/O high uses less current for signals that spend most of their time inactive (like keyboard and joystick inputs). This is similar to the "chip enable" discussion we had some weeks ago. "Active low" is very common in computers in general. Interesting. There seems to be an endless amount of learning available via this ancient little system. I get caught up with it all until something mysterious pops-up in my way, a barrier I cannot see beyond. You all have been very helpful in circumventing these barricades to progress. Matthew, I've almost completed dissecting your viewport code. This time I noted minimal comments and less discussion as to how it all works. This has lead to a better opportunity for me to learn. Along with Assembly coding, I'm learning some very valuable graphics presentation techniques, discovering many clever details... I may have even discovered a small unnecessary code segment?! Probably, I'm wrong...but maybe not. More on that in the debrief/lessons learned post to follow. This challenge is more enjoyable than I ever anticipated. -james Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 Where does one look for more technical data on manually polling joysticks and the keyboard? E/A manual is all about KSTAT which seems cumbersome compared to Matt's viewport example. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 14, 2017 Author Share Posted July 14, 2017 Bring it on, I'm all for being shown better or more efficient ways to do something. If you found unnecessary code in my programs, it will be great to have you call it out. As for more info on the joysticks, you can look at the schematics to see how they are actually implemented in the computer. Also, the 9901 datasheet, since IIRC the keyboard and joysticks go through the 9901. In addition, if you have not read Thierry Nouspikel's TI Tech Pages, this is required reading for assembly language programmers: http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm Note, when you post code lately it is always on a single line. I'm wondering why? Are you wrapping the code in [ code ] tags properly? 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 I'm using TapATalk a lot so maybe that's it? I know what you mean, it's ugly. Noted. Never more on the single line look. Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 14, 2017 Share Posted July 14, 2017 Just what I needed! Quote Link to comment Share on other sites More sharing options...
PeteE Posted July 14, 2017 Share Posted July 14, 2017 (edited) Reading Keyboard or joystick (see http://www.unige.ch/medecine/nouspikel/ti99/keyboard.htm) To scan the keyboard, we must first activate a column by sending its number to CRU bit 18-20 at R12-address >0024. The bits are fed to the 74LS156 decoder that brings the corresponding keyboard column low. Then we must read the status of each keyboard row in CRU bits 3-10 at R12-address >0006. If a key is pressed the row will read as 0, otherwise it reads as 1 (non-intuituve!). To read a key, set R1,R12 and LDCR R1,3 to write CRU, then set R12 and TB to test selected bit CRUHere's some skeleton code that I use to read the keyboard/joystick directly LI R1, X * See chart below LI R12,>0024 * Select address lines starting at line 18 LDCR R1,3 * Send 3 bits to set one 8 of output lines enabled LI R12,>0006 * Select address lines to read starting at line 3 TB X * Test key bits, see chart R1 TB 0 TB 1 TB 2 TB 3 TB 4 TB 5 TB 6 TB 7 0000 = space enter fctn shift ctrl 0100 . L O 9 2 S W X 0200 , K I 8 3 D E C 0300 M J U 7 4 F R V 0400 N H Y 6 5 G T B 0500 / ; P 0 1 A Q Z 0600 Fire1 Left1 Right1 Down1 Up1 0700 Fire2 Left2 Right2 Down2 Up2 Edited July 16, 2017 by PeteE 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted July 15, 2017 Share Posted July 15, 2017 Reading Keyboard or joystick (see http://www.unige.ch/medecine/nouspikel/ti99/keyboard.htm) To read a key, set R1,R12 and LDCR R1,3 to write CRU, then set R12 and TB to test selected bit CRU Here's some skeleton code that I use to read the keyboard/joystick directly LI R1, X * See chart below LI R12,>0024 * Select address lines starting at line 12 LDCR R1,3 * Send 3 bits to set one 8 of output lines enabled LI R12,>0006 * Select address lines to read starting at line 3 TB X * Test key bits, see chart R1 TB 0 TB 1 TB 2 TB 3 TB 4 TB 5 TB 6 TB 7 0000 = space enter fctn shift ctrl 0100 . L O 9 2 S W X 0200 , K I 8 3 D E C 0300 M J U 7 4 F R V 0400 N H Y 6 5 G T B 0500 / ; P 0 1 A Q Z 0600 Fire1 Left1 Right1 Down1 Up1 0700 Fire2 Left2 Right2 Down2 Up2 Or using RXB use the CALL IO command to do this. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 15, 2017 Share Posted July 15, 2017 (edited) Question about matthew's ViewPort code: To me the map looks to be 88 columns wide by 40 rows high; with columns numbered 0-87 (left to right), and rows numbered 0-39 (bottom to top.) Is this correct? With the origin 0/0 being the bottom left corner, not top/left? The PLY40 code segment has me needing to take a break. Don't understand why you set the origin to the bottom-left corner when it's top-left in memory? Off to run and think... - james Edited July 15, 2017 by Airshack Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 15, 2017 Author Share Posted July 15, 2017 Well, counting from zero is a very common thing to do with computers and especially in assembly or when dealing with arrays. However, I'm not sure why the data model would be referenced from the bottom left instead of the top left. You are digging into code I have not looked at since I wrote it, so I'll have to go take a look. 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted July 15, 2017 Share Posted July 15, 2017 I'm familiar with using zeros when counting, just wondered if you had a unique scheme for the viewport origin being bottom/left vs top/left. Give me another look before you look back at your code. I'll figure it out. Wanting to get through it all before asking further questions. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 17, 2017 Share Posted July 17, 2017 (edited) So I used the TI Tech pages to create this little snippet of Code in my Forth Assembler to read the keyboard quickly. (just pretend the instructions are on the left side and it should make sense. TOS is just an alias for R4 PUSH is a macro that pushes a register onto the Forth data stack) I wanted something that reads the keyboard faster than KSCAN that just returns a non-zero value if a key is pressed. It works as expected BUT, the first few times I call it, it returns >400 even though no key is pressed. I am only using CLASSIC99, so I don't know if that is significant. So to use it I have to put it in a loop until I get a 0 which defeats the speed advantage I wanted. Any thoughts on what I am missing? HEX CODE: ?KEY ( -- ?) \ check if key pressed, ?=0 means no key TOS PUSH, R1 CLR, \ Start with column 0 @@1: R12 0024 LI, \ R12-address for column selection R1 3 LDCR, \ Set 3 bits R12 0006 LI, \ R12-address to read rows TOS SETO, \ set all bits TOS 8 STCR, \ Get 8 row values TOS INV, \ outputs are low active @@2 JNE, \ A key was pressed R1 0100 ADDI, \ Next column R1 0600 CMPI, \ Are we done @@1 JNE, \ Not yet NEXT, \ return to Forth @@2: SCRTO @@ CLR, \ Reset TI system screen timeout counter NEXT, \ return to Forth END-CODE Edited July 17, 2017 by TheBF Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 17, 2017 Share Posted July 17, 2017 Classic99's keyboard emulation should be pretty close. The fact that you get inconsistent behavior from the same piece of code speaks to a bug. Although effects are not emulated in Classic99 (nor actually tested by me), there is usually a delay between setting the CRU column and reading the data back -- based on other's approaches my fast kscan code uses an "SRC" with a count of 7 to get the delay. Beyond that, though, I can't see what's wrong with your code. It's very similar to my own. I'd suggest setting a breakpoint on it (that becomes asm, right?) and just stepping through the first invocation to see what the CPU is actually doing. Reference to my C version: https://github.com/tursilion/libti99/blob/master/kscanfast.c 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.