From: Groepaz (groepaz_at_gmx.net)
Date: 2000-01-20 21:48:01
HyhO! ...
> I guess the IDE64-harddisk controller will work fine then. It runs with an
> expanded basic, that accept standard kernel-calls on unit 12.
Thats the reason for starting with a kernal-'driver' actually... it will just
work
fine with anything out there, it will nicely make use of the speeddos i have
(*G*)
and also have a load() and loadexec() thing that works with eg the actionreplay
fastloader. (are there corrosponding 'standard' functions for loading and/or
running another executeable?)
> It should even be possible to read/write more than one file at a time:
> Just remember the file handle used in the last kernal call. On the next
> write or read, check if the file handle is the same, if not, use CHKOUT to
> switch to the other file handle (channel). The limitation for seek seems
> to be real, however...
well, my knowledge in that particular question is a bit rusty, but as far as
i can remember its only possible to have more than one file open for READING,
but only one for write... however, it'll handle the kernal-file-id's like you
say ofcoz when dealing with different files...
however, seeking WILL also be supported by the kernal-driver, but will perform
awfully bad ofcoz (only way to seek would be to read sequentially from the
start,
not quite cool performance if you fseek(-1,...) in a loop ;=P).
there will be, however, a somewhat 'generic' driver for floppy-drives though,
that
will support real seeking via direkt disc-access.
> Maybe you could use the forward slash or accept it as well. Forward
> slashes are more portable than backslashes.
good idea... wasn't aware of that. well... actually, did you ever see a
backslash
on a c64 ? :=P (it was a typo of mine last time, its 8:/path/file.ext ofcoz ;=))
> lseek is not there, because I don't know of any drive that supports it. If
> you find a way to support it, adding a prototype (and the corresponding
> ANSI C function fseek) is no problem.
just fine with me then ;=)
> The low level functions should handle three file descriptors without any
> further action:
>
> 0 stdin
> 1 stdout
> 2 stderr
ehrm... /me confused =) ... do you mean that first descriptor my open() returns
should be 3 and whenever my read/write routines are called with descriptors 0-2
as parameters they should simply map the call to stdin etc ? IF so, what is the
standard way to SET what IS the, eg, stdin ?! (what c-function ? or should the
OS somehow define this?)
> With this in mind, the current behaviour of printf() makes sense: It
> writes to stdout which is mapped to the file handle with the value one.
well.... ehrm... yes it MAKES some kind of sence, if you would consider the cbm
kernal calls beeing standard C-style i/o functions. but however, in real life
this behaviour won't make sence, even less with a filesystem like the one i
am doing ;=P ($ffd2 is actually one of the low-level routines of the kernal
driver ... and because of that, the 'user' wouldnt be supposed to call this
one directly) for practical use it would make much more sence if you'd use a
"screen-only" kernal call for printf() - if someone wanted to specifically
write to a file, he would use fprintf() anyway ;=P (and your fprintf calls
write doesnt it?) - it would obviously have the backdraw that printf() could no
more me mapped to a file (by defining a file as stdout) but if you WANTED to do
that, it would mean that printf had to call my filesystem and pass its data
through it... making screenoutput via printf unacceptable slow.
> It should even be possible to close or reopen the first three file
> descriptors, so the best way is probably to open them using the normal
> kernal calls at program start.
now this sentence confuses me again... so CBM_KERNAL file-descriptors 0-2 ????
(nonononono that dont make sence ;=P)
> While all this needs some special handling in the low level routines, it
> is very portable, because this is the way, it is defined by the C standard
> (the C standard does not define the low level functions open/close/read/
> write, but the high level functions like fprintf. But it makes sense to
> mirror the behaviour of the high level functions in the low level ones,
> and it is common use).
yes, i am doing the same.... i want all the open/read/close etc bla stuff
to work just it does on the c-compiler(s) i am used to ;=P its not *that*
much special handling actually, most annoying issues are related to string
parsing/conversion atm =)
> o65 is a good solution for a relocatable executable format. It is not a
> very good solution for an object file format for a crosscompiler or
> crossassembler.
>
> The format is quite simple. This is an advantage for the loader (which
> runs on a 6502 machine). On the other side, the simplicity means there is
> no way to do the more complex things that would be possible on the PC when
> using it as an object file format for a crossdevelopment tool. Examples
> for such an additional features would be support for more segments (you
> need this on machines with two non-adjacent ROMs), or debug information.
>
> So yes, o65 would be a good candidate for what you are planning to do.
cool... is there some good specs on this around somewhere? =P
> I'm looking forward to it! Maybe you can send me the diffs so I can verify
> that they are working with the current development version, and we can
> talk about any open issues. This is only a suggestion, of course.
well... atm the whole thing looks like that all functions have a fs_ prefix and
i just #include all the .c and .h files in my test-program... i still have to
split the files into smaller ones and compile it all into a library, but the
way its now is somewhat easier to handle for me atm ;) I dont think it'll
cause any probs with further versions of the compiler anyway... i dont use any
fancy C tricks (hate that shit ;P) and try to reduce complexity where i can.
sneak-peaks into the code will be available as soon as i am satisfied with the
appearance of the code. (code is art you know :P)
> I have some specification on the 1571 (that I found on the Internet), that even includes specification on the build-in MFM-controller. A driver to read PC-disks in 1571 and 1581 can be made.
>
in electronic format? gimme! :=P
> > Does this mean that every program that is compiled with cc65, will have
> the drivers build-in? Wouldn't the best thing be, the drivers as a part of
> the Operating System?
>
> This is true for all features that are not supported by a standard
> machine. If the software that is running as an operating system does not
> have a specific feature, every program generated by cc65 that wants to use
> the feature must have code linked in to support it.
>
> On the other side, libraries for other operating systems (remember that
> cc65 is not C64 specific) do not need the additional code. One example is
> the support for ACE (which has been dropped some time ago): Since ACE has
> a very C like file interface and did support a lot of CMD equipment in the
> kernel, the file I/O routines needed for cc65 were very small. (This was
> the reason why the first implementation of file I/O was for ACE: It was
> very easy to do, and I'm a lazy person:-). Most of the file I/O routines
> were just wrappers that stored registers in specific locations, and called
> an ACE function.
>
exactly.... there will be a few #defines though to be able to recompile the
filesystem for a specific situation (eg if you only want one drive and just
kernal calls a whole lot of the code is redundant and can be left out)
i would *LOVE* to support LOADABLE device drivers so one wouldnt need to
recompile
everything for every little change of conditions... but i honestly dont
know how i could do this using cc65.... any ideas?
> I was just sitting down to write file i/o when I heard about your posting
> to the list. You sound to be much farther along than I. The question now
> is what can I do to help? Either I could offer my help to you or announce
> that I will work on something else. I have a lot of experience with assembly
> coding but I am rusty in C and not very familiar with cc65. I'm pretty
> good at optimizing and have a good understanding of math, I could probably
> write a fast loader if I had to but I've only written a 32 cycle fast transfer
> routine (2 wire) which doesn't do anything practical.
well... basically, once the filesystem itself is completed, cleaned and most
important the api (the backend ofcoz :P) is documented everyone could start
adding specific drivers (think about a driver that supports seeking on a 1581!
or one that maps a filesystem to a REU! :P)
at this momemt, all i need is info on different types of drives... eg:
- how does the directory (read via "$" file) exactly look like? any differences
to a 1541?
- any differences to 1541 with accessing the error/cmd channel?
- same for the direkt-access channels
- any additional dos commands (all i know is "H:discname,id" for renaming a disk
using action-replay) - the filesys will support them if possible
- whats the dir-track on the disc? how is the layout different to a 1541 disc?
- whats the disc layout? (how much tracks,sectors per track)
- how *exactly* does changing directories and partitions work? (give me examples
in cbm-basic ;=P)
- anything else ;=)
ok.... so far so good =P
oh, one thing... how could i have an initialized list of strings? define it
in .byte as asm ? mmmpf.... C w/o initialized structs somewhat lacks
functionality ;(
gpz
--
........................................................
/^\
\ /
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:35 CET