RetroEdit cleanup

For the lack of any better ideas, I've been cleaning up retro edit into a more consistant state and I've now got the control editing the data in a native format. This means theres no real conversion required when lifting the data out an saving it off - or indeed loading data into it.

I still need to go through the application itself as I've changed my mind on several things. For example while its perfectly valid to allow you to edit HiRes and MultiColour more sprites together I'm not going to allow it. This means you dont have to run through a hundred sprites and switch them all to Hires or MCM, and in reality this would hardly ever happen anyway.

I can now draw a sprite okay so what I really need to do is add colour palette selection to let me pick which colour I want to paint with. Once I've done that I can add the features that make editing fun.

I'll need to extend the editing control to allow for character and bitmap mode because I want to use the same control to do all editing. That said, I'm still not sure what I'll be spending my time on over the Christmas break, but for now I'll carry on with this...

RetroEdit

I was looking through the source of retro edit and wondering what I'd do to change it, and came to the conclusion that actually, its not as bad as I thought. The only major change I want to do is how the data is stored internally. You see when I started this I decided to store the data in a basic INT[] array, where each 0 or 1 was actually a BIT, and I would then process the data for editing and drawing. However, this is a bit yucky, and I now think it would be better to just store the data in a more native format. Thats not to say I'll store it in boxes, or colums etc. but as a simple X by Y row of bytes. This makes plug-ins to save the data in a custom format easy.

So I think I might have a little play and see if I can reorginise things so they are more to my liking, and this will (I hope) then allow me to use the custom control to actually do real graphics work.

The way I've gone about this is to have a custom control that deals with retro graphics. So you load it up with the data (in a simple rowxcolum format, and you can then select colours and plot pixels. The idea is that once its released (if ever!) then you could use the control yourself outside of retro edit to do other things. I have no idea if this would ever happen, but it might.

So I've decided to give it a few days and see how I get on. If I feel like Im getting somewhere, I'll carry on - if not, I'll bin it.

SID tunes.

I discovered today that one of our musicians has discovered the SID chip. He got hold of a new synth that uses SID emulation (due to lack of SID chips) and has been making music with them. I find this amazing really, that folk are rediscovering older tech like SID chips and putting them to work making really. It's also funny when others comment that it’s all old hat and a waste of time that new comers find so much enjoyment in them that they buy dedicated units to play with. Stuart (Ross) said that while the SID is pretty harsh in its basic form, he loves the way the filters work and the sounds you can get with them - which is of course why oldies like me still love to listen to old SID tunes. While the sound is somewhat unique, at the heart of our favourites is a good tune and because of that, more musicians are re-discovering the wonders of the likes of SID/Synth style music. Great stuff.

Change of direction.

So with Christmas comming up it's almost time for my anual direction change. I was hoping that my ATmega devkit would arrive in time, but its looking less likely as time goes on - pooh. Oh well. I've pretty much completed what I wanted to do with Minus4j, although I'd like an option to pick a file fom the ZIP to switch to or load, but until Plus4world allows real access to ZIP files, this isn't that important. I'll probably wrap up what I've got into another release and leave it there for now, although I've yet to look at the sid filters but that may also be defered until later.

As to what project I'll do at Christmas time, well I'm not sure. I'd love to get back into electronics a little, but theres also my debugger and getting it running on a C64 and emulator. I'm also starting to think I need to restart RetroEdit. When I started it I hadn't done much C#, and over the years I've learnt how to do things properly. This means I could make a real stab at a proper system but as i've seen with the debugger, this means some serious effort. That said, I'd love a very simple interface so that I could draw tiles/graphics for myself.

I also really need to get a basic MAP editor togther even if its a very simple interface so that we can make levels for Xeo3. The old one works but is a little crude in paces - it would be nice to fix that.

So I have a few things I'd like to play with, I guess time will tell if I actually GET to...

Java, java everywhere and not a drop to drink.

So it turns out the ZIP file issue I was having is a bug, and SUN have now filed it. This is good as it means I'm not going mad! Someone from Sun got in touch and I was able to send them the offending file, so with any luck no one else will have to pull their hair out in frustration.

It's also good to know that it is indeed simple to read ZIPs, and I have been making steady progress now. I now have the ZIP being downloaded, and the first D64 being loaded and run. I really need to orginise the file processing better as it - well sucks. Its hacked in really badly and is sorely in need of a re-orginisation so that the normal rules about loading D64s and PRGs then apply to the contents of the ZIP. That said, I feel like I'm getting sucked further and further into emulator development again, and thats not something I want to do again (or at least, not right now).

This means I'll be hacking together a simple version and then I may update it later to allow better support and the zipping of everything.

I have also started using collections inside java (more to see what they're like than any real need), and while similar to C#, they just aren't as nice. C# has lots of little features like array access to them and handy functions like sorting all built in, where as its a little cruder in Java. Still, at least they're there...

It never rains but it pours..

So, I've figured out what was wrong...ready? The ZIP file. And I have no idea why. I unzipped it, then rezipped it, and it all works. Sugar. Does this mean I have to go and rezip every file on Plus4world? Who knows... But at least it appears to be working...kind of. I wonder if I could send the broken ZIP to sun and have them fix it, because I can only assume theres a bug in the JVM. I'll need to see if I can find an unzipping program that CAN'T unzip it, because if they all work then its definitelty broken in the java JVM.

I hate java, I hate java, I hate java, I hate java....etc..

So, back with Minus4j once more. I'm trying to get some ZIP support in here so that more files on Plus4world will work, but once moe=re I'm struggling to get Java to behave and do what its supposed to do. Opening a ZIP file in java is pretty is (supposedly) but will it work for me? Will it strawberry. All that should happen is I pass it an input stream and then read files, and while I appear to get no error, it also doesn't appear to actually read any file inside....Oh chocolate.

       BufferedInputStream bis = new BufferedInputStream(_stream, 16384);
       try 
       {
          ZipInputStream in = new ZipInputStream(bis);
          ZipEntry entry;
          while( (entry = in.getNextEntry())!=null )
          {
               // process the ZIP
          }
          in.close();
       }

So in the above code, it just never gets into the inner while loop and I've no idea why - so if you have any idea...let me know. I did think it was because it was coming over HTTP, so I read it all in and build a memory stream, but that doesn't seem to matter. On top of this, no one else seems to have this problem, so I can't find any answers on the net either..... *sigh*

PHP'ing

I've been reading through my PHP for dummies book and I'm actually having fun with it! Its very like C/C++/C# with only minor differences really, so I'm thinking of using the Plus4world database to try a few things out; read only mode of course, I;m not stupid! So what I think I'll try first is to see if I can make a "play online" page.

The reason for this is that i've spent quite a bit of time going through all the games and testing them out with the new Minus4j, and their working pretty well. But I'd like to get them all listed so I can see how many we have and get them all under one roof - as it were. It'll also (obviously) teach me more about PHP, and the more I know, the more I can help Csabo out on the site - or thats the plan.

I'm obviously no where near that stage yet, but I find that doing a real project helps focus what your doing and helps you learn. So here we go!

I took was also speaking to someone about multi monitor setups a while back and was saying that while I have 3 monitors at home, I actually have 4 at work! So I've taken a piccy of my development setup (I should really do a home one too - even though its a hell of a mess) for you all to mock. I've got a really old TFT for my main source monitor as it rotates and gives me more lines to read - which is cool. All those monitors are from one machine and gives a lovely big desktop, which means I have loads of programs open at once, So much so...I think I need more RAM - Vista being the power hog that it is. Good fun though!

Oh...and you'll notice I'm still a fan of the good old "clunky" keyboard - I had to look long and hard for a good "click" one! I hate these springy things.

SNOOOOOOOOOOOOOW!

We've got SNOOOOOOOOOOOOOOOOOOW!!! Good, proper, BIG snow! This is the view from the Realtime Worlds office, and its great!! I hope it hangs around for a while, but its getting quite bright and sunny just now..pooh.

I got on pretty well with Minus4j over the week end as I managed to get 1551 disk emulation in and working! This means that we should be able to get more games online at Plus4 world. However, I'll need to add ZIP support before we really get invloved in it as most disks on plus4 world actually have 2 sides and are packaged up. Still I think this should be okay, but I'll have to look at it later this week.

I've also got a couple of PHP books so that I can learn a little bit of PHP and help out a bit more on Plus4world; well, that and my DMA Site. It's in desprate need of re-vamping and I'd like to make the whole thing database driven. However, first things first - I need to learn PHP first! I'm looking forward to it I have to say!

I've also been reading through the Yape SID code to see if I can get something from it. The filter stuff is pretty complex and I need to figure out exactly what its doing before I can decided to use itor not.... I'm fairly optimisitc that I'll get something from it.

Vista x64 upload working!

I've managed to get the upload program working once more with the x64 driver, however I now need to press F8 whenever the machine is booting up so I can disable driver signing. Stupid stupid stupid vista! I wonder how much it costs to sign a driver. This is a VERY popular driver, so it may be possible for everyone to club together and pay for it.

There used to be a work around where you could just switch it off, but Microsoft in their infinite wisdom disabled it. Its thing like this which will drive folk to other operating systems. (Course... MAC doesn't HAVE a parallel port...)

I think one of the things on my to-do list should be a simple USB to parallel wire. Now I know there ARE some, but I'd love to have a proper one that acts EXACTLY like a parallel port and does all the crap for you. I imagine this would sell pretty well, particually if it could get signed properly. Oh well... another one to add to the list.

Still, for now its working and means I can now test Plus4 code again. The original uploader hasn't changed, but I now have a new DLL and SYS file that I use on VISTA.

So what else is new; well I've added basic SID support to Minus4j but its a bit pooh to say the least. The lack of filter support really sucks and since most music/fx uses them, they just dont sound right at all.Attila has kindly sent me the core of the SID emulator from YAPE and I'll see if I can wedge that in. It's very much like trying to put a square peg in a round whole though as YAPE and Minus4j are not only very different langauges, but have very different design philosophies. Still, its worth a go! With any luck I'll get it added and we can get some good sounds playing in demos.

Speaking of demos, I noticed that many appear to over run their rasters, and I think I've finally figured out why. I dont think Minus4j (or Minus4w) are letting them have a whole scanline. Basically the "newline" function is being called at the start/end of a scanline (HBLANK) but thats not where the timing is working from. The horizontal dot clock is being reset by the newline function and losing clock ticks. This means you dont get all your processing cycles, and would also be the cause of my inability to load tapes. Tape loading is in fact VERY easy (once you have a good sample), all you do is set a bit on/off as it plays, and at the right time. But if the CPU timing is out, it'll never work - explains a few things.

It may however be a nightmare to fix, so I'll have to look into it. It would be great to be able to load PRGs, D64s and TAPs into Minus4j, but I'll wait and see how everything else goes. I really really don't want to get sucked wasting all my time on emulators again...I have bigger fish to fry.

EDIT: Oh, and if anyone else does want to use the uploader on Vista64, then let me know and post a ZIP with the new drivers and installation instructions.

A sound idea and Vista kicking you when you're down.

I was fixing some sound issues with Minus4j last night, as I suddenly discovered it was actually pretty broken. If both channels went quite loud and high frequency, it all started to break up - samples too in point of fact. So I spent some time fixing this and its all much nicer, samples sound pretty clean and music in Commando and Monty on the Run are much much nicer.

This then lead me to look at D64 support. I was trying to load TerraNova and it started to work, then didn't. It gets stuck in some odd loop which i think is sample based, but I'm not sure, and I think I have my interrupt flagging wrong. Currently I flag them only when $FF0A is also set, but I believe this is wrong. I think you should always flag them, they just dont kick off an interrupt!

So i thought I'd do some test code on the real machine and see what happens. It was at this point I realised I haven't downloaded anything since I've upgraded (and I use that term losely) to Vista x64. Parallel port access requires a system driver, and under x64 all system drivers must be x64 based. This means my great little 32bit dll which gives me raw access to a parallel port under windows, now no longer works, which in turn means I can no longer download directly to the plus4 - OR carry on with my debugger. FEK!

So I've managed to find a 64bit version of the driver, but its just not working, and now I dont know if thats because the driver isn't working, isn't being found or simply because the parallel port on my machine is set up wrongly. FEK.

So tonight I hope to fix this and test out the interrupt registers a bit more. At the same time, I've started adding D64 support via the Commodore 1551 parallel port registers. This is why turbo loaders dont work on Minus4 as I assume its one of these devices. I used to just intercept calls to the LOAD command, but this is a little better. Anyway, I hope to get basic D64 support in soon although with all the disk turbo loaders around I'm not sure how much use it'll be.

As a little aside.. I was looking at the Minus4sim I started years back. This was a cycle perfect version of Minus4, but I got bored with emulation and mechanic was a little too messy for my likeing. However... C# has some really, REALLY cool constructs for pausing code mid execution, and i think if I ported it over to C#, it would all become VERY elegent and simple to follow. No longer would you have to hold partial states etc. You just pause and resume. So I may play with this at a later date as it would give some very simple code but yield some amazing results. It would also allow me to finally do a fully emulated 1541, which I've been meaning to do for years.

Still mustn't get too side tracked. I have to finish up with Minus4j, then the debugger, then back on to Xeo3.

Cool Electronics things....

So first a couple of links:-


http://www.belogic.com/uzebox/index.htm
http://www.ladyada.net/make/fuzebox/


Now whats this got to do with anything? Well have a look at these videos




Very cool indeed, more so because its not a particually expensive chip. So I was wondering what more you could do with it, and I've been having a look at some videos, and the specs. Now I've always used PIC Microchips, but I've noticed an increasing number of projects using these ATmega things and after looking at the datasheets, I can see why. The assembler is actually pretty nice! It looks normal! PIC stuff is okay, but I'm not a fan where as the ATmega has 32 registers, hardware multiplys, and most instructions take a single cycle! Now that IS interesting! Now have a look at this video....





This guy does various demos with it, and he gets some pretty cool results for such a small little device. So, I've ordered myself a little kit to playwith, and I might try hooking it up to a VGA monitor (I'm still struggling with PAL colour output, this phase shift stuff is a tad confusing). The other thing this little chip can do that PIC's simply can't, is address external RAM without having to do all the work yourself! Thats awesome! It means you could have megs of addressable SRAM (in the same way a Plus/4 could) without any speed loss, where as a PIC would really struggle as you have to set address lines, read and write data lines et..

What I would really like to try is making a GPU for a plus4. If I use dual port RAM, I could get the plus4 to write into the ATmegas ram, then get it to use it as a frame buffer and render things. This means you could switch the plus4's screen off (saving lots of CPU time), and then output the signal from the cartridge's ATmega chip. You could then add sprites, sound and all the rest without too much effort. if you really wanted to, you could have multiple chips each doing a different job - one for 10 channel SID emulation (or something), another for pure sample playback, and perhaps one to deal with chatacter maps, and another could add sprites etc... kinda like an arcade machine does.

Course...that won't happen. but i'd love to try and hook one up to a Plus4 and see what it would be like. Having already done a RAM expansion without opening up the plus4, I don't see why something like this couldn't be done - it'd be neat!

JAR files.

I've been having a little trouble getting resources inside JAR files working, I took some code from my mobile phone days and used it inside Minus4j without any luck. The idea being that I could package the ROM and WAVE files up in the JAR file, and so I wouldn't have to do a slow load over HTTP.

I've now managed to get this working by using the main minus4j class rather than a java object. No idea why this matters, but it does, and it's now working. This means I can now package up ROMs and samples without having the extra paramaters or load commands, which it turn will spead up loading.

I'm also planing to add a virtual keyboard that will let you click keys rather than search for them - Saying I don't get bored of all this first of course....

Minus4j Version 1.5 released.

I've just released the latest version of Minus4j, this is the one thats been up on plus4 world for a week or so. Its got some major improvements like Audio, joystick/key combos and auto starting via the filename.

Added a paramater for the initial frameskip value.

Removed software screen scale and now use built in JAVA one - should be MUCH faster.

Added ESCAPE key (Escape)

Added RUN STOP key - ` (backwards apostrophe, beside 1 key)

Added the * key (numpad)

Added undocumented opcode LAS,Y ($BB) command. Danger Diamonds now runs.

Minus4j now picks up sys0000 style RUN commands from the filename. So games like "mercenary_sys23552.prg" now work without a seprate RUN command.

Minus4j now picks up g12AB style RUN commands from the filename. So games like "mercenary_g5C00.prg" now work without a seprate RUN command.

TED Sound!!!

TED Samples!!

New "sound" paramater. sound=off or sound=on are valid. ON by default.

You can now press F7 while running to toggle sound (mute).

Added VOLUME control register.

If joystick is enabled, CursorKeys and Space key is disabled.

INSERT now does a soft reset.

Emulator now shuts down better.

You can get the latest version from minus4.plus4.net.

Virtual Machine JOY!!

I've just installed Microsoft's Virtual PC 2007 with Ubuntu running as a VirtualMachine, and its all going pretty well for a first install....so much so, that I'm typing this inside the Ubuntu VM! I've been testing the java version of Minus4 and it runs pretty well here, of course this is a pretty big machine (quad core, 4gig ram etc.) so its not a big surprise... still, at 50fps its pretty solid.

Once you scale the screen it starts to get sluggish, but a single frameskip pushes it up into the mid 40s and another to an solid 50. This is fine for games like mercenary that didn't draw the screen that much - or even XeO3 as I only draw the screen every second frame.

I still have to get sound working - and get the screen res fixed as its currently locked to 896x600 for some odd reason. Once I've done that I'm going to try and get mono installed ready for some real work! Then I want to get a Mac VM created (if possible) and try the same stuff there. This would give me a solid development platform and let me do ALL my work from a single machine/desktop! How fekin' cool is that!

Let there be sound!

After a marathon day yesterday I managed to get some audio into Minus4j, and it really does make a huge difference. For the moment its TED sound only, and I do still have a little bit to do yet before its really nice, for a start volume isn't used at all! I ported this code directly from Minus4w and have only just noticed that theres no volume control on it, doppy bugger that I am. Still, you now get 2 TED channels (tone and noise) and samples (using the TED). Samples are a bit crude to say the least, so I'll need to work on that a little - although I think I'm driving my wife mad listening to odd sounding beeps all day, oh well.

Once I have TED music in a better state, I'll port over my SID music player, and although its far from great (its a little rough and uses NO filters), it's still a good 1st step. After that, D64 support will almost bring it in line with Minus4w! Almost.... I'll need to see if its possible to save data to the local machine which would allow you to save games etc. other wise adventure games would be a pain. The solution to this I guess would be to port Minus4 to C# and Mono, this would allow it to run on any machine, AND on silverlight at a later date. It might also be a good time to use my cycle exact CPU I wrote about 6 years ago! It was designed to be more in line with YAPE than my scanline based one.

Still, thats a loooooooooooooooooooooong way off, and theres loads to do before that. Russell also pointed out that I could let Minus4j host my debug stub as well, meaning you could develop and debug Plus4 apps on Linux or Mac OS, which would be cool.

Anyway, head over to www.PlusWorld.com to see (and hear) the latest one in action! I've also started validating demos on Plus4 world, and although some just dont work, many work fine and its a much easier way of browsing them. We should really do an online demo page so you can have simple access to them.

Even more java love.

I've updated Plus4 World with the latest version of Minus4j. I've added a couple of handy features that allow even more games to run. The change list is below, and although I've not offically released this you can go and sample its goodness at plus4world.

Added a paramater for the initial frameskip value.

Removed software screen scale and now use built in JAVA one - should be MUCH faster.

Added ESCAPE key (Escape)

Added RUN STOP key - ` (backwards apostrophe, beside 1 key)

Added the * key (numpad)

Added undocumented opcode LAS,Y ($BB) command. Danger Diamonds now runs.

Minus4j now picks up sys4172 style RUN commands from the filename. So games like mercenary_sys23552.prg now work without a seprate RUN command.

Minus4j now picks up g12AB style RUN commands from the filename. So games like mercenary_g5C00.prg now work without a seprate RUN command.

I'm also looking to add sound just now. This is a long standing issue that I'd love to fix so I've been looking at a couple of other emulators and how they handle sound. I not have my Java applet buzzing with noise so thats a good start! I should now only have to port over my TED sound stuff (and later SID sounds) in order to get it playing. Although theres obviously a long way to go before that, but at least theres a buzz about the place now.

More improvements to Minus4j

So I was adding the escape and run-stop keys to the emulator last night, and was about to change the fire key from space to control (or something) when I hit a road block. Java doesn't GIVE you acess to the control key - or shift and ALT for that matter. These keys come through as modifiers, meaning you only get them when another key is pressed. Fek.

I'll need to look at other emulators and see what they do, but if this is the case Im not sure where fire will go - unless I disable the KEYBOARD "space" while joystick is active. Thats a bit fudgy, but it would work.

Oh well, I'll just have to carry on until I figure out something better.

And another thing.... In the future I hope to ditch Java altogether and move to Silverlight which is all C# (much nicer!). Someones already done a simple spectrum emulator HERE and while its not ballistic (because it still quite new), it will be better in the future, and MUCH nicer to code for. I suspect any C++ app can be ported over to it reasonably easily - since its C# and not java. Very cool.

Polls are now closed....

So...I thought it was time for another poll. Heres the results of the last ones.

What do you hope to do with XeO3?

Just play it! 52 (60%)

Just to look through the source for ideas 14 (16%)

Make my own levels. 7 (8%)

Reskin the whole game to make my own shoot-em-up. 6 (6%)

Use the full source code to make a complely different game. 6 (6%)

I'm not interested at all 1 (1%)


Which platform are you most interested in?

Commodore 64 56 (41%)

Commodore Plus/4 27 (20%)

All of them!! 15 (11%)

Amstrad CPC 14 (10%)

Commodore 64 Super CPU 10 (7%)

I'd like it on a different platform... 7 (5%)

Sinclair Spectrum 5 (3%)

So a couple of surprises.... One that theres actually 10 SCPU users! (unless he cheated and voted 10 times....), second that the CPC version out stripped the Speccy. Course, that could just mean we dont get a lot of speccy folk dropping by.

But with the main poll having a few folk actually wanting to use the source/scripting, I thought I'd ask another one. have any of you ACTUALLY looked at the demo scripting? Or better yet, even done something with it?!?!? Theres a new Poll over on the right, so let me know.

More Java - man I hate java...

So with the release yesterday Minus4j is actually in pretty reasonable shape. Sure it needs the source cleaned a little - theres loads of commented out crap in there, but on the whole not bad. So as I was adding another paramater to it (allowing you to specify the initial frame skip - since Xeo3 runs at 25Hz, you never NEED 50fps drawing), I suddenly realised that these days, Java probably provides image scaling as part of the API!

And sure enough.... there it is. So, I've now removed the software scale I was using and now use the API. This is of couse good for 2 reasons. One... being part of the API means it might be assembler optimised, and not just some tacky code I did, and second it reduces the code I've to maintain. Its all good.

Before I set it all aside again, I'm going to look into sound. I do this every 3 years or so to see how much effort it would be to add sound to Minus4j. When I started, you just couldn't, but there are now a few apps which do what I need to, so chances are its not too hard. All I really need is a buffer or two that plays music at a specific rate through a software buffer. I can then fill this up as I emulate things. This would let me plug in TED and SID music - not to mention samples that Minus4w can play. That would be cool - then all I'd need is some basic D64 support!

Oh... and while I won't release all these little bits, I will update both my blog and Plus4world to use all the latest stuff, then release it when theres enough to package it all up.

Speed UP! Slooooow down....

So, it turns out the Java compiler is fine (I think). My timing code (that makes the game run at a specific FPS) appears to be crippling things. But I have no idea how. If I take out my timing code and run the game unscaled it ticks along at 350fps - or 7 times the normal frame rate. It looks like thats correct too as everything is moving about 7x the speed, so I think the FPS counter is working.

So... whats wrong with my timing loop thats crippling it so much? I've tried to set and FPS of 200, but as soon as I do that, it tops out at 65fps. If I remove a couple of lines (the bit that makes it work), it jumps up to 350 again. So somethings rotten right in the state of Denmark... So, heres the timing loop, perhaps someone out there will spot it and save me staring at boring code for hours on end.....

          long tLastGameFrame = System.currentTimeMillis();
          long tNextGameFrame = tLastGameFrame + FPSRate;

          Last = tLastGameFrame;
          while (true)
          {
               long tNow = System.currentTimeMillis();

               // Quick check to see it timer has gone backwards!!
               if( tNow < tLastGameFrame ){
                    tLastGameFrame= tNow;
               }

               // Check to see if system is stuttering due background OS stuff.
               // if jumped ahead over 5 seconds, then just reset...
               if( (tNow-tNextGameFrame) > 5000 ){
                    tNextGameFrame = tNow;
               }
               
               // Timer has gone backwards
               if( tNow < tLastGameFrame ){
                   tLastGameFrame= tNow;
               }


               dTime = (int)(tNow - Last);
               if (dTime >= 1000){
                    dTime -= 1000; // dont get 0    (1000/1001)
                    actualfps = CurrentFPSCount;
                    CurrentFPSCount=0;
                    Last = tNow;
               }

               // Now the main timing loop
               if(  tNextGameFrame >= tNow ) 
               {
                      // do nothing...or yield/sleep
               } else 
               {
                      while( tNow>tNextGameFrame){
                             tLastGameFrame = tNextGameFrame;
                             tNextGameFrame +=  FPSRate;
                      }
                      CurrentFPSCount++;
               }

And there you go... pretty simple. Oh, and the reason for the backwards check is because in the modern world of clock syncing (to time.com or something), your clock might briefly go backwards. If this happens timer loops break - had this happen twice! Once on mobile phones, and once on a PC. Took me AGES to figure out the Mobile phone one, but fortunately I remembered about it for the PC.

New version of Minus4j released.

Well, I've decided to release what I've done so far so that Plus4world (and anyone else) can get the new bits.so head over to my MINUS4 site and get the latest one if you need it. Heres a list of the changes...

Updated rendering engine ported from Minus4w, should handle more cases.

Updated CPU processing ported from Minus4w. More games should run.

Fix a crash in the CPU processing.

Changed the colours to what Yape uses (much nicer)

Added FLASH attribute, so things now...flash. (Manic Miner keys, Monty pick-ups etc.)

Fixed the rendering frameskip - it was always skipping at least 1 frame *idiot*

Fixed the overflow flag (V) on the ADC instruction. Mercenary now works!

Added the new "joy" paramater

Fixed commando - added several undocumented NOP codes.

SOME vertical scrolling games work.

More Progress.

I've managed to fix Mercenary, although it wasn't the BCD mode it was the overflow flag inside the ADC instruction. Anyway... Here (I hope) is the current version. Click on the screen and then use the cursor keys to move and space to shoot. F9 is frameskip which may help speed it up on some slower machines. I'll be doing a release of this soon for Plus4World, but in the meantime - Enjoy!

This is pretty neat as it means I can show new things as code rather than video. However the new version of Java appears to be a little sluggish for some reason, and frame rate has dropped a lot. In the past I used to get upto 450FPS but that has now dropped to around 70fps - without scaling...pooh. I hate Java...

Still, when all said and done - how cool is it to have xeo3 actually PLAYING in a web page!!

Life in the old dog yet....

I've managed to debug Minus4j using Eclipse. This is a JAVA based IDE and its pretty spiffy in places. Couse...being Java based, its a bit sluggish - even on my new monster PC. Oh well, at least I can single step my applet!

So, which one hurdle down, another begins... I've ported a lot of Minus4 back to Minus4j (its pretty cool that the code bases are virtually identical, coz I can cut and paste most changes), and the bug I had was simple that the mainloop on Minus4w had changed a bit, so a quick change on the java side, and we're all go!

Minus4j now has inverted characters, the flash attribute, and a proper hardware cursor (not that anyone really used it outside of basic of course... but still... I'm also trying to update the CPU module as well, as minus4j is prone to crashing, and doesn't run some games (like Mercenary). I'm having a little trouble getting Mercenary to work - oh it runs and all, but it doesn't get past the intro. I'm sure this was a BCD problem, but I've ported the BCD stuff back from Minus4w and its still fubar. Mmmm...

What would be nice is if Plus4world could just allow EVERY game to be played online. Sure some wouldn't work, but I think most would and it would be easier to exclude some, then include them all.

Anyway, back to work I guess. I need to try and fix this BCD issue (if I can find it), and then add an option for joyport swapping to the paramaters (another request). I would love to add sound, but I'll need to look into doing dynamic WAV's under java. I know the C64 emulator can do it, so I might disassemble that and have a peek.

Intermission....

Albatross!! Albatross!!! Get yar Albatross here!


okay... Got slightly side tracked as a beta of Call of Duty 5 came out today so I had to have a blast at it... FAB game, got to be one of my fav all time games the COD series. Anyway... Aside from that I'm trying to update Minus4j for Plus4world so they can get more games on line, and so its well....better.

It does have some issues and I thought I'd port back some Minus4w stuff. This should be easy as the source for Minus4w originally came from Minus4j. So it was all going swimingly well, then BANG! It all fell apart. I have the drawing code ported back and as far as I can tell its now identical, except Minus4w works, and Minus4j jumps up and down like a rabbit on a pogo stick. So now I find myself in need of an applet debugger. Im sure it'll be obvious once I debug it, but until I do... I'm a bit stuck. Fek. I could undo it all and then just fix one issue at a time, but that seems silly as Minus4w is much bette over all.

*sigh*

Almost there....

I've just about got my PC setup again, althought theres always going to be apps I've forgotten about and will only rediscover later on. I thought I could get away with just installing the C# Express edition for all my needs, but alas no. I really need macro support and it doesn't have source control built in so I'll have to install the full Visual Studio again. I do hope to do some C# Express projects for the debugger to allow people to write plug-ins without having to buy the full visual studio though.

Speaking of source control... I've reinstalled Visual Source Safe so I can get access to my old repository but I'm thinking I want to install SubVersion. This would bring me upto date a little and allow others to check stuff in/out of my depo. Russell's been moaning at me for months to let him get access to the debugger and so he can keep upto date with the XeO3 source. I have come across a tool which converts VSS databases into subversion ones, so I'll have to give that a go - I like having all the history for them, but as long as I still have to old VSS repository I guess its not a huge issue.

The guys wanting to do a CPC+ version of XeO3 got in touch (again - I missed them 1st time around; my bad), so we'll have to have a chat and see if they meet the criteria for offical developers (Yes, I'm a picky bastard...).

I'm having a slight issue with my new install as it's a 64bit OS, my 32bit apps are struggling to talk to the parallel port. Still, once I get DevStudio installed, I'll see if I can fix all that. It should also mean I can release 32+64 bit versions, or I might take the opportunity to port them to C# and mono.

I've also downloaded a VMPlayer and will get a mono vm image so I can start doing Linux support. This will let me play with Linux without having to dedicate a machine to it, or even reboot into it. (I hope - depends on how the free vm player works.)

So with any luck... back to normal next week!

uniracers_credits

uniracers_credits
Originally uploaded by mikedailly

So someone was asking who was who... so here we go (hope I remember it right!) Clockwise fomr the top-left.

Robbie Graham - Artist
Malcom Scot Maxwell - Game coder and project leader
Dave Jones - Boss, Big cheese, and all round pest.
Andrew Innes - Front end, stats and general coding.
Martain Good - CG artist (did all the unicycles!)
Steve Hammond - Manual
Mike Dailly (Me!) - Level Editor, Uniracer compression, SNES framework and tools.
Colin Anderson - Music and effects.
Craig Arbuthnott - Head of testing
And I cant remember the last two. Testers I think....?

Head over to the staff pics on the Flickr account for better (all be it older!) pictures of some of us.

Demo coders....

There was a post on plus4 world about how to teach new people to code on the Plus4 and it got be thinking about some pet hates. Demo coders are renown for keeping sources to demos secret, never releasing anything but binarys in case someone steals their ideas. Others don't release code becasue, well... demos are usually hacks that are horrible bits of code and they don't want anyone to see just how much of a hack it is. Great Demos usually flow like works of art, but if you saw the internals, then its like being told how a magic trick was done, and the wonder falls away.

Still, I was thinking.... I never really code demos because, well... I'm not very good at them. Sure I can code things so they run quickly, and I can code things so that they're small. But I've never been good at prducing great demos folk really want to see. That said, I think theres a market (as it were) for demos that simply show how to do something. Kind of like online tutorials, simple demos that show off a simple effect and how to pull it off. This would allow others to use it and do what I can't, make great demos - or perhaps even use the effect in a game!

I was watching the demo posted here and was trying to think how they did the full screen scaling coz I think it would be cool in game. I think now I know but I also suspect that if the source was available I'd be much more interested in using/trying that I am now. Anyway, Csabo over at plus4 world is thinking about this too and I think its a great idea. If nothing else, it adds something valuable to the scene - which is what its all about now.

It's alive!!!!

I've rebuilt my PC, got a hold of a version of Vista64 and got it all up and running. I've also installed my new copy of office so my email is working fully again, which brings me to another point. If anyones been trying to get in touch and I haven't responded then feel free to ping me again as email should be back to normal.

I now have to reinstall all my normal software again, which will take a couple of evenings I guess, but I hope that by the weekend, I'll be back to normal - but with my fancy new quad core. I have also gotten two new terrabyte drives to try and get rid of all the little drives my PC was using, so with any luck... I shouldn't have to do this again for a long time!

New bits!

My new bits have arrived at last! So I can finally get started on rebuilding my shattered life...err..PC. The motherboard looks pretty good and actually has 4 DIMM slots, not the 2 I thought it had (the picture was pretty small), this means I could go up to 8Gigs of RAM if I want to (thanks to Vista64).

However...first things first. Build and reinstall is the job for tonight, if I get a chance - hope so. I'm gonna go and buy another 1Tb drive though so i can cut down on all the smaller drives I keep having to put it. My old primary was 160Gb, then I had a 240Gb and a 500Gb. So sod that, time to clean up and just get 2 1Tb drives. They're getting pretty cheap now, ebuyer actually had an external 1Tb for only £85(ish). This'll make life much easier and I'm beginning to get retro withdrawal!

Picture Fun...

I've been having fun with my new camera, and have been out specifically to take some nice piccys (something I plan to do more of if i get the chance!). I want to play more with the technique known as tilt-shifting. This is where you make real things look like models, and its very cool indeed given the right image. So I went up the law hill (the large hill bang smack in the middle of Dundee) and took a few images, then had a go applying the tilt shift effect to them. The image shown here is one of them, but I'm uploading more to my flickr account along with any other pictures I take (since they can stay full res there).

So if you want to see some of my piccys, check our my flickr account now and then.

New machine...

Well, with pay day comes the chance to finally fix my machine. I've order the bits I need to rebuild my main machine and I must say, I'm really looking forward to actually sitting down and a proper PC and not using a laptop. When multi-monitor appeared back in windows 98 it really did change everything. Not that many took notice back then, but I've now been using more than one monitor for so long, I really take bad to laptops with a single machine. In fact, at home I have 3 montors, and at work 4! Yes, you read that right...I have a single machine with 4 montors attached! I really should take a picture of it sometime as its quite neat. It lets me have virtually all my applications open AND visible - its very cool. I do wish they would make newer PCI cards other than the NVidia 6200 or ATI 7000 (which isnt Vista compatable)- which are both pretty crap.

So, I've bought a new motherboard that'll take my new quad-core CPU and 4gig of ram. To be honest, I'd be happy with a dual core, and 2-3gig ram but since I dont like doing this, I may as well make sure I dont have to upgrade for some time (a year or two at the least), so I've bought a good setup. Its costing about £250, but thats still less than half the price of an off the shelf full PC (from what I've seen...). I've also decided to install Vista64 (*sigh*) because I dont want to have to go through this again anytime soon... It does mean I'll have to either install DosBox, or rewrite the important ones. The other reason is so that I can create 32 and 64bit apps easily. I want my debugger to run in 64bit mode for example, and it also means I get access to ALL my RAM - which is nice... So yeah... hate it, but Im buggered.

When I was in the US I got a stack of BluRay disks, and I was horrified (and disgusted) to see they've started to region code things. Now, I read somewhere that they do this because something might be released on disk in the US, but just be coming out at the Cinema over here in the UK. Now, you might think well...okay, we might just about give you that. But then I was reading through a list of region coded disks, and found out The Longest Day was also region coded. Now... it was released in 1962, so what the hell do they take us for. In todays climent, we're in a world market, not local - particually with the credit crunch having been in the US but affecting the world. So I think it's actually a form of racism. After all your giving preferential treatment to some contries, and not others - and thats racist; Particually given that their excuse of movie release dates is an obvious lie. Region coding pisses me off. I paid for the disk, I bought it legally when on holiday, so why shouldn't I be allowed to watch it? We're a global enonomy, so why should Joe Blogs from the US be allowed to watch it and I'm not.... Now I'll have to wait and get a multiregion bluray player. I'll tell you one thing though, I will have NO guilt getting a hidef media version of it to stream from my PC - I already own the fucker. I'm a big fan of buying things you use,watch or play. If you get a copy of anything and dont like it, delete and and dont buy it. If you do..then you should buy it - whatever it is. I have a stack of games I tried loved so bought - many are still shrunk wrapped and only opened when I go back to play them years later. So my region coded Disk will be the same. Still wrapped, but at least I own them.

Sorry.... bit of a rant there.... Oh one thing though.... Some BluRay disks over there come with a PC media version, which is a FAB idea!! Well done those guys (whoever thought that up).

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. ;-)

Home sweet home....

I'm finally back from Florida and back at work (pooh...), but until I get my main machine fixed I won't be doing much of anything. I just cant work with my laptop, its small keyboard and single screen. I could use its screen and an LCD I suppose, and plug a USB keyboard in, but it just doesnt feel right. I really am an old geezer stuck in his ways - oh well.

If anyone needs any small task done, nows probably the time to ask :)

Disney world fun and games.

Still here having a blast. Kids are loving it of course, and its a shame I'm being forced to relax and have fun too! I've not done anything over here, and I'm not sure I'll manage until I get back home and get my machine rebuilt. I was looking at some off the shelf PC's, but they're so damned expensive I'll probably rebuild it myself; I only really needa CPU+Motherboard I think so...

I got a new camera over here too. A nice Nikon D60, very cool. Piccys are virtually always just brill from it without having to do anything special, and the manual settings are great fun. The piccy on the left was taken with it on auto setting. It just works...fab cam.

Anyway... off to church and then downtown Disney for some more shopping! It's a hard life....

Busy busy busy!

Been busy having some serious family fun so not had much time to do much - well, anything really. Still really needed to chill so here we are!

Kids have been in the pool a lot, and while I've only dangled my feet in, I've been lovin' it!

Still, time to eat I think, it must have been about 30min since I last ate! :)

Orlando!!

I'm currently in orlando having a family break, it's long over due really but I'm loving it!We had a great flight over as the plane had TVs in the back of the seats, so you could pick your own films or TV programs. It also had some good games to play, so Rebecca and I had great fun - I didn't even get my laptop out I was having so much fun!

It's been raining a bit here, usually for about 1/2 hour a day, and it's incredibly heavy (as usual), but because of that, it's not getting as hot as it can get which is great!

We've actually spent more time in walmart than anywhere else just about! The misses is loving it! We spent most of yesterday in the Animal Kingdom and eventually had to leave cause the rain was so heavy we were soaked through. Our clothes dried pretty easily, but our socks/shoes were soaked. I also appear to have killed my iPod, as my bag got soaked through, and the screen is full of watter - bugger.... I'm trying to let it dry out before trying it, but iPods never really switch off so I'm not hopefull. *sniff*

Plus4 world lives again!

Plus4 world now has a new home!! Although it still has some way to go in terms of files etc, you can now at least log on and use it again.

http://www.plus4world.com

Thanks again to Csabo for all his hard work!!

Bloody PC's!!!!

Well, it looks like I've had a hard disk failure, or rather its almost dead (I think). It keeps locking up, and it can take an age to access things sometimes, which is usually a sign your disks on the way out. This is a bugger an no mistake....

It means I've got to buy a new disk, reinstall everything, not to mention try and find all the software I use but forgot about... little utilities I take for granted.

I also have the choice of installing Vista or XP again. I hate vista, so the choice would seem pretty clear.... but that said, I dont really want to have to do this again. The hard disk that failed is about4 years old and its been that long since Ive had to install things again, but I hate doing it - who doesn't.

Anyway, all this means that things will now move pretty slowly as I need to do this before I can get going on my various projects again. Bugger.

I hate PCs.....

Debugging.

I've been discussing the debugger and trying to gauge how people develop over on lemon64 (HERE!), so if your interested head on over there.

I still think this project has the chance of being invaluable to the retro comunity, particually if I can get emulator writers to pick it up and implement the STUB (which I think/hope should be minimal work for them). This then gives a stable, consistent debugger across the board and should allow developers a great code base for doing tools and other features, not to mention develop new hardware and games.

I'm actively looking for feedback and suggestions on how you develop and what you'd liketo see in a debugger, so feel free to join in the discussion on lemon64.

Plus4 world gone....

Well, it would seem that yet another problem has hit plus4world, emucamp has had many problems reciently and now it seems its domain name has expired! I'm not sure where all the plus4 folk have gone to talk/complain about it, but I think now is the time to bite the bullet and move the site - enough is enough. Emucamp was okay, but its so incredibly unreliable now it's not funny, and I'd hate to lose the site because of some badly maintained server.

I tried to mail Lando, but he appears to have changed email addresses since I last spoke to him - which is a bugger....

Alive and kickin'

Well, I appear to be back in the world of the living again. I finally had to take a couple of days off to try and kick this cold and it appears to have worked, so after a reasonably lazy couple of days I'm finally sitting in front of my machine again looking back at the debugger.

When I started this I thought it would be a reasonably small job, and one I could quickly do and get it out there so I could progress with more interesting things, but alas... this was not to be. It's turning into yet another mamoth task, and one thats eating up yet more of my limited free time. Sure, once its all working things will be great! But that still looks like being a long way off for now. I may have to scale my initial release back a little so I can at least release something and not have this as yet another project that never seems to appear.

What I'll probably do is finish the Plus4 debugging so that its pretty good to use, and then do the emulator (TCP/IP) stub for everyone else, then release that. I know I wanted to get the C64 version done first, but that will take ages, and since it requires a real machine hooked up, I can only do it in my work room at home. Once I get TCP/IP support for emulators, I can carry on doing debugging features using my laptop anywhere I like using Minus4 (or my C64/Spectrum emultor for that matter).

I gave Russell my spectrum emulator and he's be rewriting it in C# with the idea of playing with Silverlight, but this means he's doing a Z80 debugger and will use the plug in interface to support his emuator.

So....thats where we are just now, lets hope I can kick things up a gear and do some actual work! Of course...I go away on holiday to Florida in two weeks, so that's gonna get in the way, although I've bought an extra battery for my laptop, so hope to do some stuff on the plane there.

You wait. Time passes......

Yeah, I've not been doing much past few days. I've got a bit of a cold so I'm feeling a bit pooh, and we've had some birthdays etc. so I've not had much time. I might get a chance to get back into gear over the weekend, but it depends on this cold...*sigh*

Go faster stripes....

I've been struggling with replacing the rich text box for a while and almost everything I've tried was much slower, even though I know I could plot those bloody pixels myself quicker that windows ever could. I've tried several things but I've finally gotten a normal windows form to draw without flickering like a bugger and fast enough to be - well, actually usable.

I'm now rendering the dissassembly window using a large bitmap that I create each Paint (although I'll probably change that to be a little more optimal later). Still, at least I can do pretty much anything I want now without having to worry about it. The update is pretty good to - much quicker than the RichTextBox. So, I'll continue to progress with this and clean up the code as its been hacked around quite a bit in the last week.

After that I really need to address the registers as they have to be created, updated and process by the plugin.

So...progress at LAST! I'm now into the middle third of the project, and this is where things seem to move at a crawl and will never get finished. However, I'm now getting things moving again and I hope it picks up pace and I can actually release it to everyone to play with. I really do hope it'll help change development and make emulators a better platform to write on, not to mention making it easier to test on real hardware.

Wikipedia

I was reading through some wikipedia entry's on DMA and their games, and it staggers my just how bad community editing can be. I look at these every now and then to see if anyone's discovered anything cool, but what strikes me the most is how bad the editing is.

Uniracers for example. About a year or so ago it had a fairly large entry and was pretty factual, but now its a tiny stub as editors trim bits they don't like. If you look back through the history far enough, you'll find additions by me where I talked about the split screen system having to be verified by Nintendo R&D. This was because I got the guys to use an old C64 trick of ripping sprites to get perfect splits. However some over zealous editor started asking for citations and verifications and it eventually got cut. It pisses me off a bit since they really know nothing about it, and any citations would have come from me in the first place.

The problem with only putting down things they are 100% sure of because its been in print somewhere else, is that there's never anything new. Its just a duplication of what's out there already. This is stupid. It means no one could EVER use wikipedia to publish a new theory or idea, because some little Hitler will come along and nuke the whole thing just because they have never heard of it.

Community editing is good, over all the right thing gets out there. Bits you've never heard of you leave, bits your sure about you add or fix. But at some point you get some kind of community editor, and they have too much power to kill things they don't like or don't understand. They are usually appointed because they've spent lots of time adding content, but it doesn't means they know what the **** they're on about.

All in all, Wikipedia is going downhill fast. Rant over....Grrrr...

Status...

I've not done anything this past week as I've been fixing a friends machine (and been knackered to boot!), so I've made no progress from what I reported last time.

However I was thinking.... I got a question a while ago about my tools being runable on Mac/Linux and I said probably not, but that might not be true. You see the thing about C# and .NET is that you can just use it as a C/C++ compiler as C# will happily do whats called unsafe code; thats basically where you use pointers again. Now what this means is I can port SNASM and possibly Minus4 into a C#/.NET environment and get it compiling, and it would then magically work on other platforms!

You see the thing about .NET is that its a virtual state machine, so you compile your code for a mythical CPU. This is then JIT (Just In Time) compiled when the program runs - much like Java is. This means my plain ol' C++ program would run quite happily under Mono on Mac or Linux. If I get a chance, I'll give this a go and see how I get on. Once its in a C# project I can then slowly port it properly to C# without all the pain.

(And yes...I know theres a managed C++ for .NET, but C/C++ sucks and I'd rather use C# these days...)

Toys - old and new

I've spent most of today playing with some old zx spectrum stuff. I looked out my old 48k spectrum (I actually have 4 or 5 now!) and some interfaces I have for them. I hooked up my Interface 1 and microdrive, tried my DivIDE (which I couldnt get to work on a 48k for some reason - need to find the manual...), and a Disciple interface. I had to find a floppy controller but had an old Amiga drive so used that. New PC drives dont work because they are hardwired to the wrong device. Still, the disciple interface works pretty well (its a clone though, not an original). It loads really (REALLY) quickly, and theres loads of storage. However theres no through connector (on this one) and I can use the interface one's RS232.

I also tried using the interface 1 with other things plugged in, and it didn't work either - although plugging an interface 2 did work. I have an interface 2 card that takes an eprom so thats a possibility as well. We could (for development) use an interface 1 and interface 2 to try out ROMs.

The other thing we could do is supply new ROM's for the spectrum itself, but thats not what we really want to do....

The first downloading code has to be written on the speccy, but after that It should be easy enough to develop for. However, most of this is Russells problem, and I've just been having fun for the day.

More progress...

As you can see from the screen shot I've now gotten the watch window up and running properly. I now need to implement breakpoints properly and come up with a better way to redraw the main dissassembly window, rather than use the rich text box.

Oh, I also need to implement the register window properly as its currently processed by the monitor app rather than the CPU module. Since each processor has different register requirements theres no way to have this done generically, so it must be handled by the CPU module. This is a pain, but necessary. Technically speaking, I could implement a simple generic one IF the CPU module doesn't, and this would mean you could get up and running quicker, but I'm not sure yet.....

Lastly, I suddenly realised that we could use RS232 on a 48K spectrum using an interface one as it has a serial port built in. This would be slow (2.4k a second) but would be quick enough for a remote debugger. I expect most work to be done in an emulator, but this would provide a cheap way to get access on a real machine. This will of course be up to Russell whenever he gets around to doing that.

Watch Window.

I've gotten most of the watch window running now, and although its not finished it IS doing the client memory lookup as part of the expression. This involves giving the expression system access to the ICOMMS interface. This is fine as the monitor window owns both the expression and the comms classes.

The theory is you can have multiple monitor windows each with their own ICPU,IComms and IEvaluation objects. This means watches are attached to the CPU window and so can fetch memory from the client using a different comms interface (or the same). This should provide the most flexibility for the future as you should be able to debug multiple CPU machines like the SNES or megadrive which has a main CPU and a seprate sound CPU.

So, for now the expression evaluation will do proper evaluations, and allow you to access memory on the client via the attached comms module like so: [TEMP+4,w] This looks up the label TEMP, adds 4 then looks up the client memory and downloads a word (the ,w bit). This could then be used as a further value into a more progressive expression like this....
[SpriteData+[CurrentSprite,b]*2,w]. Obviously the more remote memory accesses you have the slower it'll go; BUT it will do it.

So, its looking good. I've decided to drop the memory count at the end for now as this means you can ALTER watch values via this window as well - which I wasn't planning. So all in all, its going well.

I plan to release full sources the the following modules-

The ISymbolFile module to load the SNASM symbol tables

The ICPU 6502 CPU module

The ICOMMS parallel port COMMS module

The 6502 STUB for parallel port version of the comms (C64 and Plus4)

The TCP/IP ICOMMS module

The TCP/IP C++ STUB for emulators

I will not be releasing source to the main Monitor program. I do hope to be doing a UDP version for the RR-NET, but that might not be in the first release. There will probably also be a Z80 ICPU module for using with my spectrum emulator which Russell is currently rewriting in C#. He's also really keen to write a remote stub for a real machine somehow, although we'll need an interface for that first. I do have a download cable for an amstrad, so he should be able to write a stub for that in the future as well.

I'm not currently sure what the first version will look like, or what features will be in but I think it'll be the basic monitor with breakpoints etc. Watch and memory window. If theres anything you think it shouldn't be released without, let me know - but remember most key systems are pluggable, so if theres a CPU thats not supported, you can write it yourself! I might add some tool modules so that the ICOMMS can do things like fetch sprite data etc. This would mean you could add a tool that views maps, sprites and all the rest at a later date.

Future additions will include a 65816 module for the superCPU, and probably a 65c02 module as well as a Hu7 module sometime there after. I know these will take time to appear, but feel free to add it yourself! In the far distant future, 68000 will appear as I want to play with the Amiga+ST again and this would be an ideal way....

Be warned though, part of the license agreement to this will state that any new modules WILL be included in the main application package although I've yet to decide if it will require the source code to be relased as well. So even if you dont send me your modules to get included, if I find them, they WILL be. I suspect this won't be an issue for anyone, but be warned. This is only for new ICPU, ICOMMS (and any stub that goes with it) and ISYMBOLTABLE modules, not for any program that uses them. if you have a problem with this, let me know now why that is.

Watch me now....

I've been fighting with .NET list views for the watch window and have finally managed to get a watch class being mapped and displayed via the .NET data mapper. The Data mapper is very cool, and lets you map a class directly into a control. It also lets you add new items and will allocate/edit/delete new entries without me lifting a finger! Very neat.

I'll start on the actual watch processing tomorrow, and with any luck that'll be all that I'll need to do to implement basic watches! After that I'll need to get breakpoints working and I suspect the first version will closely follow afterwards.

Coming together....

I've been making steady progress and have now got the dissassembly window scrolling around under user control (without tracing). So you can now use the cursor keys to scroll the window, and the page-up and page-down keys to move quicker. It's going pretty well but I'm not happy with the ricj text box control. It feels slow, and there are a few keys you can't seem to override. This means although it gets rewritten every tick, you can upset things by pressing enter at the wrong time. I think I'm going to have to draw it myself somehow - perhaps even on a bitmap or something....

However that aside, its making good progress, and once I have user breakpoints in I can start looking at memory and watch windows. But the drawing of the display remains a concern....

Single stepping.

After a long discussion with Russell on Friday about the best way to single step, I decided to try out the new method. It basically involves having the STUB execute a single command inside the STUB itself. Currently I simply place a breakpoint one instruction later, and then run the application; the program runs, hits a BRK then stops again. This new way is friendlier to machines like the ZX Spectrum that has issues (and bugs in the ROM), but its tricky.

Imagine you've stopped the execution of a program, saved all the registers, flags etc. and now want to single step. What you would have to do is copy the instruction you want to trace into a 3 byte slot (thats prefilled with NOP's), restore all registers and flags (also stack) and execute the command. You then resave everything and return back to the debug comms loop. It sounds fairly simple but its not as easy as it appears.

;******************************************************************************
;
; Name:  SingleStep
; Function: Given an address and a byte count, execute a sequence of bytes
;
;******************************************************************************
ExecuteCommand:
             jsr   GetByte             ; Get destination address
             sta   Dest
             jsr   GetByte
             sta   Dest+1
 
             jsr   GetByte             ; get opcode size
             tay
             dey
 
             ; Clear out exec buffer
             lda   #$ea                ; Clear the instruction space 
             sta   ExecBuffer+1        ; in case the instruction isn't 3 bytes long!
             sta   ExecBuffer+2
 
             ; copy 
!lp1         lda   (Dest),y            ; Copy the instruction to execute
             sta   ExecBuffer,y
             dey
             bpl   !lp1
 
             tsx                       ; Save current stack
             stx   StackStore
             ldx   RegSP               ; Restore application stack
             txs
 
             lda   RegF                ; Get the flags ready
             pha
             and   #$4                 ; We must keep interrupts OFF!
             sta   RegF
             pla
             ora   #4
             pha
 
             lda   RegA                ; restore registers
             ldx   RegX
             ldy   RegY
             plp                       ; restore flags
ExecBuffer:
             nop                       ; Command goes here.
             nop
             nop
 
             php                       ; Save flags
             sta   RegA                ; Save registers
             stx   RegX
             sty   RegY
             pla                       ; get the flags and store
             and   #%11111011
             ora   RegF
             sta   RegF
             tsx
             stx   RegSP               ; Store the application stack
 
             ldx   StackStore          ; get the debugger stack back
             txs                       ; and restore it.
             rts
StackStore   db    0

Now you'll also notice you have to do some jiggery-pokery with the flags so you dont reenable interrupts by accident (since we're actually still IN an interrupt), but aside from that theres a lot of stuff involved. The bit I really dont like is that emulators simply wouldn't do this. They would simply set a break point and run. I really don't want to have 2 ways to step through code, I'd like it if the CPU module simply didn't care if it was a real machine or an emulator. Now, the spectrum can still do it with breakpoints, but since the spectrum ROM has bugs in it, its limited in exactly what it CAN do.

We currently think you would need to do breakpoints with CALL's, as the RST instruction needs ROM support and its the part thats bugged. NOW calls take up a few bytes which means you have limits as to where you can place a breakpoint. For example, if you were to branch over an XOR A but wanted to put a breakpoint on the XOR, then the breakpoint would overrun onto the next instruction, and it might crash.

Now for single stepping, that shouldn't happen; particually if the coder is aware of the limits. On other Z80 machines, it should be possible to use the RST instruction to do the breakpoints so they would be fine. I've put breakpoint control on the STUB for a few reasons, but because of this it means each STUB can decide how it wants to do them.

So... after playing around a lot with it (and actually getting it to work), I've decided not to use it, but to go back to the breakpoint idea. I think it has the widest compatibility, and if your really stuck you could still implement you own single step if you modify a CPU module and package it together with a dedicated COMMS module.

I've also started to think about the TCP/IP module for using with emulators (and I'll do a UDP one for the RR-NET later), and I'm starting to get excited about the possibility of it being adopted by other emulator guys. If all goes well, then no one should ever have to write a built in debugger again!

Lookin' good!

I've finally done enough to make some visible progress. With the addition of the expression evaluation, symbol table lookup and command line processing means I can finally display symbols in the dissassembly view. It's now starting to look like a proper debugger. I need to get left side labels in next (where the addresses are displayed) so you can see where your branching to, then we'll be mostly done in that view.

I still have to add control of the view but thats next. The biggest unknown is the registers, I've no idea yet how to display a generic number of registers or how to lay them out. I'm tempted to let the CPU module display them as well as handle them, but I don't know yet.

Good progress!

I've gotten on pretty well tonight! I've managed to finish BOTH the lexical analysis class and the expression evaluation system. Not bad for a nights work. I can now evaluate things like...

((2<<(4*4)+8*4)&$ffff-MySymbol)*4

This means watches can enter calculations to be evaluated, which you can then apply the [...] modifier to so that its a memory lookup on the target. I still have a way to go as theres currently no way to get the evaluation system to look at the targets memory OR registers. However that shouldn't be hard and then things will start to get very cool. Of course the inital reason for this is so theres an interface for the CPU module to lookup symbols for the dissassembly, but through the same interface you'll be able to execute actual calculations.

I also have the ability to add commands to this, like Lo() and Hi(). This means you could do calculations like...

Lo( 2<<(4*4)+8*4 )<<2

This is pretty neat, but it also opens up for more complex functions like ...err... SQRT() or something, which is pretty cool too. The whole expression and lexical stuff is just 2 small C# files, so its pretty portable if I want to do anything else, so this could be handy!

Expressions and Lexical analysis

So I started to look around after yesterdays revamp of the plugins, and realised that to finish the intialisation system I need to pass in an expression evaluation interface. Oh well.... more code to port..... I started to port over SNasms expression stuff but it soon became apparent that I needed a lexical processor first. Now the one in SNasm it pretty fully featured, but a bit much for a command interface, then I suddenly realised that I dont need very much at all. I need to be able to pick out symbols (like *,."$&[]() etc.) and symbols. This means I only need a very simple one as at text I dont understand will be a label (or I can do a quick dictionary lookup to got basic commands).

So I've almost got this basic one going, and its really very simple but will do the job at hand. So I'll finish this tomorrow, and then port the expression stuff the night after and finally I'll be able to get the intialisation stuff done. It also means I can start to load symbol files and get a proper symbolic dissassembly!

Slow going, but we're headed in the right direction.

Slow going....

I've not been doing much on the debugger as I've been busy with real life, but I did get some time today to mess around. I've been updating the plugin system to make it more flexible and so that I can do some work on the command line arguments system. Currently I can specify which modules I want to use on the command line (along with symbol table loader and symbol file), and the next step is to spawn a monitor window using the selected modules.

I've rearranged all code so that multiple monitor windows are possible, in theory this will allow debugging of secondard CPU modules as long as the debugging stub or interface supports it - although thats a long way off yet.

Future plans....

There was a question about using the RR-NET instead of the serial port, so I thought I'd answer in depth here.....

Currently I'm debugging via the user port on a Commodore Plus/4 and the parallel port on the PC, but the plan is to then do two C64 versions using both the userport AND the RR-NET (since the RR-NET is far easier to get a hold of). However the user port version would allow you to develop more hardware as you can't always use RR-NET if your trying to develop for a bit of hardware where theres no passthrough, or it's simply not available (The current cart disables the pass through when in use.)

That said, for normal apps and games, I hope the MMC64/RR-NET (and the MMC Replay) will be invaluable for getting things working on real hardware. Theres nothing quite like debugging on a real machine, particually if you are using the MMC64 file loader stuff I did in the framework, as thats currently impossible to develop with via an emulator. Of course someone could also implement a SilverSurfer stub as well - nothing to stop them!

In between these versions (probably at the same time as the RR-NET version), I'll write my first emulator plugin and get Minus4 working using it. This will then be given away for everyone to use. I then hope that new modules will start popping up as all the hard work should be done, and emulators should just be able to plug it in. Once we have some simple CPU types (Z80, 6502 etc.) then all an emulator should have to do is implement the STUB and it'll all magically work.

The idea is to give away the source to the 6502 module, the COMMS modules, all the STUBS that I end up doing, and the Symbol table module. This should allow you to write whatever system you want, without having to implement all the crap around it that makes up the debugger - in theory. It also means you can easily adapt modules for your own use; so the 6502 one could be changed to be a 65816 one, or a 65c02 etc. allowing for new machines like the SNES or PC Engine to be added easily.

Lastly.... if theres ever any real problems with getting a particular machine to work using the interface provided, then all you need to do is put both modules in the same DLL (comms and cpu) then you can add extra interfaces to expand or alter the behaviour. Lets say you couldn't implement single stepping in the way thats assumed you would, then you can add a new comms command that only YOUR cpu module knows about and call it instead.

Thats the theory......

Bingo!!

I've now fixed the tracing system so I can trace without a problem. I managed to single step through quite a bit of XeO3 which is a good sign. It appears to be pretty solid, I can stop/start and trace without any issue now - which is great. That means I have the core functionality now needed to progress. The current CPU and COMMS interface does have an issue however.... Single stepping on the spectrum (a 48k one at anyrate) isn't easy, and in order to make it better you really need to get the target to execute the single step so it can do it best for itself. However, getting the stub to do that takes quite a bit of memory and I dont want that, so I need to think about it a little longer....

Almost there!

I've now got things almost working, single stepping is rock solid and I now have the RTS instruction being simulated fine. There appears to be a slight glitch where on a specific instruction in XeO3 it doesn't step properly but jumps off to $FFFF for some reason - no idea why as yet. While I'm trying to figure this out I'll start adding breakpoints to the interface and then get the symbol table loaded.

I suddenly realised that I shouldn't be passing the an interface top the symbol table to the CPU model, but an interface to an expression evaluation module. This means the CPU code could evaluate expressions if it needs to, and that leaves me to deal with symbol table lookups inside the expression evaluation without having to worry about it. You'll still be able to write your own symbol table so that you can load funny symbol file formats, and you'll still be able to query for symbols but this time it'll go through the evaluation system instead.

I'll pinch the expression stuff from SNasm and put an interface around it, this means it'll handle anything SNasm could (which was a lot!). It also means that watches (with their complex expressions) should be a breeze to process, all I need to do is add the new [..] context to get memory from the target. Should be fun when its all working! I'm still not sure how fast its all gonna run, as getting lots of memory over a parallel cable isn't quick, still emulators should be very fast and at least you'll be using a common interface then!

I also realised that each module (ICPU, ISymbolTable and IComms) needs to be able to change some options, so I'll add a new interface that means it can pop up an options box and allow you to change things. For example, the CPU module might allow you to enable undocumented opcodes which aren't on by default.

So there you go! Its going pretty well so far! Once I get it to a basic level, I'll need to see if I can get some other coders to try it out and give me some feedback. of course, having only SNasm labels might hinder things a little, but then again it would be a good opportunity to have someone else write a module and tell me how easy or hard it was!

Step, Step, Pause, Step step, step step

I didn't get much done tonight, but single stepping is a lot more stable now. I've updated the window update so that it doesn't request the current view every time you single step. This obviously won't work for self-modifying code, but for now it makes it much quicker to single step. I'm trying to get the RTS instruction to work but the register update doesn't appear to be working yet. The idea is to simulate RTS and RTI (and possibly JSR, JMP and all the branches) but this involves updating the registers to their new values.

I'll need to clean the monitor code up once its all working, as its getting a little messy just now. Also I'm still having trouble debugging this code as devstudio doesn't appear to want to load the symbols for all the modules its loaded....very annoying!

Squeezing it all in.

Now that things are working better I've started to try and squeeze it all down a little. It's not finished by any means, but I think it's at a reasonable stage where I can start to think about the memory foot print. The inital goal was to have the stub take up around 1k, but I now have it down to under 0.5k which is great news. I'm sure there's going to be more added to it, but its pretty complete for now. As a default setup, I've put the debug variables on the unused bits of the stack ($100 to $138) which is usually free - although since I'll give away the source - you can put it where you like. I only use 5 bytes of zero page $FA-$FF so as along as you avoid these locations, all should be well.

I've made pretty good progress today, and while tracing still isn't finished (still jumps off into the wilds now and then), it's now progressing nicely. I'll fix up JSRs, RTSs, RTIs and branches tomorrow night if I get time, then I can move on to making the dissassembly window nicer along with a user controlable BAR for scrolling the view around, and then start on the symbol table and displaying a proper symbolic dissassembly.

AT LAST!!!!

I've finally figured out what I was doing wrong...what a twat! Okay, so in the old remote debugger I hadn't delt with the +2 of the BRK instruction and I have here, so that wasn't it this time around. I was begining to think the 7501 was slightly different from the 6502 and all the docs I had would be wrong for it, but no. The REAL reason was far simpler..... I had 2 interrupt routines.

Now I figered you only need to check for a debugger in one of them since its only checking comms and waiting a frame there doesn't matter, but the more I tested this BRK thing, the more confusing it became.

I was able to make a test where it was out right ignoring BRK instructions! I simply couldn't figure that out, that is until I realised you need to call the debug stub EVERY interrupt so it can ALSO check for BRK instructions. Otherwise it'll just exit the IRQ and carry on like nothing happened.

So, that really annoying bug fixed, and I can now single step/run/stop in a rock solid manner - at last! Now I need to emulate RTS and RTI instructions so that the debugger works properly, and I'll probably emulate branches as well since it means I only need one breakpoint. Although I'll allow RTI via the monitor, you wont't be able to debug interrupts, this is just for emulator support as it WILL be able to debug interrupts. Because a real machine uses BRK's for breakpoints, its stub is inside an interrupt, but emulators dont have to do that, they can single step anywhere and dont need to write BRK's, they can just have a breakpoint table and check to the current PC which makes them very powerful.

I have to say I'm relieved, it was starting to get to me. I usually don't spend long on bugs, but this one was pushing it.... Still, all fixed and now we can really push on with some monitor features! It'll be great to get real watches and multiple memory windows without having to do to much. The comm's speed will probably hurt the update of watch windows, but we can probably put in a bit of smarts and a FORCE UPDATE button or something to help. Watches are probably the most powerful thing I've missed as you can ask for a variable and tell it the type and number of entrys you want displayed. i.e.

DestAdd,w:        $2881
SrcTable,w,3:     $8002, $8100, $8132
SpriteData,64:    $00,$01,$02,$03,$04....(up to 64 bytes)
[Temp,w]+y,5:     $10,$22,$44,$86,$00

The other great thing about watches is that you only get the memory you need, not a whole memory window just to watch a single byte! You'll also notice I hope to do expression evaluation like "[Temp,w]+Y". This would get the word contents of Temp and add on the Y - or something like this. this is of course way down the line, but features like this will come, and everyone that uses the STUB interface will benifit without having to do it themselves.

Progress? Who knows....

Here's another little test app and this one's pretty simple, but it does show up the flaw.

58C9  CE 15 FF      dec $FF15
58CC  EA            nop   
58CD  EA            nop   
58D0  00            brk   
58D1  EA            nop   
58D4  EA            nop   
58D5  4C C9 58      jmp $58C9

Now on entry to the debugger I adjust the stack to point to the BRK instruction so that we know exactly where its stopped. This works fine. But on exit I expect it to re-execute the BRK and not do anything, however this one does not. When I run it again the screen colour changes, and its not supposed to. I suspect this is the problem, BRK's are not being restarted properly, but at least now I have a test case, I should manage to fix it easily enough - I think.

Trouble ahead.

I really am struggling with getting this thing to single step properly, its a nightmare! The actual monitor code is pretty easy but I think I have something wrong on the stub end that means its just now working right. I have a single breakpoint that I place after the current instruction (lets ignore branchs and calls just now), and I then resume execution. The idea being that it runs a single instruction and hits the new breakpoint (however its been implemented) and jumps back into the debugger again.

The problem is, its just not working like that. Now RUN and STOP work great, so I know jumping in and out the debugger is fine, and I have tested BRK instructions as well and they are okay too. Whenever I hit a break I subtract 2 off the PC (as its moved on entry to the interrupt routine), and I can then resume again.

So far so good.... but if I drop in some more BRK's, they don't seem to be getting hit properly at all. I can't of course debug the stub either so I'm left with just looking at code. I suspect I'll need to start a new, simple project to try and figure out why its not working, as staring at code doesn't seem to help.

So heres the loop Im trying to debug, and its interesting coz aside from not doing much, it shows up several issues.

58D1 CE 15 FF    dec $FF15
58D4 A9 01            lda #$01 
58D6 A2 02            ldx #$02 
58D8 A0 03            ldy #$03 
58DA EA               nop   
58DB CA               dex   
58DC D0 FC            bne $58DA
58DE B9 00 10         lda $1000,y 
58E1 88               dey   
58E2 4C D1 58         jmp $58D1 

First, if I try and single step $58DA, the whole thing dies a horrible death. IF I try and step $58D6, then $FF15 is increased and Y is decreased to 1 (which is impossible).

Its all very odd, but there must be a logical solution - somewhere!