• Please review our updated Terms and Rules here

Powertran Cortex

ClassicHasClass said:
I think I'm missing something, but I looked at http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=tip and I can't find where to download 9995 binaries. Are there any?
Click to expand...

That is correct, there are currently none. Let me know how I can help. A set of binaries, the disk images for MDEX and/or Unix? The cross-compiler pre-compiled? A zip with all the sources?

Eventually I hope to get everything packaged up to the same quality as Stuart's site or the powertrancortex site, but right now it is such a moving target that I think my time is better spent pushing the hardware and software forward. By late March I hope to have a eurocard sized pcb with a "mini cortex" as the next step.
 
Does anybody know of any work on a CRU to SPI bridge?

Once you realize that the SPI protocol does not impose many restrictions on the clock signal (like duty cycle or minimum frequency), it starts looking quite similar to the CRU protocol. I'm thinking of hooking up an ethernet controller:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889

It is available as a 24 pin narrow DIP and also as a breakout board (there is the olimex board https://www.sparkfun.com/products/765, but there seem to be many others as well).

I think it might take only a few 74 series chips and a free output line to hook it up to a 99xx processor as a CRU device. Unfortunately the bit order on the SPI protocol and the CRU protocol are reversed, but that is easily solved with a 256 byte lookup table.

All I could find was a post by Jamie Malilong who seem to have had the same idea about a decade ago:
https://groups.yahoo.com/neo/groups/ti99-4a/conversations/messages/46761

The TCP/IP stack is handled on the 28J60 chip, which is imho a two sided fact. It certainly makes stuff a lot easier, but doing a SLIP protocol serial line with TCP/IP running in 99xx software is more vintage.

Paul
 
pnr said:
That is correct, there are currently none. Let me know how I can help. A set of binaries, the disk images for MDEX and/or Unix? The cross-compiler pre-compiled? A zip with all the sources?

Eventually I hope to get everything packaged up to the same quality as Stuart's site or the powertrancortex site, but right now it is such a moving target that I think my time is better spent pushing the hardware and software forward. By late March I hope to have a eurocard sized pcb with a "mini cortex" as the next step.
Click to expand...

The disk images for LSX and a raw binary image of the kernel (or at least the bootstrap) would be perfect if you have them handy. Thanks! I have an idea which I will share if I get it off the ground.
 
ClassicHasClass said:
The disk images for LSX and a raw binary image of the kernel (or at least the bootstrap) would be perfect if you have them handy. Thanks! I have an idea which I will share if I get it off the ground.
Click to expand...

Attached. The zip file contains the kernel image (still with the 16 byte a.out header which you might need to strip) and the disk image (expands to a 4MB file). The boot.s.txt file is the ROM based first stage boot loader. It scans the root directory of the CF card for file LSX_DSK0.DSK (assuming the CF card is FAT32 formatted) and loads sector 0 of this disk image. Sector 0 contains the 2nd stage boot loader which loads the kernel image (it is file "lsx" in the image root directory -- same file as in the zip).

The first stage boot loader also locates LSX_DSK1.DSK which is a second disk for future use. Currently I simply use a copy of the same disk image as a place holder. The first stage boot loader leaves the starting sector number of LSX_DSK0/1.DSK at location 0xff00 and 0xff04 (two 32 bit numbers) and all the code assumes that the disk images are stored as unfragmented files (i.e. all sectors contiguous).

Finally, I just noticed that there is still a comment in the first stage boot loader source (just above label "main") that still refers to the MDEX boot loader -- ignore it.

Hope the above is clear enough.
 

Attachments

  • lsx.zip
    87.8 KB · Views: 1
  • unixboot.s.txt
    5.8 KB · Views: 1
Last edited:
Thanks. If I read this correctly, it loads the first sector to @>8000 and executes it from there, correct? Where does the kernel load in memory?

(And while I'm asking, is the source code for emulsx around anywhere?)
 
Last edited:
ClassicHasClass said:
Thanks. If I read this correctly, it loads the first sector to @>8000 and executes it from there, correct? Where does the kernel load in memory?
Click to expand...
Yes, that is correct. The kernel loads at @>0000, please have a look at the second stage boot loader ("the first sector") for details:
http://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/9f2ce0cc6ad7babce3ad716aa7447f8291186a8a
The "emu" flag adds a bit of code that does some initialisation that on the real hardware is already performed by the first stage boot loader.

(And while I'm asking, is the source code for emulsx around anywhere?)
Click to expand...
Sure, attached. It is a messy bit of code that hacks together parts of David Pitt's TI990 emulator and Warren Toomey's Apout unix simulator. The latter was used in debugging the userland programs (or more accurately: debugging the compiler) well before I ported the kernel itself. The Apout code is not currently used. As said, it is messy code that just evolved as a debugging tool as I went along.

Compile with:
Code: 
gcc -o emulsx -O -m32 -DUNIX sim990.c simio.c simload.c simops.c simuv6.c

Paul
 

Attachments

  • emulsx.zip
    22.2 KB · Views: 1
I had to do a little hacking on my AIX system, but it runs emulsx and boots the kernel. There's a glitch with the terminal where it wants 4 characters at a time -- I suspect this is an endian problem given the fact it's exactly 32 bits, but it otherwise behaves properly.

Once I figure that out, then I want to see if I can get my larger project off the ground, and if it does I'll share.
 
ClassicHasClass said:
I had to do a little hacking on my AIX system, but it runs emulsx and boots the kernel. There's a glitch with the terminal where it wants 4 characters at a time -- I suspect this is an endian problem given the fact it's exactly 32 bits, but it otherwise behaves properly.
Click to expand...

It might be the way AIX handles raw mode. To emulate the 9902, it places stdin in non-blocking raw mode and checks for new characters arriving ~60 times per second. On OSX I get each character reported separately, perhaps AIX groups in 4 characters with the current raw settings (Side note: on my breadboard I have not hooked up the 9902 interrupt to the CPU, so on every clock interrupt the service routine checks the receive buffer full flag on the 9902 -- see low.s for details).

Once I figure that out, then I want to see if I can get my larger project off the ground, and if it does I'll share.
Click to expand...

Super!
 
ClassicHasClass said:
I put it on my G5 running OS X and it works fine.
Click to expand...

Happy to hear you could replicate the results! Now try the command "mv . a" and witness an ancient inside joke between the original Unix developers. Google for it to read the background to this joke.
 
pnr, one last request: I tried to extract out the DSKs and was not able to. Are you using the CF card image as merely one big honking DSK image? My hope was to distill down to floppy size (say, around 120-140K each).
 
ClassicHasClass said:
pnr, one last request: I tried to extract out the DSKs and was not able to. Are you using the CF card image as merely one big honking DSK image? My hope was to distill down to floppy size (say, around 120-140K each).
Click to expand...

To extract the files you need to build the file system tool:
http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=c5338a82ca9ceeaa&name=fsutil
With this tool you can also rebuild the file system for a different size disk.

Note that the disk is also the swap device and that in the current configuration it needs to be able to hold two 40KB swapped images, i.e. 80KB. With one 120KB disk I'm not sure you have enough space left over for the file system. Perhaps use one 120KB floppy as swap space and the other as a file system?

The original LSX had 32KB user space, so it needed 64KB swap space. It ran on a system with SSSD 8" floppy, or about 240KB, of which 176KB was used as the filesystem.

Have a look at the param.h file for configuration settings:
http://1587660.websites.xs4all.nl/c...38554efc6a80d0a71c7c3967ee96689d929c?ln=17-31
You need to consider the NBLKS, SWPSIZ, NSWAP and SWPLO settings.

All-in-all you will need to recompile the kernel, probably also adding your own disk driver code (see drv_cf.S for the breadboard CF Card driver).
 
Ksarul said:
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.
Click to expand...

Here are a draft schematic and a PCB design for the "Mini Cortex". I have a little room left over on the PCB. I've considered adding further memory protection (futile), adding an ethernet chip or an F18A. For the latter I'm not so much interested in the 9918A part, but I find the embedded 9900 GPU intriguing and an F18A may serve as a handy development board to prototype an FPU for the 99105 project. On the other hand, mission creep is usually a progress killer.

Jim, Stuart and Ksarul, I would appreciate your constructive critique of the design and PCB (it has been 35 years since I last did a PCB and those were simple, hand-drawn affairs).

Paul
 
Last edited:
Looks good, Paul. Although you renumbering the address and data buses away from the TI standard had me confused. ;-)

Questions more than anything:

(1) What's the purpose of the RESET jumper? Won't that just hold the processor in the reset state?

(2) Is the 3K3 resistor for the Power LED correct? These normally seem to be around 330R.

(3) Why have you split the inputs/outputs to the memory mapper into a group of 4 and a group of 3?

(4) Is the single-step triggered by reading/writing a specific memory address, rather than using the LREX instruction?

(5) What's the USER output of U10? I can see it goes into the GAL but isn't used. For future use?

(6) Out of interest, why on some ICs (like the memory mapper) do you pull pins high through a resistor, but with the 74LS74 you tie the /Set input directly to +5V? Seen that done before, but never understood why.

Is it worth filling that spare space on the PCB with a load of 'tripad' holes and power rails so you can add extra ICs for mods?

(Programmed my first GAL yesterday. Got it to emulate a 74LS138.)

Stuart.
 
Stuart said:
(1) What's the purpose of the RESET jumper? Won't that just hold the processor in the reset state?
Click to expand...
Ah yes, it is not a jumper: it is a header for connecting an external reset switch. Could not find the symbol for a two pin header, so used the jumper symbol. Confusing, I admit.

Stuart said:
(2) Is the 3K3 resistor for the Power LED correct? These normally seem to be around 330R.
Click to expand...
It is a low power LED, 2 mA does the job. That said, a 2K7 is perhaps a better choice.

Stuart said:
(3) Why have you split the inputs/outputs to the memory mapper into a group of 4 and a group of 3?
Click to expand...
Originally they were all together and in order, but this way works out better for laying out the PCB tracks.

Stuart said:
(4) Is the single-step triggered by reading/writing a specific memory address, rather than using the LREX instruction?
Click to expand...
It is triggered by a CRU bit. So to execute a single instruction from the monitor the code would be:
Code: 
li r12, 0x0800
sbo 2
rtwp
This will execute one instruction after the RTWP and than do an NMI. The NMI routine then starts with:
Code: 
limi 0
li r12,0x0800
sbz 2

Stuart said:
(5) What's the USER output of U10? I can see it goes into the GAL but isn't used. For future use?
Click to expand...
Good catch. I forgot to update the GAL formulas. The purpose of USER is for the operating system to set "user mode". In this mode access to the CF Card, the mapper registers and the 9902 is blocked. A user program can always reset the bit, so it does not protect from malicious code, but should help as a minor defense against bugs taking the system down. That said, on a 9995 any user program can do a "limi 0" and that pretty much locks out the OS from recovering.

Stuart said:
(6) Out of interest, why on some ICs (like the memory mapper) do you pull pins high through a resistor, but with the 74LS74 you tie the /Set input directly to +5V? Seen that done before, but never understood why.
Click to expand...
I guess the truth is that I don't really understand the purpose of these pull up resistors. I will have to read up on their origins. Most likely outcome is that this needs to be modified to use a pull up resistor.

Stuart said:
Is it worth filling that spare space on the PCB with a load of 'tripad' holes and power rails so you can add extra ICs for mods?
Click to expand...
That is a good idea. Not sure what you mean by 'tripad' holes: I think three holes connected by a long pad, like you see on prototyping boards?

Stuart said:
(Programmed my first GAL yesterday. Got it to emulate a 74LS138.)
Click to expand...
That is great news. This means you have figured out the required toolchain to go from logic formulas to a programmed device. I still have that learning curve ahead of me.

Paul
 
pnr said:
I guess the truth is that I don't really understand the purpose of these pull up resistors. I will have to read up on their origins. Most likely outcome is that this needs to be modified to use a pull up resistor.
Click to expand...

Found this explanation:
http://www.edn.com/electronics-blogs/living-analog/4428104/Pull-up-Resistors-

As a teenager 35 years ago I experimented a lot with TTL (mostly LS types, though) and I never experienced this problem. Depending on the value of beta (as defined in the above write-up) one would perhaps not immediately notice (if beta is in the 10 to 20 range, the chip would get warm, but not hot). It is also possible that this was a sixties problem and that by the late 70's chips were designed to prevent this issue.

In any case, the safe route is to assume that it can be a problem. I will update the schematic and pcb to add a pull-up resistor. Thanks for highlighting this.
 
The Cortex has a 74LS74 with /Set and /Reset tied directly to +5V, so I'm sure it a 'valid' thing to do. Just not sure why. Using pull-up resistors can't hurt though. ;-)

Tripad - yes, three holes connected by a long pad.

All your other replies sound convincing. ;-) Apart from perhaps:

-- U10. Feel a bit uncomfortable that CRUCLK isn't involved in deriving the /CE. I guess though that if /MEMEN is high then it must be a CRU cycle (or an external instruction, which you aren't using by the looks of things).

-- If PROTECT is high, then it looks as if you're locking out use of the 9902, as its CRUCLK input won't ... clock. Is that intentional?

Stuart.
 
Stuart said:
The Cortex has a 74LS74 with /Set and /Reset tied directly to +5V, so I'm sure it a 'valid' thing to do. Just not sure why. Using pull-up resistors can't hurt though. ;-).
Click to expand...

Have a look at this 74LS74 datasheet:
http://www.ti.com/lit/ds/symlink/sn54s74.pdf
Look at the full schematic on page 3. All inputs are protected by two diodes that should block the run-away currents described in the write-up. I guess the Cortex designers felt safe that TI chips would be used and that the issue could not arrise -- after all, they were working for TI's chip division, weren't they? It is a bit strange though that the "equivalent input circuit" on page 2 is still the open emitter design mentioned in the write-up.

I've looked at datasheets from National Semi and Motorola but the TI one is the only one giving full internal schematics.

Stuart said:
-- U10. Feel a bit uncomfortable that CRUCLK isn't involved in deriving the /CE. I guess though that if /MEMEN is high then it must be a CRU cycle (or an external instruction, which you aren't using by the looks of things).

-- If PROTECT is high, then it looks as if you're locking out use of the 9902, as its CRUCLK input won't ... clock. Is that intentional?
Click to expand...

It looks like you have found two more bugs. I'll correct those too. Once more many thanks.

Also, the "spare" area could be used to make the circuit even more Cortex-like with decoding of the external instructions.
 
Thanks for the reminder something had been happening here Paul, the last message I saw was a couple of months ago.

Yes, my TMS99105 system did suffer from feature creep somewhat and I got distracted by another hobby.

A quick look at your PCB and I would say you need more 0.1uf decouplers, at least one for every chip, as close between 0v and 5V as you can get them.

Silly question, where does the power connect ?

Jim
 
You must log in or register to reply here.
Back
Top