Jump to content
Sign in to follow this  
Trash80toHP_Mini

Is an inverter bi-directional: 74LS04 specifically?

Recommended Posts

Need some general Digital Logic help here, gang.

 

None of the datasheets say whether the 04 inverts a signal going both ways. The arrow shape in the graphic tells me no and my gut tells me it must be an "understood" kinda deal that inverting a signal is a one way street? EVERY hit I get for bi-directional inverter is either another useless data sheet or worse, info on bi-directional AC/DC Inverters.

 

I REALLY need some help here, color me clueless/confused/concerned. :blink:

 

@Bolle is asleep and this one will keep me awake, so:

LC-030-Logic-0-003.jpg

Those arrows look ominous and have for some time.

 

Here's the first bit of digital logic gibberish Bolle tossed my way:

 

Bildschirmfoto 2019-04-28 um 11.52.26.png

 

 

This is Bolle's schematic in Greek as far as I'm concerned. But even after 45 years of corrosion from disuse, I'm probably still a little bit better at reading Greek than schematic.

 

Bildschirmfoto 2019-05-05 um 18.40.53.png

 

My major concern is that we've got the LC PDS -> 030 PDS figured out, but there's either a disconnect or a wrong connection going from back to the NIC from 030 PDS -> LC PDS?

 

My heebiejeebies tell me we need the other three inverters on the way back to the NIC and diodes to direct the two opposing lanes of traffic? But I know next to nothing about digital logic. It looks like a bunch of pipe, valves, a whackdoodle silt collector cyclone/mixing valve thingie that needs backflow prevention valves in some mixed up section of my digitally impaired analog visual cortex. I don't think what I use for a brain will ever transition to digital. Fluidic logic I can "see" digital  .  .  .

 

HELP!!!! 8-o

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Shortest answer: no.

 

Followup: why in the world do you think it would need to be here? I haven't been following the other thread particularly closely but my vague understanding of what this inverter is for is to change the address at which some hardware on the peripheral card you have there will "wake up". Unless this peripheral is going to be doing bus mastering it's always going to be the computer driving the address bus lines so... again, why would you need the inverter to be bidirectional? 

Share this post


Link to post
Share on other sites

Thanks! That's what I thought.

 

As I understand it, the inverter has the NIC filling memory locations in $A or $9 space instead of the stomping on the memory space of the SE/30 video subsystem at $E as it would be doing without one line being inverted for $A or all three inverted for $9.

 

When the SE/30 needs to feed data to the NIC, it's controlling the address lines, no? From the wiring of the inverter as is, I see none of those three address lines making a return trip over any wire to the NIC. I see a disconnect when the Jumper Blocks are configured to send the Address signals through the inverter on a one way trip. I see no connection back to the NIC for any of those three address lines. The NIC still thinks it's in $E and the SE/30 will be thinking it's at $9 or $A. I'm thinking those three lines from 030 PDS -> NIC need to be provided at best and inverted on the way at worst. The diode check valve thing is the only way I can describe controlling the flow of traffic on the ingoing and outgoing lanes.

 

My heebejebies are about the missing return leg on the journey of those three address lines to the NIC? Is something missing as is or am I missing something here?

 

 

edit: maybe I've got it backwards? trag was helping me a bit, but he'a really busy at work. He said we shouldn't assume the outgoing leg of the inverter was tri-stated as null. That's why I cut it completely out of circuit when not in use in my diagram. From the non-mastering point of view, does Bolle's initial diagram do the trick in both directions?

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

Well... as Gorgonops said we don’t have to worry about the other direction unless we want to use a bus master card.

It‘s the host machine setting up the address lines all the time. The card latches in that address and presents whatever data it has on that address on a read from the card or waits for a strobe signal to read in data from the host bus on a write to the card. Those are the only two scenarios that should be happening on a non-busmaster card.

 

If we want to support bus mastering it would be easiest to do this with some programmable logic.

Have the address lines as feedback pins and monitor the R/W line as well as /BGACK to see if the card is in control of the bus. Address signals get inverted in both directions then and tri-stated accordingly if not used using OE conditions.

Share this post


Link to post
Share on other sites

OK, thanks guys. This stuff is still clear as Koine Greek, but at least I can go to sleep now.

 

Is my "blocks of four" jumper setup for the inverter good to go as is?

Share this post


Link to post
Share on other sites

This is me being ignorant about the exact machinations going on in the parent thread again, and also probably ignorant about the requirements of PDS card re: 24 and 32 bit mode, but I'm going to toss this out there: I see you're putting inverters on the A20, A21, and A22 because you want to munge $A0 0000  into $90 0000. (Or was it vice versa? Whatever, it's not important.) Are you *sure* that's what you want to be doing? Here is why I ask, from page 307 of "DCaDftMF, 2nd ed.":

 

image.png.a44a9fbc61375f54d540e1abca2c3d94.png

 

IE, it was my vaguest of understandings that in a Macintosh a card didn't really need to worry its head about whether it was running in 24 vs. 32 bit mode, the hardware was always designed for the 16MB "normal" Slot spaces at F9xx:xxxx to $FExx:xxxx and the PMMU (or that simpler mapper unit that was in the Mac II and the original LC) was used to remap the first 1MB of that normal slot space into the 24 bit slice.

*IF* that gibberish I said above is true wouldn't it follow that messing with the A20-A22 address lines would at best be unnecessary and at worst be deeply counterproductive? I dunno, maybe I'm totally missing something here.

 

Share this post


Link to post
Share on other sites

My specific thought was in reference to the middle diagram that jt posted above.    It wasn't clear to me whether the red wires or the blue wires were meant to be input/output.

 

Case 1:  If the blue wire was in, and the red wire was out, then one could get the inverted address by putting a jumper on 2-3.   However, if one wanted the uninverted address, putting a jumper on 1-2 would get you a mix of the uninverted address and whatever the floating inverter happened to be outputting.

 

Case 2:  If the blue wire is out and the red wire is in, this works much better.   Now the uninverted address is available on pin 1 of the jumper.  The inverted address is available on pin 3 of the jumper.  One connects the output line, pin 2 of the jumper, to either pin 1 or pin 3 to obtain either the uninverted or the inverted address, respectively.     The problem  with this diagram is that, as far as I can tell, it is using the inverteres on the 7404 backwards.    In other words, pin 1 is connected to the output of the inverter.  Pin 3 is connected to the input of the inverter.

 

So, I don't think either case works, but I think Case 2 is the better choice if one just reverses which pins of the 7404 pins 1 & 3 of the jumper connect to.

Share this post


Link to post
Share on other sites
24 minutes ago, trag said:

Case 1:  If the blue wire was in, and the red wire was out, then one could get the inverted address by putting a jumper on 2-3.   However, if one wanted the uninverted address, putting a jumper on 1-2 would get you a mix of the uninverted address and whatever the floating inverter happened to be outputting.

That is a really good point. You're far better off leaving the output waving in the wind when the jumper's not being used than the input.

I still stand by my suggestion that this whole thing might be on the wrong set of address lines in the first place, but I might also be on crack for saying that.

Share this post


Link to post
Share on other sites

Dunno about any of this crap, obviously, but this is what's set up on the board. Gut tells me I may need to swap input/output sources for the inverters, but like I said  .  .  .

 

WKSHT-LOGIC-0-002.jpg

 

Using two pairs of jumpers for each line I take the inverter entirely out of circuit instead of worrying about signals swaying in the breeze from whichever direction.

-  four shorting blocks installed as shown sets the board up for $A memory ops (need to set a block in the diagram for the IRQ to Slot $A as well)

-  changing orientation and adding another pair of blocks sets it up for $9 memory ops

-  three in a row straight across the top sends all address lines straight thu, kicking $E Video ops in the groin, but we gotta test it. [}:)]

 

Just need to know if I need to reverse the inputs/outputs before I start to wrap.

Share this post


Link to post
Share on other sites
10 hours ago, Gorgonops said:

This is me being ignorant about the exact machinations going on in the parent thread again, and also probably ignorant about the requirements of PDS card re: 24 and 32 bit mode, but I'm going to toss this out there: I see you're putting inverters on the A20, A21, and A22 because you want to munge $A0 0000  into $90 0000. (Or was it vice versa? Whatever, it's not important.) Are you *sure* that's what you want to be doing?

I can help a bit there: we've set aside any possible 32 bit addressing considerations for the time being. We'll be testing for bare function in the SE/30 in 24-bit mode only.

 

The NIC thinks it's at $E00 0000 - whatever and inverting A22 dumps it over into thinking it's in $A00 0000 - whatever. Invert all three lines and shazzam, it's supposed act like it's in $900 0000 - whatever. That just happens to be the IIsi NuBus Adapter Slot ID, which I thought might somehow be magical. ::)

 

So switching from Slot E space to Slot A space is the requirement. Further decoding to include the Slot 9 space gambit was to keep me happy in my superstitious, blissful ignorance. :blink:

 

edit: technically the NIC isn't thinking anything, I know, but that's the way I could get it into words. Acting in a way that works  .  .  .  nevermind.

Edited by Trash80toHP_Mini
I'm an idiot. :-/

Share this post


Link to post
Share on other sites
19 minutes ago, Trash80toHP_Mini said:

can help a bit there: we've set aside any possible 32 bit addressing considerations for the time being. We'll be testing for bare function in the SE/30 in 24-bit mode only.

My point is that I'm not entirely convinced you are hitting the correct address lines. The Apple manual reads an awful lot like the MMU takes care of presenting a 24 bit view of the 32 bit normal slot space, that you don't need to have two separate sets of decode on the card. And if that is actually true then inverters on A20-22 are not going to change the address decoding in a useful way. To modify the 16MB slot space you should be playing with A24-26. And worse, if you really think there is going to be a problem with a conflict in 32bit mode you can't get away with ignoring it because it also reads to me like during hardware initialization it's going to be in 32 bit mode when it's looking for declaration ROMs, etc, regardless of what the control panel setting for the OS is.

 

I also got the distinct feeling looking at the third edition of the "Designing..." Manual's LC PDS section that there are some wrinkles about how chip select works for LC PDS that are different enough from 030 PDS that you're going to need to address them too. (You did notice how the LC PDS is missing A28-30, right?) But, hey, maybe I have no idea.

Share this post


Link to post
Share on other sites
15 minutes ago, Gorgonops said:

My point is that I'm not entirely convinced you are hitting the correct address lines.

Got that, just wanted to let you know where we thought we were coming from.

 

Those are some nasty problems.

Quote

I also got the distinct feeling looking at the third edition of the "Designing..." Manual's LC PDS section that there are some wrinkles about how chip select works for LC PDS  .  .  .

Yep, I thought even more were missing. I dumbed my LCIII 030 PDS to 68030 IIsi PDS graphic down for this insanity. I thought even more were missing from the 020 LC PDS, but apparently I missed that.

 

What's nagged me all along was the notation that /SLOTIRQ.E acts like NMRQ on NuBus Macs. Doesn't sound at all SE/30 tolerant. Found it, it's at the bottom.

 

RosettaCache-01-002.jpg

 

Sorry about the editing, I hit quote and everything went downhill from there. :-/

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
41 minutes ago, Gorgonops said:

My point is that I'm not entirely convinced you are hitting the correct address lines. The Apple manual reads an awful lot like the MMU takes care of presenting a 24 bit view of the 32 bit normal slot space, that you don't need to have two separate sets of decode on the card. And if that is actually true then inverters on A20-22 are not going to change the address decoding in a useful way. To modify the 16MB slot space you should be playing with A24-26. And worse, if you really think there is going to be a problem with a conflict in 32bit mode you can't get away with ignoring it because it also reads to me like during hardware initialization it's going to be in 32 bit mode when it's looking for declaration ROMs, etc, regardless of what the control panel setting for the OS is.

 

I also got the distinct feeling looking at the third edition of the "Designing..." Manual's LC PDS section that there are some wrinkles about how chip select works for LC PDS that are different enough from 030 PDS that you're going to need to address them too. (You did notice how the LC PDS is missing A28-30, right?) But, hey, maybe I have no idea.

 

The presented addresses differ in 24 and 32bit mode on the LC. Verified that in the other thread (why do we have two now anyways?)

 

Solution on how to handle 24/32bit mode switches to fool the LCPDS CS decoders are there as well. You’re right, A28-30 are involved... we basically need another address decoder to decode the full address. /FC3 is used on the LCPDS to compensate for the missing address lines.

 

Edited by Bolle

Share this post


Link to post
Share on other sites
4 minutes ago, Bolle said:

(why do we have two now anyways?)

Because I was afraid of digital logic in the night and needed a simple answer before I could crawl into bed. [:I]

 

It got interesting after G gave me the easy one and then went on to make fun of me. [:)]

Share this post


Link to post
Share on other sites

That doesn't read the way I meant it, sorry, G. What I meant to imply was that every time I see you answer simply, sigh, take it a step back and expand upon the fallacy of my thinking I learn a crap ton of new and interesting stuff. Thank you.

Share this post


Link to post
Share on other sites

@Bolle having the technical side of the other thread break out into a serious discussion here is serendipity in action.

 

The IP of the other thread advertises it as the shot in the dark in need of hardware experimentation that it is, just to see what happens. The wire wrap discussion probably should be kept a tangential offshoot of this new, meaningful, main line of technical discussion.

 

@Gorgonops what I meant when I said I missed the point you made about the missing address lines was that I was surprised to go back and find it to be only three lines on the LCIII extension of the LC PDS.

 

Here's the PCB rats nest diagram I dumbed down to LC PDS spec. Visual differentiation of LC and LCIII connections to the 030 PDS may be helpful here.

 

Ratline-LCIII-030-003.jpg

 

My question at this point would stem from "the Macintosh Way" of doing things outlined in DCaD manuals:

 

Assuming the NuBus version of the card pre-dates introduction of the LC by some time or that the two cards were developed simultaneously, which amounts to the same thing:

 

NuBus card design would have been transferred wholesale to the PDS card. When that is assumed to be the case

-  hardware adaptation would be handled on the card itself within a module in its ASIC?

-  In true 128k wizardry fashion, following DCaD guidelines the same basic driver would be used for both versions of the NIC

-  NuBus NIC version would be communicating though the multiplexed NuBus using the full set of control lines

-  LC NIC driver would be communicating through the more limited 020 PDS using the subset of control lines available

-  LC PDS version would have a table conversion module appended to baseline driver for

-  CPU would be communicating with the formula infested ASIC on the NIC

-  ASIC degibberized control signals would be handed off within the ASIC

 

The same general purpose hardware on either NIC would be behaving in the same manner, one from NuBus MUX, the other from 020 PDS MUX. WAG from the origins of the other thread was that the NuBus driver would make conversion of the LC NIC possible.

 

WAG now is that the conversion has already been done, including 24/32 bit complications in the hardware/driver combination on the NIC/Floppy combo @maceffects sent my way.

 

The trick here is to make sure the LC driver can run on the SE/30 CPU to take care of everything BUT the memory mapping. The 030 PDS "CPU" is already in LC PDS speak mode in 24/32 over available subset of control lines on the left side of the LC/LCIII divide above?

 

 

There that's out of my system, now where's the obvious fallacy in that logic?

Share this post


Link to post
Share on other sites

Now that I've stopped trying to think in .TXT above and poured a bowl of cereal: outlandish WAG of the day

 

Address inversion in hardware isn't necessary, just the IRQ line jumper? We've been thinking hardware hack when the crux of the matter would hacking the LC NIC driver to talk in $A memory mapping as opposed to its native $E memory mapping while it's hooked up by the IRQ line for $A? It's already in LC speak mode when it comes to hardware on both sides outside of that pesky IRQ line?

Share this post


Link to post
Share on other sites
12 hours ago, Bolle said:

The presented addresses differ in 24 and 32bit mode on the LC. Verified that in the other thread (why do we have two now anyways?)

Okay, if it's verified then I guess you know what you're doing. (I tried looking for specific discussion of that in the other thread, I really did, and honestly I just couldn't follow it through all the interstitial pictures of wiring looms. Maybe I need more coffee.) I'll just note one last time that my concerns are based on passages like this: (Page 133 of D..3rd ed:)
 

Quote

As explained in Inside MaCintosh, a Macintosh computer operates in either 32-bit or 24-bit mode. In 32-bit mode, it can access all the address space in both the standard slot and super slot spaces of any slot card. In 24-bit mode, it can address only 1 MB of each card's standard slot space. This first megabyte of standard slot space is called minor slot space. In 24-bit mode, the computer hardware translates 24-bit addresses of the form $sx xxxx into 32-bit addresses of the form $FsOx xxxx, where s is a digit in the range $9 through $E.

 

Addresses of the form $Fssx xxxx access the same NuBus slot in both 24-bit and 32-bit modes. However, if you use an address of this form in 24-bit mode, the system will translate it into a NuBus address of $FsOx xxxx. In 32-bit mode it will remain unchanged. Hence, if you need less than 1 MB of address space to be accessible from NuBus, you should design your card to use only bits /AD19-/ADO. By ignoring bits /AD23-/AD20, you guarantee that addresses of the form $Fssx xxxx will be valid in both 24-bit and 32-bit modes.

This *is* in the NuBus section of the manual, but there are passages in the PDS section (that I think I've quoted before) that made me think that this translation still happens with PDS cards. But, hey, if I'm wrong I'm wrong. Do you have a reference that shows PDS cards actually need to decode both the standard *and* minor slot spaces?
 

12 hours ago, Bolle said:

Solution on how to handle 24/32bit mode switches to fool the LCPDS CS decoders are there as well. You’re right, A28-30 are involved... we basically need another address decoder to decode the full address. /FC3 is used on the LCPDS to compensate for the missing address lines.

 

 

I assume the A28-A30 decoding issue is why you have the PLD in there. Are the "A22LC" and "A26" outputs from that chip essentially what's going to be used for device enable for the LC card?

 

Share this post


Link to post
Share on other sites

Last broken record post, I swear. From the LC II devnote:

 

Quote

The FC3 function code signal on the expansion connector, which selects 24- or32-bit memory addressing mode on the Macintosh LC, is always driven high in the Macintosh LC II. Expansion cards are always addressed in 32-bit mode on the Macintosh LC II. The MMU remaps all logical 24-bit expansion card addresses($E0 0000–$EF FFFF) to their physical 32-bit equivalent ($FE00 0000–$FE0F FFFF).

 

Share this post


Link to post
Share on other sites

Good point. I only have an original LC here for testing which lacks the MMU hence no remapping there. This might be why I can see card accesses in 24bit as well as 32bit range with the LA depending on what is set in the memory cp.

 

As I said in the other thread that’s the way the LC does it so the card has to be able to decode both ranges. I can take a closer look at the card itself and buzz out the connections and crack open the decoder GAL to see what it is actually doing.

Might be worth a look.

 

If the SE/30 only addresses cards in 32bit mode that would make things easier indeed, as we wouldn’t have to check the whole upper half of the address bus to see if it’s doing a 24 or 32bit access. One more thing to check on the list.

Share this post


Link to post
Share on other sites

If the original LC *does* pass the FC3 code to the expansion connector because it expects cards to select on different ranges depending on whether it's in 24 or 32 bit mode and all subsequent LC machines don't then that's an annoying anomaly. It would *imply* at least that a card manufacturer that wanted to make a card that worked in all LC models would have to make hardware that groks and responds properly to both methods even if the low-address decoding is really only needed on the one model.
 

21 minutes ago, Bolle said:

I only have an original LC here for testing which lacks the MMU hence no remapping there.

That is one thing that has me a little confused, and makes me wish the original LC DevNote was out there in the wild. (Maybe the equivalent information is in one of the "Inside Macintosh" volumes.) The original 68020 Mac II shipped with that proprietary chip in the MMU socket that apparently provided some subset of the MMU's mapping capabilities to switch between 24 and 32 bit addressing mode. Given how the "D..." manual talks about "the computer hardware translates 24-bit addresses" and doesn't specifically call out the original Mac II as an exception I'd assume that if all it says about decoding is true then it must be capable enough to handle that... and based on that I naturally assumed the LC must include the equivalent functionality built into the chipset somewhere.

But, I dunno, maybe it just doesn't? I guess you could technically get away with it since it has that hard 10MB RAM ceiling if you were careful about where you put everything else... with one exception? If the original LC actually supports the full 16MB normal slot space then you'd *have* to at least have some kind of switching to keep the ROM and RAM from being shadowed into said slot space when running in 32 bit mode. Maybe there's something in the chipset that suppresses chip select for all motherboard devices when the address bus is in $FE00:0000-$FEFF:FFFF?

(My uneducated guess as to why the original LC/LCII don't have A28-A30 was to thwart trying to us the 256MB SuperSlot spaces to make a RAM expansion board or other peripherals that would violate the "cheap and cheerful" designation of the LC? Only good reason I can think of.)
 

40 minutes ago, Bolle said:

If the SE/30 only addresses cards in 32bit mode that would make things easier indeed, as we wouldn’t have to check the whole upper half of the address bus to see if it’s doing a 24 or 32bit access. One more thing to check on the list.

Given what you've got there is a network card that almost certainly only occupies the 1MB of minor slot's worth of memory and I/O then, yeah, it might make life easier because you "only" need to fake out the 32 bit $E enable on the PDS card to respond to your chosen alternate slot.

In experimenting with the LC what did you read on the address bus when it was looking at the declaration ROM?

Share this post


Link to post
Share on other sites
58 minutes ago, Gorgonops said:

If the original LC *does* pass the FC3 code to the expansion connector 

It does.

 

As said in 24bit mode I don’t get any hits on the 32bit address range and /FC3=high (unless FC0..2 are high which means it’s not an actual call to the card but some kind of interrupt handling.

 

In 32bit mode I don’t get any hits on the 24bit card range (and /FC3=low)

 

I can dissect the card once I get back from my two week vacation in Japan and see what the address decoder on my card does if that’s of any interest.

Share this post


Link to post
Share on other sites
4 hours ago, Gorgonops said:

Okay, if it's verified then I guess you know what you're doing. (I tried looking for specific discussion of that in the other thread, I really did, and honestly I just couldn't follow it through all the interstitial pictures of wiring looms. Maybe I need more coffee.)

No worries, you were awake all right. There really isn't a technical discussion in that thread. The main line of discussion is specifically about development of that wire wrap mess in hopes that @maceffects dragon hoard of the LC version of Farallon's would benefit from cross-platform driver and DeclROM compatibility inherent in a DCaD correct product line development.

 

What technical discussion there is in that thread amounts to @Bolle popping in here and there to help me implement logical intervention he and another member came up with in an LC NIC adaptation discussion elsewhere. Who was that? It woul be goo to get another pair of eyes on the docs? Bolle's busy with other projects when he's busy doing his best to mangle himself in downhill bicycle madman mode. I reached out to @trag my other mentor with basic questions about digital logic, but he's really busy at work so I chucked my immediate concerns into a new thread to get your quick "no."

 

I said earlier that the series of events was serendipitous because the three of you are having a meaningful discussion on technical issues and I now can go back to playing with my flexible tinker toys. :lol:

 

WAG: one thing that makes me think the missing LC DevNote may never have been released was that information on the closely intertwined nature of Apple IIe Card and LC may have been closely held. At about that time, Laser was making legal clones of the Apple II and building a better compatibility card with more capability than Apple wanted fielded would have been right up their alley. The IIe card was meant to wean folks off the Apple II line and nurse them onto the Mac in its place. By the time the LCII and LCIII shipped approx 18monthe and a year and 18 months later this wasn't all that great a concern. Like I said, just a guess.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×