Jump to content
IGNORED

Assembly on the 99/4A


matthew180

Recommended Posts

 

... 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 by Airshack
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 right
From 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 by Airshack
Link to comment
Share on other sites

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 right
From 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).

  • Like 1
Link to comment
Share on other sites

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 right
From 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.

  • Like 1
Link to comment
Share on other sites

 

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 :grin:

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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 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 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 by PeteE
  • Like 2
Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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 by Airshack
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by TheBF
Link to comment
Share on other sites

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

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...