For some reason it wouldn't get positioned right when mapped in through the
blitter memory mapped location, so switched to the register mapping, which
works.
XXX colormap handling for the cursor is still broken.
configuration. This way, the delay loop is calibrated before graphics and
serial hardware is touched.
This change should smooth pr 2890 by Thorsten Frueauf (also privately
reported by Laurent Badoukh). While the real problem with those is the
paranoically high delay() calls in the grf_cl initialization, it was made
even more visible by the miscalibrated (to the save side) new style delay
loop.
making me think that the Blizzard-IV and the Blizzard-2060 scsi
options have nearly identical DMA engines (just with a different
address offset). Alas, this isn't true.
Herewith I replace the "bznsc" (all-new-Blizzard-models) driver with the
"bztzsc" (Blizzard Two Zero).
drisavar.h pretends to provide a few bus.h macros, hardwired to
that chip.
This should eventually be replaced by attachment code for the normal
com.c driver, once that one is split up into chip core driver and
attachment code, and once we have busxxx macros in NetBSD/Amiga.
Earlier, we re-complained about excessive token losses about once a minute.
However, on small ARCnet networks, the token will also be lost if only one
station (us) is active (ifconfig'd down interfaces don't take place in the
token exchange), and our syslog would be filled with repeated messages about
this condition.
Our new code only complains once, starts a timeout() each time a token
regeneration is reported by the chip, and generates a log message about
the regenerated token if it was stable for 15 seconds.
buffer out of the hardware (it is invalid!).
This fixes hangups due to spurious rx interupts.
XXX Maybe I should completely reset the hardware in this case?
Still untested on -1260/-1230, and hangs when enforcing SFAS_NO_DMA on 2060;
but works with DMA on the latter.
Still untested in a NetBSD-12A environment. (Sorry, don't have the hardware
myself.)
Thanks to Laurent Baroukh for being the guinea pig, and to Jerome Lovy
for forwarding the hardware information Phase V gave him, and to Phase
V for providing it.
clock_attach() time (for now).
This removes our dependance on the DraCo ROM access timing and frees
the second CIA on Amigas.
b) support for DraCo rev. >= 4 native timer chips.
"The mapping of IP Class D addresses to local addresses is
currently specified for the following types of networks:
[...]
o Any network that supports broadcast but not multicast,
addressing: all IP Class D addresses map to the local
broadcast address."
multi-channel driver), or to SCSI_CHANNEL_ONLY_ONE if a
single-channel driver.
(2) use scsiprint() rather than a locally-defined autoconfig print
function, and kill any locally-defined print function.
a char *, because that's what was really intended, and because
if the print function modifies the string, various things could become
unhappy (so the string should _not_ be modified).
an unrelated bug report. This will make kernel startups a bit more readable
in the presence of unsupported hardware.
Information contributed by Andreas Bussjaeger.
existence of the SCSI hardware in the boards adress region.
Thanks to Oster Nerhus for the detailed bug report and to Ralph Schmidt for
the recommended probing method.
piece of hardware into kernel virtual memory (was only a guess 'til now).
XXX Unfortunately, the hardware vendor reserves the right to change this in
future DraCo revisions. We must rethink delay() and DELAY(), at least for the
DraCo, soon.
thorpej