Wednesday, July 30, 2008

Slow going....

You know C# is great and all, and you do code things faster, but the ground work reall does take some time to lay. I've found this at work as well where I use C# all the time, it just takes longer. When we started out current project it took us much longer than we thought it would to get the base application framework running. Of course once thats done you really do go quicker, and a few things are quicker right off the bat! I implemented a symbol table last night using my ISymbolTable interface, and using a few Dictionarys I was able to write it in about 15 minuets. In the past I've had to do a binary tree so I can do symbol lookups quickly, but Dictionarys in C# are very quick so I just dont have to worry about it.

I've also been slowly adding the basic 6502 dissassembler while at the same time trying to make it more C# than all the last versions. I've more or less just cut-and-pasted if from the old version (which is the same one I've been using since Minus4 DOS days!), so I want to make it a little prettier.

I decided a little while back that I just dont want to use C/C++ anymore unless i really have to, as C# and managed code is just so much nicer. I'm stuck with things like SNASM and Minus4 of course because they are pretty old and would be a major task to rewrite, and thats not something I want to do just now.

Anyways..... I'm slowly laying all the groundwork and I'm almost ready to start dissassembling stuff to the screen. Once I have that then steppng code will be the next big thing, but that appears to be a long way off for now. I'm actually looking forward to adding support for this to minus4 since while the debugger in Minus4 is actually one of the best in emulators, its still pretty poor. Also, once I have the module to do tracing in Minus4, I'll release that and see if i can't get someone to implement it in VICE and YAPE which would make my day.

(I also secretly hope that I can do a PC Engine module and get it added to Magic Engine, and possibly do a proper remote debugger for the real hardware too - one day!)

8 comments:

Anonymous said...

But isn't C# Microsoft/Windows only. That's a bit sad :(

Mike said...

No no, .NET is an open standard and theres a multiplatform version called MONO which will run on most platforms.

Whats more, it can run the built executable without the need to recompile, so running on a MAC (for example) should simply be a case of running mono with the supplied files.

http://www.mono-project.com/Main_Page

nate said...

mike, I like python or ruby for most new apps I write. For the gui, I use wxWidgets or QT4. You get cross-platform and even faster coding that C# or Java since you get dynamic typing and no compile cycle.

Mike said...

I hate python; any language where white space is important is stupid! I havent used Ruby, but it looked okay. They're both .NET langauges and you can code them about the same speed I guess.

I dont like QT or anything like that, and the winforms stuff in C# is dead easy - particually what I need it for.

Sandro said...

Not all .NET programs run in Mono. I have looked at Ruby and it looks nice. I have never used Python. Why don't you code in Java? Not much different from C# and fully cross platform.

Sandro said...

BTW, is there a version of Snasm for Linux? thx

Mike said...

Mono is getting better all the time, and we use it a lot at work so Im pretty confident that if it doesn't work now, it will real soon. I beleive it now does basic windows forms (which is all I'm using) so it should have no problems with it. When I'm ready to release it I will test with mono and see what extra needs to be done to support it.

Man.... I can't even begin to tell you all the problems with Java! I've used it a fair bit in the past, but lets just say that while technically its similar, thats about all. It sucks - bigtime.

No, I dont have SNASM on Linux... perhaps one day, but not yet.

Tomaitheous said...

"I also secretly hope that I can do a PC Engine module and get it added to Magic Engine"

Or mednafen. It already has a full PCE/CD debugger. Plus, ME is pretty inaccurate with timings and opcode cycle times. Great for games, not so much for dev.