A bit OT here, but they've been mentioned a few times...

So... in the late 80's/early 90's I worked for one of a few spin-off companies from inmos who developed the Transputer. We made some big (for the time) systems with them. Lots of fun and tears... At one level the transputer is just a microcoded 32-bit processor with a somewhat interesting instruction set - variable length instructions, internal 3-deep register stack - and built in communication means - either by a channel which is a means for one process to communicate with another process (the transputer can multi-task at the microcode level) or using links to talk to another transputer. It's normally a blocking communication - a process writes to a channel/link, is stalled, then the transputer can run another process and when the target process/processor reads the data, the sending process can carry on.

This: https://en.wikipedia.org/wiki/Communica ... _processes is a relatively good description of the communication methods.

The key thing we learned when building big machines was that latency was often key - get that down and you might have a competitive advantage (and in later years, we abandoned the transputer, but kept a similar communication model)

Could we go this with the 6502/816/265/etc. ? Sure. High speed? Maybe, "ish", but harder. Worthwhile? Yes - in an academic sense, but in reality, we're not going to solve modern day parallel processing problems on the 6502...

How to put a "link" on the 6502?

The fastest might be a DMA engine - which would probably involve more silicon than the 6502 has to start with... Or maybe some other silicon that acts like a FIFO of sorts - load it up with a message, poke the 'start' then have your kernel de-schedule that process until the FIFO has drained into the target system. If you used the block-move instruction on the 816 and arranged the input register to the FIFO to span say 256 bytes, then sacrifice 1K of address space for 4 links and you're off... I imagine making such a device might not be too hard - I'm thinking of the SPI engine here that might be usable as a base? If would need to serialise the data into a format that another of it's kind can read.

Then you need to write the (micro) kernel for the system...

One feature of the transputers - they could run ROMless. After a reset, with no ROM they would listen to their links and you could send a command down the link - write byte, read byte or jump to address, so, using their internal RAM (2K or 4K) you could poke a little program into it and run it - some transputer systems were built with just that too - 4K internal RAM. (Although our customers kept wanting more and more RAM and I think 48MB was the biggest board we made before moving to something else.)

Could this be applied to the 6502? I think so - others have posted here various ROMless bootstrap systems - which might be usable with this super spi comms link chip...

So I think it would be a nice little demo project, but I've a funny feeling it's something I might leave someone else to do


This:



Is a photo of the last generation system I helped build. to give an idea of scale, it's 2m high. The comms link wires go diagonally under the floor from the middle set of cabinets. They were actually parallel links - 1000's of wires and the raw speed was 75MBytes/sec. slow by todays Gb Ethernet standards, but it was effectively DMA to DMA, from one processor to another via the switch network. (Oh, switches - you need them once it becomes vaguely complicated, so you can optimise the wiring and choose the best topology for the problem) That system has 256 compute boards (dual Sparc, 128MB RAM) and another 16 admin boards and 16 hot spare backup boards) Each board has it's own local 1GB SCSI drive and the black boxes were the prototype RAID systems each with 3 sets of 5x4GB drives. It's less than a modern smartphone might have today, but in 1992 that was the fastest computer on the planet. For a few months, anyway...

One other thing about that picture - each of those white boxes consumes just under 1Kw.. Nice and toasty in there...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

My first job, in 1990, was implementing an Ethernet switch using a set of Transputers. In Occam. That was a weird few months.

Great system but my shed is full (and was full the day we bought it.)

I think there were several interesting and notable things about the transputer
- nice way to do variable length instructions
- on chip scheduler
- CSP blocking communications
- on chip RAM
- serial links to neighbouring devices
- flexible controller for off-chip memories
- same architecture could be implemented at 16 or 32 bits
- on chip FPU (for later devices)
- all speed grades take same 10MHz input
- pre-boot protocol
- stack based instruction set with local workspace pointer idea
- Occam high level language a good fit for parallel programming with CSP

But the most clever part, I think, is the serial links. The CSP communications makes it much easier to build complex networks of communicating processes without getting into a mess of not-working spaghetti. Even trivial processes can efficiently be used: such as processes to put a small buffer between two other processes.

The on-chip scheduler is very nice but could presumably be done in software.

Sounds fascinating, Gordon. That's a lot of metal and boxes in that room. Can you share what the application was?

You should look at the data sheet for the W65C134S, as it really does have this system. It's a serial system that appears to run at system clock speed (so if you have a 4MHz clock, you have a 4MHz serial connection). The technical details are heavy reading, but from a programming PoV it seems mostly straightforward -- the rest is all under the covers.

It's interrupt driven. A common handler is called that checks if it received a message, and if it has a message to send, it sends it. Basically as the token bounces around the network, you get an interrupt. Being a token passing infrastructure, the more CPUs (up to you have in the network, the slower it gets (since you can only send one message each time you get the conch). But it is a 32 byte message (almost, I think 3 bits are used for addressing).

But, notably, it appears to be a high speed network. It would be nice to be able to get a point to point specialization for bulk transfers (to avoid all the token passing overhead), but other than that, I think it's pretty neat. I'd like to understand it more. I'm sure someone with CPLD skill could mimic the system.

Surprised it's not in a circle. Always reminds me of the quote "How long is a nanosecond?" "Oh, about 12 inches".

The one in that picture? It was built in a place called Lawrence Livermore National Laboratories, CA. There's a Cray in the background if you look close enough... Oh, just found this on it: https://str.llnl.gov/str/Alonso.html



It sounds interesting, but I can't think of anything that would use that sort of network, although without going into it in more detail, who knows. I did work for a company that used token ring in an industrial setting (automated manufacture) but Ethernet more or less wiped out token ring back then. We had a link switch for transputer links to the backplane of the Mk 1 modules - it wasn't a true cross point switch though (not practical) but good enough to represent most topologies that people wanted - which a lot of the time was nothing more than a linear chain. Manual patching was also possible. The CS2 that you see above also has switch chips which worked slightly differently but was efficient for larger networks.



Diagonally is the shortest route for that physical layout. The bottom 4 modules in the middle of each leg housed switch nodes (along with 2 modules in the middle cluster) The "L" shape was the basic building block - expanding them went L to T to H shapes if I recall all the ray-traced images that were put together.... The company never got that far, sadly. All the diagonal wires were 5 or 6m long from what I recall. They acted as a FIFO - with several bytes being "in flight" on the wires when in-use.

I think the biggest obstacle now is trying to justify it vs. just picking up a modern laptop/smartphone - although there are people building Pi clusters just because it can be done. I think that if I put all the Pi's I have here in a box, I'd probably have more compute power than that system had back in the early 90's though - for a fraction of the cost and I could plug them into one 13amp wall socket and not need enough power for the whole town I live in!

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

actually only about eight inches on a PC board or in cat-5 cable

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Some details and photo of a smaller CS-2 machine at CERN in this PDF:
http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf

A good find. thanks.

I think that was installed while I was in the US working on the LLNL one. Nice pictures of the switch network too. The switches worked by programming the destination route into each packet, so a packet went into a switch and up as far as it needed then the switch would use the first byte of the packet to select the output port, then send the rest of the packet down that link until there were no more routing packets at which point it was hoped to be a compute node...

Quadrix mentioned there was founded from a lot of Meiko people and they were making high speed switches but at that point, I went on to work with this relatively new thing to the UK called "the internet" ...

That board on page 12... They all had a Dallas RTC chip with on-board battery and 56 bytes of RAM... It had to be socketed as any boards that came home from Livermore were not allowed to have any non-volatile storage on them, no matter how small...

One of my tasks was to write the boot rom for those boards - it was essentially in Sparc assembler and forth - so was effectively a port of Suns open boot prom... I don't think I've written any forth since...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Let me go a little more off topic ... reminds of trying to work with ahh ... certain folks over at the US DOD who were using our software to monitor a, ummm ... 'project' and every time they had an issue and we asked for log files, we got back useless edited garbage. We basically had to either put someone on site (if we could get permission and as often as not wouldn't), train one of their people in using our internal tools (which was an intense pain because a few weeks of training on unfamiliar debugging tools can't make up for years spent developing the code), or try to debug from symptoms alone. Tiny problems that would normally have taken a few minutes to diagnose would take weeks or months and cubic $$$. They paid though.

_________________
Bill

It's just a simple, point to point network.

I looked at it some more, it's kind of clever I think.

By "token passing", that's a mechanism for network arbitration. It's not a ball bouncing from node to node like a hot potato.

So, what happens is that at start up, one of the nodes is set as the Master. Or, rather, WAS the Master. This node has no real control over the bus at this point.

When any of the nodes wants to send a payload, it requests Master. Now what happens, is when the network sees someone raise the "I want master" flag, the node that USED to be Master asserts a signal on its CHOUT pin. All of the nodes have their CHOUT pin connected to their neighbors CHIN pin. When a node see the CHIN pin asserted, if that node does NOT want Master, they simply passes it along by asserting their CHOUT pin.

When it eventually arrives to the node that wants Master, then it's handed off. This is the "token" passing component of the network. If more than one node wants Master at the same time, the one closest to the previous Master is the one that gets control.

Once it has control, it'll tell the CPU that it's ready to go. The interrupt routine puts data in to the data registers (4 bytes, top 3 are node address). Once the LSB is written, the controller starts clocking the data on to the data lines. All of the nodes on the network simultaneously clock the data in to their local registers.

Now, the node to who the data was addressed to will do three things. 1) It'll raise a signal to the net saying "I got it", then it will flag its data as ready to read to the host, finally it will interrupt its local processor to go and get the data. When the host CPU reads the 4th byte of the data, that will automatically reset the "ready to read" bit.

Meanwhile, on the Master node, it will see the "AOK" signal, and interrupt it processor to let it know that the data was received.

If a node has the "read pending" bit set, then it will NOT clock in the data from network. It will just sit there. If that node is the one that the data was addressed to, then it will not flag the AOK signal, and the Master node will see that the AOK wasn't fired, interrupt its host and tell it "message sent, but not delivered" so it can try again.

At this point, the bus effectively goes idle waiting for the next "Hi, I want to send data".

So, the bus arbitration only takes a few clock cycles, the CPU itself is not involved. That means that during a bulk transfer, you almost have the full bandwidth of the bus to move the data. Meaning you can almost achieve 128KB/s on a 4MHz clock. That's a theoretical limit, not a practical one because there's downtime staging the next 4 bytes and raising the Master flag again. If you have one node wanting to bulk transfer to another, it stages the data up, and waits for the interrupt to fire to load it again (which will happens in ~32 cycles).

The destination will get the interrupt to read the data, and at this point it's a race to read the data out before the Master tries to send again. You do NOT want the Master to win that race, because the retry is costly. I think would take some careful study to make sure that Master is not writing faster than the destination wants to take it. Mind, again, it's not a data corruption issue, it's just a performance issue. Wasting a packet send to a deaf node is expensive. When the AOK flag goes up, both nodes are in a race with each other.

But, that said, it would not surprise me if you could not get 4 nodes, streaming to a respective partner, and saturating the bus at 128KB/s between them. With the interrupt handling and everything, I think you'd be hard pressed to get 4 bytes of processing done in 32 cycles. It takes 44 cycles just to move 4 bytes in to/from a buffer not counting interrupt overhead (LDA ABS, STA ZP,Y, INY) x 4. I think I'd stick a NOP or two in to the Master routine, just to make sure that reader was done.

But still, 128KB/s is not nothing with 4MHz.

Now, how does this compare to SPI? Compared to SPI, any node can be Master. It's a 4 wire bus with up to 8 nodes. SPI uses hardware to select (more nodes, more wires) and, as I understand it, is Master to Slave only. A Slave can't push back (directly) to the master. Being a 4 byte transaction, there's probably a wee bit more bandwidth too.

Use cases? Eh, who knows. But I would say if the '265 had this, I'd consider seeing if it could be used to talk to the RPi (but I don't know if the RPi could keep up consistently with a 4MHz serial clock, much less an 8MHz one). My protocol is likely faster being parallel, and more deterministic and probably better suited for the Pi. But takes a lot more wires than 4.

thanks for the in-depth "under the hood" explanation.



the use-case is more what I was curious about - I wonder what WDC had in-mind when they designed it?

As for using it as comms to a Pi - I doubt it, however I think there is a way to run the SPI port in slave mode, but I've never looked, so that might be a way in. As I understand it, it's marginal for software to sample a 2Mhz signal used in the Pi Tube direct project. (Pi Zero, anyway) The Pi hardware can read much faster - e.g. the camera interface, but getting into it at that level is not at all easy. (it's VC4/GPU level code)

The "Tube" was a chip (ULA) that sat between the BBC Micro host processor (a 2Mhz 6502) and the 2nd processor (one of many different ones). It's a few FIFOs that allows high speed data from one side to the other. Pi Tube direct is a complete software emulation of not only the Tube ULA but also all the original 2nd processors, and a few more, so the software on the Pi has to sample the Ph2 clock from the 6502 side to know when to sample the data. (Others here know more about it, I'm just a happy "user" of it, but I think that's the essence) One of the CPUs it emulates is a 250Mhz 6502...

I think someone with the ken and time on their hands could make something for the 6502/816 with a CPLD/FPGA type device. Connect to 8 data lines, 8 address lines plus a few more for address decoding into 4 x 256 byte blocks, IRQ and Ph2, then the other side is 4 x high speed data serialisers - up to as fast as you dare - 100Mb/sec? You block-move up to 256 bytes into one of the 4 decoded regions, poke the chip and wait for the "done" interrupt - the chip just spews forth the data out of one of it's 4 "links" to another connected to another 6502/816 which sucks the data in, interrupts it's 6502 which can then block-move the data out. All you need do them is write a little message passing microkernel and you have a poor mans 8-bit transputer

Which, while still an academic exercise, might be fun for those who want to play.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

(Just a bit of a technical tweak to the description: PiTubeDirect is a bare metal Pi project which uses the GPU's CPU to sample the pins and respond to reads and writes of a 2MHz 6502 system. The critical path is a read, and the initial polling is of a decoded chip select signal. Then the low address lines and RnW are sampled, the data is marshalled, the databus drivers are turned on. The clock is used to tell us when to stop driving the databus, but that's less critical. It's possible to respond to a 1MHz host using the ARM, but the timing from the memory system wasn't quite deterministic enough for completely reliable 2MHz operation.)

SPI or some other autonomous high-speed sampling of pins is probably what you'd need to engage in a serial connection. If not one of the serial UARTs.

Honestly, one can ask that about both of the WDC micro controllers. They seem to have been designed for Something, and then just released in to the wild rather than, perhaps, designed for a generic task. The serial network I think is for some data crunching exercise where they wanted to save CPU bandwidth to move the data. Maybe.

From a CPU perspective, it IS pretty cheap. It costs more to load up the registers than it does to move the data, and it's mostly fire and forget, seems easy to code for, and its 10x faster than a normal serial interface. Plus there's the whole 8 node part, which is extra sexy. That's "free" too.

So, it's almost a high speed GPIB, without any of the electrical details that might make it work with an actual "plug multiple peripherals together" kind of thing (dealing with shielding and length of wire issues, and stuff like that). Though I bet you could wire a couple of modules together with some twisted pair over a reasonable distance (inches to feet, not meters).

I can see some contrived example where the real time nature of the monitoring task requires dedicated CPUs in contrast to a single, faster CPU with multiple processes. But then I wonder if that's the case, when will they have the time to handle the interrupt. But, who knows.

I'm not particularly interested in serial, honestly, I want higher bandwidth.

The only reason I would consider it if I were using the '134 is, simply, because it's there, "cheap", and "free".

Kind of why I'd like more information on the '265s Parallel Interface Bus. It seems to offer some interesting features that I might be able to leverage for talking to the Pi, but the 3 lines of documentation they have on the data "sheet" are lacking at best. The serial network is much better documented.

I actually emailed them to ask if they had any more information, but never heard anything back. (I should say I contacted them on their form from their website.)

I could probably learn more if I had the actual board, but I think you'd need a logic analyzer to really figure it out.

SPI has no speed limit, and there are SPI devices that can handle nearly 100Mb/s. SATA, abbreviated from Serial AT Attachment, is a computer bus interface that connects host bus adapters to mass storage devices. Latest versions run many gigabits per second.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?