Instructions all in ram?

[sci4me]

Okay, so.. this is something that I haven't really figured out yet and I really need to understand. So, in every processor system I've seen, the instructions are all in ram. My question is how do the operating systems exist on a disk drive (or something like that) if the instructions go in ram. The only way I can think of to do this would be to have the code in the ram read instructions from the disk and execute them. Because I assume that it would make no sense for the entire system to be in ram... so, is this how it's done? Is there some other way?

BTW sorry for "spam topics" but the topics aren't really related so..

[Arlet]

Every system has some non-volatile boot memory. On PC motherboards, there's the BIOS that's stored in a flash chip, for example.

[GARTHWILSON]

This non-volatile memory Arlet refers to is generally ROM, and the reset routine resides there, pointed to by the reset vector which is also in ROM. The RST\ signal sets the processor up in a known state and then when it is released, it grabs the beginning address of the reset routine from the reset vector, goes to the reset routine and starts executing. Depending on what the system is made for, the whole application could be in ROM (as in the case of microcontrollers which have no mass storage of any kind, or access to any), or the ROM may only have enough code to tell the processor how to load an application from mass storage or other outside source. In many cases, the ROM may have an entire language like BASIC or Forth onboard which is extensive but does not contain actual applications. A well known example is the Commodore 64 which had BASIC ready to go as soon as you turned it on, and you could type in BASIC commands or program lines, or load a program from disc, etc.. If it did not have the instructions already in it in ROM, it would not know how to display anything, scan the keyboard, ask the disc drive for a program, or even beep.

Do check out my extensive 6502 primer which is logically organized into many subjects, at http://wilsonminesco.com/6502primer/index.html.

[BitWise]

When a CPU is reset (or switched on for the first time) it will begin executing code from a location that either fixed in the CPU's design (i.e. a Z80 starts at location 0x0000) or defined by a 'vector' (e.g. an address value) stored at a specific location (i.e. the 6502's reset vector at 0xfffc), so normally you must have a small amount of ROM which is accessible on reset.

Often this ROM contains a simple 'bootstrap' program which accesses a device like a floppy or a hard drive and reads more program code into memory from a fixed location (i.e. the first few sectors of the disk) and executes it. Often several stages of bootstrapping, each more sophisticated than the last, are needed before you have all the code needed for a complex operating system to be loaded into RAM and fully initialised.

Most CPUs can be kept in a frozen state by means of some control pins, for example by holding the 6502's reset pin LO does this. This means that another device can take control of the address, data and control lines to write into memory at the location where the boot ROM would normally be. This makes the main CPU effectively ROM-less only having RAM (and I/O areas). When CPU is released to start its reset processing it will execution the code put into its memory as if it had a ROM but with the advantage that it can be overwritten later if need be. You can use a microcontroller like a PIC or AVR to do the memory initialisation because these devices have an EEPROM memory designed on to the same silicon as their CPU.

Another trick is to have a boot ROM that appears in the memory space when the device is reset but which can be disabled (and hidden) under software control. Lots of 8080 and Z80 machines do this because operating systems like CP/M expect the memory starting from 0x0000 to be RAM. Often such ROMs copy themselves into a different RAM area and then disable the ROM before starting the operating system.

[Justin]

Sci4me - Check out the "Demonstration of bootstrapping a ROMless machine (not 6502)" thread in Newbies. That machine has nothing but RAM. After seeing what it takes to get that machine started, you can see why boot ROMs were invented

[Arlet]

GARTHWILSON wrote:

Depending on what the system is made for, the whole application could be in ROM (as in the case of microcontrollers which have no mass storage of any kind, or access to any)

Most of the smaller microcontrollers (without external memory bus) have internal flash memory for the user programs. The higher end microcontrollers/SoC often have a bootstrap mask ROM, and then load code from external (NAND) flash.

Some years ago, I worked for Intersil, and actually wrote a couple of boot ROMs for their SoC devices. The most sophisticated of those (the ISL3893) could boot straight from network interface, although this was only used for internal development.

[BigDumbDinosaur]

BitWise wrote:

When a CPU is reset (or switched on for the first time) it will begin executing code from a location that either fixed in the CPU's design (i.e. a Z80 starts at location 0x0000) or defined by a 'vector' (e.g. an address value) stored at a specific location (i.e. the 6502's reset vector at 0xfffc), so normally you must have a small amount of ROM which is accessible on reset.

Often this ROM contains a simple 'bootstrap' program which accesses a device like a floppy or a hard drive and reads more program code into memory from a fixed location (i.e. the first few sectors of the disk) and executes it. Often several stages of bootstrapping, each more sophisticated than the last, are needed before you have all the code needed for a complex operating system to be loaded into RAM and fully initialised.

The above is the pattern followed by my POC unit. The BIOS ROM contains enough code to load a boot block from SCSI disk $00 and execute the code therein. The only significant difference is that the same ROM also has a machine code monitor, which acts as a primitive "operating system" if the load-from-disk fails to start a real one.

Quote:

Most CPUs can be kept in a frozen state by means of some control pins, for example by holding the 6502's reset pin LO does this. This means that another device can take control of the address, data and control lines to write into memory at the location where the boot ROM would normally be.

Another way to do this is by asserting the 65C02/65C816 RDY and BE inputs to halt and tri-state the MPU. The data sheets do not indicate (or even imply) that the MPU goes to tri-state while RESETB is being held low. It's conceivable that inadvertent bus contention could occur while the other device is writing to RAM.

[BigEd]

It might be worth pointing out the historical trends in 6502 systems: at first, they had minimal RAM, 128 bytes or less, and all the program would be blown into ROM and fixed at system manufacture. For a games machine, that ROM was in a cartridge, so it was fixed at boot time depending on which cartridge you plugged in.

A later generation would have 4k RAM or more, but still have significant ROM: 8k, 16k or 32k. They'd have an OS and a BASIC in ROM, and RAM was either for BASIC programs or machine code programs.

Later still, the PC-compatible market followed a different tack, somewhat like the CP/M that it derived from, where the ROM was a minimal bootstrap and a hardware compatibility layer: the BIOS. The BIOS has doubtless got bigger over time, but it is utterly dwarfed by the amount of RAM. We no longer load BASIC programs; generally we're running machine code (originally written in some high level language and compiled)

So, from a modern perspective, almost everything runs in RAM and the BIOS is barely visible or even forgotten. But the principle remains the same: at boot time, the first few instructions have to come from ROM, and they need to initialise the hardware and load the next piece of code from a peripheral - generally a disk, but could be a network or flash memory or an optical drive. That piece is generally pretty small - 512 bytes or 4k - and is just enough to load the next bit. Eventually you get to code which understands a filesystem, and code which manages the machine and can load applications.

Cheers
Ed

[sci4me]

Thank you all for the replies. So, I suppose what my question should be is how to create a bootstrap... to the point where it is able to load an OS from a disk of some sort. But, i'll work on that stuff later... for now i'll just stick to learning and designing my processor.

[nyef]

As a semi-exception to all of this "startup code executes from ROM" line, and a little off-topic for 6502.org, I offer up the example of certain Alpha CPUs, which loaded the full CPU state from a serial EEPROM on startup, including the contents of the I and D caches, and then executed bootstrap code out of the I cache until it managed to set up the north bridge so that it could access the system RAM and ROM.

[White Flame]

sci4me wrote:

Thank you all for the replies. So, I suppose what my question should be is how to create a bootstrap... to the point where it is able to load an OS from a disk of some sort. But, i'll work on that stuff later... for now i'll just stick to learning and designing my processor.

Assuming you get a ROM in the upper memory space, the vector at $fffc holds the address where the CPU should start executing, and point to code held in the ROM. That's pretty much it. It's simply a normal 6502 program that has some data at $fffc (and the interrupt vectors if you're using them) burned into a ROM.

Nice features to add to your startup program would be doing a memory scan to see how much is in there, setting up interrupt sources, routines to talk to IO devices, some way to input commands (or blindly load off a storage device), and the other things mentioned here.