Whilst researching the 65C102's memory layout, it occurred to me that, since the I/O processor's memory is mapped to 0xFFFFxxxx,
Well, that's only a convention set by the filing system. In reality they are two seperate memory spaces, each with 64 KiB (*1). Communication between the Memory blocks is only available under programm controll by both CPUs via a FIFO (*2).
The $FFFF 'prefix' tells the filing system (running on the main CPU, now called I/O Procesor) to place any data into it's own memory (or take from there) as final destination. Also, this convention is true for all Tube-CPUs, not just the 6502 wedge or the 65C102 card.
it might be possible to store code there
Sure, it's still the whole original machine. Just keep in mind that several pages are now used by the software needed to handle the Tube-CPU. For example the second KiB ($0400-$07FF) is now occupied by the DNFS communication software. Furthere there is a redifined character set and other usage.
As a general assumption all memory between
HIMEM is available. But keep in mind that this can change during runtime, as the screen can grow downward, depending on the video mode selected, and other memory may be used for like buffers (*3).
Here is a nice thread about the memory issue (*4).
and execute it by setting the co-processor's instruction pointer to a value in that range.
Now, that's the tricky part. One way is to write your own wraper for DNFS to be in control, or you hook later on. Either way you may want to take a look at its commented Listing.
While the wraper method does require a lot of thinking plus modifying the ROMS (or adding a new one), using the existing hooks is way less work - though, not free. So if all you want to do is to kick of some serial action (*5) Using the
$FF calls (*6) is the way to go. When executed from the Tube-CPU side, they transfer execution thru
USERV on the I/O-Processor side. These calls are also able to shovel a parameter block of up to 128 Bytes.
Keep these functions short, as they are, AFAIK, not secured by locks. Less than desired programming on the Tube-CPU side can screw things up when another call comes while first is still served.
For more dereffered, parallel processing you need to dig into the world of interrupts and so on. Have fun.
Does this work?
In general, yes. But as said, your programm must fit into the management scheme of the DNFS. Otherwise the whole system will come to a grinding halt. Like a Brain (the Tube-CPU) isolated from its body (the I/O Processor).
On which co-processors does this work?
On all, as it's a change on the I/O-Processor side, not a specific Tube-CPU (*5).
What are the side-effects?
(Possible) Reduced I/O performance, especially missing responsivnes (Schwupdizität). As usual it depends on what the task is and how it's implemented - the classic YMMV case :))
If you want to dig deeper, the Acorn Tube™ Software and Resources at the mdfs.net site might be a good start - just be aware, that's hard core information, not for the faint at heart :))
Also search for the Acorn Tube Application Note 004 from 1992, which I used for the description of the OSCALL/USERV calling part. Sorry, got no scan :(
*1 - Or to be more correct, there are 64 KiB basic (I/O-Processor) Memory and up to 4 GiB minus 64 KiB accessable in the tube.
*2 - @Chenmunka described the associated OS calls in an answer to a related question.
*3 - See the
PRINTER untility programm from the disk.
*4 - Or is it about the fact how people can go on and on with poitless misunderstandings? Can't realy decide :)
*5 - Well, it's parallel as far as the Tube-CPU is contiuing to run after the call, but it will hamper further action on the I/O Processor until it's done.
*6 - Fine for the 6502 extensions, other CPUs may already use some. For example the Z80 grabs
OSWORD $FF for extended transfers.