@Executioner How it works is that once a byte is written to port 0xFC00, the M4 will issue a BUSRQ and effectively the z80 will be "stopped" while the M4 processes the command.
Once processed and responses are written, control is let back to the z80.
It could get stuck, if the M4 code crashes (which it shouldn't of course!).
Most responses should be so fast that it's hardly noticeable, but of course doing realtime effects and downloading / doing sd I/O etc, could result in glitches.
If it turns out to be a problem in some way, it could be re-designed to pull a port on the z80 while waiting for it to be processed. Reason for the BUSRQ, is that it cannot maintain romboard emulation while the MCU is doing heavier tasks, so the wait code would then need to be placed in RAM.
As it is though I think it works pretty good atleast for all the basic operations it does now.
Hi Duke,
It seems this board is fast becoming the de-facto standard for CPC internet support and some other things like FAT filesystem/DSK support. I have one major concern. Perhaps it's just my misunderstanding, but all the commands seem to return results immediately, including HTTPGET (which is impossible). The ROM simply sends the command then reads the data. Obviously, the data isn't available straight away, and there's no code in the ROM to wait for a response, so how do you force the Z80 to stop and wait. Could it get stuck waiting forever? Are interrupts available while it's waiting? Is the CPC internal RAM refresh still happening as it should be?