1024MAK wrote:I don’t think there will be very much interest in this subject unless some software is developed that makes good use of the concept - a killer app so to speak. But anyway...
Nasta wrote:
The documentation clearly shows that the Acorn Tube is designed around using the BBC operating system, and this extends down to the very hardware, which is tailored to pass parameters the way OS calls do it. How this is relevant to a machine that runs an entirely different OS with a completely different abstraction of it's operations and methods of parameter passing, is beyond me.
I think you may have completely missed the point. Yes of course all the documentation is specific to the Acorn BBC B / Master OS. Because the Tube is an Acorn system. That does not mean that it can’t be used on other systems.
...as long as they basically look like a BBC computer.
Note, again, that the entire Tube HARDWARE specification is based on how the BBC OS does things. To a 68k computer this is rather restrictive.
Yes, it could do the same things the BBC does, in effect, emulate it's OS calls (most of them as some specific things like video modes and sound are not the same or supported on the QL) but my question is, why would you want a QL to do this in effect to run BBC parasite software. Yes - it gets all it's code via the host, but a certain host side interface is expected for it to run, which would then have to be re-written for the QL, in essence making it a BBC emulator of sorts.
It should also be noted that the actual hardware is an Acorn ULA which is actually situated in the parasite hardware 'box' and only addressed via the BBC side port as a couple of memory locations. This is not too difficult to do on a QL (almost trivial) but again, what would be the actual concrete benefit?
The BBC has this benefit since the Tube system and extra CPUs on the BBC have been around for decades so there are applications that can use them to good effect.
On the QL some form of multiprocessing has been implemented with the IPC - and it's not that uncommon, many retro computers have a second CPU to control the keyboard (mostly on the keyboard PCB itself).
I think what the thread was aimed at are applications that take various types of load away from the main CPU and delegate. It's mostly an IO thing, though it can be further extended. For instance, on 68k machines the original FPU unit is a dedicated processing unit that works in parallel with the main CPU, reason being that some FP operations take hundreds of cycles, during which the main CPU can do other things like service interrupts. To your point, this sort of thing can be used for emulation, but in general it's expected of the host to be able to support most of the operation set needed to exploit a more advanced second CPU. Given a Rasberry PI, it is actually more logical for the Pi to be a host for a QL system rather than the other way around, the reason why it works on the BBC is the PI is used to emulate other processors.
That being said, given how cheap processing on the level of a PI has become, it is also possible to use a RPI as an IO platform for other systems, including the QL. This is not about a killer application, but rather a killer OS integration. In an asymmetric processing situation, the extra CPUs do not execute applications (at least not directly).
The QL is a relatively minimalistic system that can never the less support (or, better said, does not prevent the support of) some rather fancy concepts in computing. One of it's strengths is an attempt to provide a relatively uniform abstraction of various IO operations. In this sort of model there is nothing preventing the OS calls to be only a data (structure) passing mechanism to some more or less specialized hardware that does the actual work, quite possibly using one or more extra processing 'units' of some sort. The question is, if your processing units are capable of many things, how can you interface them to your host system and be able to exploit their advantages without setting any major limitation when deciding how the OS interfaces with said units. DPRAM is one of the better methods, since it can be used to set up many kinds of data structures to communicate between the main CPU and extra processing unit, and it's main limitations are basically size and the need to set up complex signaling protocols in software on both sides. Using these principles for IO operations is just one of the more obvious exploits as the point where the application passes control to an IO abstraction and back, is already well defined in the OS.
This already goes in in any QL system with a mass storage device that is, or is based on a PC hard drive. All of these have a uC on them tat takes care of a lot of the low level stuff, while the actual host interface communicates on a much higher level of abstraction. For instance, an IDE hard drive uses a register file and buffer RAM to transfer data - the file holds parameters for the data transfer and a command/status register, which are visible to both the host and the uC on the hard drive. When the parameters are set (and data loaded if needed) a command is written into the command register (which is a trigger for the uC on the device), at which point the uC takes over, reads the parameters from the registers, controls actual hardware, and uses or gets the data if required using the RAM buffer - which is a sort of large mail box for the data, while the registers are smaller ones for the parameters. In this case the operating protocol is such that true dual port access is not strictly required, but it could just as well be implemented as dual port RAM.
With proper hardware, the device on 'the other side' (this side being the host computer) could also have it's operating code loaded by the host, which would, again with the right provisions, enable the host to define what the device is supposed to do. In a typical IO system this is typically not the case in normal operation, but in cases such as add-on DSPs or graphics processors, it's almost a rule. There are many ways such a system can be set up, in some cases the lines can get blurred (no reason why a second CPU of the same kind as the main one could not be used for such tasks), but the main point is that this is transparent on the level of applications programming, except in cases where an OS resource is actually provided by a specialized processing unit which has not been built into the system for some reason (such as not having an FPU).