Jump to content
IGNORED

xdt99: New TI 99 cross-development tools available


ralphb

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

monitor.gpl.zip

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

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?

Link to comment
Share on other sites

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!

  • Like 2
Link to comment
Share on other sites

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

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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

*
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 3
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...