there aren't any schematics available, but that's not too much of a problem.
Notices by Tube🌞Time (tubetime@mastodon.social), page 5
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:22 JST Tube🌞Time -
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:22 JST Tube🌞Time these two ROMs are for auto start, allowing the Amiga to boot from the hard drive. it can even load the Kickstart disk from a special drive partition!
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:22 JST Tube🌞Time it's got a battery because it is also a real-time clock (the Amiga 1000 doesn't have one).
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:22 JST Tube🌞Time here's a neat and rare bit of hardware: the Comspec SA-1000 SCSI sidecar for the Amiga 1000!
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:21 JST Tube🌞Time got a whole pile of equations. due to the way that DuPAL works, i usually get "extra" terms that aren't real. in this case, the highlighted terms appear in common with every single output term and are spurious. it's probably due to the table not being filled out completely--there are some output combinations that aren't possible.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:21 JST Tube🌞Time the PALs are locked, so I need to use a DuPAL to reverse engineer them.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:21 JST Tube🌞Time and the schematic! it still needs a bit of work since i don't fully understand it, but i understand the basic functionality.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:21 JST Tube🌞Time nice, got the layout basically done.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:20 JST Tube🌞Time 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.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:20 JST Tube🌞Time 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).
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:20 JST Tube🌞Time having trouble with one of the PALs causing DuPAL to quit early, so I taped over that pin to get a dump of the rest of the pins (assuming this one doesn't feed back into any of the input terms)
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:20 JST Tube🌞Time i also like to use the DuPAL "Peeper" tool to manually toggle the pin states and confirm my equations. the newest version can also detect tristated outputs (yellow color code). quite handy!
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:19 JST Tube🌞Time anyway i think i have this thing 99% figured out. something that stumped me for a bit is the bus connector here. all the signals are passed through from the Amiga side (blue/green connector) to the card edge side (going to the next sidecar expansion) with two exceptions -- see the weird pins that stick out.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:19 JST Tube🌞Time 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.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:19 JST Tube🌞Time 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.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:18 JST Tube🌞Time in this design, pin 11 is used for something else: a card select signal that goes the opposite direction as the config done signal. if the expansion sidecar detects that it is being addressed, it asserts the CD_SEL# output that goes to the *downstream* sidecar (closer to the A1000). the downstream card sees this signal as UPS_CD_SEL#.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:18 JST Tube🌞Time this is very similar to how autoconfig is done on the later Amigas, which uses pin 12 and pin 11 to create a "daisy chain" config mechanism.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:18 JST Tube🌞Time the first pin is a CONFIG_IN# signal that comes on pin 12. if it is ground, then the card decodes the address space at E8xxxx -- the Amiga autoconfig space. this pin is always grounded on the A1000. once the card completes its config, it remaps that space to somewhere else in memory, and then pulls the CONFIG_DONE# line low, signaling the next sidecar expansion to do its autoconfig.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:17 JST Tube🌞Time here's how the address gets decoded. the register on the left is normally disabled, so the pullup and pulldown resistor arrays set up the address comparator to "E8" which is the autoconfig space. during configuration, the card gets assigned a new address which gets latched in the register and overrides the default address. simple and elegant.
-
Embed this notice
Tube🌞Time (tubetime@mastodon.social)'s status on Tuesday, 21-May-2024 10:21:17 JST Tube🌞Time UPS_CD_SEL# from the point of view of the downstream sidecar means that the sidecar upstream has decoded the current address. if this signal is active and your own address decoder is also active, that means that both expansions are trying to decode the same address, which is a conflict! one of the PALs detects this and asserts BERR# (bus error).