Jump to content

Photo

Musings on 99000 macro code

99000 ti990/12 macro code

42 replies to this topic

#26 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Sat Jan 20, 2018 4:05 AM

 

I am not sure if I understood your assumptions correctly - is your working assumption that some 99105 chips are actually 99000 chips without any support for macro code? I thought that we've been lucky with some 99105 chips behaving as 99110, but that a 99105 would still be a 99105 as a minimum. 

 

In short my assumption is that all of the 99000, 99105 and 99110 actually have macro code support, but only differ in what is inside the macro ROM. So far we have yet to find a true 99105 chip with a blank ROM: so far we have three 99105's that have 99110 ROMs inside, one that most likely has a 99000 ROM inside, and two that are as yet unidentified (one of which is your second chip - which also seems to have the 99000 ROM, the other is JH's chip - which I suspect has a 99110 ROM).

 

The longer answer is that the 99xxx was designed in the closing days of manual mask production, with masks being taped out by hand on huge mylar sheets. In that context it does not make sense to have multiple designs, other than ROM contents.

 

Some two years ago I thought that there perhaps never was a 99000 and that the TI990/10A actually used a 99105 chip. This idea has now reversed: perhaps there never was a 99105 ROM, but all are 99000 or 99110 ROMs. Maybe in the early years 99105's included chips that were fully functional except for an error in the ROM: this would have improved yields and thus reduced cost. On the other hand, the ROM covers only ~10% of the chip surface area, so functional chips with only an error in the ROM would be relatively rare among defects.

 

As time progressed the yield must have gone up, perhaps as high as 80-90% in the second half of the 80's. If TI persisted with having no specific 99105 ROM that would mean that a very large share of 99105's currently floating around have functional 99000 or 99110 ROMs inside (and by 1985 it would have made no sense for TI to put new money into the 99xxx, at that point they were just producing them to recoup the investment). That theory seems to fit with what we observe. Based on findings so far I would say that the odds are 50-50 or perhaps 60-40 in favour of finding a chip with a 99110 ROM.



#27 speccery OFFLINE  

speccery

    Moonsweeper

  • 336 posts

Posted Sat Jan 20, 2018 4:45 AM

Thank you Paul, this starts to make sense. I have done a bunch of new tests - and I did read the data sheet more carefully, which also helped a great deal... 

 

I enabled the prototyping mode on my second TMS99105, I have a latch that drives both RESET# and APP# pins separately so that was easy to do, only FPGA change. After loading the TMS99110 macro code ROM into address >800 in my macrocode region, I have this second TMS99105 working as a TMS99110. Nearly - it seems there is a minor difference in timing between macro store reads and normal reads, as the system is a little unstable when running from macro store. But occasionally I get it to run the floating point test properly, and that can only happen when the CPU is reading the macro store code from external RAM properly.

 

It is also possible that the FPGA timing variations between different synthesis runs cause this specific run to be unstable, I do not know how much timing margin I have, I haven't placed many timing constraints in there. However, in general I have had no problems making FPGA design changes and coming up with stable synthesis results, and this FPGA load works well as long as I am not running code from macro store, so I think the source of problems is a slightly different timing with macro store accesses.

 

But all in all, I think I now understand better this functionality. It would also appear that with a "real" TMS99105 it only makes sense to run the CPU in prototyping mode, otherwise one cannot locate the vectors at macro store >800 onwards into external memory.



#28 HackMac OFFLINE  

HackMac

    Chopper Commander

  • 158 posts
  • Skywalker
  • Location:Germany

Posted Sat Jan 20, 2018 5:23 AM

Please find attached a quick disassembly with xda99. It does not handle the extra 99000 instructions and has those as DATA, but that is minor.

If you use an Apple Computer, you can use the TI-Disk Manager for disassembling code for nearly all processors of the 99xxx family.
It has an interactive tool (Disassembler Editor) for producing clean source code.

Edited by HackMac, Sat Jan 20, 2018 5:32 AM.


#29 speccery OFFLINE  

speccery

    Moonsweeper

  • 336 posts

Posted Sat Jan 20, 2018 6:48 AM

If you use an Apple Computer, you can use the TI-Disk Manager for disassembling code for nearly all processors of the 99xxx family.
It has an interactive tool (Disassembler Editor) for producing clean source code.

 

 

Thanks! That's cool, I downloaded and ran it. The file to disassemble is not in any TI Disk format, just a plain 1k binary on my Mac's disk, what would be the steps to get it disassembled with your tool?



#30 HackMac OFFLINE  

HackMac

    Chopper Commander

  • 158 posts
  • Skywalker
  • Location:Germany

Posted Sat Jan 20, 2018 7:01 AM

I'll anwer with an PM - don't want hijack this thread... (or we have to switch to the TI-Disk Manager thread :) )



#31 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Sat Jan 20, 2018 10:01 AM

 

I didn't think the 99000 existed as a specific chip, i thought it was just a name for the 99xxx series of chips, the 99105, 99110 and the probably never made 99120.

 

 

That's what I thought for a long time as well. However, chips marked TMS99000 (or at least marked TMP99000 and TMX99000) do exist:

http://www.cpu-world...t=19180&start=0

The coding looks like preproduction samples, but the date codes (1983) suggest that these were much later. Interestingly, one of the pics shows a TMP99000B (not A). If memory serves me right, Ksarul has a chip marked "TMS99000" in his collection, but I'm not 100% sure.

 

When I write having a "99000 ROM" I mean the ROM in the chip that was used in the TI990/10A. The pictures of TI990/10A CPU boards that survived are too low res to read the marking, or have other issues (like glare on the lid) for example here:

http://img11.hosting...50tm990_10a.jpg

The TI990/10A board that Dave Pitts has in his collection has a chip with completely faded markings.

 

In summary, I don't know for sure what the markings on the CPU chip in a TI990/10A were, and I use "99000" as a best guess.


Edited by pnr, Sat Jan 20, 2018 10:03 AM.


#32 speccery OFFLINE  

speccery

    Moonsweeper

  • 336 posts

Posted Sat Jan 20, 2018 10:18 AM

 

When I write having a "99000 ROM" I mean the ROM in the chip that was used in the TI990/10A. The pictures of TI990/10A CPU boards that survived are too low res to read the marking, or have other issues (like glare on the lid) for example here:

http://img11.hosting...50tm990_10a.jpg

The TI990/10A board that Dave Pitts has in his collection has a chip with completely faded markings.

 

Wow there is a ton of logic on those boards. I suppose there is architecture documentation somewhere? That would be an interesting FPGA project to build the whole thing... I will probably extend my TMS9900 FPGA CPU to TMS99000 at some point.



#33 kl99 ONLINE  

kl99

    Dragonstomper

  • 836 posts
  • Location:Vienna, Austria

Posted Sat Jan 20, 2018 4:58 PM

There are documents showing the schematics of TI-990 machines:

http://www.bitsavers...s/990-10cpu.pdf
http://www.bitsavers...990/schematics/



#34 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Mon Jan 22, 2018 3:13 AM

My 'new' 99105 arrived from China. It has the 99110 ROM :^)

 

After reading out the ROM, I can confirm that it is byte-for-byte identical to the ROM in speccery's chip.

 

That further supports the theory that - at least later in the chip's lifecycle - fully functional 99110 silicon was put in some of the packages marked 99105.



#35 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,583 posts

Posted Mon Jan 22, 2018 7:48 PM

I have at least one TMS99000 chip here at the house, on a strange little single-board machine that was given to me by a former TI employee in Germany. All I have is the fully-populated board--not the rest of the associated machine.



#36 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Tue Jan 23, 2018 2:13 AM

I have at least one TMS99000 chip here at the house, on a strange little single-board machine that was given to me by a former TI employee in Germany. All I have is the fully-populated board--not the rest of the associated machine.

 

 

Interesting. Could you post a picture of the board and of the chip markings?



#37 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,583 posts

Posted Tue Jan 23, 2018 6:22 AM

I'll look to see where I put it away, as I haven't touched it in about 20 years now. . .



#38 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Thu Feb 1, 2018 2:42 PM

I've done a bit more testing on the 99105 chips that seem to support the TI990 variant of the LDS, LDD and LMF instructions. The theory here is that these chips have silicon inside with the macro ROM that was used for the TI990/10A mini. The further tests support that theory.

 

The TI990 assembler manual

http://bitsavers.inf...smRef_Nov82.pdf
documents what LDD, LDS and LMF were supposed to do.

The TI990/10A general description
http://bitsavers.inf...Descr_Sep82.pdf
documents that a 10A has its mapper registers in the parallel CRU area >9F80->9FFF.

(there is table with the CRU address map that has this info on page 1-19).

 

So I set up a test to see if my 99105 chip supported that. The test looks to see if the LDD/LDS/LMF instructions indeed store the map information to parallel CRU addresses in the >9F80->9FFF range. They  do:

 

LMF R0,0 loads the 6 words to >9F80 (i.e. this is where map 0 is)

LMF R0,1 loads the 6 words to >9FA0 (i.e. this is where map 1 is)
LDD and LDS both load the 6 words to >9FC0 (i.e. this is where map 2 is)

This means that a sequence LDD-LDS-MOV is of limited use: both the source and destination will use the "map 2" loaded by LDS, as that overwrites the upload by LDD.

 

My conclusion is that the code for LDD/LDS/LMF in the 99000 ROM is simple and easy to factory test. This probably means that there really is no backdoor to its ROM. On the other hand, using the 99110 ROM as a guide, it is now fairly easy to newly write the code for a 99000 ROM. It will of course not be exact, but it will document what is functionally in there.

 

This is my go at recreating that code:

; Macro ROM jump table
;
        AORG >0800

        DATA ILLOP
        DATA ILLOP
        DATA ILLOP
        DATA LMENTR
        DATA ILLOP
        DATA ILLOP
        DATA LDENTR
        DATA ILLOP
        DATA ILLOP
        DATA ILLOP

; LMF
;
LMENTR  MOV R5,R2          ; Is opcode LMF?
        ANDI R2, >FFE0
        CI R2, >0320
        JNE MAP1
        LI R12, >9F80      ; Yes: LMF for map 0
        JMP PRVTST
MAP1    CI R2, >0330
        JNE ILLOP
        LI R12, >9FA0      ; Yes: LMF for map 1

PRVTST  CZC @USER,R15      ; CPU is in supervisor mode?
        JNE PRVERR

        ANDI R5, >000F     ; Fetch map pointer from register W
        ORI R5, >0020      ; by pretending W is *R
        EVAD R5

        LDCR *R8+,11       ; Load six words into MMU
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8+,11
        LDCR *R8, 10
        RTWP               ; Normal exit      

ILLOP   RTWP2              ; Return with ILLOP error

PRVERR  LIMI 0             ; Return with PRIVOP error
        RTWP

; LDS/LDD
;
LDENTR  MOV R5, R2         ; Opcode is LDD or LDS?
        ANDI R2, >FF80
        CI R2, >0780
        JNE ILLOP

        CZC @USER,R15      ; CPU is in supervisor mode?
        JNE PRVERR

        ANDI R5, >003F     ; Mask out src bits
        EVAD R5
        JNE NOINCR         ; Handle auto-increment
        INCT *R10

NOINCR  LI R12, >9FC0      ; Base address of map register 2
        MOV *R8, R2        ; Fetch pointer to new map

        LDCR *R2+,11       ; Load six words into MMU
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2+,11
        LDCR *R2, 10
        RWTP4              ; return, skip interrupt test

USER    DATA >0100

Note that for CRU addresses in parallel space (i.e. R12 has top bit set), that a bit count of 11 means 'transfer a word and post-increment R12 by 2' and a bit count of 10 means 'transfer a word, leave R12 as-is'.

 

I think I have also finally figured out how the TI990/10A mapper can work out that a LDD/LDS is in effect (as the supervisor can use both PSEL=0 and PSEL=1, it is hard to tell when the PSEL/D15 line it is being inverted).

 

However, every change to the PSEL status bit is echoed on the address bus during an ST machine cycle (bus code 1101, see section 2.4.2. and table 2 in the data sheet). The mapper can use this to keep a copy of the PSEL bit in the status register in a flip-flop, and doing a XOR with the bit on the PSEL/D15 line will tell it when the bit is inverted and "map 2" has to be used.

 

 



#39 speccery OFFLINE  

speccery

    Moonsweeper

  • 336 posts

Posted Thu Feb 1, 2018 3:10 PM

Very interesting and great work, pnr! If I wanted to test my TMS99105 to see if it behaved similarly, I would just need to watch for those parallel CRU space accesses - is that right?

#40 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Fri Feb 2, 2018 12:25 AM

Yes, that is correct.

#41 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Sat Feb 17, 2018 1:17 PM

I've built a little modification on Stuart's 99110 board to test the copying of status bits ST7 to ST11 to external flip-flops.

 

I'm decoding bus status "ST" (binary 1101) and then clocking the address bus bits 7-11 to an external flip-flop on the rising edge of CLKOUT. This appears to work fine.

 

Copying status bit to external flip-flops makes it possible:

 

(i) to make the non-privileged/privileged status (ST7) available to external hardware

 

(ii) to use the status map select bit (ST8) directly in external hardware and to use the PSEL signal to signify "use another map" to the MMU (as the TI990/10A mini does)

 

I've also found that the unassigned status bit (ST9) is present as a real register bit on 99xxx silicon: it can be set and reset. Like ST7 and ST8, the ST9 bit is reset whenever a reset, interrupt or XOP occurs. On the TI990/12 mini this bit enables error checking by the MMU. Maybe in a new design other creative uses are possible.

 

I'm finding the 99xxx an ever more intriguing design!

 

 



#42 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 9,561 posts
  • Location:Hustisford, WI

Posted Sat Feb 17, 2018 1:25 PM

https://rover.ebay.c...tm/202228801857

Pricey but cool

#43 pnr OFFLINE  

pnr

    Chopper Commander

  • Topic Starter
  • 105 posts

Posted Sat Feb 17, 2018 4:56 PM

Thanks for that link and that is indeed pricey!

 

The TM990 series are development boards:http://http://www.st...tm990/tm990.htm

 

Although they can be rack mounted, they are very distinct from the TI990 series mini computers. In a way, they are more reminiscent of PEB boards.

 

The board that was sold on eBay is trainer board with a 9981 CPU and a calculator style user interface.

 

(there's some pictures of a TI990 here:

http://www.computing...omputer-System/)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users