Floopy wrote:
BigDumbDinosaur wrote:
Floopy wrote:
The memory is sectioned into 8 banks each 8192Bytes. I'm using a De-MUX (74138) to do the selecting. It's using the upper 3 bits of addressing.
Why? What is wrong with using linear addressing in a single (larger) SRAM? That 74HC138 won't be doing you any favors with its slow performance. Using a single 32k × 8 SRAM, you can reduce your parts count and you'll gain timing headroom should you later decide to run a faster clock. Take a look at Alliance's AS7C256B-15PIN 32k × 8 SRAM, which is in a DIP28 package and has a 15ns access time.
The idea was that I would have enough memory to slot any experimental device.
"Experimental device" sounds too vague to be tying up large segments of the MPU's address space the way you are doing. Better to set up some I/O ports (which is a good place to use the 74*138 decoder) and not directly expose the MPU's buses to your experiments. The 65C22 can be used for this purpose, a topic that Garth extensively covers on his website.
It sounds as though you are designing in excessive complexity. The likelihood of a first-time unit not working is roughly proportional to the square of the degree of convolution.
All kidding aside, learn to fly a Piper Cub before you climb into the cockpit of a 747. Your mistakes will be easier to diagnose and correct.
Quote:
If I have just two 32K banks then I can't do too much.
Au contraire! What you are trying to do is lay out a memory map that doesn't fit the 65C02 very well. The "classic" memory map would have a modicum of contiguous RAM—which would encompass the all-important zero and stack pages, followed by some amount I/O, followed by ROM. This can be accomplished with minimum of glue logic.
With a little more glue logic, you can have a more expansive memory map. For example:
Code:
$0000-$CFFF RAM, 52KB contiguous
$D000-$DFFF I/O, 4KB
$E000-$FFFF ROM, 8KB
That's the memory map I used in my POC V1 design, accomplished with no more than two gate delays from the address bus to the chip selects for RAM and ROM, and a maximum of three gate delays between the address bus and I/O hardware. In V1, I used a 128KB SRAM, and simply ignored the part of it I wasn't interested in using. That was also the case for ROM—I use a 32KB EPROM, but only decoded 8KB of it.
Within the I/O block, I arranged the following:
Code:
$D000 Dual UART
$D100 Real-time clock
$D200 SCSI PIO data port
$D300 SCSI DMA data port
$D400 SCSI DMA request
$D500 Spare I/O A
$D600 Spare I/O B
$D700 Spare I/O C
In the world of computers, I/O is everything. A computer that can compute but can't communicate is of very limited usefulness.
Quote:
Also the datasheet for the 138 I'm using says a 13ns switching time.
http://www.ti.com/lit/ds/symlink/sn74ahct138.pdfYour schematic appears to be identifying that part as a 74HC138. That device has much different timing specs than the 74AHCT138—also, the 'AHCT138 has TTL-compatible inputs, which is not the case for the 74HC138. Those letters in between the '74' and the '138' do matter, y'know.
Incidentally, it's best if you post your schematics in monochrome. We have one or two members who have color-blindness.
Quote:
floobydust wrote:
I would also suggest using something like a DS-1815 Reset chip instead of the RC setup and add a momentary switch as well so you can easily reset the CPU and any other I/O devices.
I will look into it. The reset circuitry needs some work done
floobydust meant the Maxim DS-1813, which is a handy little gadget in a TO-92 package. I also use it as a push button debouncer for the NMI circuit in my POC units.
Attachment:
File comment: Maxim DS-1813 Reset Controller
reset_controller_ds1813.pdf [206.15 KiB]
Downloaded 147 times
Quote:
BigDumbDinosaur wrote:
Taking the MPU's buses and signals off-board is not recommended.
The original idea was to run it on a pin header to hook it to another board. I think I will do what they do on floppy drives. Alternate between ground and a signal.
Remember my above comment about the Piper Cub and the 747?
I do not recommend you do this. Parasitic capacitance will quickly degrade signal quality and may result in a DOA unit. Also, if the cable has any significant length to it, you will be grappling with problems caused by transmission line effects, which only experts can usually resolve. I think you will quickly end up in over your head.
Quote:
I should have mentioned that programming is not my strong point either.
Well, programming is something you will have to bone up on if you are going to write enough firmware for your machine to make it do something. Fortunately, many of use are fluent in the 6502 assembly language and can help you.
Login
Register
FAQ
Search
So far it is just capable of drawing current 
(OK, there is 
)
my lack of English skills is showing. I should have worded the sentence better. I will do some digging, there seems to be more info on the forum than I thought there was. I usually get what I need from Mouser anyway, it's nice when you open a package and it's all inside anti-static bags.