Help on choosing an MMU for 65c816

[franz357]

Hello,

I would make a ''homebrew computer'' based on 65c816

What is a good MMU easily purchasable, which allows you to connect to the cpu :
1 rom 8MB
1 ram 256KB (another cpu (cpu 2) must be able to read in this ram)
1 ram 256KB (another cpu (cpu 3) must be able to read in this ram)


Thanks

[Dr Jefyll]

Welcome!

Do I understand correctly that you intend for your project to have THREE cpu's plus an MMU? This is far too ambitious for a novice.

I hope you have lots of fun and success playing with our favorite microprocessor family, but to do so you'll need to start with more modest goals and then later aim for greater achievement as your skills develop.

Can you propose a simpler set of specifications for your first project? We'll be glad to assist.

--Jeff

[franz357]

Dr Jefyll wrote:

Welcome!

Do I understand correctly that you intend for your project to have THREE cpu's plus an MMU? This is far too ambitious for a novice.

I hope you have lots of fun and success playing with our favorite microprocessor family, but to do so you'll need to start with more modest goals and then later aim for greater achievement as your skills develop.

Can you propose a simpler set of specifications for your first project? We'll be glad to assist.

--Jeff

Thank you for welcome,

Something simpler would perhaps be (missing the "audio part") :
https://i.postimg.cc/hPQF9G4V/schema2.png

1 cpu
1 rom 16MB (15mo used) (is the soft)
1 rom 256KB (is for fonctionnement)
1 ram 512KB

- "inputs" it's 2pads with 2octets by pad
- a dac will receive the 300KB stocked in ram for the image 320x240 pixels

I would use if possible the addresses:
000000-EFFFFF (15MB) for rom1
F00000-F7FFFF (512KB) for ram1
F80000-F87FFF (256KB) for rom2

What do you think ?

[Dr Jefyll]

First of all, allow me to mention that, on this forum, your images can be attached to your posts. This is more convenient than using a third-party image sharing site, and it also ensures the images will remain visible in future.

I like the simpler goals you have here. What are the pads and the octets you mention? Is this project a game of some kind? (I don't know much about that kind of thing.)

Because your project includes video it may still be rather challenging for a novice. Have a look at some of the other projects undertaken by novices. Also maybe check out a fellow called Ben Eater who has instructional 65xx videos online. I think he's on YouTube, and he's quite popular (although I've never viewed any of his content).

-- Jeff

[and3rson]

I think a bigger problem here is the DMA, not the MMU.

In your setup, all the MMU needs to do is to decode address lines into chip selection signals, which for 3 chips is likely going to take just a few NAND gates (or a single PLD).

DMA (direct memory access) to your RAM - i. e. reading/writing RAM by some other controller without involving your primary CPU - is a tricky thing, and it's been practiced a lot by people on these forums who want to add video output to their computers. Personally I didn't have enough guts nor experience for that..

I'm not too familiar with '816, so here are some of my personal thoughts as from someone who comes from '02:

Easiest way to go would probably be to use a dual-ported RAM - you don't need to worry about bus sharing, timings and signal propagation delays. Unfortunately, dual-ported RAM chips don't seem to be popular nowadays, which is a problem unless you're fine with using parts that have reached end-of-life and aren't manufactured anymore.

Slightly more complex method is sharing the bus by doing DMA while CPU Ф2 signal is low (this is easier to do with 65C02, since 65C816 will still drive the data bus during low phase of Ф2 to present address lines 16..23)/

Most complex method (although, in case of '816, it might be easier than previous one) is stalling the CPU, doing the DMA, and then resuming the CPU. The problem with this approach is that you cannot stall the CPU whenever you want: you must synchronize this with Ф2 signal to make sure CPU has time to finish what it's doing and release the buses for your DMA to take place. If your secondary controller is very timing-specific - e. g. if it needs to access RAM at very precise times to generate real-time video signal.

Some helpful posts:
- viewtopic.php?f=4&t=2898
- viewtopic.php?f=4&t=2438

EDIT: As Jeff mentioned - video is indeed hard, mostly due to its time-sensitive nature.
As for the pads - what exactly do you mean by those? If they are some input devices, you will definitely need additional components to handle them and possible generate interrupts whenever the input state changes.

EDIT 2: If you're trying to build your first SBC and would like to have some visual output - I highly recommend to start with a character LCD display. Those things are cheap and come in all shapes and sizes: 8x1, 8x2, 16x2, 20x4, 40x4 - just to name some. There are even OLED versions of those - I recently purchased one. All of them usually have 16-pin headers and use HD44780-compatible controllers. There are even bigger ones based on T6963C-compatible controllers (I have two, 240x64 & 240x128 pixels, and they also have built-in fonts).
Besides, if you run your SBC on a relatively small speed - say, 1 MHz - you can interface the above-mentioned displays directly with your CPU without the need in additional parallel I/O ports. This means you can build an entire very simple SBC with just a handful of chips: CPU, RAM, ROM, address decoder, and a display itself!

[franz357]

Dr Jefyll wrote:

First of all, allow me to mention that, on this forum, your images can be attached to your posts. This is more convenient than using a third-party image sharing site, and it also ensures the images will remain visible in future.

schema2.png

I like the simpler goals you have here. What are the pads and the octets you mention? Is this project a game of some kind? (I don't know much about that kind of thing.)

Because your project includes video it may still be rather challenging for a novice. Have a look at some of the other projects undertaken by novices. Also maybe check out a fellow called Ben Eater who has instructional 65xx videos online. I think he's on YouTube, and he's quite popular (although I've never viewed any of his content).

-- Jeff

For the moment I don't worry about the DAC, first I connect memories to the CPU
I mentioned the DAC so that it could be taken into account in the ram choice criteria

Yes I would make a console game , I programmed my GFX engine 2d
"the pads" have 12 buttons (12bits) , I make diy pad with arcade's buttons and stick

[GARTHWILSON]

Dr Jefyll wrote:

What are the pads and the octets you mention?

He's apparently not a native English speaker.  "Octet" in French (and maybe other languages too) is a byte.

franz357, I left you a PM (private message).  Be sure to check your PMs.  You should get an automatic pop-up message telling when you have a PM.  If you don't get this, you can edit your settings in the "User Control Panel."

[Dr Jefyll]

Thanks, Garth.

franz357 wrote:

I programmed my GFX engine 2d

Alright, good. Just be aware that hardware is a whole different subject, and it involves a lot of detail -- more than one might initially suppose.

and3rson makes a good point regarding LCDs. For a novice project an LCD would be much more suitable than video.

-- Jeff

[gfoot]

It's definitely worth at least building a simple design first, even if it's not what you really want to make - you will learn a lot just from doing that, and if it doesn't work then you'll know it's due to your construction technique rather than the design itself being flawed. Personally I started out with Grant Searle's 7-chip 6502 computer (but left off the serial communication IC) and once you've got that kind of thing under your belt, you can easily progress to adding more interesting output (graphical LCDs, even analog video) and input (pads can be connected up to a 6522, for example, which most of these simple designs will already have).

I can't speak for the 65816 and whether it's a suitable goal to build based on that as a first system, as I've not used it at all myself; I do worry though that it's more complex and maybe less suitable for a first attempt.

My main advice would be, at each stage in your development, think of something you're 90% sure you can achieve, and then don't go any more than 10% more complicated than that! Every time you build something that works you'll gain more knowledge and confidence, and eventually you'll be in a good position to actually attempt the thing you originally wanted to build. When you build things that don't work, on the other hand, you will gain different knowledge, but it will be very frustrating and you might give up!

[BigDumbDinosaur]

and3rson wrote:

EDIT 2: If you're trying to build your first SBC and would like to have some visual output - I highly recommend to start with a character LCD display.

Another possibility is to use Geoff Graham’s VT-100 ASCII terminal, along with a UART for console I/O.  I started a topic on it right here.

Whatever path you take to equip your unit with a console, you want to be as uncomplicated in that regard as you can.  In a first build, as you are planning, it is a lot easier to debug the hardware if you don’t introduce the additional complexity of a video subsystem, which as noted, can be a challenge to get working.  Also, there will be the challenge of achieving a workable keyboard.  I suggest you give that more thought before you get too far into your design.

[franz357]

Let's not focus on the display for now

For now I just want to connect memories to the CPU

[anomie]

GARTHWILSON wrote:

"Octet" in French (and maybe other languages too) is a byte.

Even English, maybe.

*mumbles something incoherent about practically all of the RFCs he’s ever read*

Edited to add an aside: way back, ‘byte’ used to be used like ‘word’ in the sense that it was a machine-specific size. As an example, the MIX machine in Knuth’s “The Art of Computer Programming” series had six bit bytes (for the binary one, anyway, there was also a decimal machine spec’d in the books). There’s real hardware, probably in computing museums now, but maybe someone somewhere still has something running, that had not-8-bit byte sizes as well. So, as far as I understand, RFCs use ‘octet’ for exactly eight bits because it used to matter.

Edit again: I expect plenty of people on this forum already know this. I’m basically just rambling here, don’t mind me.

[Dr Jefyll]

franz357 wrote:

For now I just want to connect memories to the CPU

In your intro you said you don't know much about electronics and hardware (and of course we all need to start somewhere). Are you familiar and comfortable with the signals that allow a RAM to function? There are the address inputs, the data input/outputs and several control signals, each with a unique and crucial function. This is the sort of detailed knowledge you'll need now that you're entering the world of hardware.

Luckily, there are lots of resources available. Have a look at Garth's primer and we'll be glad to assist with any questions you may have!

-- Jeff

[and3rson]

Here's a possible implementation of address decoder for your memory map using 3 74x00 chips (I'm sure some guys on this forum can take the gate count even lower):

I'm using a tool named "Digital" for simulating logic circuits such as the one above. It has lots of components (including many 7400 drivers/flip-flops, RAMs and even PLDs), and it's free and open source. Here's the circuit file that you can use to run the simulation locally:

816dec.zip

(1.05 KiB) Downloaded 145 times

Alternatively, if you're OK with using PLDs (e. g. GAL16V8 or newer ATF16V8 - I like them because they come in standard DIP packages) - you could have a reprogrammable address decoder in a single chip. Equations for your current memory map would then look something like this:

Code: Select all

GAL16V8
AddrDec

NC   A18  A19  A20  A21  A22  A23  NC   NC   GND
/OE  ROM1 RAM1 ROM2 NC   NC   NC   NC   NC   VCC

 ROM1 =  A23  *  A22  *  A21  *  A20  ; 000000..EFFFFF
/RAM1 =  ROM1 * /A19                  ; F00000..F7FFFF: ROM1 = 1, A19 = 0
/ROM2 =  ROM1 *  A19  * /A18          ; F80000..F87FFF: ROM1 = 1, A19 = 1, A18 = 0

DESCRIPTION
Address decoder

[nyef]

anomie wrote:

Edited to add an aside: way back, ‘byte’ used to be used like ‘word’ in the sense that it was a machine-specific size.

To jump on this real quick... The programming language Common Lisp has "signed-byte" and "unsigned-byte" types which can be parameterized by the number of bits involved, and has a "byte" function for specifying a consecutive run of bits within a larger integer for various shift/mask operations, and it inherits this from previous incarnations of Lisp. A "byte" is not always a machine-specific type, and not always a constant size, let alone always eight bits.