(thesing@cs.uni-sb.de), heavily hacked upon by me to
- make it work with -current audio system
- make it shut off Amiga audio DMA only at appropriate places.
XXX A couple of bugs still remain, which well be handled later.
XXX Among them: only mono output; doesn't refuse to handle input, but chokes;
will not play last millichunk (is this 20 ms?) of data.
>Signed shifts are evil.
>Thanks to Michael Smith for reporting, Jason Thorpe for pointing to the
>report, doing a quick workaround which pointed me to the right code part and
>for testing the final fix.
Some of the stuff (e.g., rarpd, bootpd, dhcpd etc., libsa) still will
only support Ethernet. Tcpdump itself should be ok, but libpcap needs
lot of work.
For the detailed change history, look at the commit log entries for
the is-newarp branch.
- Fixes for Interlace and DoubleScan
- Memorysizedetction for 1MB Bords
- Clockdoubling for PicassoIV and PiccoloSD64
NOTE: Don't use the X11R6.1 Xserver with -useHWC on the SD64
with a gfxmode >80Mhz or you get a broken mousepointer.
- HiColor and TrueColor Support
(doesn't work yet, since it needs some fixes for the XServer)
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?
