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.
* 4AM for afternoon of August 4th, 2019 (nw)
* Continue the work on the CoCo floppy softlist (nw)
* Add the 4.0 version of Kobayashi Alternative (nw)
* CoCo disk fixes for OS-9, add a few other disks (nw)
Progress will be slow for awhile on the CoCo side..
* CoCo updates.. (nw)
Rip out the OS-9 stuff until I can figure out what's actually going on with the disks.
Add several things that I actually CAN confirm in the meantime.
* More CoCo work.. (nw)
Also try to get the disk names into what will hopefully be TOSEC-compliant formatting so I can contribute across both..
* More CoCo adjustments (nw)
Get the naming a bit closer to TOSEC standard so we can try to contribute this stuff back directly where possible.
Removed the v3.5 version of CoCo Max III until I have a better idea on how legitimate this disk actually is.
* Small metadata adjustment for a2_flop_misc: stkoba40 metadata (nw)
* WOZ originals up to date with 4AM as of August 13th, 2019 (nw)
* Apple to morning of August 15th, 2019 (nw)
* Add the new Yakyuu-Kyou (ヤキュウキョウ) dump for SMC 777 (not working) (nw)
Crashes at startup, but we can at least document it.
