reenigne
Veteran Member
I've got my XT set up so that I can remotely run programs on it from a laptop in a different room of my house, get results back over the serial connection and also remotely power-cycle it.
One thing I've been thinking about doing with this setup is putting it online so that anybody who wants to can do the same thing - I suspect there a few people here who would find that useful for profiling code, writing emulators and generally poking into the less well-known behaviors of the machine.
I'm worried about the possibility of killer pokes, though - I don't want someone to be able to run code which will damage the machine. It won't be connected to a monitor, so there's no worries about stuffing bad values into the CRTC registers and breaking flyback transformers. I have a capture card I can connect to the composite output of the CGA so that people can see what's on the screen. I'll probably also limit how long programs can run, both to avoid tying up the machine with crashed programs, and also to avoid wearing out floppies by leaving the motor spinning for too long.
One thing that is a concern is the possibility of reprogramming the 8255 PPI IO lines that are supposed to be inputs to instead be outputs and driving them to different voltages than they would otherwise be, causing overly large currents to flow. Has anybody actually done this and determined if it actually does or doesn't damage anything? Would it have been standard for devices like this to include current-limiting resistors on their output circuits? I checked the datasheet but it was inconclusive. I suppose if that is a real problem I could remove the 8255 and replace it with a daughterboard containing the 8255 and some resistors on the output pins.
Do you know of any other killer pokes for the XT?
If I ever finish my cycle-exact emulator, I suppose I could use it to check for any hostile behavior, but then any software-detectable inaccuracy in the emulation could be used by an attacker to determine if they were running on the emulator or the real hardware and deploy the payload only on the real hardware. And if it is perfectly accurate then it would make running programs on the actual hardware rather pointless (although still cool!)
One thing I've been thinking about doing with this setup is putting it online so that anybody who wants to can do the same thing - I suspect there a few people here who would find that useful for profiling code, writing emulators and generally poking into the less well-known behaviors of the machine.
I'm worried about the possibility of killer pokes, though - I don't want someone to be able to run code which will damage the machine. It won't be connected to a monitor, so there's no worries about stuffing bad values into the CRTC registers and breaking flyback transformers. I have a capture card I can connect to the composite output of the CGA so that people can see what's on the screen. I'll probably also limit how long programs can run, both to avoid tying up the machine with crashed programs, and also to avoid wearing out floppies by leaving the motor spinning for too long.
One thing that is a concern is the possibility of reprogramming the 8255 PPI IO lines that are supposed to be inputs to instead be outputs and driving them to different voltages than they would otherwise be, causing overly large currents to flow. Has anybody actually done this and determined if it actually does or doesn't damage anything? Would it have been standard for devices like this to include current-limiting resistors on their output circuits? I checked the datasheet but it was inconclusive. I suppose if that is a real problem I could remove the 8255 and replace it with a daughterboard containing the 8255 and some resistors on the output pins.
Do you know of any other killer pokes for the XT?
If I ever finish my cycle-exact emulator, I suppose I could use it to check for any hostile behavior, but then any software-detectable inaccuracy in the emulation could be used by an attacker to determine if they were running on the emulator or the real hardware and deploy the payload only on the real hardware. And if it is perfectly accurate then it would make running programs on the actual hardware rather pointless (although still cool!)