RetroEdit: Back again...

After a short break - where I more or less did nothing but sleep, I've come back to RetroEdit and decided to shuffle things around yet again. While it's been going fairly well one thing thats been lurking at the back of my mind is that I'm going to have to do this all again - but this time with characters. The one thing I hate doing is repeating the same work, even if its cut and paste job, its just horrible. So, I'm about to move the rendering part (and probably the editing side) over to a user control. In VB and C# you can write your own controls that you can then drop into your windows form. This is pretty handy since on most retro machines the rendering for sprites is the same as the rendering for characters. i.e. The Spectrum is still HIRES, the C64 still has HIRES and MCM - as does the +4. So, I'll move all this code into its own display (RetroBitmap) and then I'll be able to use it for drawing/editing both sprites and characters (or chars+tiles on the spectrum).

It also means that once released, others can simply swipe the .DLL file and use it themselves inside their own C# or VB project - which is also nice.

And.....rest....

Done nothing at all tonight.... well, not quite nothing. I got an Opus Discovery disk drive for the spectrum months ago from ebay for a steal (around £14 I think), problem was it didn't work. I've spent the past few nights tinkering with it and I finally figured out what was wrong. The disk drive itself simply wasn't working. After pulling it apart and putting it back together the drive started up and kinda worked, but I got disk errors. So, I dismantled it again and saw it was more or less a standard PC floppy drive, but plugging in a PC floppy didn't work. Probably because back then they were XT drives. So I was trying to think of a way to get an old XT drive to try, and searched the web for one, but with no luck. Or rather no luck I want - $170!! No thanks.

Then I had a brainwave. I'd just gotten an 1581 drive assembly (without drives) where it stated the drives were removed for use in the Amiga, so I thought...what about an Amiga drive? I was a bit reluctant to destroy an Amiga to get this working, but I thought try and see - I could always keep an eye open on ebay for a dead Amiga. Then it stuck me: The Atari ST reads and writes PC disks... Anyway, since I have a huge amount of crap, I of course have a dead Atari ST, so I removed the drive and plugged it it - BANG! works a treat! It seems to have all the jumpers the PC XT drives have as well, so if your ever after an old XT drive, try an atari one first - they're cheaper!

So, job done - back onto Retro Edit tomorrow I hope.

RetroEdit: Clean up.

I've not done that much tonight, just cleaning the code up and putting in the machine selection system I was yattering on about yesterday. Now if I load in some sprites and I select SPECTRUM as the global machine state, it sets all the sprites to hires. Same goes for PLUS4 and C64. On SPECTRUM mode, it also disables MCM selections and so on. This is the kind of things I've been doing, nothing earth shattering.

I've also added in an Enable Mask tick box, and an Edit Mask tick (which becomes active when masks are enabled - of course). This means on spectrum sprites, you can edit masks along with the sprites. I'm thinking of putting in a basic "light box" mode as well, to let you see the next (and possibly the previous ) frame so animation is a little easier. I'll also allow this mode for MASK editing, so you can see the shape you're trying to bring out. All these kinds of features till take time to do which is a bit of a pain, but its back to the problem of a single state that then effect the almost every other state, and you have to make sure its valid. Yuck.

I hope to start basic editing tomorrow so that it'll actually become useful, so once I get HIRES and MCM drawing it, I can let Luca lose on it, and see how it holds up. I need to figure out how to detect key presses in c# first so I can use things like + and - to change sprites, and 'm' to toggle the mask view on and off, that kind of thing. So still lots to do.

RetroEdit: HiRes Appears...

I've spent the evening changing the editor into something a little bit more sophisticated, it can now do Hires and MCM sprites - although I still can't edit them. I've also added C64 and Spectrum modes so that once I allow you to select it, you'll now be able to edit using those colours. Internally, its almost completely changed. before I had a simple C# List<byte[]> for my sprites, but now I've gone and made a nice Sprite class that contains everything about a sprite - the basic array that makes up the pixels, its width and height, and which editing system its using (Plus/4 and C64 in MCM or Hires, and Spectrum).

While this actually lets me have every sprite different in the animation sequence - even down to different systems(!), its actually a little impracticle. I suspect what you actually want is a global editing mode, so that you when select C64, Plus/4 or spectrum the whole project swaps to that. I think what you really want is to be able to load in sprites from one system, and convert it to another - as best it can. This will mean that C64_MCM->Spectrum conversion gets the HIRES version of the sprite, but it gives a starting point for editing; rather than having to do each one by hand.

However, I will allow each sprite on the same system to vary - because thats perfectly valid. So MCM/HIRES isn't a global state, but one for each sprite. This means you could create many C64 MCM sprites, and then create some HIRES overlays for them, all within the same project.

This is actually the thing that pisses me off most about editors. Theres so many dependencies. Change one radio button or drop down menu, and you have to do shit loads behind the scenes, and make sure every combination works!.... pain in the bum. However... I hope to be able to use the same basic classes in the character editing which means you should be able to edit 16x16 characters for the spectrum - or Plus/4. Internally, its stored as a simple array, but when you save it out, it'll convert it to the correct output format. Plus4 Sprites, chars, sprectrum sprites, C64 hardware sprites; well...thats the theory.

XeO3: The games afoot...

Luca and I have been hammering out the how the actual weapon system is going to work and I have to say its one of the few times where internet development really sucks. Trying to chat about something like this and get the details right so that we both agree is hard enough, but having to type every line into Windows Messenger is just a nightmare. If we were in the same room, it could be done in about 5-10 min since we could discuss it easily, draw diagrams on a bits of paper, and basically get to sorted quickly. But over the net, it took us the better part of an hour to go through it and make sure we both understood what the hell we were talking about. Oh well, its all sorted now - I'll let Luca go through it all though.

I've also been trying to figure out how to erase files from a floppy using the kernal. Little bit of a pain, since theres hardly anything telling you how to execute disk commands from assembler. I know you can do this in DOS...

  open 15,8,15,"S0:FILE"
  close 15

But, I wasn't sure how to actually do it in assembler. I finally found some code after a bit of hunting around and this is now what I do...

    lda  #15                   ; file handle
    ldx  #8                    ; device
    tay                        ; command channel
    jsr  SETLFS                ; set channel details
    lda  #8                    ; length of filename ("S0:SCORE")
    ldx  #LO(HISCORENAME)      ; pointer to score
    ldy  #HI(HISCORENAME)
    jsr  SETNAM                ; Set file name
    jsr  OPEN                  ; perform OPEN command
    lda  #15
    jsr  CLOSE                 ; and close the channel

And thats all there is to it. When we have the turbo installed we'll have to issue a save with overwrite and get the turbo (on the disk drive side) to erase the file first. This is all to avoid the SAVE "@0:filename" bug. However, after all this is done, it'll mean we can save hiscores to disk for a proper record - which is cool.

XeO3: Not as stupid as I look!

After yesterdays head-banging moment, I sorted out exactly what I'd need to do in order to get a proper double buffered star field. Then after groaning inwardly at the effort involved just to get a bloody star field running, I slapped myself hard across the face with a virtual fish - and got on with it. I now needed another two 100 byte tables (CPU built, so theres stack of memory for that), 4 star routines in total (2 to draw, 2 to clear - ouch!), but could reduce the size of my logo drawing code to almost nothing - much better.

So...What does the new Star code do? Well, picking up from yesterday... It now copies the current index into a SAVE_STAR table (2 of these, 1 fro each frame), checks to see if it can draw a star at the desired location, and then draws the correct character, and colours it with a random colour (multicoloured stars are much nicer than depth queued gray ones) at the same time making sure its in HIRES mode (top half of the screen is in MCM mode). This is fine... Now comes the really annoying part. To wipe them, I read from one of the SAVE_STAR tables, check to see if a star is actually there, and if so wipe it. I dont need to wipe the colour, as theres nothing else going to go there.

Now for 360 stars, this is horrible, much slower than clearing screen and blasting it on. However.... for the original 100 stars, its much faster. So...strike a little bit of a middle ground (240 stars or less - undecided just yet), and the fact I no longer have to continually draw the text and the logo, means I win out over all. So the original idea wasn't that dumb after all, and while I may actually be as stupid as I look, at least this time I get to keep my head firmly attached to my shoulders - but theres always tomorrow.

XeO3: Stupidity abounds....

I often wonder why programmers are never given protective head gear, since every now and then we do something so stupid then you either bang you head off a desk, or get someone to hit you with a hammer. I've been thinking about rewriting the front end star field so that it goes in between the stuff thats already there. This means I wouldn't have to clear the screen and then redraw it every frame! Quite a saving.

So I set about doing this thinking all I need to do is double buffer the star locations and then clear anything thats in the "clear" list. Sounds easy doesn't it. The problem being, that my star field is actually in 4 places at once. A star can have a location of 0 to 255, which I then store in $0c00,$0d00,$0e00 and $0f00. This means I get 4 stars for the price of 1, and when a star leaves one zone (goes from 0 to $ff) it smoothly enters the next and you never know.

The problem being, to clear the stars, I can't just store a location, I need to check to see if a star is actually there because it might be visible in one bank, but hidden in another. When you add this time to the increased time taken to actually plot the stars, it'll probably come out longer than the current method! Idiot. I'll have to sit down and think about it a bit more. Theres always the chance that because I dont redraw the logo or the text, that this doesn't matter, but I'd like to be able to have lots of time to spare so I can scroll stuff onto and off of the screen - and Im not convinced I can do that knowing how long it'll take.

Its a pitty as well, I increased the number of offsets from 24 to 90 (giving me 360 stars in total) thinking that since I'd saved stacks of time, I could now bump up the number - WRONG!. Idiot!!.... Wheres that baseball bat when you need it.....

BTW - this star routine was pinched from Delta on the C64, I spent a while hunting it down years coz I thought it was fab.

XeO3: Death of a Parallel port....

Well, looks like I've fried part of my parallel port; damn. Pin 11 (busy line) doesn't appear to work anymore. This is probably why I wasn't able to get the C64 to set it - or at least the PC to notice. The plus/4 downloader is now also dead because it also uses that bit; damn. I know the machine and cable are okay as I've currently got the Plus4 plugged into my server and it can upload from there; damn. Although....its VERY odd that only 1 pin has died - I'd have expected the whole thing to go, but since the C64 still happily displays values getting sent TO it, I know its still a little bit alive!

Oh well, this means I'll have to go buy a plug in card - but if I get a dual port, then I can have the C64 and Plus4 both plugged in at once. At least some good has some out of it. I remember reading about doing hardware stuff. You dont just pay with your time while you debug it, you pay with your wallet. Oh so true. Still, it also means my C64 cable is now ready to go....all it needs is a downloader! It should be around twice the speed of the plus4 one which can currently download XeO3 in around 7.5 seconds. 3 seconds, 7 seconds... doesn't really matter I guess - fast is fast.

If I get around to doing my remote debugger, it might be nice to have a proper bidirectional port - even if it is a nibble. When I was doing a playstation debugger with the PSone action replay's I was using a bidirectional serial port on that and it was great, it made its communications very robust. I'm still determained to do a full, proper remote debugger for both the C64 and the Plus4. Theres something very satisfying about debugging on actual hardware. Of course...emulators have some BIG advantages - like being able to debug interupts, being able to stop and view hardware registers at any point...well... pretty much everything! But its still not a real machine your controlling. Oh I dont know...it would just be cool.

XeO3: A work in progress...

I've added the new front end logo, made sure the game cycles properly and all the usual stuff. So I've decided to treat every one with a video of the current state of play. Its nothing fancy but shows the game running and lets you hear the sounds and music togther. The paths and animations aren't final, but it does show you it all working. Hope you can view it okay.

I've now got a grand total of 440 bytes left. This means the big squeze is on again! I also need to shuffle the memory map once more so that I can use large space at the top of memory to store the logo and character map. I hoped to keep this space, but it looks like its now about to get all used up. Bugger.

The only free or at least flexible space is now the sprite cache. This area can take a little bit of a pounding since if its not in the cache it'll just redo it. However, it does take more CPU time to re-cache something so I'm reluctant to do so.

Edit: The direct youtube link is: www.youtube.com/watch?v=W-DtKhk6qFw

XeO3: Front End..

So after a couple of days squeezing the front end down as much as I can, I've now spent today putting much of it back in - bugger. I got a logo from Luca to try and tart the front end up a bit, and it means I have to start double buffering the front end a bit. Since the logo itself takes up almost 1K, it also means I'll have to try and free up even more space. Its worth it though as it does help make the front end a bit nicer. I hope to finish this up tomorrow, and then I can take stock of the damage its done to the memory. At least if we do need to trim it, theres at the very worst we could just reduce its size.... It also means my nice and simple 3 layer starfield isn't nice and simple anymore. I now need to double buffer that as well so I dont need to redraw the logo all the time! Its never easy.....

I've had to redo my C64 parallel cable as I got the pins backwards! Doh. Idiot. All the diagrams I found to tell me the pins never actually got around to telling me that it was describing the back of the computer, and not the cable itself. I had assumed that it was descibing the cable, since thats what everyone wants to know! But no... wrong again. Anyway, I've built my own cable rather than the PC64 one, and once I manage to get the PA2 line working, I'll be able to download a whole byte at a time, rather than a nibble which all the other cables seem to do. Not sure why... it might be to do with old parallel ports not being bi-directional or something, but I don't really know. If I can't get the PA2 line working, then I'll have to drop down to a nibble and use some of the datalines as handshaking - which I'd rather not do; although if Im desprate, I could do 7 bit.... but thats horrible!

Edit: Oh! And after finding the old instructions to my SID card, I've discovered it has an adjustable volume! FAB!! I can now balance out the TED and SID music without having to turn TED music down to virtually nothing! Hurrah!!