From: Groepaz (groepaz_at_gmx.net)
Date: 1999-07-10 17:57:20
> > mmmh, will there be windoze binaries as well? still no linux here, bah
>
> I've created binaries for all supported platforms as usual.
ok... sorry if that question sounded somewhat ignorant =)
> No, there's no low level file support. But then, there's also no low level
> file support if you write your stuff in assembler, so at least you don't loose
> anything:-)
true... however, i wanna make the code as portable as possible (that is,
i want the thing to be easily portable to PC using the PLAYSID-engine)
so
beeing able to use open/write/close etc would be very nice.
> More seriously: This topic is not quite as easy as it looks on the first
> glance. It seems that there is no easy way to support files in a standard
> conform way. One reason is, that you may open a file for reading and writing
> in C, and this is not possible with the CBM disk drives, at least not with
> sequential files. The second reason is that things like fseek() must be
> implemented by closing and reopening the file, then skipping all the bytes
> >from the beginning (things like SEEK_END are even more ugly). This makes the
> routine almost useless.
>
> An alternative would be to use relative files, but these are far more complex
> to handle, and are not very well supported by many software tools available.
> In addition, relative files may not be used for some type of data: If you
> write a program in C that outputs a program file (assembler for example), this
> program file may not go into a relative file, otherwise it won't be executed
> by the kernal.
>
> So, until I have a good idea how to handle this problem, the easiest way is
> probably to write a short specialized assembler that reads or writes your data
> files. If you write your programs in assembler you would also need such a
> routine, so just make it C callable and use it from the high level code.
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.
SO: don't say it's impossible... there's no such thing 'impossible' in
c64 world 8=)
the ONLY drawback to this all would be, that it'll probably only work
for
15xx drives (and compatible oceanic etc), but however, it'll still serve
90% or sth of all users very well
> Well, some people (including me) seem to have a different opinion about what
> is annoying and what isn't.
well, sure.. no doubt =) i still think C is annyoing by itself and ASM
rulez the world 8=) hehe, at least i thought that until i started coding
C on PSX =)
> In fact, the original compiler had a #asm
> directive that worked the way you described.
yeah, i know (thats why i mentioned this actually) ... actually i have
also
worked on a 65xx version of some other small-c version, but i cancelled
that
when i saw yours 8=)
> The reason for replacing it were:
>
> 1. #asm is in no way standard conform. C++ specifies an asm() keyword like
> the one used in cc65.
oh well.... rulez are made to break them =)
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
#define u_char unsigned char
etc pp. ?! this would make the code MUCH more portable and also would
let
you compile a whole lot of sources that are around. (besides the u_char
thing is
quite common anyway).
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)
> 2. asm() is more flexible, since it allows parametrized assembly instructions
> similar to what gcc implements.
well, yes and no =) i know asm() rox for small macros and stuff (i use
it
like hell in gcc) but it really sux for some other stuff.
> 3. #asm was implemented as a preprocessor directive (like all others
> starting with #). Since the parser works with a two token lookahead, an
> absolutely ugly hack was needed to implement #asm (since it is executed
> by the preprocessor, however, it must be in sync with the parser, so that
> the emitted code gets in the right place).
mmmh, "ugly" hack ? na... GOTO is ugly =))
> Apart from that, #asm (and asm()) was never thought to write anything more
> than two lines of assembly. ca65 is a full featured macro assembler, so why
> not use it?
well, i told you.... i like having both the asm library code AND the
test-code
that calls it in ONE source file and beeing able to compile (and run) it
with
just one command-line command... 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.
> Admitted, there is no "dummy" implementation of a C callable assembler
> function. Instead, there are lots of "real" assembly functions called by the C
> code with full source code. The lib/ subdirectory contains all sorts of
> functions that are used in a C program. Examples are strcat(), atol(),
> isdigit()... Just have a look at the supplied sources.
ok, i will try... if i understand that, i will probably write that
'dummy'
thingy myself for everyone (and me ofcoz =) to use it as a template...
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)
ok dudes...
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