OSDev.org

kmcguire wrote:You would _need_ some type of firmware that could boot the system into a ready mode by loading a starting screen for the user. The loading could be done from the network or a storage device (flash, platter).

I agree. I was thinking how it would load games, e.g. you would insert a cartridge (the ROM in emulator terms), and would the cartridge content's get dumped straight into memory then start executing from address 0?

But then how would games handle game resources (sprites, music, sound effects, level data, etc)? Usually they have to be uncompressed/parsed/loaded before they can be used, so it would be a waste of memory. What would happen if the cartridge was larger than the main memory? I'm sure you can think of other problems.

So I need a firmwire which is copied into memory on bootup, and that scans the cartridge for a file system and loads the game into memory.

EDIT: I've finished most of the CPU specification along with the debug controller so I'm writing an assembler for it now. After that I'll design the other components (audio, video, etc) one by one.

If you are using cartridges and not discs, you can simply tie some of the device's address lines to the address lines of the cartridge. When the processor resets, it can simply read its code from the cartridge with no loading or anything. This does leave everything up to the developer though... they will have to deal with getting the device out of reset, setting up all the controllers and so on, initialising the screen, etc.

On the other hand, for a disc-based system, you will definitely need a BIOS to be able to load the initial code into memory. And if you already have a BIOS, you might as well make it have handy functions for the developer as well.

I am personally fond of making a cartridge-based system with a standard library that all developers can use (they can also choose not to use it, of course)... but it's up to you, not me.

try http://atanua.org

you will soon discover designing a CPU at the software level is a much easier task than at the hardware level...

@hckr83: That program's cool! Thanks for the link. I used a similar program called Logisim to build a 4-bit ALU but it had no where near as many features.

The assembler is around half complete I should say. What it yet does not do:
- Labels don't yet work (working on that tonight).
- You can't reserve data in the binary file.
- Preprocessor (#include, #define, etc) - lowest on my priority

MessiahAndrw wrote:@hckr83: That program's cool! Thanks for the link. I used a similar program called Logisim to build a 4-bit ALU but it had no where near as many features.

The assembler is around half complete I should say. What it yet does not do:
- Labels don't yet work (working on that tonight).
- You can't reserve data in the binary file.
- Preprocessor (#include, #define, etc) - lowest on my priority

Preprocessor stuff you don't need to write yourself! just run it through /usr/bin/cpp (the C preprocessor).

Why don't you modify binutils to output to your cpu? It really isn't as hard as you think. In a couple of hours, I had written a complete gas backend(including assembler and disassembler) that could output bytecode for my virtual machine. All you got to do is define some macros specifying endianness and such and then define some functions that deal with relocations and then write a callback function that parses the instruction. GAS takes care of labels, preprocessor stuff, comments, and everything else.

iammisc wrote:Why don't you modify binutils to output to your cpu?

That's a good idea. I don't have time to look through the source of binutils yet, but can give a rough explain of the steps involved?

I can't tell it for binutils, but I created a half-working m68k port for yasm once. If you keep the same style of instructions as intel's you just need to copy a bunch of code with a different opcode map. Otherwise that's the only piece of code you'll have to write

That's a good idea. I don't have time to look through the source of binutils yet, but can give a rough explain of the steps involved?

Sure. First you got to add some new cases to the autoconf script so that it can handle your new hardware. That way you can configure binutils by passing the --target option to configure. Then you need to create an architecture header file with some macros specifying the details of the architecture. Lastly you write some callback functions(less than 20). Most of the time you can use generic callbacks. When I wrote my backend for example, I simply copied code from cpus that shared similar characteristics with mine.

This document really details the process and if you want to do a port,I suggest you read it.

hckr83 wrote:try http://atanua.org

you will soon discover designing a CPU at the software level is a much easier task than at the hardware level...

Very nice!
Of course it is more easy to create a virtual CPU in a high level language like C/C++ then in a low level language like this graphically bit manipulator language.
But like many other programs of this kind it lacks the memory-chip to save programs and other data.

This seems to be the most useful resource I've found on porting GCC to a custom architecture so far:
http://www.le-hacker.org/hacks/projects ... piler.html

The relevant documentation of the files within the gcc/config/mycpu is found in the GCC Internals doc (which I'm currently working my way though it) at:
http://gcc.gnu.org/onlinedocs/gccint/

You don't need to port gcc unless you want C/C++ support. If you're going to write your stuff in assembler, then all you need is binutils. I would suggest first doing binutils because without that, gcc will only be able to output assembler, not actual machine code. Also porting gcc is infinitely more complex than binutils. A full gcc port might take about 3 weeks at least but a binutils port could be completed in a couple of days.

iammisc wrote:You don't need to port gcc unless you want C/C++ support.

That's my reason.

iammisc wrote:I would suggest first doing binutils because without that, gcc will only be able to output assembler, not actual machine code.

I already have my own assembler.

iammisc wrote:Also porting gcc is infinitely more complex than binutils. A full gcc port might take about 3 weeks

I have 3 weeks

MessiahAndrw wrote: I already have my own assembler.

GCC however, will only work with binutils.

iammisc wrote:GCC however, will only work with binutils.

In it's default configuration, however it is possible for GCC to just output to a different assembler. I've noticed there are a few macros in the target headers that their description says depends on the assembler/linker, brining me to the assumption you can use other assemblers/linkers. Also curiously, you can specify you don't have a linker (in which case the entire project is outputted at once). Another way is you can tell GCC to output the assembly code and manually invoke your own assembler.