Possibly writing an emulator... of sorts

dav7 · 2008-12-18 15:08:32

[ To achieve a more widespread response, this post has been duplicated at 68kmla.org. ]

As a sort of toy to play with in recognition of old technology, I want to try my hand at writing a kind of emulator similar to an old Macintosh, except using simpler principles.

I want a fixed amount of video memory for a 320x200 or 512x384 (not sure which) 1-bit (b&w) display, and basic keyboard and mouse support. Nothing else.

From there, I want simple routines to be able to detect where the mouse cursor is and/or if the keyboard is being used, and from there flick bits on and off in the video array to form pictures.

I want this emulator to run between 500kHz and about 5MHz - that should get everyone doing some serious optimization although I would of course let the emulator run at full host speed for testing/developmental purposes.

If all works well, I hope to build up enough awesomeness to get a basic GUI running, although nothing serious.

There's just a small issue: I'm not too sure how to do this. Of course, for this to be remotely authentic, I'd make a real CPU and an assembly language for it, but that's a bit (very large bit) over my head (although if I did that I could load the language onto an FPGA... ) so I was considering somehow using C and abusing dynamic libraries to get myself a "binary" file format.

The other issues are the CPU - how do I execute code at a set speed? - and mouse/keyboard event reporting. I have no idea how to do that, except for using interrupts, which is obviously out. And the screen is another issue - how do I refresh my "video memory"? At the end of each "CPU iteration" do I just run through the video memory area armed with (since I plan to use Xlib) XSetForeground() and XDrawPoint()?

So... input? suggestions? Thanks.

-dav7

Last edited by dav7 (2008-12-18 17:00:31)

LiteHacker · 2008-12-21 22:54:46

I would like to clear up a few things about your project.

An emulator is a program that takes a binary file (filled with compiled assembly instructions) and makes a virtual environment for the binary file. Basically it takes the role of the CPU. An example of an emulator is Bochs.. it takes a binary file (usually an image of file system with an Operating System) and emulates a CPU type of environment. In this case, you would be able to set the speed of execution.

From what I understand, you do not want to do this, because of all the work required in basically reading through all of the instructions of the binary file.

What you are thinking about is a simulator. It is a fake version of the OS, running as a program with (hopefully) most of the same functionality of the original Mac OS. In this case, you cannot regulate the CPU speed, as your program is running directly on Linux (or whatever you have).

....if you are still interested in building something like that, I suggest you learn how to produce graphics on Linux (or whatever OS you want to produce it in).... to jump start your venture, I suggest you look into using the XLib library in C. ....note that doing so is not a simple task.... doing anything graphical in Linux is not your simple "Hello World" ...even though you may find a relatively simple "Hello World" code for graphical program. You may alternatively try using GTK or QT libraries, but I assume you won't get too much further with them.

Intrepid · 2008-12-31 17:00:11

While not as fast as Xlib, you can always use SDL. It is relatively simple once you have your routines (putpixel, line routines, window-drawing routines) written. Maybe using the framebuffer is what you want? (directfb). SDL provides the "screen" per se, all you have to do is output to it and receive input. Highly recommended if you do not want to use the more terse Xlib. Some emulators run in SDL very successfully (see dgen-sdl).

How to execute code at a set speed? What you need is a "frame" or "emulation" limiter. In SDL, it is very simple. A "tick" is a certain set duration in time (I forget how much it was). Basically, if the code is running to fast, you can slow it to a set speed like this (in Pascal):

repeat    <-- This is the emulator loop
    ticks:=SDL_GetTicks;   <--this is the current time (must be at least longint)
    allyoursubroutinesgohere;  <--nuff said.
    SDL_PumpEvents;  <--claim that input is already processed and move on to next instruction.
    difftick:=50-(SDL_GetTicks-ticks);  //if less than 50 ticks have passed
    ticks:=round(difftick);      //then wait until it passes.
    if (difftick) > 0 then begin SDL_Delay(ticks); end;  //if less than that much has passed, don't delay the code at all!
until (keys[SDLK_Escape]=1);

You can control that by modifying the value of ticks (in this case, 50). This should be mostly the same as C code. For finer control, look to others' examples.

Last edited by Intrepid (2008-12-31 17:09:49)

Arch Linux

#1 2008-12-18 15:08:32

Possibly writing an emulator... of sorts

#2 2008-12-21 22:54:46

Re: Possibly writing an emulator... of sorts

#3 2008-12-31 17:00:11

Re: Possibly writing an emulator... of sorts

Board footer