From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 1999-07-10 22:33:45
> well.... i dont pretty much agree with you... there is actually NO
> difference
> in using PRG, SEQ, USR, REL or whatever files, since direct raw access
> worx
> with all of these in the same way. also lseek() and stuff aint a real
> problem
> since we could use a thing simelar to what 'crackers' refer to as IFFL.
> this
> would probably work without having to seek through the whole file, since
> it'll
> work on a 254-bytes block basis, and also the last readen block could be
> buffered (in the drive). i know that would still cause some problems if
> you
> would be lseek()'ing like a mad dog, but it'll still work (however)
> the other problem (opening several files at once for reading and
> writing) may
> be a harder thing to solve, but keeping the above mentioned technique in
> mind,
> it will still be possible with a clever drive-code.
It seems you know more about this than I. Maybe you can elaborate this a bit,
so we can find a possible technical solution. If we have one, the only thing
left is to find someone who writes the code:-)
> btw, while we are at standards.... your chars that are unsigned by
> default break
> the rulez by far more than that non-standard directive would =) whats
> wrong with having a signed/unsigned keyword, and then just doing a
The C standard says nothing about the signedness of chars. Both signed and
unsigned chars are allowed. Traditionally, PC compilers tend to use signed
chars, while Unix compilers often have unsigned chars. The choice to use
unsigned characters for cc65 does not only give better code, but it is in full
compliance with the ISO C standard. Programs that depend on the signedness of
chars are non portable.
If you need a specific character type (signed or unsigned), declare it as
such. If you don't specify the signedness explicitly, the compiler is free to
choose.
signed char sc; /* A signed character */
unsigned char uc; /* An unsigned character */
char c; /* Signedness depends on the implementation */
> Also i noticed that you mention the INT datatype in
> quite some places of the docs, and since you seem to be one of the ppl
> that like to "follow the rulez" i just wanted to point out that INT is
> by far
> not standard, and lots of literature (ehrm orthograpy sux =) advices
> to
> no more use it, at least not for portable code (use short/u_short
> instead
> for example)
I'm not sure what you're refering to. I don't remember mentioning a datatype
named INT in the docs, and a
grep INT *
in the doc directory shows no match. If you're talking about int (as opposed
to INT), this is a standard datatype with well defined semantics. I don't see
any problems with portability when using ints.
> however, i have noticed there is now
> also a
> MAKE-utility for cc65, so i guess that should be no prob now doing that
> with
> more sourcefiles.
There is no make utility (you may want to consider GNU make if you need one),
but the cl65 compile and link utility allows the translation of a multi-file
project with one command.
> oh, another quick question i was wondering about.... my editor needs to
> bank out ALL kernal/basic rom and also need access to ram under i/o at
> certain times... will the runtime library work with that? and, will i
> need to rewrite lots of the other libs to make them work independent
> from the roms?! or would it just compile and WORK? 8=) (that'll be very
> nice really hehe)
The compiler generated code, the runtime library and the standard C library do
not depend on any ROM code. The startup code uses kernal calls, as well as the
conio module. Most other C64 specific routines do not call the kernal. The
BASIC ROM is never used, in fact, it's banked out in the standard
configuration.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET