Powertran Cortex

[Jim Hearne]

TMS99105 on it's way

I presume that with a suitable interface board I should be able to make a "overdrive" processor for the Cortex ?
Not looked at the 99105 closely yet, just bought one.

Jim

 

[Stuart]

Will be a bit tricky to use a 99xxx with the Cortex as a 99xxx has a full width 16-bit data bus. So you'd need some sort of data bus multiplexer to convert between 8 and 16 bit. Which should introduce some interesting timing issues because on the 99xxx the data bus is also multiplexed with the address bus ... ;-)

 

[pnr]

And I've bought the other 99105 chip from this seller. Not sure I will have the time to build the "99110" breadboard within the 2 week return period, but it seems a reasonably safe bet. Everybody thanks for the heads-up.

A 99105 breakout board for the Cortex does not immediately make sense. From Stuart's measurements, a 99xxx is about 15% faster than a 9995, when both are running without wait states on a 16 bit bus and at 3 MHz (i.e. 9995 code and workspace on the internal RAM). When code and and workspace are in main RAM the difference goes up to about 60% faster. Putting the 99xxx on 6 MHz makes it 1.6 x 2 = ~3 times faster.

But that all assumes zero-wait state memory. The memory circuit on a Cortex can only deliver one byte every 650ns or so. A 6 MHz 99xxx would need about 7 wait states for two bytes to be delivered from RAM. Taking that into account, the breakout board is more likely to be back in the 15% performance difference area. You could of course integrate fast RAM onto the board and use it as a kind of co-processor, perhaps hooked up to the E-Bus.

However, I think you might have a F18A installed, I believe. That FGPA was mentioned a few days ago in this thread contains a 9900 co-processor that is at least 10 times faster than your current CPU.

Paul

 

[pnr]

Have not heard from Alan Beard, either I located the wrong person or he's not interested to respond. It would seem that the TI-C compiler is out as an option.

In better news, I have made some progress on porting the Ritchie C compiler to the 99xx and it looks quite promising. With only a hour here or there to work on that, it will be a little while before I have something.

 

[Jim Hearne]

A 99105 breakout board for the Cortex does not immediately make sense. From Stuart's measurements, a 99xxx is about 15% faster than a 9995, when both are running without wait states on a 16 bit bus and at 3 MHz (i.e. 9995 code and workspace on the internal RAM). When code and and workspace are in main RAM the difference goes up to about 60% faster. Putting the 99xxx on 6 MHz makes it 1.6 x 2 = ~3 times faster.

But that all assumes zero-wait state memory. The memory circuit on a Cortex can only deliver one byte every 650ns or so. A 6 MHz 99xxx would need about 7 wait states for two bytes to be delivered from RAM. Taking that into account, the breakout board is more likely to be back in the 15% performance difference area. You could of course integrate fast RAM onto the board and use it as a kind of co-processor, perhaps hooked up to the E-Bus.
Paul

Yes, you are quite correct, it doesn't really make sense, i didn't by the TMS99105 for that purpose, i just fancied making a SBC with it like Stuart has (except on Vero or maybe a PCB).
I'd not even read that datasheet when i bought it.
Any thoughts on how to run it a full speed but still having I/O
I know the TMS9901 and 9902 only run at a max of 4Mhz clock but the TMS99105 Clkout will be 6Mhz.
I can't seem to find any Texas I/O chips for the TMS99xxx series cpus, did they do any ?
Failing that i assume that dividing the TMS99105 Clkout by 2 to give 3 mhz and then adding some wait states to the CRU accesses for those devices should work ?
If i do a PCB it would be nice to make it plug into the E-Bus and then it could maybe act as a co processor to the Cortex.

Jim

 

[Stuart]

Any thoughts on how to run it a full speed but still having I/O
I know the TMS9901 and 9902 only run at a max of 4Mhz clock but the TMS99105 Clkout will be 6Mhz.
I can't seem to find any Texas I/O chips for the TMS99xxx series cpus, did they do any ?
Failing that i assume that dividing the TMS99105 Clkout by 2 to give 3 mhz and then adding some wait states to the CRU accesses for those devices should work ?

Don't think TI did any I/O chips to work at that speed, and I don't think you can use wait states with CRU accesses - /READY seems to be only sampled for memory accesses. But can easily add single bit and parallel I/O with a couple of memory mapped TTL chips, and interface a faster non-TI UART like the 16550?

Stuart.

 

[mnbvcxz]

You could use a microcontroller to provide all the I/O capability of your board or if you want more ports than an MCU can provide, you could use a 9900/9995 to handle I/O and have it connected to the 99105 with ~2k shared memory.

 

[pnr]

... I don't think you can use wait states with CRU accesses - /READY seems to be only sampled for memory accesses. ...

I think you can. See figure 23-25 in the prelim data manual, including footnotes. Also, figure 16 suggests that the 99xxx has automatic wait state insertion ("WAITGEN"), but I could not find how to activate it. Perhaps the same as for the 9995.

Paul

 

[pnr]

If i do a PCB it would be nice to make it plug into the E-Bus and then it could maybe act as a co processor to the Cortex.

I'd love to do a single eurocard version of a 9995 based system and a 99105 system on two piggybacked eurocards. However, my Eagle skills are next to non-existent. Other than the E-bus interface, most of the routing could be the same. I'm too busy now, but in a few months time I'd be interested in working on PCB's for this, as a novice assistant.

Paul

 

[Jim Hearne]

Don't think TI did any I/O chips to work at that speed, and I don't think you can use wait states with CRU accesses - /READY seems to be only sampled for memory accesses. But can easily add single bit and parallel I/O with a couple of memory mapped TTL chips, and interface a faster non-TI UART like the 16550?

Stuart.

Page 34 of your 99xxx databook says /READY is sampled on I/O operations and can be used to extend them.
Seems strange TI bought out the 3rd gen cpu but no I/O devices that would work with it at full speed.

I have plenty of 68xx and 65xx series I/O chips but you usually end up adding a load more interface logic when converting between manufactures.

Jim

 

[pnr]

C on a 9995

C on a 9995

I'm spending way more time on this than I should, but over the weekend I've grown quite optimistic over the Ritchie compiler port. It is now in a state where it will compile small test routines satisfactorily. I'm currently working with it as a cross-compiler, but it should fit on a Cortex:
- If I'm not mistaken there is 56K of available RAM (8K mapped to I/O?)
- The compiler has three passes, measuring 18K, 22K and 8K for the PDP11 binaries
- It would seem that the passes need 10-20K in data space, so 30-40K is needed for it to run
Using Cortex Basic/CDOS as host (taking up 24K), one should be able to compile smaller programs. Using MDEX (with a 12K kernel), it should have enough room to compile itself.

Considered at a very high level, the code generation pass (the second pass, ~4.000 lines of C) works by matching code snippets to the parse tree. There are about 350 such code snippets and I have reviewed/adapted about 50 so far. I'd like to share my progress, and perhaps get some input/help from others. Certainly the folks working on gcc ports (Dave Pitts and "tursi") might be interested.

I'm not sure this thread is the right forum to expand on the compiler port. Use a new thread in the TI area of this forum? Use another forum for this? Or is this thread the best place?

Paul

 

[Stuart]

Page 34 of your 99xxx databook says /READY is sampled on I/O operations and can be used to extend them.
Jim

Ah, yes, you're absolutely right! Checking again, the 9995 works in the same way. Only the 9900 where READY only applies to memory cycles (unless it's just the way that the spec is worded?).

 

[Jim Hearne]

I'd love to do a single eurocard version of a 9995 based system and a 99105 system on two piggybacked eurocards. However, my Eagle skills are next to non-existent. Other than the E-bus interface, most of the routing could be the same. I'm too busy now, but in a few months time I'd be interested in working on PCB's for this, as a novice assistant.

Paul

I don't know if Stuart still has any of the MPE TMS9995 eurocard boards left.

PCB's I am good at (IMO), though the program I use here at work ( Boardmaker ) is rather old and won't export anything other than Gerbers.

Would a 99105 system need 2 Eurocards ?, if you use modern RAM and EPROM (or even EEPROM) like Stuart has it shouldn't take up too much space.

Jim

 

[Stuart]

Also, figure 16 suggests that the 99xxx has automatic wait state insertion ("WAITGEN"), but I could not find how to activate it. Perhaps the same as for the 9995.

Depending on where you look, pin 6 on the 99xxx is described as either WAITGEN or Vss. Talking with someone else a while ago, we concluded that the wait generation circuit in the 99xxx is possibly buggy so they relabelled the pin as Vss so the wait gen circuit is disabled.

 

[tms9995]

C for Cortex Basic/CDOS

C for Cortex Basic/CDOS

Thanks to a great kick-start from Paul, I have pursued the C99 route. I got the DOS version from whtech running using my C++ Builder XE2 and modified the CSUP Runtime Library for use with Cortex Basic.

Like Paul said, c99 produces .asm source file(s) that are assembled and linked to a single relocatable object file using asm990 and lnk990. I have written a utility that converts the object file to an auto-run machine code program in the form of a .cas file, which can be loaded into the emulator or real Cortex. The load address is user selectable . Works very well. Basically, with the C source in your favourite editor, simply press Save, run a build.bat script in a DOS window and do a LOAD"" on the Cortex and it's running C code! I've been wanting to do this for years.

I still have some tidying up to do and I've not added a CDOS file I/O library yet. Also, I probably need to develop a .cas to CDOS file utility if you want to actually save the file on CDOS, although this can easily be done manually just using MONITOR.

As far as getting the compiler itself to run on CDOS (and MDEX), I've not anything with this yet. Anyone got a copy of the C99 source without the DOS/UNIX mods? I'd prefer to use this rather than try to take all the mods out (I think there might be more than the ones indicated by #ifdef _DOS etc).

Dave.

 

[Stuart]

Excellent work chaps!

A few questions:

(1) What hardware do the ports of C support? Serial? Keyboard? VDP?
(2) What's the format of the object file from asm990 and lnk990? Attach a sample?
(3) What changes would be needed to run the object code on a different 99xx system, like my breadboard systems? The CRU address of the serial port?

Stuart.

 

[tms9995]

Excellent work chaps!

A few questions:

(1) What hardware do the ports of C support? Serial? Keyboard? VDP?
(2) What's the format of the object file from asm990 and lnk990? Attach a sample?
(3) What changes would be needed to run the object code on a different 99xx system, like my breadboard systems? The CRU address of the serial port?

Stuart.

Hi Stuart,

Best example of asm990/lnk990 is http://www.powertrancortex.com/downloads/EPROM Build from Source.zip

Each asm file is assembled to an obj file. Each obj file is then linked to a single relocatable obj. I then wrote something to convert that to an absolute binary ROM file.

As for c99, it just adds an extra step of producing an asm from a c module. I then modified the 'mkrom' utility to produce the .cas file.

As far as hardware goes, my changes to the Runtime Library for Console I/O use the built-in MID instructions (e.g. READ R1 to read a key, WRIT R1 to display it etc.). That's about it. It's very 'open' in that if you want a function to support something, either write it in C or assembler or just add it to the RTL. This is what I like about it really. It's purely a cut down C compiler (with no libraries!) that's so light-weight, it is completely self-contained. The only thing the RTL needs to do is initialise the stack and handle the exit back to Cortex Basic, the rest you add as required. The manual describes putchar, puts, getchar & gets but you can make them do whatever you want or eliminate them if you don't need them. Paul, on the other hand, is after a full compiler as he's trying to build Unix!

I'll post it all when I'm done tinkering.

Dave.

 

[pnr]

(3) What changes would be needed to run the object code on a different 99xx system, like my breadboard systems? The CRU address of the serial port?
Stuart.

For instructions how to use small C with the breadboard see my post of Jan 4th, 12:30.

The Ritchie compiler outputs assembler in unix syntax (using e.g. ".globl" instead of REF/DEF); I ported a unix v6 assembler to the 9900 and modern C a few years back and that's what I'm using now. All work in progress.

Just like small C its output expects nothing from the environment: if you need interfacing with the hardware, you write a small assembly subroutine to do that for you. Essentially, 'getc' and 'putc' is all you need to get going.

Paul

 

[pnr]

Would a 99105 system need 2 Eurocards?, if you use modern RAM and EPROM (or even EEPROM) like Stuart has it shouldn't take up too much space.
Jim

Probably I was demonstrating my ignorance. My thoughts were that if you put 2 RAM, 2 ROM, a LS612 mapper, 4 bus drivers, a CPU, a microcontroller, a flash card, the UART and USB breakout board, and some 5..10 TTL glue chips on a board pretty much all space is gone and where will the tracks go then? Two cards stacked together would still fit in a flat alu box and make a nice "pocket-minicomputer". Just Stuart's minimal design should certainly fit on a single card.

Paul

 

[Stuart]

Fake Chips

Fake Chips

We know that the TMS9909 FDCs on eBay from a certain Chinese supplier are fakes. A couple of months ago I was given some surplus 99xx chips by a UK eBay supplier who sells 'kits of parts' of various processor families, and these parts are apparently sourced from China. This included a TMS9900 and a TMS9995. Both looked distinctly dodgy, with the date codes not making sense and the printing not looking quite right. Surprisingly, both work absolutely fine. Also included were two clock generator chips for the 9900, which should be TIM9904ANL's. They're obviously new (or re-labelled), but are actually printed "TMS9904ANL" (TMS, not TIM), which is not a valid designation. Even more surprisingly, these work as well ...