As the code seems to wait forever for something to happen I guess (and checked) those writes to 0x40. A write with value 0x00 seems to "cut" a line from the model1 host to one of the PALs - I think this is some IRQ line. (once per frame?). A value of 0x02 "joins" the line, so the IRQ reaches the PALs.
As there is also a link from Z80 IRQ pin to that very PAL I assume the Z80 can tie/untie itself to/from the vblank IRQ.
There is a endless loop reading from 0x8000 (internal) and if it is non zero, it decreases some counter (starting at 0x78 -- 120) which with a framerate of (close to) 60 would cause a 2 sec delay.
If I decrease that counter by hand (either by writing some bogus data to 0x8000 or) by editing the counter itself, the loop ends, another time 0x00 gets written to IO 0x40 (disabling vblank irq again) and some magic with the (not yet hooked up) DMA is starting.
---
On another front there is some logic madness seemingly connected to host writes to the memory area above the shared memory and databus bit0 that seems to control the RESET lines on the comm board.
As we know the Model1 keeps spamming 1s to 0xc00040 after posting, most likely this enables/disables the comm board.