6502.org

The objective:
------------------
A 65C816 based SBC, with built in VGA and keyboard interface, UART, and some sort of mass storage. I want it to be as self-contained as possible, meaning that it should be able to operate without being connected to a PC, and being able to write code for it on itself. That's the long term goal anyway.

Some "specifications":
-Regarding video, I just want it to be usable as a terminal and do rudimentary graphics. A screen resolution of 400 by 256 would result in 50 columns and 32 rows for text. That would result in 16 K of RAM for monochrome video. I could implement it with discrete IC's or using a CPLD. I want the video circuit to read off the system RAM directly.
-Keyboard, PS/2 interface using a couple of shift registers should do, could be integrated in the CPLD as well.
-UART: Either using a suitable IC or inside a CPLD if space left.
-Mass storage: Maybe an SD card with a rudimentary file system. This will come later.
-Memory: I may stick to 64 K address space, or have an extra 64 K of RAM in bank 1. I just want to build a "experimental" computer to play around with. I don't quite envision a use for large amounts of RAM.

I have quite a lot of things to figure out. I have also been fighting with the WDC software (and documentation) without much luck. I need to spend more time on it. I could try other assemblers, but having a simulator/debugger is certainly desirable. For initial development I can use the 6502 emulation mode anyway.

A possible prototype build:
-------------------------------
I have some 65C816's around (I have done the NOP test on a couple in a breadboard, they work, but not sure if they are legit as they came off eBay) , plus HM628128-ALP-7 128 KB 70 ns static RAMs and AT28C256 15PU EEPROMs.
I thought I could build a minimal prototype system, just to get used to the 65C816 and to try out some ideas.

Of most interest would be RAM accesses during phi 1 by the video card. My TTL 6502 computer's video card detects writes to a range of addresses and saves that same data to the internal RAM.
I intend the video circuitry on this system to read directly from system RAM, as the Apple II did. The easy way is, of course, to use dual ported RAM, but I'll try not to for the time being.

So the idea is to build a simple system, in order to get that working, sticking to 64 K. I don't have to build an entire video card, just the part that interfaces with the system RAM. As for I/O, it may suffice with some push-buttons and LEDs, or even a character LCD.

Clock speed would be 2.5 MHz (20 MHz pixel clock/8, for a screen resolution of 400 by 256, using 800 by 600 SVGA timing). Significantly lower than some of the projects around here, but the Apple II GS did run at 2.8 MHz, so it should be enough for my purposes. On the future version, with faster parts, one could go with 5 Mhz and have video access RAM every other cycle...

Below is a block diagram and timing diagram of what I'm thinking about.
RAM address would be selected from either the CPU or the Video circuit by a multiplexer driven by phi 1, while ROM address would be coming straight from the CPU in order to allow it some extra time to respond (it takes 150 ns from /CS to data valid, and 70 from /OE to data valid)
Driving /OE with phi 1 would ensure it does not output while the video circuit is accessing RAM.
Also, RAM's /WE is "forced" high during phi 1, regardless of RWB.

I surely have missed something, I'm just thinking out loud.

But
-------------

A lot of my design decisions are based on my parts bin. I don't want to build a more limited system just because I wan't to use those parts. So it may be better to design a final system, order some parts, then do a simple prototype towards designing a PCB or go to the PCB directly and expect to add bodge wires and what not.

If I decide to use a CPLD, I would have to find a suitable one and learn to use it. ATF15xx seem suitable as stated in several places on this forum. I'd have to acquire some, and needed programming cables and such. They are in-system-programmable by JTAG yet I don't know if I could use my TL86 programmer for that. It does support ATF16XX devices, which are maybe too limited. I don't mind purchasing Atmel's cable/adapter if I get some decent use out of their CPLDs.


Some random thoughts and ideas
---------------------------------

One could use the VPA and VDA pins in order to overlap ROM and a portion of RAM dedicated to video, say 16 K. As no code would be executed from that portion of RAM, we would be getting an extra 16 K. Not sure if it makes much sense on a 65C816 system, capable of addressing 16 MB, but if one sticks to 64 K it may be useful.

EEPROMs are more difficult to adquiere in faster speed grades, so if one wants to go faster there's the option of using a microcontroller/CPLD to copy code to RAM before start up. It occurred to me that one could put $EA on the data bus upon power up, and use the increasing addresses to copy contents of a ROM to RAM from $EAEA to $FFFF at a slower clock speed, then disable the ROM, and reset the CPU while switching to a faster clock.

I could use the 65C265 microcontroller as well, it has built in UART and other commodities. I don't mind if I'm limited to 5 or 8 MHz.


Conclusion:
------------------------
I didn't want to use a CPLD if I could avoid it, to keep things simple. But not using it would complicate matters and increase board size (I have to put a discrete VGA controller somewhere). And also it would give me more flexibility to modify things later on.

So I think I'm going towards something like Daryl's SBC-3.

Apologies for the long and messy post. It is just a brain-dump (looked it up, the expression actually exists...). I just want to get things going and writing it down helps a bit. Any suggestions are welcome.

Juan

I may comment more later on, but did you by chance overlook what the 65C816 is doing on the data bus during Ø2 low?

I did include a 74HC245 bus transceiver in the block diagram. Without it video RAM accesses would collide with bank address put out by the '816.
Juan

I've wired up a 65C816 in a breadboard with an EEPROM, some address decoding & data bus buffer, and a latch connected to some LEDs. No RAM yet. I just made a simple program to get the LEDs to count, and it just works. (Well, you have to slow the clock down in order to see something...). I also tried to put the CPU in native mode, and the CPU puts the expected bank address on the data bus, and the Emulation pin changes when it should. It seems to work. Just for kicks I sped up the clock and it stops working just under 9 MHz with 150 ns EEPROM.

I've been thinking about the CPLD. I'm considering two options:

Altera MAX II family:
-Pros: I already have a programmer & used their software (Quartus). Macro cells running from 192 to 980 (gets expensive pretty quick), plus 1 KB "user flash" that could hold some bootstrap code. Convenient development boards can be cheaply acquired on eBay for prototyping. More I/O pins.
-Cons: 3.3 V only: 3.3 V system or level conversion (Higher end ones have some 5 V tolerant I/O, but are too expensive). TQFP-100 packages, not sure about soldering those with my current soldering iron. Not cheap enough to risk it.

ATF15XX:
-Pros: 5 V, PLCC packages which I can socket, and prototype with.
-Cons: Specialized programming cable. Less macro cells, 128 for the higher end ones. Less I/O. Outdated software (Apparently one can code in Verilog on Quartus, and then translate the output files for programming, see here https://www.eevblog.com/forum/fpga/atme ... d-wincupl/)

I would be using the ATF1508. Here it is mentioned that it may be suitable for a simple VGA interface like the one I'm thinking of viewtopic.php?f=10&t=4997

I would like to consolidate as much as I can into the CPLD, at least the VGA interface and address decoding, and ideally also the PS/2 interface and even the UART as well. I may have to use a couple of them to fit everything.

I just want a simple system, mostly though hole. In a 5 V system, I can just use a through hole EEPROM in a ZIF socket to store code. Not sure about a 3.3 V one. RAM will have to be SMD most likely in both cases, but it should pose no problem.

I think I'm going to order a couple ATF1508s and a programming cable, and get the video working first, then work on the rest.

Juan

EDIT:Spelling

I've given it some more thought, and I'm going to throw an FPGA at it. Just because I've got one .
I wanted to put many things inside of the CPLD, and I would need a large one anyways. An FPGA, with some amount of internal RAM, PLLs and other nice stuff eases initial development (we'll see about that). One can hold bootstrapping code on the FPGA as well.

So I would have a 65C816 CPU and extra RAM as discrete ICs, everything else will go inside of the FPGA. I will be using a Cyclone II, in the same "development" board that Grant Searle uses in his Multicomp project (http://searle.x10host.com/Multicomp/index.html).

Replicating that project sounds great, and I may in the future. For this one though, I want to do everything from scratch.

The FPGA is probably overkill for what I'm going to use it for. It may even be enough to fit a 65C816 soft core (I've searched around and it doesn't seem to be one freely available). I don't know if having an external CPU makes much sense, it's likely to be slower than a hypothetical soft core as well. But it is probably the easiest way.

Attached is a mockup of the SBC and a screenshot of the simple text-only vga card I've programmed in verilog.

I'll try to connect the '816 to the FPGA, and see how it works out. I have to figure out how to keep the CPU under reset while the FPGA boots. Maybe a simple resistor to ground suffices.

External RAM will come later, for initial tests, the 14 K inside the FPGA are enough. I'm using 2 K for the character RAM and 1 K for the character ROM for the VGA interface.

Juan

Forum member Rob Finch posted his bc65816 core on his web site, here.

-- Jeff

Thanks. Missed that one. I saw on one site that there was no 65C816 soft core available and looked no further.
Unfortunately it says bc65816 is untested, and his FT816 core is too big for the FPGA I have according to this page. Mine has 4096 Logic Elements, and the core takes well over 5000.

The original plan was to have programmable logic just for the peripherals, but who knows, I keep changing my mind too often...
Juan

I had pretty much the same goals when I built my 65C816 based SBC in 2016. I also postponed the Mass Storage to later and so added a small IO bus to the SBC to add a 8-bit IDE Interface for CF Cards later.

viewtopic.php?f=4&t=4195

In addition it emulated an Apple II.

It features

- 512kbyte of RAM using a single AS6C4008
- 32kbyte of Dualport RAM for the Video RAM
- An Atmega1284P MCU that deals with the PS/2 interface and generates the Video
- One ATF1508 for the GLUE logic

The MCU generates the VGA Signal using the second port of the DP RAM to read the video data. For non-graphics mode it also emulates the character ROM. It also deals with the PS/2 keyboard. The trick is to use one USART of the MCU in synchronous mode so the bytes sent by the keyboard can be received without any software intervention by the MCU. The MCU runs a main task which deals with the command interface, the keyboard handling and bootstrapping the 65C816 and the interrupt task which generates the VGA signal.

There is no ROM as the MCU is able to load a ROM image into the RAM at power-up or reset and then the GLUE logic write protects the region in RAM. The MCU also generates the PHI2 of the system so you can change the system clock from 11MHz down to static.

And I wanted it to have a genuine CPU not a FPGA.

I also built a 8-bit IDE interface on a second board and added a driver so I could use Apple PRODOS 1.9. But the interface limited the clock speed to 4MHz, which was not very nice.

There are plans for a ROMulus the 3rd which will include a CF-Card using SPI and at least two Serial port. However my current free time is pretty much used by my PDP-11 projects

Peter

Indeed. Nice project. That's very close to what I was aiming for. Fitting the video, glue logic, and a way to load RAM on startup on the CPLD as I intended is maybe a bit ambitious. I may explore the micro controller route on a future project as it seems to be a popular solution.

The end goal is learning at any rate.
Juan