View Full Version : SMS Emu in borland delphi 7?

August 16th, 2004, 12:13
i want to make a sega master system emulator with delphi 7 but dunno where to start any help?

August 16th, 2004, 21:39
Try finding some documentation about the system at first and start by emulating basic processor functions. The next steps and how you will follow them are up to you.

August 17th, 2004, 00:42
yeh i got few hints and tech specs from a sms dev forum it sounds a bit much for me lol. But i got no project ideas it really sux.

Jet Set Willy
August 18th, 2004, 20:57
If you don't understand the tech specs, you are nowhere near experienced enough to make an emulator. Learn hardware, assembler, and low-level hardware. A lot of people emulate a Z80-based system on their first attempt, as there is a lot of documentation and pre-made cores in C. Also: Delphi? Learn C. It's not much different to pascal in anything more than type and form.

August 18th, 2004, 23:29
ummmthere is quite a large difference one being deplhi is very much like vb very fast development time but it's a real language unlike vb.

I don't have to code GUI's in WinAPI or handle window's messages delphi does it for me unless i want to.

Jet Set Willy
August 20th, 2004, 12:27
Uhm, good for you, but you do realise that Delphi programming requires more than drag-and-drop interface creation, don't you? You're trying to create an EM-U-LA-TOR. You're going to need to be programming in the Object Pascal language Delphi provides you with.

I think you're blatantly incapable of this. That's not an insult - I just suggest that you focus your time in a more worthwhile project.

August 20th, 2004, 23:39
lol im not dumb enough to call myself a pro or anything but yes i am familiar with the language itself not just the Visual Designer. But still this emulation stuff sound's like a fairly difficult task even with the know how. Im not uber leet or anything but i can understand how difficult it is or atleast in part and i think ill leave it alone lol.

I know a few languages (Python (ewww) VB, C,C++ ) But delphi and the object pascal language happens to be my fav :)

October 6th, 2004, 20:37
A processor Emulator is a ralativley easy thing - it is essentually a BIG case statement on the opcode and a little routine to manipulate the "registers" for each instruction.

You can get fancy and make objects for the registers, memory, and IO ports such that screen updates and manual changes to values are buried inside the objects - or not.

Then you can create objects that represent each IO device and register each with the IO object for a set of IO port addresses.

If you are still interested in doing this, I can help - I think I've written a Z80 simulator a half a dozen times - not Delphi yet - but I've written a few others in Delphi - could be fun!

Jet Set Willy
October 6th, 2004, 21:51
A Z80 emulator is certainly a simple thing - if you can read technical documentation well enough. But Delphi? Why?

October 7th, 2004, 23:57
Because ... C++ is too ... and JAVA is too ... , and well because he wants to.

Dead Zed
November 24th, 2004, 11:22
Go with the language you know best, I reckon. Delphi may not be the best suited language for an emulator. Assembler would probably be the best but if you don't have the slightest clue of it, you naturally won't be able to use that potential.Just know the language good enough and you should be able to workaround most of the probs you wouldn't encounter with the better suited languages like Assembler.

Jet Set Willy
November 24th, 2004, 13:40
In what way would assembler be "best"?

Assembler is hard to write. Assembler is hard to maintain. You can't write cross-platform assembler. "Assembler is best" is what people say when they want to sound hardcore.

C is much more suitable. Instructions in C translate directly to machine code, in a roundabout sense. Where you really need the tightest possible optimisations, you can call ASM from C, or link to a module written in ASM.

Emulators aren't a low level programming task. ASM is barely suitable in most cases.

Dead Zed
November 24th, 2004, 14:14
Using assembler you can do everything the higher-level languages can, with less overhead work = less speed issues. (Though it's a minimal boost in most cases) This makes it ideal, almost required, for the time-critical parts of the emulation, like you said about C with linked in ASM-libs. Doing it all in ASM would be easier to maintain, IMHO.I also disagree with Assembler being hard to write, but thats just me.

Jet Set Willy
November 24th, 2004, 14:27
I've seen this so many times before, and it's not particularly hard to debunk so I won't bother going into too much depth arguing with you. I will ask you to back up your statements by

1) Showing me some assembler code that I couldn't write in C and produce a computationally identical program
2) Showing me a portable ASM "hello world" program
3) Showing an example of how ASM is easier to maintain.

The only use I can think of for ASM in an emulator is for MMX-style optimisations, and dynamic recompilation - and still the second part could probably be done more easily in C (most examples I've seen focus on use strings of machine code algorithmically spliced together), and even with the inline ASM/ASM modules for things like MMX, the project would still be 99% C.

I think deep down you know I'm right. I can see the attraction of writing an emulator in assembler, but that attraction is purely geeky interest, and not practicality.

Jet Set Willy
November 24th, 2004, 14:29
I'm jealous that you live in Sweden. I want to live in Sweden. Let me live in Sweden.

Dead Zed
November 24th, 2004, 14:46
Why? it's like winter all year round here... Hey! You're just trying to confuse me aren't you? :blink:
And how'd you know I live in Sweden??

Meanwhile, back on topic:

1)Wasn't saying that; was saying that Assembler does it with less overhead = slight speed boost.
2) Alright.. I yield.You are correct. (Though Crasm was compatible on 6800, 6801, 6803, 65C02, and Z80 when they were the rage)
3)Once again, wasn't saying that. Was saying that it's easier to maintain a program written 100% in ONE language, rather than several.(Only assembler/Only C) Like a project I had once in Blitz Basic: Most of the code was BB, but for some of it needed to use C-libs, and some of what the C-libs were doing was timecritical, so ASM was used. That project was a bitch and eventually abandoned.

Jet Set Willy
November 24th, 2004, 14:55
I really do like Sweden, and many of its surrounding countries. I knew you lived there because of your web page. I like cold weather. England isn't quite cold enough for me yet. Maybe when those pesky polar ice caps melt...

I'd say that in most cases, a straight C program will often turn out faster than hand-written assembler. Compilers easily know how to churn out instructions for things like "a+b" using all of the known ASM tricks. I'd say ASM is only faster when the compiler is doing something wrong and you need to explicitally do it the other way (inlining a function, for example). A C compiler also has the advantage over written ASM in that it can analyse a block of code, recursively, very quickly. Human written instructions just can't compete with that.

I'm not sure that a project written in C with a bit of inline code would be more difficult to maintain than an entire project in ASM, but that is approaching personal preference territory.

Dead Zed
November 24th, 2004, 15:12
When the polar ice caps melt England will shrink to half its size and every swede but the laplanders will drown. :(
So I kinda appreciate em. :)

I am not 100% sure on the following, so bare with me.

C + B

add C,B

X clockcycles


C = B+C

C translated to Assembler

B = [0x545454]
C = [0x5A5A5A]
add [0x545454],[0x5A5A5A]
mov [0x5A5A5A],[0x545454]

X+Y clockcycles

If Im terribly wrong here, I blame my lack of intimate compiler knowledge.And even if Im right, this is just picking nits.

Jet Set Willy
November 24th, 2004, 15:37
It depends if by C and B we mean declared variables or just two numbers. In which case, the compiler will produce equivalent code to assembler each way. (You can verify this by having the C compiler output ASM files rather than object files).