From firstname.lastname@example.org@21:1/5 to All on Sun May 19 04:04:25 2019
Hello Transputer fans!
Some months ago I started my personal project which is to understand the hardware design of the transputer.
I did browse the material available and decided to start with the ROM dump published by Gavin Crate. Taking the dump of the T425C, some time and energy I was able to figure out the meaning of the 118 bits.
While decoding the meaning of the bits I had to design the ALU, registers, multiplexors in front of the registers, clock compare, schedule counter, branch conditions for the microde addresses, memory interface, the links and some other bits inside the
transputer. Some of you will already know what it consist of but my claim was to reverse engineer it on my own.
I don't want to bother you with all the bits on my way to finally run the compiler chain and some Occam examples which I found in the material you guys preserved. Many thanks to Mike's transputer.net, ram's archive, Gavin's Transputer Emulator page, Axel'
s Geekdot and David May's Transputer Page.
The emulator now does execute all the code I have but maybe some of you can support me to figure out if all bits and pieces are really working.
The emualtor is written in C. Here is what it can emulate so far.
The occam compiler taking hello world as an example.
[cpm@spam hello]$ make -f hello.makefile
oc hello -ta -h -o hello.tah -i
sending HUP to pid 7685
occam 2 compiler Version 2.01.01 (21:15:57 Feb 27 1991) (Transputer)
Compiling (TA,HALT) "hello.occ" to "hello.tah"
Syntax tree occupies 183780 bytes
Alias and usage checking
Alias and usage checked ok
No errors found in source
Read 183 lines of source, syntax tree occupies 192352 bytes
Syntax tree transformed ok, now occupies 198652 bytes
Writing debug information
PROC hello requires 59 workspace and 128 vectorspace words
Module code size is 64 bytes
Code generated ok
0.01user 0.01system 0:17.21elapsed 0%CPU (0avgtext+0avgdata 11344maxresident)k 1856inputs+16outputs (1major+320minor)pagefaults 0swaps
The emulator itself is a single task running on a 4.2Ghz i7-3770K for those who are interested in the execution speed.
Knights, Prime and Sqrroots from Gavin's page run too. Sqrroots was really helpful in discovering that the alu needs an extra bit.
Looking forward to get in touch with the wonderful people preserving the legacy of inmos.
From Mike B.@21:1/5 to All on Mon May 20 03:26:54 2019
Great news. If you are interested in more transputer tests (e.g. primary all arithmetic instructions) I can supply you with my transputer validation suite.
If interested in Transputer FPU emulation I can also gave you some hints and tips.
From Gavin Crate@21:1/5 to All on Sat May 25 03:39:28 2019
I've uploaded two more Occam test cases for you to run on my website (see Further Occam Examples.zip) on the same webpage as the other examples.
The first example (ex95) does an exhaustive block move using the byte move instruction and post move verification. If the program stops then the post move verification has failed, otherwise it runs forever. This will test if your AregReadPartWrite logic
The second example (ex94) handles high and low priority timer requests in parallel with a low priority continuous block move. Again if the program stops then the post move verification has failed, otherwise it runs forever. See the text file for what the
REAL transputer output should be (Thanks to Axel).
I agree with Mike that the key to a successful emulator is a lot of verification testing, both instruction level and system level (i.e. Occam / C test cases).
Just for information, these above Occam test examples run successfully on "both" my T414B and T425C VBC emulators. The later not publicly released yet. I am planning to release it once I've released the next release of the T414 VBC v2.6 sometime in the
next 2 months.
From email@example.com@21:1/5 to All on Sat May 25 11:14:28 2019
Thank you very much for the two examples. I really appreciate your support. I've downloaded the zip and tested my emulator with it.
Test Ex195 run fine and forever.
But Ex194 is giving me the chance to further enhance the logic I discovered so far. It correctly runs up to the point where the first interrupt occurs:
Maybe my guessed interrupt logic isn't working correctly and needs to be fixed.
Great to hear that your emulators are running them successful!
I was pretty sure that you emulator is much closer to the original then mine is right now. I guess I still need some time. I started my project six month ago and my ancient transputer knowledge was long gone.
It is really fun to reverse engineer what the famous inmos guys invented.
I figured out that it is not so easy to correctly model the links. There are still some things which I do not know about them. Have you discovered all the bits in this area?
From Gavin Crate@21:1/5 to All on Sun May 26 01:29:17 2019
The Occam test case (Ex94) was specifically designed to test the correctness of a high priority task interrupting a low priority byte move instruction. Note that the ucode (VBC) for the byte move instruction checks at the completion of word boundaries
for a high priority request (channel or timer).
One helpful bit of advise - Maybe think about disabling the byte write strobe latch (used to enable byte writes) when the ucode is switching from low to high priority task (but MUST be before the registers are saved to the lower memory space -
xxxIntSaveLoc). And then setting the byte write strobe latch back on return to low priority task if a move instruction was interrupted.
By the way, is the Occam test case (Ex95) completing all the test cases and hence repeating over and over?
From firstname.lastname@example.org@21:1/5 to All on Sun May 26 12:37:27 2019
Ex95 is running perfectly. No error flag raised and doesn't stop.
Ex94 shows a funny behaviour which is for sure one of my stupid mistakes. I switched on the trace output of my emulator and then it was running perfectly but slow while creating gigabytes of output. Thus I think the basic logic is fine and I have to
rethink my programming skills :-) I'm sure I'm getting this fixed.
Byte write logic isn't in the state I would like to have it. By now it is a switch case taking three of the ROM-bits into account. It was much simpler to figure out which logic is needed in which combination of the three.
Not sure if I understand your advice. I haven't checked but isn't the interrupt condition evaluated after the write took place at uCode address 0x0CD? Anyway I will check what the actual uCode is executing and hopefully I will understand it.
I really appreciate your input. It's very helpful. Thanks a lot.
From email@example.com@21:1/5 to All on Fri Jul 19 12:24:04 2019
Hello Transputer fans!
Some progress was being made in the last few weeks.
Even if I couldn't spend much time in this project I did discoverd some more gems in the Transputer internals.
Mike with his knowledge an enthusiasm contributed tons of information in my project.
I'm happy to report that Gavin's EX94 test is now fully running. I found a mistake in my implementation of the communication between the processor an the link engine. I purely forgot to implement the StatusInquiry and the interrupt associated with it :-(
Still some way to go but all the tests I have are running now very nicely. I have a long list of todos.
rspy (thank you Mike!) is testing my emulator like on a real Transputer :-) ./rspy -l -f -zm
# Part rt Link0 Link1 Link2 Link3 F.Test RAM@cycle
0 T425C 20 16M ... ... ... passed 4K@1,2044K@2.
And yes it does pass the functional test!
Just for the fun of it I started 10 instances of the emulator thread and voila.