Gregory's Servergot 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.
|
34 comments
@tubetime Oh that's very handy, all the more reason for me to finally build up my DuPAL board up  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) 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. 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. 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. 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. 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#. 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). 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. i've been reading the Amiga 1000 Assembly and Component Level Repair manual and found this interesting memory map diagram. notice what is stored from F00000-F7FFFF? it is marked "CART." could this have been for a game cartridge slot? the Comspec SCSI card puts its autostart ROM here. @tubetime most likely it is a remnant of the old game console design, but it was also heavily used in os development for temporarily loading new ROM modules when testing, and also many expansions used it for their roms if they did not do autoconfigure. here's the Comspec SCSI drive enclosure. it's a bit of a beast and supports two half height drives. Comspec was definitely Canadian; check out that mounting screw!  @tubetime Brings back many fond memories of ST-225Ns! And the vias on that board are strangely attractive… the circuit is similar to the "typical application circuit" and it looks like there are two small electrolytic capacitors on the UC3842 VCC rail that have gone super leaky, preventing it from bootstrapping and powering up. it was a simple enough fix. the yellow screen means it is trying to load the Kickstart off of a special drive partition. oh that's not good, it blinks red 8 times. this means the drive failed the SCSI mode sense command for some reason. weird. @tubetime Is that something special added by the controller interface? Or is the onboard boot room able to look for kickstart other than the floppy disk? @ChartreuseK the onboard (non kickstart) ROM looks at F00000 and finds the controller ROM, which then takes over the boot process. i think this was originally for supporting game cartridges @tubetime Ah okay, didn't know that was a thing it did. Certainly a nice feature to not need the kickstart disk to boot a hard disk  @tubetime I've run into this in audio amplifiers too. They have a bootstrap pin which is connected to a RC network off a supply voltage - the cap charges up slowly once the power comes on and eventually lets the amp come out of inhibit. It's a power up thump avoidance thingy. And yeah, when the cap fails short, the amp plays dead  @tubetime Sounds like a job for the Glasgow Interface Explorer.  @tubetime I've used a resistor voltage divisor to bias the pin to 1.4V (haflway between TTL receiver thresholds), and two comparators at the thresholds. |
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!