On 7/13/2016 12:32 PM, Gerrit Heitsch wrote: > > Yes, but somewhere in a Commodore datasheet I read that that the 23xx > ROMs didn't really have a power down, so they really might have had > the ROM running all the time and using _CE to only control the output > buffer. The datasheet mentioned their 24xxx ROMs being able to power > down. > > It's here, search for '24128' > > http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/csg.chips.info While I agree with your point, 2364s do not have a _CE pin, so my comments are around ICs that do have such a pin. The official CSG/MOS pin name is CS (active high or low depending on mask) > > > >>> then you could get away with just checking for (_CE | _OR ) == 0. >> You can do so, but that costs an OR gate, and most times, 2764 sockets >> just tied CE to ground all the time, as the power savings with CE =1 >> would not matter. > > With NMOS-ROMs it makes quite a bit of a difference. Replacing the > 16KB NMOS ROMs in a Commodore C16 or +4 with a 27C128 each results in > power savings of 50mA per Chip. 2 ROMs = 500mW power savings. I'm not disputing the savings. If you read my response, I am saying that, in such a design, the power savings does not matter (to the designer or the user) in the original design. Whether it should is an exercise for the owner of the equipment. > >> If you >> deadbug the IC, you can stash it in the interior of the 24 pin socket, >> as you only need 5 connections (A,B,Y,PWR,GND) > > Well, you should not leave unused inputs open. Some logic families > don't like that. Sigh... I stand by my statement. Only 5 connections are needed for a use case that would use "deadbug" construction. I know of no "junk box" TTL families (straight TTL, LS,or HCT) that would behave badly with unconnected inputs. Yes, they will use more power, which will be unimportant for the use case. I do make an assumption that things written in this forum can assume a general familiarity with digital and analog best practices. Jim Message was sent through the cbm-hackers mailing listReceived on 2016-07-13 18:00:47
Archive generated by hypermail 2.2.0.