• Please review our updated Terms and Rules here

Powertran Cortex

Many thanks, Tony! I was beginning to think this document was lost in the mists of time!
 
Hello all,

Background

About a month ago I came across this thread and I have read it with much interest. I had never heard of the Cortex before reading this thread, but I do own a 99/4a. I powered it up about two years ago and was overjoyed to see it still work. Back in the day I had expanded it with 32K RAM on the 16 bit bus, and built an EPROM programmer and a 5.25" floppy disk driver for it, both from scratch. 30 years ago I wanted to put a mini unix on it, but that never materialised. That dream kept itching and was the driver for reviving the 99/4a. However, including an old telly it is too big a setup to be practical. Still, a 9900 plus 64K RAM should be enough to run Xinu and LSX unix. With a MMU and 256K it should be enough for Version 6 ("Lion's") unix. A 99105 or 99110 (having separate I/D spaces) should be enough for Version 7 and perhaps even BSD 2.11.

Via Dave's website I discovered the Cortex, Marinchip and the MDEX software. What an interesting read. By the way, Dave, your site lacks the general MDEX manual, but it is available on Jim Hearn's pages. Perhaps a forgotten item? Very impressed with the Cortex emulator by the way.

All in all, a Cortex with the disk hardware installed should be able to run LSX unix. This may sound unrealistic, but some Russian hackers have it running on a BK0010, a Russian home computer from the 1980's that uses a single chip PDP11 derivative as its CPU, and has 48K RAM. The software repo for it is over on Sourceforge.

I have no intention of building or owning a Cortex, but Stuart's breadboard projects look like a practical start to get my 30 year old project speeded up a bit.

Hardware

Stuart, thank you for these captivating designs and excellent web pages. You are getting quite a following: http://www.vaxman.de/projects/tms99xx/

I've just build the 9995 breadboard and it works like a charm. The CPU and UART came from G&C supermarket at eBay, which sells them for 7 and 3 euro respectively, free shipping via mail. The parts arrived after 19 and 28 days and turned out to be genuine. By mistake I ordered a 9902 instead of a 9902A, but it still works. I compared the datasheets and saw no obvious differences. Does anybody know the difference between the two?

I left out the MAX232 level shifter and hooked up the 9902 to a FTDI232 chip right away, using the Elektor/Circuit Cellar breakout board. http://www.elektor.com/magazines/2011/september/ft232r-usb-serial-bridge-bob.1912360.lynkx
This way I can use the USB port as a power source and the system becomes a handy A5 sized USB peripheral. I also changed the LS04 to a LS14 (hex inverting schmitt-trigger) and used two inverters to make a (power-on) reset circuit. I have found that the LS138 is not actually needed: if one connects an inverted /MEMEN signal to the 9902 chip select it works equally well. Other adaptations are the use of an EEPROM and a 512K RAM chip. What results is a 6 chip fully functional computer (CPU, UART, RAM, ROM, LS14 and LS32).

Somebody suggested that the ROM should be bankable and that writes could always go to the RAM. I haven't tried this yet, but I think the following should work: if the RAM chip select is hooked up to /MEMEN it covers the full 64K. Its output enable becomes the OR of /DBIN and the inverted /ROM_CE. That latter becomes the OR of the original /ROM_CE and a new signal MAP. When MAP is low, the lower 32K are read from ROM, when MAP is high the ROM is disabled resulting in 64K of RAM.

Another modification I would like to try is adding the single stepping hardware. I think the Cortex circuit for this could work: decoding the external instructions with a LS138 and generating a /NMI signal with three flip-flops (two LS74's). The CKON/CKOFF instructions and the fourth flip-flop could be used to generate the MAP signal for above bank switching. This would take it from a 6 chip system to a 9 chip system, but still fitting on two strips of breadboard.

For disk I'm thinking about a microcontroller hooked up to an SD memory card, but that is for another day. Also for another day is building the 99105/99110 project.

Questions:
- any suggestions?
- connecting READY to /RESET should eliminate the automatic wait state. Has anybody done the recalculation work for the baud rate table?
- the only 99xxx I can find is a 50 euro part sold by 'timeline' on eBay, a UK source. Is that a known good source? Are there better alternatives?
- what is the best way to get software downloaded? 'Typing' a file from the terminal emulator to the breadboard seems a good way, but currently this overflows; I guess I need to hook up the hardware flow control signals.

Software

With convenient hardware now almost sorted, the next step is getting a good 9900 C compiler. This is what I lacked 30 years ago and I am still not there yet. These are the options I'm aware of:

- Clint Pulley's C99 for the 99/4a. This one is too limited for my purposes.

- Allan Beard's TI-C for the Geneve 9640. This one is based on Matthew Brandt's compiler for the 68K which is open source. A compiled version of TI-C for the 9640 is on whtech, but alas no sources. I'm trying to locate Allan Beard, but have not found him yet.

- Port the original Ritchie C compiler from PDP-11 to 9900. This is my current preferred route. With the 9900 similar to the PDP-11 in philosophy this should be feasible. I ported the version 6 compiler to modern C some 4 years ago (and the BK0010 project has done the BSD2.11 compiler). Already ported the assembler to 9900.

- Dave Pitt's GCC port. I couldn't get this to work out of the box and using GCC kinda kills the 'retro' attraction for me, as it could never run natively on a 16 bit machine.

Did the Cortex ever have a C compiler? Any other suggestions?

Thanks everybody for the wonderful preservation work!

Paul

Did everybody else only just get (on the 2nd) notification of this post ?
I'm sure it wasn't there on the 30th that it's dated.

Jim
 
Did everybody else only just get (on the 2nd) notification of this post ?
I'm sure it wasn't there on the 30th that it's dated.

Jim

Yep, got the email notification last night. This is the same situation as Norvin. How very strange. It's bad enough that the notification is delayed but I can't think why the message doesn't get posted and when it does, it's in the past so you don't think to look back. Definitely seems like some sort of quarantine.

Anyway, hi Paul! Welcome to the Forum.

As far as the C compiler goes, this is one thing that's been on my list for a long time but not jumped in to anything. I've considered Dave Pitt's GCC as he's pretty thorough with his work and gives exceptional support. However, this would be a case of generating the code on a PC and then downloading to the Cortex, which just doesn't feel right! Small C looks like a possibility. It would have some compromises but should be 'good enough' for the Cortex but probably not for your Unix project.

For what it's worth, MDEX and SPL provide a reasonable OS with a C-style(ish) programming environment. By the way, what MDEX manual is missing?

Thanks for the kind words about my emulator. Are you using the new one (version 2.0)? I only recently put it up on the site but haven't told anyone on here yet...

Dave.
 
has anyone considered implementing the whole of the cortex in an FPGA?

Hi Tony,

Great to see you back on here! It's been a while!

I have toyed with the idea of an FPGA Cortex but it's such a steep learning curve plus very difficult for the home constructor to build. We're not talking wire-wrap here! Also not sure what use it would be. It would really be a hardware version of the Emulator but with the possibility of an E-BUS. Here's an idea, how about the emulator coupled to a USB E-BUS module!

Dave.
 
Yep, got the email notification last night. This is the same situation as Norvin. How very strange. It's bad enough that the notification is delayed but I can't think why the message doesn't get posted and when it does, it's in the past so you don't think to look back. Definitely seems like some sort of quarantine.

Anyway, hi Paul! Welcome to the Forum.

As far as the C compiler goes, this is one thing that's been on my list for a long time but not jumped in to anything. I've considered Dave Pitt's GCC as he's pretty thorough with his work and gives exceptional support. However, this would be a case of generating the code on a PC and then downloading to the Cortex, which just doesn't feel right! Small C looks like a possibility. It would have some compromises but should be 'good enough' for the Cortex but probably not for your Unix project.

For what it's worth, MDEX and SPL provide a reasonable OS with a C-style(ish) programming environment. By the way, what MDEX manual is missing?

Thanks for the kind words about my emulator. Are you using the new one (version 2.0)? I only recently put it up on the site but haven't told anyone on here yet...

Dave.

Paul said by PM that once he posted he was taken to a screen saying his posting was pending moderation.
So maybe it's taking 3 days before a moderator approves it ?.
Still a bit silly about the date being 3 days old so you never see the new posting.

Jim
 
Paul said by PM that once he posted he was taken to a screen saying his posting was pending moderation.
So maybe it's taking 3 days before a moderator approves it ?.
Still a bit silly about the date being 3 days old so you never see the new posting.

The moderators just confirmed that the "first few" posts of each new member are moderated and that they had been backlogged a bit. After the "first few" one becomes trusted and can post without moderation. I did not sound as if the moderators for this area of the forum could change that.

Paul
 
Are you using the new one (version 2.0)? I only recently put it up on the site but haven't told anyone on here yet...

Yes, I am.

For what it's worth, MDEX and SPL provide a reasonable OS with a C-style(ish) programming environment.

Yes, I had a look at those. Found some interesting FP routines that I couldn't quite understand from disassembly -- contacted Mike Riddle and he thinks he still has 8" disks with the source to SPL. Apparently he has some 8" hardware too. Still, porting a compiler to a new machine is less work than porting an entire OS to a new language.

By the way, what MDEX manual is missing?

The 'general' one, that describes the shell and all:
http://www.quantums.info/cortex/MPE...Disc Executive User Guide For Release 3.1.pdf

I'll do a separate post on the C compiler.

Paul
 
Small C looks like a possibility. It would have some compromises but should be 'good enough' for the Cortex but probably not for your Unix project.

There is a "PC version" of small C on whtech that compiles with GCC. You could put its output through the MDEX assembler/linker and get a Cortex binary that way. Biggest job would be to port the runtime to MDEX. Small C compiles itself, so from there you would be close to a MDEX native small C compiler.

Yesterday found the current street address for Alan Beard (author of TI-C), and I've sent a (snail mail) letter of to him today. We'll see.

In the mean time I'll keep plodding along and try to find a good way to push assembler output onto the breadboard. It seems that a 9902 is a RS232-C chip and in that protocol the computer (DTE) can't actually slow down the modem/printer device (DCE), only the other way around is handshaked. Perhaps a low baud rate is the solution.

Paul
 
Hi Tony,

Great to see you back on here! It's been a while!

I have toyed with the idea of an FPGA Cortex but it's such a steep learning curve plus very difficult for the home constructor to build. We're not talking wire-wrap here! Also not sure what use it would be. It would really be a hardware version of the Emulator but with the possibility of an E-BUS. Here's an idea, how about the emulator coupled to a USB E-BUS module!

Dave.


I've recently been using this http://www.xess.com/shop/product/xula2-lx25/ (they also do a cheaper version the LX9 with a slightly smaller FPGA) with enough internal block ram to implement the 64KByte and 16KByte cortex memories inside the FPGA, it also has a SDRAM if there is a better use for the block rams.

I've implemented a 9900 derivative CPU in VHDL before but I dont have access to it any more, shouldnt take much effort for me to implement a 9995 from scratch though.

Another oddball thought that came to me was to run the emulator on a raspberry pi to produce a cheap,tiny cortex.

The XuLA2-25 and XuLA2-9 FPGA modules are worth keeping in mind for other projects that might come up, the hardware is also open source. I'm not connected with the company at all btw
 
Hi Paul,

I've embedded a few comments in your message below.

"By mistake I ordered a 9902 instead of a 9902A, but it still works. I compared the datasheets and saw no obvious differences. Does anybody know the difference between the two?"

{Stuart} Functionally I think they're the same, but according to the datasheets, the -A version has a lower power consumption than the non-A version. So perhaps the -A had an internal redesign or something.


"I left out the MAX232 level shifter and hooked up the 9902 to a FTDI232 chip right away, using the Elektor/Circuit Cellar breakout board. This way I can use the USB port as a power source and the system becomes a handy A5 sized USB peripheral."

{Stuart} Great idea! I see that you can get little FTDI232 serial-USB adaptor modules cheap off eBay. ;-)


"Somebody suggested that the ROM should be bankable and that writes could always go to the RAM. I haven't tried this yet, but I think the following should work: if the RAM chip select is hooked up to /MEMEN it covers the full 64K. Its output enable becomes the OR of /DBIN and the inverted /ROM_CE. That latter becomes the OR of the original /ROM_CE and a new signal MAP. When MAP is low, the lower 32K are read from ROM, when MAP is high the ROM is disabled resulting in 64K of RAM."

{Stuart} Sounds good. You're probably aware that the Cortex does something similar - RAM shadows the ROM. At power on, the code steps through and reads each ROM memory location and writes back the same value, with the writes going into RAM. Then disable the ROMs so both reads and writes are made to RAM and carry on executing the boot code.


"For disk I'm thinking about a microcontroller hooked up to an SD memory card."

{Stuart} Be interested in seeing your design for this when you do it. I've got an IDE interface hooked up to one of my other systems.


"connecting READY to /RESET should eliminate the automatic wait state"

{Stuart} The 9995 data manual shows a gate of a 7407 connected between /RESET and READY to achieve this.


"Has anybody done the recalculation work for the baud rate table?"

{Stuart} Not that I'm aware of. What I've done before though is get the micro to continually send a short text string as it increments and prints the baud rate value. When you see the text string correctly, read the baud rate.


"the only 99xxx I can find is a 50 euro part sold by 'timeline' on eBay, a UK source. Is that a known good source? Are there better alternatives?"

{Stuart} Cheaper 99105s are also listed by eBay seller "hkutsource". One has been sold and received positive feedback, but the feedback might have been left before the chip was actually used. A couple of us know from experience that the TMS9909s sold by that seller are fakes, so be aware. Make sure you can return it for a refund if necessary.


"what is the best way to get software downloaded? 'Typing' a file from the terminal emulator to the breadboard seems a good way, but currently this overflows; I guess I need to hook up the hardware flow control signals."

{Stuart} For my TM990 system, I've written a small VB5 (don't laugh!) program that sends code to a TeraTerm app which sends it to the board over RS-232. The VB5 app includes a delay loop to limit the download speed to a value that the board can handle. It can also extract the bytes from tagged object code files and hex dumps. Be interested to see if you get hardware flow control working. The flow control on the 9902 seems to be arranged for controlling whether the 9902 is clear to send, rather than receive (based on the idea I guess that the 99xx was faster than any peripheral device that you might connect it to). Any flow control would have to be handled by the processor and while it's doing this - whoops! - there's another byte you've missed. ;-)


"With convenient hardware now almost sorted, the next step is getting a good 9900 C compiler. This is what I lacked 30 years ago and I am still not there yet. These are the options I'm aware of:"

{Stuart} Look at this thread for another GCC port: {http://atariage.com/forums/topic/164295-gcc-for-the-ti/}. Might be interesting.
 
Back
Top