Bit 7 of the control register inhibits all drive select lines when high and
this is now implemented. This was a long standing feature in this line of
floppy disk controller boards. The drives are also inhibited when the motor
timer has timed out. It is not just their motors that are off.
Add a conf option to interpret bit 7 of the control register as an 'erroneous'
side select, and log such usage. Some drivers use bit 7 for side selection and
this option help work around them and adapt them.
Add support to set the clock rate using the DC5 extended control register, and
update the associated code. The clock rate config option is now only an
'expected' rate and may be null.
Clarify that the motor timer is only triggered by access to the FDC registers
and not by access to the control registers. There appears to be a common error
in drivers, they access the control register and then wait a period, and it
appears they wait for the motor to spin up, but that can not happen. The
problem appears to be documented, flaky disk booting, having to reset and try
again and again. It seems best to deal with that in boot and driver software
rather than an emulator hack.
The motors are on, or off, irrespective of drive selection.
Rewrite the updating of the floppy and FDC state based on the control register
and the motor timer out, so that the latched control register state is
respected when the motor timer output changes - it had been just turning the
motors on or off but the drive selection also needs to be updated.
Reset the DDEN input, setting it for single density, upon device reset.
Default DC5 to 16 byte address mode to suit the SWTPC 6809 - the SWTPC 6800
overrides this default for it's 4 byte address mode.
Indentation fixes.
- Created emu.register_before_load_settings(), to allow LUA scripts to
override default input port values before settings are loaded
- New ioport_field methods/props ([set_]default_input_seq(), port)
This seems to work around a problem that (at least for me) caused the
'sol::object seq' parameter to not properly handle a specified
sol::user<input_seq>.
This problem could be reproduced with the following command at the LUA
console:
manager:machine():input():seq_poll_start("absolute",
manager:machine():input():seq_from_tokens("KEYCODE_Q"))
I would feel more comfortable if I understood why the existing code
failed; it isn't clear to me if this is a bug in our sol handling for
input_item_class, a bug in sol itself, or a compiler bug, but this
change works for me and should definitely not introduce any problems.
