jrd@STONY-BROOK.SCRC.SYMBOLICS.COM.UUCP (12/07/87)
Hi all. Here's my weekly batch of wierd questions. What if anything has happened w/r/t fixing the dreaded '40 directory' bug? I saw a lot of discussion of the problem and symptoms, but no mention of a fix. I've recently gotten a hard disk, and so am now in a position to get screwed by this bug. Is there a recent copy of Spacewar available? The one in the archives appears to be mono only (I use color) and the one on UMIX.CC.UMICH.EDU is corrupted; at least neither ARC on my ST nor ARC on a Un*x can read it. I'm trying to understand the difference between .O files (as produced by C backends, I guess) and executables, ie .TTPs etc. It looks to me like they're the same format (both relocatable) and that the only net difference is that in the executable, all the TEXT psects from the .Os are concatenated together, all the DATA psects ditto, etc, and that references are resolved. If that's true, it seems like the linker's pretty trivial. If not, what am I missing? Also, if my supposition about the linker's true, what's RELMOD for? Are there any PD debuggers around? As always, thanks in advance for any info.
holloway@drivax.UUCP (Bruce Holloway) (12/10/87)
In article <19871207191413.3.JRD@GRACKLE.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: >Hi all. Here's my weekly batch of wierd questions. >What if anything has happened w/r/t fixing the dreaded '40 directory' >bug? I saw a lot of discussion of the problem and symptoms, but no >mention of a fix. I've recently gotten a hard disk, and so am now in a >position to get screwed by this bug. As far as I know, Atari hasn't fixed the problem, but they sort of distribute FOLDRXXX.PRG which delays the problem, perhaps indefinitely. >Is there a recent copy of Spacewar available? The one in the archives >appears to be mono only (I use color) and the one on UMIX.CC.UMICH.EDU >is corrupted; at least neither ARC on my ST nor ARC on a Un*x can read >it. A color version came over the net awhile back, and is probably available on any timesharing service you can think of (People/Link, for example...) >I'm trying to understand the difference between .O files (as produced by >C backends, I guess) and executables, ie .TTPs etc. It looks to me like >they're the same format (both relocatable) and that the only net >difference is that in the executable, all the TEXT psects from the .Os >are concatenated together, all the DATA psects ditto, etc, and that >references are resolved. If that's true, it seems like the linker's >pretty trivial. If not, what am I missing? Also, if my supposition >about the linker's true, what's RELMOD for? The linker also can search through libraries for unresolved routines, and only pull out the modules you need. For almost two years now, the Atari developer's kit's linker has been LINK68, which doesn't require RELMOD. RELMOD just translated the fixup information to a more compact format. The format used with CP/M-68K added a LONG WORD (4 bytes) to a file for each code or data reference. The smaller format just saves the type of reference it is. I think. It's been a while. But you get the idea. >Are there any PD debuggers around? No good ones. -- ******************************************************************************* * Bruce Holloway - Terminal Netnews Addict uunet!amdahl!drivax!holloway * * ALBATROSS, ATARI*TROS @ Plink ALBATROSS @ Delphi * *******************************************************************************
johno@pnet51.cts.com (John Ogawa) (08/29/88)
[Is there still a line eater out there? Or am I just looking foolish?]
Hi out there in Netland. Long time no see. I am back online again by the
gracious permission of the sysop of pnet. I can receive mail here, but the
prefered place is my school account, lxw6035@ux.acss.umn.edu.
Anyway, on to some questions that I have been building up.
Currently I have 2 projects: a terminal called Lazy Term, and an update of
Schizo, it will be v1.5. I am having major problems with both. If I can get
some help from people who know better out there, they will both be out soon.
On to the first.
Lazy Term (why do we need another terminal emulator?) will be a SMALL,
reasonably full-featured VT52 emulator. You will be able to call it up from
anywhere with a key combination. I am debating XMODEM capability, but it will
surely have macro capability, and dialing capability (automatic redialing,
RS232 settings PER PHONE NUMBER, etc). It also will answer like a real VT52
(for those of you that use qterm on UNIX). Most everything is working, except
for the most important part, calling it up! <grin> At first I was going to
make it a desk accessory. But then I had major problems looking for a key
combination from the desktop (anyone know why the Desktop ignores MU_KEYBD
events?). So, I decided to try and put a keyboard intercept in. No go. I
have never messed with interrupt routines before, so I don't know what the
problem is. Right now, I can't even install a dummy routine. I am replacing
the routine that I find from Kbdvbase in the kb_kbdsys pointer. I use Mark
Williams' C, and the setrte routine (which saves registers) first, and then
pass control to the original routine after finishing. This always bombs out.
If anyone can help, I'd be thankful. I am also wondering whether it is safe
to use system calls (like Bconout) in an interrupt routine. Any code would be
much appreciated.
On to the second set of problems. Schizo v1.5 will have two major
improvements: it will have a corner clock, and it will select a desktop.inf
file that matches the current resolution. Of course, I am having problems
with both. The corner clock is related to the interrupt routine problems. I
am using a VBI to keep the clock working in non-GEM programs. I can install a
VBI, but am wondering whether it is safe to use system calls within the
routine. The second problem is with the desktop.inf reading. Right now,
short of reading it myself, the only way I can do this is to rename a file to
desktop.inf, and then reboot. Obviously this is a poor answer. Is it the
only answer though?
Those are my problems. I apologise for asking. I program to learn. Every
new revision or program has taught me loads about how the ST works. I am
obviously still learning <grin>.
Any comments, suggestions, and help is welcome. Thanks.
John Ogawa
BITNET: lxw6035@ux
UUCP: lxw6035@ux.acss.umn.edu
USMail: Institute of Child Development
University of Minnesota
51 E. River Rd.
Minneapolis, MN 55455
Phone: O: (612)624-3347
H: (612)870-9103
UUCP: {rosevax, crash}!orbit!pnet51!johno
INET: johno@pnet51.cts.com7103_300@uwovax.uwo.ca (Eric Smith) (09/02/88)
In article <30@orbit.UUCP>, johno@pnet51.cts.com (John Ogawa) writes: > ... But then I had major problems looking for a key > combination from the desktop (anyone know why the Desktop ignores MU_KEYBD > events?). So, I decided to try and put a keyboard intercept in. No go. I > have never messed with interrupt routines before, so I don't know what the > problem is. Right now, I can't even install a dummy routine. I am replacing > the routine that I find from Kbdvbase in the kb_kbdsys pointer. I use Mark > Williams' C, and the setrte routine (which saves registers) first, and then > pass control to the original routine after finishing. This always bombs out. Your best bet is to pass control to the original keyboard handler first, after which you can check the keyboard input buffer for the desired keys. > ... I am also wondering whether it is safe > to use system calls (like Bconout) in an interrupt routine. No, not unless you expand the size of the BIOS stack (the pointer to which is located at 0x4a2). If you replace this with a pointer to a suitably large area of your own (say, 1 or 2K) then you can use BIOS and XBIOS calls. GEMDOS is another story, and making GEMDOS calls from inside of an interrupt is basically impossible (unless you want to rewrite the GEMDOS trap dispatcher). > ... The second problem is with the desktop.inf reading. Right now, > short of reading it myself, the only way I can do this is to rename a file to > desktop.inf, and then reboot. Obviously this is a poor answer. Is it the > only answer though? > John Ogawa No, it isn't the only answer. The best way to change the desktop.inf settings is to tell the desktop to do it for you. That's what the control panel does. There are 2 AES calls to do this; shel_put and shel_get. The syntaxes are as follows: shel_get(buf, n) char *buf; int n; Get n bytes of data from the desktop's current desktop.inf values, and put them in memory starting at 'buf'. A value of n=128 gets the whole thing, I think. shel_put(buf, n) char *buf; inf n; Put n bytes of data, pointed to by 'buf', into the desktop's copy of desktop.inf. A value of n=128 puts a whole new copy of desktop.inf in there. When the user next selects 'Save Desktop' from appropriate menu, then this information will be used to create (or re-create) the file desktop.inf on disk. One last note; the control panel apparently only does one 'shel_get' (when it is first loaded) and hence won't recognize changes made by other accessories unless you save the desktop and reboot. I guess Atari or DRI didn't expect anyone else to use these calls. They're also very poorly documented, at least in the stuff available to poor 'unregistered developer' slobs like myself! So I can make no guarantees about the above information, but it seems to work (a friend and I wrote a replacement VT52 emulator acc. and used these calls to communicate with the desktop). -- Eric R. Smith email: Dept. of Mathematics 7103_300@uwovax.uwo.ca University of Western Ontario 7103_300@uwovax.bitnet London, Ont. Canada N6A 5B7 (a shared mailbox: put my name on ph: (519) 661-3638 the Subj: line, please!)