Sunday, October 22, 2006

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


Anonymous said...

Use LDX $AE instead of LDX #8 and it will use the device the game was loaded from.


Mike said...

Yep I would....except by the time this runs, Zero page is well fried :)

I intend to have the loader save the current device number somewhere safe for the game to pick up later.

Anonymous said...

I pair-coded a game with a friend who moved abroad half way through the project, yet managed to keep things going regardless. VoIP (skype), desktop sharing and virtual whiteboards is the next best thing to actually meeting in person.

Seriously, it works =)


Anonymous said...

No, don't tell me: didn't you enjoyed the long chat? :D

Anonymous said...


Chicken said...

If I remember correctly that turbo only loads faster (as do pretty much all software turbos on plus/4). Any other disk operation will be executed at normal speed. Doesn't really matter because it's probably just one block anyway.

I think direct writing to the disk is more elegant but I figure this "dirty" (scratch/save) hack will save you a few bytes. Though, it's a bit slower. But after making the Top10 one probably needs some rest anyway ;)

Have you decided how many entries there will be? Top10? And just initals (which I think is good)? So what happens if you have exactly the same score as let's say rank #10? First in, first out?

Mike said...

Scartch/Save is the safest way really due to the 1541 SAVE"@0:blag" bug. Either that or writng directly to a track/sector, which I dont want to do incase the track is corrupted. You can always write the file again, but if a track becomes unreadable...its a bugger.

Yes, there will be a pause when saving the highscores, but thats not going to be THAT often - not really.

either 5 or 10 entries, haven't decided.

if you are less than or equal to an entry, you go under it. So if you equal the bottom one, you dont get on the table.

Chicken said...

How big are the chances that THAT track/sector gets corrupted (and not a different one)? Especially on an emulator? ;)

I do get your point, though. I guess I see it more from a design point of view. When you write to a certain track/sector (which can still be an actual file, though yes, it's always at the same location) you can design a nice directory for the game and hiscore saving is not messing it up.

Well, I can do that when the source is out ;)

Mike said...

with the 4bytes of memory left, you can do whatever you want :)

Chicken said...

Hehe ;)

I got a 256kb extension :)

That turbo is 1541 only. So without it, there's some memory left for other things. And if that memory map is still valid, there are a few unused bytes.

Which zeropages (and up) addresses are you using?

What about the tape buffer? Or is that off limits due to a tape version? ;)

Mike said...

What I really want is a SID card with a 256k or larger memory expansion - THAT would be nice.

The Turbo TNT is making is 1541,1571 & 1581. The memory map has changed a little. And although theres memory free just now, I'm trying to keep it for a couple of "surprises" :)

Zero page is up to 193 just now. But as I start to finish up, I'll move more common variables down into ZPage to help keep the speed up.

Yeah, spotted a few places in low memory that I could use. I'm trying not to so that unknown systems (and possible future systems) will still work. For example, if you wrote a RAM disk for your memory expansion and loaded the whole lot onto the disk, you would have just under 2K to do this. Or, if you wanted to "patch" the game to make use of memory expansion (or a new IDE device), then there is a known area thats free to do so.

Chicken said...

TNT is coding a speeder? That's great news :) That wasn't mentioned here before. Luca mentioned some help from TNT but that was about the highscore I thought. That means you don't have to use that unreliable one anymore :)

Some areas are "safe" like the function key ram. That's usually not used by anything and you have probably redefined the f-keys to chr$(132+x)... So there's some ram left, too.

$ff40 above is almost never used. That's where I usually inserted my 1551 loaders when I modified 1541only games/demos.

The 256kb extension I have is the "...HANNES.../SOLDER" one. There are a few demos using this (e.g. Bionic's DREAM WORLD and if you are interested, I can dig up the docs. It's supported in YAPE, too. Not much code needed to make use of it :) Though, a dedicated version using the "blend in" ram features would be nice because there's more to this expansion than being just a ram disk.

Way past my bed time :(


Mike said...

I don't want to use the RAM since the SID card I think is much more important. But others can if they like - once the source is released feel free to do a RAM expanded version :)

I'll be using all the memory up to $fffb quite probably.

If there was a SID+Memory card, then I'd get more interested in it.

Anonymous said...

1541/1571 turbo is 173 bytes after installation, but that doesn't include save. I suspect that to take another 40-50 bytes, still keeping it below one page. Couple more bytes and the same code will talk to 1581 too, although the code in drive is somewhat different.

Oh, the speed? Xeo3 teaser takes 2:35 to load without any speeder in YAPE, with my loader it's 0:54. Only ~1 KB per second, but it keeps the screen on. How much data there is to load per level?


Chicken said...

that's pretty tight code :) I think speed doesn't matter that much: Most of us grew up with a datasette, we are used to long loading times. It's more important that it works. And if it leaves the screen on and Mike invents a method of creating free bytes out of air he can do some on screen action while loading.

It would be interesting to read about that in detail and maybe ppl will start making their games/demos 1581 compatible. And actually, hearing about that makes me want my 1581 back now :)

Anonymous said...

All sources will be released with the game. With save routine added it's now 212 bytes, but it doesn't yet do additional init handshake which allows interrupts on drive side (read: automatic write buffer flushing with 1581).

FLoad3.2 uses memory $055d-$07d7, my loader/saver uses $055d-$063b. That leaves some space for eye candy while loading if loader is detected. It's up to Mike if he wants to use it.


Anonymous said...

I forgot that c1541 (D64 tool which comes with VICE) doesn't use interleave at all! That didn't seem to matter with normal load tho.

Assuming YAPE uses normal 300 RPM for disk rotation, optimal interleave for my loader is 16. 43 seconds to load XeO3 teaser - that's ~12 seconds for 16 KB.

I suggest using interleave 17 because some drives rotate faster, and that also leaves some cycles for eye candy.