|[hatari-devel] Re: [Emutos-devel] Aranym blitter|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Thorsten Otto schrieb:
> But is this really what happens on real hardware
Is there any particular reason you don't trust Hatari's implementation here?
> ie. the blitter does not
> generate buserrors at all?
No. First of all: The Blitter doesn't *generate* bus errors, at all.
Neither does the CPU. Bus errors are (in general) generated by GLUE.
Second, it is correct -- and also quite obvious -- that there is no
CPU-side bus error trap during a Blitter transfer. When the Blitter is
in operation, the CPU has relinquished control of the bus. So, of course
the CPU will not react with a bus error trap during that time.
Naturally, the Blitter will terminate its own bus cycle upon BERR.
However it will not cease operation. Writes will silently fail and reads
will return random data -- or rather: the last word on the data bus.
This is -- as far as I understand -- consistent to the implementation in
Feel free to look into the Blitter schematic yourself. You'll see that
BERR and DTACK inputs are combined by an "or" gate right at the input.
Hence the Blitter state machine doesn't even *know* whether a bus cycle
was terminated successfully by DTACK or unsuccessfully by BERR.
> And if it is treated as an indepedent device, why
> does it depend on the supervisor state then?
This question I do not understand. Why do you think Hatari's
implementation currently depends on the supervisor state?
PS: Moving this discussion to the Hatari list.
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA