From: Groepaz (groepaz_at_gmx.net)
Date: 1999-07-11 15:18:25
Ullrich von Bassewitz wrote:
>
> > 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:-)
well honestly... after over 15 years hacking the c64, i guess there's
not
much left on that topic that i dont understand 8=)
i will just leech the latest compiler now and then have a look how much
work it'll be to write something like that =)
> 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 */
aaaah, ok... sorry then, i thought the signed/unsigned keyword isnt
available
at all (that is, i ALWAYS declare my stuff as signed/unsigned)
> > 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.
yeah... ofcoz i ment int... and well, i have read quite some stuff about
C
lately, and i remember that there were certain problems with int and it
should be replaced by some other datatype. i think the major problem
was,
that the amount of bits in an int is not defined (in opossite to
short/long)
so you may get some probs when porting the code.
> > 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.
yeah... thats what i ment =)
>
> > 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.
ok.... seems to work for me then =) i need a custom conio anyway
(keyboard-
scanner that can detect several keys pressed at once) so guess that wont
be
a problem...
whatever.... gotta play around with the new compiler now i guess =)
regards
gpz/hit
--
........................................................
/^\
\ /
ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL
/ \
........................................................
.--.--.--.----..--.--.--.-----.----.
C=64 / / / / . / . . / . / . /\
/ / /__/ /__/ / / / / / / / /
PC / / / /\_/ / / / __ / / / /
/ / / / / // / / / / / / / /
PSX / / / / / // / / / / / / / /
/__/__/__/__/ //__/__/__/_____/__/__/ /
\__\__\__\__\/ \__\__\__\_____\__\__\/ Groepaz
........................................................
.. http://fly.to/hitmen-c64 ............................
..... the hitmen c64 home page .........................
.. http://www.hitmen-console.org .......................
..... hitmen psx section ...............................
.. http://start.at/hitnav64 ............................
..... biggest c64 link collection around ...............
.. http://fly.to/hitmen-groepaz ........................
..... my little personal page ..........................
........................................................
----------------------------------------------------------------------
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