Micron Xceed SE/306-48 and SE/30 issue

[zigzagjoe]

Been fiddling with this card again, now that I have my Hakko FR-301 I've been able to easily socket most of the chips.

I've discovered that if I remove either U42 (address decoder) or U38 (bus cycle control) the SE/30 will start up.

Validating this statement, I can get a start up if I lift both the /BERR and /HALT pins on U38, and Tattletech sees the card too.

I'd quite like to try replacments for those two GALs to see if one of them is malfunctioning. Since we have the equations in the technical handbook, would something like EQN2JED produce a valid Jedec file that I can use to flash a new chip?

You've exactly got it. Assemble those into a .jed, stick them on a PAL, GAL, or ATF of appropriate speed rating and plug it in.

You just need to identify what format that is in. It's not EQN2JED. Looks like CUPL to me.

 

[croissantking]

I used WinCUPL to convert the code into .jed files for U38 and U42, and burned them onto a couple of GAL16V8s. Observations as follows:

- With U38 swapped in, no change in behaviour. (hung on simasimac stuck in a bus retry loop)

- With U42 swapped in, boots up if harness not attached (or attached but with the switch in the off position); hangs if harness attached. This is a notable change in behaviour, although it still doesn’t see the card.

- With both U38 and U42 swapped in, the Mac boots but doesn’t see the card.

Of course, I’m not able to verify if the custom burned GALs are functioning exactly the same as the originals, so this isn't thoroughly conclusive.


Going in another direction now, I already know I can get the SE/30 to boot and detect the card (but no image) if I lift the /BERR pin on U38.

U38 asserts /BERR if any of following three statements are true (! indicates 'not active'):

COUNT4 & !SAMPLE & STRMCLOCK (Condition 1)
COUNT4 & BERR (Condition 2)
COUNT5 & !STRMCLOCK (Condition 3)

I altered the code for U38 to remove each one of these statements in turn, and found that if the last one - COUNT5 & !STRMCLOCK - is deleted, the Mac will boot and see the card. So this narrows the issue down to probably COUNT5, an internal state variable, not advancing.

All very interesting and perplexing.

 

[zigzagjoe]

I used WinCUPL to convert the code into .jed files for U38 and U42, and burned them onto a couple of GAL16V8s. Observations as follows:

- With U38 swapped in, no change in behaviour. (hung on simasimac stuck in a bus retry loop)

- With U42 swapped in, boots up if harness not attached (or attached but with the switch in the off position); hangs if harness attached. This is a notable change in behaviour, although it still doesn’t see the card.

- With both U38 and U42 swapped in, the Mac boots but doesn’t see the card.

Of course, I’m not able to verify if the custom burned GALs are functioning exactly the same as the originals, so this isn't thoroughly conclusive.


Going in another direction now, I already know I can get the SE/30 to boot and detect the card (but no image) if I lift the /BERR pin on U38.

U38 asserts /BERR if any of following three statements are true (! indicates 'not active'):

COUNT4 & !SAMPLE & STRMCLOCK (Condition 1)
COUNT4 & BERR (Condition 2)
COUNT5 & !STRMCLOCK (Condition 3)

I altered the code for U38 to remove each one of these statements in turn, and found that if the last one - COUNT5 & !STRMCLOCK - is deleted, the Mac will boot and see the card. So this narrows the issue down to probably COUNT5, an internal state variable, not advancing.

All very interesting and perplexing.

Sounds like STRMCLOCK signal should be probed. That would seem to agree with the card thinking that it needs more time and issuing a /BERR+HALT to get a bus retry.

 

[croissantking]

Sounds like STRMCLOCK signal should be probed. That would seem to agree with the card thinking that it needs more time and issuing a /BERR+HALT to get a bus retry.

I probed that with my multimeter and it shows 15.66 MHz, the same as CPUCLOCK. Next step is to check with my logic probe that it’s a clean signal.

Since it’s generated by the SE/30’s own crystal it’s hard to imagine there’d be anything wrong with it. But the GAL code suggests that the pin might either be active or inactive, which I don’t understand. Doesn’t seem like there’s any logic that could toggle the signal on or off, it’s directly connected to the PDS connector (I think).

 

[zigzagjoe]

I probed that with my multimeter and it shows 15.66 MHz, the same as CPUCLOCK. Next step is to check with my logic probe that it’s a clean signal.

Since it’s generated by the SE/30’s own crystal it’s hard to imagine there’d be anything wrong with it. But the GAL code suggests that the pin might either be active or inactive, which I don’t understand. Doesn’t seem like there’s any logic that could toggle the signal on or off, it’s directly connected to the PDS connector (I think).

Based on that snippet above, that signal is sensitive to clock state. Since a clock signal is toggling on and off regularly (hence the name ) sometimes you need your logic to have certain behaviors under specific clock conditions in order to meet timing requirements. For example, /STERM has some fairly stringent conditions under which it should be asserted or you run the risk of latching invalid data into the CPU OR the CPU not registering it meaning your state machine might enter an invalid state. /DSACK (asynchronous) acknowledge strobe has looser timing requirements, but if you assert it while meeting certain timing requirements you can guarantee it will be deterministically registered by the CPU.

An example I use, after /DSACK has been asserted and registered by the 68030, /AS will go high during the next low clock cycle. I hold the output-enable for DSACK for the duration of that low clock cycle (despite /AS going high) to give some time to drive /DSACK high before releasing it.

Though it shouldn't be an issue here if you're just testing with the one card, the SE/30 has a particularly flaccid clock signal as it is very overloaded. More than one PDS card (and especially MacCons) can overload the clock to the point where the system won't work, so it's best practice for any cards with a passthrough slot to buffer the clock (at the cost of a small phase shift) to provide a strong clock for downstream cards.

 

[croissantking]

Based on that snippet above, that signal is sensitive to clock state. Since a clock signal is toggling on and off regularly (hence the name ) sometimes you need your logic to have certain behaviors under specific clock conditions in order to meet timing requirements. For example, /STERM has some fairly stringent conditions under which it should be asserted or you run the risk of latching invalid data into the CPU OR the CPU not registering it meaning your state machine might enter an invalid state. /DSACK (asynchronous) acknowledge strobe has looser timing requirements, but if you assert it while meeting certain timing requirements you can guarantee it will be deterministically registered by the CPU.

An example I use, after /DSACK has been asserted and registered by the 68030, /AS will go high during the next low clock cycle. I hold the output-enable for DSACK for the duration of that low clock cycle (despite /AS going high) to give some time to drive /DSACK high before releasing it.

Though it shouldn't be an issue here if you're just testing with the one card, the SE/30 has a particularly flaccid clock signal as it is very overloaded. More than one PDS card (and especially MacCons) can overload the clock to the point where the system won't work, so it's best practice for any cards with a passthrough slot to buffer the clock (at the cost of a small phase shift) to provide a strong clock for downstream cards.

Of course! Duh! A clock signal rapidly toggles so it very much is constantly either active or inactive at regular intervals. I'm still learning and I wasn't thinking of it in the right way. Right, so that's how the state machine advances, it watches for the clock oscillation, amongst other variables.

 

[zigzagjoe]

Of course! Duh! A clock signal rapidly toggles so it very much is constantly either active or inactive at regular intervals. I'm still learning and I wasn't thinking of it in the right way. Right, so that's how the state machine advances, it watches for the clock oscillation, amongst other variables.

Exactly I'm sure they've probably got a counter in there (the count variable names do kinda give it away) to help sequence accesses too, so it seems like something is going wrong there as you found.

I do similar things to control behaviors on my nuCF card and boosters, advance a counter based off the clock and take actions as it hits certain points.