• Please review our updated Terms and Rules here

Powertran Cortex

As to the wiring changes, when doing the schematic and PCB I was confused over the numbering of the '612 pins (I forgot that TI numbers in reverse order, also on 74-series chips). Also tying the unused mapper lines together is not the best practice, although it doesn't hurt. The fix is:
- Separate pin 12, 29, 30 and 31.
- Cut wire from pin 14 of the mapper to pin 28 of the RAM
- Add a wire from pin 24 on the mapper to pin 28 of the RAM
- Add a wire from pin 7 on the mapper to pin 31 on the mapper

74LS612 chips get quite hot (I guess they are run at high currents to get minimal delay times with the chip technology of the time). Personally I prefer 74HCT612 chips that draw only a fraction of the power.

Attached is the current programming info for the GAL (added .txt to get the forum to accept it).



  • cortex.eqn.txt
    1.1 KB · Views: 1

Didn't we conclude that there was a problem using the 74LS612 mapper chip, and it needs to be the HCT version?

Yes and no.

There was an issue with the "write protect" bit, that was resolved by a GAL change.

The last bit of the mapped address is used to block writes. If page F is write protected the mapper itself gets write protected as well (this was a poor design decision that needs change on a rev. 2 mini cortex). When setting the write protect bit for page F it stores through and cuts the write short, leading to faulty writes. Also, LS612 mapper outputs can go through random states before settling, putting noise on the write protection line. The HCT612 seems much more well-behaved and the issues do not arise.

The solution for a LS612 is to make the write protection dependent on being in "user mode" (GAL change) and modifying the write protect bits only when the mapper is not enabled (Unix change).

We worked on this almost exactly a year ago. Maybe my memory is fading, but the above is what I recall it was.
Paul, Stuart,
Good to know these comments. I only have 74LS612 chips, so I am going to try out with those on the mini Cortex.

My FPGA design does not currently implemented the write protect bit, I used the highest bit for chip select between FLASH and RAM. I also made it so that when the 74LS612 "equivalent" circuit in the FPGA is being addressed (i.e. the "chip select" is active), the mapper itself goes into passthrough mode. I did that originally to keep the design small and to prevent the VHDL code generator from having to make the page registers dual ported, i.e. the address lines of the page registers come either from the low order address lines or high order address lines, not both.
By the way, about a week ago I debugged the generation of READY signal to get the circuit running at zero wait states. That works also for the Flash memory, despite it being a 120ns part running at under voltage. Maybe I have been just lucky there. When I have time I will measure with the scope the page translation delay.

I am glad to report that the Mini Cortex works! Amazingly it worked the first I powered it up with all components mounted. I am using a 64K (E)EPROM, so I needed to fiddle a little on how the memory layout needs to look like to make it look as a 32K ROM for the Cortex CPU. Not difficult though.
Now I am trying to setup identity memory mapping. I start to understand what your issue on the first PCB was - I first thought that RA12..RA15 would appear at MO0..MO3 when mapper is disabled, but actually that can't be right and it seems they come out from MO11..MO8. So I need to get my head around what the register values need to be in the beginning to enable mapping without changing the memory map.
I don't think I have much time today, but I am looking forward to working on this!


Happy to hear it works for you.

The wiring fixes leave the map slightly jumbled and the identity map is:
By this I mean that if you put the above values in the map registers at >FE40 through to >FE4F, it does not matter whether mapping is active or not, as in both cases the same physical memory locations are reached.

Stuart has done a version of Cortex Basic that works with the mapper as implemented on the mini Cortex (and supports the F18A option as well).

Let me know when you need MDEX and Unix images.
Thanks Paul.
Good to know the identity map, I will create a new version of my development firmware to set that up.
I guess I am ready for the MDEX and Unix images too, I just want do some checks to see that the memory mapper works as I have not been able to fully validate that yet.
Regarding the CF memory cards, will all sizes work? I may have some old cards laying around somewhere. The new ones seem start from capacities of 8GB or 16GB. I am asking this since now that I've been playing around with SD cards I know there is a communication protocol difference between older and smaller SD cards and newer SDHC cards, so I wonder if there is a similar thing to be aware of for compact flash cards. I know that your boot code requires a FAT32 partition, so that should all be good.
I guess I am ready for the MDEX and Unix images too, ...
Images sent by private mail. Note that the images must be on the card as unfragmented files, so copy them onto a freshly formatted card.

Regarding the CF memory cards, will all sizes work?
Yes, as far as I know all CF cards support the "memory mode" hardware interface and the few commands that the software actually uses. Note that cards of 2GB and below will not normally be formatted with FAT32. On a Mac "Disk Utility" can be used to reformat. For using both MDEX and Unix the card size needs to be >= 32MB
The chap in Germany should be able to rebuild the power supply fairly easily. Even if the transformer's gone away he could replace it with a standard 12-0-12 toroidal one, and wind on the winding for the 5V. It'll probably only be about 20 turns of thickish (about 1mm^2) wire
I suppose if the supply is missing completely, a little pc one would do the job with the power control wire shorted to ground to turn it on.
SD board for Mini Cortex

SD board for Mini Cortex

I've been doing some hardware design over the last several weeks. I had several goals for the whole process - not only to have a working circuit, but also the necessary skills such as experience in PCB design. Today I finally could place an order to sitopway for PCB manufacturing (thanks for the recommendations!).

The board is an SD card interface for the Mini Cortex, although I also had other design goals, primarily to have a "universal" SD interface card that would work on many other retrocomputer systems too. As an example I intend to interface it to the TI-99/4A I recently acquired. (That machine is in a pretty beaten up shape and it does not work, so I need to first debug that system too, but it will be another story). I also wanted the board to be useful on a standalone basis too, for development and testing purposes. So in addition to having the obvious SD card interface and the Mini Cortex CF interface, it has a bunch of other extension interfaces too.

For the PCB design I wanted to try to do an all SMD design. I have obtained most of the components to see that they match the footprints on the PCB layout. Even though I went with 0805 sized "large" passive components (resistors, capacitors and LEDs), they are pretty darn small. I have test soldered a few TQFP chips by hand on protoboards, and that seems to be doable although my magnifying glass has been heavily necessary. I attach the schematics and PCB layout files for those who are interested. Actually for some reason the PCB pdf file does not want to get attached, the attachment loader shows a red exclamation mark. Any clues? The PDF is 85K in size so it's not huge.

It will be interesting to see how the boards turn out and what kind of a nightmare the assembly will be with all this tiny stuff. I am looking forward to the bring up phase after assembly, fingers crossed that the board will work... Waiting mode now. Or actually firmware and VHDL design mode...



  • sd_proc.pdf
    35.8 KB · Views: 1
SMD design - ouch! Personally I'd advise through-hole design where possible. Many TI'ers are now of a certain age where hands and eyes are not as good as they once were, and it's likely to put some potential builders off.

I see the schematic PDF with lots of lovely interfaces on it. ;-) How does one access such a device? Is it all memory mapped ports, or ...?

(Trying zipping the file you can't attach, and see if it lets you attach the zip file.)
SMD design - ouch! Personally I'd advise through-hole design where possible. Many TI'ers are now of a certain age where hands and eyes are not as good as they once were, and it's likely to put some potential builders off.

Stuart, thanks for the comments. I have to say I am not that young myself either... Even if I often like to see myself that way :confused:

I debated with myself about going entirely SMD. I eventually settled to go that way, because many components were going to be SMD anyway: the CPLD, the micro controller, USB connector and SD card socket. But to be honest, I wanted to go this way because I wanted to see if I could do it ;) so this is my small mount everest to conquer. We will see how it pans out. The good news is that the boards turned out to be very affordable - the order went in yesterday. If it turns out to be difficult to construct, I can modify the design with through hole components for the parts where that option is available. I tried to align parts in a way where there would be some maneuvering space around them - towards the end of the layout I realized I had placed some parts too close to each other to facilitate hand assembly.

To continue on the SMD theme, I also want to say that I believe the board layout was easier to do this way. Currently the only through hole parts are the pin headers and the crystal. Going through hole with the other components would probably have required a larger board. I attached a printout of the top and bottom of the board (I eventually settled on Eagle, dare I say due to the fact it seemed to have more complete SMD part part libraries...). With the XC9572XL and its 100 pin package there is quite a bit of routing pressure to bring the signals out. Even though the board does not look like much, it took me probably 50 hours or so to manually place and route after the first version of the schematic was done. A lot of that was learning curve and early design changes, finding the appropriate packages, but also just getting the signals where they need to go. I think the next board will go very much faster.

I see the schematic PDF with lots of lovely interfaces on it. ;-) How does one access such a device? Is it all memory mapped ports, or ...?

Basically the idea is that all signals from the Mini Cortex CPUBUS go to the CPLD. There is a 11 bit parallel bus between the microcontroller and the CPLD. In addition the SPI bus of the SD card goes to both the micro and the CPLD. With that, the actual interface topology will be up to the CPLD configuration.

You are right, my idea is that the ports will be memory mapped and actually on the mini cortex that is the only option as the CRU bus does not arrive at the CF connector. This also matches the FPGA design I did on the breadboard - the SD card interface is memory mapped.

There are 8 memory locations that are available. The existing SPI design requires two (one for SPI data read/write, one 1 bit register for SPI chip select and status read). I am planning that on some of the remaining memory locations there would be access to the extension connectors of the CPLD (12 signals - more would exist but I wanted to get the board done and did not want reposition the parts yet again to route more signals out). A couple of registers would be a mailbox interface between the micro and TMS9995. That mailbox would be the means of interprocessor communication, providing access to the vast array of peripherals available on the micro. Of particular interest there are the serial port and the USB port. I also brought out the I2C bus of the micro to some header pins.

The NXP LPC1343 microcontroller is tiny in size but has an impressive amount of stuff in it. It has a 32-bit ARM Cortex M3 processor core running at up 72MHz, 32K of flash ROM and 8K of RAM. It has a very handy boot loader feature, basically you short one pin to ground and it's built in boot ROM makes the chip look like a 32K FAT12 USB memory device, allowing one to drag and drop in a 32K firmware image. I haven't tried that yet, in my test setup I have used a raspberry pi connected to the serial port of the micro and I've used the serial boot loader feature of the chip. In case one wants to use more of the micro controllers features on this board, one can just route the 11 bit bus going to the CPLD thought the CPLD to its extension connectors. I tried to keep things flexible there.

I also wanted to go with these particular chips and packages (XC9572XL and LPC1343) because for both there is a pin compatible upgrade path (XC95144XL with 144 macrocells, and LPC1347 with 64K Flash).



  • sd_proc_bottom.pdf
    39.9 KB · Views: 1
  • sd_proc_top.pdf
    37.6 KB · Views: 1
  • sd_proc_parts.txt
    6.6 KB · Views: 1
Ok so I posted a few years ago that I have a cortex and was going to have a go at getting it going.....then life took over.

So anyway now I really am about to try and resurrect it.

I have the original mk1 Cortex but with the Yamaha display and the wd floppy controller both on sub pcb's on flying leads, I also did the 256k memory mod.

Have got all the boards on a bench and if interest is there I will post some pictures as I go.

My plan is as follows over the next 8-10 weeks.

1) to allow me to use a TFT screen--order a video console to VGA converter from ebay (done)
2) spray clean with PCB cleaner all the boards as very grubby with 25+ yrs of loft grime accumulated( bits bought and next to be done)
3) change electrolytic's on PSU but may also get a Switch Miode PSU to replace original unit
4) change electrolytic's on all other PCB'S and the tantalum caps from the main board.
5) remove all 74xx logic chips, test and replace one by one.
6) remove all components from tape unit, old video rams, old TV display from motherboard.
6) remake all flying leads to suit a new layout with the sub boards being on a Perspex plate mounted above main board.
7) power up from bench supply at low voltage then fit main PSU.
8) prey that the 25 year old Cdos2.0 disk still works !
9) fit it back into original case.

then I am thinking of making a new pcb sub board to use include 512k of static ram.

only for fun and to see if I can get it going.
Definitely post the pics, as it will be interesting to see how you did the 9938 mod. One of these days I want to try and do up a little daughter board layout with a 9938 and its memory on it that I can insert into a Cortex or a TI-99/4A. . .
restoration started

restoration started

Ok so a slow start, Picture is of the main board with the video card sitting above the video processor, to the left is the wd disk controller board that I built and above is the rom daughter board that takes 2764 roms. bottom left is the ls2001 replacement header for the ebus.


will be cleaning it all up this weekend and will post more
Last edited:
My first PCBs arrvied

My first PCBs arrvied

Today I had my magical moment as the SD processor PCBs arrived. They look like the real deal :)
I'll see how the assembly turns out. It looks that at least in theory it can be mounted on the Mini Cortex as one can see from the picture here. The PCB is just casually laying on top of the CF card breakout board. The mounting holes (well all of 2 of them that are of use with the cortex) are in the right place - but a tad too small... I doubt that will be the only thing that is wrong.

I have a very busy weekend ahead of me in RL so not sure yet if there is time to work on these, but I look forward to having time for that.


Last edited:
That is a very cool PCB! I'm looking forward to hearing how this progresses :)
I'd be happy to work on software drivers for this PCB for MDEX, Unix and CDOS once you have the hardware functional.

In the last couple of months Dave Pitts has done a lot of work rounding out the V6 Unix port, I hope to find time to add all that to the repository soon. I've also looked into moving to the V7 Unix kernel and that looks just about doable on the mini cortex. Last but not least, I looked at integrating the BSD tcp/ip stack, but that seems a bridge too far: that stack does not fit in a 16 bit address space. Perhaps a different, smaller stack can work -- looking at the first edition of this book. Otherwise simple uucp is as far as it will go.

The FPGA prototyping board and Xilinx cable arrived. Currently undecided whether doing an SD card interface for the mini cortex v2 or jumping to working with the 99105 will come first. On a 99105 doing tcp/ip will be easier, but it also would be leaving Cortex territory.