I had an idea it might be fun to build something like a "souped-up BBC Micro" using a 65C816 processor instead of a 6502, running as fast as reasonably possible, and loads of RAM. As a stepping stone I built a prototype system to develop and test some building blocks. The prototype has a 65C816 running at 12.5MHz, 256KB RAM and a VGA display. The video controller accesses RAM on a multiplexed basis with the processor - when PHI2=0 the video controller accesses RAM, when PHI2=1 the processor accesses it. The video controller, RAM multiplexer and all address decoding is implemented in an EPM7128 CPLD which sits between the processor and RAM. The memory map implemented is as follows (only 20 address bits are used - the top 4 are ignored):

00000 - 3FFFF 256KB System RAM
1A800 - 3FFFF Frame buffer 150KB (640 x 480 x 4bpp)
40000 - 7FFFF Unused (possible extension RAM)
80000 - 8FFFF 64KB System ROM (Winbond W27C512)
90000 - BEFFF Unused
BF000 - BFFFF Writes to this area update HW scroll registers
C0000 - FEFFF Unused
FF000 - FFFFF 6522 VIA (even addresses only)

An FT240 USB module (this one: https://www.ecstaticlyrics.com/electronics/USB/FT240X/ ) is currently attached to the VIA - this serves as keyboard input for now (PS2 support will be added later - that's one of the things which need developing). It also allows code to be downloaded to the board from a PC, and memory dumps to be uploaded to the PC. System output can be switched between the VGA display and the USB port.
An expansion connector is present. This is intended to be used to add an extra board with another CPLD on, which can be used to implement building blocks to be developed. These include a PS2 controller for keyboard connection, SPI controller to allow serial flash and/or SD/MMC to be used as mass storage, and I2C controller to connect to RTC and clock generator chip. The extra CPLD can also do address decoding for a second block of 256KB RAM - the Video PLD is completely maxed out on I/O lines, and very nearly maxed out on logic.

So, here's the schematic:
Here are the Verilog files for the Video CPLD:

And here are some photos of the prototype.
This is the top of the board (component side):


This is the mess of wires on the bottom (along with SMD caps and resistors)


This is the test pattern the video controller displays before the processor starts running:


This is a memory dump from the system boot monitor on the video display:


Colour text:

Like this design a lot. I have 6502 sharing the memory with video at 12.5mhz, but 65816 certainly provides more memory for the graphic. I have used FT240 in one of my designs and really like the high speed transfer and simplicity of the interface. I think it is an excellent choice for data intensive graphic hardware.
Bill

I am confused. I have just started working on a 65816 design, so I am pretty much a newbie here. Doesn't the CPU output the bank address on the data bus during phi2 low phase? I thought it wasn't possible to share the bus on a 65816 system, as we do with the 6502.

I think you can do whatever you like if you have the appropriate multiplexing and glue logic - it's all possible but it's less simple. (And the glue logic and multiplexers will probably affect the max clock speed, of course.)

Edit: a block diagram showing the busses would be very helpful here!

That's not a problem if the CPLD isolates the CPU data bus from the ram data bus during the video access half cycle.

The upper address bits from the CPU can be latched while the video data is read, and then the full 24 but CPU address is ready for the CPU half of the cycle when the 2 data busses are linked.

Cool! Thanks for the information. I just notice on the schematic the data bus goes through the CPLD. Noted!

Yes, as others have pointed out the RAM is not connected directly to the CPU but via the CPLD which deals with multiplexing the address and data paths between the CPU and the video controller.
Here's a basic block diagram:

Thanks for the diagram!

I've now got a rudimentary port of BBC BASIC v2 running on the board. It's the full interpreter as found on the BBC Micro, but lots of the MOS features are currently missing.
ClockSp runs and gives the correct result for a system running at 12.5MHz.

Splendid! You might find Basic4 to be a nice choice - the interpreter uses 'C02 opcodes and delivers more performance. I see you already have a nice large HIMEM.

Well done!

Did you port it, as in assemble from source, or just drop the ROM image in?

I have the ROM images for all versions of BBC Basic going in my Ruby 6502 (and 816) systems (HIMEM is &8000) - Basic4 is far faster for floating point. I started with just the bare minimum MOS calls but it's now pretty much fully fledged for the hardware (no sound, but one day...)

I've not yet tried to get the '816 version of BBC Basic going - not really sure where to start there..

But hey - maybe another system to run my BCPL OS on ...

-Gordon

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

Ah yes, of course, the '816 version for the Communicator... would need a slightly different kind of OS shim, I think, and possibly also has a dependency on another module which it would need to be able to find. A project!

I assembled it from source. I got the source code for both Basic 2 and Basic 4 from here:

https://mdfs.net/Software/BBCBasic/6502/

The source there is in "BBC Micro Inline Assembler" style and I've been using ACME for my coding (and the MOS assembler listing is for ACME) so I first converted it to ACME assembler syntax. I ended up with the following files:




These files both assemble with acme to give binary identical output to the original ROM images. So far so good.
I changed the start address of the code from $8000 to $B800 and added a minimal MOS implementation - basically just OSWRCH, OSRDCH, OSWORD 0,1,2, a few OSBYTE calls (to get PAGE, HIMEM and a few other things). It didn't work at first, which I discovered was due to the TXS instruction doing something not terribly useful if x=1 - it sets the stack to be in page 0 instead of page 1. So I replaced all the TXS instructions with calls to a routine which does S = $0100 | X. After that BASIC 2 seems to work. However BASIC 4 is being more awkward and I haven't got that to work yet. Interestingly, the source for BASIC 4 didn't originally match the binary ROM image. The assembler mnemonic table seems to be slightly different. I just modified it by hand to match the ROM image.
I'm not running BASIC in 65816 emulation mode - I'm running it in native mode with m=x=1.

I might have a look at that at some point - I did try to convert the "sources" to ca65 format but it never produced an identical binary...

And yes - anything with TXS is prone to issues unless in emulated 6502 mode - I arranged my OS to drop into 65C02 emulation mode before calling a ROM, then it's up to the ROM code to convert to whatever mode it needs (So it allows BBC Basic, EhBASIC, etc. to work, but my BCPL "ROM" immediately switches back to native mode). I had issues when I moved to the '816 as the extra hardware vectors get in the way, so I patch the ROM at load time to cater for the changed vectors (another reason I want to re-assemble from source at some point).

Cheers,

-Gordon

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

Got BASIC v4 running at last, and as expected the floating point is considerably faster - the trig/log test is just over twice as fast.


The list of things which needed to be changed was as follows:

1. Two instances of JMP ($020E) needed to be changed to JMP OSWRCH since my MOS implementation doesn't have OSWRCH vectored through page 2
2. All uses of TXS replaced with calls to a routine which performs S = $0100|X
3. The Basic4 floating point code relies on the fact that the zp,X addressing mode calculates the effective address modulo 256 on the 65C02 - if the sum of zp and X exceeds 255, it wraps within page zero. On the 65C816 it doesn't do that - it produces an effective address in page 1. The wrapping behaviour allowed some loops to be coded starting with a negative value of X and incrementing towards zero, using the zero flag as a loop termination indicator. I had to change these loops to increment upward from 0 and add a CPX instruction to test for the end point.
4. Items 2 and 3 above increased the code size above 16KB. The last page of the Basic4 ROM image contains a table of floating point constants used to evaluate transcendental functions. The code assumes that this entire table fits into a single page - it refers to the constants with 8 bit addresses and assumes all the addresses have the same top 8 bits. The increase in code side meant that didn't work any more, so I had to relocate the table to nearer the beginning of the ROM and ensure it was all in one page.

Here's the (seemingly) working source code:

Although it has to be said it hasn't been very heavily tested.