You can send me your address by PM or send it to the email address on my site (which is also the Paypal address). You can pay me after I send it (or them) so we know how much the postage is. First Class should just be a couple of bux.


All the info is on Daryl's 65SPI page at http://sbc.rictor.org/65spi.html . It goes on the 65xx bus like any other 65xx I/O IC. You don't go through the '22 to get to it. the 65SPI takes care of the serializing & de-serializing, the timing, etc., so your program can be doing other things at the same time. I ended up not using the 65SPI, so I can't claim any experience with it. Note that this CPLD uses a fair amount of current and gets kind of hot, which might be why it got discontinued and he's re-working the design for a newer part (although it will no longer be 5V). Just don't get alarmed when you find out it's very warm. That's normal.


There are SPI flash memories, and there are of course also parallel ones.


There again you may or may not need to go thought the '22. 8-pin I²C EEPROMs (24 series) go up to 128KB. If you go that route, let me encourage you to use our hobbyist-friendly I2C-6 connector on tiny swapable modules. Similarly, if you use SPI flash, go for the hobbyist-friendly SPI-10 connector.


Those look like nice chips. The '22 has some capabilities they don't, and vice-versa, and of course the '22 will give more-instant access since it sits directly on the 65xx bus.


The main things to avoid blowing things up are just observe good static-handling precautions, and make sure the power is applied to the right pins and not too high of a voltage nor reversed. Output pins shorted to power or ground will probably survive if the application is short, and you'll be able to tell when you flip the switch if the current is unreasonably high, prompting you to immediately shut it down and figure out what you did wrong.


Just remember gates don't have infinite speed, and propagation delays add up fast if you cascade them.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just to note, backspace119, you keep mentioning flash, but for mass storage I was thinking of SDCard. You do need at least 1k of ROM, somehow, unless you're going very deep into diodes or a bank of toggle switches, which means you will need some way of programming that ROM. Simplest, I think

Be sure to have a look at Grant Searle's minimal designs - you need to understand one or two existing designs before you start your own. It wouldn't be a bad idea to build them, either.

Is serial communication going to cause delays for waiting for data from eeprom? Also, even just writing out address decoding in its simplest form is perplexing me, but I think it's because I'm trying to add in paging as per a recommendation earlier, and I don't quite understand how paging works (I think we set our page over the data bus to the latch, then our addresses are essentially offset by that page, but this seems like a long process that would impact performance pretty badly) I think I'm going to look into BigEd's recommendation of building an existing design first, although I'd like to keep working on my own while pursuing that avenue.

I may also just take the schematic from your circuit potpouri and make my own layout, so it's at least partially my design.

It would be cool to start out with paging though, to allow for a lot of address space even with just 16 bit addressing mode, but from what you've said, it sounds like the 24 bit addressing mode of the '816 isn't that hard to access, just and !RDY and phi2 together to determine if it's a valid address? I suppose, as I think was mentioned earlier, if I start with 24 bit addressing space everything is simpler. I have plenty of space for ROM and RAM and I/O in between.



On this, I mean mass storage when I say flash, I've been thinking SD card this whole time, but it could be anything, and it would be neat to do cartridges for games

Hmm, there's an incomplete thought there! I think was going to mention EPROM programmers. EEPROM is also interesting, as you can program in-system, but that doesn't help you in getting your first system up. Very likely a friendly member of this forum will be able to program an EPROM for you, but you won't get a rapid edit-burn-test cycle until you can program in-house, or run code in RAM.

I think, if you start from no knowledge, you need to go through a series of 'aha' moments before you're fully confident in system design. Getting banking working is certainly the far side of getting simple address decoding working! There's no need for banking or overlays in a first system. Your first code isn't likely to fill even 16k, I wouldn't think. And that's a good thing! You need, ideally, lots of iterations while you're learning.

On the E/E/P/ROM front ...

I went for a ROMless system for 2 reasons - one was re-programming them (I have a programmer though) and the other was speed - access speed of the ROM that is - they're not easy to find in the speeds I was hoping for (14Mhz - but remember the 6502 needs memory that runs fractionally faster than double the clock speed) so I was looking at wait states or some funky way to copy ROM to RAM, then disable the ROM and switch the RAM in (not that hard but obviously needs more logic)

There are a few innovative romless ways to boot a 6502 - search here (don't have the links to hand, sorry, but do search here). Some only need 3 wires from a microcontroller to the 6502 if I recall. My system has a 256 byte block of shared RAM which the microcontroller pokes an initial bootloader & vectors into, that then talks back to the microcontroller to load up the rest. (So there are 8 wires of data bus, 8 of address and a few control lines.

But if you are going down the ROM route, then do invest some time getting to know an emulator - I used the Symon one for a while before putting hardware down. https://github.com/sethm/symon

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Okay, let me walk you through address decoding and paging. It doesn't work *quite* the same way as in modern PCs. Forget about implementing adders in hardware; you won't need them. In the following, I'll asume you only have a 16-bit address to deal with.

Typical 6502-attached devices will have a number of address pins - generally fewer than 16 - plus a chip-enable (/CE if active-low), an output-enable (/OE) for reading, and a write-enable (/WE). The /OE and /WE signals are derived from a combination of Phi2 and R/W from the CPU, and can be sent to all devices without further decoding (in most cases). And in non-paged scenarios, the address pins are usually attached to the low-order address lines from the CPU (starting from A0), so that the device occupies consecutive addresses.

The devices will then "wake up" and look at their address pins when selected by /CE, then actually perform the transfer in either direction when /OE or /WE goes active. When /CE remains inactive, the other control signals and the address pins are ignored, and the device is quiescent. When we talk about address decoding, we mostly mean generating the correct /CE signal for every device on the 6502 bus.

A 256Kx8b SRAM, however, has 18 address pins and all of them need to be driven. So we drive only the first 10 from the address bus (A0-9), and drive the rest from an 8-bit latch which we put somewhere in I/O space, with separate decoding. In the simple case, the latch is just connected straight to the 8 highest address pins of the SRAM (A10-17) and loaded from the 6502 data bus (it has no /OE or /CE, only /WE, so we need to combine the two signals in this specific case). The SRAM chip then gets a /CE corresponding to a 1KB window in 6502 address space, ie. some combination of the top 6 address lines.

Stepping back a tiny bit, you also have 32KB of "flat" SRAM and 16KB of "flat" ROM in a typical 6502 first project, leaving 16KB spare. This configuration only requires decoding the top two address lines to implement. A15 *is* the /CE for the SRAM, and (A15 ~& A14) is the equation for the ROM /CE (where ~& is my way of writing NAND). To carve the remaining space into 1KB segments, don't bother writing interminable logic equations, just slap down a 4-to-16 active-low decoder and feed *its* enable input with (A15 ~& ~A14), and its select address with A10-13. One of the resulting lines is the /CE for your 256K paged SRAM.

I rather hid the link to that:

Bootstrapping an SBC

But I would say, all this business of trying to build a fast system that can boot from slow ROM - it's interesting, and it's a great project, but it's not (in my view) a good first project.

I think 150ns EEPROMs are easy to get, and you can use them directly with a WDC 6502 at 4MHz without wait-states. Just so long as you implement the control signals and decoding the right way.

That sounds nice and simple!

The 65816 can go to 14MHz, just like the 65C02 can from WDC.

WDC has a simple circuit with 2 chips (a 74573 or 74373 and a 74525) plus an inverter that demuxes the Data and Address bus. Page 44 of the datasheet.

And this immediately leads to another point: don't treat the WDC datasheet as gospel. They have often contained errors (some of which have since been corrected), and that diagram is one of them.

The first and most serious problem is that the enable signal to the latch (the '573 or '373) doesn't include the RDY signal. If the RDY signal is driven externally to provide a wait-state, then this circuit may corrupt the high address bits during Phi1 of a wait-state cycle, because the CPU is in fact held in Phi2 state when RDY is low. So that NOT gate must be augmented with something to incorporate the RDY signal.

The second problem, less serious, is that the bidirectional bus driver (the '245) is not required in most designs. You could reasonably leave it in if using the Phi1 phase for video scanout or other DMA purposes, but in that case you'd also need it with a 6502, and it's not specific to handling the high address bits of the '816. In designs where it's *not* needed, it's potentially a performance liability.

Welcome backspace119.

You have recognized that there are a lot of people here that like to assist/advice/remind/etc. you (and all other "newbies") when creating a new 65xx system. Now the "evaluating" what's to do and don't has reached the problem of getting a system up and running. It' s a sort of hen and egg me think. How to create a new running system w/o having a system to create and test the (monitor-)software for that new one?

Time for me to throw in my 2 coins

I would recommend to take a deep look into the datasheet of the W65C265. Be warned: it's a bit of a nightmare to understand what WDC is talking about, just try it a couple of times

Why I suggest the W65C265 ? First, it is possible to get this beast up and running without additional software - the Mensch monitor program is included and ready to run. You only need to attach two quartz crystals (32768 KHz and 3,6864 MHz), something for power on reset (RC should do) and perhaps a TTL_to_RS-232 level converter for one serial port. This should work, and if, you have a very tiny running 65xx that can greatly expanded. Next, you get a couple of ressources like serial I/O (4 channels total), timers, even 2 tone generators and more . But one thing that isn't obvious at the first glance: you get separated IRQ vectors for all internal (and some external) signals - regardless wether you run in native or in emulated mode. This can be very very helpful if you need fast IRQ response. (Thinking of graphic...)

You may then add 32K RAM @ 0..7FFF and 32K (E)EPROM @ 8000..FFFF (I would suggest flash type, as they are faster than EEPROM - if you wish to get beyond 4 MHz). The required chip select signals are provided (CS3B and CS4B).

Once you have a self written monitor/boot program, you can get rid of the ROM monitor and speed up to 8 MHz (official) and more (mine runs 18 MHz just using a different crystal).

You think 32K ROM like memory isn't good, too much, unflexible? No problem, simply attach a single 2 MB one (or 512 KB) and use CS5B. This selects memory for the first 4 MB (00:0000...3F:FFFF), except where other CS's are enabled. Then you can switch off your entire EEPROM and replace it by RAM. If something runs mad - you can always fall back to either your monitor or the Mensch monitor.

The W65C265 isn't broadly discussed within this forum, some of my experiences with a ready_to_run SXB from WDC you can find here.


Regards,
Arne

It's only a serious problem if you're using the RDY signal externally to provide a wait-state. If you're not, you're not.

It's adequate for many systems. They use a very similar (though not identical) circuit on their '816 board that they sell, and the don't do anything with RDY in that circuit either.

So I'm out right now and won't be back till late or I'd make individual quotes.

As far as demuxing the address bits from the data bus goes, this is probably something I'll pursue, I've already settled on using the 816.

I think I'm going to build similar to grants builds since they're easy, but with some small changes to incorporate some of garth's designs.

This will get me a basic terminal that will run basic, and do a couple other neat things. From there I can start trying to do video and audio and all the other goodies. The final thing I need to set in stone is the memory map and glue logic, and also mapping where peripherals are going to go.

As far as that single chip computer goes, it looks interesting, and I may use it for another project, but I'm going to stick with the 816 for now as the heart of this.

So, I've started picking out a few parts since I've decided on the base build requirements, I've found this ram which looks plenty fast and is 32KB, I suppose if I want more I can always add more chips, or try and find larger sizes that are also this fast (a cursory look came up with no results on mouser).

Does this ram look like it will work out alright? Looking at the data sheet everything seems to be ok, I'll just be forced into 5v since I don't want to use a level shifter for ram. I've decided to get the WDC processors, since they're on mouser and they're well documented, same with the IO chips.