This is an alternate approach proposed by Sean Nolan in 1987 which
allows placing the driver files in a subdirectory of the root volume
to avoid clutter and file ordering issues. Only a SETUP.SYSTEM file is
needed at the top level, and the drivers go into a SETUPS/ directory.
All drivers here (except QUIT.SYSTEM and SETUP.SYSTEM itself) have
alternate forms built into the /DRIVERS/SETUPS/ directory as XYZ.SETUP
instead of XYZ.SYSTEM. If you choose to use SETUP.SYSTEM, place these
.SETUP files in your SETUPS/ directory. The naming doesn't matter -
any SYS or BIN file can be used - but this convention makes
distribution easier. These .SETUP files do **NOT** chain to the next
file - that's handled by SETUP.SYSTEM itself.
Resolves#16
If ProDOS finds a ThunderClock it installs a built-in driver for it.
The ThunderClock card gives day-of-week but not year. So the driver
uses the day/month/day-of-week to infer the year, using a 7-entry
table. This means the driver gives the wrong year unless it is
reasonably updated.
ProDOS 2.4.2 includes an update to handle 2018-2023 but that's about
to run out. https://github.com/ProDOS-8/ProDOS8-Testing/issues/72
Make the CLOCK.SYSTEM jumbo driver do the extra work of updating the
year table for the ThunderClock driver. This handles old versions of
ProDOS from 1.1 through 2.4.2, and the update handles 2023 through
2028. (In 2027 we can update again to handle through 2032.)
This detects a ZIP CHIP and, if present, configures it to slow down
for speaker access, leaving the other settings alone.
In the future maybe there will be a configuration utility to control
the slots, as was included with the ZIP CHIP back in the day.
In MAME, for the SSC in Slot 2, the STATUS flag never comes back with
ready-to-send, so the probe would hang. Introduce a timer, same as on
the receiving side, and timeout instead of hanging.
Similar to 14e72b7384
The change in b182a53d made resetting/detecting The Cricket! fail on
my Laser 128EX, likely due to startup config of the SSC not being
the same as on an Apple //c. This should be a superset of the change,
but compat testing will be needed.
This appears to improve reliability when reading the NSC on the
IIc+. More data is probably needed before declaring this a really
good solution, but "it works on my machine!"
* The Cricket!: fix hang on Total Replay
The Cricket reset command sends Total Replay into an endless loop when launched, presumably because of an interrupt situation (TR just does RTI on an interrupt). Toggling the COMMAND and CONTROL settings seems to allow TR to function properly, while also allowing the Cricket initialization code to silence any playing notes.
* The Cricket!: Reset Cricket before probing
Finds the Cricket every single time this way. Occasionally the driver would miss finding it due to it being in a wait state. Sending a reset first fixes that.
* The Cricket!: make sure registers are toggled for TR
This stops any active music playback, which is handy if you did a warm
boot in the middle of playback, and your The Cricket! is stuck playing
the same note constantly but you don't want to power-cycle the device
which will unset the RTC.
c/o @frankmilliron
... and don't bother saving/restoring registers during install,
as this will only follow a boot or OS restart.
Suggested by @frankmilliron
Also inhibit interrupts in the SET.XXX utilities for good measure.
* Replace BCD->Binary with smaller routine
* Replace most absolute use of $200-7 with stack
* Remove unneeded sentinel byte at end of unlock sequence
Leaves 9 bytes free in driver.
The NSC driver installer starts off by checking each slot, bit-banging
into the card's memory space to try and detect an NSC installed. If a
Z80 card is encountered before the NSC is hit, the Z80 card is
activated, causing the 6502 to halt.
Borrow the Z80 detection routine from A2D's This Apple and verify that
there isn't a Z80 in the slot before we start bit-banging.
Fixes#15
When a SmartPort device was found that wasn't the FujiNet, the search
continuation used the wrong offset to get the high byte of the slot
address.
Also, fix the "jumbo" clock driver's Makefile to ensure it is rebuilt
when dependencies change.
This one driver pulls in the installers for each other clock driver,
and invokes each in turn:
* No-Slot Clock
* ROMX
* FujiNet
* DClock
* Cricket!
This requires adding `.ifndef JUMBO` guards in the other drivers for
when they pull in include files (symbols, macros, etc). The other
drivers are adjusted to return with carry clear on successful install,
failure otherwise.
Previously, the boot volume was shown first, but then tab would cycle
from the highest priority volume to the lowest. This would be awkward
if the boot volume was not the highest priority volume. For example,
with these devices (listed lowest to highest priority, like DEVLST),
/HD1 is the boot volume but the RAM disks are highest priority:
(low) /FLOPPY2 /FLOPPY1 /HD4 /HD3 /HD2 /HD1 /RAMWORKS /RAM (high)
Prior to this fix, it would cycle:
/HD1 /RAM /RAMWORKS /HD1 /HD2 /HD3 /HD4 /FLOPPY1 /FLOPPY2 /RAM ...
After this fix, it will cycle:
/HD1 /HD2 /HD3 /HD4 /FLOPPY1 /FLOPPY2 /RAM /RAMWORKS /HD1 ...
To fit, a little bit of code golfing was necessary.
ProDOS prefers disks sorted with the fastest (e.g. ramdisks) at the
end and slowest (e.g. 5.25 floppies) at the start. This facilitates
pathname resolution starting at the end of DEVLST, so misses are
cheap.
Joshua Bell
frankmilliron
Ivan Izaguirre
Chris Parana