Architecture for video-game system

[JamesM]

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.

Hur hur hur - nonstandard behaviour? GCC? All I can say is... Good luck!

[AndrewAPrice]

I've got the CPU emulator about 70% done. However I still haven't finished the video/audio specification so I haven't started any emulation on that. Porting the compiler is also currently in process but I'm waiting for the emulator to be complete CPU-wise.

Anyway, as far as cartridge formats go, what file system do you recommend I use, what executable format, entry point, etc?

The BIOS (which is loaded in to address 0) will search the file system on the cartridge for a specific file (like a main.exe) and load it into memory at 1MB. Maybe do some funky JIT, have the start-up executable's name embedded into the file system, etc.

I was thinking of using SFS as the file system. Though http://bcos.hopto.org/sfs.html appears to be down.

[Combuster]

I was thinking of using SFS as the file system. Though http://bcos.hopto.org/sfs.html appears to be down.

Link in my sig, for a while now

[AndrewAPrice]

It's been a while since I've posted an update. This is what I've done so far;
- CPU spec is finished and is fully emulated (may have some issues with interrupts since I haven't tested it yet).
- Graphics chip spec is finished and is fully emulated!
- Input controllers and chip specs are finished though not emulated.
- Debug controller (used like you do a serial cable debugger) spec is finished and fully emulated!
- Low level assembler is finished.
- High level assembler is at a workable level (functions work! - not much else). I've also started a HLA library which wraps all emulated low level hardware stuff in friendly functions.

All tools are written in portable C++ EXCEPT for the emulator front end (the GUI is done in C#) and one file in the emulator backend (win32 specific stuff for creating/destroying/updating the OpenGL window).

I still have to finish audio, storage, timer, emulating input, improve the HLA, and probably a few other things I forget right now. Oh, and make a few sample games.

My college has allowed me to take it up as my independent study, so I'm being graded on this.



Take a look at the screenshot above if you can. In the top left you can see the OpenGL window titled "Messiahtron Video Output" which is the emulated graphics display (runs in either 640x480 or 1280x720). I'm probably going to use how it says "MESSIAHTRON" as my BIOS boot logo. The top right window titled "Messiahtron Emulator" is the front end for loading ROMS, pausing the emulator, etc. All the way to the right is an example of what my HLA looks like, and in the background is Visual Studio looking at my graphics emulation code.

[AndrewAPrice]

I have my first C program running on my console's funky architecture (using my own backend for VBCC).

stub.asm:

Code: Select all

mov z2 0x80000 ; set the stack to 512k
mov b30 _main
call b30 ; call main()
hlt ; halt the processor

lowlevel.h: (header that wraps low level hardware)

Code: Select all

#ifndef MESSIAHTRON_LOWLEVEL_H
#define MESSIAHTRON_LOWLEVEL_H

/* controller IDs */
#define DEBUG_CONTROLLER_ID 0
#define GRAPHICS_CONTROLLER_ID 1

/* IO */
volatile void io_portOut(unsigned int __reg("b10") port,
								unsigned int __reg("b9") data)
								= "\tout\tb10\tb9\n";
volatile void io_portOutSigned(unsigned int __reg("b10") port,
								int __reg("b9") data)
								= "\tout\tb10\tb9\n";
volatile void io_portOutFloat(unsigned int __reg("b10") port,
								float __reg("b9") data)
								= "\tout\tb10\tb9\n";
/* debug  controller*/
void debug_writeString(unsigned int numberOfChars, unsigned int address)
{
	io_portOut(DEBUG_CONTROLLER_ID, 1);
	io_portOut(DEBUG_CONTROLLER_ID, numberOfChars);
	io_portOut(DEBUG_CONTROLLER_ID, (unsigned int)address);
}

void debug_writeUnsigned(unsigned int integer)
{
	io_portOut(DEBUG_CONTROLLER_ID, 2);
	io_portOut(DEBUG_CONTROLLER_ID, integer);
}

void debug_writeSigned(int integer)
{
	io_portOut(DEBUG_CONTROLLER_ID, 3);
	io_portOutSigned(DEBUG_CONTROLLER_ID, integer);
}

void debug_writeFloat(float value)
{
	io_portOut(DEBUG_CONTROLLER_ID, 4);
	io_portOutFloat(DEBUG_CONTROLLER_ID, value);
}

main.c:

Code: Select all

#include "lowlevel.h"

static char *message = "hello";

int main()
{
	volatile int b = 10;
	volatile unsigned int c = 12;
	debug_writeUnsigned(1004);
	return 0;
}

[iammisc]

I have my first C program running on my console's funky architecture (using my own backend for VBCC).

Cool. I'm going to need to retarget a C compiler soon. Is VBCC easy to retarget?

[AndrewAPrice]

Pretty much..

Open up the "machines" directory, make a copy of the "generic" directory and name it whatever you call your architecture.
Type "make TARGET=<target-name>", then run dtgen (the syntax is something similar to "bin/dtgen machines/<target>/dt.md dt.c dt.h", but check the usage first) and answer a few questions about the types your architecture supports (unsigned char, signed long long, float, etc).

Then edit machines/<target>/machine.h and machines/<target>/machine.cpp. The z target is also a good reference.

For detailed info see chapter 13 here: http://sun.hasenbraten.de/vbcc/docs/vbcc.html

[babylon2233]

do you want to release your emulator to the public? I hope you do. And maybe with its SDK too.

[AndrewAPrice]

do you want to release your emulator to the public? I hope you do. And maybe with its SDK too.

That's my plan when it's finished in around a month I'm going to release all my technical documents too.

I've spent most of this week and last week working purely on the VBCC backend. I'm proud to say it's working, even though it is extremely inefficient (the same function in my HLA can equal around 5 lines of assembly, where as in C it equals around 50). I've even enabled full optimisations. One example is the VBCC feature that it can use registers for passing parameters, and I've enabled it. It uses registers for variables, but when it enters the function, it pushes them all on to the stack anyways. And each time a variable is used it is pulled from the stack, operated on, and pushed back. This is really inefficient since the operation to move something from stack<->register is 5 instructions (we're talking midway through the stack, not a simple pop/push).

I'd be really grateful is a person experienced in code generation could help me.

Anyway, now it's time to move on from compiler backend coding. I only have 3 and a little more weeks left and here's a list of stuff I still need to do:
- Finish emulating the input device
- Finish designing and emulating the audio device
- Finish emulating the storage device
- Make a few sample games (Pong, Tetris, Tron, Top-down racer)

The sample games are going to be really basic, although I'm thinking about including a test application showing off the fancy graphical chip.

EDIT: I feel like a fool. I've went through each compiler optimisation which could apply to me and enabled them. Now I'm generating around 9KB of assembly, instead of 110KB.

[babylon2233]

Great!. I would like to ask you one stupid question. If your console physically exists, is it a handheld console?

[AndrewAPrice]

Great!. I would like to ask you one stupid question. If your console physically exists, is it a handheld console?

I wasn't planning it to be, though I haven't implicitly stated in the design document. Nor have I designed the aesthetics of the console, the documents are purely technical.

If someone wants to build a hand held version then they're welcome to. Infact if someone build the console at all I'd be socked and honoured at the same time : .

[AndrewAPrice]

I'm going to have the emulator, specification, and toolchain complete and ready to release next week (in 7 or 8 days). There's no programming tutorials for it yet, and the emulator currently just works on Windows (the only non portable thing is the audio/graphics interface in the backend, the emulator front end is written in C# (which should work thanks to Mono)).

To write software for it, you have a choice between assembly, high level assembly, and C. The high level assembly is really just assembly with functions, and the HLA library, while it works, only has functions wrapped around the graphics controller because I abandoned it when I moved to C.

The C library is complete. I have a lowlevel.h header which is low level stuff (contains io port stuff, functions for registering input, wrapping around every hardware function). Also, I have a mathematics controller (that does sin/cos/sqrt/etc), and which means I have a hardware accelerated math.h. Probably the only other thing I'll add to the library is a memory allocator and some functions for accessing and loading resources (bitmaps/waves) from the file system on the storage device (which is a write-once file system for resources, although you can attach another file system at the end of the disk if you want).

[AndrewAPrice]

Okay, just a quick update before I go to bed. The storage device is fully emulated now, and I wrote a tool which turns a directory in to a cartridge image (a cartridge image is a raw dump of a simple write-once file system I made for another project (which was to do with embedding files in to the pixels of images)). I need to finish loading the code in the firmware so it can load the executable program from the cartridge.

I have a rather nice directory layout too

Then I can start writing some games! Since I don't have that long I'm thinking of doing a few basic games. Right now on my list is:
- Pong
- Tron
- Asteroids
- A simple top down racing game
- A demo program which shows of various features

I still have a few more emulator features to implement as well.

[AndrewAPrice]

The firmware loads an executable off a disk and starts executing it. I've got fed up with C since occasionally my backend emits the wrong type (e.g. it uses unsigned ints to compare 2 char values and my architecture treats them differently). But for non low-level stuff C should work fine.

So anyway, I'm coding my games in assembly since I don't have much time left and don't want to spend hours debugging my C backend anymore.

I've spent a lot of tonight working on parsing the file system and loading images in assembly.

Loading a 1,200kb raw image (640x480 * 8 bits per byte * 4 channels) takes around a minute when I'm copying 32-bit by 32-bit (I was using 3 channels but switched to 4 so they were aligned to 32 bits) . So in my hardware maths controllers (which also does a lot of helpful utility tasks) I'm going to add a single IO operation that causes it to do a hardware accelerated memcpy using DMA

[Stevo14]

This is a very intriguing project. I will be very interested in playing with it when it is released.

On the topic of portability of the emulator:

(the only non portable thing is the audio/graphics interface in the backend, the emulator front end is written in C# (which should work thanks to Mono))

If you're looking for a cross platform C# graphics and sound library for the backend I would recommend OpenTK. I might even be willing to add support for this backend if it turns out to be a relatively easy programming task.