• Please review our updated Terms and Rules here

Powertran Cortex

Following a very busy second half of 2014 it looks like I may have some time early in 2015 to resume my "ancient Unix on Cortex class hardware" project. First a quick stock take of where it is at:

- Al Beard open sourced his C compiler for the geneve and it now lives on in the WHTech archive
- The Ritchie C compiler was ported to the 9995 and works well enough to compile significant software
- The 1983 edition of Xinu for the PDP-11 was ported and runs on Stuart's 9995 bread board
- A Unix V6 user land runs on a 9995 emulator, with the OS calls handled by the emulator direct
- Stuart's bread board was enhanced with a CF card interface
- MDEX was ported to the enhanced bread board

For reference see:
The software repository
The bread board schematics (warning: 4MB scan)
A picture of the bread board
A screen shot of MDEX running

I'm pondering where to go next. The breadboard hardware could probably use simple memory mapping hardware, using the 7 spare lines of the LS259. I think with two more TTL chips I can create a design with 8 pages of 60KB each and the top 4KB always mapped to page 0. With the kernel running on page 0, that leaves room for 7 processes without swapping. I think this may work for porting the MDEX successor NOS as well, assuming that it has survived.

On the software side, the LSX Unix kernel already compiles (but not sure if there are compiler bugs remaining). I'm a bit hesitant to debug that kernel on the real hardware, probably should try that on emulated hardware first. I have thought about adding write protect to the first and last 4KB, but I don't see a simple way to do it.

Perhaps I should move the hardware to a PCB first. Jim, I noticed the MPE CPU-E manual on your site. The MPE E_BUS 9995 board looks like a nice start, and not a million miles away from what I ended up with on the breadboard. Do you have that MPE board? Perhaps a few hires photo's to have a baseline understanding of component placement and routing?

The chip count of my breadboard design could probably be significantly reduced by using one or two GAL's, I noticed that Reichelt still stocks a 24 pin DIP GAL, but getting it programmed may be a hurdle that increases build complexity rather than reducing it; for sure I don't have a GAL programmer and have no GAL know-how.

Also thinking ahead about building a small 99105 based system, to get the separate I/D address space and the supervisor/user modes, so that a process crashing doesn't bring down the whole system. Anybody working on/with 99105 based designs?

All creative thoughts and support welcome.
 
pnr said:
Following a very busy second half of 2014 it looks like I may have some time early in 2015 to resume my "ancient Unix on Cortex class hardware" project. First a quick stock take of where it is at:

- Al Beard open sourced his C compiler for the geneve and it now lives on in the WHTech archive
- The Ritchie C compiler was ported to the 9995 and works well enough to compile significant software
- The 1983 edition of Xinu for the PDP-11 was ported and runs on Stuart's 9995 bread board
- A Unix V6 user land runs on a 9995 emulator, with the OS calls handled by the emulator direct
- Stuart's bread board was enhanced with a CF card interface
- MDEX was ported to the enhanced bread board

For reference see:
The software repository
The bread board schematics (warning: 4MB scan)
A picture of the bread board
A screen shot of MDEX running

I'm pondering where to go next. The breadboard hardware could probably use simple memory mapping hardware, using the 7 spare lines of the LS259. I think with two more TTL chips I can create a design with 8 pages of 60KB each and the top 4KB always mapped to page 0. With the kernel running on page 0, that leaves room for 7 processes without swapping. I think this may work for porting the MDEX successor NOS as well, assuming that it has survived.

On the software side, the LSX Unix kernel already compiles (but not sure if there are compiler bugs remaining). I'm a bit hesitant to debug that kernel on the real hardware, probably should try that on emulated hardware first. I have thought about adding write protect to the first and last 4KB, but I don't see a simple way to do it.

Perhaps I should move the hardware to a PCB first. Jim, I noticed the MPE CPU-E manual on your site. The MPE E_BUS 9995 board looks like a nice start, and not a million miles away from what I ended up with on the breadboard. Do you have that MPE board? Perhaps a few hires photo's to have a baseline understanding of component placement and routing?

The chip count of my breadboard design could probably be significantly reduced by using one or two GAL's, I noticed that Reichelt still stocks a 24 pin DIP GAL, but getting it programmed may be a hurdle that increases build complexity rather than reducing it; for sure I don't have a GAL programmer and have no GAL know-how.

Also thinking ahead about building a small 99105 based system, to get the separate I/D address space and the supervisor/user modes, so that a process crashing doesn't bring down the whole system. Anybody working on/with 99105 based designs?

All creative thoughts and support welcome.
Click to expand...

Good to hear from you Paul!

I have one unread email in my gmail inbox. It's from you in April concerning the c compiler port for the Cortex. It's been one of those years and not sure it's easing up in 2015. I will get to it eventually I hope!

I do have a fantasy about getting my emulator running on a Raspberry Pi and creating an E-Bus interface for it via the SPI interface. It's good to dream...

Dave.
 
Greetings, and Happy New Year to one and all. My resolution for this year is to understand what one can actually do with all this stuff that Paul has been doing. ;-)

I got an e-mail yesterday from a chap called Alex Cameron in Australia who has set up a website for stuff he done 25 years ago ... including a TMS99105 SBC. Details, including schematics, on his website: http://www.itech.net.au/tms9900.

I think Jim H was working on a TMS99105 design as well, but I think the PCB for that is currently around 6 feet square from all the features he was trying to include. ;-)

Stuart.
 
Thanks for the info!

I noticed that photo's of the MPE CPU board are already posted in message #462 of this thread. I think I might try my hand at the ExpressPCB schematics and layout software over the coming months.

Currently busy finalising the LSX Unix port (on the breadboard simulator) -- good progress, it might actually run during the course of this week. Considering the experience built up with the XINU and MDEX ports, moving to the real hardware should not be a stretch. Porting to a real Cortex should also be straightforward from there.
 
Gentlemen,

I'm happy to report that LSX Unix now runs on the breadboard simulator. Next step is the real hardware. Attached is a screenshot of a sample run.

In essence the LSX kernel runs in the first 16 kB, and the other ram is available for user programs. A user program calls into the kernel via a XOP 1 instruction. There is always only one program in memory and the other processes are swapped out to disk. There are 3 processes max.

This memo http://www.60bits.net/msu/mycomp/terak/termubel.htm by Hans Lycklama (the guy who cut down Unix version 6 to the LSX and Mini versions back in the mid 70's) describes the capabilities versus Unix version 6. The little kernel is less performant, but runs most userland programs unchanged.

My current compilation does not quite fit in 16 kB, it needs about 17kB. Perhaps I need to do more work on the compiler's optimiser, perhaps the code density of the 990 is just a bit less. Note that this sizes are inclusive of data areas and buffers, the actual kernel code is only 11 kB.

Paul

And here is a link for a proper screenshot
 

Attachments

  • Screen Shot 2015-01-14 at 20.07.50 .jpg
    Screen Shot 2015-01-14 at 20.07.50 .jpg
    8.6 KB · Views: 2
Last edited:
Nice work! We could probably port this over to a Geneve 9640 too--it uses a memory mapper to give it access to up to 2M of memory on a 9995-based machine.
 
Ksarul said:
Nice work! We could probably port this over to a Geneve 9640 too--it uses a memory mapper to give it access to up to 2M of memory on a 9995-based machine.
Click to expand...

Yes, that would be a cool project. If you know the Geneve 9640 hardware and its drivers well, it should be an easy project to do. Lot's of overlap with the Cortex that also uses a '612 mapper chip. Let me know if you need any pointers on how to get started with the code.

Actually, my build of Stuart's breadboard has a 512KB RAM chip and I think it would not be very hard to make a version of LSX that keeps 7 processes in mapped RAM, with the 8th slot for the kernel. Note that adding mapped memory makes for a fairly straightforward road from LSX, via Mini to full V6:
- LSX was designed to run with 40KB RAM and two 256KB floppies (kernel 10KB, ~3.600 sloc)
- Mini was designed to run with 56KB RAM and 5MB harddisk (kernel 18KB, ~6.500 sloc)
- V6 was designed to run with 256KB RAM and 5...40MB harddisk (kernel 28KB, ~10.000 sloc)
All versions can use essentially the same set of userland programs.
 
ClassicHasClass said:
Where did you find the LSX source code? All I can find are binaries.
Click to expand...

The original source files are in the Unix Tree at the The Unix Heritage Society:
http://minnie.tuhs.org/cgi-bin/utree.pl
or more specifically:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX

Leonid Broukhis did a lot of work making the stuff usable for the BKUNIX project. This you find here:
http://sourceforge.net/p/bkunix/code/HEAD/tree/trunk/

My repo with the port from the PDP-11 to the 9995 is here:
http://1587660.websites.xs4all.nl/cgi-bin/9995/doc/tip/doc/index.wiki
Note that the cover page is a bit out of date.
 
ClassicHasClass said:
That's very cool. Too bad my Tomy Tutor will probably never run this without substantial hardware modification, eh, Jim (Ksarul)?
Click to expand...

From this link:
http://www.floodgap.com/retrobits/tomy/hardware.html
it would seem that the standard hardware allows for both roms to be mapped out completely. This then leaves 0x0000-0x0e000 available for ram chips on the expansion port. You would have to build an expansion cartridge with a 64KB RAM chip and the CF Card and you would be good to go, no modification of the Tomy console needed.

I cannot find full schematics for the Tutor on the web, so it is hard to be sure.
 
pnr said:
From this link:
http://www.floodgap.com/retrobits/tomy/hardware.html
it would seem that the standard hardware allows for both roms to be mapped out completely. This then leaves 0x0000-0x0e000 available for ram chips on the expansion port. You would have to build an expansion cartridge with a 64KB RAM chip and the CF Card and you would be good to go, no modification of the Tomy console needed.

I cannot find full schematics for the Tutor on the web, so it is hard to be sure.
Click to expand...

Ironically, as it happens, that's my web page on the Tutor ...

Anyway, I meant without additional hardware. I don't know if both ROMs could be mapped out in that fashion, although it does appear like it should work. I've tried to think of ways to get a PEB connected to a Tutor (Tomy even considered making such a device) but I've never been willing to risk a PEB and a Tutor on what could be an ugly failure.
 
I did find a site with somewhat complete schematics for the Japanese version of the Tutor--the Pyuuta. The site also has schematics for the Pyuuta Jr.

http://www43.tok2.com/home/cmpslv/Pyuuta/EnrPt.htm

The hardest part of using a TI PEB with the Tutor would be that you'd have to design all of the cards for it pretty much from scratch, as the Device Support Routines (DSRs) for the TI are in the wrong address space. . .the Flex Cable Interface would work though--once you built a Tomy adapter. . .I may just have to try that experiment once I finish making some Tutor cartridge boards.
 
Gentlemen,

I am happy to report that Stuart's breadboard system now runs Unix (screenshot). I was concerned that it would run slow as molasses in winter (in Siberia), but actually it runs about as fast as I remember from the early 80's (a PDP11/40 with a handful of users logged on). This is with the auto wait state, with that disabled it is even better -- but unfortunately my breadboard isn't 100% stable without that wait state.

The screenshot show a small "Hello, world!" assembly program being assembled and run, and a one-line shell script being created and run. The date command shows the system clock running. I remain amazed how similar this 40 year old code is to today's Posix command line.

There is more work to do, there always is. I have not ported "signals" yet, need to think a little bit about how to handle multiple workspaces. The C compiler needs to be back ported to native; this involves completing the work on floating point. Other than that it is pretty much a complete port of LSX.

I think some hardware work may be next, but probably I will not get around to that until late March. I imagine that there are zero "rebuilders" of this project, but if there are I may need to redo the CF card interface to use a standard CF->IDE converter board (my current CF breakout board is arguably harder to find than a 9995).

Paul
 
Actually, there might be a couple of folks who'd want to build one of these. There was an individual on AtariAge that wanted to build a 9995 single-board computer this past week and was looking for folks to chime in on his development project. Right now he's looking at a possible update to the Cortex, but the breadboard project may be a good fit too.
 
You must log in or register to reply here.
Back
Top