From: "ntt" Newsgroups: comp.sys.apple2 References: <364919f0.0@news.cgocable.net> Subject: Re: Hardware Project Date: Tue, 17 Nov 1998 08:08:37 +1030 Lines: 76 X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 NNTP-Posting-Host: pppk56a-77.mtx.net.au Message-ID: <36509add.0@news.mtx.net.au> X-Trace: 17 Nov 1998 08:06:29 -1050, pppk56a-77.mtx.net.au Path: news1.icaen!news.uiowa.edu!news.physics.uiowa.edu!math.ohio-state.edu!news.cis.ohio-state.edu!news.maxwell.syr.edu!newspeer.monmouth.com!intgwpad.nntp.telstra.net!news1.optus.net.au!optus!yorrell.saard.net!duster.adelaide.on.net!news.saix.saia.asn.au!news.mtx.net.au!pppk56a-77.mtx.net.au Xref: news1.icaen comp.sys.apple2:141876 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 Path: news1.icaen!news.uiowa.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.erols.net!sunqbc.risq.qc.ca!news.uow.edu.au!david From: david@uow.edu.au (David Wilson) Newsgroups: comp.sys.apple2 Subject: Re: Hardware Project Date: 16 Nov 98 22:03:27 GMT Organization: University of Wollongong, Australia Lines: 58 Message-ID: References: <364919f0.0@news.cgocable.net> <36509add.0@news.mtx.net.au> NNTP-Posting-Host: wraith.cs.uow.edu.au X-Trace: wyrm.its.uow.edu.au 911255509 207 130.130.64.1 (16 Nov 1998 22:31:49 GMT) X-Complaints-To: usenet@wyrm.its.uow.edu.au NNTP-Posting-Date: 16 Nov 1998 22:31:49 GMT X-Newsreader: NN version 6.5.0 #15 (NOV) Xref: news1.icaen comp.sys.apple2:141879 "ntt" writes: >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. I had already discarded 2716/2732 and reached 2764/6264 sized chips. Bank selection is included (1/4 is used for the slot space, the remainder is banked 3 ways into the C800-CFFF space). >How generic is the PAL/GAL to be (since you're also adding a TTL device as >well)? Just a standard 20V10 or similar. >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. Very similar to my GAL design. Rather than using up the limited C0[8+n]X space I am using CFFC-E to select banks 0..2 while bank 3 is forced when IOSEL is asserted. The reason for a GAL is that it is relatively small and I have access to a GAL burner. >To make all of this happen, you need /IOSEL, /IOSTRB & /DEVSEL for the 3 >memory spaces Got them. > you need the 8 data bus lines to latch a bank number > (if you wanna make it simple make this read only) No need as I use A0-A2 instead. > 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 I feed A10:8 straight to the EPROM - this uses 8x256 bytes for the slot ROM but does allow slot dependant code rather than having to write PIC. > you need to produce the high 8 address lines > (latched from the data bus/forced by /IOSEL) I am producing A11 & 12. > you need to produce at least one /CS line Yep. > you need to convert R/W into /OE and /WE Currently /WE = R/W* and the GAL inverts R/W* to form /OE. >If you were to produce some generic 'application-specific' logic parts you >might as well do it properly... Very interesting ideas. Thanks for the input. -- David Wilson School of IT & CS, Uni of Wollongong, Australia david@uow.edu.au