I am currently getting all my ducks in a row on the initial design choices. Since I am new to all of this I figured I would post my thoughts here to see if I am missing something.

I plan on using the ATF1504A to handle address decoding. I was originally going to use the ATF22V10 but due to availability and needing a programmer decided on something else. I am going to use a similar memory map described by Daryl's DEC-1 decoder. Since the CPLD has more pins I plan on extending the original decoder in include address pins A3 and A2 as well as several more CS pins for I/O devices. I have written out the logic yet but the CPLD will have an internal single bit configuration bit that is memory mapped similar to an I/O device. The idea is to use this configuration bit to switch from 32k RAM/32k ROM to 64k ram during operation. This does mean that the CPLD will have to be tied to the reset circuit as well.

Currently the idea is to have two 65C22S VIAs and use an ATF1504AS to implement a 6502SPI controller. I am still waffling back and forth whether to include a uart on the cpu bus or not. It would be helpful to have a way to interact with the computer fairly quickly but not sure if the trade off is worth it in the long run when the MAX3100 is an option.

The rom will be a 39SF010A nor flash with either a 64k or 128k SRAM IC depending on what is available.

An external canned oscillator will be used for clocking and either a DS1813 or MCP100 for the reset circuit.

Welcome!

What's your plan for switching the memory map over? Perhaps you intend to have writes to the ROM region to be sent to RAM so you can copy some or all of the RAM before the switchover?

What's your plan for bringup? Perhaps some minimal initial ROM which signals success on a VIA output?

What sorts of equipment do you have, ranging from multimeter to logic analyser or 'scope? (I'm sure you can get to success with ingenuity and minimal equipment, but it'll be easier in some cases than others.)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Consider a USB FIFO, such as the FT245. It's faster than serial over a UART and considerably simpler to configure. (On both ends: the USB side appears as a USB serial interface, but it doesn't care how you set the baud rate, stop bits, etc. on the host since it's a parallel interface.)

_________________
Curt J. Sampson - github.com/0cjs

Let's see if I can manage to remember all the questions to answer.

I plan on using the W65C02 CPU for this project

The way the memory map switchover will work is the ROM will contain the startup code, possibly device drivers, etc... enough that the cpu can load things from external storage. The CPU would load initial part of the program into RAM, switch over the the 64k ram map and start executing the loaded program. The idea is to use this for larger programs such as interpreters or basic operating systems that would benefit to having more ram. I have seen similar things in Z80 computer designs for running CP/M but the Z80 access I/O differently which might make this idea inadvisable.

The bringup will essentially work as suggested. Set some output on the VIA so notify that everything is brought up.

I currently have a multimeter and looking to get a logic probe. I have been looking at getting a used oscilloscope but haven't put a lot of effort in on that front.

I absolutely plan on adding JTAG ports to better access the CPLD. I went ahead and picked up some of the nor flash and the CPLD to see if I can get them programmed before moving too far ahead with them. I got one of the CPLD programmed using JTAG and a Bus Pirate but haven't gotten a chance to see if it is correctly working.

To start off with I plan on targeting 2Mhz or possibly 1. I am aiming for a stable system before trying to push it as far as I can

Thank you for the information on the CPLD pins and suggestions for peripheral ICs. I will absolutely look into them!

To reduce the complexity of your first design, all you need is 6502, RAM, flash, CPLD, and oscillator. CPLD can be reprogrammed at least 100 times via JTAG so your basic design can evolve from very basic, fixed memory map to complex, programmable memory map to emulate 65C22 functions in CPLD to adding serial port function in CPLD by just reprogramming the CPLD.
Bill

I find it best to think of the Z80 as having 2^17 bytes of address space with "A16" being the ¬MREQ/IOREQ lines. The "memory" and "I/O" address spaces are accessed from machine-language using radically different means (using IN, OUT, etc. instead of LD etc. when "A16=1") but from the bus and address decoding point of view there's no difference between them, and no reason you can't put memory on the "I/O" addresses or vice versa. Plenty of Z80 systems use memory-mapped I/O devices and some, such as the Game Boy, support only memory-mapped I/O.

One thing you want to watch out for when bank-switching ROM is the NMI, reset and IRQ vectors at the top of the address space. If there's any chance you might get an interrupt (or reset!) just after you've switched, you want to make sure that these are set up correctly before you do the switch. This is one reason why systems often have writes to the "ROM" area always go through to the RAM that can also be mapped to that address space, even when reading ROM from it.

_________________
Curt J. Sampson - github.com/0cjs

I just spent some time looking into the FT245 and at the schematic that plasmo as for the ROMless EEPROM programmer. Looking at how easy it is to interface I am seriously considering using on in a design. In fact I realized that I might already have one from a WaveShare FPGA dev kit that I have collecting dust. I tried looking around the forum but didn't fond a whole lot on interfacing it to the 6502. Is there any gotchas or is it just some glue logic for the RD# and WR inputs and maybe adding the TXE# and RXF# lines to the memory map?



I absolutely plan on making this initial design as simple as possible. If I was going to use the ATF1504AS for glue logic it seemed kind of a waste to not design a way to take advantage of the power and ability for in system programming at a later date.



I completely forgot about that even though I just read it a little bit ago. You probably saved me a lot of headache in the future!