I have written some OSs for x86, but I would like to try for 6502. I am somewhat familiar with the instruction set, and 6502 asm. I would like to know how to write a bootloader, but I am not asking for full source I just want to know how to load my kernel from rom to ram and do the rest of the boot work

_________________
JMP $FFD2

Well, it obviously depends on the architecture of the system.

The 6502 has its RESET vectors at the very top of memory. Whatever value it sees there, it will JMP to on CPU startup.

Typically that points to a ROM location.

If the ROM is to be copied out of, that sort of suggests that the ROM will be banked out when it's done (so as to not consume actual memory space).

You could do a two phase thing, where the the RESET vector points to ROM, the ROM then copies itself in to lower memory, and part of that copy is a routine to bank the ROM out and copy the code back on top of where the ROM was. You could then tweak the RESET vector to point to a warm restart entry point, perhaps requiring a power off to bank the ROM back.

But unless the ROM code itself needs to be in RAM, there's little need to copy out of the ROM. As I understand it, that's done for performance reasons (with ROMs being rather slow), but 6502s aren't fast enough for this to matter, I don't think.

Also, nowadays, many home built machines have separate processors that load up RAM, or download code, etc. before letting the 6502 start up.

And if you're talking booting off of mass storage, that's an entirely different problem.

There's really no "boot work" to be done. I/O is generally memory-mapped, so that has more to do with the bus than CPU state. There are no CPU privilege states or MMU to configure. It's just a flat 16-bit address space with direct per-byte single-cycle access to RAM/ROM chips and no cache.

The only other thing beside RESET that I can think of is to make sure your interrupt vectors (IRQ and NMI) point to a desired location, but those are up by the RESET vector and typically are set to ROM locations. The ROM handlers for these will often indirect through RAM so that user programs can hook in their own extensions, or some systems like the C64 allow you to bank out the ROMs to let RAM reside at those top-of-memory vectors for less indirection, saving quite a few cycles.


In booting off of mass storage, it's still the same sort of issue. RESET points to your ROM loader, IRQ and NMI might be used for I/O signaling, then your code does whatever it needs to talk to storage using bus-mapped memory reads & writes to pull in programs.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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