flynnjs wrote:As Dave says OSWORD &7F and other OSWORD friends.
And OSGBPB then you can access the block device as an image on your native filing system instead of having to trash whatever disk you are using. That's how all the non-BBC-OS-on-CoPros work, OSWORD &72/&7F for raw floppy access to foreign-OS floppies and OSGBPB for "hard drive" access to an image file containing the hard drive.
flynnjs wrote:I suspect there could be benefits to rewriting on the parasite side.
The 6502 client in particular is very tightly written and there would be little benefit in rewriting it. I've done a couple of bugfixes for v1.11
, but that's at the high level not at the low level API-to-host level.
flynnjs wrote:The original Tube hardware resets into code which copies itself into RAM and then makes the RAM Read Only.
On what platform does it do that? On all the 8-bit platforms the ROM is copied into RAM then the whole memory map is made read/write.
A quick check seems to confirm that on the 80x86 and 320xx the ROM is fixed in the memory map and the client code is executed from ROM.
1. Are you currently enforcing the F800-FFFF read only from the original copro, and if so is that an address based enforcement or can I just remap the bank lower and patch it
read-only, if it was the system would fail; the hardware reset code modifies itself to make itself a warm entry to the supervisor, data transfers modify the NMI vector to point to the required NMI routines.
EtchedPixels wrote:2. From the docs I've seen and the code am I right in assuming NMI based transfers are always part of a parasite initiated activity.
No, all data transfers are initiated by the host. Mostly the host will initiate them in response to the client asking for something, for example during an OSFILE call, but a data transfer can happen at any time. You could have something on the host ticking away in the background and doing a data transfer whenever it wants.
EtchedPixels wrote:3. The host to parasite interrupt (not NMI) doesn't have a timing constraint ?
(1 means I can patch the code to make the irq handling cleaner, although if not I think making IRQ1V push a fake RTI frame and then jump to the old handler is sufficient to pick it up.)
In what way is the IRQ handler "dirty"? It's as minimal as it needs to be, very quick check for Tube interupts, then if not Tube dispatches as fast as possible to IRQ2V.
EtchedPixels wrote:3. means I've got time to bank switch the MOS code holding E000-FFFF page to 0-1FFF as well so that there's a private IRQ stack and ZP for the MOS interface to use and all the zero page variables are free without expensive copying. $FC while needed in each bank is only used to save and on the return to the right bank restore A.
Zero page locations &E0-&FF(*) are reserved for the Tube MOS, everything else is free, so only &E0-&FF is needed. &FD/E/F are readable by programs as the FAULT pointer and the ESCAPE flag.
(*)I've only seen Tube MOSes using &EC-&FF, but documentation says &E0-&FF, so stick to the documentation.
Edit: Plus, of course, page 2 is also owned by the MOS as that's the vectors and string and host error buffer.