Thursday 29 December 2011

Google Code Repository Online

I've just constructed a Google Code repository for any source code I produce. You can find it here.
My initial 6502 Emulator (very unfinished) is there - but overall - this is just my first experiment on how I even integrate Google code hosting with Visual Studio and subversion.

So far, I'm using AnkhSVN as my subversion plugin to Visual Studio 2010. For a free product, it's working quite well. :)

Monday 26 December 2011

Development Plan and Custom 6502 Emulator

I'm starting to get some good ideas on what exactly I'll be seeking to build. A quick development plan (component view) has been added to my Blog Pages. You can take a look at this here.

And in further thinking about how to write a debugger for a C64 emulator - I realised that it's going to be very tough building a Debug Engine (DE) in Visual Studio against a system (say CCS64 or WinVice) that I don't know a lot about (yet!). So for this reason, I've started to build a 6502 emulator in .NET and will attempt to create my first DE against that. My reasoning is that if I have a really simple "engine" - and I wrote it, then I can begin to appreciate what it will take to build a fully fledged DE. The documentation and walk-throughs on the web for debug engine development is next to non-existent! I need every advantage I can muster.

 And besides, so far writing the 6502 emulator (supported by what's shaping up to be a C64 platform that it sits on) has been really cool.

I've also started a new Blog Page on that endeavour (Writing a 6502 emulator in .NET).

Thursday 22 December 2011

Plenty of tools already... Anything left to do?

Well as I continue to look around the interwebs, it's clear that there's lots of interest in retro coding - and particularly in the development of the just the kind of tooling I'm talking about.

Two tools of note...
One is C64Studio written by Georg Rottensteiner. This guy has completely written his own IDE with sprite editor, char editor - and importantly, and interactive debugger that sits on top of a modded copy of ACME (cross-platform assembler) & WinVice... Pretty special I think, I'm very keen on seeing how this was all done... He tells me he will be happy to release the source in due course, which will certainly go a long way to seeing how emulators such as WinVice actually emit system state for reading and interpretation (I don't want to reinvent wheels!)

The other is the WUDSN IDE - it's a 6502 assembler plug-in for Eclipse, and targets the C64 and Atari among others. It has good syntax parsing and highlighting etc. - and clearly looks like a great way to plug-in and get started. 

So it's looks like I'm travelling a path not exactly well trodden, but certainly there are others doing some hard work in this space... Which is exciting :) The question now is - what am I going to do with Visual Studio? How am I going to make this work too?

Wednesday 14 December 2011

A short break - but my brain can never stop



Heading up north to the Gold Coast, Queensland for a week in the sun. After a pretty tough year (I do internet banking security at a major Australian Bank), I'm really looking forward to it :)

Prior to packing though, last night I had a really quick look at the Visual Studio 2010 Extensions SDK and woah!, it's pretty complex.

I'm looking at how VS2010 can be extended and what features I'd like to see.

I'm thinking, a "Retro" project type that sets up an initial assembly file, establishes the correct makefile for hooking onto an assembler, code editors (an inbuilt custom 6510/6502 colour coded view), and debugger...

Now I know that some people have already modded VS colour coding to work with .asm files etc. But I want to have a specific filetype that has customised tab stops and precise formatting and knowledge of how a .asm file is put together. Fast and intuitive editing is the key.

Most of the above should be OK I guess, but that last one... A debugger? Mmmmm lots of work, but you see, that's what I'm interested in from a coding point of view... the full "developer experience" thing... Plus I've always wanted to know how debugging works. What better way to find out than to write one of your own. :)

Happy holidays! :)

Others are doing it too...

OK - so looking around the interwebs shows me that a few others have got something going between Visual Studio, their assembler of choice, and WinVice.

This is good! It means I'll have a good perspective on what currently works and how to, hopefully, make it better.

A good discussion on this can be found over at noname64.org here. This discussion happened a couple of years ago - but there's not a whole lot else I could find on the subject. I'll be sure to add to the comments if I see any similar links.

So the task for me now... set up a dev environment as others have done and see what can be improved on or changed. Now another thing that has come very obvious to me as I research this - is that I don't actually know what is a good set up for developing for the C64 is right now!! :) A bit of a case of putting the cart before the horse, I know... but what can I say? I'm ready to charge right in and get something going...

So maybe then, I should also find out how to construct a development environment in the typical manner:

Editor -> Assembler -> Emulator -> Real 64 (well I think that's how it works anyway! :)

I've created a new page: Setting up a C64 development environment - which I will construct over the coming weeks... Sure, everyone does it different, but there's a generic view that I'm sure I can define.

Until next time...

Tuesday 13 December 2011

Coding for the 64 with Visual Studio


Hello everyone, and welcome to my new blog.

Today I ask the question: Can modern tooling be purposed in such a way to make coding for retro platforms easy?

Now I know many retro coders already have their full on setups - they code in assem, use modern cross platform assemblers, test against emulators like VICE etc, then can auto push code to a real 64 and debug within seconds...

Sounds great. But pulling all this together sounds tough. It takes time. These people are elite - and I hold them in high regard for their dedication to the platform. Their abilities are a testimony to the time and effort they have all put in to their craft.

But for me - I'm a modern coder with a 40 year old head on my shoulders. I code in things like Visual Studio 2010 - but my memories go back to when I was a young boy coding 8-bit...

For me, it's not about authoring cool retro 64 games. It's about that simple question I posed earlier. I want to try something silly. I want to code for the Commodore 64 using Visual Studio. I want an assembly editor with highlighting. I want a debugger/machine code monitor IN the VS application - connected to my c64 emulator.

Better yet, I want a .NET port of either frodo or VICE to be highly integrated into Visual Studio itself...

Why?

I mostly don't know. But I guess one thing is clear. Coding for older 8-bit platforms is mostly a lost art. To be honest, I've forgotten how to code assembly. I can't remember the fine details of the c64 memory map - because I was never really a great coder when I was younger anyway. But I want to change that. I want to become good now! And to do that, I really want to see modern tooling target older platforms because it makes them re-discoverable. Back in your face. Younger coders don't know 8-bit at all, but modern computing is still founded on the basic principles that underscore these platforms of old.  

Let me know what you think! Leave a comment below if you've got any views on this. Am I mad? Can it be done? What would be your perfect development set-up?