Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

My Master Project... a virtual operating environment

This topic is 5092 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

As a summer project, I am going to try to create my own gaming system, or atleast an emulator for it. I''ve done assembly before, x86, and a little z80. I figure that doing this would be a great way to learn a little more, and use what I already know. here is how it would work. I would premap out the memory, and allocate enough for a decent sized program. the orginization would look something like this. [u]address, descritption:[/u] 00000000-000000FF: The stack 00000100-00000FFF: Registers 00001000-0000FFFF: Instruction Segment 00010000-000FFFFF: Video Memory ...: don''t know(misc device memory) 10000000-FFFFFFFF: Free Memory It would go something like that. It''s going to be a learning experience, thats all I can say. Perhaps I will write a console emulator after I get this working. who knows... anybody do anything like this? any advice? I don''t think this is too ambitous, just a little diferent from most peoples projects. wish me luck, atleast.

Share this post


Link to post
Share on other sites
Advertisement
After I got through laughing over a stack of 256 values, and 3840 registers (I know, ''something like...''), I wanted to recommend that you pick up the book, "Virtual Machine Design and Implementation in C/C++" by Bill Blunden.

Thanks for the laugh, and good luck with your project.

David

Share this post


Link to post
Share on other sites
The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.

As for 3000+ registers, well, that is creative licence :-)

Share this post


Link to post
Share on other sites
quote:
The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.


It is my day for learning things. Why would only having a 256 byte stack allocated by hardware affect the ability to write a compiler for it? Couldn't the compiler writer ignore the hardware stack and implement their own stack in regular memory of whatever size they wanted, and work their program around this stack? I believe that is what MS, Borland, and other compiler writers do, but maybe I am wrong.

David

[edited by - david oneil on June 8, 2004 11:22:32 PM]

Share this post


Link to post
Share on other sites
Here''s a riddle: After making your virtual computer on a computer, make a virtual computer on the virtual computer and then another virtual computer on that virtual computer, and finally a virtual computer on top of it all. Now how many virtual computers do you have?

Share this post


Link to post
Share on other sites
quote:
Original post by David ONeil
quote:
The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.


It is my day for learning things. Why would only having a 256 byte stack allocated by hardware affect the ability to write a compiler for it?
[edited by - david oneil on June 8, 2004 11:22:32 PM]


Hmm, it''s been ages since I programmed a 6502, it did not have segment registers like a 8086 so I think you could not allocate your own stack segment. I think the stack was something like the above author has, it was a fixed block of memory.

Languages like C and Pascal require a stack for function calls and recursion. 256 bytes is very limiting, even on a very limited machine. You could write a compiler for them but, they were so slow and small, nobody really programmed them in anything but assembler language anyways.

Share this post


Link to post
Share on other sites
MS, Borland, etc use the stack that the processor thinks of as a stack. Though you could get around it, it would be extra effort, a waste of a register, and ignoring any optimization Intel put into their chips for dealing with the stack. It would likely screw up prefetch and branch prediction

To "create your own stack" rather than using what the CPU thinks of as a stack would mean never using call, and ret, but manually emulating the behaviour, saving the current address, changing the stack pointer, jumping to a new location, changing the stack pointer back, reading the location, and jumping to it. Push and Pop would become complex, large macros.

On the 6502, yes there was a 256 byte stack, at $0100-$01FF. There was also only 3 8-bit registers. Creating your own stack isn''t feasible in that situation, and a 256 byte stack severely limits recursion, and local variable storage.

call, ret, push, pop (and other cpus sets of similar opcodes...jsr, rts, pha, pla, bsr, bcc, etc) all use an implied stack. With the x86 this is at SS:SP. With 680x0 it''s A7. You just need an SP (stack pointer) register which is a pointer to memory like any other addressing register, which is the implied memory used by stack based instructions.

Modern processors don''t have a specific memory area for stack. One of the registers is considered the stack pointer, and it''s just a pointer to somewhere in RAM. This lets you have any stack size you''d like, and since it''s location isn''t fixed, allows multithreading easily. With a fixed memory location stack you''d need to copy stacks around on every context switch, which isn''t a good idea. Just save the current registers somewhere, and load in the other threads registers, and voila, you''ve switched context.

Share this post


Link to post
Share on other sites
interesting point, with the multithreading and context switching. I am only trying to produce something about as powerfull as a gameboy or graphing calculator. It will have a fixed stack, as well as fixed free memory. One question though, how would you distinguish between memory adresses and literals? The best I could think of would be to have a seperate interupt for each instruction. sucky, but the best i could do.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!