8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CAT6.MSGS.ARC / CAT6.5MSGS930525 < prev next >

Wrap

Text File | 2019-04-13 | 32.4 KB | 811 lines

Category 6, Topic 24 Message 46 Sat Mar 21, 1992 JIM.COLLETTE at 00:00 EST By one block, I meant as REU memory... basically just tap into DoRAMOp and see what the current high bank limit is and then up that by two and put your code to access the 128's internal memory in to respond to the two extra banks. There would be problems with wraparounds between the REU memory and 128 memory, but I'm not aware of anything in GEOS that ever crosses bank boundaries in the first place. As far as I know, GEOS doesn't use zero page in bank 0 for anything, but I could be wrong. Don't remember ever seeing anything in Hitchhiker's about it though. Jim :) ------------ Category 6, Topic 24 Message 47 Sat Mar 21, 1992 R.KNOP1 [Rob Knop] at 21:08 EST No, I don't think the HHG2G says anything about RAM0 zero page usage. Probably what I will do is run a simple test: write a program to put some pattern of bytes into the BASIC-only parts of bank 0 ZP. Exit the program, run GEOS for a while, then check to see if the byte pattern is still there. I'll let y'all know what I figure out with this. (I wonder if the BackRAM debugger uses any of RAM0's ZP.... I expect not, but it is something else to test.) -Rob ------------ Category 6, Topic 24 Message 48 Sun Mar 22, 1992 J.COLLINS5 [GeojoeC[JTC]] at 12:14 EST This compatibility thing is the real problem. Forget compatability. The software your trying to be compatible with was written for the limited system or 6 years ago! The whole point of revamping the OS is to make it use more of the computers NEW features, and make it use those features better. Those who don't invest on the new hardware don't need a GEOS 3.0. Let them use the old stuff and stay copmatible. It's the power users who are most likely to move to another platform! I know I did! They are the ones who need new, improved software to go with the new super hardware. They're not satisfied with Geopublish now in it's 40 column, 3 drive, crippled version. What makes you think they want that same Crippleware on their improved Super 8 bit, that they sank a fortune into. I wouldn't. As for retaining some compatibility I had this old idea to break up GEOS into Component libraries, Grafix, Storage, ect. The jump table is where all sane programers call their routines from. So they can retain compatibility. My idea was to remove GEOS from the computers memory and place it in an REU. The jump table woule be left in tact but now when a call went to the jump table it would store the address of the table that was called, then retrive only the code needed for the operation. That code would have been rewritten to load over the jumptable alone and execute, and the the last thing each operation would do is restore the jumptable from the REU and fix the stack ect. I think the bottleneck I ran into was that I needed a Calculated JMP routine to get the job done and there is none in the 6502's intruction set. I started working on using JSR as a calculated JMP, but I couldn't figure out how to get rid of the need for an RTS. It's been almost a year since I even though of this stuff. But that was the wa to stay compatible and expand. Now, with all the CMD peripherals, and REU compatibles, and Zip chips doing double addressing I would be compleatly lost. ------------ Category 6, Topic 24 Message 49 Sun Mar 22, 1992 R.KNOP1 [Rob Knop] at 22:01 EST I like the idea of non-resident Libraries. Nowadays, though, it might be betterto not only store the libraries in the REU, but be able to store them in a disk file as well. Not really a practical idea for real disks, but that would allow one to use it with a RAMLink.... What sort of Calculated JMP do you need? How were you using JSR for the purpose, in a way that JMP wouldn't work? What's wrong with the indirect JMP statement? Calculate the address, stick it in a ZP (or whatever) variable, and JMP (variable). There are also sneaky things you can do with BRK- push an address on the stack, do a BRK, have the interrupt handler call the routine of the address you pushed on the stack. (Alternatively, you could just leave the address in the code, since the address of the BRK is shoved on the stack before the interrupt handler is called.) It is a good point, though, that people with Super-128's (ZIP cip, 512K or 1 Meg of memory, possibly with RAMLinks hanging off the back) may want a whole new OS that takes advantage of what is more or less a new computer. There is a guy on Usenet who is writing a multitasking OS for the 128- it sounds like he's getting it to work, too. Now, imagine that with a ZIP accelerated 128. -Rob ------------ Category 6, Topic 24 Message 50 Sun May 31, 1992 P.CATCHPOLE [Mike] at 14:39 EDT Is anyone here using GEOWORKS? They tried to sell it to me, using, of course, my name from the 2.0 registration ( I use a difrent middle initial on verious things... allows me to tell imediately where the adress came from.... ) I said "No Way". I don't feel they supported the C= version well, and they walked away from it.... they did it once, they'll do it again. ------------ Category 6, Topic 24 Message 51 Sun May 31, 1992 JIM.COLLETTE at 16:41 EDT That's your prerogative, Mike... but if you think about it logically, they would only abandon PC/GEOS to move onto even greener pastures, and if you consider the way the PC world is growing these days (unfortunately so), at this point in time I can't fathom any other market where they could possibly make as much money. This hasn't been any real immediate switch either... they've been working on PC/GEOS for years. Jim :) ------------ Category 6, Topic 24 Message 52 Mon Jun 01, 1992 C128.JBEE [* Sysop *] at 02:21 EDT I don't think BSW walked away. After all, they pretty much sold the whole market and there were not too many more units to sell. Sure, the Geos market wants for a few things, but not major applications, except maybe a few C-128 80 column versions of applications. But! You can still call BSW and get reasonable support, plus, they still sell Geos. If they treat PC owners 1/2 as nice as they treated Commodore owners PC owners shouldn't complain. ------------ Category 6, Topic 24 Message 53 Tue Jun 02, 1992 R.KNOP1 [Rob Knop] at 01:50 EDT I agree that BSW has been very nice us. Also consider the fact that they let us have the Hitchhiker's Guide to GEOS and geoDebugger 2.0, even though neither of those products were ever completely finished, or ever marketed. They still give strong customer support on "That Other Network," don't they? Plus, there's always user support (which goes a long way with a lot of C64 and C128 stuff nowadays). -Rob ------------ Category 6, Topic 24 Message 54 Wed Jun 03, 1992 P.CATCHPOLE [Mike] at 22:06 EDT Still sell it? I read in COMP.SYS.CBM that it had been cut off, and all unsold units were recalled to the office for god knows what. I'm still using geos. It's faster than this XT, and I do have a ramdrive and GATEWAY, so it purrs right along.... ====== I don't use that other network anymore. I wanted to be able to get dos and amiga files for my projects :) BSW has been nice, MAYBE. I still hate the serial key system they used. The superintendent of schools where i go to school was going to use geos to do the school newsletter. I was going to show him GEOPUBLISH one day, since he was thinking of buying it. Got the famous "Reboot geos with the original copy of geos blah blah". He want out and bought a nice little clone that does the same thing, only without serial number keys. ------------ Category 6, Topic 24 Message 55 Wed Jun 03, 1992 JIM.COLLETTE at 22:42 EDT They haven't cut it off by any means... haven't seen the post over in comp.sys.cbm but guess I'll have to go look for it. They're no longer making new applications, but they still sell and support the old ones. Jim :) ------------ Category 6, Topic 24 Message 56 Wed Jun 03, 1992 CBM-ED [e.g.bell] at 23:29 EDT GEOS is extremely popular everywhere I get to see messages from CBM users. The most consistent complaint is the copy protection. Why did they not use it for the other platforms. >>shrug<< ------------ ************ Topic 25 Sun Feb 02, 1992 M.MINNIG at 02:52 PST Sub: 128 RBOOT How to RBOOT on a 128 6 message(s) total. ************ ------------ Category 6, Topic 25 Message 1 Sun Feb 02, 1992 M.MINNIG at 02:53 PST Boy, what a doofus am I! Two years I've been using GEOS 128, and I've been unable to use the RBOOT function. Trying "load"128 rboot",8,1" and "load"128 rboot",8 got me nowhere except a one-way trip to the ML monitor! Well, friends, the secret is to type: boot"128 rboot" Mirabile dictu! Happy RBOOTing, all! Michael ------------ Category 6, Topic 25 Message 2 Sun Feb 02, 1992 R.KNOP1 [Rob Knop] at 17:52 PST If you want to go one better, check out the program "rescue128.arc" in lirary #35. That one will succesfully rboot from your REU even if you have rearranged your disk drives. (The standard 128 rboot crashes if you have. For instance, I have a 1581 (drive 8) and a 1571 (drive 10). If I swap them in GEOS, reset, and try to RBOOT, it doesn't work.) Also, rescue128.arc will let you rboot after a system crash (useful for programmers who have this tendency to crash the system all over the place). Normally, pressing the 128 reset key in such a case will just hang the system. However, you can reset to 64 mode, do a poke, reset again to 128 mode, and run rescue128 to get back into GEOS with your RAMdisk intact. I have no idea if rescue128.arc works with a RAMLink. -Rob ------------ Category 6, Topic 25 Message 3 Mon Feb 03, 1992 JIM.COLLETTE at 22:00 EST Rescue128 reads the drive info out of the REU, I believe... and if I remember right, he (Joe Thomas, the author) does it before the RBOOT has started - which means it's probably 17xx exclusive. I haven't looked at the code yet but I wouldn't be surprised if it didn't work with GEORAM or my new RL patches. Jim :) ------------ Category 6, Topic 25 Message 4 Mon Apr 13, 1992 J.ROBBINS16 [JBUS] at 23:01 EDT Jims right, only works with REU'S, but you don't need it for RamDrive or RamLink if you make one of your RamDisks a boot disk, with the Gateway or Geos makeboot programs, and generally the Ramdisk won't lose any info except what wasn't updated at the time of the crash.... If RL or RD happens to zap RDDOS or RLDOS, just reinstall them and the ram contents will most likely still be intact, if the directory wasn't zapped along with your crash.. ------------ Category 6, Topic 25 Message 5 Wed Apr 15, 1992 JIM.COLLETTE at 00:06 EDT Right, with the RL Configure and the regular 1581 RAMLink partitions, booting from scratch doesn't erase them so you're not in trouble if you can't RBOOT. For anyone that's interested, I'm uploading tonight a program for GEOS 128 that will disable RBOOT when you hit reset - it kills it completely, so no more POKE 996,96 from 64 mode every time you want to get back into 128 mode. You can still RBOOT from disk or with BANK1:SYS49152, it just won't happen by itself anymore (which never usually worked anyway if your drives were out of order from how they power-up). Jim :) ------------ Category 6, Topic 25 Message 6 Thu Apr 16, 1992 J.ROBBINS16 [JBUS] at 03:19 EDT Sounds like a good idea,(a little better than the one I use), so I'm gonna try it when it becomes live.. Thanks Jim ------------ ************ Topic 27 Fri Aug 07, 1992 R.KNOP1 [Rob Knop] (Forwarded) Sub: Fancy PostScript Bitmap output Discussion started elsewhere of an easy way to tile multiple bitmap outputs (e.g. of geoPaint files) one one page. 14 message(s) total. ************ ------------ Category 6, Topic 27 Message 1 Fri Aug 07, 1992 R.KNOP1 [Rob Knop] (Forwarded) This discussion got started over in the CMD LQ topic, but as it seems to be taking up a life of its own, I thought I'd start a new topic. Anyway, the issue of a PostScript BitMap printer driver that can scale and position prints on the page. I thought about it, and did some simple calcuations. You send images to PostScript in Hex form, so that means for each byte in the geoPaint file, you have to send _two_ bytes to the PostScript printer. There is in addition some overhead, but this is small. (It just takes a few numbers to tell the printer where to put the image, and how big to make it.) Not having a PostScript printer plugged into my 128, I'll probably start by having it write PostScript files, to make sure that part works, then make another version that'll print directly to the printer. Now, a geoPaint page has 80X720 = 57600 bytes; multiply this by two, you get 116200 bytes. This is for one image! So, even with a blank 1581 disk, you couldn't get more than 6 or 7 per page in a disk file. But, I can live with that, for testing purposees. Another issue is transfer time to a directly hooked up PostScript printer. Assuming a 9600 baud connection (what sort of connection do you really get?), and 120K per geoPaint file that's on the page, you have about 100 seconds of transfer time per geoPaint file. This translates to 15 minutes for a 9 geoPaints in a 3x3 pattern. Add to that overhead (which'll be less than for a dot matrix printer driver, since PostScript takes the bytes horizontally like they're stored in memory, not vertically like a DM printer), and we're probably talking somewhere between 20 and 30 minutes for one 3x3 page of 9 geoPaints. In other words, a very nice coffee/go for a jog/vacation overseas break. I hope this is livable? -Rob ------------ Category 6, Topic 27 Message 2 Fri Aug 07, 1992 C128.JBEE [* Sysop *] (Forwarded) Sounds like something I could live with easy enough. One thing to remember is that the 9600 is probably one of the slowest ways to send the data to a printer. Parallel output could be up to 8x faster if written the proper way. Also the new HP printers coming out (Laserjet 4 this fall) can accept data up to 4-10x faster than the current ones. Even hooked up to the serial buss (vs. RS232) Paperclip can still stuff the printer and it's 99K buffer faster than it can print the pages. I did a test of ZED128 (super fast!) and it can feed the printer well over 200k before the second sheet is just out. So once we have a nifty way of printing the pages out and it actually works then I would think about the speed problem. The easiest solution would probably be to print from a Swiftlink to the printer's parallel port. You could hit up to 38K that way! Also by adding the ability to batch print pages and grabbing images off off a native mode partition of a huge size you could go for a short vacation and come back and have everything done :) Seriously though, the people with Postscript printers for Geos are also the most likely ones to own a massive storage device. ------------ Category 6, Topic 27 Message 3 Sat Aug 08, 1992 CMD-DOUG (Forwarded) Or likely candidates to buy one... (grin) ------------ Category 6, Topic 27 Message 4 Sun Aug 09, 1992 C128.JBEE [* Sysop *] (Forwarded) ;) ------------ Category 6, Topic 27 Message 5 Mon Aug 10, 1992 R.KNOP1 [Rob Knop] (Forwarded) JBEE- Do you hook your printer in through the serial bus? In other words, can one write to it by just opening device #4 as if it were any other sort of serial printer? Or, is it hooked in through the user port? (If it's hooked up through a parallel port, does that work just like accessing any other user port device? (Never done that, but have a vague idea, which can be improved with a little reading, of how it's done.) Or, is there a more involved protocol that one must go through?) What I'll probably try to do first is write a driver that makes a PostScript _file_, so I'll be able to test what I'm working on. I'm just a little worried about squeezing it all into the space allocated to a printer driver, but I'll see how that goes. I'll probably start hacking at this tomorrow evening. -Rob ------------ Category 6, Topic 27 Message 6 Mon Aug 10, 1992 C128.JBEE [* Sysop *] (Forwarded) The printer for Postscript mode is hooked up to the User port (RS232) and for HP mode is hooked up to the C= serial port. The printer can be run from either a serial connection or a parallel port connection. This will be the case in most Postscript printers or HP clones. You could send a Postscript file down the C= serial bus, you just wouldn't be able to see any error messages the printer sent back to you. I have my User Port to the printer serial port and my C= serial bus to the printer's parallel port. That way I don't have to switch cables and it works without swapping cables and stuff with most software. Since geoPublish uses the RS232 connection automatically everything works out fine. ------------ Category 6, Topic 27 Message 7 Tue Aug 11, 1992 JIM.COLLETTE (Forwarded) If you want to provide geoCable (parallel, user port) support Rob, I can give you the source to the parallel I/O routines if you need them. Let me know. (I've got reverse-engineered RS-232 (user port) serial source from geoPubLaser/geoLaser itself as well which you can also have if you like.) Jim :) ------------ Category 6, Topic 27 Message 8 Wed Aug 12, 1992 R.KNOP1 [Rob Knop] (Forwarded) Jim- Yes, that'd be extremely helpful! Thank you! I was worried about writing code to access a PS printer through the User port, since I don't have such a beast, just a simple old 9-pin DM printer hooked through a Cardco interface. I believe (JBEE correct me if I'm wrong) that serial access through the User port is what I need here.... Testing is still going to be somewhat interesting, but to have previously tested code fragments will help me tremendously. I've pretty much "written" the version of the printer driver that'll write to a PostScript file. "Written" in quotes because I haven't tested it, so the bulk of development (debugging and such) is still ahead of me. This evening I'll try it out with geoPager, and when I have this much of the printer driver working, I'll modify geoPager to take advantage of its extra features (that part'll be easy), and then test the combo. When I have all that working, I'll then launch into the task of trying to have the driver write directly to a printer hangning out of the user port. I'm gonna be out of here next week, so probably I'll be working on that starting the week of the 24th. -Rob ------------ Category 6, Topic 27 Message 9 Wed Aug 12, 1992 C128.JBEE [* Sysop *] (Forwarded) Yes, writing to the serial port of the printer through the User Port is the way to go for at least the 1st version of the new GeoPager. ----------- Category 6, Topic 27 Message 10 Thu Aug 13, 1992 R.KNOP1 [Rob Knop] (Forwarded) Well, progress is being made. I've compiled and ironed some bugs out of the version of the priner driver that makes a PostScript file. For now, I'm just printing a single image to it. It seems to be producing mostly legal PostScript (I look at the file with ZED-the-godlike-editor), though my code doesn't seem to be printing out some of the ending PS code; still have to figure that one out. Also, my decimal number priting routine is producing bizarre results; probably another stupid error along the lines of the one I found, which was a 8-byte table whose entries I had put in backwards. The good news is, my file writing routines (I doit all with the low-level GEOS file routines, like PutBlock, NxtBlkAlloc...) seemed to mostly work the first time around with no trouble. It is possible that some problem here is what's eating part of the ending PS code, although the very last line in the file (the "showpage") shows up OK, so I'm inclined to believe it's something else. Once I fix the two problems, though, I'll give a try at spewing the file out to a PostScript printer (which'll require moving files across MS-DOS disks and other scary things), and THEN I'll dive into the geoPager modification that will take advantage of the printer driver's ability to position and scale the images. -Rob ------------ Category 6, Topic 27 Message 11 Thu Aug 13, 1992 C128.JBEE [* Sysop *] (Forwarded) If you want you can always upload it here and I can download it and test it :) ------------ Category 6, Topic 27 Message 12 Fri Aug 14, 1992 R.KNOP1 [Rob Knop] (Forwarded) You'll see that, don't worry. I think I've got all of the bugs ironed out of the version of the driver that makes a PostScript file. The residual problems were stupid little things, like popping things off the stack one line _after_ I needed them, LoadW instead of MoveW, that sort of stuff. I've also launched into work on geoPager to make use of the printer driver's ability to put multiple prints on one page, but I haven't yet got that working. Probably won't get a chance to work on it again for a week or so. JBEE - the printer driver you use now to print geoPaint files, it only prints 72 dpi, thus lopping off the right 64 pixels of the geoPaint file, right? The one I'm doing lets you configure for either 72 or 80 dpi [calibrated on a full- size printout] both horizontally and vertically. (The vertical configuability is so you can still get square printouts without losing the right 64 pixels.) Tomorrow I sick some of the PS files I've created on a PS printer.... -Rob ------------ Category 6, Topic 27 Message 13 Fri Aug 14, 1992 JIM.COLLETTE (Forwarded) Ok Rob... I'll look for the stuff this weekend and get it uploaded to you. Jim :) ------------ Category 6, Topic 27 Message 14 Fri Aug 14, 1992 C128.JBEE [* Sysop *] (Forwarded) Yes, that sounds like the problem! It supposely will let you print 75,150,300 dpi but lops off the right hand side so it must still be figuring it t 72dpi x 8 vs. 8x80. ------------ ************ Topic 28 Wed Feb 12, 1992 M.MINNIG at 18:13 PST Sub: geoWrite 64 runs under GEOS 128?!? It's weird but true! 1 message(s) total. ************ ------------ Category 6, Topic 28 Message 1 Wed Feb 12, 1992 JIM.COLLETTE at 22:22 EST Yep, I think I've tried that before too... in reality, there's no reason why it shouldn't.... but with geoWrite 128 available, most people never even try it! Jim :) ------------ ************ Topic 29 Wed Feb 12, 1992 M.MINNIG at 18:15 PST Sub: DA runner and geoDex Jim, when I try to open geoDex fromyour excellent DA RUNNER, I get a "cannot open this DA message. Is this normal? 4 message(s) total. ************ ------------ Category 6, Topic 29 Message 1 Wed Feb 12, 1992 M.MINNIG at 18:16 PST I'm guessing that the file size is too big? Michael ------------ Category 6, Topic 29 Message 2 Wed Feb 12, 1992 JIM.COLLETTE at 22:26 EST Hmmm... it's been so long since I wrote that, I can't remember the limitations offhand. It MAY be a memory conflict problem - or possibly you just don't have enough space on the disk to write the swap file. How much room is free on the disk? For geoDex, I think you need 20K or so... Because of the way DA-Runner works, there's a chance it won't run DAs that overwrite DA-Runner... although I'm not sure if I got around that or not. I know geoWizard has no problems with it, and I pulled most of the DA support code for geoWizard right from DA-Runner and patched it up a bit. If I get a chance, I'll go back and look at the DA-Runner code and see just what it's doing. Jim :) ------------ Category 6, Topic 29 Message 3 Thu Feb 13, 1992 M.MINNIG at 18:21 PST Jim, you were right: I was trying to run DA's on a nearly-full disk. DA RUNNER works fine with geoDex on a disk with enough free bytes. OOPS! Michael ------------ Category 6, Topic 29 Message 4 Thu Feb 13, 1992 JIM.COLLETTE at 22:53 EST Glad to hear you got it working! :) Jim :) ------------ ************ Topic 30 Wed Mar 04, 1992 M.MINNIG at 21:12 EST Sub: That pesky device #11! What to do? Automating a device # change and GEOS boot in one program 6 message(s) total. ************ ------------ Category 6, Topic 30 Message 1 Wed Mar 04, 1992 M.MINNIG at 21:13 EST I DIP-switched my 128D's internal 1571 to allow me to use my HD-40 as my primary drive. Usually, the 1571 stays as device #11, but the swap routines in GEOS 2.0 use that device # also, causing a real mess when I swap in drive C. To avoid this, I soft-wire the 1571 to device #20 with this command: OPEN15,11,15,"U0>"+CHR$(20) CLOSE20 This works fine in direct mode, but I'd like to add a line that will load and run GEOS from a BASIC program. So I tried this program: 10 OPEN15,11,15,"U0>"+CHR$(20):CLOSE15 20 LOAD"GEOS128 2.0",8,1 No joy. The 1571 gets changed to #20, but for some reason the program goes back to line 10 and crashes with a "DEVICE NOT PRESESNT" error. I've successfully used this technique with programs other than GEOS. I wonder if I shouldn't be trying to mix ML and BASIC together like this, or perhaps it takes a BLOAD and SYS command (to what address?) to get GEOS's ML code into gear. I'm sure the flaw in my programming must be obvious to someone here. Any suggestions? Michael ------------ Category 6, Topic 30 Message 2 Wed Mar 04, 1992 M.MINNIG at 21:15 EST BTW, that message was slightly garbled when uploaded; line 20 should start a new line :) ------------ Category 6, Topic 30 Message 3 Wed Mar 04, 1992 PAUL-MB at 21:42 EST Michael - Try this and see what happens. 10 OPEN15,8,15,"U0>"+CHR$(20):CLOSE15 20 BOOT"GEOS128"ONU8 Let me know if the computer starts smoking blue smoke ;) ...Paul @ Micro-Bytes Publishing ------------ Category 6, Topic 30 Message 4 Thu Mar 05, 1992 M.MINNIG at 22:18 EST That did it; works like a charm. Thanks a lot. In your honor, I'm naming this program "paul" ;) Michael ------------ Category 6, Topic 30 Message 5 Fri Mar 06, 1992 PAUL-MB at 19:17 EST Gee thanks ;) ...Paul @ Micro-Bytes Publishing PS: I'll probably upload a file for Word Writer 6 which does a similar thing; changes drive 10 and up to 8 then boots. :) ------------ Category 6, Topic 30 Message 6 Tue Jul 14, 1992 C128.JBEE [* Sysop *] at 14:36 EDT Or use the program Howie uploaded: File #9793 SET1581.NUMBER ------------ ************ Topic 32 Sun Apr 12, 1992 R.KNOP1 [Rob Knop] at 02:37 EDT Sub: geoProgrammer Discussion of issues associated with BSW's assembly language programming package for GEOS. 6 message(s) total. ************ ------------ Category 6, Topic 32 Message 1 Sun Apr 12, 1992 R.KNOP1 [Rob Knop] at 02:38 EDT I ran into what might be a Linker bug. Suffice to say it was doing strange things that I can't explain given my source code. The problem is likely either a Linker bug, or some glitch in my REU (although a strange one). I was assembling and linking a short program. The program assembled fine, and according to the claim of the linker, linked fine. When I hauled out a ssector editor (geoDebugger's getb command) and looked at the files on the disk, I found the following: the .rel file was just fine. VLIR record 0 of this file holds the object code (machine code with 0's in place of unresolved symbols), and the first two disk blocks of this code looked just as it should have. However, the exectuable file (output from geoLinker) was messed up. The first disk block of the exectuable (a sequential appliation) was fine, but the track/sector link pointed to the track and sector of the HEADER record for the .dbg file! Needless to say, this caused some problems when I tried to run the program, since the 2nd (and beyond) 254 bytes of the code was replaced by (definitely non-executable) data. Has anyone else seen this (potential) geoLinker bug? Or is it just me? Jim, do you know anything about this? -Rob ------------ Category 6, Topic 32 Message 2 Sun Apr 12, 1992 R.KNOP1 [Rob Knop] at 02:40 EDT A little more info I forgot to mention: I recompiled 3 or 4 times and kept getting the same object code. I rebooted between recompiles, but I did a RAM rboot, so the RAMdisk on my 1.5 Meg 1750 stayed intact, thus it is possible that it was a repeatable RAMdisk glitch. Finally, I delete the current exectuable and .dbg file, and re-linked; since then, all has been working fine (including subsequent links with the executable and .dgb file existing). Odd. -Rob s ------------ Category 6, Topic 32 Message 3 Sun Apr 12, 1992 JIM.COLLETTE at 23:15 EDT Any chance your program (or another one) went astray and messed up the BAM in your RAM disk? That's about the only thing I can figure. GEOS is especially bad it seems about continually goofing up writing files when parts of them that go along with a trashed BAM are involved... after deleting them and validating, it's OK. I used to get the Linker to act up on me all the time when I started getting impatient and I'd hit Return on the link options box as soon as it started to come up instead of waiting for it to be drawn and then hit return or click OK... it was stopping too early and something wasn't getting initialized, because it would always write out a bad executable file and the BAM would get all trashed and everything. And at the time i didn't know what the problem was and was just getting ticked off and likewise more and more impatient (it was Font Editor I was working on, that thing takes forever to link!) so it kept popping up more and more often. I was on the boards on Q-Link swearing up and down to BSW that there was a real nasty bug in geoLinker and then FINALLY somehow I discovered what was going on and felt like a bumbling idiot! Dunno if you ever use the return-for-OK shortcut in Linker, but if you do, try doing it right as it starts to put the box up and see if you get the same thing again... might be that same bug. Jim :) ------------ Category 6, Topic 32 Message 4 Thu Apr 16, 1992 R.KNOP1 [Rob Knop] at 02:17 EDT Jim- That sounds exactly like what my problem was. I normall assemble and link with my eyes glazed over and one hand on the mouse. Last weekend, when I had the problem, I was doing some ironing while assembling and liking. I distinctly remember standing at the computer impatiently starting an link, and hitting the RETURN key in the Link options box. I don't remember if I did that on the times when the link failed, but it is entirely possible. Anyway, it's good to know I'm not off my rocker on this one, and that my REU isn't dying on me. Also, It's good to know how to avoid the bug in the future! :) -Rob ------------ Category 6, Topic 32 Message 5 Thu Apr 16, 1992 JIM.COLLETTE at 20:14 EDT LOL, you're the only other person I'm aware of who's encountered that bug! I guess it's just us intense and impatient programmer types... LOL :) Jim :) ------------ Category 6, Topic 32 Message 6 Thu Aug 13, 1992 R.KNOP1 [Rob Knop] at 01:21 EDT Linker Humor: I was trying to link this application, a sequential application that had only one source file, under the name PSBMF. Well, I would boot up the linker, and give it the .lnk command file, and the linker would tell me it was linking PSBMF and then hang. The first time around it went for a long while, then put garbage up on the screen. Later, I realized that this was a <2K application, so there is no way the Linker should take that long on the file, so I'd reboot and do the ESC-7 KeyDOS GEOS reboot to try again. After trying a few times, I looked at the Linker command file, and everything looked OK... until I realized that I had left the ".rel" off of my object module name! To think, all that hair I tore out simply because the Linker treated my geoWrite file like a .rel file. The geoWrite file was well more than 4 pages, too, so the records that the linker would look for were all there. A new potential problem to keep in mind; I'm surprised I've never done this one before. -Rob ------------