You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Referring to this conversation and this with TubeTime on Mastodon, the analyzer doesn't handle well an output pin being used as a feedback input.
so this output (O12) is supposed to drive the enable pin on the data buffers. it looks like it was designed to release the bus during a bus error condition (BERR).
BERR is a truly bidirectional pin that drives the open-drain BERR signal on the Amiga bus. i think this is what was tripping up DuPAL.
i'm thinking about how a PAL dumping program should deal with this. ideally you have a driving circuit that can detect if the output state is 1, 0, or hi-z. if it is hi-z, then you have to treat it as an additional input.
or better yet, treat all IO pins as both inputs and outputs. drive them as if they are inputs as you walk the state tree, but always check to see if the pin state matches what you are driving. if there is a mismatch, then the pin has been turned into an output and then you 1) record the actual pin state instead of the one you are trying to drive and 2) record that it has become an output so that you can create the IO.oe term correctly.
This probably requires an overhaul of how the state map is implemented/walked through.
The text was updated successfully, but these errors were encountered:
Referring to this conversation and this with TubeTime on Mastodon, the analyzer doesn't handle well an output pin being used as a feedback input.
This probably requires an overhaul of how the state map is implemented/walked through.
The text was updated successfully, but these errors were encountered: