FFFF000000060001001277AA000000000060000000001001210000001-7EFF6EB60Â4800480255A0Á-1‚0Â4600Â2‚55A22AFFFF0‚‚10‚‚2‚00010000003A000000010C9540840‚‚2‚55A22AC95028E00054E255A20000200000C9B00000000C95,Subject: Re: Hardware Project From: "ntt" Date: Mon, Nov 16, 1998 14Ç38@ Message-id: <36509add.0@news.mtx.net.au> David Wilson wrote in message ... >Most any card you design with on-board ROM needs to decode all three selects >(DEVSEL, IOSEL and IOSTB) and generate chip selects for ROM, devices and the >data bus buffer. This tends to take quite a few LSTTL chips. My idea is to >replace these with a single PAL/GAL (plus an 8 input NAND gate) to take care >of all this (including the CFFF disable function). It will also allow for the >use of RAM instead of ROM as this makes code development much easier. > >Any thoughts on this would be appreciated. It is hard to imagine any significant project being undertaken which would really benefit from this. It is almost impossible to get hold of devices (eg EPROM) that would fit into the memory space (and those you do get, you probably wouldn't want to use). Using larger devices would be a waste without making available the rest of the memory which means using some form of bank switching. How generic is the PAL/GAL to be (since you're also adding a TTL device as well)? PLDs are becoming inexpensive and readily available. It would be easy enough to produce a trivial PLD design which would decode everything (get rid of the NAND gate), provide /CS lines and addressing for modern memory devices (eg 128Kx8 --> 512Kx8) making the entire space available through the 2K C800:CFFF window using an arbitrary location (eg C0[n+8]0) for the bank switching. Decoding the slot ROM (Cnxx) could force a certain bank (such as bank zero which would presumably always be there). The PLD could also convert the R/W line to /OE and /WE lines for memory. You don't need to use all this space, but at least make it available... Lets see... To make all of this happen, you need /IOSEL, /IOSTRB & /DEVSEL for the 3 memory spaces you need the 8 data bus lines to latch a bank number (if you wanna make it simple make this read only) A7:0 can go straight through to the memory chips... A10:8 need to be latched (and driven) if you want to force Cnxx accesses to a certain bank you need to produce the high 8 address lines (latched from the data bus/forced by /IOSEL) you need to produce at least one /CS line you need to convert R/W into /OE and /WE adding that up you get 3 + 8 + 0 + (3 + 3) + 8 + 1 + (1 + 2) = 29 available I/Os This will fit comfortably in a 44-pin PLCC (socketable) package for under $10 and will address all locations ('cept for the 256 CFFF locations (one in each bank)) of a 512Kx8 FLASH (non-volatile memory) or SRAM. Smaller parts will just 'wrap around in the available banks. There are still outputs available in the same package for decoding other locations in the C0[n+8]x range for other devices or purposes. If you want to get fancy you could use the 7M clock to generate /CAS and /RAS signals for DRAMs but this would require a larger package. Going to a 68-pin PLCC package (or 84-pin PLCC) would give you enough I/Os to decode almost anything. If you were to produce some generic 'application-specific' logic parts you might as well do it properly... cheers ntt@dove 000400000010000000030C901C97100050000000A000000020C97000060000005C000000020ÁC310‚‚ÁFFFF0‚C00000 30ÂÁ ‚‚ÁA20‚‚ÁFFFF0‚900000 10ÂÁ ‚‚Á000700000018000000010‚20Â180‚Á0008000000970000000140,Geneva40,4030 10000900000015000000022‚FA22A2‚FA22A000A00000021000000022‚7FFFFFFF22A2‚7FFFFFFF22A000B00000005000000020Â000C0000001600000001C951EB‚D72D0‚1000F000000280000000050 11AE890C0‚ÂÁÂÁ‚‚ÁÂ00130000005E00000000DA91F8CE1C1D1E1F7F1B024,-.¦¹°­­.FFFF0FFFF0