• Please review our updated Terms and Rules here

Powertran Cortex

Found the time to build it. It appears to work, except for the mapper. Need to do further testing, and probably will have to make a "revision 2" PCB.

That's great news. As for the mapper, you're going to need that to run NOS. It's somewhat flexible, but essentially it needs 128K as a minimum. NOS ends around 0xEFFF and builds downwards to 0x6600 ish (depending on drivers and so on). It then pages out everything from 0x0000 to 0xDFFF to provide a userspace of 56K (0xE000-0xEFFF is NOS's common area). I've been hitting it pretty hard over the last couple of months so hope to have a NOS package put together sometime soon. It's awesome!

Dave.
 
That's great news. As for the mapper, you're going to need that to run NOS. It's somewhat flexible, but essentially it needs 128K as a minimum. NOS ends around 0xEFFF and builds downwards to 0x6600 ish (depending on drivers and so on). It then pages out everything from 0x0000 to 0xDFFF to provide a userspace of 56K (0xE000-0xEFFF is NOS's common area). I've been hitting it pretty hard over the last couple of months so hope to have a NOS package put together sometime soon. It's awesome!

It turns out that the mapper can be made to work with just a little rework. Pictures attached of the top and the bottom view. The mini-cortex currently runs EVMBUG and Stuart's 'breadboard BASIC' port of Cortex BASIC. It also runs MDEX and Unix. Although there is socket for an F18A I have not tested that yet.

It would be great to add NOS to the list. The mapping you mention above should be no problem. Do you have documentation for the NOS on-disk format, so that a tool can be written to create disk images, and load/extract files from such image? What software exists for it, the same packages as for MDEX?
 
It would be great to add NOS to the list. The mapping you mention above should be no problem. Do you have documentation for the NOS on-disk format, so that a tool can be written to create disk images, and load/extract files from such image? What software exists for it, the same packages as for MDEX?

From what I can tell, the software is the same as MDEX (programming languages, word processor etc.). What it brings is the feel of a true operating system. Cortex Basic + CDOS is great but it always had that 'home computer' feel. MDEX added the more conventional environment of an OS but it always felt very limited. NOS changes that:

Multiple storage units mounted as Volumes (4 floppies, RAM disk, Hard Disk).
Directories
Users, Groups, Access Rights
Interrupt-driven I/O
Time/Clock
Automatic directory and file creation, expansion and fragmentation
Script files
Easier file copying (file/directory/volume)
File paths by volume name e.g. MYNOS:utils/source/test.asm where MYNOS is the volume name of, say, a floppy. The floppy can be mounted in any floppy drive so you don't have to remember which one (if you're moving disks around etc.).

There are probably other things but it's just a lot easier to use.

As for the disk format, it's nothing like MDEX. It does have the interleave but that's very easy to remove by SYSGENing a drive as having no interleave and then copying your interleaved disk to it. There are various DEF files. One is FILEDEF:

Code:
.
.         FILEDEF
.
.         File system internal definitions
.
.         Memory Inode format returned by FSTAT$/OSTAT$
.
iflags    equ       0                   flag bits
irfu      equ       2                   reserved for future use
irefc     equ       4                   number of links to file
isizeh    equ       6                   length in bytes (high word)
isizel    equ       8                   length in bytes (low word)
igroup    equ       10                  group ID of owner
iuser     equ       12                  user ID of owner
idcre     equ       14                  date of creation
idlref    equ       18                  date of last write
ipgmap    equ       22                  start of page map
.
.         Inode flag bits
.
ifall     equ       08000               Inode is allocated
ifcont    equ       04000               contiguous file
ifft      equ       03000               file type
ifftn     equ       00000                normal file type
ifftd     equ       01000                directory file type
iflarge   equ       0800                page table format if nonzero
ifasui    equ       0200                assume user ID if nonzero
.
ifread    equ       4                   read permission bit
ifwrite   equ       2                   write permission bit
ifexec    equ       1                   execute/search permission bit
.
ifbself   equ       1                   bias for self permission bits
ifbgroup  equ       8                   bias for group permission bits
ifbany    equ       040                 bias for anybody permission bits

which should help decode the directory entries. To 'extract' files I just list the on the terminal and save the output to a file.
 
What an interesting file! It looks like the on-disk structure is an ancient Unix derivative. It uses "inodes", which are a unixy concept (certainly were back in the late 70's). Also, the layout of the NOS inode resembles that of version 6 unix (I guess John Walker was not aware that the SUID bit (apperently called "ifasui" in NOS) was the only thing in Unix protected by a patent).

In his blog on the development of Autodesk, John Walker writes on 1 Jan 1990:
Ten years ago today, I was celebrating not just the dawn of the 1980's, which I hoped would be an improvement over the Souring Seventies, but also the first successful multi-user test, achieved minutes before midnight, of NOS/MT, the Unix-like operating system that seemed to be the future of Marinchip, my company at the time. What was to eventually become AutoCAD was, on that night, less than 2000 lines of undocumented code in an obscure language for an unpopular computer.
Perhaps there is more similarity between ancient Unix and NOS and this can help with figuring NOS out. The two key things to figure out would be the structure of the "superblock" and the structure of the page map entries in the inode (As an aside, the last sentence refers to Mike Riddle's Interact, which on that day apparently was 2000 lines of SPL code and to running on MDEX and the Marinchip M9900).

Also interesting, the "Before Autodesk" chapter of the blog (written in september 1981) discusses abandoning the 9900 (including 9995/99000) in favour of the 68000 for NOS/MT. Six months later, John's thoughts have refocussed on becoming a shrinkwrap application business:
I feel that at the present time it is possible to, albeit with high risk, start a software firm with the capital available from Marinchip Systems, and that this is the best possible deployment of that capital. No conceivable investment in the business of Marinchip has the probability of generating a comparable return. Unlike the hardware business, Marinchip Software Parteners will be in the middle tier of companies in its business, and will likely be in the front rank based on competence and professionalism.

Another take on NOS/MT comes from Dan Drake, John's business partner:
So that was the original Altair Bus that was picked up by Ed Godbout and those guys who codified it and made into the S100. [...] And so John had invented a way, found enough extra bits on the Bus to put a 16-bit processor on it, which was the Texas Instruments 9900. A very nice little machine with an enormous chip and very decent instruction set and no marketing. [...] He had written a simple operating system for it - not radically different than, say, CP/M or DOS, and then had to put together almost all of a much more sophisticated operating system for it, pretty much single-handed. And we were selling these things, small numbers of them.

All that time, Marinchip was a two man operation, run from John's house!
 
A clever hack for the original design and hardware I think. I believe it also switches the ROMs back on when you use the command that resets the character set - copies the original character data from the ROMs again.

For the ports of Cortex Basic that I've done, I removed the code that switches the ROMs back on. I don't run any software that overwrites the error messages, and I've put in two copies of the character set - one a 'working' copy plus a 'master' that gets copied over the working copy when you reset the characters. Loose a bit of memory, but not worried.

Still thinking about a Cortex Basic loaded from disk.

How about relocating 'TMPBUF' to the >F000 to >FFFF area? It seems to be a single define in the source that needs adjusting. If I understand correctly the original Cortex did not allocate RAM to the this area, just partially decoded I/O and the TMS9995 internal stuff. For instance, TMPBUF could be placed at >F200 to >F5FF. Similarly, a copy of the character map could be placed at >F600 to >F7FF, and this copy then used to restore the primary map as needed.

Wouldn't that be the cleanest solution for a disk Basic?
 
Still thinking about a Cortex Basic loaded from disk.

How about relocating 'TMPBUF' to the >F000 to >FFFF area? It seems to be a single define in the source that needs adjusting. If I understand correctly the original Cortex did not allocate RAM to the this area, just partially decoded I/O and the TMS9995 internal stuff. For instance, TMPBUF could be placed at >F200 to >F5FF. Similarly, a copy of the character map could be placed at >F600 to >F7FF, and this copy then used to restore the primary map as needed.

Wouldn't that be the cleanest solution for a disk Basic?

Originally the Cortex had everything from >F000 as memory mapped I/O (obviously the TMS9995 internal RAM took precedence). There was a modification to change this so that >F200+ became local RAM. This is where the V9938 extensions are loaded (CDOS).

Finally I believe the entire F000-FFFF is available as RAM either via the memory mapper or just with CKON - can't remember. Some NOS configurations make use of it. Here's a config file:

Code:
%
%          SP-MPE
%
%          10M winchester, 2*1M discdrives, 100K ramdisc
%          1*1M discdrive wd1002
%          1*56K user, TMS9902 term, Centronics print
%          870630  Base 05a00  Version 3.0
%          Must be used with CONFIG.NORMAL moved to CONFIG.MOD
%          - BEFORE WINCHESTER IS INITIALISED USE CONFIG.X -
%
%          Configuration parameter section
%
nprior    equ       10                  highest process priority
nusers    equ       1                   number of users on system
nintlv    equ       5                   number of interrupt levels used
nproc     equ       1                   max number of processes per user
bsize     equ       01000               system buffer pool size
dtbufl    equ       256                 data transfer buffer length
ticksc    equ       40                  clock ticks per second
slice     equ       13                  clock ticks per user time slice
psynct    equ       60                  periodic SYNC$ time in seconds
trmobuf   equ       3                   maximum output msgs backed up to term
trmibuf   equ       3                   maximum input msgs backed up to term
maxof     equ       10                  maximum open files per user
nblocks   equ       10                  number of file paging buffers
blockbsz  equ       256                 largest block size used (by any SU)
nmemi     equ       10                  number of memory Inodes
maxpar    equ       10                  maximum program parameters
scrmax    equ       3                   maximum SCRIPT$ file nesting
%
%          Configuration table section
%
. * Terminal pointers go here
          data      trm1
. * end
. * Storage unit pointers go here
          data      su1
          data      su2
          data      su3
          data      su4
          data      su5
. * end
. * Memory bank pointers go here
          data      mb1
          data      mb2
          data      mb3
. * end
. * Terminal control tables go here
trm1      data      trm902,trm1d,trm1ib,trm1ibe,trm1eb
          data      trm1ebe,illogin
          bss       chbss
trm1d     data      080                 cru software addr.
          byte      crsb2+crpenb+crlen7 9902 control reg.
          byte      01                  non int. send, check DTR
          data      9600                baud rate
          data      0                   onboard=0, offboard<>0
trm1ib    bss       80
trm1ibe   .
trm1eb    bss       20
trm1ebe   .
. * end
. * Real time clock table goes here
rtct*     data      rtc995,rtctd
rtctd     data      18750               25 ms / interupt
. * end
. * Clock/calendar table goes here
. * end
. * Storage unit tables go here
su1       data      256,1,22,23,500,wdwini,hdskt,1
          data      09b80,256,09b80 
          data      0,0,0
          bss       10
          bss       dinl
su4       data      256,1,2,3,96,wdwini,hdskt,2
          data      +(16*80*2),256,+(16*80*2)
          data      0,0,0
          bss       dinl
hdskt     data      0ff00               device addr
          data      cbuffh              buffer in common
          data      hrdut               unit table
          data      2                   units on controller
          bss       66
hrdut     data      hrdut1,hrdut2
hrdut1    byte      winch0+sec256+eccbit  unit select code
          byte      wsr35u              step rate code
          data      4                   # of heads
          data      256                 sector length
          data      32                  sectors / trk
          data      311                 trks / head
          data      0                   interlace tbl addr, 0 if none
hrdut2    byte      flppy0+sec256       unit select code
          byte      fsr3m               step rate code
          data      2                   # of heads
          data      256                 sector length
          data      16                  sectors / trk
          data      80                  trks / head
          data      hlct16              interlace tbl addr, 0 if none
.
su2       data      256,1,1,2,12,tmx909,dsk1t,1
          data      +(16*80)/2,256,+(16*80)/2
          data      0,0,0
          bss       10
          bss       dinl
su3       data      256,1,1,2,12,tmx909,dsk1t,2
          data      +(16*80)/2,256,+(16*80)/2
          data      0,0,0
          bss       10
          bss       dinl
dsk1t     data      0f140,001c0,dmabuf,d1ut,2
          bss       66
d1ut      data      d1ut1,d1ut2
d1ut1     byte      000                 =1 then test if two sides (8")
          byte      000                 step rates 0=A, 1=B
          byte      000                 ()
          byte      000                 drive size : 0=5" , 1=8"
          byte      000                 select bits : 00,01,02,03
          byte      001                 select bits : 01,02,04,08
          byte      001                 sides : 00=single,01=double
          byte      001                 density : 00=single,01=double
          data      128                 single density sector size (bytes)
          data      16                  sectors/track
          data      80                  tracks/side
          data      ilct16              interlace table,0=none,ilct16/26
d1ut2     byte      0,0,0,0,01,02,01,01
          data      128,16,80,ilct16
.
stepratea equ       3                   time / step in ms
headsetla equ       15                  head settling time in ms
headloada equ       50                  head load time in ms
steprateb equ       3                   time / step in ms
headsetlb equ       15                  head settling time in ms
headloadb equ       50                  head load time in ms
.
stepra*   equ       stepratea*2+1
headsa*   equ       headsetla*2+1
headla*   equ       headloada*2+1
steprb*   equ       steprateb*2+1
headsb*   equ       headsetlb*2+1
headlb*   equ       headloadb*2+1
.
su5       data      0,0,0,0,30,memfil,memf1t,1
          data      0,0,0,0,0,0
          bss       10
          bss       dinl
memf1t    data      m1ut1,2
m1ut1     data      mb2,mb3
. * end
. * User memory bank tables go here
mb1       data      0e000,enmb1,dsmb
mb2       data      0e000,enmb2,dsmb
mb3       data      0a000,enmb3,dsmb
. * end
. * Printer control tables go here
pr1       data      prcent,pr1t,0,0,0,0
          data      0,0,0,0
          data      3,68,3
          bss       pfbss
pr1t      data      0800                CRU address
          data      01                  on=0 , off<>0 (main board)
. * end
. * Printer offline access tables go here
off1      data      pr1,5,128
          bss       30
. * end
. * Background batch control tables go here
. * end
. * Special file name tables go here
          data      9,xsnsf1,0fe,pr1,spfprt
          data      9,xsnsf2,0fd,off1,spfapq
. * end
. * Special file names go here
xsnsf1    text      "PRINT.DEV"
xsnsf2    text      "PRINT.OFF"
. * end
. * Interrupt routines for level 1 go here
. * end
. * Interrupt routines for level 2 go here
          mov       r12,r5
          li        r12,01fda           point to MID flag
          tb        0                   MID ?
          jeq       midint              yes, go and crash system
          blwp      snap$               no, then it is an Arithmetic Overflow
          text      "Arithmetic Overflow.&"
          even
          jmp       finint2
midint
          blwp      snap$
          text      "\Macro Instruction Detect.  Illegal opcode.&"
          even
finint2
          mov       r5,r12
. * end
. * Interrupt routines for level 3 go here
          li        r2,rtc995
          mov       rtvint(r2),r1
          li        r7,rtct
          bl        *r1
. * end
. * Interrupt routines for level 4 go here
          mov       r12,r1
          clr       r12
          sbz       1                   turn off keyboard
          mov       r1,r12
.
          li        r2,trm902
          mov       cvint(r2),r1
          li        r7,trm1
          bl        *r1
.
          li        r7,pr1
          mov       pfdrvv(r7),r2
          mov       cvint(r2),r1
          bl        *r1
.
          li        r2,tmx909
          mov       bvint(r2),r1
          li        r7,dsk1t
          bl        *r1
.
          li        r2,wdwini
          mov       bvint(r2),r1
          li        r7,hdskt
          bl        *r1
. * end
%
%          Memory bank control section
%
. * Memory bank enable and disable routines go here
mapper    equ       0f100               memory mapper memory mapped addr.
map1start equ       060                 upper 8 bits of 20 bit addr.
map2start equ       070
.
sysmap*   ckof
          rt
sysdmap*  rt
.
enmb1*
          mov       membank1,membankwp+2*r3
          blwp      enable              get some wp of my own
          rt
enmb2*
          mov       membank2,membankwp+2*r3
          blwp      enable
          rt
enmb3*
          mov       membank3,membankwp+2*r3
          blwp      enable
          rt
.
enable    data      membankwp,enablepc
enablepc  c         r0,r3               is the mapper unchanged
          jeq       setmapon1           y, turn on the mapper
          mov       r3,r0
          li        r1,mapper           point to reg 0
          li        r2,16               do all registers
mb1loop
          movb      *r3+,*r1+           only 8 bits is enough
          inc       r1                  make sure it points to next mreg
          dec       r2                  have we done all mreg
          jne       mb1loop             no one more
setmapon1
          ckon                          let the mapper go !
          rtwp
.
dsmb*     ckof                          return to system
          rt
.
membank1  data      membank1map
membank2  data      membank2map
membank3  data      membank3map
membankwp data      0000                make r0 something <> membank1,2,3..
          bss       30                  give r1-r15 someplace
.
.                                       Mapper
.		                        Reg 
membank1map
          byte      00                  reg0  00000-00fff }
          byte      01                  reg1  01000-01fff }
          byte      02                  reg2  02000-02fff }
          byte      03                  reg3  03000-03fff }
          byte      04                  reg4  04000-04fff }
          byte      map1start+05        reg5  65000-65fff }
          byte      map1start+06        reg6  66000-66fff }
          byte      map1start+07        reg7  67000-67fff } user mem 56K
          byte      map1start+08        reg8  68000-68fff }
          byte      map1start+09        reg9  69000-69fff }
          byte      map1start+0a        regA  6a000-6afff }
          byte      map1start+0b        regB  6b000-6bfff }
          byte      map1start+0c        regC  6c000-6cfff }
          byte      map1start+0d        regD  6d000-6dfff }
          byte      0e                  regE  0e000-0efff   NOS common mem
          byte      0f                  regF  0f000-0ffff   memory mapped I/O
membank2map
          byte      map2start           reg0  70000-70fff }  
          byte      map2start+01        reg1  71000-71fff }
          byte      map2start+02        reg2  72000-72fff }
          byte      map2start+03        reg3  73000-73fff }
          byte      map2start+04        reg4  74000-74fff }
          byte      map2start+05        reg5  75000-75fff }
          byte      map2start+06        reg6  76000-76fff }
          byte      map2start+07        reg7  77000-77fff } ramdisc part 1 56K
          byte      map2start+08        reg8  78000-78fff }
          byte      map2start+09        reg9  79000-79fff }
          byte      map2start+0a        regA  7a000-7afff }
          byte      map2start+0b        regB  7b000-7bfff }
          byte      map2start+0c        regC  7c000-7cfff }
          byte      map2start+0d        regD  7d000-7dfff }
          byte      0e                  regE  0e000-0efff   NOS common mem
          byte      0f                  regF  0f000-0ffff   memory mapped I/O
membank3map
          byte      0f                  reg0  0f000-0ffff } top of internal ram
          byte      map1start+0e        reg1  6e000-61fff }
          byte      map1start+0f        reg2  6f000-62fff }
          byte      map2start+0e        reg3  7e000-7efff }
          byte      map2start+0f        reg4  7f000-7ffff } ramdisc part 2 40K
          byte      map1start           reg5  60000-60fff }
          byte      map1start+01        reg6  61000-61fff }
          byte      map1start+02        reg7  62000-62fff } 
          byte      map1start+03        reg8  63000-63fff }
          byte      map1start+04        reg9  64000-64fff }
          byte      0a                  regA  not used
          byte      0b                  regB  not used
          byte      0c                  regC  not used
          byte      0d                  regD  not used
          byte      0e                  regE  0e000-0efff   NOS common mem
          byte      0f                  regF  0f000-0ffff   memory mapped I/O
. * end

I think this is for a Cortex with an MPE 128K RAM card. It's clever how they use every last bit of RAM for the RAMDISC. What's not shown is that NOS itself resides >5000-EFFF.

Dave.
 
Last edited:
Still thinking about a Cortex Basic loaded from disk.

How about relocating 'TMPBUF' to the >F000 to >FFFF area? It seems to be a single define in the source that needs adjusting. If I understand correctly the original Cortex did not allocate RAM to the this area, just partially decoded I/O and the TMS9995 internal stuff. For instance, TMPBUF could be placed at >F200 to >F5FF. Similarly, a copy of the character map could be placed at >F600 to >F7FF, and this copy then used to restore the primary map as needed.

Wouldn't that be the cleanest solution for a disk Basic?

Would we be able to load disk Basic at >0000 so we can set/use the interrupt vectors?
 
Would we be able to load disk Basic at >0000 so we can set/use the interrupt vectors?

Yes, you would. I think I have not expressed myself well.

Here's where I'm coming from. I'm using your breadboard ROM with EVMBUG, BASIC and boot loaders for MDEX and Unix. It is now getting a bit full and I still would like to add stuff (a better EVMBUG, better boot loaders, FORTH, perhaps self test routines, a FAT disk library, NOS/MT loader, ... the dream list goes on). From there my thought was that perhaps the ROM should only contain the self test, a really good monitor and a way to load executables from the CF Card. Cortex Basic and Forth could then be loaded from disk as if they were copied from ROM. The operating systems could have their 1st stage boot loader as such an executable. One vision would be to have all these programs in a directory (say /BOOT) on the CF Card and the ROM could show a menu with all the executables that it finds in that directory. That setup would allow others to more easily add for instance a Geneve 9640 personality.

I'm probably getting way ahead of myself: time is limited.
 
The Cortex has a "RESET" and a "BREAK" button. On the Cortex II these appear to be located on the front, next to the LEDs. Not sure where they are on a Cortex I.

"RESET" seems to be what it says, a button to trigger a reset. Not sure whether this is always a 'cold' reset.
"BREAK" triggers an non-maskable interrupt. Not sure what it does, a 'warm' reset perhaps?

The ETI construction articles don't seem to discuss these buttons. The Cortex Basic manual only mentions the reset key once, as a way to regain control after the machine is caught up in an endless loop (endless loop on a single line, or 'escape' turned off).

How were these keys used in Basic and other software?
 
The Cortex has a "RESET" and a "BREAK" button. On the Cortex II these appear to be located on the front, next to the LEDs. Not sure where they are on a Cortex I.

"RESET" seems to be what it says, a button to trigger a reset. Not sure whether this is always a 'cold' reset.
"BREAK" triggers an non-maskable interrupt. Not sure what it does, a 'warm' reset perhaps?

The ETI construction articles don't seem to discuss these buttons. The Cortex Basic manual only mentions the reset key once, as a way to regain control after the machine is caught up in an endless loop (endless loop on a single line, or 'escape' turned off).

How were these keys used in Basic and other software?

RESET is a true cold start reset. Same as turning the computer on. However, with the memory mod that enables >F200 - >FFF9, this area is preserved because Cortex Basic doesn't initialise it.

BREAK (called WARM START on a Cortex I) causes an NMI interrupt. I think it's only used by Cortex Basic. MDEX has no interrupts whatsoever and pressing it under NOS causes a crash (no handler).

Under Cortex Basic, pressing WARM START essentially invokes the Monitor. Consider this:

Code:
loop  limi 0000
      jmp  loop

Obviously an extreme example but that would normally be game over! WARM START recovers this nicely. You can try it on the emulator.

On a Cortex I, these two buttons are located on the rear of the computer which makes them somewhat difficult to reach. Since you can't really see them, you soon learn which one is which! There's nothing more frustrating than typing in some code that locks up an then hitting RESET before you saved it...
 
I'm looking at the ROM code for extended commands in Cortex Basic, the "*" commands, i.e. file "extend.asm" in the set published by tms9995. It would seem to me that the routine is broken (the pointer in R8 does not get reset to its initial value when a compare fails and the algorithm moves on to the next name in the list). As far as I can tell it needs an extra MOV R10,R8 instruction between line 130 and 131.

However, in the newsletters I find no reference to a bug fix for this, and newsletter 11 (page 12) details an EPROM with a number of extended commands, so apparently the ROM code works okay as-is.

What am I missing?
 
I'm looking at the ROM code for extended commands in Cortex Basic, the "*" commands, i.e. file "extend.asm" in the set published by tms9995. It would seem to me that the routine is broken (the pointer in R8 does not get reset to its initial value when a compare fails and the algorithm moves on to the next name in the list). As far as I can tell it needs an extra MOV R10,R8 instruction between line 130 and 131.

However, in the newsletters I find no reference to a bug fix for this, and newsletter 11 (page 12) details an EPROM with a number of extended commands, so apparently the ROM code works okay as-is.

What am I missing?

You are correct, it doesn't work! However it is fixed in CDOS 1.20. It's transparent because the *PROG command appears to simply load the program "PROG" from Drive 0. However, prior to doing the disk load, it checks if the mapper is fitted and tries to find "PROG" in extended memory first.

Also take a look at Newsletter 5 Page 12 for a 'pre CDOS' version.

Dave.
 
Hello everyone, I'm Dexter from the AA forum. I've been reading this thread for a few days now, I'm at post #659 page 66. Some amazing stuff you've done, despite the Cortex is so rare. I'm interested in building a TMS9995 modular homebrew computer.

I ordered two TMS9995NL, two TMS9902NL and a few SN76489AN from UTSource. The TMS9995NL are most likely pulls, they are a bit scuffed / scratched, what I interpret as a good thing. On the other hand, they could be counterfeits, perhaps someone of you can determine?
 

Attachments

  • 9995.jpg
    9995.jpg
    97.6 KB · Views: 1
Hi Dexter. I haven't yet (personally) seen any genuine (I think) TMS99xx chips without (1) a clear 4-digit date code for the 80's or 90's and (2) a correct part number. So those you have would seem a little suspect to me due to no 4-digit date code. Having said that though, I've got a couple of Chinese clone chips and they all seem to work ...
 
I've been reading this thread for a few days now, I'm at post #659 page 66.
Indeed, when I first found this thread I too was reading for days. It simply is a tantalizing read.

I'm interested in building a TMS9995 modular homebrew computer.
It is not modular, but I'm doing a eurocard version of the Cortex (keep reading the thread, it shows up at page 78 or so). I can send you a bare PCB if that is any help (or the design files if that is what you need). Alternatively, Stuart's breadboard is a great way to get going and test parts: just wire up the 9995 and a ROM, run the test routines and a logic tester or scope will tell you if the part is working or not. Last but not least, MPE did a series of modular boards back in the day, I think you have already come across these in page 1 to 66.

I ordered two TMS9995NL, two TMS9902NL and a few SN76489AN from UTSource. The TMS9995NL are most likely pulls, they are a bit scuffed / scratched, what I interpret as a good thing. On the other hand, they could be counterfeits, perhaps someone of you can determine?
I have no personal experience with UTSource but I have read mixed opinions about them. My TMS9995's come from G&C superstore. These parts look like NOS, although I suspect they are very nicely refurbished pulls.

The TMS9995 is a very nice part. Without wait-states it runs about as fast as a PDP11/40. Sometimes I wonder what would have happened if TI had released this part in 1977 instead of 1980.
 
Hello,

It seems I have the same delay as other newcomers, before my messages arrive on the board. So we have to communicate with a time shift. :)

Hi Dexter. I haven't yet (personally) seen any genuine (I think) TMS99xx chips without (1) a clear 4-digit date code for the 80's or 90's and (2) a correct part number. So those you have would seem a little suspect to me due to no 4-digit date code. Having said that though, I've got a couple of Chinese clone chips and they all seem to work ...
So there might still be a chance that they work.

I already build two single board computers, MARC-1 and MARC-2, based on 6502 and 65816. MARC-3 also would have been 65816 based, but modular, with a back plane and sort of an S-100 bus. I already build the back plane, but changed the design of the cards to match it to the TMS9995.

The first card will contain the TMS9995 CPU and a XC95108 CPLD. All lines of the CPU are on the expansion connector and on the CPLD. The rest of the CPLD I/O lines are connected to the expansion port. This way I can add more complexety to my computer as I go.

The second card will contain a 512KiB 55ns Aliance SRAM with an ATMega1284P connected to all lines of the SRAM. This way I can copy the firmware into the SRAM during RESET. Developing new software will also be very quick.

The third card will have some I/O like the F18A, SN76489 (TI99 sound chip) and my favorite DUART SC26C92.

While learning and programming on the TI-99/4A, I enjoyed the 9900 assembly language so much, that I wanted it on my home build computer. Your site gave me the last push to change from the 65816 to the 9995, because it had the schematic I need.

It is not modular, but I'm doing a eurocard version of the Cortex (keep reading the thread, it shows up at page 78 or so). I can send you a bare PCB if that is any help (or the design files if that is what you need).
Thanks for the offer, but I hope I won’t need a PCB. I did get a schematic from you on the AA forum, “Mini Cortex TI990/6 Rev. 1.0 2/23/2015”. However, more info / schematics are certainly welcome. I’m eager to study them.



Alternatively, Stuart's breadboard is a great way to get going and test parts: just wire up the 9995 and a ROM, run the test routines and a logic tester or scope will tell you if the part is working or not.
That’s probably the fastest way to get those 9995’s tested. I’ll set this up these days and report weather they’re working or not. Which test routines are you referring to? I could program something myself, and wiggle some address lines, but if there is some test program for just the CPU and ROM.


I have no personal experience with UTSource but I have read mixed opinions about them. My TMS9995's come from G&C superstore. These parts look like NOS, although I suspect they are very nicely refurbished pulls.
UTSource never disappointed me, this would be the first time. At least it’s good to know an alternative source for these parts, if the ones I have don’t work.

The TMS9995 is a very nice part. Without wait-states it runs about as fast as a PDP11/40.
Yes, I’m very excited to see my computer run with this CPU, I hope it will run on 16Mhz eventually.
 
I read the whole thread. Phew!

Meanwhile, I wrote a little test program to toggle the 9th and 10th address lines, put the 9995 with the program on EPROM on breadboard, and could confirm that CLKOUT puts out 1/4 of the clock signal. After a reset, the address lines toggled happy on my old scope. :)

I tried 4, 8, 12 and 16MHz crystals successfully.

So it seems the CPU's are working. But I'm still not sure about quality and durability.
If there is someone here who would want to part one or two TMS9995NL's, I'd be more confident. The two sources mentioned in this thread aren't available anymore. :(
 
Somewhere in the first half of 2014 someone (might have been Jim Hearne) posted a link, or otherwise put me in the direction of a 99000 series design handbook (I don't mean the datasheet). I cannot find that link or reference anymore, nor can I find it on my drive. Does this ring a bell with anyone?
 
Somewhere in the first half of 2014 someone (might have been Jim Hearne) posted a link, or otherwise put me in the direction of a 99000 series design handbook (I don't mean the datasheet). I cannot find that link or reference anymore, nor can I find it on my drive. Does this ring a bell with anyone?

This TI Designers Handbook has a TMS99000 section in it:

http://www.quantums.info/cortex/TI Microsystems Designers Handbook 2nd edition.pdf

Hopefully it's what you were thinking of?
 
Back
Top