1 #: 17859 S1/General Interest 04-Apr-93 13:36:55 Sb: #17858-SALE OF ALL COCO STUFF Fm: Brother Jeremy, CSJW 76477,142 To: JOERG SATTLER 74016,631 (X) I will be in touch.--Br. Jeremy, CSJW #: 17860 S1/General Interest 04-Apr-93 16:21:05 Sb: #Ar Version 1.3 Fm: PHILLIP TAYLOR 72067,3430 To: All This is the second time I uploaded Ar to Area #10, Version 1.3 as far as I know is a official release from the author. Whats going here? There is 1 Reply. #: 17863 S1/General Interest 04-Apr-93 21:22:27 Sb: #17860-#Ar Version 1.3 Fm: Steve Wegert 76703,4255 To: PHILLIP TAYLOR 72067,3430 (X) Phil, Sorry for the confusion over your AR upload. But as we understand the situation from the the author, Carl Kreider, the current release of AR is 1.2 and resides in our libraries. Carl has requested that the OS9 Forum on CompuServe serve as the official site for the AR archiver. To that end, he has also requested that the staff do what they can to limit the spread of other versions of AR claiming to be 'the lastest release'. While 1.3 is still backwards compatable with 1.2 (the only change I'm aware of is the handling of permissions) it was not authorized by the author. Hope this clears the air. If you have any questions, don't hesitate to ask. Thanks, *- Steve -* There is 1 Reply. #: 17883 S1/General Interest 08-Apr-93 17:31:27 Sb: #17863-#Ar Version 1.3 Fm: PHILLIP TAYLOR 72067,3430 To: Steve Wegert 76703,4255 (X) Since I am so confused from Ddelphi using on version of ar, and saying that the one they require for me to use to upload files, and this form used a different version, I am going to check and see if 1.2 is the lastest release version. Phillip Taylor There is 1 Reply. #: 17888 S1/General Interest 10-Apr-93 10:32:17 Sb: #17883-Ar Version 1.3 Fm: Steve Wegert 76703,4255 To: PHILLIP TAYLOR 72067,3430 (X) Several months ago, when the various version of AR began to pop up, I left word with Greg over on DELPHI as to what I understood Carl to want. I thought he indicated at that time he'd check out the various versions and abide by Carl's wishes. Perhaps this will be a moot point. Carl is working (has been working) on a new release of AR. *- Steve -* #: 17862 S12/OS9/68000 (OSK) 04-Apr-93 18:24:42 Sb: #17370-Termcap Fm: David George 72240,134 To: Bob van der Poel 76510,2203 (X) Sorry it took me so long to reply, but I don't get up here much anymore. A * means that the padding is proportional to the number of lines effected. I don't have my Unix system botted up right now so I can't look into the others (** and (G)) #: 17873 S12/OS9/68000 (OSK) 06-Apr-93 18:43:17 Sb: #17801-PCF Fm: Bert Schneider 70244,427 To: Bob van der Poel 76510,2203 (X) Thanks! I really appreciate that! #: 17871 S12/OS9/68000 (OSK) 06-Apr-93 05:25:45 Sb: #17856-HD Fm: Mark Griffith 76070,41 To: Hugo Bueno 71211,3662 (X) Hugo, > I used newer drivers and managed to format the hard drive sucessfully. Good, glad you're up and running now! /************* /\/\ark ************/ #: 17861 S12/OS9/68000 (OSK) 04-Apr-93 17:51:02 Sb: #17853-OS-9 Config 4 SCSI Boot Fm: ole hansen 100016,3417 To: Peter Baxter 74650,2522 Hello Peter. If the only problem is with the 'dd' device, try not to include it in the bootfile, and create one for the rimfire-board using the '/h0' or '/h1' or whatever the device-name is for the rimfire-device. The 'dd'-device is normally just another name for the 'device' yuo use as 'default device'. You can always 'load' the desired 'dd'-device (from startup) or command-line. If your system can make access to the rimfire without the 'dd'-device loaded, then just copy that file to dd.rimfire and use moded to chenge the name to 'dd'. If you also are having problems with no 'dd' loaded, then you probably have loeded two different device-descriptors with the same module-name. use 'mdir' to confirm that the device use want is loaded. Then use 'ident' on the file you loads as the device-descriptor to access the rimfire-drive and use ident (with '-m' flag) to check that the 'crc' is the same. If not, then you don't(sorry : the system does not) make access to the device you want. Does you get any error-messages ?? Try also to use the 'dump'-command wtih the '-m' flag to show the device-descriptor in memory. Yuo should be able to see the filemanager-name(RBF) and the device-name and driver-name. regards ole@danelec.dk #: 17868 S12/OS9/68000 (OSK) 05-Apr-93 12:57:34 Sb: #17853-OS-9 Config 4 SCSI Boot Fm: Kim Kempf 71161,3221 To: Peter Baxter 74650,2522 You are misunderstanding how the disk booting process works. It's the part of OS-9 in ROM that knows how to "boot" devices. The rom for your cpu already knows how to operate the 53c710 hardware to read a bootfile from a scsi target. You need to have a booter in the rom that knows how to operate the Ciprico controller in order to boot from that. There is nothing you can do to the bootfile or driver to change this. The rom booter is the thing that reads in the bootfile...sort of a chicken and egg problem. Making a rom boot routine requires the Portpak source code and lots of knowledge. Your best bet would be to contact Ultrascience to see if they can add a Ciprico booter to the ROM. #: 17864 S12/OS9/68000 (OSK) 05-Apr-93 01:15:59 Sb: #17855-#C_error_help Fm: LARRY OLSON 72227,3467 To: Mark Griffith 76070,41 (X) Mark, Do you mean 1 variable of 32k size ? or many variables totaling more than 32k. I don't have any assembler code imbedded in the program. I don't (intensionally) have any 32k variables, but the total data size looks to be 39k. I'm trying to narrow down the point when I get the error, its down to about a dozen lines of program, if I remark these out I don't get the error. I'll see if I can narrow it down some more. larry There is 1 Reply. #: 17870 S12/OS9/68000 (OSK) 06-Apr-93 05:25:34 Sb: #17864-#C_error_help Fm: Mark Griffith 76070,41 To: LARRY OLSON 72227,3467 (X) Larry, > Do you mean 1 variable of 32k size ? or many variables totaling more than > than 32k. If there is an array that is dimensioned to greater than 32K, like in 'char array[33000]', this will cause errors like what you are getting. /************* /\/\ark ************/ There is 1 Reply. #: 17892 S12/OS9/68000 (OSK) 11-Apr-93 04:05:42 Sb: #17870-C_error_help Fm: LARRY OLSON 72227,3467 To: Mark Griffith 76070,41 (X) Mark, I don't have any arrays close to that size, I have 4 at 1535 and quite a few other smaller ones. I'm trying to track down the problem, I have the program working again, but I'm not sure if I'm going to run into the same error later. I went through the program and tried to pare down the variable data space. I got it down to where an IDENT gives a DATA SIZE of #32086. With that data size I was still getting the same error, so I thought I would try to shrink some of the module size. By cleaning things up quite a bit, I was able to bring the following down: Module size #76648 #74158 Init. data off: #72474 #69992 Data ref. off: #76344 #73858 Theprogram now compiles without the Value Out of Range error !! For some reason, the problem is tied into the size of the program. Could this be something to do with the compiler ? This is all one big source file (86640 in size), I havn't got the hang of the linker yet. I have a couple more routines to add yet, and I afraid that I will see this problem crop up again. larry #: 17865 S12/OS9/68000 (OSK) 05-Apr-93 01:23:52 Sb: #17857-C_error_help Fm: LARRY OLSON 72227,3467 To: John R. Wainwright 72517,676 (X) John, This is strange, as I was telling Mark, I don't have any arrays that large. There has to be some error in my code, which isn't too hard to believe . I'm trying to narrow down the offending code now. larry #: 17866 S12/OS9/68000 (OSK) 05-Apr-93 03:52:25 Sb: C help Fm: Bob Taylor 73270,3124 To: all I need help with the following integer with the top 4 bits used as flags and the bottom 12 bits a signed integer. I haven't been able to correctly sign extend. Could an expert help? Thanks, Bob --------------------------------cut here------------------------------- typedef unsigned int CTYPE; #define MODE_BIT 0x8000 #define VM_BIT 0x4000 #define HM_BIT 0x2000 #define MOTION(amt) ( ((CTYPE)(amt) & 0xfff) | (MODE_BIT) | HM_BIT) ) ??? #define MVAL(c) ( (int) ((c) & 0xfff ) ) ????????? #: 17874 S12/OS9/68000 (OSK) 06-Apr-93 21:29:33 Sb: #COco disks on MM1 Fm: Hugo Bueno 71211,3662 To: All OK, another MM1 question. I'm trying to read 360K Coco disks on my drive 1. I've tried using the /c1 descriptor with no luck. The drive spins up, but all I get is an error 246-device not ready. Any ideas/suggestions? Hugo There is 1 Reply. #: 17877 S12/OS9/68000 (OSK) 07-Apr-93 17:30:32 Sb: #17874-#COco disks on MM1 Fm: Steve Wegert 76703,4255 To: Hugo Bueno 71211,3662 (X) Hi Hugo! Things were never meant to be this difficult! :-) I've use /c0 to read CoCo disks without any problems. How about posting the idents of the various drivers and descriptors involved. I'll be happy to compare them to mine. Have you been able to access other formats in that particular drive? *- Steve -* There is 1 Reply. #: 17884 S12/OS9/68000 (OSK) 08-Apr-93 20:23:02 Sb: #17877-#COco disks on MM1 Fm: Hugo Bueno 71211,3662 To: Steve Wegert 76703,4255 (X) Steve, I've been unable to read my Coco disks with the /c1 descriptor. Per messages on Delphi, I apparently have the latest RBF drivers and device descriptors. One thing I notice is that the LED on the 360K drive is brightly lit while the LED on the standard MM1's 3.5 inches is dimly lit. Does this mean anything? I'm absolutely sure the drive is jumpered correctly as drive 1. Again, all that happens is the disk spins up, but all I get is an error 246. Never seen that error using disk devices before. Hugo There is 1 Reply. #: 17889 S12/OS9/68000 (OSK) 10-Apr-93 10:32:28 Sb: #17884-COco disks on MM1 Fm: Steve Wegert 76703,4255 To: Hugo Bueno 71211,3662 (X) I'm not sure about the brightly lit LED on your drive ... sounds fishy. My 3.5 does glow dimly ... but no where near the intensity of an accessed drive. Perhaps your cable is on incorrectly? What are your dmode values for /c1? Perhaps Mark can jump in with a few ideas. *- Steve -* #: 17885 S12/OS9/68000 (OSK) 08-Apr-93 20:30:49 Sb: #serial buffer size Fm: Hugo Bueno 71211,3662 To: All How do I determine the size of transmit and receive buffers on serial ports on the MM1. I think part of my comm problems can be attributed to too small buffers. How do I go about changing them. I seem to remember 2k as a recommended size. Hugo There is 1 Reply. #: 17890 S12/OS9/68000 (OSK) 10-Apr-93 10:32:38 Sb: #17885-serial buffer size Fm: Steve Wegert 76703,4255 To: Hugo Bueno 71211,3662 (X) The moded command is what you need. Make sure you have the current moded.fields file . Best way to do this is to pop it into an editor and see if the variable bufer size stuff shows up in the SCF driver entries. Type moded use the f command to spec /d0/os9boot use the m comand to spec the proper descriptor to edit ues the e command to edit. Thump enter (leaves the field alone) until you get to the the buffer entries. They should be at the end of the module. Change the values to 2048 or so. use the w command to write and verify the module back out. use the q command to quit. Happy hunting! *- Steve -* #: 17891 S12/OS9/68000 (OSK) 10-Apr-93 15:41:48 Sb: BGFX docs Fm: keith bauer 71102,317 To: Kevin Darling 76703,4227 (X) Kevin, I caught a message about docs for BGFX and noticed that there are docs available. I bought BGFX at the Chicago Fest last year form Paul and at that time there where not any docs. I would really like to get my hands and these docs. Can I send you a SASE or will you upload them here? Thanks Keith Bauer Press !>