Prev: ebay: 2x 1541, 1541 w/XU1541, 1750, GEOS PRG, 1351, C64c w/Box, Joystick, SFD-1001, VIC, 1571, 2x 64 w/Box
Next: 1541 Ultimate 6pin expansion header ... how does it work?
From: Harry Potter on 12 Apr 2008 20:03
On Apr 12, 7:18 pm, Bill Buckels <bbuck...(a)escape.ca> wrote:
> Why did you rush this Harry?
>

I completed the documentation and uploaded the changes. Sorry about
the inconvenience.
From: Anssi Saari on 14 Apr 2008 08:06
Bill Buckels <bbuckels(a)escape.ca> writes:

> Anyway, you probably have a pretty good handle on CC65 from what I see
> so tell me this... what kind of useful programs do you think either of
> us could write for the C64?
>
> I don't see much needed.

How about a CRC checker for files? I don't know if there are any good
ones.

Explanation: say I have some files I want to put on a C64 floppy and
want to make sure transfer worked correctly, So I include a file with
CRC32 checksums, maybe in the common sfv file format. And then after
transferring the stuff over with my new XU1541 cable, I can _easily_
check the files on the C64/C128/whatever. Creating sfv files on the
C64 side might be useful too.

I was thinking I could maybe mangle Pasi Ojala's Gunzip to do this,
since it already has the CRC checking code and disk speeder.

I found two programs at Zimmers.net programs already, called crc32 and
pcrc. However, these are not very poiished.
From: BruceMcF on 14 Apr 2008 10:45
On Apr 12, 7:58 pm, Harry Potter <maspethro...(a)aol.com> wrote:
> I once started a Sci-Fi text adventure for the C64 called Smir 3
> Episode 1 under cc65, but at the end of Chapter 1, it cost about 20k
> executable size, and I discontinued it. I started working on C-Boost
> for DOS and Win32, which forms templates for C source code. Maybe a
> C64/128 version could do the same for C64/128 C code (and BASIC
> code). I thought of a SMB3 graphic adventure for the C128, but I need
> a better C compiler/assembler than cc65.

In the classical text adventures, the engine is a binary executable
and the engine works with a data file, normally in plain text with
token keywords for ease of re-use.

So if Chapter 1 in an integrated approach takes 20K, the strategy
would be to split that into runtime and scenario. That establishes the
size of the runtime engine which then establishes where to locate the
base of the data area. Then a little tool auxilliary to convert a text
file to a PRG file based at the data file, and anything mass store
that can handle a ,8,1 load of a PRG file can download each chapter as
required. Then Chapters 2 and on are simply additional scenarios (plus
whatever tinkering you need to do with the runtime to take into
account options you had not needed in Chapter 1).

From: Harry Potter on 19 Apr 2008 06:49
On Apr 14, 10:45 am, BruceMcF <agil...(a)netscape.net> wrote:
> In the classical text adventures, the engine is a binary executable
> and the engine works with a data file, normally in plain text with
> token keywords for ease of re-use.
>
> So if Chapter 1 in an integrated approach takes 20K, the strategy
> would be to split that into runtime and scenario. That establishes the
> size of the runtime engine which then establishes where to locate the
> base of the data area. Then a little tool auxilliary to convert a text
> file to a PRG file based at the data file, and anything mass store
> that can handle a ,8,1 load of a PRG file can download each chapter as
> required. Then Chapters 2 and on are simply additional scenarios (plus
> whatever tinkering you need to do with the runtime to take into
> account options you had not needed in Chapter 1).

I think the separation is a good idea. Make it chapter-based.
Separate each chapter into its own executable. Make a data segment in
high memory to only include the player struct and information. Have
a stub to delegate between chapters. Thank you. :)
From: BruceMcF on 19 Apr 2008 11:36
On Apr 19, 6:49 am, Harry Potter <maspethro...(a)aol.com> wrote:
> On Apr 14, 10:45 am, BruceMcF <agil...(a)netscape.net> wrote:
>
> > In the classical text adventures, the engine is a binary executable
> > and the engine works with a data file, normally in plain text with
> > token keywords for ease of re-use.
>
> > So if Chapter 1 in an integrated approach takes 20K, the strategy
> > would be to split that into runtime and scenario. That establishes the
> > size of the runtime engine which then establishes where to locate the
> > base of the data area. Then a little tool auxilliary to convert a text
> > file to a PRG file based at the data file, and anything mass store
> > that can handle a ,8,1 load of a PRG file can download each chapter as
> > required. Then Chapters 2 and on are simply additional scenarios (plus
> > whatever tinkering you need to do with the runtime to take into
> > account options you had not needed in Chapter 1).

> I think the separation is a good idea. Make it chapter-based.
> Separate each chapter into its own executable. Make a data segment in
> high memory to only include the player struct and information. Have
> a stub to delegate between chapters. Thank you. :)

Here's the thing: make the engine in each chapter *the same engine*,
so that it can start in the correct place in the middle of the next
program executable to load the chapter *data* from the next chapter.
That saves the wait to reload the engine when you are moving from one
to the other, but at the same time makes each chapter a free standing
program.
First  |  Prev  | 
Pages: 1 2
Prev: ebay: 2x 1541, 1541 w/XU1541, 1750, GEOS PRG, 1351, C64c w/Box, Joystick, SFD-1001, VIC, 1571, 2x 64 w/Box
Next: 1541 Ultimate 6pin expansion header ... how does it work?