Friday, October 24, 2008

Past tools.

I've just my old SNES framework source, so if I get a chance I'll clean it up and release it. Not sure who its of use to but its always fun to look at others code so... It does have a nice squareroot function in it, so you could always steal that. Its also (of course) 65816 based, so C64 SuperCPU users could steal more from it. If its of immediate interest let me know and I'll try and do it sooner....

Speaking of SNES.... I found this video on youtube ( YouTubes great! ) of the end sequence to Lemmings II. I had pretty good fun doing this. Theres actually a single pixel on the front end screen that if you click it, you get to the end sequence without playing the whole game - see if you can find it. ;-)


lint said...

Hey, I guess many people would like to see a SNES framework. You knwo there is still a small amout of homebrew coders on the SNES. I'm also looking forward for your SNES debug stub, using magicom or anything else ...

KungFuFurby said...

Hmm... do you remember who was on the Whodunnit screen for Uniracers? You got me curious... ^_^

Anonymous said...

Hey there.

I second lint, I would also love to
see that framework. I am personally
also still playing around with snes
(when time and wife allows) so that
would be very nice :D

thanks a bunch in advance..


Mike said...

You can see tghe Uniracers whodunnit screen here:

Anonymous said...

hey make..

ever used your SNasm for SNES stuff?
I'd be interested in either the sources
or a compiled linux binary ;) There are
some assemblers available to choose from
but I'm not all that happy with either
of them..

Mike said...

Well, part of the reason for doing 65816 support was to allow SCPU ANDSNES coding. My long term aim is to port XeO3 to each generation... so Amiga/ST, SNES/Megadrive, PS1, PS2 etc. I suspect I'll get bored with it way before then... but thats the aim.

I've always wanted to use the SNES for a game it likes. Doing Lemmings was horrible coz it doesn't suit the hardware at all.. XeO3 could be pretty cool, and easy!

I've been thinking more about Linux actually... And I always hate installing it. But I think the best thing now would be to use a VMWare image, then I dont kill my windows machine, its just a file I could use now and then! I suspect I'll look at mono soon, and I could port SNasm over to that...

Anonymous said...

Well what language is SNasm written in?
C/C++ ? Pascal? (*shrug*) ? :)

Also.. I still want to see that SNES
framework stuff u've mentioned!! :D


Mike said...

Its in C++, but if I port it into C# (it can take almost C++ code so its pretty easy to port), then the exact same compiled code will work on Linux and the Mac, so I prefer that. Not to mention I can start to make it a TRUE C# app, which makes LOTS of things simpler...

Yep, I intend to make sure it compiles with my SNasm assembler before releasing it, but I'm almost there with my reinstall (although can't find drivers for vista and myt dual parallel port card...bugger).

Anonymous said...

C++ .. well as long as you don't use
some weirdo windows.h or whatever then
there should be no problem just compiling
it for OSX/Linux/FreeBSD/... ? :)

Of course there sometimes are some differences in the way msvc and gcc handle
things but overall that is no big deal
to fix. Should be much, much less work
than porting the thing to c# for sure.


PS: Wanna see what one can do with the
C64 if you know it inside out? Then
check this one out:

pretty awesome for a crappy old 8bit
puter :)

Mike said...

I've obviously done lots of multi-platform C/C++ before, however with .NET I can use the exact same binary as all the other platforms. This means I only have to build ONE release, and everyone can use it! .NET is awesome :)

Thats a pretty amazing demo! I've been looking at the full screen zooming in particualr as its a great affect to use in a golf game (or something...) I'm fairly sure I know how it works, but I'd love to see some source. I wish demo coders would release sources... its not like they're gonna make money from it...

Anonymous said...

Well actually I'd be careful about .net
as it is proprietary Microsoft thing
so your mileage on different platforms might vary to say the least.

The only way to run .net apps on
non-windows platforms is through mono.
I'm not so sure about how portable
c#/.net code really is given that mono
is pretty much .net RE'd.

Sure.. if you went for C++ you'd have
to compile binaries for each platform
("each platform" .. well.. it's really
just Windows/Linux/OSX usually). But
then you also have the guarantee that
the binaries actually work as expected

Or you could of course just provide
the source code and be done with it.
Everyone who wants to use an assembler
should be able to compile it I suppose.

Just some thoughts..


PS: do you ever hang out on irc ?
freenode/efnet/ircnet ? i'm usually
around as "gilligan-" .. gimmie a
*ping* if you happen to see me around.
Would be nice to chat a bit.

Mike said...

Not at all! .NET CLR is an open standard, and although Microsoft lead it novel (I think who own mono) have invested lots of time and money into making it a true open source solution. We use it at work and its very cool As long as you don't use the very latest features (and I won't be for this stuff), then your fine.

Doing multi-platform builds are very annoying, and I've spent years hating it. So given the chance for folk to use exactly the same binary - I will!

While I provide source to my emulators, I don't to my assembler. Many components of it are used by me for other things, some of which are comercial so I won't release it. To be honest, even if I rewrote it, I only release source once Im done with it.

I also HATE having to build stuff myself, puts me right off it... I know having to install mono might be the same, but if I swap to C#, I also get to use some nice C# code - I really hate C++ now :)

Anonymous said...

well as for C++ .. I have to admit
that right now I am happy to work
with pure C. Working on Atmel AVR
stuff / firmware programming in my job.

Then again if I was to choose between
C++ and Java i'd still go for C++ - no
doubt. Just don't like Java. For one
thing I wholeheartedly hate the conception
of forced Exception handling. Furthermore
I hate the fact that there is no operator
overloading. Don't get me wrong though,
C++ is seriously flawed in various

Oh by the way.. as you also mentioned
PC-Engine stuff on your blog .. have
you seen the flashcarts from tototek? - not exactly
cheap but I suppose right now that's
the best thing you can get.

Also.. what do you currently use to run
code on your SNES ? Some old backup
station I presume? I have a super wild
card dx2 (32mbit). While that sort of
works I still wish I had a solution
that is more aimed at programming and
less at playing copied games.

I'd love something that allows for
faster test-cycles, adds a communication
channel between snes and PC and ideally
also provides debugging features !!!

Another thing by the way.. Do you know ?
A forum on NES development, and there
is also one sub-forum about SNES stuff -
although that one doesn't have quite
as much traffic as the NES stuff.


Mike said...

Yeah, java sucks big time. I used it on my last job doing mobile phone games and hated it. C# is what java should have been. Code generation is superb and it has some really nice language features. I also love have a tiny compile cycle and not having to do header files!

That said you can still do unsafe code which means your back to C++ but without header files and thanks to the .NET fileformat, its not processor dependent. This means the same exe runs on 32bit, 64bit, mac, linux and so on. Very cool.

Yep, got one of those PC Engine things. I will try (at somepoint) to do a devkit for that. The PC Engine memory card format is just direct line outs, so that might make it easy to do new hardware if I need to.

As for SNES...well, I have 3 magicoms which I hope to use, but also have an old profesional SNASM devkit. I'll need to find an old pentium or something with an ISA slot, but it works fine last time I tried. I actually have a HEAP of them, but only one interface card! I also have a Megadrive SNASM kit, which also uses the same card.

Ideally I want to get some emulator writers to implement my debugstub then I can remote debug using my debugger and any old SNES/Megadrive/TG16 emulator. Then I only need to use a real machine everynow and then.

Thats the plan...

KungFuFurby said...

I have no idea who are the people on the Whodunnit screen for Uniracers... do you know what each person on that screen did? Perhaps you know who did the music for Uniracers?

Anonymous said...

hey mike..

if you indeed have a heap of those
devkits.. i'd be very interested
in getting one of em.. maybe u'd like
to trade one for something or so? :)
feel free to drop me a mail at ;)

As for the debugging the only emulator
that has a somewhat acceptable debugger
built-in is ZSNES. Still I'd obviously
much rather do in-system debugging
on the real thing.

I think there would be several ways
how one could achieve debugging with
self-built hardware but I know *nothing*
about electronics.. For breakpoints
one could use something like the logic
in an action-replay cards.. There is
a little thread at about creating
a snes flashcart.. but it didn't
create that much echo really..


Mike said...

The problem is, I have a load of boxes and only one interface card. This means its usless without it. Its a custom SCSI card so you can't even go and buy something "like" it.

Well, the idea is that my debugger will be used for proper cross development AND emulators giving a lot more features than emulator writers usually do, and it'll mean it feels the same as working on a real machine. For normal developing working with an emulator is obviously much quicker so I hope lots of them will adopt this debugger.

If you read back through my blog you'll find out what I plan. Its currently got tracing, breakpoints and a watch window with full expressions. This allows some really cool things that emu debuggers just can't provide.

I'm pretty confident that mine will (eventually) be much better than all the rest, but will also work with 6502, 65c02, 65816, Z80, 68000 and all the rest. It'll mean you can use the same debugger on any project and always have access to some powerful features.

Anyway.... read back through my blog for more info. (I should really tag things like this...)

Anonymous said...

yeah I know.. without the custom
card you obviouly can't do all that
much with it.. But I have to admit
it's the silly collector soul in me
that despite this fact feels a slight
desire to own one of those anyhow hehe..

And yes.. tagging would be nice. I'm
actually reading back through your
blog right now. As you can tell by
the amount of my posts I quite like
reading your blog ;) Keep it up.

I'll look out for details on these
debugging plans. As sources for snes9x
and zsnes are available it would
certainly be possible to add custom
features to support your stub.

Actually I suppose it would also be
possible to use it in combination with
a snes&backup-station. I can send
data over the parallel-port of my
backup station but the overhead for
this is a bit annoying. Furthermore
(even though not that grave) the
code has to be executed from RAM as
the copier needs to be switched to BIOS
mode - Meaning the copier code is
mapped in the ROM space..

I also have a joypad-serial-port cable
but never quite got the timing to work