SMS Emu in borland delphi 7?

Lefteris_D

Administrator
Staff member
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.
 

NaXeM

New member
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.
 
J

Jet Set Willy

Guest
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.
 

NaXeM

New member
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.
 
J

Jet Set Willy

Guest
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.
 

NaXeM

New member
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 :)
 
B

Black68Cougar

Guest
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!
 
J

Jet Set Willy

Guest
A Z80 emulator is certainly a simple thing - if you can read technical documentation well enough. But Delphi? Why?
 
B

Black68Cougar

Guest
Because ... C++ is too ... and JAVA is too ... , and well because he wants to.
 

Dead Zed

New member
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.
 
J

Jet Set Willy

Guest
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

New member
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.
 
J

Jet Set Willy

Guest
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.
 
J

Jet Set Willy

Guest
I'm jealous that you live in Sweden. I want to live in Sweden. Let me live in Sweden.
 

Dead Zed

New member
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.
 
J

Jet Set Willy

Guest
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

New member
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
Assembler
Code:
add C,B 

X clockcycles

C
Code:
C = B+C

C translated to Assembler
Code:
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.
 
J

Jet Set Willy

Guest
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).
 
Top