I Am under the assurance of some members of the Forum that i should have my memory layout as ROM -> VIA -> RAM

However, How Much Of The Map Space should my RAM and ROM be taking up 50/50 25/75 etc..
As is common in the Newbies section, I am a beginner but looking to write my own kernel as i come from a background of Software Engineering so am up for the challenge

_________________
Nice Little Community This Isn't It

Keeping the memory map simple initially would probably be best. On a recent project I used:

RAM: $0000 - $7FFF (32K)
I/O: $8000 - $83FF (1K)
ROM: $8400 - $FFFF (31K)

I use a 32K ROM (EEPROM) but don't use the first 1K to make room for I/O.

How much RAM and ROM you need depends on what you are doing with it. If you were planning to run programs in BASIC or other high level language interpreter in ROM then 50%-75% RAM would be about right. If you were running fixed code from ROM you might not need much RAM at all.

What is your intended use case?

_________________
Bill

The 6502 more or less forces the provision of RAM at the low end of the address space and ROM at the high end, so it's very normal to have a memory map like that, with I/O in between. How much you fill the space, how much you set aside for each purpose, is a trade-off and depends on what you're trying to do. If you have at least 16k of space for RAM and at least 4k for ROM, you'll probably be fine. In all probability you'll have more of both.

At some point you need to get a picture of what you're going to put in ROM: whether it's minimal, or maximal. Will there be a Basic, for example, a monitor, a simple OS or a complex one, or just a tiny bootloader.

My Ruby 6502 project has 64K of RAM, (512KB on the '816 version) however this is divided up in a fairly traditional manner and the memory map is:

$0000 - $7FFF: 32KB RAM for general use
$8000 - $BFFF: 16KB RAM for general use, but where a language (e.g. BASIC) might live in a ROM in a traditional system
$C000 - $FDFF: 15.75KB RAM where the operating system lives this might be ROM in a traditional system
$FE00 - $FEFF: 256 bytes IO Space. Currently just a 65C22 VIA
$FF00 - $FFFF: Shared RAM between the 6502 and the host processor with $FF00 through $FF8F being the data transfer area and
$FF90 - $FFFF vectors for software and hardware entry points.

$01.0000 - $07.FFFF - extended RAM in the 65C816 version.

-Gordon

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

By way of adding (I hope) to the discussion, my POC V1.0 and V1.1 units had the following map:

Code:

$0000-$CFFF  RAM (52KB)
$D000-$D7FF  I/O (2KB, decoded into pages)
$D800-$DFFF  unused (mirrors $D000-$D7FF)
$E000-$FFFF  ROM (8KB)

Although I used the 65C816 in those units I did not implement any addressing beyond $FFFF.

POC V1.2, which is going through design right now, uses a similar map:

Code:

$0000-$BFFF  RAM (48KB)
$C000-$C7FF  I/O (2KB, decoded into pages)
$C800-$CFFF  unused (mirrors $C000-$C7FF)
$D000-$FFFF  ROM (12KB)

The above map is actually easier to decode than the map used in V1.0 and V1.1. No more than two gates sit between the address bus and the device being addressed, which minimizes circuit complexity and the effect of gate propagation times on performance.

Speaking of the 65C816, I recommend you use it instead of the 65C02. Interfacing is about the same and you gain the ability to use 16-bit loads/stores/operations, in addition to 8-bit operation. You also get more instructions and addressing modes, such as the very useful stack relative addressing. At reset, the '816 looks mostly like a 65C02 (emulation mode) and thus you can get started with it right away using standard 6502 programming methods. Once you get over the hurdle of getting your system to work, and have gotten comfortable with the 6502 assembly language, you can switch the '816 to native mode operation and start writing 16-bit code—which runs substantially faster than its 8-bit equivalent. When I undertook to build my first 6502 contraption I went with the 65C816 and never looked back.

As for the amount of ROM desired, it all depends on what you plan to do with the unit. My POC V1.0 and V1.1 units had a BIOS and a machine language monitor stuffed into the 8KB of ROM space. That included a SCSI driver, serial I/O, support for timekeeping (real time, plus uptime and a time delay function), console driver, and a jump table for access by programs. V1.2 will incorporate all of the above, plus a different method of calling BIOS services via software interrupts (the COP instruction, which is unique to the 65C816). I decided to go with 12KB of ROM to give me the "headroom" needed for experimenting with new BIOS features.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'd second this. (unless you're really tight for cash and want to save a £ or 2)

It is possible to construct a design that will take a 65C02 or a 65C816 interchangeably if you like. I did it when modifying my Ruby 6502 into an '816 board. The only "iffy" thing is that you end up connecting the ph2out clock to 5v via a resistor. That's probably not going to hurt but you can add in a jumper link if you're uncomfortable with it.

https://projects.drogon.net/ruby-6502-b ... uby-65816/

-Gordon

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