Jump to content

Photo

xdt99: New TI 99 cross-development tools available


230 replies to this topic

#126 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,695 posts
  • Location:Silver Run, Maryland

Posted Thu Jan 14, 2016 5:53 PM

Why does xga99 gpl compiler implement the SLL, SRC etc... (shift bit wise instructions) in reverse order to that specified in the gpl_programmers_guide.pdf ?

It took me some time to realise why it was throwing an exception.

 

According to PDF Shift Right Circular = SRC GD,GS

but XGA99 needs this instruction as SRC GS,GD

 

Thanks

 

This is as stated in the docs on Ralph's Github site referenced in post #1 of this thread.

 

...lee



#127 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Thu Jan 14, 2016 11:51 PM

Ralph,

 

Just out of curiosity, was there a particular reason why the Bitwise Shift instructions were documented as Sxx GS,GD in you writing rather than Sxx GD,GS as found in the original scanned GPL documentation "gpl_programmers_guide.pdf". 

 

Thanks



#128 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 567 posts
  • Location:Germany

Posted Fri Jan 15, 2016 12:14 AM

Well, the problem was to decide which syntax to use.  Original GPL sources written by TI are hard to come -- in fact, to this day, I haven't seen any.  What you do see is disassembled GPL code, and there the syntax is entirely made up by the disassembler.

 

When I looked at today's GPL world I found that the RAG and the RYTE DATA (aka Weiand) syntax dominated, probably due to the extensive work by Rich.  Additionally, I implemented Michael's TI Image Tool syntax so that I could compile code disassembled by his tool.

 

Both of those syntax variants have the shift operators in "reverse" order, so I kept that.

 

My own xdt99 syntax variant is very similar to RAG, and thus keeps the reverse order for sanity reasons.

 

Note that I didn't implement the original TI syntax, as I found the FMT subsyntax to be rather ... arcane.  I still have the implementation on my low-prio todo list, for completeness sake, but so far I haven't got around to it.



#129 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Fri Jan 15, 2016 4:44 AM

Also keep in mind that the GPL source as used by TI has more structures than we find by GPL disassembly. For instance, it has some kind of if-then-else and for/while blocks, which are assembled to the common test/jump instructions. I have some original TI sources (not here) for the TI-99/8 - will post them later.

 

The problem is whether it makes sense to go for the original syntax if we don't have a proper assembler for it. The GPL format I created in TIImageTool wasn't actually intended to be used for assembling again, but instead to provide me with a better readable code.

 

There are indeed some more ugly parts. In particular, the compare instructions have a reversed operand order. This is because TI seemingly decided to compare dst versus src in order to get the well-known operand order, not src versus dst like in TMS9900 assembly language.

Attached Files


Edited by mizapf, Fri Jan 15, 2016 5:53 AM.


#130 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Fri Jan 15, 2016 7:13 AM

All,

 

  Given these limitations which is not the fault of any one person and my aim is to use my time to be able to contribute towards a product which can be enjoyed by many within a cartridge format, should I use my time more wisely on Assembly or is the XGA99 stable enough to achieve my goals using this wonderful GPL language?



#131 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Fri Jan 15, 2016 7:44 AM

TMS9900 (Assembly language) is wonderfuller. :)

In my humble opinion.

#132 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 567 posts
  • Location:Germany

Posted Fri Jan 15, 2016 8:55 AM

Personally I would love to see some new GPL programs -- you'd be quite a unique contributor in the area.  Right now I can only think of Rich who codes in GPL on a regular basis.

 

xga99 is absolutely stable.  You just have to decide on a syntax -- if you're uncertain, I recommend the RAG/RYTE DATA syntax, using option "-s rag".  That syntax variant is well established and has a very long tradition by now.  IIRC Rich is using it in his tutorials.  (And if you're really worried about your time investment I can always write a converter between variants later.)

 

Assembly is fine, but by using GPL you cannot get any more "TI" than that!



#133 ralphb OFFLINE  

ralphb

    Dragonstomper

  • Topic Starter
  • 567 posts
  • Location:Germany

Posted Fri Jan 15, 2016 8:58 AM

Thanks for GPL code, Michael!

.

$IF @RKEY .LT. :A: GOTO BADKEY 

SPEED0 FMT 2^,4<,':SET SPEED:',2^,23<,':[A] SLOW:';
           1^,24<,':[B] 99/4A SPEED FOR GAMES:',1^,7<;
           ':[C] FULL SPEED:'

.

Now I remember why I was hesitant to tackle that syntax!  ;)

 

Edit: formatting mess-up


Edited by ralphb, Fri Jan 15, 2016 9:00 AM.


#134 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,695 posts
  • Location:Silver Run, Maryland

Posted Fri Jan 15, 2016 9:48 AM

All,

 

  Given these limitations which is not the fault of any one person and my aim is to use my time to be able to contribute towards a product which can be enjoyed by many within a cartridge format, should I use my time more wisely on Assembly or is the XGA99 stable enough to achieve my goals using this wonderful GPL language?

 

The most advantageous feature of GPL is program size, I think.  That is at the expense of speed, of course, since it is a byte-interpreted language that operates on one memory-mapped byte at a time.

 

Then there is the FMT command, which is actually a sub-interpreter and allows extremely versatile management of the display screen.

 

The GPL interpreter is written in TMS9900 assembly language (ALC); so, if space is not a problem, it makes sense to write a faster, direct-memory accessed program in ALC.

 

...lee



#135 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,780 posts
  • Location:Denmark

Posted Fri Jan 15, 2016 9:53 AM

All,

 

  Given these limitations which is not the fault of any one person and my aim is to use my time to be able to contribute towards a product which can be enjoyed by many within a cartridge format, should I use my time more wisely on Assembly or is the XGA99 stable enough to achieve my goals using this wonderful GPL language?

 

I think you would be disappointed with the speed of GPL, and assembly would give you more options for distributing your work (disk, ROM).



#136 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,062 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Jan 15, 2016 11:46 AM

From what I've seen it's quite fast. A number of TI vat games are GPL only. Is around 50% of machine code unless in mistaken. Maybe a bit slower than forth but not a while lot.

#137 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Fri Jan 15, 2016 11:47 AM

Thank you all for your kind feedback. I will try to sacrifice my time for the greater good then, that of keeping GPL code alive. Do you know of any commercial games launched using GPL ?



#138 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Fri Jan 15, 2016 11:49 AM

 

I think you would be disappointed with the speed of GPL, and assembly would give you more options for distributing your work (disk, ROM).

I know you are right, but I feel very few tried to squeeze GPL. So maybe we can get something decent out of it.



#139 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Fri Jan 15, 2016 11:50 AM

I also read about a very recent library called Spectra2. Does anyone know of anything great that came out of using such a library? I cannot imagine such an effort going to waste.



#140 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Fri Jan 15, 2016 12:02 PM

If you look at this GPL code snippet from the 99/8 Monitor (ROM) you can see that the original TI GPL assembler had a src,dst argument order.

 

Nevertheless, as I said, if we don't have a suitable assembler, this is just of historic value.

*

*** THIS INITIALIZATION IS FOR THE ARMADILLO BREADBOARD #2 ONLY         ATA

*

       CLR  @0           CLEAR CPU RAM

       MOVE >71 FROM @0 TO @1

       MOVE >3E FROM @>00 TO @>82

       MOVE >B FROM @>00 TO @>74

       MOVE 22 FROM @0 TO @>C2                                          ATA

       DST  >0605,@CRLIST+1         DISABLE KBD INTERRUPTS              ATA

       I/O  @CRLIST,3

       DST  >1801,@CRLIST+1            TURN ON AUDIO GATE               ATA

       I/O  @CRLIST,3

       INV  @CLEARU                 WRITE A ONE TO CRU

       DST  >0102,@CRLIST+1         ENABLE VDP AND EXTERNAL INTERRUPTS

       I/O  @CRLIST,3

       DST  >1601,@CRLIST+1            TURN ON CASSETTE MOTOR           ATA

       I/O  @CRLIST,3

       CALL TON1$$                  BEEP AT PERSON

       ST   8,@>FD                INDICATE 16K RAM                      ATA

       DST #>3FFF,@MEMTOP         WE ALWAYS HAVE 16K OF RAM             ATA

       MOVE 1 FROM ROM(#H20) TO VDP(1)

       DATA XML2,FILLV,#>300,#>D00,0      CLEAR 4K OF VIDEO RAM         ATA

*                                        (LESS SCREEN)                  ATA

       DATA XML2,TIMVDP  Determine Euro/USA model                       GFH

       CALL INITC1     CLEAR SCREEN AND LOAD LARGE CHARS                ATA

       MOVE 32 FROM ROM(#TABLE$) TO TABLE(0)

****   MOVE 512 FROM ROM(#CHAR1$) TO CHAR(>20)                          ATA

       MOVE 80 FROM ROM(#TIBUG$) TO CHAR(1)

****   ALL  : :                                                         ATA

       ST 5,YPT

RSCAN

       ST YPT,@KEYBD       RESET ALL KEYBOARDS FOR SCAN                 ATA

       SCAN

       DEC  YPT

       BR   RSCAN

       DCLR YPT

       $REPEAT

         ST   >60,@RKEY                                                 ATA

         $REPEAT

           FMT  2('@RKEY'),>11^,30<,2('@RKEY')                          ATA

           SUB  >12,YPT

           ADD  >8,@RKEY                                                ATA

         $UNTIL @RKEY .EQ. >E0                                          ATA

       $UNTIL YPT .EQ. 3

       HOME

       UNLM                                                             ATA

       FMT  5^,15<,'1,2,3',29<,'4,5,6',29<,'7,8,9';

            8^,16<,':READY-PRESS ANY KEY TO BEGIN:'

       LISTM                                                            ATA

       MOVE 17 FROM ROM(#TI) TO RAM(296)

       MOVE 29 FROM ROM(#TI1979) TO RAM(706)                            ATA

       MOVE 8  FROM ROM(#HC) TO RAM(364)                                ATA 8/12

*

*      CHECK FOR EUROPEAN GROM AND GO TO THEIR

*      FOREIGN LANGUAGE CODE

*


#141 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,780 posts
  • Location:Denmark

Posted Fri Jan 15, 2016 12:27 PM

I also read about a very recent library called Spectra2. Does anyone know of anything great that came out of using such a library? I cannot imagine such an effort going to waste.

 

That's Retroclouds' assembly library. I think he used it for Pitfall and I think OLD CS1 has used it for his Arkanoid project. That would be a very good place to start.



#142 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,062 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Jan 15, 2016 1:10 PM

I personally prefer src,dst as it's the same way as 9900, which is of course, the best assembly language ever invented.



#143 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Fri Jan 15, 2016 1:46 PM

We're somewhat lucky to have only one syntax.

 

Compare with x86: http://www.imada.sdu...r/IntelnATT.htm



#144 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Fri Jan 15, 2016 3:33 PM

I wonder whether the GROMs were particularly invented for the 99/4. The TM990/189 seemed to have none, neither did the 99/2.

 

Are there any devices outside of the 99/4 family (console, cartridges, p-code card) that made use of GROMs?

 

If not, maybe the GROMs were a way to fit enogh memory into small cases (like cartridges) in that time. And GPL was possibly invented to have a kind of a machine language that works from GROMs. And if all that were true, the question still remains whether this was ultimately less expensive than trying to go for a true 16-bit system with pure TMS machine language.



#145 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,125 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Jan 15, 2016 6:09 PM

From what I've seen it's quite fast. A number of TI vat games are GPL only. Is around 50% of machine code unless in mistaken. Maybe a bit slower than forth but not a while lot.

 

GPL is slower than it needs to be... the interpreter is written to be very generic and doesn't take advantage of possible optimizations. For instance, the MOVE instruction, when accessing VDP or GPL, always sets each address for each byte moved. This makes it very generic (and would be necessary for VDP to VDP, for instance), but since most cases are between different memory types, a few separate MOVE routines could have been implemented, each optimized for performance. It spends a lot of time reparsing information it has already parsed before, rather than cache results. This makes it more memory efficient, but again, at the cost of performance. I've often wondered how fast GPL /could/ run with a new interpreter.

 

My main problem with it, personally, was that it's missing some memory access methods. For instance, the ONLY way to write to VDP registers is by using the MOVE instruction, which is a minimum of 6 bytes long. For what it was intended to do, run the system, I think it's acceptable, but for gaming and high interaction software it felt a bit clunky to me. (Of course, you can always have assembly subroutines).



#146 kl99 OFFLINE  

kl99

    Dragonstomper

  • 836 posts
  • Location:Vienna, Austria

Posted Mon Jan 18, 2016 8:08 AM

I wonder whether the GROMs were particularly invented for the 99/4. The TM990/189 seemed to have none, neither did the 99/2.

 

The actual GPL chip was being development by TI for an external customer. Once the customer dropped, the plan for the 99/4 was changed to use a TMS9985 instead, however the GPL language and Grom chips survived. As this one failed the tests because it was not ready yet they switched over to use the TMS9900. The Grom chip was invented by Granville Ott. I guess once you invent something, you tend to use it. Adress space and costs were the main reasons given.



#147 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,271 posts
  • Location:Germany

Posted Mon Jan 18, 2016 9:24 AM

Yes, I mean, having these GROMs is one thing; one could have decided to just store data in them. But to develop a complete virtual machine (which the GPL interpreter is to some extent) with an own instruction set, maybe from scratch, is a much bigger thing.

 

If only I had a time machine ... I'd like to have some serious talk with the person in charge.



#148 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,062 posts
  • Location:Uzbekistan (no, really!)

Posted Mon Jan 18, 2016 3:29 PM

Yes. The 4A is much more of machine than its peers. It's always felt like a small mini-computer to me. There's a hell of a lot of stuff going on under that handsome aluminium cover!

#149 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,780 posts
  • Location:Denmark

Posted Sat Jan 23, 2016 1:42 PM

Could xas99 optimize MOV @FIELD(R1),R0 to MOV *R1,R0 if FIELD is zero?

 

I use the indexed addressing mode a lot to read and write data structures, and define each field as an EQU with values 0, 2, 4 etc. This results in readable and changeable code, but being a speed freak I hate that the CPU has to read the extra word when the field number is zero.

 

Thanks, R



#150 Davvel OFFLINE  

Davvel

    Moonsweeper

  • 259 posts
  • Married
  • Location:Malta

Posted Sun Jan 24, 2016 9:23 AM

Rasmus,

 

  Do you have some advice on best way to determine collision detection in Assembly ?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users