Musings on 99000 macro code

[Musings on 99000 macro code]

on vacation at the moment but I'll have a look to see if I have a copy when I get home

[Musings on 99000 macro code]

2 hours ago, mizapf said:

 

This reminds me very well of the behaviour of IBM in the nineties, whose OS division promoted OS/2 (which I actually favored over Windows 95, OS/2 was really cool), while the PC/Laptop division sold computers with pre-installed Windows.

TI was quite close to IBM, their joint venture brought about the first token ring chipsets

[Musings on 99000 macro code]

1 hour ago, BeeryMiller said:

Is this feature gone now? 

 

Beery

yes, existed only for the very first batch of silicon

[Musings on 99000 macro code]

14 hours ago, speccery said:

Thanks for sharing, sounds interesting. That sort of WP manipulation possibilities are certainly unique to the TMS9900 and TMS99000. Luckily TMS99000 instruction set  seems to also add support for normal stacks

as long as you wanted a stack that grew towards high memory they were fairly painless. We used to use the workspace to make fast routines for things, when you entered you could have all your registers pre-loaded with useful constants, pointers etc, overlapping workspaces was always "fun" just needed lots of coffee to hand :). the BLWP calling mechanism was always handy for passing inline parameters too, not something you get with other architectures, BL was abused in a similar way to save space

 

JMPR0    MOV  R11,R2      GET TABLE ADR
*
* NEXT INSTRUCTION INSERTED TO OVERCOME PROBLEM WITH
* ODD ADDRESS GENERATION (WITH TMS9980 AND 81 PROCESSORS)
*
    CLR  R1
*
JMPR01    MOVB *R11+,R1      GET DISPLACEMENT, DONE?
               JEQ  JMPR02            Y - INSTRUCTION FOLLOWING TABLE
               CB   R0,*R11+         N - CODE FOUND?
               JNE  JMPR01            N - KEEP LOOKING
               SRA  R1,7                Y - POSITION
               A    R1,R2               ADD DISPLACEMENT
               B    *R2                  GOTO ROUTINE
*
* BYTE OPCODE NOT FOUND - RETURN TO INSTRUCTION
* IMMEDIATELY FOLLOWING THE TABLE
*
JMPR02    INC  R11                 MOVE TO NEXT LINE
               RT
 

used to jump +/- 128 words based on R0 MSB used as in

 

*
*    HANDLE TEXT CONTROL CHARACTERS
*
CNTRL  BL   @JMPR0                   ;DO JUMP ON R0 (USES R1,R2)
CJUMP  BYTE HT-CJUMP/2,>09     HT - CURSOR RIGHT
            BYTE BS-CJUMP/2,>08    BS - CURSOR LEFT
            BYTE LF-CJUMP/2,>0A     LF - CURSOR DOWN
            BYTE VT-CJUMP/2,>0B     VT - CURSOR UP
            BYTE FF-CJUMP/2,>0C     FF - CLEAR SCREEN & HOME
            BYTE CR-CJUMP/2,>0D    CR - CURSOR BEGINING OF LINE
            BYTE FS-CJUMP/2,>1C     FS - CURSOR ON
            BYTE GS-CJUMP/2,>1D    GS - CURSOR OFF
       BYTE RS-CJUMP/2,>1E     RS - CURSOR HOME
       DATA 0
 

 

 

[Musings on 99000 macro code]

It might help you understand some of the strange and apparently contradictory decisions TI made back then if you knew that internally TI operated as several distinct and separate businesses. The semiconductor group was just interested in selling chips, the DSG? group was only interested in selling minicomputers and the home computer group only interested in the 99/4A. Semiconductor group wanted the 99000 as as faster generation of the 9900, the minicomputer group liked that as a cost down on building the minicomputers but was only interested in running it with loads of wait states (can't have the cheap version outperforming their cash cow main product 990/10, 990/12). The non-cooperation between groups was everywhere, our 990/10 had a pair of T50's (washing machine sized 50MB multi-platter disks) and we obtained a pair of T200's - (massive 200MB lol) but they sat idle for 18 months because DSG wouldn't sell the semiconductor group the controller card because they hag brought the drives from an unofficial source on the cheap.

The semiconductor group would love to put the 9900 family in a home computer and "do it right" but couldn't as home computers was another groups territory.

Sooooo ...

I was one of the developers of the Cortex home computer, published as a series of articles in the magazine Electronics Today International, developed in our own time this was an unofficial official project to get the family out into the public. Logistically the company Powertran handled the distribution and ETI the publicity.

Did you know that the first 9995 chips had a cru bit to enable/disable the internal ram? Great in a ram based system where you could disable the internal ram, write stuff in the same location and then re-enable the internal ram, your code/data was now safely hidden and inaccessible :)

[Musings on 99000 macro code]

4 hours ago, kl99 said:

Hi Tony,

That sounds awesome to work in this technology and get paid. Do you still have access to any software for a 990 or that 99000 bases system?

We are trying to preserve docs and software before it gets lost l.

Thanks a lot

Software, probably some Mag tape reels and 8" floppies, I have no means of reading them now. I have a vague recollection that one of the tapes has the TIP compiler source on but I could be wrong.

Manuals, quite a bit, anything you know you are short of?

[Musings on 99000 macro code]

On 6/6/2020 at 2:01 PM, speccery said:

Hi Tony, thanks for the comments, very interesting. As is discussed before in this thread, I have three TMS99105 chips, and at least one of them seem to have the TMS99110 floating point macrostore ROM. 

I am curious, what were the systems you were involved in using the TMS99000 series chips outside of TI?

for a few years I worked as a contractor for a company called Seismograph Services developing their DWS & MWS seismic recording systems for use on oil surveys. The MWS system used a 99000 based board with 2M of ram (special double high DIL sockets to take 2 dram DIL devices on top of each other, with a slight horizontal offset). It ran a custom version of the FS990 operating system that was used on the 990/4. We added support for hard drives, tape drives, keyboard with 2 line LCD, 610 memory mapper. Using the FP macrostore instructions we developed a complex maths package as the equipment had to do a lot of FFT type calculations and performance was critical. We did some insane stuff in that package like sliding the WP up and down a few words to move the FP accumulator (R0/R1) into "other" registers during sub calculations, quicker than moving the actual register contents and still accessible as registers just differently numbered registers, really messed with your mind during debugging

 

[Musings on 99000 macro code]

On 6/7/2020 at 9:58 AM, Jimhearne said:

Did you mean TMX and TMP prefixes ?

 

Jim

 

sorry, finger (or brain) trouble. TMX/TMP were pre TMS prefixes indicating devices that were pre qualification status and nothing to worry about, it's e-sample (engineering sample) marked devices you need to be a bit more cautious about

[Musings on 99000 macro code]

On 6/7/2020 at 3:25 AM, GDMike said:

Oh. I was caught up in the story.. excuse me. Welcome!!

thanks

[Musings on 99000 macro code]

I realise this thread is old but there again the 99000 is way older. I used to work for TI  and have worked with 99000s after leaving TI .

From what I can remember (which isn't terribly reliable), TMS & TMP prefixes designate devices produced before the part has completed full qualification (takes months) but are otherwise identical to the TMS part. 99000 devices were only available to the group making the 99/10A, the only devices gennerally available were the 99105 & 99110 (99120 never produced) and were identical silicon. 99110s were hard to come by for a long time and we ran 99105s with external macrostore containing TI supplied code as 99110 equivalents as we needed the floating point instructions. I think the supply issue with 99110s was down to a yeild issue.