shadow@pawl.rpi.edu (Deven T. Corzine) (03/19/89)
In article <70@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >Has anybody written a Unix compatible alarm() function on the amiga. For >those not familiar, and to be more specific, its definition is Not that I know of, but it IS one of the functions I intend to write for Amigix. Amigix is a tentative name for the Unix V7-compatible "operating system" environment which will be implemented on top of Exec and alongside AmigaDOS. Initially, Amigix file system calls will be translated to AmigaDOS calls, but I will probably eventually write a filesystem to integrate into the system as well. All BCPL crap will be hidden from the (Amigix) process, handled by a system task which will run as an AmigaDOS process. See the huge thread here on "Unix V7 functionality ..." for more details... This same system task would also coordinate the alarm() function by sending requests to the timer device, and only acting on the one most recently defined by an alarm() call. (and AbortIO on any others, if the timer.device supports it; otherwise simply deallocate and ignore the IO request when it finally returns.) >int alarm(seconds) unsigned seconds; { } Oh, I rather think the definition will be somewhat longer than THAT... :-) >The function sends a signal ( SIGALRM, defined in signal.h and trapped by >(*signal())() ) to the invoking process after the number of seconds indicated >in the argument has elapsed. Unless the signal is caught or ignored, the >signal terminates the process. Signals will also be specially handled under Amigix. >Successive alarm() calls reinitialize the alarm clock. In other words, >alarms are not stacked, and calling alarm() with a zero argument cancels >any pending alarms. Ayup. >Also, the function should return the number of seconds remaining from a >previous alarm request. CheckIO() should work for that, I think. >I actually don't care whether it has been written with Lattice or Manx. >I need it for something I'm working on, but I though it might be a >function which may me of much more general usefulness. Well, I'm writing for Lattice, but I hope to make the code compile and run under either. (for which I'll surely need some help from someone with Aztec...) Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
jesup@cbmvax.UUCP (Randell Jesup) (03/22/89)
In article <SHADOW.89Mar19085542@pawl24.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >In article <70@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > >Has anybody written a Unix compatible alarm() function on the amiga. For > >those not familiar, and to be more specific, its definition is ... >This same system task would also coordinate the alarm() function by >sending requests to the timer device, and only acting on the one most >recently defined by an alarm() call. (and AbortIO on any others, if >the timer.device supports it; otherwise simply deallocate and ignore >the IO request when it finally returns.) NO! NEVER deallocate or reuse an IO request until it has been returned by the device (and yes timer supports abortio, all devices must "support" it, though not all devices will actually try to stop the io in mid-stream.) Normal abort is AbortIO();WaitIO(). > >Also, the function should return the number of seconds remaining from a > >previous alarm request. > >CheckIO() should work for that, I think. CheckIO only tells you whether the request hs finished. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
deven@rpi.edu (Deven Corzine) (03/23/89)
In article <6363@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <SHADOW.89Mar19085542@pawl24.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >>In article <70@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >>>Has anybody written a Unix compatible alarm() function on the amiga. For >>>those not familiar, and to be more specific, its definition is >... >>This same system task would also coordinate the alarm() function by >>sending requests to the timer device, and only acting on the one most >>recently defined by an alarm() call. (and AbortIO on any others, if >>the timer.device supports it; otherwise simply deallocate and ignore >>the IO request when it finally returns.) > NO! NEVER deallocate or reuse an IO request until it has been >returned by the device (and yes timer supports abortio, all devices must >"support" it, though not all devices will actually try to stop the io in >mid-stream.) Normal abort is AbortIO();WaitIO(). I suppose I should have made that more clear. What I meant was the system task would AbortIO() the pending request, and allocate a new one for the new request. When the original request was returned, it would then be deallocated. (That would be caught at the Wait() in the main loop.) I was not suggesting to reuse the IO request. The requests, like most everything else, would be in an Exec list, pending removal when returned from the device. >>>Also, the function should return the number of seconds remaining from a >>>previous alarm request. >> >>CheckIO() should work for that, I think. > CheckIO only tells you whether the request hs finished. True. I suppose you could look at the IOrequest which probably contains the remaining time, but that's not legal, and not nice at all. So, the question is, is there a legal way to find the time remaining on a timer request? AbortIO/WaitIO and THEN check the time fields? Something else? (Preferably something that won't break in the future...) Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
jesup@cbmvax.UUCP (Randell Jesup) (03/24/89)
In article <DEVEN.89Mar22211102@daniel.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: > > CheckIO only tells you whether the request hs finished. > >True. I suppose you could look at the IOrequest which probably >contains the remaining time, but that's not legal, and not nice at >all. So, the question is, is there a legal way to find the time >remaining on a timer request? AbortIO/WaitIO and THEN check the time >fields? Something else? (Preferably something that won't break in >the future...) Remember the time you started the request, and the length, seperately from the IO request itself. To determine how much time is left, ask timer what time it is, and use determine the amount of time remaining. I think timer has an entry for subtracting time values for you. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
deven@pawl.rpi.edu (Deven Corzine) (03/24/89)
In article <6381@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <DEVEN.89Mar22211102@daniel.rpi.edu> shadow@pawl.rpi.edu (Deven Thomas Corzine) writes: >> > CheckIO only tells you whether the request hs finished. >> >>True. I suppose you could look at the IOrequest which probably >>contains the remaining time, but that's not legal, and not nice at >>all. So, the question is, is there a legal way to find the time >>remaining on a timer request? AbortIO/WaitIO and THEN check the time >>fields? Something else? (Preferably something that won't break in >>the future...) > Remember the time you started the request, and the length, seperately >from the IO request itself. To determine how much time is left, ask timer >what time it is, and use determine the amount of time remaining. I think >timer has an entry for subtracting time values for you. Indeed. (I probably would've thought of it sooner or later. :-) Yeah, the timer has time arithmetic functions available... That'll work fine. Will do. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
rsb584@leah.Albany.Edu (Raymond S Brand) (03/25/89)
In article <DEVEN.89Mar22211102@daniel.rpi.edu>, deven@rpi.edu (Deven Corzine) writes: > True. I suppose you could look at the IOrequest which probably > contains the remaining time, but that's not legal, and not nice at > all. So, the question is, is there a legal way to find the time > remaining on a timer request? AbortIO/WaitIO and THEN check the time > fields? Something else? (Preferably something that won't break in > the future...) > > Deven Once you submit a timer request to the timer.device, the time fields of the request are "owned" by the timer.device and are not guarenteed to contain any- thing useful. In fact, the 1.1 and 1.3 autodocs specify that the tr_time field will contain junk when TR_ADDREQUEST returns the message. Fixing-up the time field on an AbortIO could probably be done but that sounds like an enhancement request :-) ------------------------------------------------------------------------- Raymond S. Brand rsbx@beowulf.uucp 3A Pinehurst Ave. rsb584@leah.albany.edu Albany NY 12203 FidoNet 1:7729/255 (518-489-8968) (518)-482-8798 BBS: (518)-489-8968
nichiren@glyph.UUCP (Andy Heffernan) (03/26/89)
In article <DEVEN.89Mar25023341@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) complains: > You still haven't told me much about this; I don't understand how it > works. Sure, I get the general idea, but I need to know exactly how > it all works so I can implement it correctly. I truly hate programs > that run fine but randomly crash the machine when they exit. I want > everything to work smoothly, and for that, I need to know how the Exec > routines operate. I'd prefer not to go digging around in the ROMs > with a disassembler if I can avoid it. Please do. For Randell's sake please walk through some Exec code with a single-stepper (but watch out for critical-section code!) It's really very lovely stuff. > AddTask(task,initialPC,finalPC)... > > Task I understand fine. I take it that AddTask starts off the task by > pushing finalPC on the stack (as a return address for initialPC) along > [etc.] Open the door, get on the floor -- Everybody single-step their code... > Deven > -- > ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- > Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America > ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 > sum... In the immortal words of Socrates: "I drank what?" ...I think. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!nichiren [1222 - 1282] -------------------------------------------------------------------------
deven@pawl.rpi.edu (Deven Corzine) (03/28/89)
In article <0282.AA0282@glyph> nichiren@glyph.UUCP (Andy Heffernan) writes: >In article <DEVEN.89Mar25023341@daniel.pawl.rpi.edu> deven@pawl.rpi.edu (Deven Corzine) complains: >> You still haven't told me much about this; I don't understand how it >> works. Sure, I get the general idea, but I need to know exactly how >> it all works so I can implement it correctly. I truly hate programs >> that run fine but randomly crash the machine when they exit. I want >> everything to work smoothly, and for that, I need to know how the Exec >> routines operate. I'd prefer not to go digging around in the ROMs >> with a disassembler if I can avoid it. >Please do. For Randell's sake please walk through some Exec code >with a single-stepper (but watch out for critical-section code!) >It's really very lovely stuff. Actually, I probably will anyway, for the experience, but the main reason for asking Randell (or anyone else who may care to answer) is that I'm more likely to know what's safe to count on and what's not. I don't want to code based on one version of exec.library, since 1.4 may change it wildly, for all I know, so I'd rather have some assurance of what is supposed to happen, and what may change in later versions of the operating system... and what I can count on. (and to what extent.) Besides, I suspect there may be others that could benefit from a clear explanation of this murky subject [meaning only that it's hard to figure out from the docs (RKM's, etc.)] and seeing as how Randell's been so wonderfully helpful hitherto, and generally explains things fairly well and knows what he's talking about, it seems worthwhile asking. >> AddTask(task,initialPC,finalPC)... >> >> Task I understand fine. I take it that AddTask starts off the task by >> pushing finalPC on the stack (as a return address for initialPC) along >> [etc.] >Open the door, get on the floor -- Everybody single-step their code... Besides, I'd rather not reverse-engineer Exec functions and work on empirical evidence. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
ugkamins@sunybcs.uucp (John Kaminski) (04/09/89)
I subscribe to comp.os.minix, which is about MINIX, a V7 UNIX-like operating system that was originally developed on an IBM-PC then ported to the Atari-ST series of computers. I have received email stating that an Amiga port was underway, and may possibly be available by year's end. MINIX is for the most part source code compatible with many UNIX varieties, of which V7 is the definitive base. The main difference is in the implemen- tation of the interal workings. The "better" difference is that the MINIX "project" was started as a teaching/learning tool on operating systems (much as Pascal was intended to be a teaching programming language) and therefore is distributed with FULL SOURCE CODE for everything EXCEPT the C compiler. For the definitive reference on MINIX consult (search for at a library or go buy) the Prentice-Hall publication Operating Systems: Design And Implementation Andrew S. Tanenbaum ISBN 0-13-637406-9 This includes the source code listing for the MINIX system including all but some of the device drivers (most notably the printer and hard disk drivers). Andy is THE best computer writer I know. Not only does he seem rather knowlegeable (sp?) but he is *EXCELLENT* at expressing what he is writing about.
deven@pawl.rpi.edu (Deven Corzine) (04/10/89)
In article <5121@cs.Buffalo.EDU> ugkamins@sunybcs.uucp (John Kaminski) writes: >I subscribe to comp.os.minix, which is about MINIX, a V7 UNIX-like operating >system that was originally developed on an IBM-PC then ported to the Atari-ST >series of computers. I have received email stating that an Amiga port was >underway, and may possibly be available by year's end. I have heard about this Minix port to the Amiga. I would like to see it, though my personal opinion remains than it could be better implemented under Exec, both because Exec is more dynamic than Unix and Minix are (e.g. doubly-linked lists vs. static-sized tables) and it would save the difficulty of reinventing the wheel as far as writing a scheduler, device drivers, a message-passing system, etc. As a learning tool, however, rewriting the low-level as well is just fine... >MINIX is for the most part source code compatible with many UNIX varieties, >of which V7 is the definitive base. The main difference is in the implemen- >tation of the interal workings. The "better" difference is that the MINIX >"project" was started as a teaching/learning tool on operating systems (much >as Pascal was intended to be a teaching programming language) and therefore >is distributed with FULL SOURCE CODE for everything EXCEPT the C compiler. I am working on writing Amigix, a V7 based environment layered over Exec, which should be reasonably source code compatible with various Unix systems, as is Minix. This project was in fact inspired by Minix and Tanenbaum's book. It is not intended as a learning tool primarly, but as a practical environment and platform for more effective utilization of the Amiga computer. It will (as I mentioned) be significantly different from real Unix in internal implementation, but it will be very similar from the programmer's point of view, and hopefully from the user's as well. I intend to start with the basic Unix V7 system calls as a base, and add SysV/BSD Unix system calls and libraries as seem appropriate/feasible, along with Amiga-specific extensions. One point I should note is that upon full release, I intend to distribute Amigix with full source code and binaries. Exactly how much will be implemented at that point in unclear. I hope to have at least Unix V7 system calls, some SysV/BSD system calls, most of the easier library calls, logical Amiga extensions, a tty driver (probably based on console.device), job control (depends on the tty driver), possibly a curses library (have to see how difficult it looks), *maybe* a file system and a shell, some utilities and a pile of Unix-type filters all written before making a full release complete with source code and documentation. Eventually, I would like to have a file system (if I don't at the first release), integrated networking software and some other goodies. Preliminary releases will likely be an alpha release with the straight V7 syscalls, beta with more syscalls and libraries (maybe tty driver and job control), gamma with most everything but the file system and some utilities, and perhaps a delta release with the file system, shells and utilities. Such preliminary releases will NOT be redistributable, and may or may not be accompanied with source or documentation. Distribution will start very small for the the alpha release, (probably copies to Randell Jesup, maybe a couple others at CATS, Peter Da Silva, and 3-4 others, assuming they are interested) to maybe a dozen more for the beta release, perhaps a couple dozen for the gamma release, and if there is a delta release, it will probably be distributed to as many as 100-150 people to help ferret out bugs and test it all out. This, of course, presupposes that there will actually be that much interest in the project, and people actually want to have such a thing. Maybe people won't care. I'll just have to see how it goes. In the (unlikely) event that I simply give up on the project, I will release everything developed to that point, source, binary and documentation, such that others may attempt to work on it. However, I don't expect to give up on it. I may, however, be delayed for unknown amounts of time by mundane things such as day-to-day life. >For the definitive reference on MINIX consult (search for at a library or go >buy) the Prentice-Hall publication >Operating Systems: Design And Implementation >Andrew S. Tanenbaum >ISBN 0-13-637406-9 >This includes the source code listing for the MINIX system including all but >some of the device drivers (most notably the printer and hard disk >drivers). >Andy is THE best computer writer I know. Not only does he seem rather >knowlegeable (sp?) but he is *EXCELLENT* at expressing what he is writing >about. I have a copy of this book (borrowed, actually) and I also highly recommend it; it is well written and contains lots of useful information which is practical along with the straight theory. An excellent book. Randell, Peter, CATS, et al. -- (you know who you are... :-) If you are interested in obtaining preliminary releases for this project, should they be forthcoming, please send me Email and tell me so. In fact, anyone is welcome to request preliminary distributions, but I make no guarantees, and do not wish preliminary releases to get out of hand. If you're interested, tell me who you are, an Email address that works, (numeric address also if on the Internet) and why I should include you. :-) Keep in mind I will be willing to have larger distributions for the later releases, but permission for redistribution of preliminary releases will be explicitly denied. The first full release will be distributed with source and documentation as well as binaries, and will be freely redistributable. Actual size of preliminary distributions will be mainly be determined by actual interest expressed and arbitrary judgements by myself. I reserve the right to do whatever I feel like. :-) One unknown is whether I will even attempt to write a C compiler for Amigix... all I can say is that I will NOT write one for the first full release, but I will at least look into the idea after that point; I see writing a compiler (from the ground up, that is) to be a challenge of roughly the same magnitude of the syscalls and libraries, as is the file system. So I don't know if I'll attempt it. I'm leaving it as a simple "maybe". Anyhow, I'm talking too much again, so I'll stop now. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
peter@sugar.hackercorp.com (Peter da Silva) (04/11/89)
In article <5121@cs.Buffalo.EDU>, ugkamins@sunybcs.uucp (John Kaminski) writes: > I subscribe to comp.os.minix, which is about MINIX... > Andy is THE best computer writer I know. Not only does he seem rather > knowlegeable (sp?) but he is *EXCELLENT* at expressing what he is writing > about. He also heartily dislikes the Amiga. Some of his reasons are valid, but many of them seem to be based on the Amiga having unconventional hardware. He's got a couple of students working on an Amiga port. From what I've heard it's not going to run under Exec, and it's not a very high priority. Under these circumstances I wouldn't hold my breath for MINIX to do the duty of Amigix. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
deven@pawl.rpi.edu (Deven Corzine) (04/11/89)
By the way, I will gladly accept any wishlist items for Amigix, (be they SysV, BSD, or Amiga-type extensions/libraries/whatever people would like to see) and consider whether or not to try to implement them. Suggestions should be sent by _Email_ to shadow@pawl.rpi.edu [NOT deven@pawl.rpi.edu]... I attempt to reply to all mail, mailers willing. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.