6502.org

Hi everyone,

A bit over a month ago, I posted a topic titled '6502 PC - where to start' asking for some advice on creating a functional and practical computer to run BASIC (viewtopic.php?f=12&t=6080). Well I got some great replies and I've investigated a bit more so here is my design goals. The CPU will be a 65816. I know it's harder to get started with but the good thing is it emulates the 65c02 and when I want to get more advanced I don't have to pay another $20 at Mouser. My memory map (assuming 24 bit addressing) looks like this: Instead of TTL logic I'll use a CPLD to do memory mapping, etc., because then I can easily change it to take advantage of '816 native mode. It will have a 65c22 and 65c51 for I/O, and I might buy another CPLD to implement Daryl's 65SPI. In my original post I said I wanted VGA output with an FPGA, but I've researched a bit more and it seems unlikely. I could use a parallax propeller, but I'll probably go with Grant's composite video controller, because I have some Arduino Unos lying around that I can pull chips out of. For expansions, it will have 65SIB, SPI-10, I2C-6 (so many interfaces appear on this forum ) and maybe a PC printer port. I know that it's bad to use the processors own buses for expansions but I was also thinking of having ISA card slots since my memory map will have so much empty space. For BASIC I can use EhBASIC so I only need to write 2 routines. Is this design easily plausible for a beginner? I'd appreciate any tips and advice.

Thanks

Sounds good! Bear in mind that the system's vectors are at the top of bank 0, so you need either to put some ROM there permanently or have a way to do something temporarily. Both approaches have, I think, been used successfully.

I didn't realise that at the time. I sort of assumed that the vectors would be at the top of the memory map like the 65c02. I suppose it makes sense if some users aren't using the upper address lines.

You've got to have some ROM in bank $00 because at reset, or when any interrupt occurs, the 65C816 will look in bank $00 for the necessary vectors and code. As an example, but not necessarily the only way to do it, my POC V1.2 unit has the following bank $00 layout:
The unit has a 128K RAM but I'm not generating the A16 signal at this time.

Extended RAM in your unit should appear at $010000-$01FFFF. That only requires one bit of extended address generation. Trying to make anything appear at $FFxxxx means you have to generate A16-A23.
The WDC 65C51 has a serious hardware bug and is not something I'd recommend you use. There are much better UARTs available.
I think you need to scale back your aspirations for a first system. The more features you add the greater the likelihood the unit will not work or will be buggy. In fact, I question the wisdom of building your first unit with a CPLD. If you build it with discrete logic you will have a better understanding of timing, logic, etc., as well as a better chance of it working on the first try.

Trying to incorporate too many features into a first-time build is what often causes projects such as yours to stall and not get completed. As I said in your other topic, it's best to learn how to fly a Piper Cub before climbing into the cockpit of a 747.

The 65C816 was designed to be a superset of the 65C02 and thus has the same 16-bit address bus. As the '816 always starts in 65C02 emulation mode at reset the design had to present an architecture that is consistent with the 65C02.

Is a CPLD fine for a first system build? I think so, which is to say both ways are fine. There are tools to master, but the point is well made that the hardware is simpler and more flexible.

dagenius: you'll notice, I think, that BDD is very prescriptive: it will serve you well to read his posts accordingly. What appears to be a strict directive is usually only advice based on experience: reality is not so strict. What appears to be a definitive statement is, unfortunately, often not quite the case: it should be read as if it's a strong possibility, or a simplification.

[Edit: just to note that I'm not happy to have posted the above. I could possibly have found a better way to proceed.]

What would be the best alternative UART that works the 6502 bus (preferably in a DIP package)? I did originally have a 64KB memory map, but it had a lot of banking so I decided to just have no banking over 16MB. Forgive me if I'm wrong but it seems all I have to do for the 16MB is latch the data lines when phase-2 is low. I don't have any experience and might be wrong, but it seems a lot simpler than it sounds. Another reason I chose CPLD is because I can create PCBs at the local makerspace, but the CNC machine won't be able to do anything really big.

BTW, thanks for separating out this project thread from the previous discussion thread. With a bit of luck we won't have to keep rehashing things which have already been said over there.

By "temporarily" Ed means there's a way the memory map can be changed sometime after the machine has woken up and done its reset.

One simple approach is to use one bit of a 6522 VIA port as an output to say when the machine is "cold." Upon reset the VIA bit will be high impedance, and it goes high (you might need a pullup resistor). When this COLD signal is high it causes the memory decode logic to alter what appears at the top of Bank 0 (you want ROM). Then later, after the machine has gotten itself in order, it sets the VIA bit to output a 0 (low), and henceforth decode logic will cause the top of Bank 0 to be RAM instead.

ETA: another approach is to use the 816's E output rather than a VIA bit. Reset causes E to go high (ie, Emulation mode), and that can be your COLD signal that causes ROM to appear. After the machine has gotten itself in order you'll switch to Native Mode, and that's when you get RAM instead.

-- Jeff

Ed, why don't you shove it? I didn't prescribe anything.

It seems like there are some serious flaws in my memory map. I'll probably just redesign it completely so that it has RAM, ROM and I/O in bank 0, then I can add RAM and larger ROMs to the other banks. The reason I decided to go with 24 bit addressing is to avoid complexity and lots of banking, so I probably won't do that. It's easier to just use a different memory map.

In other projects I've seen people have used MCUs to copy am EEPROM top RAM during reset. How would ths be implemented? I'm thinking that with something like an adafruit feather that has a micro SD card reader it could be possible to boot from SD without implementing FAT.

There are as many ways to do it as there are hobbyists wanting to make a system - which is as much a joy as a curse, I suspect...

Traditionally, you need some ROM in the $00.FFxx region at power-on time, but with the right hardware (CPLD type thing) you can swap that out once booted for (faster?) RAM if required. Or just leave it there. One issue we have today is that small (e.g. 2KB) EPROMs are really hard to get so you end up with 256KB if not careful and while you don't need to use all of it, it's still something more than you really need.

IO is also traditionally in bank 0 - probably to mimic the old was of doing it in 6502 land. There are some people who suggest IO in page 0 (in Bank 0) is good too, as it's one cycle faster to access, however that's at the expense of precious page 0 RAM - less a problem in the '816 though as you can move the page 0 base address (called the direct page in '816 terms) Putting IO in higher regions on the '816 does require extra work to access though - it's not a linear 24-bit addressing scheme, but banks of 64KB, so again for ease of code, bring-up testing, bootstrap then having IO in bank 0 is easier.

Personally, I like to keep things a simple as possible. I have 512KB of RAM (8 banks of 64K) with a 256 byte window at $00.FExx for a single 65c22 VIA chip in my Ruby 816 board. I could decode that region further for more IO chips if needed.
Do have a good read of the 65816 data sheets and programming guides and think about what your goal is. The Apple II did really well with effectively 48KB of user RAM and 16K of ROM and IO space, the BBC Micro did well with 32KB of RAM although it did have a paged ROM system. I'm suggesting that unless you have a clear vision/roadmap then maybe you don't need more RAM... ???

And note that the 65816 is effectively a banked system - It's a 24-bit program counter, but the memory isn't quite as linearly addressed as you might think or want it to be. Index registers are 16-bit, not 24 and some operations will extend into the next bank and some will wrap.
My Ruby system is ROMless. I use an MCU (ATmega) to bootstrap it. The area of RAM at $00.FFxx is shared between the 65816 and the MCU, so the MCU holds the '816 is reset, pokes the bootloader into the shared RAM area, then takes the 6502 out of reset (it's not truly shared as only one can access at a time) And while the MCU does have an SD card, it's not used to boot the CPU - the bootstrap code comes from the flash memory in the MCU.

Hope the project goes well - we need more 65816 projects going!

-Gordon

For my new memory map I might do 56KB - 256 bytes of RAM (256 bytes for I/O) and 8KB ROM in bank 0, then more RAM and applications in the upper banks. I do like the relocatable page 0 of the '816, so 1 page of I/O allows apps that use it often to switch their ZP to it. There definitely is a shortage of 65816 projects. A lot of people say it's harder, but the circuits for decoding the upper address lines are readily available in the datasheet, and the 16-bit operations make a lot of code smaller and easier.

Just to clarify, things that are distinctly aware of bank boundaries are program execution—PB will not increment when PC rolls over or if a branch target would apparently be in the next or previous bank, or addressing modes that are bound to bank $00 (direct page, stack and instructions such as JMP (<addr>)). Addressing modes that use a 16-bit address substitute what's in DB for A16-A23, but can still span banks via indexing. Beyond that, data fetches and stores that use indirect-long addressing are completely bank-agnostic to the extent that DB is ignored..