Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GEOS question - I am about to go insane

0 views
Skip to first unread message

Sean Huxter

unread,
Jun 21, 2009, 4:34:05 PM6/21/09
to
So I've been working on this GEOS game project since January.

I'm developing it on the 128 (in VICE 128) and I occasionally test it on the
C64 version of GEOS (using VICE 64).

I've spent a lot of time developing a save-game option that stores the game
progress as well as the various Options in the FileHeader.

This works perfectly on the 128.

But it completely fails on teh C64.

Is there any reason this might be happening?

I even made sure I was using InitForIO before using PutBlock to write the
header back to disk, and DoneWithIO after, like the GEOS Reference Guide
says I should.

This only locks up the computer.

I've tried other things, like the simpler IO_Out/IO_In that directly alters
memory location 1.

Nothing works. But it all works fine with the 128.

Ugh... I put in a lot of time writing the save routine, and I'd hate to ship
without it, but I'm about to give up.

Anyone have ANY ideas what will make this work on a 64 in GEOS 2.0 when it
is already working perfectly on GEOS 128?

Sean.


Greg King

unread,
Jun 24, 2009, 12:52:05 PM6/24/09
to
"Sean Huxter" wrote...
> So, I've been working on this GEOS game project since January.
> I'm developing it on the 128 (in VICE 128), and I occasionally test it

> on the C64 version of GEOS (using VICE 64).
>
> I've spent a lot of time developing a save-game option that stores the
> game progress, as well as the various Options, in the fileHeader.
> It works perfectly on the 128. But, it completely fails on the C64!
> Is there any reason that it might be happening?

>
> I even made sure I was using InitForIO before using PutBlock to write the
> header back to disk, and DoneWithIO after, like the GEOS Reference Guide
> says I should. That only locks up the computer. I've tried other

> things, like the simpler IO_Out/IO_In that directly alters memory
> location 1. Nothing works. But, it all works fine with the 128.
>
> Ugh! I put in a lot of time writing the save routine, and I'd hate
> to ship without it. But, I'm about to give up.
> Does anyone have ANY ideas what will make this work on a 64, in GEOS 2.0,
> when it already is working perfectly on GEOS 128?

I don't see where the Guide tells us to use InitForIO and DoneWithIO with
PutBlock. PutBlock, itself, calls them.

So -- simply use PutBlock directly.

Greg King

unread,
Jun 30, 2009, 6:57:15 AM6/30/09
to
"Sean Huxter" wrote...
> So, I've been working on this GEOS game project since January.
> I'm developing it on the 128 (in VICE 128), and I occasionally test it

> on the C64 version of GEOS (using VICE 64).
>
> I've spent a lot of time developing a save-game option that stores the
> game progress, as well as the various Options, in the fileHeader.
> It works perfectly on the 128. But, it completely fails on the C64!
> Is there any reason that it might be happening?

>
> I even made sure I was using InitForIO before using PutBlock to write the
> header back to disk, and DoneWithIO after, like the GEOS Reference Guide
> says I should. That only locks up the computer. I've tried other

> things, like the simpler IO_Out/IO_In that directly alters memory
> location 1. Nothing works. But, it all works fine with the 128.
>
> Ugh! I put in a lot of time writing the save routine, and I'd hate
> to ship without it. But, I'm about to give up.
> Does anyone have ANY ideas what will make this work on a 64, in GEOS 2.0,
> when it already is working perfectly on GEOS 128?

Your game is a Desk Accessory, isn't it? A weak memory popped into the
back of my mind: I think that 128-GEOS uses backRAM instead of a
swap-file.

64-GEOS uses the fileHeader buffer to create the swap-file.
Therefore, you probably modified the transient header.

You need to reload the DA's header.

Sean Huxter

unread,
Jul 2, 2009, 9:06:00 AM7/2/09
to

"Greg King" <greg....@verizon.net> wrote in message
news:fcm2m.2082$NF6....@nwrddc02.gnilink.net...


Well I tried that, that is I loaded r9 with dirEntryBuf and did a jsr
GetFHDrInfo just as the DA starts.

But it still didn't allow any saving using PutBlock on the 64.

I hope I don't have to do this every time I use PutBlock because I store
valid data in there that changes during the running of the DA, and then I
save it out. Having to laod the FileHdr every time will overwrite the
fileHeader block, requiring me to create a second block to store things, and
a copy of that data to fileHeader AFTER I reload the fileHdr, and before I
do a PutBlock.

I really hoped that would work. As it is, I'm still stuck with a game that
saves its data on GEOS 128, but not GEOS 64.

Thanks, though. I appreciate the memory. It could be I'm just doing it wrong
even with your advice.

Sean.


Greg King

unread,
Jul 4, 2009, 12:01:55 AM7/4/09
to
"Sean Huxter" wrote...
>
> "Greg King" wrote...

> >
> > Your game is a Desk Accessory, isn't it? A weak memory popped into the
> > back of my mind: I think that 128-GEOS uses backRAM instead of a
> > swap-file.
> >
> > 64-GEOS uses the fileHeader buffer to create the swap-file.
> > Therefore, you probably modified the transient header.
> >
> > You need to reload the DA's header.
>
> Well, I tried that; that is, I loaded r9 with dirEntryBuf,

> and did a jsr GetFHDrInfo just as the DA starts.
> But, it still didn't allow any saving using PutBlock on the 64.

Darn! I had hoped that it would be just that easy -- but, no such luck.
"dirEntryBuf" is like fileHeader; at the start, it describes the Swap File.
So, you still wrote the transient header! :-(

You must "back up" by one or two steps (before you can get to the right
header).

2. Use FindFile to get your DA's directory entry. But, that would mean
that the player must not rename the accessory! If you want to allow
renaming, then ...

1. You must start with a call to FindFTypes (using the DA's permanent
name), in order to learn what the DA's current file-name is. [Are you
beginning to feel that it is a lot of extra work to do something that seems
like a good idea? ;-) ]

>
> I hope I don't have to do this every time I use PutBlock, because I store
> valid data in there that changes during the running of the DA; and then,
> I save it out. Having to load the FileHdr every time will overwrite the


> fileHeader block, requiring me to create a second block to store things,

> and moving a copy of that data to fileHeader AFTER I reload the fileHdr,


> and before I do a PutBlock.

As far as I can see, fileHeader is munged only when the Swap File is
written. That happens only once -- before the DA starts to run. So, you
will need to retrieve the DA's header only once. After that, your code can
"poke" and PutBlock, as often as it wants.

Sean Huxter

unread,
Jul 4, 2009, 7:20:37 AM7/4/09
to

"Greg King" <greg....@verizon.net> wrote in message
news:TuA3m.731$P5....@nwrddc02.gnilink.net...

Thanks again, Greg. I can see if this is the problem that I simply
over-wrote the swap-file which is of no help.

So let me get this straight in my head before I actually attempt it:

1) During DAStart (the first routine my DA runs when the DA is executed) I
should first use "FindFile" (with the filename pointed to by r6) and that
will get a new dirEntryBuf, (rather than using the one that existed before,
which was for the Swap File)

2) Then I should point r4 to the NEW dirEntryBuf, which now should refer to
my DA instead

3) Then I should GetFHdrInfo again (which will now load up the header block
of my DA

4) After which point I can simply save the Header using PutBlock as often as
I like?

I hope this is all right. This whole problem bothers me to no end, having it
work flawlessly in GEOS 128 but not GEOS.

Is this outlined anywhere in the GEOS Programmer's Reference, because I
can't find it flipping through looking for any references to this problem.

Sean.


Sean Huxter

unread,
Jul 4, 2009, 9:35:44 AM7/4/09
to

"Greg King" <greg....@verizon.net> wrote in message
news:TuA3m.731$P5....@nwrddc02.gnilink.net...

Well, Allelujah, Greg.

It worked.

I went the easy route for now, just using FindFile on the filename. But I
like the elegance (even if I dislike the complexity) of using FindFTypes to
ensure that this will work even if someone changes the filename. And while
that is unlikely, it IS possible, and since it's not all THAT difficult, I'm
going to go the route of using the Permanent filename.

Thanks for your help! I'll make sure I credit you for your assistance either
in the DA Info screen itself, or the web-site.

Sean.


Greg King

unread,
Jul 4, 2009, 6:02:48 PM7/4/09
to
"Sean Huxter" wrote...

>
> Is this outlined anywhere in the GEOS Programmer's Reference,
> because I can't find it flipping through looking for any references
> to this problem.

I haven't seen any documents about it. My old memory came from a comment
that a Berkeley Softworks employee left in the GEOS forum on the old
QuantumLink online service. My other knowledge about Desk Accessories and
Swap Files came from dissassembling parts of GEOS, and using VICE's monitor
to see what happens at various times.

0 new messages