#: 8496 S15/Hot Topics 30-Nov-90 20:52:21 Sb: #8315-#Fest Fm: Mike Knudsen 72467,1111 To: Frank Hogg of FHL 70310,317 (X) Frank, as far as I can tell, with DMODE the MM/1 driver (actually the descriptor) can be set to read any format known, as long as it's "known" what it is, grin. MM/1's "standard" is 33 (or 34?) sectors per track -- some folks use more, but it isn't 100% safe. I hear that some "standards" (new ones) are just bypassing Track 0, with its confusion as to what density it is. Anyway, there is a set of about 6 parameters that serve to describe any format well enuf that with DMODE you can zap a descriptor to read it. If we could settle on a common set of names for those parameters, then vendors could label disks with the key parameters. I've scribbled a fewon your DS 3.5" disk already, grin. Oh yes, Coco 720K DS-80T 3.5" disks don't read on an MM/1 without changing a few parameters either. So many standards -- so little time -mike k. There is 1 Reply. #: 8528 S15/Hot Topics 01-Dec-90 23:47:10 Sb: #8496-#Fest Fm: Frank Hogg of FHL 70310,317 To: Mike Knudsen 72467,1111 (X) The 'standard' that skips track zero is referred to as the 'universal' format. MW does have a numbering system that used to be in their sig here on cis but Kev tells me that it is no longer there??? I have it somewhere and will upload it 'if' I find it. With the ability to change descriptors and also the ability and room (memory) to have named descriptors it really doesn't matter what each company uses as long as the disk has the info on it that is useful. To this end I will be doing 'something' on the disks we ship out in the future. How about a 'read me' file on the disk... (ha ha) BTW we are working on a upgrade to DynaStar to fix some of the little bugs and make a few changes, little ones, to make it easier to use. We are also trying to make it work as the manual says it does. Or... we'll change the manual to reflect what it actually does. If you have any 'small' suggestions now is the time to speak up. This is 'not' a rewrite, just a touch-up. Frank There is 1 Reply. #: 8853 S15/Hot Topics 22-Dec-90 23:12:09 Sb: #8528-#Fest Fm: Mike Knudsen 72467,1111 To: Frank Hogg of FHL 70310,317 (X) He he -- a readme file on the unreadable disk, grin. Glad to hear you're cleaning up DS. At the moment I can't think of LITTLE fixes, other than finding the bug which very rarely causes DS to write the last line of file forever till your disk fills up. Oh yes, how about that final non-newline character that sometimes can't be made to go away? I heard that shouldbe easy to fix. Would be nice to be able to save yaour file and go on editing the same file at the same place, but I guess that's not a minor fix. Could you add a way to QUICKLY set all TABS to 4 spaces instead of 5? Oh here's a nasty bug -- ^KA puts only 1 space instead of 2 after periods, unless you end each sentence with a period, space, and newline. Same bug applies to question and exclmataioion marks. PLEASE fix that one-I saw a reviewer really rag about it, and it bothers me too. Dyna Form needs to crash the system less often when things aren't quite right in the .init file. Some printer code definitions crash it. Also you need to be able to send zero-bytes in the printer commands (I think that's fixed in OSK?). "nuff bugs for now -- mike k. There is 1 Reply. #: 8867 S15/Hot Topics 23-Dec-90 16:51:29 Sb: #8853-#Fest Fm: Frank Hogg of FHL 70310,317 To: Mike Knudsen 72467,1111 Some if not all those you mentioned have been taken care of so far. I will pass this on to Dave to see about the others. Thanks for the input Frank There are 2 Replies. #: 8888 S15/Hot Topics 25-Dec-90 14:30:53 Sb: #8867-Fest Fm: MOTD Editor..Bill Brady 70126,267 To: Frank Hogg of FHL 70310,317 (X) Merry Christmas Frank...... send money. #: 8893 S15/Hot Topics 25-Dec-90 22:14:05 Sb: #8867-Fest Fm: Frank Hogg of FHL 70310,317 To: Frank Hogg of FHL 70310,317 cute #: 8593 S15/Hot Topics 04-Dec-90 17:13:55 Sb: #8107-#Fest Fm: Paul K. Ward 73477,2004 To: Mike Knudsen 72467,1111 (X) Mike, Don't you have Kevin's "Drive" command on that MM/1 proto? You just type drive d0 st or drive d0 coco or whatever. Let KEv know and I am sure he'll mail it to ya! Paul There is 1 Reply. #: 8854 S15/Hot Topics 22-Dec-90 23:15:35 Sb: #8593-Fest Fm: Mike Knudsen 72467,1111 To: Paul K. Ward 73477,2004 OK Paul -- sounds like a substitute for various DMODE shell scripts. Good idea. Say, I hear there's an MM/1 developer's DataBase LIbrary area here for those with "need to know" -- can I get in? Plus I hear there's useful stuff in the OSK libe here -- will take a look. #: 8594 S15/Hot Topics 04-Dec-90 17:15:14 Sb: Fest Fm: Paul K. Ward 73477,2004 To: Mark S 76004,373 (X) And then you have those 20 meg flopticals. Whew. Paul Ward #: 8504 S4/MIDI and Music 30-Nov-90 21:25:09 Sb: #8413-#Fallin.UME Fm: Mike Knudsen 72467,1111 To: Ches Looney 73016,1336 (X) Is Glen's MT32 editor uploaded here? How does it compare with Cluts' MTPanel? There is 1 Reply. #: 8521 S4/MIDI and Music 01-Dec-90 18:13:44 Sb: #8504-#Fallin.UME Fm: Ches Looney 73016,1336 To: Mike Knudsen 72467,1111 (X) Both Glen's MTMIDI and Jonathan's MTPanel are available in DL4 and both work nicely. Unfortunately both are unfinished and Jonathan hasn't been by to see my query and let me know whether any more work has been done on his. Jonathan's MTPanel has the promise of providing voice editing for the MT32 equivalent to Bill's TX81Z voice editor in RS Basic. If you haven't looked at Bill's, you might wish to get it out of CoCo DL4 (? or 5) and take a look at its implementation. 'Tis interesting to compare all three. Glen's is incomplete in the controls area and would be fun to see complete just for the fun of having an impressive control panel. He says he hasn't done any more work on it and I urged him to complete both that and the Fallin.UME that is really neat but O so short! Regards, Ches. There are 2 Replies. #: 8522 S4/MIDI and Music 01-Dec-90 20:05:41 Sb: #8521-#Fallin.UME Fm: James Jones 76257,562 To: Ches Looney 73016,1336 (X) I think that one *big* roadblock to my looking into doing something to let me mung patches and the like on the MT-32 is that the docs that come with it don't explain diddly about L/A synthesis, or what any of the buzzwords or acronyms mean and how they affect the sound of a patch, or anything like that. Is there any good description of that lying around that one can find somewhere? There is 1 Reply. #: 8532 S4/MIDI and Music 02-Dec-90 07:49:33 Sb: #8522-#Fallin.UME Fm: Ches Looney 73016,1336 To: James Jones 76257,562 (X) Not that I'm aware of. I've just had the MT-32 a couple of weeks so I am not very well acquainted with it yet. I've had the Yamaha TX81Z for a couple of years or so, so I'm better acquainted with it. I thought it had manual shortcomings, but it did explain much better how it synthesized tones. The Roland manual is somewhat better in its understandability, but I agree with your observation that it does nothing for the user in aiding understanding of the LA approach. Sorry!. Ches. There is 1 Reply. #: 8857 S4/MIDI and Music 22-Dec-90 23:33:00 Sb: #8532-#Fallin.UME Fm: Mike Knudsen 72467,1111 To: Ches Looney 73016,1336 (X) I heard that the only way to get a "manual" for the MT32 that explains how to use the parameters, is to order a manual for the D-50 or another similar keyboard synthesizer. I guess if they give you a keyboard they also let you adjust the parameters too, so they tell you what they mean. Of course with a really good grafix editor, you could learn pretty quickly by trial-and-error, just alike a REAL synth with a square yard of knobs. There is 1 Reply. #: 8923 S4/MIDI and Music 28-Dec-90 00:29:05 Sb: #8857-Fallin.UME Fm: GLEN HATHAWAY 71446,166 To: Mike Knudsen 72467,1111 Hi Mike... I just bought a brand new D-50 last Friday. Mucho fun! Learning to program it taught me everything I was unclear about on the MT-32. You all should expect a decent MT-32 (and D-50) patch editor soon if I can find the time. When I get my MM/1, I plan to write a patch librarian too. So, if you can't figure out how to program your MT-32, get a copy of the D-50 (or D-20 or D-110) manual - all are quite similar. You'll find it helpful... #: 8852 S4/MIDI and Music 22-Dec-90 23:04:12 Sb: #8521-Fallin.UME Fm: Mike Knudsen 72467,1111 To: Ches Looney 73016,1336 (X) Thanks for the info. Donj't have the time these days to wade thru RSDOS assembler code (por is it BASIC?), but would be nice ot see the TX81Z stuff anyway. I *think* I have C source for MTPanel, so anyone who really wanted to finish it could hack at it. I just saw amazing examples of what can be done to an MT32 over MIDI SysEx -- even write into the LEDs the name of the computer adventure game! --mike k #: 8505 S4/MIDI and Music 30-Nov-90 21:29:02 Sb: #8442-#New utils in DL4 Fm: Mike Knudsen 72467,1111 To: Pete Lyall 76703,4230 (X) Pete, thanks for the uploaded utilities. I have a real-time recorder working, sort of, but I need a faster 6850 chip in my MIDI Pak to get rid of occasional read errors that cause stuck notes and missing notes. And did you know that Casio synths send one NOTE-ON $90 at power-up and expect everything you play that session to be one long Running Status? Sheesh! Regards, mike k There is 1 Reply. #: 8507 S4/MIDI and Music 30-Nov-90 22:07:53 Sb: #8505-#New utils in DL4 Fm: Pete Lyall 76703,4230 To: Mike Knudsen 72467,1111 (X) Mike - On tha Casio's... sure that applies to the 101/1000/3000/5000/1? How about after pitch bend, or modulation message? That is weird.. may well explain why Casio's are so notorious for the 'stuck note' syndrome.. Pete There is 1 Reply. #: 8851 S4/MIDI and Music 22-Dec-90 23:00:22 Sb: #8507-#New utils in DL4 Fm: Mike Knudsen 72467,1111 To: Pete Lyall 76703,4230 (X) Pete, it's beena awhile since I was last here, but I've been told that Casios can indeed be cajoled into sending a NOTE ON by playing with the mod wheel, etc. This is from other MIDI hackers who confirmed that Casios overuse running status to the max, and your software must always intiialize to a NOTE ON when recording from one. I think keyboards should use running status ONLY when "no time" has elapsed between the note events, where "no time" depends of course on the synth's clock speed. In other words, a chord. I've never used a Casio keyboard to drive anything else -- I got a real Korg for that. --mike k There is 1 Reply. #: 8865 S4/MIDI and Music 23-Dec-90 10:31:56 Sb: #8851-New utils in DL4 Fm: Pete Lyall 76703,4230 To: Mike Knudsen 72467,1111 Mike - I had heard similar rumors... that a casio sends a NOTE ON on its assigned channel at powerup, and then relies on running status for the rest.. argh! What a nightmare. That certainly explains the proliferation of stuck note problems with Casios. In fact, the new Sequencer Plus Gold from Voyetra has a /CASIO switch! Pete #: 8508 S1/General Interest 30-Nov-90 22:19:00 Sb: #I'm Baaaaack! Fm: David L. Kaleita 72657,2775 To: Kevin Darling (UG Pres) 76703,4227 (X) Yeah, I've been talking to Hazelwood about some of their new (and upcoming) stuff... pretty neat! More CoCo OS-9 users? Where're they COMING from??? There is 1 Reply. #: 8511 S1/General Interest 30-Nov-90 23:01:40 Sb: #8508-#I'm Baaaaack! Fm: Kevin Darling (UG Pres) 76703,4227 To: David L. Kaleita 72657,2775 (X) Check out Lib 15 for specs on the three main new machines. There are more new L-II users on the nets than I've seen since L-II came out for the CoCo.... I dunno if they all just finally decided to jump on the fun, or what.... but they're showing up all over! Perhaps the emphasis switch in Rainbow magazine helps somewhat (it's gone a lot more OS9ish). The Amiga port is still hiding in Australia, but I betcha this coming year you'll see one done in the US, and become widely available. The Mac port was done last year... I thought you were there at the debut? Good to see you back: cuz 1991 will finally be the year of CD-I ! kev There is 1 Reply. #: 8598 S1/General Interest 04-Dec-90 18:57:49 Sb: #8511-#I'm Baaaaack! Fm: David L. Kaleita 72657,2775 To: Kevin Darling (UG Pres) 76703,4227 (X) Oh yeah, I guess I WAS there for the UltraScience MAC debut. I haven't heard much about it since, tho. Do you know anyone who is using it? CD-I? I'll believe it when I see it. (I'll also probably be one of the first on the block to get one... sigh!) There is 1 Reply. #: 8611 S1/General Interest 05-Dec-90 14:23:00 Sb: #8598-#I'm Baaaaack! Fm: Paul K. Ward 73477,2004 To: David L. Kaleita 72657,2775 (X) Dave, Well, Kev and I have seen CD-I and its being used for training disks and so on already. The newest industrial machines are now available, better integrated, and cheaper. Call Ray Ashton at American Interactive Media in Washsington for more information. I'm sure he can send you some info (I think the glossies for that came in last week). Paul There is 1 Reply. #: 8615 S1/General Interest 06-Dec-90 01:32:01 Sb: #8611-#I'm Baaaaack! Fm: Kevin Darling (UG Pres) 76703,4227 To: Paul K. Ward 73477,2004 (X) Paul - Dave was the biggest and earliest booster of CD-I around... you weren't here then tho, I think (it was almost two years ago). He even got Wayne to make one of the forum sections into the "CD-I" section. So I'm pretty positive that he's seen it long ago. Oh. Except you may have meant the current status of it, instead. Ne'er mind ;-) There is 1 Reply. #: 8672 S1/General Interest 10-Dec-90 20:58:09 Sb: #8615-I'm Baaaaack! Fm: David L. Kaleita 72657,2775 To: Kevin Darling (UG Pres) 76703,4227 (X) Hmmm... now that you mention it, what ever HAPPENED to that CD-I section?? #: 8599 S1/General Interest 04-Dec-90 19:00:32 Sb: I'm Baaaaack! Fm: David L. Kaleita 72657,2775 To: Pete Lyall 76703,4230 (X) Yeah, I just remember that I HAD seen the Ultrascience port (see #8598). So what's been happening in the UG? (Please disregard this question if there is no good news). #: 8512 S4/MIDI and Music 30-Nov-90 23:22:53 Sb: #MIDI Fm: Everett Chimbidis 76370,1366 To: 76703,4230 (X) DSdo you know of a way to play on my midi keyboard and record to ume? and do you have a way to change these ume files into files that msdos can use? or visaversa? There is 1 Reply. #: 8514 S4/MIDI and Music 01-Dec-90 02:42:24 Sb: #8512-#MIDI Fm: Pete Lyall 76703,4230 To: Everett Chimbidis 76370,1366 (X) Everett - Well - I'm not Umuse literate per se (Mike Knudsen is the author), but the scoop is: a) For the time being, UME cannot record from the MIDI INPUT. I know Mike's working on it, but knowing what's involved, I can tell you it's a b*tch to do under OS9. b) Most packages these days can read and write Standard MIDI Files (usually called MFF's or SMF's). Kind of like GIF for MIDI. I don't know if he's installed it yet, but there have been discussions (initiated by Mike, I think) regarding putting MFF capability into UME. Pete There is 1 Reply. #: 8526 S4/MIDI and Music 01-Dec-90 22:46:34 Sb: #8514-#MIDI Fm: Everett Chimbidis 76370,1366 To: Pete Lyall 76703,4230 (X) When this happends will it be posted here? There is 1 Reply. #: 8858 S4/MIDI and Music 22-Dec-90 23:40:45 Sb: #8526-#MIDI Fm: Mike Knudsen 72467,1111 To: Everett Chimbidis 76370,1366 (X) I wrote a simple set of programs to record and playback MIDI under OS9. All very legitimate, no screwing around with interrupts or anything. I will upload them here when they are debugged, but first I havae to get a faster chip (68B50) for my MIDI interface pack, since the current 6850 drops bytes now and then, ugh. You certainly cannot record MIDI thru the rear serial port, even tho it plays just fine under UME. Getting from hand-played recording to notation score is a real, ah, fun project, to say the least, but it will be fun to fool with, probabl;y on the OSK machines tho. --mike k There is 1 Reply. #: 8871 S4/MIDI and Music 24-Dec-90 17:46:58 Sb: #8858-MIDI Fm: Everett Chimbidis 76370,1366 To: Mike Knudsen 72467,1111 Where can I buy a midi PACK? #: 8520 S10/OS9/6809 (CoCo) 01-Dec-90 17:59:35 Sb: #CoCo 3 Emulator? Fm: John M Semler 74020,736 To: all Would it be legal to create a Coco 3 hardware emulator that runs on Macintosh hardware? I am asking this because I would like to run OS9 Level II on my MacIIcx to keep up with you guys! Of course if I create such a thing It will be uploaded for free. It would be interesting to see how much faster this emulated CoCo 3 would run compared with the real thing . John Semler There is 1 Reply. #: 8530 S10/OS9/6809 (CoCo) 02-Dec-90 05:38:55 Sb: #8520-#CoCo 3 Emulator? Fm: Kevin Darling (UG Pres) 76703,4227 To: John M Semler 74020,736 (X) John - interesting thought! One of the guys here has been working on a similar thing: it runs L-II/6809 software under OS9/68K. It's written well enough that it could probably be made to run under other systems also (altho I suspect that it would help a lot if the other system was also a multitasking one). But even tho this emulator is highly tuned, it's still tens of times slower (at least) than a coco-3, even when run on an 030. It's still quite useful, but it points out that 6809 code is very optimized and powerful... emulating the 09 seems to be harder than emulating other, simpler processors. There are 2 Replies. #: 8534 S10/OS9/6809 (CoCo) 02-Dec-90 11:06:06 Sb: #8530-#CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Kevin Darling (UG Pres) 76703,4227 (X) > "... emulator ... tens of times slower ..." I would of thought that I could at least break even with a 6809 emulator running on a 16MHz 68030. Case in point, here is an excerpt from page 30 of the manual for SoftPC EGA/AT for 68030 Mac's (It runs MSDOG version 3.30): "The absolute speed of SoftPC EGA/AT depends primarily on the speed of your Macintosh. On the slowest SoftPC-compatible Mac, the original Mac II, the Norton Computing Index for SoftPC EGA/AT is about two and a half times the speed of the original PC. On the fastest Macs, the Computing Index is about the same as that of the original AT, or about seven times the Index of the original PC." Who is this other guy that implemented a LII emulator? Is he willing to share his work with others for free? Besides, I already got a cute Icon made up for the CoCo III emulator. I just need to add a CODE resource to it to complete my project . There are 4 Replies. #: 8543 S10/OS9/6809 (CoCo) 02-Dec-90 15:39:30 Sb: #8534-CoCo 3 Emulator? Fm: Kevin Darling (UG Pres) 76703,4227 To: John M Semler 74020,736 (X) John - Bob Santy wrote the emulator over the last year or so... I believe that he'll be selling it. It includes source for the customizable I/O section, I think (the places where I$ and SS.calls must be translated). I have no idea what would be involved in a Mac port of it, altho we've talked about his porting it to say, OS-9000. (He wrote it in C, but has def'd it so that his extensive 68K asm quick routines can be compiled instead). I've used it at strange times: like when I didn't have a wordcount util under 68K. So I just used my coco "wc" util under the emulator instead. Sure, it's slower than a 68K util, but when you want to use something in a hurry without writing a new one, you can't beat it . He says the 6809 C compiler even runs under it. As for the SoftPC comparisons.... well, remember how we all would talk about how a 2mhz 6809 is pretty fast at many things? We weren't kidding! And remember that the 6809 has addressing modes even a 680x0 cpus doesn't have! Plus you have two separate 8-bit regs (A and B) which sometimes are concatenated into the one 16-bit reg (D). Not to mention that it sets condition codes on almost all instructions, which really slows down emulations. So faking a 6809 is _much_ harder than emulating early Intel cpus. A 680x0 emulating an AT is kinda like making an adult fake babytalk: no problem. A 680x0 emulating a 6809 is like making the same adult fake teenage slang: similar language, but sophisticated in a different way, and harder to fake ;-). PS: on the CODE resource comment! hehe - kev #: 8565 S10/OS9/6809 (CoCo) 03-Dec-90 06:59:56 Sb: #8534-CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) John: I've tried my darndest to get the emulator to go faster (in pure 6809 CPU terms) and I haven't figured out a way to do it and still have a working program. The emulator I have is a 6809 object code "interpreter" with an OS9-6809 "emulator". I use the terms individually to describe the two basic parts of the utility because they are different conceptually. The 6809 address space sections (TEXT and DATA) is kind of "emulated" as well. Here's a list of things to think about: o The 6809 is an 8 bit machine with no restrictions on the address of an object. The 68000 is a 16 bit machine with byte and word object differentiation. At any point in the interpreter, a memory reference to a word object can take place. Therefore, all accesses to the emulated address space are byte wide, slowing it down. o As Kevin pointed out, the D register is a nasty. I keep the A and B registers in global 68000 registers, but must glue them together every time D is referenced. o All 6809 registers are kept in global 68000 registers. X and Y in data registers and PC, S and U in address registers. But, as mentioned above, stack pushes and pulls force the disassembly and re-assembly of the words. The address registers have the added slow-down of having to be normalized to the 6809 64K space. o Perhaps the nastiest slow-down is the darned condition codes. The 6809 and 68000 condition codes are tantalizingly similar and annoyingly dis-similar. Plus, the 6809 CC register must be faithfully emulated so the program dosen't fail on a branch. I'm still trying to figure out how this can be streamlined. For now, every instruction that can alter the CC register has to do it correctly according to the 6809 rules. Check out the differences in rotates and the lack of a 68000 X-bit conditional branch. (continued) #: 8566 S10/OS9/6809 (CoCo) 03-Dec-90 07:00:45 Sb: #8534-#CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) (continued) I should note that the "emulator" dosen't appear to be slow if a program does a lot of I/O. The operating system interface (especially the I/O stuff) runs pure 68000 code and isn't too bad. A port to the MAC should be fairly straightforward assuming that the MAC can support the OS9 level II system calls needed. The current version runs on OSK and most of the calls are one to one. I don't know the MAC, so I can't say how easy it would be. Start by comparing your MAC's C runtime library with OS9 level II's system calls. Any ideas on the above would be appreciated. Bob Santy There is 1 Reply. #: 8583 S10/OS9/6809 (CoCo) 04-Dec-90 03:41:53 Sb: #8566-#CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Bob Santy 76417,714 (X) Bob - Maybe I do have an idea... Why couldn't we build an OS9 6809 object program loader that also creates an equivalent 680X0 phantom executable object. This peusdo interpreter would not need to perform any 6809 opcode fetches since it "knows" where it is at and what it is doing at all times. What I am proposing is a fast 6809 to 680x0 object code translater/loader that creates a highly optimized "peusdo" interpreter for each 6809 object program it loads. Each 6809 opcode would be compiled into a series of 680x0 instructions obviating the need for an opcode fetch. This model would break down for OS9 programs with self modify code. The OS9 Debug command would not be able to set breakpoints since this phantom is created only at program load time. Also programs that run amuck and destroys its own 6809 object code space will not crash this phantom. What do you think? There is 1 Reply. #: 8585 S10/OS9/6809 (CoCo) 04-Dec-90 07:36:51 Sb: #8583-#CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) John: Such a "translator" is actually in the works here. The problem to be solved is not as simple as it appears. In order to correctly translate 6809 object to 68000, the 6809 code must be interpreted and converted only when the actual program function is verified. How many disassemblers (as good as they may be) are actually guaranteed to produce 100% correct source? This is my basic problem. I need to guarantee that the resultant 68000 code is faithful to the original. By the way, I can only generate 68000 code in USER mode to allow the program to be used on a 68000. I don't have a 68020 to test on and will leave any optimizations available on the '20 (and '30) for later. With the above in mind, it would be possible to generate a 68000 object that was faithful to the original to the extent that the original was interpreted. One would "exercise" the 6809 object to take it through all possible paths. Some method would be available (a special trap) to inform the user of an unexercised path in the 68000 executable. Then the program would be extended by running the interpreter again. That's the current theory anyway. Even with that kind of conversion working, there's still the problem of byte/word boundries. What if the 6809 program had a series of byte addressable objects that were ALSO referenced by word operations as well? This would be a tough problem to solve although not impossible. Bob Santy There is 1 Reply. #: 8605 S10/OS9/6809 (CoCo) 04-Dec-90 21:59:41 Sb: #8585-#CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Bob Santy 76417,714 (X) > "...the 6809 code must be interpreted and converted only when the actual program function is verified..." I disagree. The translator I have in mind can translate 6809 object code into 680x0 code with only 4 bytes of lookahead in a single pass! I don't care if it is code or data as I am only concerned about constructing macro cells for each program memory location that specifies how the state of the 6809 microprocessor changes if the PC pointer was pointing to it (macro cells are all the same size). Kinda like a strip down version of the MC6809 for each memory location. The "Fast" mode of 6809 emulation assumes that the OS9/6809 program is well behaved (software does not generate code and execute it). The "Slowpoke" mode of emulation would cause the pseudo interpreter to incrementally update itself for each memory write for complete 6809 emulation. I believe most OS9 programs are well behaved which makes the "Fast" mode of emulation a practical first choice. I will illustrate my point with a short code fragment (Assume that the cell size is 16 bytes in this example). Virtual 6809 address space | 680X0 address space | Relative Location Value Opcode | 6809 Macro Cell Cell address $E503 86 LDA #$43 | "LDA #$43" $E5030 $E504 43 | "COMA" $E5040 $E505 8B ADDA #$53 | "ADDA #$53" $E5050 $E506 53 | "COMB" $E5060 . . . . . . . . . Note that I have generated macro cells for "COMA", and "COMB". This ensures that the emulator will correctly execute even if the programmer got sneaky and jumped into the middle of a "valid" 6809 program instruction. John Semler There are 4 Replies. #: 8645 S10/OS9/6809 (CoCo) 08-Dec-90 15:33:02 Sb: #8605-CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) John: I decided to check out your suggestion of using a cell approach to translation. The following message shows the 68000 code that I believe is necessary for your example instruction sequence mapped out into cells. I'm afraid that maintenance of the 6809 CC register prohibits the use of 16 byte cells (they are too small to accomodate the code necessary in COMA, COMB and ADDA #$53). These cells are full with a 32 byte size. Since I have only taken the example instructions and coded them into cells and they are relatively simple ones, I have a sinking feeling that 32 bytes is not even enough. They DO however illustrate my original statement that the 6809 condition codes must be emulated for automated translation to actually work. I have not determined how the data space references would be handled using this cell approach. I presume that the data references would be handled by using the first byte of each cell to hold the 6809 data and the code in the cells would assemble and disassemble 16 bit references to this data space. That would certainly add to the complexity in such cells. Another troublesome issue is how this approach would handle stack frame references. I think that psh and pul instructions would probably use the 68000 stack, but then what about stack offset references? (continued) #: 8646 S10/OS9/6809 (CoCo) 08-Dec-90 15:33:51 Sb: #8605-CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) (continued) Finally, I feel it necessary to voice a concern that I have about the practicality of a cell approach. 16 byte cells (which most probably cannot work at all because they are too small) would require 1 Mb of cells for the maximum 6809 space of 64k. The 32 byte cells that I illustrate (marginal at best) require 2 Mb. I think that means many OS9 68000 users would not be able to use it. The example in the following message assumes the following: 1. That D0 is used globally for the emulated A register. 2. That D1 is used globally for the emulated B register. 3. That data space for the running program is available with its base address in A6. This is OS9 68000 convention. The global 6809 CC register is shown as the first byte of this space. 4. That several 68000 data registers are available for scratch. I have used D4 and D5. Bob Santy #: 8647 S10/OS9/6809 (CoCo) 08-Dec-90 15:34:56 Sb: #8605-#CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) * * code for LDA #$43 * cell_0 0000 103c 0043 move.b #$43,d0 this is easy 0004 022e 00f10000 andi.b #$f1,cc09(a6) clear N,V and Z 000a 6034 bra.s cell_2 skip next cell 000c 4e71 nop this cell is padded 000e 4e71 nop 0010 4e71 nop 0012 4e71 nop 0014 4e71 nop 0016 4e71 nop 0018 4e71 nop 001a 4e71 nop 001c 4e71 nop 001e 4e71 nop * * code for COMA * cell_1 0020 1a2e 0000 move.b cc09(a6),d5 get 6809 CC 0024 1805 move.b d5,d4 save EFHI bits 0026 0204 00f0 andi.b #$f0,d4 * * Put 6809 CC in 68000 CCR * 002a 44c5 move d5,ccr prepare for "COMA" * * 68000 not.b will set Z, N and V properly * 002c 4600 not.b d0 emulator A 002e 42c5 move ccr,d5 get CCR * * But 6809 COMA sets C! * 0030 0005 0001 ori.b #1,d5 set C 0034 0205 000f andi.b #$0f,d5 preserve NZVC 0038 8a04 or.b d4,d5 restore EFHI 003a 1d45 0000 move.b d5,cc09(a6) save 6809 CC 003e 4e71 nop fill cell (continued) There is 1 Reply. #: 8653 S10/OS9/6809 (CoCo) 08-Dec-90 16:41:59 Sb: #8647-#CoCo 3 Emulator? Fm: James Jones 76257,562 To: Bob Santy 76417,714 (X) Wouldn't it be possible, when translating 6809 code, to do some lookahead to see whether an instruction is followed by other instructions that both (1) don't depend on the current value of the condition code and (2) set the condition code themselves, so that when translating a given instruction preceding it, you know from context that it really doesn't have to dot the i's and cross the t's on condition code setting? You'll almost certainly want to do something special for the usual implementation of the BASIC09 syscall procedure, which pushes an SWI2 on the stack. :-) Programs that generate code on the fly, even if they do it in a re-entrant way, are nasty for this sort of code translation! There is 1 Reply. #: 8654 S10/OS9/6809 (CoCo) 08-Dec-90 17:50:36 Sb: #8653-CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: James Jones 76257,562 (X) James: Well, yes. However, I hardly think that the cell size can be reduced to 16 bytes by such a technique. Even if it could, a 16 byte cell would call for a 1 Mb space for the cells in a 64k translated address space. Just not practical. My original suggestion of doing the translation by actually running the target program emulation would seem to offer the most opportunity for the tightest 68000 code. The resultant code would not be cell oriented and consequently no restrictions on the 6809 to 68000 relationship. The exercising approach would be better able to handle the BASIC09 and other such nasties as well. I suppose that this kind of a translator would be able to figure out that the PC got into data space and complain. I don't think that a 68020 would allow the address space to change like that. That would depend on the memory management arrangement for the particular machine. We could probably get a 68000 to fake it. In any event, I think a complaint and refusal would be the way I'd go. BASIC09 would be un-translatable! However, BASIC09 does run using the working emulator/interpreter. Bob Santy #: 8648 S10/OS9/6809 (CoCo) 08-Dec-90 15:36:02 Sb: #8605-#CoCo 3 Emulator? Fm: Bob Santy 76417,714 To: John M Semler 74020,736 (X) (continued) * * code for ADDA #$53 * cell_2 0040 183c 0053 move.b #$53,d4 get byte 0044 1a2e 0000 move.b regs(a6),d5 get CC 0048 1405 move.b d5,d2 copy and 004a 0202 00f0 andi.b #$f0,d2 preserve EFHI 004e 44c5 move d5,ccr make CC current 0050 d004 add.b d4,d0 add to A 0052 42c5 move ccr,d5 get CC 0054 0205 000f andi.b #$0f,d5 mask NZVC 0058 8a02 or.b d2,d5 fix CC 005a 1d45 0000 move.b d5,regs(a6) in ram 005e 6020 bra.s cell_4 skip next cell * * code for COMB * cell_3 0060 1a2e 0000 move.b cc09(a6),d5 get 6809 CC 0064 1805 move.b d5,d4 save EFHI bits 0066 0204 00f0 andi.b #$f0,d4 * * Put 6809 CC in 68000 CCR * 006a 44c5 move d5,ccr prepare for "COMB" * * 68000 not.b will set Z, N and V properly * 006c 4601 not.b d1 emulator B 006e 42c5 move ccr,d5 get CCR * * But 6809 COMB sets C! * 0070 0005 0001 ori.b #1,d5 set C 0074 0205 000f andi.b #$0f,d5 preserve NZVC 0078 8a04 or.b d4,d5 restore EFHI 007a 1d45 0000 move.b d5,cc09(a6) save 6809 CC 007e 4e71 nop fill cell cell_4 There are 3 Replies. #: 8664 S10/OS9/6809 (CoCo) 10-Dec-90 03:12:01 Sb: #8648-CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Bob Santy 76417,714 (X) Bob, I recoded the example over again and I was able to make them fit in 16 bytes. I made use of the following facts: o On entry to or exit from any cell, the 68000 NZVC bits are exactly the same as the emulated 6809 NZVC bits. o Code that will overflow a cell is made into a template. I can pass up to two short words of data to a template without destroying the integrity of the NZVC bits. I don't know how many templates I would have to make but I know that it is less than 1500 (). o The emulated 6809 program counter is implicit in the 68000 program counter. The code for "adda #$53" is complex because of the H bit. Did you take this into account in your code? Did I calculate it right? The code for "coma" and "comb" is trivial. The code for "lda #$43" is slightly more complex because I have to preserve the 68000 C bit. I also included two more examples. One is "BSR $100" and it illustrates the absolute limits in calling a template. It also demonstrates how the 6809 stack frame references are emulated. The other "TFR CC,B" shows how I remap the 68000 NZVC bits into the 6809 CC register before swapping CC and B. I concede the point that this idea is impractical on all but the largest system. I have an 8Mb 68030 system so this will not deter me from trying out the idea. The register assignment I am thinking about for my model is as follows: D0 emulates A register D1 emulates B register D2 emulates CC register D3 emulates DP register A0 emulates S register A1 emulates U register A2 emulates X register A3 emulates Y register The following data structure emulates the 6809 address space: vsect m6809 dz.b 65536 ends This is the first time I have coded in 68000 assembly language so it is definite possibility that the code fragments have some bugs. The code fragment follows... (continued) #: 8665 S10/OS9/6809 (CoCo) 10-Dec-90 03:14:41 Sb: #8648-CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Bob Santy 76417,714 (X) psect test_a,0,0,0,0,0 nam test_a vsect * * 6809 address space (data space emulated here) * m6809 dz.b 65536 ends * * Code for "LDA #$43" * cell_0 bcs.s cell_0a % preserve C bit moveq #$43,d0 % NZVC bits are ok bra.s cell_2 % skip to next cell cell_0a moveq #$43,d0 % NZV bits are ok ori #$01,ccr % set C bit bra.s cell_2 % skip to next cell nop * * Code for "COMA" * cell_1 eori.b #$ff,d0 % NZV bits are ok ori #$01,ccr % set C bit bra.s cell_2 % skip to next cell nop nop nop * * Code for "ADDA #$53" * cell_2 move.b #$53,d7 % set up parameter jsr adda_imed % call template bra.s cell_4 nop nop * * Code for "COMB" * cell_3 eori.b #$ff,d1 % NZV bits are ok ori #$01,ccr % set C bit bra.s cell_4 % skip to next cell nop nop nop * * Code for "EXG CC,B" * cell_4 jsr exg_cc_b % call template bra.s cell_5 % skip to next cell nop nop nop nop * * Code for "BSR $100" * cell_5 movea.w #$0007,a5 % PC offset movea.w #$0100,a4 % bsr address jsr bsr_rel % call template bra.s cell_7 % goto next cell (continued in next message) #: 8666 S10/OS9/6809 (CoCo) 10-Dec-90 03:17:33 Sb: #8648-CoCo 3 Emulator? Fm: John M Semler 74020,736 To: Bob Santy 76417,714 (X) (continued from previous message) * * Template for "xBSR $" * bsr_rel move ccr,d7 % save NZVC subq #2,a0 % SP predecrement clr.l d6 % clear b32-b16 move.w a0,d6 % save SP in b15-b0 move.w a5,d5 % free up an addr reg move.l a6,a5 % data area ptr adda.l d6,a5 % add in SP offset move.w d5,(a5) % save PC on 6809 stack clr.l d4 % clear b31-b16 move.w a4,d4 % get bsr address asl.l #4,d4 % calculate cell offset lea cell_0,a4 % get first location adda.l d4,a4 % add cell offset move d7,ccr % restore NZVC jsr (a4) % call subroutine addq #2,a0 % pop 6809 SP rts * * Template for "ADDA #$" * adda_imed andi.b #$df,d2 % clear H bit in CC move.b d0,d6 % make a copy of A andi.b #$0f,d6 % mask off lsn move.b d7,d5 % get operand andi.b #$0f,d5 % mask off lsn add d5,d6 % add the two halves andi.b #$10,d6 % discard b0..b3 asl #1,d6 % H bit in b5 or.b d6,d2 % or H bit into CC add.b d7,d0 % NZVC bits ok rts * * Template for "EXG CC,B" * exg_cc_b andi #$f,ccr % mask off 68000 NZVC move ccr,d7 % fetch 68000 NZVC andi.b #$f0,d2 % discard invalid 6809 NZVC or.b d7,d2 % save NZVC to 6809 CC move.b d1,d7 % make a copy of B exg d1,d2 % CC <-> B andi.b #$0f,d7 % mask off new NZVC move d7,ccr % set 68000 CC rts ends #: 8876 S10/OS9/6809 (CoCo) 25-Dec-90 13:01:39 Sb: #8534-#CoCo 3 Emulator? Fm: MOTD Editor..Bill Brady 70126,267 To: John M Semler 74020,736 (X) But the book on SoftPC/EGA/AT fibs. On my 32Mhz '030 Mac II Norton pegs it at only the speed of a NEC V20. (1.5x an 8088 XT @ 4.77MHz.) & Norton don't measure screen speed. SoftPC is a snail. Try running PC Paintbrush! zzzzz There is 1 Reply. #: 8925 S10/OS9/6809 (CoCo) 28-Dec-90 06:14:41 Sb: #8876-CoCo 3 Emulator? Fm: John M Semler 74020,736 To: MOTD Editor..Bill Brady 70126,267 Bill, Those are the kind of results I would expect for a 16Mhz '030. What kind of accelerator are you using? Accelerators that consist solely of a 68030 and a 32Mhz crystal only speeds up the execution unit, bus cycle time is still 16Mhz. Only marginal improvement. (Maybe I am wrong?) The 32Mhz Dove MaraThon 030 board speeds up the Mac II by a third according to the August 1990 MacWorld review on accelerators. John #: 8537 S10/OS9/6809 (CoCo) 02-Dec-90 12:51:26 Sb: #8530-CoCo 3 Emulator? Fm: Mark S 76004,373 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, Keep in mind that the Coco-3 was optimized in hardware for level II It's more then just a 6809 emulation to achive equivilent results. #: 8525 S10/OS9/6809 (CoCo) 01-Dec-90 20:48:53 Sb: #VRN Fm: Ted Miller 76545,457 To: 76625,2273 (X) Hello Bruce; Just a message of appreciation for your VRN upload. Its cleared up a long standing and puzzling problem I was having with my system. Also looking forward to your new ACIA driver. Hopefully it will clear up a few rs232 problems I've been having. Ted Miller There is 1 Reply. #: 8546 S10/OS9/6809 (CoCo) 02-Dec-90 16:38:07 Sb: #8525-#VRN Fm: Bruce Isted (UG VP) 76625,2273 To: Ted Miller 76545,457 (X) Ted, Glad you like VRN. If you don't mind, what was the problem that it cleared up? Just wondering... Bruce There is 1 Reply. #: 8556 S10/OS9/6809 (CoCo) 02-Dec-90 20:23:50 Sb: #8546-#VRN Fm: Ted Miller 76545,457 To: Bruce Isted (UG VP) 76625,2273 (X) Hi Bruce; Its kind of a long story. The ramdisk software I have installed in my system,written by Ken Drexler, would not work with the cron utility. Cron would error out saying that it didn't see a ramdisk installed. Cron wasn't the problem as it would work with a different ramdisk(i.e Kevin Darlings 'Rammer'). No matter what combination of boot disks I tried cron wouldn't work.I now realize that my nil driver (being the common denominater on all boot disks)must have been the problem for cron works fine with your VRN and nil descriptor installed in conjunction with Ken Drexler's ramdisk. The other problem was with a C Compiler user interface I use when playing around with C. All temporary files and libs are used with the ramdisk. With VDGInt, FTDD,and AGIvirq installed my source would not compile when using the interface program. I would get a ramdisk sector error. Without the above modules the interface works fine with the ramdisk. However with your VRN,ftdd,vi installed I have experienced no problems with the interface program and VDGInt in the boot disk. I don't have any idea why I should have had these problems.All I know is that the problems disappeared when I installed your VRN modules. Once again thanks. Ted Miller There is 1 Reply. #: 8580 S10/OS9/6809 (CoCo) 04-Dec-90 00:01:37 Sb: #8556-#VRN Fm: Bruce Isted (UG VP) 76625,2273 To: Ted Miller 76545,457 (X) Ted, Very strange... I don't know why VRN should apparently work better than NILDRV, because never found anything really wrong with NILDRV. It was more a case of VRN acted like a null driver anyway, so why not make a NIL descriptor for VRN? However, both FTDD and AGIVIRQDr had a few things wrong with them. But I can't see that they could cause any problems if they weren't in use, as when you're using the C compiler. Or do you play Leisure Suit Larry while waiting for C compiles? Perhaps its just because VRN is a littel smaller than FTDD, but does the job of FTDD plus AGIVIRQDr plus NILDRV, and saved you a bit of system space? I don't know, but I'm glad it helped you out. Bruce There is 1 Reply. #: 8623 S10/OS9/6809 (CoCo) 06-Dec-90 22:20:26 Sb: #8580-#VRN Fm: Ted Miller 76545,457 To: Bruce Isted (UG VP) 76625,2273 (X) Hi Bruce; The nil driver software I was using was copied from the 'Complete Rainbow guide to Os9' originally designed for a level 1 system. Maybe something in that caused a problem although it looked so simple.When I tested it and it worked it didn't dawn on me that it was the problem. I do have a large bootfile (>35k) so maybe that was it. Also I've applied your cc3io patch for the regular hires mouse. The most noticable difference? Before I couldn't run my terminal without losing characters when the gshell screen was displayed on my host Coco. Now there is no problem. Right now I'm limited to 4800 baud as I don't have the irq hack intsalled for my terminal port. Perhaps your aciapak replacement will allow 9600 baud without the hack? Any way great work. Ted Miller There is 1 Reply. #: 8652 S10/OS9/6809 (CoCo) 08-Dec-90 16:40:30 Sb: #8623-VRN Fm: Bruce Isted (UG VP) 76625,2273 To: Ted Miller 76545,457 (X) Ted, Glad you like the stuff, and thanks. Kevins Darling's trick to improve IRQ response was pretty slick, I think! I'd actually done similar things in other drivers, but it never occurred to me that it'd work in CC3IO too. Bruce #: 8539 S3/Languages 02-Dec-90 13:28:11 Sb: #'C' problem Fm: Jim Peasley 72726,1153 To: 'C' mavens Anybody want to help save my sanity?? I'm trying to parse out the year from an input string passed to a function, and can't see where I'm going wrong. Sample C code : ------------------------------------------------------------------------ print_event(Inline) char Inline[81]; { int e_yr; ... ... char ev_yr[3]; char *inptr = Inline; ... ... p strncpy(ev_yr,inptr + 6,2); /* copy bytes 6 & 7 to ev_yr */ itoa(e_yr,ev_yr,10); /* convert int e_yr to char ev_yr base 10 */ printf("\nEvent year = %s",ev_yr); <=== always prints "2" ... ... ------------------------------------------------------------------------ I'm using Turbo C and stepping through the code line-by-line, and still can't see what's wrong... anybody else see the problem?? BTW - Turbo C is a neato development environment - lots of on-screen help and it's lightning FAST, but the CoCo C compiler catches some errors that TC seems to ignore. ...Jim There is 1 Reply. #: 8540 S3/Languages 02-Dec-90 15:00:12 Sb: #8539-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Off the top: Are you REALLY passing an ARRAY of characters to the function, or did you pass a pointer to that array? If you called the function with the name of the array, you passed a pointer: char junk[81]; gets(junk); do_function(junk); .. as in this scenario. It'll also be easier to manipulate (and faster) in the target function. I've never passed an array in TC, but don't think you CAN under MW C. Also - on your reference to strncpy(), you said you were copying the 6th and 7th characters... you actually started the copy at the 7th character when you did this: strncpy(target, source+6, 2); Pete There is 1 Reply. #: 8553 S3/Languages 02-Dec-90 20:10:40 Sb: #8540-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Yep, commenting error on the 6/7 bytes - stepping thru the program, I can look at the variable (or pointer + offset) and see the value at any time. Just got thru with 2 weeks of classroom 'C' and I guess all of it hasn't sunk in yet. That's what I'm trying to do now, practice until I get all the 'not quite clear' points so that I understand them. The name of the array is what's being passed to the function, and I'm declaring a local pointer to the char array. Have any ideas on why strncpy doesn't seem to be doing it's thing? ...Jim There is 1 Reply. #: 8568 S3/Languages 03-Dec-90 08:53:21 Sb: #8553-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - If you're passing the NAME of the array, then that's automatically a pointer to the array: saying: assuming: char myarray[81]; saying : myarray is the same as &myarray[0] So, if you called a function with 'myarray like so: do_it(myarray); You'd need to declare it at the receiving end like this: do_it(stuff) char *stuff; /* myarray arrived as a pointer to the base of itself*/ { char woof[3]; strncpy(woof,myarray+5, 2); /* grab chars 6 & 7 */ .... } Pete There is 1 Reply. #: 8582 S3/Languages 04-Dec-90 00:20:40 Sb: #8568-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Yeah, your way seems to be a bit more self-documenting than the way I was doing it... but at this point in the game, any way that works is what I'm shooting for! ;-) > do_it(stuff) > char *stuff; /* myarray arrived as a pointer to the base of itself*/ > { > char woof[3]; Hopefully, this'll all become more automatic as time goes on. ...Jim There is 1 Reply. #: 8589 S3/Languages 04-Dec-90 08:44:46 Sb: #8582-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) I'm sure it will (become more automatic). Even with my ASM background, the prodigous use of pointers was baffling. It became clear to me later on that if you simply point to things, vice moving them around, things are MUCH quicker. Probably some of the best tutorial hours I spent were staring at Carl Kreider's code - any of it. I highly reccomend scanning the DL's (esp. the UG LIB) for anything by Carl. He's really a wonderful programmer. Pete There are 2 Replies. #: 8631 S3/Languages 07-Dec-90 10:12:19 Sb: #8589-#'C' problem Fm: Carl Kreider 71076,76 To: Pete Lyall 76703,4230 (X) (Blush) 8-) I don't get around so much, but I get by every so often. I caught the 6809 lib unix time stuff bug and will fix it this weekend and upload fixed version. I can't believe that took this long to find! Carl There are 2 Replies. #: 8632 S3/Languages 07-Dec-90 13:18:03 Sb: #8631-#'C' problem Fm: Pete Lyall 76703,4230 To: Carl Kreider 71076,76 (X) It has been found and worked around in the past. And stop blushing... it makes the other characters on the screen hard to read .. (grin).. Pete There is 1 Reply. #: 8668 S3/Languages 10-Dec-90 09:43:45 Sb: #8632-'C' problem Fm: Carl Kreider 71076,76 To: Pete Lyall 76703,4230 (X) Well, I stll feel dumb. But i is fixed now, which of course breaks your work around .... (grin)... Carl #: 8688 S3/Languages 12-Dec-90 09:44:06 Sb: #8631-#'C' problem Fm: Paul K. Ward 73477,2004 To: Carl Kreider 71076,76 (X) Carl, I have been talking to a professional photographer here on some brochure and advertising issues. Name is RC Kreider, the son of one of five brothers who left central PA years ago to ove to (move to, oops) Ohio and Illinois. Any relation, I wonder? Paul There is 1 Reply. #: 8691 S3/Languages 12-Dec-90 12:20:14 Sb: #8688-'C' problem Fm: Carl Kreider 71076,76 To: Paul K. Ward 73477,2004 Probably are related. My kin landed in PA late 1700's or so and then moved into Ohioo,Ill, Ind, Kansas, and so on. Lots of roving preachers. #: 8639 S3/Languages 08-Dec-90 11:32:10 Sb: #8589-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; My weekly question on "C" this week is on memcpy and strcat. I seem to be missing the boat somehow, and would appreciate a "pointer" to whtre I'm erring. >> inline = "01/22/54Tiny Tim*Birthday" << addr. passed to funct. 'print_event' print_event(inline,yr) char *inline; int yr; { int s_len, ev_len; char date[6], *eptr, name[32]; memcpy(date,inline,5); /* pull in 1st 5 bytes */ strcat(date,'\0'); /* and null term it */ eptr = strchr(inline,'*'); /* loo' for delimiter */ s_len = strlen(eptr); /* get length of event + '*' */ ev_len = strlen(inline + 8); /* get length of instring - date*/ memcpy(name,(inline + 8),(ev_len - s_len)); /* copy only name */ strcat(name,'\0'); /* and null term it */ printf("\n%s %s",date,name); return; } >> date = "01/22 %#Tiny Tim%#&$!"#$!" >> name = "Tiny Tim%$#!%$%!"#$#$" In both cases, my strings don't get null terminated and it prints garbage chars after them. ...Jim There are 3 Replies. #: 8640 S3/Languages 08-Dec-90 12:40:47 Sb: #8639-#'C' problem Fm: Bruce MacKenzie 71725,376 To: Jim Peasley 72726,1153 (X) Jim, Strcat[date,'/0']; is not the way to null terminate a string. Strcat assumes the string pointed to by date is already null terminated. It searches along it until it finds a null (from the output it obviously doesn't find a null until it's searched along several characters beyond the space set aside for the string). It then tacks on the second string, a null string in this case, at that position. To null terminate date all you need do is explicitly assign the null: date[5]=0; There are 2 Replies. #: 8649 S3/Languages 08-Dec-90 15:44:43 Sb: #8640-'C' problem Fm: Jim Peasley 72726,1153 To: Bruce MacKenzie 71725,376 (X) Thanks Bruce, I've been tearing my hair out over this one. Originally, I was trying to use strncpy, but found a caveat that I had overlooked : "if s2 is longIr than s1, the string is not null terminated". Since s2 will always be longer in my case, I thought I'd try memcpy and explicitly put a '\0' at the end. Never occurred to me that strcat has to find the original '\0' in order to know where to begin concatenating! I'll try yours and Pete's suggestion in a bit and let you know. Thanks, ...Jim #: 8655 S3/Languages 09-Dec-90 11:16:54 Sb: #8640-#'C' problem Fm: Jim Peasley 72726,1153 To: Bruce MacKenzie 71725,376 (X) Bruce; (&& Pete && JJ) Explicitly assigning the null byte worked like a champ! Thanks guys. Lots of things in 'C' are not too intuitive, but learning thns way, I'll not soon forget lessons learned! success = ((goal != experiment && frust_lvl[i] < MAX)?try_again(),++i:ask_cis()); ...Jim There is 1 Reply. #: 8669 S3/Languages 10-Dec-90 16:46:27 Sb: #8655-#'C' problem Fm: Bruce MacKenzie 71725,376 To: Jim Peasley 72726,1153 (X) Jim, Good deal. Keep with it and I hope you learn to love C as much as I do. It's a neat language. There are 2 Replies. #: 8683 S3/Languages 11-Dec-90 23:32:33 Sb: #8669-'C' problem Fm: Jim Peasley 72726,1153 To: Bruce MacKenzie 71725,376 (X) Bruce; Yah, I'm beginning to like it (he sez, gnashing teeth and pulling hair!). ...Jim #: 8727 S3/Languages 14-Dec-90 00:00:58 Sb: #8669-#'C' problem Fm: Jim Peasley 72726,1153 To: Bruce MacKenzie 71725,376 (X) Bruce; Maybe you can help- #define INFILE c:\\system\\dates.fil FILE *fp; main(argc,argv) { add_event(); etc. } add_event() { char outstring[80]; etc. if ((fp = fopen(INFILE,"a+")) == NULL) fprintf(stderr,"Cannot open output file\n"); else { if (fputs(outstring,fp) == EOF) fprintf(stderr,"File write failed\n"); } f lose(fp); clearerr(fp); return; } This code fragment doesn't want to write to the output file for some reason. Reads work fine using the same #define for INFILE, and checking the last char of "fputs(outstring,fp)" returns the correct char. I'm obviously doing something wrong, but for the life of me, can't see what it is! Can you give me a clue? Thanks, ...Jim p.s. not to worry about the obvious MS-DOS file spec, I've ifdef'd similar calls for OS9! There is 1 Reply. #: 8736 S3/Languages 14-Dec-90 09:05:09 Sb: #8727-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Other than the fact that your #defined name isn't in quotes, I don't see any immediate problem (granted, I'm still on my first cup of coffee...) Pete There is 1 Reply. #: 8744 S3/Languages 15-Dec-90 01:37:38 Sb: #8736-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Again, I missed the quotes in the translation... they're there in the source though, and the pgm. will read from the file O.K., so I know that it's getting expanded properly. Since I posted the message, I've tried 'fopen(INFILE,"a")', "a+", "at", and "at+", all without the expected results. Using the debugger, and watching the HD lights, I can see that the fopen and fputs statements, as well as the fclose statement cause some disk activity, but nothing appears in the file after the data that's already there. Actually, the new data doesn't appear ANYwhere! Oh, and using the debugger, the outstring is what it should be. Messing with it tonight though, I notice that the file IS being appended - it's grown by 130+ bytes, although when I list it or look at it with an editor, none of my fresh input is there! Curioser && curioser by the minute! ...Jim There is 1 Reply. #: 8748 S3/Languages 15-Dec-90 08:13:46 Sb: #8744-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Let me see the ACTUAL code. Is it in TC? If yes, I can diddle with that, as I have an AT with TC 2.0 on it... Pete There is 1 Reply. #: 8754 S3/Languages 15-Dec-90 15:03:57 Sb: #8748-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) O.K. Pete, I'll shoot you the code and a small data file in PKZIP format (since you're using TC) to DL10 in a bit. ...Jim There is 1 Reply. #: 8760 S3/Languages 15-Dec-90 19:17:09 Sb: #8754-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - I dl'ed and compiled it, and ran it (on instinct anyway). I think you'll be in for a surprise... Your added data DID make it into the file. Two gotchas: 1) The original file had a PHYSICAL control Z at the end of the data. That means that does won't recognize any data beyond that point (I used a Unix 'vi' editor clone on the data file, which ignores CTRL Z, to find this out). DOS no longer requires a CTRL Z at the end of text files, so I'd remove it if I were you. 2) Your added records (your birthday?.. hmm - you're 4 years older than Marsha) had no EOL's on them. I also noted you had problems with 'system(CLS)'.... why not do it the direct way (under dos) and use 'clrscr()'. That should get you rolling, hopefully. If not, I only did about a 5 minute cursory scan, and may not have dug out all the nasties. Pete There are 3 Replies. #: 8782 S3/Languages 16-Dec-90 10:41:31 Sb: #8760-'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Thanks Pete, I'll peruse your msg. and get back later today. Got some Xmas parties to attend & some honey-dews. ...Jim #: 8786 S3/Languages 16-Dec-90 12:10:08 Sb: #8760-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; 15 mims before we have to go, so... YES!! Never thought to use another editor to look at the file. Using 'WRITE' under W3.0 shows the CTL-Z. I see what you mean about the newlines, and have added one to the end of the string to be stored. However, after deleting the CTL-Z from the original file, another one seems to have crept back in. It's gotta be DOS that's doing this, as the file on my CoCo has NO control chars, and I simply PCDOSed it over. Have to think about this a bit and do some reading in the 4.01 manual to try and get around this. BTW, some reading this thread may wonder why I'm asking DOS type questions in this forum. My intent is to become familiar with and proficient enough with the 2 OS's that I can port programs to OS-9. I've got a wealth of DOS sourc available at work & it'd be a shame to let them 'go to waste' . Thanks again, ...Jim There are 3 Replies. #: 8787 S3/Languages 16-Dec-90 12:50:14 Sb: #8786-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Hmm - how are you creating the file? My autoexec.bat and config.sys files don't have CTRL Z's in them. Are you using 'copy con: filename.ext'? Are you using edlin? These might be culprits (dunno if EDLIN appends CTRL Z or not...I just tried it, and it does appear to, as you have to use a CTRL Z to get out of insert mode). Enjoy the parties... I have to go tree shopping later m'self. Pete P.S. Don't plan on getting anything significant done after the parties... There is 1 Reply. #: 8813 S3/Languages 18-Dec-90 00:38:40 Sb: #8787-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; The original incarnation of the date file was PCDOS'd over from the CoCo, but I never thought to look at it for stray control chars. I don't _think_ that PCDOS is doing it, but haven't checked yet. If I remember the sequence correctly, the first attempt at appending the file using 'fputs' seems to work o.k. with subsequent appends being 'invisible'. This is definitely on my list of things to investigate, but it'll probably be after the holidays and the house gets put back together before I get back to it. (Having some foundation work done, and the downstairs is all torn apart!) Later, ...Jim There is 1 Reply. #: 8819 S3/Languages 18-Dec-90 08:55:25 Sb: #8813-'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) JIm - Another possiblity is to use kermit to move the file between machines. It also handles the EOL conversions properly (when not in image [-i] mode). Pete #: 8791 S3/Languages 16-Dec-90 17:57:00 Sb: #8786-#'C' problem Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) I bet that this may be some remnant of MS-DOS's CP/M-like origins. Some utility or program on the PC side may well be padding with CTRL-Z. CP/M, which MS-DOS was written to sort of behave like, at least at first, couldn't tell how long files were other than the number of 128-byte sectors they contained, so the convention for text files came up of marking the end of the good stuff with a CTRL-Z character. Anything past that was junk remaining in the last 128-byte sector of the sort that CP/M disks used. There is 1 Reply. #: 8814 S3/Languages 18-Dec-90 00:38:45 Sb: #8791-'C' problem Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; I think you're right on here... what had me scratching my head was the fact that I could step through the code and "see" the fopen and fputs lines being executed and the corresponding disk activity, yet not see anything new in the file! I'm having a hard enough time getting up to speed without craziness like this! Anyway, fprintf seems to solve the problem for now, and I'll investigate further after the holidaze. Thanks, ...Jim #: 8800 S3/Languages 17-Dec-90 07:39:16 Sb: #8786-#'C' problem Fm: Mark B. Sheffield 76247,1332 To: Jim Peasley 72726,1153 (X) Jim - Be sure to check how the file was opened (translated mode or not). In translated mode, reads will stop when they encounter a ^Z. Similar wierdness happens when writing. There is a global variable that you can set to specify the default mode (translated or not). Check your compiler manual, give it a try, and let me know. Translated mode can cause all kinds of headaches, so I make sure to never use it (except when it sneaks up on me ;-) ) -mark There is 1 Reply. #: 8815 S3/Languages 18-Dec-90 00:38:51 Sb: #8800-#'C' problem Fm: Jim Peasley 72726,1153 To: Mark B. Sheffield 76247,1332 (X) Mark; Do you mean the "t"ext and "b"inary modifiers to the "a"ppend, "r"ead and "w"rite modes? as in "at+", "ab+", etc.? I tried all the append combinations with about the same results - no new data that was visible, although the file size grew with each attempt! This invisible EOF character thing has me intrigued. It's things like this that make me realize just how nice OS-9 is!! BTW, I'm waiting by the front door with my screwdriver in hand! ...Jim There is 1 Reply. #: 8828 S3/Languages 19-Dec-90 08:13:02 Sb: #8815-'C' problem Fm: Mark B. Sheffield 76247,1332 To: Jim Peasley 72726,1153 (X) Jim - Yes. In addition to opening a file +t for text mode, you can open it +b for binary. In MSC 5.0/5.1 the default mode is t. Sooo, it will default to text mode. You have two choices: set the extern global _fmode to O_BINARY ("b"), I think; OR fopen the file +b. Give this a try and let me konw how it works. And BTW, keep your screwdriver ready! -mark #: 8811 S3/Languages 17-Dec-90 23:38:12 Sb: #8760-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Finally got the results that I was looking for by using "fprintf". Still don't know how those control ciars snuck in there when using "fputs". On another subject, have you ever investigated those C function libraries (order now and we'll throw in the source code for only $19.95!) that you see advertised in the back of the computer mags, or in the card packs that seem to find their way to your mailbox after subscribing to almost any DOS mag? For someone in my position - ie. 'greenhorn' - having libs of common functions such as get_date(), get_phone(), or get_ssn() would save lots of time, but on the other hand, I probably wouldn't learn anything. Any experience with them? Maybe it'd be a good idea for someone to collect and AR them (I'll volunteer) if anyone has any good generic routines they'd like to share. C'mon back? ..Jim There is 1 Reply. #: 8818 S3/Languages 18-Dec-90 08:53:16 Sb: #8811-'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - I wouldn't say that you wouldn't learn anything - on the contrary... looking at someone else's (good) code is often the best tutorial there is. Don't forget that DOS mechanisms for getting date and such will be different than in os9. The best tool for sharpening your C skills is a flat nose.. the one you get from falling on your face from trying, and retrying to get code to compile and work. Take it from someone who took years to break the C-phobia (83-86). There is just no substitute for writing volumes of code. Pete #: 8642 S3/Languages 08-Dec-90 13:31:34 Sb: #8639-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - I saw Bruce's answer - that's the crux of the problem. Strcat assumes that the string is already null terminated (that's how it knows where to append whatever it's appending). Memcpy() is useful for raw bytes (i.e. like copying whole structures).... strncpy or strcpy are usually fine for characters. Also, with mem???(), I believe there's a possibility of a byte order problem if you move between CPU families. I'm not sure of that though... Anyway, given your situation, here's how I might approach it: ** the year, and have passed it to the function. */ print_record(recptr, year) char *record; int year; { char date[6], name[32]; char *evptr; date[0] = '\0'; /* just to be sure... */ name[0] = '\0'; /* that they're empty */ strncpy(date, recptr, 5); /* get MM/YY */ date[6] = '\0'; /* null terminate it */ evptr = strchr(recptr, '*'); /* find the delimiter */ if(evptr == NULL) { fprintf(stderr,"No delimiter found in record '%s'\n", recptr); return(-1); /* return error to caller */ } /* This will do 2 things: a) Terminate the name field ** and b) bump evptr so that it points to the event. */ *evptr++ = 0; strncpy(name, recptr+8, 31); /* copy upto 31 chars */ name[31] = '\0'; /* just in case we truncated name */ printf("Date: %s Name: %s Event: %s\n", date, name, evptr); } ================================================================= Pete P.S. I enjoy the questions There is 1 Reply. #: 8650 S3/Languages 08-Dec-90 15:44:46 Sb: #8642-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; > P.S. I enjoy the questions > You don't know how happy that makes me! Having a place to ask inane questions is a _real_ security blanket. Hope your patience is in good supply; I start a M68000 assembler course at the local JC in January! ;-) Are you up and running with the MM/1 yet? ...Jim There is 1 Reply. #: 8656 S3/Languages 09-Dec-90 12:22:07 Sb: #8650-#'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Well, we'll be going through it together.. though not at school. I'm taking compiler writing and calculus this semester... I have just taught myself (more accurate: am still teaching myself) 8086/80286 ASM, at least to the point where I can disassemble code, change it, and reassemble to get it to do what I want. I haven't yet learned 68K ASM, but will be shortly. It looks a LOT easier than *86 low level stuff. Nope - I still don't have an MM/1. Sore subject. Pete There is 1 Reply. #: 8682 S3/Languages 11-Dec-90 23:32:29 Sb: #8656-#'C' problem Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; re:learning M68000 asm. A lot of us will probably be dipping in to the font of knowledge just after the first of the year. Good to know we'll have company! Hope my MM/1 comes in time to use it for homework assignments. Do you know if the supplied S/W includes an assembler? ...Jim There are 2 Replies. #: 8686 S3/Languages 12-Dec-90 08:54:03 Sb: #8682-'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) I believe that the equivalent of RMA will be included in the package. Pete #: 8689 S3/Languages 12-Dec-90 09:46:24 Sb: #8682-'C' problem Fm: Paul K. Ward 73477,2004 To: Jim Peasley 72726,1153 (X) Jim, Assember is included as the back end of the Microware C compiler. Paul #: 8643 S3/Languages 08-Dec-90 13:37:45 Sb: #8639-#'C' problem Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) memcpy(), unlike strcpy(), doesn't null-terminate the destination. strcat() wants pointers as arguments, so you needed strcat(whatever, ""), but...strcat itself looks for a null terminator to know where to start copying, so you can't use it to force null termination. (Sort of a catch-NUL. :-) There is 1 Reply. #: 8651 S3/Languages 08-Dec-90 15:44:49 Sb: #8643-'C' problem Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; I'm beginning to 'C' the light! Hallelujah!! What worries me even more, is I'm going over my first struggling attempts and making the code more terse. AAaargh! (first pgms. were written ala PL/I - one evaluation per line) ...Jim #: 8588 S3/Languages 04-Dec-90 08:40:01 Sb: 'C' problem Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Yep - it's like that for a bit. Your feet look like swiss cheese after you've shot yourself there a few hundred times. Learning C is worth the anguish though. You'll be happy you invested the time later. Keep chugging, and as always, free advice is only a modem-call away. Pete #: 8550 S4/MIDI and Music 02-Dec-90 17:45:01 Sb: #8277-#MIDI File Format Fm: Lester Hands 70135,430 To: Ches Looney 73016,1336 (X) The present version of PC-Lyra will write (not read, like everyone seems to want!) midi files. I'm working on a version 2.0 which will do just about everything except throw out the garbage! There is 1 Reply. #: 8563 S4/MIDI and Music 03-Dec-90 06:32:44 Sb: #8550-#MIDI File Format Fm: Ches Looney 73016,1336 To: Lester Hands 70135,430 (X) Well, shoot, I had a letter prepared with a request for you to send back the check if it didn't work as a translator. I'll tear up the letter and wait for developments. I don't need any help throwing out the garbage, but I'd sure like to have a MIDI file reader; encouragement, encouragement, encouragement. Those are supposed to be words of encouragement, Les. Regards, Ches. There is 1 Reply. #: 8751 S4/MIDI and Music 15-Dec-90 14:46:36 Sb: #8563-#MIDI File Format Fm: Lester Hands 70135,430 To: Ches Looney 73016,1336 (X) Ches, I don't want to make rash promises. I'll see what can be done about converting MIDI files to CMPro! There is 1 Reply. #: 8780 S4/MIDI and Music 16-Dec-90 08:36:47 Sb: #8751-MIDI File Format Fm: Ches Looney 73016,1336 To: Lester Hands 70135,430 (X) Thanks, Les, and a Merry Christmas, Happy Holidays, and a most enjoyable New Year are wished to you and yours. Regards. Ches. #: 8551 S6/Applications 02-Dec-90 19:05:41 Sb: #8142-#Overchoice - DOS world Fm: Art Doyle 71565,262 To: Pete Lyall 76703,4230 (X) Thanks Pete! Your advice (as always) was sound... I'm now using a Compaq 286 laptop to run the instrument under RS-232. It's slower than I'd like - but it gets the job done. You just can't beat those PC scale economies. Art There is 1 Reply. #: 8567 S6/Applications 03-Dec-90 08:47:17 Sb: #8551-#Overchoice - DOS world Fm: Pete Lyall 76703,4230 To: Art Doyle 71565,262 (X) Art - Glad to hear you struck a good 'bahgin', and that it's doin what you need. Pete There is 1 Reply. #: 8726 S6/Applications 13-Dec-90 22:25:28 Sb: #8567-#Overchoice - DOS world Fm: Art Doyle 71565,262 To: Pete Lyall 76703,4230 (X) Hi Pete! Yeah, but now I'm having problems with a mailing list. My sculptor program is overkill, and a dump to datamaster's list function ends up being too slow...Do you know of any neat filters to sort 4line addresses separated by a blank + . If I could sort this mess, I could eliminate the duplicate records When I tried to use DP Johnson's sort utility, I found out that it would not work in this fashion. I wish I knew Unix as well as you obviously do [grin]. Art There is 1 Reply. #: 8735 S6/Applications 14-Dec-90 09:01:23 Sb: #8726-#Overchoice - DOS world Fm: Pete Lyall 76703,4230 To: Art Doyle 71565,262 (X) Art - Whenever I find a small job that unix/os9 tools just won't do, I usually write a small (C) program for the situation. A friend prefers shell scripts. Have you considered cobbling a small B09 program to do the job for you? Pete There is 1 Reply. #: 8772 S6/Applications 15-Dec-90 22:29:19 Sb: #8735-Overchoice - DOS world Fm: Art Doyle 71565,262 To: Pete Lyall 76703,4230 (X) About 12 years ago, I wrote a primitive Basic bubble sort while in college.[grin]. These days, I'll go as far as messing around with databases for import/export purposes. No, I'm afraid that you folks that propduce these Unix tools have spoiled me. Btw, what's going on these days on the Sig? The message counter creeps slowly, being offered in the magazines. Art #: 8559 S15/Hot Topics 02-Dec-90 22:23:22 Sb: #MM/1 Progress? Fm: GLEN HATHAWAY 71446,166 To: Paul K. Ward 73477,2004 (X) Hi Paul... How's things coming with the MM/1? How much longer do we have to wait? There is 1 Reply. #: 8591 S15/Hot Topics 04-Dec-90 17:05:08 Sb: #8559-#MM/1 Progress? Fm: Paul K. Ward 73477,2004 To: GLEN HATHAWAY 71446,166 (X) Glen, Well, here's the full scoop, and I hope you can pass it around. Since the Atlant CoCo Fest, we have had two challenges. To ensure that our parts list for the manufacturer was bullet-proof (one distributor sent us a chip as an equivalent that was NOT an equivalent and gave developer machines a tizzy until we discovered the problem!); and the FCC certification. The MM/1 was designed from the ground up with FCC certifiable parts. This includes ferite beads on the connectors and a bunch of attention to grounding and so on. So the lab we used was delighted with the system and requested only TWO small changes. First, on the case we use, there was a little paint overspray. This is common on PC clone cases and is no doubt present on all those PC clones you see advertized in the Shopper or other computer magazines that are not FCC certified. Second, the keybaord connector on the front of our machine was not grounded -- a small oversight in the integration process. So we sent the machine back to them with these fixes -- and the machine arrived damaged. By the time we got all this fixed up, time had slipped by. We hate delays, Glen. We want to ship ASAP. But it is illegal to sell a non-FCC approved machine. It is also IMS policy to create a MAINSTREAM company with MAINSTREAM software and a legal, regulated, certified product. So what is the status now? FCC lab says that they'll have the lab portion done any day now. Hooray! And, IMS has an idea up their sleeve to get machines in your hands ASAP. It's legal, fun, and will make thousands of OSK and future OSK folks happy. TTFN. Best regards, Paul K. Ward Interactive Media Systems, Inc. There are 3 Replies. #: 8626 S15/Hot Topics 07-Dec-90 00:28:10 Sb: #8591-MM/1 Progress? Fm: GLEN HATHAWAY 71446,166 To: Paul K. Ward 73477,2004 (X) Hi Paul... Thanks for the information. Can't wait to see that machine on my desk!!! (Hey, do I need FCC certification to buy one if I live in Canada? ) #: 8628 S15/Hot Topics 07-Dec-90 06:34:20 Sb: #8591-#MM/1 Progress? Fm: Colin J. Smith 73777,1360 To: Paul K. Ward 73477,2004 (X) Paul, This is a little of the subject, but I'm sure this question is burning in the minds of more people than just me. What does paint overspray have to do with FCC certification? BTW, I'm all for getting my MM/1 as soon as possible, but if your idea (you know, the 'legal, fun' one) is the 'Part of the Month' club, you will be shot! <> --Colin There is 1 Reply. #: 8629 S15/Hot Topics 07-Dec-90 07:45:27 Sb: #8628-#MM/1 Progress? Fm: James Jones 76257,562 To: Colin J. Smith 73777,1360 (X) It concerns FCC certification because paint overspray can insulate the pieces of the case from one another, so that the case doesn't behave like a Faraday cage (keeping RFI from escaping). There is 1 Reply. #: 8635 S15/Hot Topics 08-Dec-90 08:56:02 Sb: #8629-MM/1 Progress? Fm: Colin J. Smith 73777,1360 To: James Jones 76257,562 (X) OK, thanks. I thought it was something like that. --Colin #: 8955 S15/Hot Topics 30-Dec-90 11:41:50 Sb: #8591-MM/1 Progress? Fm: Steve Wegert 76703,4255 To: Paul K. Ward 73477,2004 Paul, The word seems to be out (at least on the Internet) that the 'up-the-sleeve' deal you mentioned would be that IMS will be releasing the MM/1 in kit form, initially to get the ball rolling. What are the details on that plan? How much of a savings over the constructed unit? What is provided (case? power supply? etc.) I'm sure folks would be curious .... Steve #: 8570 S10/OS9/6809 (CoCo) 03-Dec-90 10:33:23 Sb: #serial printer on RS232 Fm: Mike Guzzi 76576,2715 To: all I have heard of people using an ACIAPAK port for a serial printer. I have the COMM-4 and now own a CGP-220 printer and would like to use it along with my epson thats hooked onto /p. i know it would work.. the cgp-220 has a serial port but my concern is the busy line. if i do something like "list file >/t4" and my cgp-220 is on /t4 will data flow stop while the printer is busy? what pin on the RS232 should the BUSY like be hooked to? Mike There is 1 Reply. #: 8610 S10/OS9/6809 (CoCo) 05-Dec-90 13:59:26 Sb: #8570-#serial printer on RS232 Fm: Lee Veal 74726,1752 To: Mike Guzzi 76576,2715 (X) Mike, I'm using a Comm-4 to send serial data to my printer, but I'm not using a Tandy-style serial interface (4-pin DIN). The serial device that I'm sending the data to uses a standard RS-232 interface. In your situation, I think I'd tie the BUSY line from the printer to the DTR line in the COMM-4 interface. Tying it to DSR might also be an option, but I'd try DTR first. Lee P.S. If you use Multi-Vue (or the Hi-Res Joystick adaptor), then you might experience some lost data when data is being sent to the printer (via the Comm-4 port) and the mouse pointer is being moved about. LV... There is 1 Reply. #: 8670 S10/OS9/6809 (CoCo) 10-Dec-90 20:13:24 Sb: #8610-serial printer on RS232 Fm: Mike Guzzi 76576,2715 To: Lee Veal 74726,1752 (X) hmmm ill have to try that and see which works. Mike #: 8573 S9/Utilities 03-Dec-90 18:35:02 Sb: #Defragmentation Fm: Frank Russell 74020,1135 To: all I am looking for a file de-fragmenter that handles larger than 1block clusters also has to be faster that CB's System File Repack. I would like to be able to run it on a BBS as a daily maintnence procedure.. (Smart enough to NOT defrag whats iss not fragmented) if any of you know wnything about something close to this plese WB Later Frank There is 1 Reply. #: 8606 S9/Utilities 04-Dec-90 22:35:21 Sb: #8573-#Defragmentation Fm: Bob van der Poel 76510,2203 To: Frank Russell 74020,1135 Frank, I uploaded an unfragmenter a while ago which should do the trick. It is called "unfrag.ar" and is in DL9. As I recall, the C source is included. Let me know if it works out okay. There are 2 Replies. #: 8612 S9/Utilities 05-Dec-90 18:01:58 Sb: #8606-Defragmentation Fm: James Jones 76257,562 To: Bob van der Poel 76510,2203 (X) Howdy. I took a look in DL9, and the unfrag.ar that I saw there was barely bigger than the unfrag executable that I recall getting from said archive a while back--which would seem to confirm my recollection that the source wasn't in the .ar file. (I was pretty sure that was the case, but wanted to verify my occasionally fuzzy memory.) I've yet to try it out; I'll let you know what happens when I do. #: 9013 S9/Utilities 04-Jan-91 01:47:53 Sb: #8606-#Defragmentation Fm: WAYNE LAIRD 73617,3042 To: Bob van der Poel 76510,2203 (X) Bob, been wondering whats your business address to purchase a copy of DED I've got two, one in canada and another in Indiana somwhere. Best, Wayne There is 1 Reply. #: 9035 S9/Utilities 05-Jan-91 20:28:53 Sb: #9013-Defragmentation Fm: Bob van der Poel 76510,2203 To: WAYNE LAIRD 73617,3042 You can write to me at either: P.O. Box 355 Porthill, ID USA 83853 or P.O. Box 57 Wynndel, BC Canada V0B 2N0 I actually live in Canada (at the 2nd address). However, Porthill is just a few miles away and I maintain a mailbox there for the software business, etc. I check this at least twice a week, so for the US it is probably the quickest route. My phone # is 604-866-5772. Oh, and I hope you wanted to order VED (not DED). Ved is my text editor, DED is a PD disk editor available here. #: 8584 S3/Languages 04-Dec-90 05:51:37 Sb: help on shell Fm: Kevin Darling (UG Pres) 76703,4227 To: MAS 76336,3226 (X) Robert - that is a little strange. But is it just that you don't see a BS take effect right away? The login shell is doing a ReadLn, and so nothing will happen until a CR is sent over. Also, I don't think pipes send signals on ^C or ^E. Can you give us a short piece of the code that the main app is using to send down the pipe to the login shell? best - kev #: 8587 S6/Applications 04-Dec-90 07:46:51 Sb: banner.ar unzipping Fm: Steve Wegert 76703,4255 To: aaron gergye 76264,1500 (X) Aaron, Any file extended with a .ar needs the OS9 specific utility AR. Arc-e.com is a PC utility and will not work on .ar files. Steve #: 8592 S12/OS9/68000 (OSK) 04-Dec-90 17:06:53 Sb: Atari-ST file transfer Fm: Paul K. Ward 73477,2004 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, I thinkg Brady has a com prog for ST under OSK. Paul #: 8595 S14/misc/info/Soapbox 04-Dec-90 17:30:49 Sb: #8394-#TC70 AND MM/1 CONCERNS Fm: Paul K. Ward 73477,2004 To: MOTD Editor..Bill Brady 70126,267 (X) Bill, You're absolutely right about the standard Clipboard interface. I think that, because the programmer interface is also fairly well defined, the Mac provides a uniform and "standard" way for a user to do real work with the least amount of thinking. Some programmers may hate the strictures, but as Quincy Jones said, "There is no freedom without restriction". Paul Interactive Media Systems, Inc. There is 1 Reply. #: 8877 S14/misc/info/Soapbox 25-Dec-90 13:21:22 Sb: #8595-TC70 AND MM/1 CONCERNS Fm: MOTD Editor..Bill Brady 70126,267 To: Paul K. Ward 73477,2004 That's the key... standardization of interfaces. But those 800 systems calls make accepting the restrictions easier. #: 8596 S14/misc/info/Soapbox 04-Dec-90 17:35:55 Sb: #8400-#TC70 AND MM/1 CONCERNS Fm: Paul K. Ward 73477,2004 To: Jack Crenshaw 72325,1327 (X) Jack, You are absolutely right about the Mac clone stuff. That does NOT mean that a point-and-click environement for OSK it a bad idea -- we'll have one for the convenience of customers because they DO save time. Do we want to compete with Apple? Why should we? We ARE doing some multimedia stuff, which they are, but they have a big niche, and we'll have a small one. IMS would be tickled pink to have 1% of the total computer market, and that won't make Apple execs lose any sleep. Remember, if we had 1%, then one out of every 100 computers would be MM/1s, making us rich and making the software and hardward choices for OSK even RICHER. I DO think getting some mainstream apps to the MM/1 and OSK is mandatory, though, and if some of these migrate, transmogrified, from t he Mac, great. Paul There is 1 Reply. #: 8832 S14/misc/info/Soapbox 19-Dec-90 16:30:31 Sb: #8596-#TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: Paul K. Ward 73477,2004 Paul, I knew that I didn't want a Mac, and certainly didn't want to have to program one, when I read the account in Byte about how the operating system works, and the hoops the programmer has to jump through to get anything to work. Basically, it's because Apple has tried to implement a sophisticated memory management scheme, with coelescence of NON-contiguous blocks of free memory, to support garbage collection, without hardware MMU support. I've also noticed that Mac programs, including expensive and popular applications, tend to bomb a lot. The other day on CLMFOR I picked up this tidbit: "Apple Finder author Steve Capps created a program called Discipline, which intercepts Mac OS calls and reports erroneous parameters. His results were startling: Virtually every Mac program that he tested -- including Apple's own applications -- made serious illegal calls to the operating system." That's enough reason for me not to want to emulate them. On the other hand, if you want to see how program environments can be very nice without being GUI, you need to look no farther than Turbo Pascal for the PC. Jack There is 1 Reply. #: 8886 S14/misc/info/Soapbox 25-Dec-90 14:26:41 Sb: #8832-#TC70 AND MM/1 CONCERNS Fm: MOTD Editor..Bill Brady 70126,267 To: Jack Crenshaw 72325,1327 (X) Programmers never stand still. The new generation of Mac "program" generators take the drugery out of programming for the Mac interface, but, you are right, the discipline is still required. One of the reasons that Mac apps make "illegal calls" is because Apple releases so many updates. There have been 4 releases this year. The Mac OS has had twice as many OS versions in half the time as Messy-DOS, for example. That's a heady enviornment oy! There are 2 Replies. #: 8895 S14/misc/info/Soapbox 26-Dec-90 06:03:49 Sb: #8886-#TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: MOTD Editor..Bill Brady 70126,267 (X) Yes, but .... there wouldn't _BE_ such drudgery required if the OS had a better user interface. There's a fiction going around that the Mac system calls, as well as those to OS/2 and Windows, are so complex because they're so powerful. The general idea is that the complexity is NEEDED to get all that power and all those features. I think that's mostly B.S. I've heard the same statements made about IBSYS, OS/360, and Multics. That puts the OS in the same category as iodine or high colonics: It must be good for you, because it hurts so bad. My idea of a powerful interface is one that makes me do _LESS_ work, not more. At a recent conference, Philippe Kahn pointed out that it takes about 500 lines of complex code to write a "Hello, World" program for OS/2. I was appalled when I got the OS/2 manuals, and discovered what I had to do to use it. Like MacOS (or whatever it's called), OS/2 is basically an event-driven OS. The user program becomes a set of what are basically interrupt handlers. The OS drives the program, not the other way around. For every program that's written, the programmer must provide code to handle the events. If someone resizes your window, moves it, or uncovers it, then you must redraw it. You must handle clicks on all the gadgets like the scroll bar. We had a long discussion about this over on CLMFOR a couple of years ago. I said, "No, wait a minute! I want the ** OS ** to take care of that for me. I want to write to a virtual window. It's up to the OS to take care of moving tiles around, covering and uncovering them, and all that. I got all kinds of arguments about why that couldn't be done, but the bottom line was that it's too much trouble for the OS. [More] There are 2 Replies. #: 8896 S14/misc/info/Soapbox 26-Dec-90 06:03:59 Sb: #8895-#TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] There's also the issue of hardware capability and size: Several people pointed out to me that it would take too much video RAM, and be too slow, if you tried to store everybody's virtual screens intact. My reaction was, "Fine. Let me know when the hardware's up to the job. Otherwise don't bother me." To be more specific about Multics (since few people are familiar with it): Although it's the grandaddy of Unix, it represents the exact opposite philosophy. Whereas the Unix idea is (or at least, was) to provide lots of small, simple utilities that you can then build on and combine to do complex things, the Multics approach was to make every utility have as much power as possible. The "open file" command, for example, had some 15 arguments, most of which were optional, and one of which served no function that any of the Multics systems guys could remember. The manual section for "send mail," I recall, was 19 pages long. I mean, how many different ways are there to send mail??? I got that argument from all the Multicians then: The system is so complex because it's so powerful ... there are so many wonderful things you can do with it, once you learn the system commands. Baloney! If that's so, then why can't I manage to open a file??? And why can't someone tell me what that mysterious extra argument is for??? And why is it that most of you systems types don't use the system at all, but write most of your software in shell scripts??? (I even knew some that write their programs in "editor." The editor had such a powerful macro language (sort of a pre-grep) that many guys wrote their "programs" for it, only.) [More] There is 1 Reply. #: 8897 S14/misc/info/Soapbox 26-Dec-90 06:04:07 Sb: #8896-TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] Since those discussions, I've put a lot of thought into it, and I've decided that the problem is not the OS itself, but the fact that the vendors never finished the toolset. They've taken what amounts to batch-oriented assemblers and compilers, and ported them to the new environment without doing anything to integrate them. If they _WERE_ integrated, then I should be able to write, in the edit window of an integrated environment, printf("Hello, World!\n); and have that compile into a program that comes up in a standard window, complete with drag, size, scroll, and kill gadgets. Note that I didn't even write main(){ ... }. That's as it should be, although I wouldn't complain too much if that were required. We can also debate whether printf, or even the '\n', make sense in a windowed environment, but I think you get the idea. Now, transporting this concept to the illegal Mac system calls, it seems to me that the problems are (a) The tools (compiler and assembler) are not integrated into the environment, and therefore put all the burden on the programmer, and (b) If properly integrated, the tools should not even allow the programmer to _GENERATE_ illegal calls. Jack #: 8905 S14/misc/info/Soapbox 27-Dec-90 04:55:22 Sb: #8895-#TC70 AND MM/1 CONCERNS Fm: MOTD Editor..Bill Brady 70126,267 To: Jack Crenshaw 72325,1327 (X) The Mac OS *does* take care of all that for you. But applications program must tell the OS what to do, of course. Today, all of that code is wrtten for you by the excellent tools (program generators) that I mentioned. In your message you used the term "user interface" when (I think) you meant programmer interface. The Mac is user friendly & programer hostile, OS-9 is programmer friendly and user hostile. There is 1 Reply. #: 8917 S14/misc/info/Soapbox 27-Dec-90 23:53:18 Sb: #8905-TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: MOTD Editor..Bill Brady 70126,267 I like the programmer-friendly part better. Jack #: 8898 S14/misc/info/Soapbox 26-Dec-90 06:04:11 Sb: #8886-#TC70 AND MM/1 CONCERNS Fm: Jack Crenshaw 72325,1327 To: MOTD Editor..Bill Brady 70126,267 (X) Yup, and I made the prediction about six years ago, when Apple first announced they were developing a multi-tasking OS for the Mac, that they would never get it, without requiring total rewrite of all the applications. Although they're claiming that they're finally close, with System 7, so far my prediction is still holding. Jack There is 1 Reply. #: 8906 S14/misc/info/Soapbox 27-Dec-90 05:00:02 Sb: #8898-TC70 AND MM/1 CONCERNS Fm: MOTD Editor..Bill Brady 70126,267 To: Jack Crenshaw 72325,1327 (X) I agree, the Mac is far too oriented to single-user operation to be "retrofitted" for multi-tasking. Although, in practical terms, much multi-tasking already takes place in the Mac world. For example, I have a fax modem on one of my Macs. Often I'll be working on some project and some one will call with an incoming fax. #: 8597 S14/misc/info/Soapbox 04-Dec-90 17:36:54 Sb: TC70 AND MM/1 CONCERNS Fm: Paul K. Ward 73477,2004 To: MOTD Editor..Bill Brady 70126,267 (X) Right, we need apps. But that doesn't mean we don't need a GUI. Like a car needs an engine, but that doesn't mean you don't need doors and power steering. Paul #: 8600 S3/Languages 04-Dec-90 20:55:54 Sb: #login shell tst prg Fm: MAS 76336,3226 To: 76703,4230 (X) PART 1 OF TEST PROGRAM ************************************************************************* Here is a sample test program! Plese see "#### WRITE 3 ####": BS is not recognized by the login shell. ************************************************************************* /* os9exec() login and piping */ #include #include #include extern int errno; extern char **environ; extern int os9fork(); main() { int i; int c[2], std[3], pid, ret; char buffer[2]; char *argblk[2]; char bs[2]; bs[0] = (char) 8; argblk[0] = "/h0/cmds/login"; argblk[1] = 0; if ((c[0] = open("/pipe",S_IREAD|S_IWRITE)) == -1) { printf("Unable to open() read pipe : #%d\n",errno); exit(0); } if ((c[1] = open("/pipe",S_IREAD|S_IWRITE)) == -1) { printf("Unable to open() write pipe : #%d\n",errno); exit(0); } std[0] = dup(0); std[1] = dup(1); std[2] = dup(2); close(0); dup(c[0]); close(1); dup(c[1]); close(2); dup(c[1]); pid = os9exec(os9fork,argblk[0],argblk,environ,0,0,3); close(0); dup(std[0]); close(std[0]); close(1); dup(std[1]); close(std[1]); close(2); dup(std[2]); close(std[2]); if (pid == -1) { printf("\n*** Can't os9exec() ***\n"); exit(0); } for(i=0;i<5;i++) /* read from login pipe till pipe is empty */ { for(;;) { ret = getstat(1,c[1]); if (ret > 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x d\\n ...\n"); for(i=0;i<5;i++) /* read from login pipe till pipe is empty */ { for(;;) { ret = getstat(1,c[1]); if (ret > 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x #include #include extern int errno; extern char **environ; extern int os9fork(); main() { int i; int c[2], std[3], pid, ret; char buffer[2]; char *argblk[2]; char bs[2]; bs[0] = (char) 8; argblk[0] = "/h0/cmds/login"; argblk[1] = 0; if ((c[0] = open("/pipe",S_IREAD|S_IWRITE)) == -1) { printf("Unable to open() read pipe : #%d\n",errno); exit(0); } if ((c[1] = open("/pipe",S_IREAD|S_IWRITE)) == -1) { printf("Unable to open() write pipe : #%d\n",errno); exit(0); } std[0] = dup(0); std[1] = dup(1); std[2] = dup(2); close(0); dup(c[0]); close(1); dup(c[1]); close(2); dup(c[1]); pid = os9exec(os9fork,argblk[0],argblk,environ,0,0,3); close(0); dup(std[0]); close(std[0]); close(1); dup(std[1]); close(std[1]); close(2); dup(std[2]); close(std[2]); if (pid == -1) { printf("\n*** Can't os9exec() ***\n"); exit(0); } for(i=0;i<5;i++) /* read from login pipe till pipe is empty */ { for(;;) { ret = getstat(1,c[1]); if (ret > 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x d\\n ...\n"); for(i=0;i<5;i++) /* read from login pipe till pipe is empty */ { for(;;) { ret = getstat(1,c[1]); if (ret > 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x 0) { read(c[1],buffer,1); printf("SHELL OUTPUT CHR> %c : %x .. ANYHOW THANKS FOR TRYING TO HELP ME..I'M NEW AT A COCO 3. I'VE HAD JUST ABOUT ALL THE ANTIQUE COMPUTERS RADIO SHACK HAD. (2) COCO 1'S,A 4P,A MODEL 3,I STILL HAVE (2) MC-10'S,(2) COCO 2'S, AND NOW (2) COCO 3'S.. I GUESS IT'S AFFIES GRAVEYARD.. MICHAEL 73340,2756 There is 1 Reply. #: 8616 S10/OS9/6809 (CoCo) 06-Dec-90 01:35:38 Sb: #8613-#How to install 512K? Fm: Kevin Darling (UG Pres) 76703,4227 To: MICHAEL ROSEN 73340,2756 (X) Michael - you'll need 16 of the 256K x 1-bit dynamic RAM chips... they usually have numbers like 41256 or anything xx256 on them. You remove the original 4 coco ram chips, and also two capacitors nearby... unfortunately my memory fails me as to their numbers on the coco3 board. Guys??? There is 1 Reply. #: 8617 S10/OS9/6809 (CoCo) 06-Dec-90 05:58:23 Sb: #8616-#How to install 512K? Fm: Dan Robins 73007,2473 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, I -THINK- the old ones are the 4154's, maybe (then maybe not...I'm going off gray cell memory on this one). Dan There is 1 Reply. #: 8618 S10/OS9/6809 (CoCo) 06-Dec-90 16:53:25 Sb: #8617-#How to install 512K? Fm: Kevin Darling (UG Pres) 76703,4227 To: Dan Robins 73007,2473 (X) Thx Dan.... but I meant the capacitor numbers to clip out for the 512 upgrade. Thanks! There is 1 Reply. #: 8621 S10/OS9/6809 (CoCo) 06-Dec-90 20:51:01 Sb: #8618-How to install 512K? Fm: Dan Robins 73007,2473 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, Oh wellst. Sorry. Guess that means I don't get any points, eh? Dan #: 8619 S1/General Interest 06-Dec-90 17:21:44 Sb: 512K UPGRADE Fm: MICHAEL ROSEN 73340,2756 To: KEVIN DARLING THANKS KEVIN & DAN FOR THE HELP, MAYBE SOMEONE ELSE KNOWS WHAT THE CAPS. NUMBERS ARE... HMMM I GUESS I'LL HAVE TO FIND ME SOME CHIPS.. THANKS GUYS... MICHAEL ROSEN 73340,2756 #: 8620 S10/OS9/6809 (CoCo) 06-Dec-90 19:56:44 Sb: #HD problems Fm: LUTE MULLENIX 70721,2230 To: 76703,4227 (X) Kevin: I'm having some trouble putting togeather this HD system, I keep getting an ERROR 246 (Device not ready). Is it possible that a bad cable will do this? I have sent the drive and the Disto adapter back and I get the same error. I even pulled my 3-1 board out of the controller and put the adapter in there with the same results. What do you think? If it might be the cable, where can I get about a three foot SCSI cable? The one I have is one I cobbled up out of some stuff I had around here. >Lute< There are 2 Replies. #: 8625 S10/OS9/6809 (CoCo) 06-Dec-90 23:52:14 Sb: #8620-#HD problems Fm: Kevin Darling (UG Pres) 76703,4227 To: LUTE MULLENIX 70721,2230 (X) Lute - could be the cable, or perhaps the power supply (?). Try this first tho: make a boot disk with H0 renamed to HD or something. Boot, then try an "iniz /hd" and see if that works. Or, if you're already doing this... ummm... what kind of hard disk is it? Did it format okay using that disto rsdos program? There is 1 Reply. #: 8637 S10/OS9/6809 (CoCo) 08-Dec-90 11:08:55 Sb: #8625-HD problems Fm: LUTE MULLENIX 70721,2230 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin: I found the problem, it was an addressing thing. However there is something else you may be able to help me with. Quite often when attempting to run Basic programs or those with basic subroutines I get an error #43. And now that the HD is going some of the stuff that used to work is giving it to me. When working up a boot file for the HD I smoked the one on my previous master disk (the one the basic stuff worked from) and don't remember what was in it. and the backup I had doesn't seem to work. Any ideas? Ad9 dosn't want to work and tis the season! >Lute< #: 8630 S10/OS9/6809 (CoCo) 07-Dec-90 09:13:09 Sb: #8620-#HD problems Fm: Pete Lyall 76703,4230 To: LUTE MULLENIX 70721,2230 (X) Cable is a prime candidate. If I recall, SCSI is simply 50 pin end-end. You should be able to build another cheaply, or pick one up from your local computer place for $20 or under. Pete There is 1 Reply. #: 8638 S10/OS9/6809 (CoCo) 08-Dec-90 11:09:47 Sb: #8630-#HD problems Fm: LUTE MULLENIX 70721,2230 To: Pete Lyall 76703,4230 (X) Pete: Found the problem, it was an addressing thing. Thanks for the input though. About the local computer shops. We have Radio Shack and Ultra Inc. Though I rate the local RS as excellent they carry no SCSI stuff, and Ultra, well they sell Macs but they weren't sure what SCSI was, and were sure they had never seen a 50 pin cable. Oh well. >Lute< There is 1 Reply. #: 8878 S10/OS9/6809 (CoCo) 25-Dec-90 13:27:18 Sb: #8638-HD problems Fm: MOTD Editor..Bill Brady 70126,267 To: LUTE MULLENIX 70721,2230 (X) Come to think of it, I've never seen a 50-pin *cable* myself! #: 8622 S10/OS9/6809 (CoCo) 06-Dec-90 20:57:33 Sb: #8575- StermHelp Fm: VERN STOCKMAN 70415,1057 To: Kevin Darling (UG Pres) 76703,4227 (X) list msgs/thanks #: 8624 S10/OS9/6809 (CoCo) 06-Dec-90 23:08:30 Sb: COCO lv 1.2 BBS Fm: LAVERN SCHOONOVER 73700,3217 To: all Does anyone know of a COCO lv.1.2 BBS program that I could buy I need it in order to get my hard drive to work. It only is accessable under lv 1.2 -=*< L.V. >*= #: 8627 S6/Applications 07-Dec-90 06:32:50 Sb: cron Fm: Tom Napolitano 70215,1130 To: Bill Dickhaus 70325,523 (X) Bill, Thanks, I'll take a look. tom PS Was that cc or cron you were responding to? Nevermind, I'll look for both. #: 8633 S10/OS9/6809 (CoCo) 07-Dec-90 18:38:59 Sb: #PCoid SCSI and Burke**2? Fm: James Jones 76257,562 To: All I got a JDR Microdevices (or whatever it is) catalog in the mail today. In it I found a SCSI controller card for PClones (floppy and hard $80, hard only $50, to one significant digit I think :-). What I'm wondering is this: can one connect this beast to a Burke**2 interface and, with appropriate drivers, connect SCSI stuff to one's CoCo? The floppy hardware is claimed to handle all the various flavors of floppy sizes up to 1.44 Mbytes. That would be a nice setup, I think, if it could be pulled off. Anyone know whether it's possible? There is 1 Reply. #: 8641 S10/OS9/6809 (CoCo) 08-Dec-90 13:25:17 Sb: #8633-#PCoid SCSI and Burke**2? Fm: Zack Sessions 76407,1524 To: James Jones 76257,562 (X) The CoCo-XT by Burke&Burke does not support SCSI controllers. There is 1 Reply. #: 8644 S10/OS9/6809 (CoCo) 08-Dec-90 13:39:11 Sb: #8641-#PCoid SCSI and Burke**2? Fm: James Jones 76257,562 To: Zack Sessions 76407,1524 (X) Shucks. I don't know enough about the hardware involved to know whether it was possible. Ah, well...I wonder how hard it would be to do? There is 1 Reply. #: 8879 S10/OS9/6809 (CoCo) 25-Dec-90 13:34:43 Sb: #8644-PCoid SCSI and Burke**2? Fm: MOTD Editor..Bill Brady 70126,267 To: James Jones 76257,562 (X) James, the SCSI adapters for clones have a driver on-board which is loaded by BIOS at boot time. (as a BIOS extension). You could disassemble the code on a PC & write a driver for OS-9. (you'd prolly have to disable the ROM later) The floppy side would be easier. I bought one of those boards for $30. The one with the floppy & SCSI was about $6 more. #: 8634 S9/Utilities 08-Dec-90 00:59:09 Sb: touch.ar Fm: Ken Drexler 75126,3427 To: sysop (X) Sysop, I have marked my touch.ar file in DL9 for deletion because it has been superceeded by touch2.ar which does all the same things and a bit more. Ken Drexler #: 8636 S1/General Interest 08-Dec-90 10:42:21 Sb: Delphi Fm: MICHAEL ROSEN 73340,2756 To: Kevin Darling Kevin, I have just joined DELPHI (MICHAELROSEN) and it may be a good system as soon as i figure it out. I guess i'll get rid of my newest coco 3 and purchase me a color monitor. I downloaded Delphiterm 3.1 and it is a well written program as is mikeyterm.. I guess i'll shut up and sit back a while,I still haven't got telecom to work on my Deskmate. I hope to be hearing from yall on d oh shoot,i pressed the wrong button.. well i'd better go. c-yall, Michael Rosen <73340,2756> #: 8657 S9/Utilities 09-Dec-90 15:32:45 Sb: #OS/9 File utilities ? Fm: Keith A. Glass 73770,1300 To: all To all and few. . . Asking a question on behalf of a friend. . .any recommendations on good OS/9 file utilities ? If so, library and filename as well as a brief summary....... Keith Glass There is 1 Reply. #: 8676 S9/Utilities 11-Dec-90 08:34:14 Sb: #8657-OS/9 File utilities ? Fm: Wayne Day 76703,376 To: Keith A. Glass 73770,1300 (X) Uh, any of the utilities in the library are appropriate, Keith. Unfortunately, recommending anything specific would be impossible, since you didn't give us enough information to understand just what it is that your friend wants or needs. Wayne #: 8658 S7/Telecommunications 09-Dec-90 15:50:07 Sb: #Sterm 1.3 Fm: LUTE MULLENIX 70721,2230 To: 76070,41 (X) Mark; I reciently got a harddrive going, and am getting all my stuff put on there. However I remembered that quite some time ago I got a patch from you to change Sterm 1.a so it looked for the termcap stuff on D0 insted of DD. I don't know if you remember this, but I don't remember the patch points or values. Now I need to change it back. Other wise I have to have this info on D to get it to run as I have set the HD as H0 and DD. Thanks >Lute< There is 1 Reply. #: 8659 S7/Telecommunications 09-Dec-90 17:01:10 Sb: #8658-Sterm 1.3 Fm: Steve Wegert 76703,4255 To: LUTE MULLENIX 70721,2230 (X) Lute, Why not use DeD and zap the offensive bytes as they appear? Just use the search capabilities to look for /D0 then modify to /DD. Give a shout if you need more info. Steve #: 8660 S9/Utilities 09-Dec-90 17:36:31 Sb: Koonce Make Fm: Ken Drexler 75126,3427 To: Bill Breckhaus 70325,523 (X) Bill, Since seeing your message to me about make, I found Tim Koonce's make had been posted here. I have downloaded and it looks great. Thanks again for the pointer (and for posting it here, if you are responsible.) Ken #: 8667 S3/Languages 10-Dec-90 09:42:16 Sb: clib bug Fm: Carl Kreider 71076,76 To: all I just uploaded versions of my libraries with 'localtime()' fixed. Pretty stupid bug. - Carl #: 8673 S1/General Interest 10-Dec-90 21:37:28 Sb: PCDos to OS9 Fm: tom farrow 72701,543 To: all Help on PcDos Utility I can read disk but I can not (-get) files to go to any other drive is there some majic incantation that I missed? /EXIT #: 8674 S3/Languages 10-Dec-90 22:24:09 Sb: #Dynamic Structure Alloc Fm: Jay Truesdale 72176,3565 To: all I am writing a program that builds a b-tree using malloc to allocate memory to hold a structure that is then referenced via pointers. The C books I have don't cover this sort of thing, I'm trying to figure out the "proper" way to reference the "next" structure item via the pointer links. The stucture template looks like this: struct b_tree_rec { int key; struct b_tree_rec *lp; /* Left Pointer */ struct b_tree_rec *rp; /* Right Pointer */ } In main() I declare these variables: struct b_tree_rec node, *root_ptr, *node_ptr; I allocate memory to hold the root node like this: root_ptr = (struct b_tree_rec *) malloc(sizeof (node)); if (root_ptr == NULL) { printf("Error number %d in allocation of root node\n", errno); exit(0); } root_ptr->key=0; /* init root node contents */ root_ptr->lp=NULL; root_ptr->rp=NULL; I'm not sure why the example code I looked at casts the pointer returned by malloc as it did but I figure at least it provides more documentation as to what is doing on. It also ocurred to me that if pointer arithmetic is used the compiler needs to know how big the pointed to object is. Am I correct in my assumption or is there more to this? How do I reference the fields in the second node? This fails at execution time and I think I see why: node_ptr->lp->lp=NULL; This fails at compile time but I'm not sure what to try next. (*(node_ptr->lp))->lp=NULL; Suggestions? Any books that cover this sort of thing that anyone can recommend? Thanks, -J There are 2 Replies. #: 8675 S3/Languages 11-Dec-90 00:29:36 Sb: #8674-Dynamic Structure Alloc Fm: Pete Lyall 76703,4230 To: Jay Truesdale 72176,3565 (X) Jay - First of all, great questions! Now lets see if I can answer them.... The statement where you do root_ptr = (struct b_tree_rec *) malloc(sizeof(node)); . root_ptr is declared to be of type 'struct b_tree_rec *' above... malloc is of type 'char *'. Since a pointer to a char is a different animal than a pointer to a 'struct b_tree_rec' (NOTE: pointer math and size of objects was right on ethe money), then we must 'cast' or 'coerce' the source type to produce the same type as expected by the receiving variable, in this case rec_ptr. Some compilers will blow you out if you try to assign different types, and some are very lax. On the getting to the second node, I believe it'd be something like this: node_ptr = (struct b_tree_rec *) malloc(sizeof(node)); ... error checking ... ... allocation and linking of subsequent notes .... /* get at left node and determine the key */ curr_node = root_ptr->lp; curr_key = curr_node->key; Hope that helps.... Pete #: 8700 S3/Languages 12-Dec-90 21:42:10 Sb: #8674-#Dynamic Structure Alloc Fm: Jay Truesdale 72176,3565 To: Jay Truesdale 72176,3565 (X) Pete: Thanks for the confirmation about why I need to worry about what the pointer points to (pointer math) and why I need to cast the pointer returned by malloc. I think that I have to do the same cast for the same reasons to do what I really want to do, reference down the tree. If I want to get the key value contained in the left node while "at" the root node then (root_ptr->lp) references the pointer field in the root node which contains a pointer to the next node. I want to dereference this to get what this points to (the next node). The pointer contained in this field is of type b_tree_rec so I need to cast the de-reference operation to the proper type??? I then can use the -> operator to retrieve the contents to the next node like this: ((struct b_tree_rec *)(root_ptr->lp))->key This appears to work as my short test program gets the results I expected. I'm not sure why I need to cast the de-reference operation as I declared the "lp" field as being a pointer to type b_tree_rec in the structure template definition right before main. Thanks in advance, -J There is 1 Reply. #: 8708 S3/Languages 13-Dec-90 09:05:57 Sb: #8700-#Dynamic Structure Alloc Fm: Pete Lyall 76703,4230 To: Jay Truesdale 72176,3565 (X) Jay - I'm not sure why you have to cast that second dereferenced pointer either.. should be implicit because of the declaration. If you DON'T, does it break? I recall before that you were doing root_ptr->lp->key, or something like that. It may be a precedence thing, where you need to cluster the binding that way you want it (i.e. (root_ptr->lp)->key. Maybe that'll let you avoid the cast? Pete There is 1 Reply. #: 8761 S3/Languages 15-Dec-90 19:41:52 Sb: #8708-#Dynamic Structure Alloc Fm: Jay Truesdale 72176,3565 To: Pete Lyall 76703,4230 (X) Pete: If I use "node_ptr->rp" then this 'is' a member of the pointed to structure, this is probably why "node_ptr->rp->rp" failed, isn't any way to get to there from here! 'rp' is a pointer to type b_tree_rec. To get the 'next' item in my B-Tree I need to use the indirection operator to get to where "node_ptr->rp" points to. If I use *(node_ptr->rp) I get an error #102 bus trap error so I assume that I'm referencing an area in the memory map that has nothing there. I may try using this as an argument to printf in hex format to try and figure out what's going on. If I use (*)(node_ptr->rp) I get a bunch of compile errors: "btree.c", line 169: **** primary expected **** print_tree( (*)(node_ptr->rp) ); ^ "btree.c", line 169: **** expression missing **** print_tree( (*)(node_ptr->rp) ); ^ "btree.c", line 169: **** not a function **** print_tree( (*)(node_ptr->rp) ); ^ errors in compilation : 3 If I cast the pointer like this "(struct b_tree_rec *)(node_ptr->rp)" it both compiles and works. Guess I'll go do some more reading and experimenting and see if I can figure this one out. (Maybe I should have purchased that "Data Structures in C" book I saw last week...) -J There are 2 Replies. #: 8784 S3/Languages 16-Dec-90 12:01:30 Sb: #8761-Dynamic Structure Alloc Fm: Pete Lyall 76703,4230 To: Jay Truesdale 72176,3565 (X) Jay - Well, in that case (as always), empirical proof is more solid that theoretical conjecture (grin)! In other words, go with what works. Pete #: 8827 S3/Languages 19-Dec-90 08:07:29 Sb: #8761-Dynamic Structure Alloc Fm: Bill Dickhaus 70325,523 To: Jay Truesdale 72176,3565 (X) Jay, What should work is: (node_ptr->rp)->rp If rp is defined as a pointer to the structure, then you shouldn't have to cast the "(node_ptr->rp)" part. The trick here is the parentheses not the cast, I think. I use this all the time with OS9 LII without any problems. Bill #: 8677 S1/General Interest 11-Dec-90 10:43:20 Sb: #900 numbers Fm: International Consulting 71520,460 To: all Has anyone else heard about these 900 numbers? I was on Delphi last night and someone said that there is a 900 number poll line, which is asking people to vote on which operating system is better, CoCo/RS-DOS or OS-9. Of course, we all know the answer to that. The numbers on Delphi were 900 535-4900 extension 796 to vote for OS-9 or ext 794 to vote for RS-DOS. The rumor is that either Lonnie Falk of Falsoft, or perhaps someone from Microware has started them. If anyone tries them, let me know. Bob Samuels There is 1 Reply. #: 8680 S1/General Interest 11-Dec-90 21:05:28 Sb: #8677-#900 numbers Fm: James Jones 76257,562 To: International Consulting 71520,460 (X) Well...you aroused my curiosity (besides, I felt I should register my opinion) so I called the appropriate number. Evidently there's some outfit that runs these polls and also does some kind of thing for people searching for hardware (and, I guess, can't take the time to buy a magazine instead of chew up $2 per minute on the phone... :-(. The outfit is called something like "Mr. Computer." Oh, BTW...the recording said that OS-9 was ahead by 120+ votes. OTOH, they didn't say how many had voted altogether, and of course this "survey" suffers from all the usual problems of self-selected surveys as well as the fact that one can vote Chicago style (early and often) if one wants to blow the $$$. There is 1 Reply. #: 8695 S1/General Interest 12-Dec-90 18:56:41 Sb: #8680-#900 numbers Fm: James Jones 76257,562 To: James Jones 76257,562 (X) Well...(talking to myself, but that's to keep the threat intact--take *that*, Atropos! :-) I couldn't resist calling again today. Either a very balanced number of people called "Ask Mr. Computer" on this, or they didn't bother to update the statistics, because the tape still said OS-9 is ahead by 121 votes. I think that my curiosity has been satisfied all it can be by calling up... Now the $64 question is--who caused this phone poll to occur? I really don't know. There is 1 Reply. #: 8697 S1/General Interest 12-Dec-90 19:33:48 Sb: #8695-#900 numbers Fm: International Consulting 71520,460 To: James Jones 76257,562 (X) Dear James, I finally broke down and blew the two bucks. OS-9 was ahead by 125 votes today, leading me to believe that the poll was updated after you called. BTW, for ANOTHER two bucks, I found out that the COCO side of things was also updated. As you say though, this is Chicago style. Do you, btw, remember me? I am a free lance writer, we have met several times at Rainbow fests. I actually put you in my OS-9 article for them. I wish I were getting rich on the 900 biz though. If they are getting rich. I wonder if it really is Lonnie??? Best Regards, Jeff There is 1 Reply. #: 8699 S1/General Interest 12-Dec-90 20:14:16 Sb: #8697-900 numbers Fm: James Jones 76257,562 To: International Consulting 71520,460 Gee. I bet I know you by face, but not by name. I'm not good with names. I wouldn't mind getting $$$ from a 900 number myself . I don't know who induced the poll--it would be highly interesting to find out, though. #: 8678 S8/BBS Systems/TSMon 11-Dec-90 19:02:58 Sb: RS232 Problem/Question Fm: Zack Sessions 76407,1524 To: ALL I recently put together a kit from Heathkit called the "Most Accurate Clock". For you kit-builders out there, it was a very enjoyable project. As with any Heath kit, the assembly instructions were clear and consise. The only problems I encountered were due to my own haste. The clock is really a combination of a clock, shortwave receiver, and micro-computer. It picks up the signal from either WWV in Ft. Collins Colorado or WWVH in Kauai, Hawaii which contains the time in a binary coded format. It automatically switches between 5, 10, and 15 MHz to find the strongest signal. A microprocessor decodes the signal and feeds it to a clock which displays the time on the unit's LEDs. I also purchased an option which allows one to obtain the time information from the MAC via an RS-232 connection. I would like to read this information via OS9. Only, I'm not sure exactly what I need to do. The connection only uses three pins, pin 2 (Data), pin 5 (RTS), and pin 7 (GND). The clock has two modes of operation which provide the data out the Data pin. One is "automatic". In this mode, it sends the information out the Data pin continuously, with a 1 second pause between transmissions. The second way to get the data is in "Request" mode. When the clock senses a "low to high transition" on Pin 5 (Request to Send), it sends the data out the Data pin. (continued in next message) #: 8679 S8/BBS Systems/TSMon 11-Dec-90 19:03:55 Sb: #RS232 Problem/Question Fm: Zack Sessions 76407,1524 To: ALL (continued from previous message) My question is two pronged. 1) What would be the harm in putting the clock in auto mode, and only reading the data occasionally when desired? I mean, is there a problem receiving data in the port and not reading it? Does it get buffered and when I do do a read, do I get what was buffered up first (which may not be the current time)? If so, how would I "flush the buffer" first so I can read the next signal which will come through? 2) If I want to use it in "Request" mode, how do I cause Pin 5 to transition from low to high? That is, what kind of output do I write out to the device or what kind of system call do I do to achieve this effect? Naturally, the sample program listing in the tech ref is in MS-DOS Basic. Plus it does things like poking hex data in hex locations on the IO buss with OUT statements. Plus it reads the data with a similar statement, INP. Thanks in advance for any help! Zack There are 2 Replies. #: 8687 S8/BBS Systems/TSMon 12-Dec-90 09:01:06 Sb: #8679-#RS232 Problem/Question Fm: Pete Lyall 76703,4230 To: Zack Sessions 76407,1524 (X) Zack - A few thoughts.... First, if XON/XOFF is turned on for that path, the buffer management code in the serial driver will probably send an XOFF when the buffer crosses the threshold of 10 (or whatever) characters left until buffer full occurs. Second, it's been so long that I don't remember if overflow errors are posted for both chip and buffer overflows.. I know they are for chip, but don't know about buffers... Bill Dickhaus could probably help here, since he rewote ACIAPAK I believe. Regarding the other mode of operation, perhaps you could cross-wire that RTS line to the CD or DSR line. These will post an interrupt, and with a little mucking about you could service it periodically rather than have it be free running. Pete There is 1 Reply. #: 8880 S8/BBS Systems/TSMon 25-Dec-90 13:51:44 Sb: #8687-#RS232 Problem/Question Fm: MOTD Editor..Bill Brady 70126,267 To: Pete Lyall 76703,4230 (X) It's a little confusing since the line Heath is calling RTS should probabaly be CTS. (clear to send). Anyway, you should try tying it to DTR. (data terminal ready). Most ACIAPAK drivers assert DTR when the driver is inized and drop it when 'term'd. (opened and closed). So from a Basic09 program, for example, you would do an OPEN #path,"/t2" FOR i=1 TO xxxx GET #path,bite where xxx is about two "frames worth" of time data. Then CLOSE #path to shut the box down. You wouldn't hang on the GET 'cause the box keeps sending until the CLOSE right? Good luck & Merry Xmas. There is 1 Reply. #: 8903 S8/BBS Systems/TSMon 26-Dec-90 10:47:12 Sb: #8880-#RS232 Problem/Question Fm: Pete Lyall 76703,4230 To: MOTD Editor..Bill Brady 70126,267 (X) Bill - I think you misdirected your message... it was probably meant for Zack. Pete There is 1 Reply. #: 8907 S8/BBS Systems/TSMon 27-Dec-90 05:00:47 Sb: #8903-RS232 Problem/Question Fm: MOTD Editor..Bill Brady 70126,267 To: Pete Lyall 76703,4230 (X) You are right Pete, I was just responding to the string. Solly. #: 8712 S8/BBS Systems/TSMon 13-Dec-90 10:19:49 Sb: #8679-#RS232 Problem/Question Fm: Bill Dickhaus 70325,523 To: Zack Sessions 76407,1524 (X) Zack, As long is the port isn't opened, ACIAPAK won't buffer anything. If the clock has been sending data continously, then the first read of the port will return an error. Subsequent reads should then get the most recent data sent by the clock, since the serial chip doesn't buffer at all. If you wanted to do it the other way, then you might try tying DTR (pin 20) on the serial port to RTS on the clock. DTR changes state when the port is opened. I can't remember, though, if RTS and DTR have the same "active' state, so this might not work. Bill There are 2 Replies. #: 8721 S8/BBS Systems/TSMon 13-Dec-90 17:20:58 Sb: #8712-RS232 Problem/Question Fm: Zack Sessions 76407,1524 To: Bill Dickhaus 70325,523 (X) Thanks, Bill. #: 8881 S8/BBS Systems/TSMon 25-Dec-90 13:53:43 Sb: #8712-RS232 Problem/Question Fm: MOTD Editor..Bill Brady 70126,267 To: Bill Dickhaus 70325,523 (X) Yup, Bill, all the RS-232 'control' lines have the same asserted level. +3v #: 8681 S7/Telecommunications 11-Dec-90 22:10:17 Sb: #Sterm Fm: Paul Hanke 73467,403 To: anyone I have downloaded STERM a while ago and am thinking of giving it a try, that is, logging on with STERM. My CoCo-3 is upgraded to 1meg. Is there any modification of procedure or can I expect everything to go as tho no upgrade had been made? Also, can STERM be used with other computers, as well as null modem up & downloads, or, other than on CIS, for which it seems to have been written? -ph- There is 1 Reply. #: 8684 S7/Telecommunications 12-Dec-90 05:36:16 Sb: #8681-#Sterm Fm: Dan Robins 73007,2473 To: Paul Hanke 73467,403 (X) Paul, In theory, it should fly on your 1meg CC3, at least, there's nothing that comes to mind that would prevent it. You should be able to use it with other computers and boards. Just remember to toggle the ECHO if on with another computer. Also keep in mind, that since it ONLY implements the CIS "B" protocols, that you'll be limited to terminal mode only, unless the other side uses the "B" protocols as well. Dan There is 1 Reply. #: 8685 S7/Telecommunications 12-Dec-90 07:44:14 Sb: #8684-#Sterm Fm: Steve Wegert 76703,4255 To: Dan Robins 73007,2473 (X) Err.... Dano ... My version (sterm 1.3) supports xmodem as well as b broto. I do believe it's the most current revision in the libraries. Steve There is 1 Reply. #: 8704 S7/Telecommunications 13-Dec-90 06:26:48 Sb: #8685-#Sterm Fm: Dan Robins 73007,2473 To: Steve Wegert 76703,4255 (X) Oops! My mistake. Guess I got comfortable with an earlier version and didn't update to 1.3, and it utilized ASCII and the "b" protos. Dan There is 1 Reply. #: 8707 S7/Telecommunications 13-Dec-90 07:57:25 Sb: #8704-#Sterm Fm: Steve Wegert 76703,4255 To: Dan Robins 73007,2473 (X) 1.2 is still rock solid, in my opinion. 1.3 added termcap stuff (which I make use of as the CoCo's downstairs and I'm in the back bedroom on a Wyse). Since I hardly ever venture from CIS, either would suit my needs in terms of protocol. B+ ... is there anything else? :-) Steve There is 1 Reply. #: 8882 S7/Telecommunications 25-Dec-90 14:03:26 Sb: #8707-#Sterm Fm: MOTD Editor..Bill Brady 70126,267 To: Steve Wegert 76703,4255 (X) You should try ZMODEM with a MNP 5 modem, then you can answer that question for yourself Steve. There is 1 Reply. #: 8909 S7/Telecommunications 27-Dec-90 07:38:01 Sb: #8882-#Sterm Fm: Steve Wegert 76703,4255 To: MOTD Editor..Bill Brady 70126,267 You bet, Bill. I'm in the process now of convincing Lisa that having a 9600 baud modem with MNP 5 is just what I need to spend less time on the computer and more time with her ... Did I forget to mention that St. Louis is slated for upgrading to 9600 baud RSN? Nahh ... nothing to do with it! :-) Steve There is 1 Reply. #: 8912 S7/Telecommunications 27-Dec-90 13:09:59 Sb: #8909-#Sterm Fm: Pete Lyall 76703,4230 To: Steve Wegert 76703,4255 (X) Steve - Soo... you gonna go for one of those beasties? It looked like a reasonable deal, but a bit painful after Christmas... Pete There is 1 Reply. #: 8915 S7/Telecommunications 27-Dec-90 16:30:10 Sb: #8912-Sterm Fm: Steve Wegert 76703,4255 To: Pete Lyall 76703,4230 (X) Yeah ... I'm seriously considering it. I passed up on the last MNP deal and have regretted it ever since. This way, I'll nab the extra speed when it arrives and gain the MNP capabilities now. Steve #: 8693 S7/Telecommunications 12-Dec-90 18:27:40 Sb: DM-3 telecom Fm: Paul Hanke 73467,403 To: all Reporting on the solution to a problem aired a coupla months ago- A null modem transfer of files to a CoCo-3 running DM-3's telecom program was not possible using 7E1 setup. Even tho keyboard text was ok, apparently DM-3 does not shift to 8N1 when xmodem is initiated, which doesn't let xmodem begin, evidently. Some other comm programs do change the setup automatically, such as Ultimaterm. So the moral of the story is to start both telecom programs using the 8N1 setup and xmodem transfers should go without a hitch. -ph- #: 8696 S10/OS9/6809 (CoCo) 12-Dec-90 19:19:12 Sb: #File structure Fm: Denise Tomlinson 71021,3274 To: All Can anyone tell me how a file is put on a disk for a Color computer under os9? I have a arced file from the music library that consists of 36 granules. This file is too big to use "dosor9" or others to transform a Dos format to a os9 format. I thought if I split it into 2 files and used "dosor9" to 2 different disks and then copied them to a genuine os9 format, then I could modify the gat tables and file ending bytes to combine into 1 file. I have done this to files in Dos format using a disk editor. But I have never done it under os9. I have the "zapper". Lets just say for simplicity that a disk I want to trace a file has only a "root " directory to make things simple. Thanks, Denise PS: I only access compuserve via Dos system because I don't have a modem pak for os9 operation. There are 2 Replies. #: 8698 S10/OS9/6809 (CoCo) 12-Dec-90 20:11:30 Sb: #8696-File structure Fm: James Jones 76257,562 To: Denise Tomlinson 71021,3274 (X) If you split the file on the DECB side into some number of parts, then the simplest way to get them back together on the OS-9 side would be to do something like merge file1 file2 file3 >bigfile (change as appropriate for the number of parts and the names you actually do give them). Doing that does imply the existence of two copies of the data, at least for a while. Is the file big enough that two copies won't fit on one disk? If that's the case, and you only have one disk, then life becomes more difficult. On the other hand, though, I thought someone had come up with a fix for one of the DECB->OS-9 file copy programs that had to do with files longer than 32K. You might look around to see whether there's a program here that does the job and avoids the file size problem. #: 8720 S10/OS9/6809 (CoCo) 13-Dec-90 17:17:53 Sb: #8696-File structure Fm: Zack Sessions 76407,1524 To: Denise Tomlinson 71021,3274 (X) If getting the file split and copied over worked, you can them combine the two with a merge command: OS9: merge file1 file2 >combined_file Zack #: 8701 S7/Telecommunications 13-Dec-90 01:21:04 Sb: #BBS Fm: edward langenback 73510,145 To: all Springwood BBS 300 / 1200 (going 2400 within the month) 24 hours/7 days 1-614-228-7371 13 message bases, limited transfers, Galactic Conflict: Journey II "KMA-68!!" >>>>>S S<<<<< !!!!!!!!!!!!! There is 1 Reply. #: 8861 S7/Telecommunications 23-Dec-90 03:57:51 Sb: #8701-#BBS Fm: edward langenback 73510,145 To: edward langenback 73510,145 (X) just a quick note to notify all that Springwood is now operating at 2400 bps as promised. Springwood BBS 1-614-228-7371 Ed. A.K.A. >>>>>S S<<<<< !!!!!!!!!!!!! There is 1 Reply. #: 9011 S7/Telecommunications 04-Jan-91 01:41:58 Sb: #8861-#BBS Fm: WAYNE LAIRD 73617,3042 To: edward langenback 73510,145 (X) edward, (got a twin named sisccior- hand?) saw your bbs adand wanted to add it to my national bbs list for the coco/os9 called COCOS9ER, the databanks should have acopy here if I don't upload a copy to you first ->grin>>>>S S<<<<< !!!!!!!!!!!!! #: 8702 S3/Languages 13-Dec-90 03:46:49 Sb: #C and buffers Fm: Dan Charrois 70721,1506 To: all I have a question about buffers and C that has no doubt been asked before, and I apologize for that. But anyways, given the following code: main() { printf("First line"); sleep(1); Circle(1,100); sleep(1); } Why does the system sleep for 1 Second, draw the Circle, sleep another second, and THEN print "First line" right before exiting? I gather that it must have something to do with buffered output since if I tack a \n after 'line' things work as expected, but how can I get the code above to work the way it would intuitively seem to? I noticed that I could use write and it worked alright (perhaps), except I still wouldn't know how to print formatted output this way. I'd appreciate hearing from anyone who has even the slightest idea on what exactly is going on. Dan There are 2 Replies. #: 8705 S3/Languages 13-Dec-90 06:29:18 Sb: #8702-#C and buffers Fm: James Jones 76257,562 To: Dan Charrois 70721,1506 (X) That's exactly what it has to do with. You can get it to do what you want also by inserting the line "fflush(stdout);" before the first sleep call. There is 1 Reply. #: 8717 S3/Languages 13-Dec-90 13:54:28 Sb: #8705-C and buffers Fm: Dan Charrois 70721,1506 To: James Jones 76257,562 (X) Thanks, James. I'll give that a try.. Seems to make sense, though I don't think I would have thought of that approach. #: 8709 S3/Languages 13-Dec-90 09:09:16 Sb: #8702-#C and buffers Fm: Pete Lyall 76703,4230 To: Dan Charrois 70721,1506 (X) Dan - If you want to avoid the "\n", try tacking an: fflush(stdout); This tells the buffering logic to toss the buffer contents even though an end of line (typical flag for dumping the buffer) hasn't been seen. If you don't mind losing the speed advantage of buffereing, you could just unbuffer the stream by: setbuf(stdout, NULL); Pete There is 1 Reply. #: 8718 S3/Languages 13-Dec-90 13:56:23 Sb: #8709-C and buffers Fm: Dan Charrois 70721,1506 To: Pete Lyall 76703,4230 (X) Thanks Pete. The speed isn't too important really, so I think I'll try the setbuf() approach first instead of using fflush() all the time. #: 8703 S4/MIDI and Music 13-Dec-90 03:48:39 Sb: #Midi device driver Fm: Dan Charrois 70721,1506 To: all I am posting this message on behalf of a friend of mine. He is wondering if a /midi device driver has been written for OS9 which includes clock pulses on the output, and if so, where it might be available. (I know virtually nothing of midi, so hopefully someone here makes sense of his question.) Thanks! Dan There is 1 Reply. #: 8710 S4/MIDI and Music 13-Dec-90 09:15:13 Sb: #8703-#Midi device driver Fm: Pete Lyall 76703,4230 To: Dan Charrois 70721,1506 (X) Dan - Nope... the only MIDI drivers are extremely primitive, and are really only useful for output. Some applications may send clocks (such as Lyra or Umuse under OS9), but no drivers. FYI, MIDI Clock is an $F8 byte sent out a rate based on the song's tempo. This allows other MIDI devices (sequencers, drum machines, etc.) to 'sync'hronize with the master device. Pete There is 1 Reply. #: 8719 S4/MIDI and Music 13-Dec-90 13:59:10 Sb: #8710-Midi device driver Fm: Dan Charrois 70721,1506 To: Pete Lyall 76703,4230 (X) Thanks for your reply, Pete. Interesting info on the clock byte... and considering the speed at which MIDI data is transferred, I'm not too surprised that the MIDI drivers available for OS9 are pretty primitive. #: 8706 S10/OS9/6809 (CoCo) 13-Dec-90 07:21:34 Sb: #SS.WTRK Fm: William Phelps 75100,265 To: ALL How does the SS.WTRK system call know what drive to use? If a path cannot be opened on an unformatted drive, then how can a path number be generated? William There are 2 Replies. #: 8711 S10/OS9/6809 (CoCo) 13-Dec-90 09:17:59 Sb: #8706-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - Good question... What about the combination of doing an open on /DD@, followed by an SS.Freeze (inhibits update of path/disk parameters the next time LSN0 is read)? Pete There is 1 Reply. #: 8732 S10/OS9/6809 (CoCo) 14-Dec-90 06:44:45 Sb: #8711-#SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) SS.FREEZE? What page of the manual is that on? William There is 1 Reply. #: 8738 S10/OS9/6809 (CoCo) 14-Dec-90 09:12:42 Sb: #8732-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - You may be a victim of the RS OS9 manuals. The $40 I spent eons ago to get the 'real' MW manuals was one of the best $40 I ever spent. Page 11-70 of the OS9 System Programmer's Manual says: SS.FRZ Input: A - Path Number B - SS.FRZ function code ($0A) Output: None Function: Inhibits the reading of the identification sector (LSN0) to memory DD.xxx variables (that define the disk formats) so non-standard disks may be read. Pete P.S. May already be defined in your os9defs or OS9.H files. There is 1 Reply. #: 8746 S10/OS9/6809 (CoCo) 15-Dec-90 04:31:15 Sb: #8738-#SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) When does SS.FRZ have to be called if reading a disk? William There is 1 Reply. #: 8749 S10/OS9/6809 (CoCo) 15-Dec-90 08:15:42 Sb: #8746-SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - I believe SS.FRZ is a single shot affair. It prevents the next would-be read of LSN0. In that case, the time to use it is before any implicit or explicit read of LSN0. I'd do it just after opening the path. Pete #: 8715 S10/OS9/6809 (CoCo) 13-Dec-90 11:16:20 Sb: #8706-#SS.WTRK Fm: Kevin Darling (UG Pres) 76703,4227 To: William Phelps 75100,265 (X) Pete has it. Try a simple basic09 program which opens "/d0@"... you'll see that the drive light doesn't come on. Thus you have an open path. This is exactly what format does. There is 1 Reply. #: 8733 S10/OS9/6809 (CoCo) 14-Dec-90 06:47:15 Sb: #8715-#SS.WTRK Fm: William Phelps 75100,265 To: Kevin Darling (UG Pres) 76703,4227 (X) I tried that, but the system tried to read the disk. William There is 1 Reply. #: 8739 S10/OS9/6809 (CoCo) 14-Dec-90 09:13:32 Sb: #8733-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - You tried open /dd@ ? Are you sure it wasn't open /dd ? Pete There is 1 Reply. #: 8747 S10/OS9/6809 (CoCo) 15-Dec-90 04:32:00 Sb: #8739-#SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) Well, I finally got it to work with: OPEN #path,"/d0@":UPDATE But now I have two more questions. Is it possible to read sector 0 if the standard OS-9 info is not there? If the pathname is input externally, then how can one tell the difference between a name for a floppy and a name for another type of disk. That last question assumes that the descriptors and drivers do not have to be the standard ones. William There are 2 Replies. #: 8750 S10/OS9/6809 (CoCo) 15-Dec-90 08:18:29 Sb: #8747-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - Not sure I understand the question. If you use SS.FRZ, I believe it's your responsibility to know what the disk's parameters are before you attempt to read it, and set them accordingly in the path yourself (using SS.OPT). The business about the name being external slipped right by me... care to rephrase & reask? Pete There is 1 Reply. #: 8773 S10/OS9/6809 (CoCo) 16-Dec-90 04:39:45 Sb: #8750-#SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) If the path to be opened is not in the program but rather taken from the command line or an input from the keyboard, then how can it be determined that a device is definitely a floppy drive? Reading IT.TYP is not good enough because some devices like ram disks look like flopies. Does Microware have any manuals that explain everything in the defs files? Most are obvious, but some ... William There is 1 Reply. #: 8785 S10/OS9/6809 (CoCo) 16-Dec-90 12:07:24 Sb: #8773-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) William - Basically, it the descriptor _says_ it's a floppy, it's a floppy. That's as sure as you can be. What other assurances do you want/need? Of course if it HAD to be a floppy for some obscure reason, you could write some low level nasty code to watch the index pulse LED from the disk bus, but that's incredibly ugly. I guess I fail to see the need? Care to explain why it's so important? Half of the beauty of os9/unix is that all devices and files look pretty much the same. Looks like you're trying to head the other way. Pete There is 1 Reply. #: 8797 S10/OS9/6809 (CoCo) 17-Dec-90 05:11:42 Sb: #8785-#SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) Actually, I wanted to add some extra disk functions without writing a whole new driver. The new functions might cause trouble if used on anything other than a floppy. William There is 1 Reply. #: 8803 S10/OS9/6809 (CoCo) 17-Dec-90 12:25:32 Sb: #8797-#SS.WTRK Fm: Pete Lyall 76703,4230 To: William Phelps 75100,265 (X) Well, in that case you should just observe the floppy/hard bit in the path (device) descriptor. Pete There is 1 Reply. #: 8830 S10/OS9/6809 (CoCo) 19-Dec-90 16:27:08 Sb: #8803-SS.WTRK Fm: William Phelps 75100,265 To: Pete Lyall 76703,4230 (X) I guess I will narrow the possibilities down to floppy or hard disks using the port address. Then I will use the TYP byte. William #: 8762 S10/OS9/6809 (CoCo) 15-Dec-90 19:50:46 Sb: #8747-#SS.WTRK Fm: Kevin Darling (UG Pres) 76703,4227 To: William Phelps 75100,265 (X) William - I think few drivers support SS.Frz, so the general answer is: it's pretty tough to read LSN 0 of a non-os9 disk. If you're using any of the Santy-like floppy drivers... the disto cc3disk, bob's cc3disk, or I think isted's cc3disk... then I believe you can use SS.Opts to set the non-OS9 disk bit ($40) in the Typ byte of the path descriptor. That causes those drivers to ignore LSN0, and use the defaults from the device descriptor (actually, the defaults in the path descriptor, which were copied from the dev desc). - kev There is 1 Reply. #: 8774 S10/OS9/6809 (CoCo) 16-Dec-90 04:40:10 Sb: #8762-SS.WTRK Fm: William Phelps 75100,265 To: Kevin Darling (UG Pres) 76703,4227 (X) If the TYP byte were changed in the Device descriptor, would that lockout error #249 regardless the of cause. William #: 8714 S10/OS9/6809 (CoCo) 13-Dec-90 10:52:05 Sb: #LISP for CoCo3 Fm: David Betz 76704,47 To: all I just received a letter from someone in Belgium asking about a more recent version of XLISP that runs on the CoCo3. He's got version 1.1 and is looking for 1.7 or later. Unfortunately, I didn't do the CoCo3 port of 1.1 and don't know who did. I would doubt that version 1.7 would fit in the 64K address space allowed by OS-9 L2 (or is it 64K of code and 64K of data?). So, does anyone know of a version of LISP or Scheme that will run on a CoCo3 under OS-9 L2? Thanks in advance, David Betz There is 1 Reply. #: 8722 S10/OS9/6809 (CoCo) 13-Dec-90 18:11:20 Sb: #8714-#LISP for CoCo3 Fm: James Jones 76257,562 To: David Betz 76704,47 (X) I did the 1.1 port; I also ported 1.2. I don't recall seeing 1.3, and I think 1.4 got too big (no separate I & D space on the 6809). I tried SIOD, and it runs fine on OSK but pukes immediately on my CoCo. I really need to go ahead and upload XLisp 1.2 here if I haven't already. There is 1 Reply. #: 8734 S10/OS9/6809 (CoCo) 14-Dec-90 08:53:52 Sb: #8722-#LISP for CoCo3 Fm: David Betz 76704,47 To: James Jones 76257,562 (X) Thanks. I figured that 1.7 wasn't going to fit. To tell the truth, I can't remember what the differences between 1.1 and 1.2 were. Also, there never was a version 1.3 released. For some reason, I went right from 1.2 to 1.4. I'm in the process of porting XScheme to OSK, but I doubt it would fit into 64K on the CoCo3. Do you know of any commercial implementations of LISP on the CoCo? There is 1 Reply. #: 8743 S10/OS9/6809 (CoCo) 14-Dec-90 23:08:41 Sb: #8734-#LISP for CoCo3 Fm: James Jones 76257,562 To: David Betz 76704,47 (X) I don't know about the CoCo, but there definitely is or was a Lisp for OS-9/6809 sold in Japan, called "Lisp09." There is 1 Reply. #: 8779 S10/OS9/6809 (CoCo) 16-Dec-90 08:07:47 Sb: #8743-#LISP for CoCo3 Fm: Dan Robins 73007,2473 To: James Jones 76257,562 (X) James, I recall seeing a LISP for OS9 in the User's group library, only I think they called it XLISP in this case. It may not be there now...but worth asking Gwit to see if it's archived. Dan There is 1 Reply. #: 8783 S10/OS9/6809 (CoCo) 16-Dec-90 10:52:55 Sb: #8779-#LISP for CoCo3 Fm: James Jones 76257,562 To: Dan Robins 73007,2473 (X) That's David Betz's Lisp interpreter (with object-oriented extensions). I guess I should go ahead and upload the 1.2 version in the "Languages" DL. There is 1 Reply. #: 8798 S10/OS9/6809 (CoCo) 17-Dec-90 06:05:10 Sb: #8783-#LISP for CoCo3 Fm: Dan Robins 73007,2473 To: James Jones 76257,562 (X) James, Not a bad idea (hint,hint,grin)...since it is topical at the moment, and others might want to play with it as well. Whatchathink? Dan There is 1 Reply. #: 8802 S10/OS9/6809 (CoCo) 17-Dec-90 07:52:47 Sb: #8798-#LISP for CoCo3 Fm: James Jones 76257,562 To: Dan Robins 73007,2473 (X) OK. It's kinda hectic this week, but I'll see if I can't do it. There is 1 Reply. #: 8883 S10/OS9/6809 (CoCo) 25-Dec-90 14:06:19 Sb: #8802-#LISP for CoCo3 Fm: MOTD Editor..Bill Brady 70126,267 To: James Jones 76257,562 (X) >>>> Rumor control! There is no 64k limit in Level 2. Just a 64 k segment space that the application must manage itself. (unfortunately). There is 1 Reply. #: 8904 S10/OS9/6809 (CoCo) 26-Dec-90 15:10:20 Sb: #8883-#LISP for CoCo3 Fm: David Betz 76704,47 To: MOTD Editor..Bill Brady 70126,267 (X) Does that mean that an individual application can access more than one 64K segment at a time? How does it do that? Are there mapping calls? There is 1 Reply. #: 8908 S10/OS9/6809 (CoCo) 27-Dec-90 05:06:12 Sb: #8904-#LISP for CoCo3 Fm: MOTD Editor..Bill Brady 70126,267 To: David Betz 76704,47 (X) What it means is that an application can use more that 64k. You can a non-mapped load, which puts modules in memory, but don't link them. You can them call them into your space when you need them. WizPro does this by keeping 16k free in its workspace, then RUNning & KILLing procedures as needed. Last time I tallied the total program size was about 128k. There is 1 Reply. #: 8911 S10/OS9/6809 (CoCo) 27-Dec-90 11:24:11 Sb: #8908-LISP for CoCo3 Fm: David Betz 76704,47 To: MOTD Editor..Bill Brady 70126,267 Can you use this trick to get access to more than 64K of data? XLisp and XScheme mostly need more data space, not more code space. #: 8723 S14/misc/info/Soapbox 13-Dec-90 21:05:39 Sb: Sen Tech/Test Eng Wanted Fm: Drake Philbrook 72557,3705 To: ALL December 13, 1990 RE: Position Available - Senior Technician/Test Engineer 360 Systems, a provider of commercial and broadcast audio products in the Los Angeles area, is interviewing for an experienced Senior Technician/Test Engineer. We need an individual with experience providing support to engineering and manufacturing. Must be a self-starter and be able to work with minimum supervision. This position requires knowledge of multiple processor systems and digital audio circuits. This includes: % 8 and 32 bit CPUs. % DSP % SCSI % DRAM % EIA 422/485 % analog and digital filters % precision analog circuits % Trouble-shooting at component level using standard test equipment. Demonstrableknowledge of a high level programming language and ASEE is a plus. Interested parties should send their resums to: Craig Lewis 360 Systems 18740 Oxnard Street, Ste 302 Tarzana, CA 91356 Please, no phone calls. #: 8725 S8/BBS Systems/TSMon 13-Dec-90 22:22:33 Sb: PlainRap BBS, California Fm: GENE TURNBOW 72457,220 To: ALL If any of you is in the San Fernando Valley, try the Plain Rap BBS. This is a completely noncommercial board, run for the love of it by Jim Sutemeier for the last eight years straight! It's on the StG net, and is the node used by Steve Bjork, who is the SigOp for the Hardware SIG. There are also SigOps for the C programming SIG, the RSDOS SIG and the OS-9 SIG, and most of the 12 SIGS are echoed across the StG network. The telephone number (gosh, I almost forgot!) is (818)772-8890. 2400, 8N1 24 hrs/day. #: 8745 S1/General Interest 15-Dec-90 04:26:45 Sb: #CoCo3 Status Fm: Ed Gresick 76576,3312 To: All To All: In their stock update dated 12/14/90, Tandy has changed the status of the CoCo 3 (260-3334) to SOWG - sold out when gone. I _understand_ that none are left in any of the warehouses. So, If anyone wants one, head down to your local RS store and pick one up. We are out of them. Ed Gresick - DELMAR CO There is 1 Reply. #: 8753 S1/General Interest 15-Dec-90 15:03:54 Sb: #8745-CoCo3 Status Fm: Jim Peasley 72726,1153 To: Ed Gresick 76576,3312 (X) Ahh, the passing of an era ...and the dawning of another (hopefully brighter!) ...Jim #: 8752 S10/OS9/6809 (CoCo) 15-Dec-90 14:48:30 Sb: #Help Fm: The Rev. Wayne C. Paul 76477,142 To: Mike Haaland 72300,1433 (X) Dear Mr. Haaland: On pg 6 of the doc's for EdPoint 1.2 you mention the following: Datadialog and icon display rotuines from Toby Farley BASIC09 MVDemo button routine from Kevin Darling. Are these files available on CIS? I am still a beginning programmer, but t is starting to come together. I have started working on an OS9 version of MAx-10. As soon as I get any working procedures, I will upload them to CIS. Thank you Brother Jeremy, CSJW CIS- The Rev. Wayne C. Paul 76477,142 There are 2 Replies. #: 8807 S10/OS9/6809 (CoCo) 17-Dec-90 20:39:11 Sb: #8752-#Help Fm: Mike Haaland 72300,1433 To: The Rev. Wayne C. Paul 76477,142 (X) The files you are looking for are in Lib 10. The one with the neat Icon display and DataDialog routines is called EDCON.AR and was written by Toby Farley. The second Basic09 source file is called MVDEMO.AR and was written by Kevin Darling. Both are in Lib 10. Good Luck on the Max-10 clone. Hope it's a BIG success, Mike There is 1 Reply. #: 8821 S10/OS9/6809 (CoCo) 19-Dec-90 01:00:07 Sb: #8807-Help Fm: The Rev. Wayne C. Paul 76477,142 To: Mike Haaland 72300,1433 (X) Thank you Mike, I will post anything that I come up with. #: 8808 S10/OS9/6809 (CoCo) 17-Dec-90 20:49:59 Sb: #8752-#Help Fm: Mike Haaland 72300,1433 To: The Rev. Wayne C. Paul 76477,142 (X) OOps! The second file is named MVTEST.AR (not MVDEMO.AR) Sorry about that. Mike There is 1 Reply. #: 8822 S10/OS9/6809 (CoCo) 19-Dec-90 01:01:05 Sb: #8808-Help Fm: The Rev. Wayne C. Paul 76477,142 To: Mike Haaland 72300,1433 (X) Got it. Thanks again. WCP+ #: 8756 S3/Languages 15-Dec-90 17:22:45 Sb: #FORTRAN available? Fm: Mike Passer 72750,420 To: All Hello! Does anyone out there know the whereabouts of a FORTRAN compiler for OS9 Level II on the Color Computer? If anyone has even half a lead, please let me know! Thanks, Mike Passer There are 2 Replies. #: 8763 S3/Languages 15-Dec-90 19:53:00 Sb: #8756-FORTRAN available? Fm: Kevin Darling (UG Pres) 76703,4227 To: Mike Passer 72750,420 (X) Mike - call MW at 515-224-1929.... I met someone last year who bought the FORTRAN package from them, and uses it on his CoCo-3. I believe it was around $300 (?). - kev #: 8765 S3/Languages 15-Dec-90 20:17:51 Sb: #8756-#FORTRAN available? Fm: Mike Passer 72750,420 To: Mike Passer 72750,420 (X) Kevin, $300! Gasp! Choke! I thought the MW version might have come down just a little - $100, I'm afraid, is about my limit. However, thanks for the suggestion, and I will give them a call, though I've heard that they no longer sell the 6809 compilers. Thanks! Mike There is 1 Reply. #: 8767 S3/Languages 15-Dec-90 21:06:24 Sb: #8765-#FORTRAN available? Fm: Kevin Darling (UG Pres) 76703,4227 To: Mike Passer 72750,420 (X) Mike - remember that Basic09 was $250 before Tandy bought enough to bring the price down . Perhaps the FORTRAN price will drop a bit in the future. There is 1 Reply. #: 8770 S3/Languages 15-Dec-90 21:56:15 Sb: #8767-#FORTRAN available? Fm: Mike Passer 72750,420 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, And now they're going for $10.00 at Radio Shack bargain tables! Too bad Tandy never decided to market FORTRAN for the Coco! :> I was actually hoping that someone out there in OS9 land had a dormant license that he was willing to sell me, but, I guess if it were that dormant, they wouldn't be looking _here_. I've heard about a small FORTRAN source for Unix, but don't know where on earth to start looking for it (besides the Unix and Computer Language Forums). I have the MW C compiler (still waiting for Radio Shack to mail me my cc2 and one pass compiler modules :>) and could give the old college try at porting it over (no, I don't value my sanity). On another subject, after reading the OS9 technical information section in the Level II manual, I wondered if there might be a modified system out there somewhere that does something besides print the "FAILED" message when system startup doesn't go as planned--maybe a hex code saying how far along it was, or something along those lines? Also, it says that the kernel initializes the system, inolving "Loading any required modules that were not loaded from the OS-9 Boot file." Does this mean that I could theoretically break up my boot and put the files in the execution directory (I know this is not a good idea - 8k blocks) and that OS9 would load them for me? Is this what happens with grfdrv, and, if so, why can't it go into OS9Boot? (If you hung on through this much rambling, take a break!) Ths again! Mike There is 1 Reply. #: 8771 S3/Languages 15-Dec-90 22:13:00 Sb: #8770-#FORTRAN available? Fm: Kevin Darling (UG Pres) 76703,4227 To: Mike Passer 72750,420 (X) In the upgrade, we modified REL so that it printed a number to tell how far you'd gotten (eg: BOOT FAILED #9 = no shell). That meant of course that we also had to modify os9p1, os9p2, sysgo, and perhaps one or two others to set an error byte before calling the D.Crash vector. So it's not an easy patch. You're right.. the system normally does not load any extra modules on boot. The exceptions are that CC3Go forks shell (which gets temporarily loaded), and CC3IO will load windint/grfint or vdgint, plus grfdrv. But none of those are the core kernel. The reason grfdrv can't go in the boot, is because it must sit alone in an 8K block.... it creates its own 64K "map" whenever it accesses the video memory and buffers. Actually, this isn't strictly true (it could straddle a coupla 8K blocks), altho the upgrade sure depends upon it. Umm, oh.. the important reason is because it's mapped out of the main system map, into its own map. Putting it into the boot would use up 8K of main system space (precious!) for no reason. Sorry, brain foggy ;-). kev There is 1 Reply. #: 8788 S3/Languages 16-Dec-90 14:47:06 Sb: #8771-FORTRAN available? Fm: Mike Passer 72750,420 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, Thanks for that info -- I don't quite have the distinction between system and user maps down yet, but I know that not having enough system memory can get you into trouble. Thus, the loading of grfdrv at the end of the boot make sense. Looking forward to seeing that upgrade someday. There's not too many things more frustrating that trying to figure out what caused that Boot Failed message (save Christmas shopping at the Crystal Mall in Waterford, CT or figure out what's really going on in the Gulf). Thanks, Mike #: 8758 S1/General Interest 15-Dec-90 18:48:02 Sb: #F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Pete Lyall 76703,4230 (X) Pete, Is there any magic to the F$CpyMem call? I've been trying to write a basic program - using syscall - that scans memory in search of data, make that, lost data - when I forget to name a Dynastar file and then back out of the program without saving the buffer. I can get the basic program to work, sort of. But all it grabs is multiple copies of one particular block. Or a few system blocks... When I force the program to look for absurdly high block numbers (above 48), I catch a few more, but they're scattered all over creation and repeat as many as 200 times. I set D to the block number (from 0 to 48 since I have 192K), X to 0 since I want the whole block from the beginning; Y to 4096 since I want the whole block and U to the address of the 4K buffer I've set up in basic. Shouldn't that work? Wendell There are 2 Replies. #: 8759 S1/General Interest 15-Dec-90 19:11:19 Sb: #8758-#F$CpyMem Fm: Pete Lyall 76703,4230 To: Wendell Benedetti 72766,2605 (X) Wendell - Never used CPYMEM much, but I know f$mapblk works ducky. Give it a shot (and remember to keep at least 1 slot vacant in your block map, as well as to UNMAP the block when done). Pete There is 1 Reply. #: 8766 S1/General Interest 15-Dec-90 21:04:05 Sb: #8759-F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Pete Lyall 76703,4230 (X) I'll give it a try. Thanks, Pete. Wendell #: 8764 S1/General Interest 15-Dec-90 19:59:47 Sb: #8758-#F$CpyMem Fm: Kevin Darling (UG Pres) 76703,4227 To: Wendell Benedetti 72766,2605 (X) Wendell - the D reg points to a DATImage... which contains the block number(s) of a 64K (fake) map you wish to copy from. So (thinking online here), you might set up a one-entry DATImage, and point to that: DIM datimage(8):INTEGER \ (* CoCo has 8 entries of 8K each datimage(0) = blocknum \ (* first 8K = desired block reg.D = addr(datimage) The offset in X would be $0000 as you surmised, and the Y copy count would be 4K for most L-II machines, or 8K for CoCos (to get entire block). Yell if doesn't make sense - kev There is 1 Reply. #: 8768 S1/General Interest 15-Dec-90 21:07:03 Sb: #8764-#F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Kevin Darling (UG Pres) 76703,4227 (X) Thanks, Kevin. I'm using a CMS level two machine so that's why the 4K block size. Wendell There is 1 Reply. #: 8769 S1/General Interest 15-Dec-90 21:09:32 Sb: #8768-#F$CpyMem Fm: Kevin Darling (UG Pres) 76703,4227 To: Wendell Benedetti 72766,2605 (X) Okay, I kinda thought you weren't using a coco. In that case, I forgot to mention that the DAT Image could have up to 16 entries composing a 64K map... the X offset would be into the entire map (of course, you'd need to set up at least as many entries as needed to "fill up" the area you're copying from). Luck! - kev There is 1 Reply. #: 8775 S1/General Interest 16-Dec-90 04:47:46 Sb: #8769-#F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, I tried your suggestion. But I changed DIM datimage(8) to DIM datimage(48) - to fit the CMS's 48 block RAM. I enter the blocks I want (by looking at Pmap or just guessing); then, with a FOR-Next loop, the whole mess repeatedly goes to Syscall (depending on the number of blocks) - and Voila! It works. But, don't ask me why! It seems like smoke and mirrors. Thanks, Kevin. Wendell There is 1 Reply. #: 8776 S1/General Interest 16-Dec-90 05:26:20 Sb: #8775-#F$CpyMem Fm: Kevin Darling (UG Pres) 76703,4227 To: Wendell Benedetti 72766,2605 (X) Glad to hear it worked... but I'm leery about the datimage(48)... the datimage max size on your system should be (16). It has nothing to do with the total number of blocks, but the number of blocks which can make up a 64K map, y'see. Ummm... and it won't work anyway : your X offset can't be over 64K anyway. Yah? So to get at all the blocks, you have to work 64K worth at a time. best - kev There are 2 Replies. #: 8777 S1/General Interest 16-Dec-90 05:57:10 Sb: #8776-F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, One more thing: DIM datimage(1) works just as well, since I'm only mapping one block at a time. Thanks again. Wendell #: 8790 S1/General Interest 16-Dec-90 15:33:53 Sb: #8776-#F$CpyMem Fm: Wendell Benedetti 72766,2605 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, I now think I understand what I've done. Since the D register is just a pointer (right?) to a memory location holding the block number, I've set up a loop like this: DIM datimage:integer INPUT "Low Block number? : ",first INPUT "High Block number? : ",last FOR look=first to last datimage=look D=ADDR(datimage) ...Figure out A and B ...Then call Syscall and print 4K block buffer to screen or file NEXT look My explanation is probably totally wacko, but the basic program works! I may even write it in assembly to save a little space and avoid overwriting any lost data. Thanks again, Kevin. Wendell There is 1 Reply. #: 8796 S1/General Interest 17-Dec-90 04:01:20 Sb: #8790-F$CpyMem Fm: Kevin Darling (UG Pres) 76703,4227 To: Wendell Benedetti 72766,2605 (X) Right-o. The D register is used as a pointer to the DAT Image for a fake (or real, in some cases) 64K map. Normally, OS9 L-II keeps a DAT Image for each process... when that proc's turn to run comes up, its 64K "image" is swapped into the DAT hardware, so that the process truly has a fairly normal 64K map unto itself. In other words, the OS keeps images of many 64K "machines". Including one for itself (the system map, where the kernel and drivers etc sit). Each image is composed of as many RAM blocks as required to hold the program code and data code... up to a 64K limit. By setting up your own image for F$CpyMem, you've created an artificial 64K world . For example, an image like this (for a CoCo. Your machine will have 16 entires/image, of 4K blocks each): 0003 - data 0004 - data 333E - nothing here (see DAT.Free in your DEFS/systype file 333E - " to see flag value for *your* machine) 333E - " 333E - " 0010 - program 0025 - program shows 16K of data RAM, and 16K of program RAM, mapped in... with 32K of "nothing" mapped in yet... where a subroutine module or data space could go. An X offset of $C000 for F$CpyMem would grab bytes starting at block 0010. A more common usage for F$CpyMem and DAT Images, btw, is to grab something from another process's space. If you get someone's process descriptor, you can point D to his P$DATImg, and voila! you can point X to any offset within that guy's own 64K space... and OS9 will use that offset and the image info to find the bytes you desired. best - kev #: 8778 S10/OS9/6809 (CoCo) 16-Dec-90 07:52:36 Sb: 900 Number Revisited Fm: James Jones 76257,562 To: All Well...I called the 900 number again last night--guess I just couldn't resist. Evidently "Ask Mr. Computer" does update the information, because this time they mentioned a slightly different number (OS-9 ahead by 125), and gave a total vote (227 votes altogether, which one can readily deduce from that "RSDOS" got 51 votes and OS-9 176--i.e. 77% for OS-9, 23% for DECB, which finally gives some idea of what's happening). I still am pretty curious about just who set up this poll. #: 8781 S4/MIDI and Music 16-Dec-90 08:50:28 Sb: #New Tune Fm: Ches Looney 73016,1336 To: Mike Knudsen 72467,1111 (X) Mike, One of my sons recently brought me a delightful piece of sheet music titled "The Battle of Gettysburg" which I have just uploaded. I think you may enjoy it; I had a lot of fun putting it through UME 4.7 with a bit of percussion on my new MT32. Let me know what you think of it. Have you any words of comment on the composer (E. T. Paull)? He's a new name to me but must have been most prolific in the early 1900s. Happy holidays to you and yours! Regards. Ches. There is 1 Reply. #: 8855 S4/MIDI and Music 22-Dec-90 23:19:00 Sb: #8781-#New Tune Fm: Mike Knudsen 72467,1111 To: Ches Looney 73016,1336 (X) Hi CHes. No, never heard of ET Paull -- there is a much older "Battle of Trenton" (Washington crossing the Deleware, Merry Xmas to the drunken Hessians), tho. Is "Gettysburg" for piano in the original? I'll come back at 2400 Baud sometime and grab it -for jhust reading mail here I use 300. I try to confine downloading to Delphi, at least till my rich uncle kicks off, grin. --mike k There is 1 Reply. #: 8862 S4/MIDI and Music 23-Dec-90 07:53:10 Sb: #8855-New Tune Fm: Ches Looney 73016,1336 To: Mike Knudsen 72467,1111 Yup, Gettysburg is for piano, but when I play it in piano, it's not as exciting as with the brass and percussion. I've heard of the "Battle of Trenton" but not heard the music. Happy Holidays. Ches. #: 8792 S10/OS9/6809 (CoCo) 16-Dec-90 19:17:32 Sb: #Starting out (part 1) Fm: Carlyle Hudkins 72040,2754 To: all I have a 128k CoCo 3, 1 FD-502 drive, which I have had for about 3 years. I recently bought OS9 and am having trouble adjusting to this new environment. I am conversant in CoCo BASIC, IBM BASIC, and IBM DOS. OS9 seems somewhat like IBM DOS, with enough changes to make me think I know what I'm doing when in reality I don't. My most recent problem is this: I went through the tedious disk-swapping using CONFIG, to create a customized System Master, as described in the "Getting Started" section of the manual, and created a disk with options PIPE, D040D, TERMWIN, W, W1, and FULL command set. Now I need to know what I will need to do in order to change the options, without going through the immensely painful CONFIG experience again. For instance, I want to change the usable Windows so that I might use graphics windows from BASIC09. I noticed that OS9gen can redo the Boot file, but there is a warning that this can fragment the Boot file, rendering the disk unusable. Other questions: Is the disk I made with CONFIG actually double-sided? I tried to format it using "format '40' 2," but through trial and error I discovered that the option "2" was not usable with the drive, as OS9 saw it at that time as a 35-trk, SS drive. Therefore, I did a regular '40' format and proceeded to CONFIG, telling CONFIG that I wanted D040D, in hopes that I will at least be able to format a DS from that disk. I don't yet know of a way to test a disk to see if it is DS, except from regular BASIC, and since I made the disk 40-trk BASIC wouldn't be able to use it anyway. It does not seem likely, in hindsight, that the disk I made is actually double sided, as only one side was formatted. I hope I will not have to use CONFIG again in order to make a real, DS, "Customized System Master"! Can I run a pure ML program, such as my terminal (Ultimaterm v4.0) or word processor (Simply Better v1.1) from a window so that I do not have to leave OS9 (which involves hitting Reset twice, necessitating removing the disk)? The WP uses a regular BASIC boot program to There are 2 Replies. #: 8795 S10/OS9/6809 (CoCo) 17-Dec-90 02:04:02 Sb: #8792-Starting out (part 1) Fm: James Jones 76257,562 To: Carlyle Hudkins 72040,2754 (X) You cannot run a program under OS-9 that was not written to run under OS-9, at least not unless you go to a considerable amount of trouble modifying it, as Chris Burke figured out how to do to the Color BASIC interpreter to get RSB. Download the "dmode" utility from here, and use it to modify th device descriptor for /d0 and /dd in memory to say the dt(rive is double-sided, then try formatting a disk. #: 8801 S10/OS9/6809 (CoCo) 17-Dec-90 07:48:27 Sb: #8792-#Starting out (part 1) Fm: William Phelps 75100,265 To: Carlyle Hudkins 72040,2754 (X) CONFIG does not change the format of the disk it writes on; so, the disk you made is still a plain SS one. Reboot using that disk; then xmode the window and printer descriptors to your liking. Format a new disk, and use COBBLER ow it. Copy "startup" over to the new disk. Make a "CMDS" directory, and copy shell and grfdrv into it(you can also copy any other commands you want). Now you will have a 40trk DS bootdisk. William There is 1 Reply. #: 8804 S10/OS9/6809 (CoCo) 17-Dec-90 17:03:38 Sb: #8801-#Starting out (part 1) Fm: Carlyle Hudkins 72040,2754 To: William Phelps 75100,265 (X) Thanks, William, but as a complete beginner how should I xmode the windows (I don't have a printer)? The manual says a lot about pauses, pages, null, and the like, but I'm not sure exactly what I should use it on in order to get the right results. If I understand this, the disk I now have should allow me to format a new disk DS. Then, I must create a bootfile (using Cobbler, which will put the modules I booted with onto the new disk). Then I copy "startup," use makdir to put CMDS on the new disk, copy "shell" & "grfdrv" (if I understand, shell is the actuall program I talk to OS9 through, and grfdrv is necessary if I want to enable a graphics window). I will try these, and see what happens! Carlyle H There are 3 Replies. #: 8805 S10/OS9/6809 (CoCo) 17-Dec-90 19:51:52 Sb: #8804-#Starting out (part 1) Fm: DAVID DE FEO 71630,721 To: Carlyle Hudkins 72040,2754 (X) Carlyle, to be able to do a double sided format, the drive descriptor in the boot file (d0 and ddd0) have to be the type for double sided drives. Your bootfile has to contain the following: d0_40d.dd and ddd0_40d.dd. You might want to use Config again to substitute these drivers in for the old ones, but if you feel adventerous, you can use OS9gen. It will probably be faster. You need to "build" a file called bootfile containing all the modules that you want in your system(you can find all the modules in the Modules directory of the config disk). Some modules that you have to include are: init, ioman, rbf.mn, cc3disk, d0_40d.dd, ddd0_40d.dd, scf.mn, cc3io, term_win.dt, clock.60hz, cc3go, w.dt, w1.dt, vdgint.io, grfint.io. Once the file is made "chd /d0/Modules" and "chx /d0/cmds" for single drive: os9gen /d0 -s So you'd pass on any Q's etc to the dealer you got OS9 from, and they'd in turn help you or ask MW. Seem reasonable? best - kev There is 1 Reply. #: 8834 S12/OS9/68000 (OSK) 20-Dec-90 06:18:00 Sb: #8833-#uWare support user OSK? Fm: Mike Passer 72750,420 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, Please see my message to you via EMail. (In case you don't have mail waiting enabled). Mike There is 1 Reply. #: 8864 S12/OS9/68000 (OSK) 23-Dec-90 10:04:30 Sb: #8834-#uWare support user OSK? Fm: Bud Hamblen 72466,256 To: Mike Passer 72750,420 (X) Mike, You ought to be able to buy extended support from Microware. You used to get 90 days of phone support from Microware with an OS-9 license and you'd buy extended support for a fair outlay. Bud There is 1 Reply. #: 8885 S12/OS9/68000 (OSK) 25-Dec-90 14:19:59 Sb: #8864-uWare support user OSK? Fm: MOTD Editor..Bill Brady 70126,267 To: Bud Hamblen 72466,256 (X) But y'll can get support right *here*. #: 8835 S12/OS9/68000 (OSK) 20-Dec-90 20:37:00 Sb: MM/1 Fm: Ron Johnson 72330,3373 To: Paul Ward Paul, A few (lot of) questions... Is the MM/1 shipping yet? If not when? How much does a plug-and-play system with monitor & hard drive cost? Is there any APPLICATION software <<< FINISHED >>> for it yet? If you don't know that off the top of your head, maybe you could post a list of ISVs on your developers program. Why hasn't anyone from IMS returned my phone calls for 3 weeks? I've called many times and never heard a peep from y'all. Back to the applications, is anyone working on a WP and a spreadsheet... They do not need to be integrated, but the ability of the S/S to read/write .DIF, comma-seperated text, or Lotus files would be a BIG help. Ron Johnson 72330,3373 #: 8838 S1/General Interest 21-Dec-90 02:59:15 Sb: Seasons Greetings Fm: Ed Gresick 76576,3312 To: ALL To ALL!! A WISH for a _Very_ _Merry_ _Christmas_ and Holiday Season to ALL! Ed Gresick - DELMAR CO #: 8839 S10/OS9/6809 (CoCo) 21-Dec-90 11:57:22 Sb: Inside OS9 Fm: REX GOODE 73777,3663 To: Kevin Darling Kevin, Where can I get a copy of your book, "Inside OS9"? Rex #: 8841 S10/OS9/6809 (CoCo) 21-Dec-90 12:20:00 Sb: #Downloading stuff Fm: Carlyle Hudkins 72040,2754 To: all A few people have advised me of files to get to help with things I need to do. Text files are no problem--I can read them with my WP. However, I know from experimenting that I cannot save a file to an OS9 disk (especially a 40-trk one) from outside OS9 (i.e. my terminal program). How, then, am I to use a utility, such as the recommended DMODE.AR, once I've downloaded it? Would running my term (Ultimaterm v4.0, pure ML) from a window help, and if so how do I manage this? Is there a text file in a Lib that would explain all this to me? If so, point me at it and I'll grab it and chew on it for a while. thanks, Carlyle H /post to:all;sb:Downloading Stuff There is 1 Reply. #: 8842 S10/OS9/6809 (CoCo) 21-Dec-90 13:10:52 Sb: #8841-Downloading stuff Fm: Pete Lyall 76703,4230 To: Carlyle Hudkins 72040,2754 (X) Carlyle - There's a program and documentation in DL10 called DOSOR9.BAS and DOSOR9.DOC. Grab these, and save them to an RS-DOS diskette. These will allow you to make an RSDOS diskette readable to OS9. That's one way you can move files over there. Another way is to use an OS9 terminal program. You'll NEED a serial port (not the one in the back of the machine, but a real one like an RS-232 pak, or one of the 3rd party versions), but it's worth it. Sterm for os9 supports ASCII, XModem, and B+ protocols, and is the terminal program of choice for os9 Compuserve folks. Sterm and goodies are in DL7. Pete #: 8843 S10/OS9/6809 (CoCo) 21-Dec-90 15:05:08 Sb: #Color of GFX Cursor? Fm: Zack Sessions 76407,1524 To: ALL I really don't have time to disassemble WindInt to figure this out, so if someone familiar with it or with this particular question, I would appreciate some input. Basically, what determines which palette slot(s) govern the color of an autofollow mouse cursor? What I know is that, the color of the mouse can't stay the same palette all the time. What if it is moved to an area which is completely filled by that palette? It would disappear! So WindInt (or somebody) can change the palette of any part of an autofollow mouse cursor (and does!) as it chooses. Just how does "it chooses"? TIA, Zack Sessions There is 1 Reply. #: 8844 S10/OS9/6809 (CoCo) 21-Dec-90 15:24:06 Sb: #8843-#Color of GFX Cursor? Fm: Kevin Darling (UG Pres) 76703,4227 To: Zack Sessions 76407,1524 (X) Zack - the cursor is simply an XOR of the bits on the screen. Thus the color depends upon the background, and the palette slot the data XORs out to. Nothing fancier than that. In other words, if your cursor is over a background of palette 0 in a 4-color screen, then the bits become palette 3. Of course, if both palettes 0 and 3 are say, white... then you get no visible cursor . Which usually is no concern except in gfx paint programs. Which is why old Max9 had two-color cursors, so that your chances increased for being able to see the thing on most pictures. (the two colors were done by creating put buffers with mixed bits in them... I guess that wouldn't work ... ummm yes it should work for autofollow too, i think). There are 2 Replies. #: 8846 S10/OS9/6809 (CoCo) 22-Dec-90 18:39:45 Sb: #8844-#Color of GFX Cursor? Fm: Joseph Cheek 76264,142 To: Kevin Darling (UG Pres) 76703,4227 (X) I believe you can create 4- and 16-color mouse pointers. just use the image you need and make sure you set the STY type correctly. should i explain it better? There is 1 Reply. #: 8849 S10/OS9/6809 (CoCo) 22-Dec-90 20:14:06 Sb: #8846-Color of GFX Cursor? Fm: Kevin Darling (UG Pres) 76703,4227 To: Joseph Cheek 76264,142 (X) Joe - I think you're right. THe mouse cursor is really just a PUTBLK each time in XOR logic mode... so a different STY type and data should work as you said. #: 8847 S10/OS9/6809 (CoCo) 22-Dec-90 18:58:43 Sb: #8844-#Color of GFX Cursor? Fm: John Ranck 73540,246 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, What if you want ot change the cursor to an underscore. Thats what it is in school on the Vax and I always like my CoCo to be more like the Vax and the Vax to be more like my CoCo. I've always wandered if there was a way to change it. Could you change like you can change mouse pointers or something. Is it mapped in w/ the fonts as a character or is it in CC3io itself? Is there a way to change the pattern of the cursor? Is there anything about this in Inside OS9? I didn't see it so thats why I'm wondering. Its a good book though. Lots info. L8R & Thanx Mike There is 1 Reply. #: 8850 S10/OS9/6809 (CoCo) 22-Dec-90 20:30:34 Sb: #8847-Color of GFX Cursor? Fm: Kevin Darling (UG Pres) 76703,4227 To: John Ranck 73540,246 (X) Well, I was about to say "sure, piece of cake"... until I looked at that part of Grfdrv... and it's not just a matter of changing something in place, as I'd hoped. Ummm. It's a not a char in the font, no. The text cursor routine reverses the attributes on a rom-text screen, and does an XOR of the whole char area on a gfx-screen... using the normal charput routines instead of a special routine... making it harder to just patch in place. (note: they partly did it this way because the cursor also had to handle proportional text, too - tough one). #: 8845 S12/OS9/68000 (OSK) 22-Dec-90 17:53:25 Sb: #OS9/ST on Atari TT Fm: DENIS CHARTRAND 72561,2714 To: All Anyone was able to boot OS-9/ST v2.3 on the 68030 32 MHz equiped Atari TT? On the 4M bytes model that I've tried, the TT crashs after STARTFD.PRG prompts for "Insert OS9 Boot diskette and Press a key" a soon I touch the keyboard. Too bad, the computer is very very fast and seems to be nice. No improvments even if I ask for a ST compatible mode instead of the default TT mode. Maybe I should try with older version of OSK, 2.2 or 1.2. But I don't think it will help. Anyway, even if it works, drivers will have to be written for the additional ports, like the two serial 85C30 SDLC ports, the 68882, the VME bus, the SCSI connector, the LAN outlet, etc. Also the MS-DOS emulator PC-DITTO (software version) does not work. Others TOS programs that were in the store (Calamus, etc) seems to work OK. BYE There is 1 Reply. #: 8848 S12/OS9/68000 (OSK) 22-Dec-90 20:12:56 Sb: #8845-OS9/ST on Atari TT Fm: Kevin Darling (UG Pres) 76703,4227 To: DENIS CHARTRAND 72561,2714 (X) Denis - I believe each of the 680x0 cpu family handles exceptions (what's put on the stack) differently... which means you'd need a 68030 OS9 kernel, at least (or most ;-). Where'd you see the TT, btw? Are you in Canada? #: 8863 S12/OS9/68000 (OSK) 23-Dec-90 09:35:28 Sb: #OS9/ST on Atari TT Fm: DENIS CHARTRAND 72561,2714 To: Kevin Darling Hi, Kevin. Yes, I'm from Montreal. The TT computers can be seen here since around early September in computers shows, but is available on market since this month. In recent european magazines, Atari TT article reviews specified the following hardware as standard in a plain TT computer: - 68030-33 used at 32MHz - 68882-33 used also at 32MHz - 8M bytes of RAM divided in two banks: - 4M bytes of ST compatible RAM, 80 nsec, 64 bits wide - 4M bytes of TT RAM, 100 nsec, 32 bits wide - TOS 3.0.1 (512K bytes of ROM) - 128K cartridge port, ST compatible - graphics resolution same as ST plus (palette of 4096 colors): - 320 X 480, 256 colors - 640 X 480, 16 colors - 1280 X 960 (monochrome) - 2 stereo RCA ports - internal speaker - 2 MIDI ports, ST compatible (ACIA6850) - 4 serials ports: - 2 RS232 ports, MFP68901 (ST compatible) - 2 85C30 hi-speed SDLC ports - one network LAN port, LocalTalk compatible - one DMA ACSI port ST compatible - one DMA SCSI port - one internal SCSI 48M bytes hard disk, 28 msec - one 3.5" drive, 720K bytes, ST compatible - one external floppy port - one VME A24/D16 connector - one MC146818 real time clock Too bad they don't have a 1.44 3.5" drive. To have more or less memory means a special configuration for this computer (like the one I saw in store with 4M bytes of RAM). In reviews, speed gain over a standard ST computer varies from 200% to 9786%, depending of the application. ATX, an UNIX System V release 4 with X Windows, OSF Motif and so on, is due in March 91. But then a 80M bytes hard disk and more memory will be necessary. I had the idea that a 68030 CPU can emulate a 68000 CPU without problems. Thanks for the note. Merry Christmas. There are 2 Replies. #: 8868 S12/OS9/68000 (OSK) 23-Dec-90 22:01:00 Sb: #8863-#OS9/ST on Atari TT Fm: Kevin Darling (UG Pres) 76703,4227 To: DENIS CHARTRAND 72561,2714 (X) Denis - the 030 is compatible with the 000, but only from the user program side of things. A few system-state things change tho, from model to model. In other words, a few sections of the kernel have to be changed, but otherwise everything else would run just fine (apps, even drivers I'd think). They (Motorola) figured that having to change the OS slightly was okay, as long as user programs were still compatible. I think they were right, because you'd want to take advantage of new features in the kernel if possible, anyway. best - kev There is 1 Reply. #: 8889 S12/OS9/68000 (OSK) 25-Dec-90 14:31:38 Sb: #8868-OS9/ST on Atari TT Fm: MOTD Editor..Bill Brady 70126,267 To: Kevin Darling (UG Pres) 76703,4227 (X) Say, Kev.... I think Toad Computers here has TT's. #: 8887 S12/OS9/68000 (OSK) 25-Dec-90 14:30:24 Sb: #8863-OS9/ST on Atari TT Fm: MOTD Editor..Bill Brady 70126,267 To: DENIS CHARTRAND 72561,2714 (X) Too bad they kept the 68901. I learned to hate that sucker. #: 8869 S12/OS9/68000 (OSK) 24-Dec-90 09:24:14 Sb: #OS9/ST on Atari TT Fm: DENIS CHARTRAND 72561,2714 To: Kevin Darling Also, of course, about the list of equipment on the TT: 1 Centronics parallel port and joystick/mouse port. There is room for 26M bytes of RAM. The LAN, SCSI and ACSI ports work in true DMA mode. There is also a connector where you can plug a ST compatible hard disk, in addition to the ACSI port which is already a DMA ST compatible port. BYE There is 1 Reply. #: 8870 S12/OS9/68000 (OSK) 24-Dec-90 14:15:32 Sb: #8869-#OS9/ST on Atari TT Fm: Kevin Darling (UG Pres) 76703,4227 To: DENIS CHARTRAND 72561,2714 (X) Denis - also, I'm not positive, but I think I heard that later models will have the hidens 3.5 drive capability. Thx for all the info, btw! There is 1 Reply. #: 8890 S12/OS9/68000 (OSK) 25-Dec-90 14:32:25 Sb: #8870-OS9/ST on Atari TT Fm: MOTD Editor..Bill Brady 70126,267 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, if ya want a TT, lemme know. I'm still "registered". #: 8873 S1/General Interest 25-Dec-90 06:09:41 Sb: #OS-9000/386 Fm: MOTD Editor..Bill Brady 70126,267 To: all Last night Santa delivered OS-9000! (368) Now I have to find a 386 PC to run it!... Merry Christmas all! There are 2 Replies. #: 8874 S1/General Interest 25-Dec-90 07:14:04 Sb: #8873-#OS-9000/386 Fm: Kevin Darling (UG Pres) 76703,4227 To: MOTD Editor..Bill Brady 70126,267 (X) Wow! Now that's what I call a present! Merry Christmas to you and Jane, too! And to everyone out there! You're the greatest bunch of people in the world. best wishes to all - kevin and marsha There are 3 Replies. #: 8875 S1/General Interest 25-Dec-90 08:58:20 Sb: #8874-OS-9000/386 Fm: Zack Sessions 76407,1524 To: Kevin Darling (UG Pres) 76703,4227 (X) Here's my Christmas wishes to the Darlings and all the other great people I've met on CompuServe! May you all have many, many more! Zack Sessions #: 8891 S1/General Interest 25-Dec-90 14:34:28 Sb: #8874-OS-9000/386 Fm: MOTD Editor..Bill Brady 70126,267 To: Kevin Darling (UG Pres) 76703,4227 (X) I'll call you later so's we can chat about 9000. Tell Marsha: thanks for putting up with us Computer nuts. Say... did I tell you about my $88 31 MHz XT? #: 8990 S1/General Interest 01-Jan-91 17:29:42 Sb: #8874-OS-9000/386 Fm: James Jones 76257,562 To: Kevin Darling (UG Pres) 76703,4227 (X) Shoot, Kevin...you know that we think the same of you. Hope your holidays were pleasant. #: 8973 S1/General Interest 31-Dec-90 19:11:15 Sb: #8873-OS-9000/386 Fm: Jim Peasley 72726,1153 To: MOTD Editor..Bill Brady 70126,267 Bill; In your search, check out (if you have one in your area) the Price Club's line of PC's - from POSITIVE in Chatsworth, CA. We picked up a 25Mhz. 386 with 2Meg of RAM, a 40 Meg HD (too small - get at least an 80 megger or >> ), DOS 4.01, Windows 3.0, mouse, kbd, VGA monitor for < $2100+tax. Excellent warrantee (with on-site repair) and toll-free hot line. Be sure and post a review of OS-9000 when you're up and running!! Luck, ...Jim #: 8892 S3/Languages 25-Dec-90 15:55:01 Sb: Pascal Fm: Paul Rinear 73757,1413 To: Anyone Greetings, I'm trying to use the OS9 Pascal package. With PASCAL in memory, and also in CMDS, and with a Pascal source code file in the working directory, typing PASCAL < filename #20k returns Error #244. Can you help me get started? Paul R. #: 8894 S12/OS9/68000 (OSK) 26-Dec-90 05:05:16 Sb: #blarslib available Fm: Robert A. Larson 75126,723 To: all A beta-test version of blarslib, my unix-compatability library for os9/68k is available for anonymous ftp from smilodon.cs.wisc.edu. The compressed tar file is 53128 bytes. (Source of course.) Smilodon also has source for compress, tar, a number of little utilities I wrote (some of them available elsewhere), TOP, diffs for porting GCC to osk (no confermation that they work, some people have tried and failed), etc. ls-lR_pub contains the current list. Questions about blarslib or my utilities should be sent to blarson@usc.edu. Questions about the smilodon archives should be sent to pruyne@cs.wisc.edu. Compuserve users who don't have direct access to the Internet should note: compuserve now supports mail to and from the Internet. bitftp@pucc.princeton.edu accepts ftp commands via mail and mails back the results. (Send it the message "help" for instructions.) The maintainer of the Internet end of the compuserve/Internet mail link has complained that the 9600 baud link can't keep up with the demand. (Compuserve should be encoraged to get a higher bandwidth link and a local cache of ftpable files.) I refuse to waste my money and time uploading things to compuserve. If someone else wishes to do so, they may. Watch comp.os.os9 for further announcements. (Ask compuserve why they don't get usenet newsgroups, not me.) There is 1 Reply. #: 8902 S12/OS9/68000 (OSK) 26-Dec-90 10:14:11 Sb: #8894-blarslib available Fm: Zack Sessions 76407,1524 To: Robert A. Larson 75126,723 (X) You may think you are wating your time when uploading to CIS, but you certainly aren't wating your money. Connect charges are suspended while uploading. Zack #: 8899 S12/OS9/68000 (OSK) 26-Dec-90 08:33:26 Sb: #68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: All For some time now I've been tinkering with the idea of writing an assembler for the 68000. I'm using SK*DOS, which doesn't currently have a relocating assembler, and we need one. I'm also adding a disassembler to my hex debugger. I've made several stabs at it, but I keep getting bogged down in complexity, and I finally figured out the reason: 68000 assembly language is _AWFUL_! Never mind the complexities in the hardware, or the fact that, having set themselves a goal of an orthogonal instruction set, Motorola then set out to introduce all kinds of bizarre non-orthogonalities. That's in the hardware, and there's nothing we can do about that. Let's just concentrate on the assembler language. I finally realized (I'm a little slow, sometimes) that part of my problem is that the mnemonics are inconsistent and irrational. For one thing, there are cases such as ADD, and ADDA where they chose to use separate mnemonics for what is essentially the same instruction (with the same opcode). [ I know, I know ... most assemblers allow ADD for ADDA, but they still have to support both.] Then, on the other hand, there are cases like ASL in which the same mnemonic refers to completely different instructions, with vastly different opcodes and argument encoding, depending upon whether we're shifting a register or a memory word. [More] There are 2 Replies. #: 8900 S12/OS9/68000 (OSK) 26-Dec-90 08:33:35 Sb: #8899-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] Worse yet, though, is the syntax of the arguments. Consider the two instructions MOVE -(A0),D0 and MOVE -(A06 + (4 * D05)/2)(A0,D0),D0 Both of these areperfectly valid instructions, assuming the labels A06 and D05 are defined somewhere. But, of course, the encoding of the instructions are completely different. And a parser, scanning from left to right, can't tell which kind of instruction it's dealing with until it gets to the fifth character of the first operand. In other words, a predictive parse is not possible without some prefiltering by the lexical scanner. This is the same problem as the old FORTRAN problem, often given as this example: DO 10 I=1.5 which is an assignment to the variable DO10I, but the compiler doesn't know that until it sees the '.'. After all these years, you'd think that we wouldn't fall into that trap again! I finally figured out how other folks do it: They keep a set of legal argument strings around (things like "-(A0)", '-(A1)", etc.) and compare the whole argument string with them, looking for the special cases. If nothing matches the "canned arguments, then they assume it's an expression. Even then, the argument could be: [More] There is 1 Reply. #: 8901 S12/OS9/68000 (OSK) 26-Dec-90 08:33:42 Sb: #8900-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] (An) (An, Rx) (PC) or (PC, Rx) Now, here's the proposition: Is anyone besides me interested in defining a better syntax? I figure, as long as I'm writing an assembler, why not choose the syntax to be easier, both to code in and to assemble? I have two alternatives: (1) Pick a new set of mnemonics, and a new syntax for arguments, that's parsible by a simple predictive parser. Make it as rational as possible, and use different mnemonics where different operations are implied. or (2) While I'm at it, make the language more like a high-order language. In other words, instead of MOVE X(PC),D0 D0 = X ADD Y(PC),D0 use D0 += Y (or perhaps just D0 + Y) JSR FOOBAR CALL FOOBAR I'd appreciate comments/ideas/criticisms. Anyone want to help define such a language? Anyone have any better ideas? Anyone out there who _DOESN'T_ think I'm crazy? Jack There is 1 Reply. #: 8916 S12/OS9/68000 (OSK) 27-Dec-90 21:39:47 Sb: #8901-#68000 ASM Language Fm: Jay Truesdale 72176,3565 To: Jack Crenshaw 72325,1327 (X) Jack: The C Users Group has a 68000 assembler written in C (CUG disk #190), with C source code included. I think they get $5.00/disk? I suggest picking up a copy of the "C Users Journal" at your local book store (I found it at a Waldens) for more information. For $5.00 I don't see how you can go wrong and it might shed some light on your problems and keep you from having to re-invent the wheel. -J There are 2 Replies. #: 8924 S12/OS9/68000 (OSK) 28-Dec-90 01:05:36 Sb: #8916-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jay Truesdale 72176,3565 (X) Jay, I already have that assembler. A conventional assembler is not what I'm looking for. But thanks for the info, anyway. Jack #: 8943 S12/OS9/68000 (OSK) 29-Dec-90 20:07:44 Sb: #8916-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jay Truesdale 72176,3565 (X) Jay, looking back on it I realize I gave you a rather short answer, and one that perhaps needs some elaboration. I have two goals: (1) Get a relocating assembler/linker combo (2) Define a "more rational" assembly language, preferably one that looks more like a high-order language. I'd _LIKE_ to be able to get both in one shot, but there's no law that says I _HAVE_ to do it that way. As a matter of fact, I'm sure that there will be people who'll prefer the conventional assembler anyway. So the right answer should probably be: Yes, the CUG assembler may well meet need #1. All I'd have to do there is change the object-file format. If I still want the other thing, I could then write it using the same format. The same linker would work for both, of course. BTW, I came from the CP/M world, and there I had the world's best assembler-language tools: The assembler/linker/librarian from SLR. I learned one thing from Steve Russell, which is that the tools work much better, and are even easier to build, when they're tightly integrated together. Logical extension: Build a conventional assembler with good linker & librarian first, then add a HOL-like assembler, and possibly a HOL compiler, all integrated together. Thanks for steering my thoughts in that direction. Jack #: 8913 S12/OS9/68000 (OSK) 27-Dec-90 15:13:55 Sb: #8899-#68000 ASM Language Fm: Ed Gresick 76576,3312 To: Jack Crenshaw 72325,1327 (X) Hi Jack! Yeah - You're crazy --- crazy like a fox!! And you're a rabble rouser, too :-). I'm all for your idea of a _new_ approach to designing an assembler and I like the idea of a high-order language. I suppose the current mnemonics are a carry over from the days when memory was scarce and expensive. So many ideas come to mind - I could easily spec out a monster! Let me throw some of these out so you can shoot them down. Could the new assembler be a combination interpreter/assembler? In other words, could an assembler be designed to permit testing the code prior to assembling? This, coupled with sensible syntax, could allow concentrating on the objectives of the program rather than the details of the code. Why not a generic assembler? Maybe it could cover the 680x0 series and the xxx86 series chips. I've noticed when coverting 86 code to 68 code, certain sequences can be automatically converted - and if I knew more, I would've set up macros. Can't the assembler do this by telling it what chip you're writing for? Could the assembler do automatic register selection? Tell the assembler what registers are reserved (for system, etc.) and then let the assembler select the registers - would probably require the assembler to automatically set-up data areas, but so what. I can go on but I better shut-up. In any event I'd certainly be happy to help you in any way I can (don't know the first thing about writing an assembler - but I'm a terrific kibitzer)! Good Luck, Ed Gresick - DELMAR CO There is 1 Reply. #: 8918 S12/OS9/68000 (OSK) 27-Dec-90 23:53:27 Sb: #8913-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Ed Gresick 76576,3312 (X) Ed, one of the interesting things about the software business is what creatures of habit we are. For people who claim to be creative, it's amazing how much we stick to the "tried and true." Look at the following code: foobar: move x(pc),d0 move y(pc),d0 bge next subq #1,d1 dbra foobar next: ... Not everyone would recognize the particular machine this is for, but almost EVERYONE would agree that this looks like assembler language. The layout: Labels starting in column 1, three or four-letter mnemonics, followed by arguments ... dates from the original assembler, SAP, for the IBM 650 circa 1952. We've been using it ever since. I've never understood why people pick mnemonics like JSR or BRA when there are perfectly good words (CALL and GOTO) already in use. Some years ago I set out to define a "rational" assembler language for the 8080. A few examples are show below MOV A,B --> A=B ADD A,B --> A+B CALL FOO --> CALL FOO { That's one Intel got RIGHT!) JNZ BAR --> IF !0 BAR [More] There are 2 Replies. #: 8919 S12/OS9/68000 (OSK) 27-Dec-90 23:53:35 Sb: #8918-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] I was real pleased with the language, but at that time I didn't know enough about how to build an assembler to implement it. Now I do. Unfortunately, the technology keeps passing me by. By the time I had the 8080 syntax defined, along came the Z80, with extra addressing modes and instructions. By the time I got those figured out, I was suddenly in the 68000 business. Gotta learn to work faster! When I first started programming for the 68000, I had a real problem with some of the branch instructions. Like DBcc, for example, NEVER seems to do what the instruction seems to say. So I wrote a structured preprocessor for the assembler. I had constructs like IF..THEN..ELSE..ENDIF, WHILE..ENDWHILE, and FOR.. ENDFOR. I wrote a prototype in Turbo Pascal for my PC, and it worked like a champ. I was truly surprised at how easy it is. Never implemented it for SK*DOS (early on, the development tools weren't up to the task), but it's still in my job jar. I don't need help building the assembler. What I _COULD_ use lots of help on is defining the language. More on this in the next message: [More] There is 1 Reply. #: 8920 S12/OS9/68000 (OSK) 27-Dec-90 23:53:42 Sb: #8919-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] The first decision is: Do I keep the conventional format (label, mnemonic, operands) ... in other words, try to remain as faithful to convention as possible, or do I go for the A=B approach? The next decision is: How to handle all the addressing modes, sizes, etc. Either way I go, I obviously have to allow for the generation of any instruction that the normal assembler provides. The size parameters give me fits, too. I'm sorta toying with the idea of a size declaration. In other words, you could declare D0, say, to be size byte. From then on, until you redeclare it, every reference to D0 would produce a byte instruction. Saves all the '.B's. [More] There is 1 Reply. #: 8921 S12/OS9/68000 (OSK) 27-Dec-90 23:53:51 Sb: #8920-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] A little history: Several people have tried to do similar things with assemblers. One notable is by Ed Ream, author of the editor "red." He came up with a unique approach, which was to make the assembler look like legal K & R C. In other words, expressions like d0 += d1; are perfectly legal C expressions. In fact, Ed's anguage was such a proper subset of C that it would compile under a C compiler (with the identifiers d0, d1, ... d7, a0, a1, ... a7, etc. just compiled as normal variables. (Not sure how Ed handled the size issue. Maybe I'd best go back and take another look.) Only one problem: The assembler ran slower than Christmas, and some of the constructs were pretty weird. Another fellow did the same thing for the Z-80 ... using C-like constructs. His program was really just a preprocessor, and also too slow to be much use. But the worst problem was some of the instructions. For example, the Z-80 LDIR (load, increment, and repeat) instruction translated to the following C code: while(bc--){*de++=*hl++) Frankly, it's a lot easier for me just to type LDIR! I concluded from all this that it's a bad idea to try to warp the assembler to fit an existing language like C. Better to start with a clean slate. (one more message, I promise) [More] There is 1 Reply. #: 8922 S12/OS9/68000 (OSK) 27-Dec-90 23:54:00 Sb: #8921-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] I've identified three main kinds of instructions: (1) The binary instructions, like D0 = X or D0 + D1. If someone _REALLY_ wants to keep a C-like syntax, I'll settle for D0 += D1, but I sort of like the stark simplicity of the first form. (2) The unary operators, like not ( !D0), negate (-D0), and shifts ( >>D0 or << D0, 4 ) (3) Things like LDIR that are better left as mnemonics. It's best to think of these as "built-in function calls." Whichever approach I take (modified traditional, or C-like), it's important that the syntax be written so it can be handled by a predictive parser. That simply means that when you see a certain character (or, more generally, a token) you always know what to do. That, in turn, means that constructs like -(A0), which starts out looking like an expression, are N.G. Hope this stimulates some thought & discussion. I'll build the assembler if (a) Anyone cares, and (b) we can agree on what should be built. I've gotten one mail message so far that said don't do anything. That may be the consensus, but for those who are concerned about compatibility, I'd like to point out: A screen editor like Brief, with good global substitution facilities, can take care of different notations pretty quickly. Jack There is 1 Reply. #: 8930 S12/OS9/68000 (OSK) 28-Dec-90 14:11:14 Sb: #8922-#68000 ASM Language Fm: William Phelps 75100,265 To: Jack Crenshaw 72325,1327 (X) Jack, Since this is the OS-9 Forum I have a question. In your first message you said that you wanted to develop a relocatable assembler fo SK*DOS; do you want to write a normal assembler, or do you want reentrant PIC? If you only want normal code we can fix that later 8-). As you know, the reason that new assemblers still use mnemonics like BRA is compatability with existing code. If you want that then you can write your assembler the same way. If you do not care about that, then why not go all the way -- natural language interpretation. How about a program written like this: * This is a menu subroutine window load data register 0 with the screen width subtract 1 from data register 0 ...... Notice how the code is self documenting and MUST do what is says it will do. In order to easily handle things like expressions, the assembler should RUN in a high level language. Any variables used should also automatically be placed in the data area -- we don't want self-modifying code do we. [continued next message] There are 2 Replies. #: 8931 S12/OS9/68000 (OSK) 28-Dec-90 14:11:52 Sb: #8930-68000 ASM Language Fm: William Phelps 75100,265 To: William Phelps 75100,265 (X) Some of the high level features mentioned are found in Forth assemblers(with are really cross assemblers even if running on the native chip). Forth assemblers also compile code WHILE it is being written, which would allow the programmer to immediately be given the clock cycles for a routine. Also, macros and the high level functions of the language can easily be used in such an assembler. ** To be fair Forth is not the only language with these capabilities, just the most visible. The the only disadvantage of a natural language assembly interpreter I see is the amount of work needed to write it. William #: 8938 S12/OS9/68000 (OSK) 29-Dec-90 20:07:02 Sb: #8930-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: William Phelps 75100,265 (X) William, I'm only just getting started in OS9, and my "baseline" system is SK*DOS, until something better comes along. I posted the message here because, OS9 or no OS9, this is the only forum where people talk much about 68000's. Re the PIC: That would be best. SK*DOS (and OS9) requires it. Which sort of means that the assembler shouldn't make you do anything special to get it. There _ARE_ some implementation issues that I haven't worked out yet. Example: You can address variables PC-relative, but then if you're using OS9 you can also address them base A6. Since the fundamental nature of the assembler is to let the programmer do anything the chip will support, I suppose that you can't assume anything, or impose any coding style. Still, there should be some easy way to tell the assembler what you want, instead of having to write things like foo-base(a6) all the time. I've thought of having pseudo-ops something like BASE A6 = OFFSET BASE PC or BASE ABSOLUTE so that once declared, you could reference data from that base. (Don't know WHAT you do if you need more than one!) As for control references, I'd like to see BRA's and BSR's generated by default, with some kind of mechanism for dealing with things out of range and/or external. [More] There is 1 Reply. #: 8939 S12/OS9/68000 (OSK) 29-Dec-90 20:07:07 Sb: #8938-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] Re "natural" language: BAD IDEA! The last time someone tried that, the result was COBOL. Technically, a roaring success since it's still the most common programming language in use today, but from a computer science (or productivity) point of view, a terrible disaster that has cost us megabucks. I don't think there's a language expert alive that wants to see _THAT_ experiment repeated! Jack There is 1 Reply. #: 8957 S12/OS9/68000 (OSK) 30-Dec-90 12:14:15 Sb: #8939-#68000 ASM Language Fm: William Phelps 75100,265 To: Jack Crenshaw 72325,1327 (X) Re:base addresses & assembler assumptions Why not use command line directives to tell the assembler what mode it is in? Some existing assembler have Motorola or OS-9 modes, and others have 68000 or 68020 modes that are switched from the command line. Re:natural language I did not mean to try to include everything & the kitchen sink, as COBOL does. Only machine language and a method of accessing system calls should be in the assembly language. Only two major changes would be necessary to make the assembly language look like "natural" language:(1) expanding the mnemonics to the words they represent, and (2) automatic definition of variables with their use. It is obvious from XREF type programs that computers can handle variable definition better after they have been used. The syntax for "natural" language would be almost identical to normal assembly language. William There is 1 Reply. #: 8965 S12/OS9/68000 (OSK) 30-Dec-90 23:56:18 Sb: #8957-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: William Phelps 75100,265 (X) William, thanks for the inputs. I'll have to go off and think about them. I have no problem with specifying the addressing modes in the command line (although it would also be nice to be able to do so as program commands. What I was thinking about was cases where the declaration might change. Example: Instead of having to say MOVE.B, MOVE.W, or MOVE.L all the time, you'd just tell the assembler "Register D0 is supposed to hold a byte." From then on, all references to D0 would be .B, until you tell it something different. Even nicer might be to assign variable names to the registers. Sort of like the register option of C, but you'd have to do it manually instead of letting the compiler do it automatically. One thing I have to be careful about here: If you go overboard with this thing, the assembler turns out to be MUCH harder to build than a compiler. You have all the complexity of a compiler, plus: (1) You have to support EVERY machine language instruction, where the compiler can use only a subset (2) There are many more restrictions and special cases imposed by the hardware, where the compiler can use a syntax that's more general. I want to have a nice tool, but I'd rather not make it my life's work! Jack There are 2 Replies. #: 8966 S12/OS9/68000 (OSK) 31-Dec-90 02:44:34 Sb: #8965-#68000 ASM Language Fm: Kevin Darling (UG Pres) 76703,4227 To: Jack Crenshaw 72325,1327 (X) Jack - been meaning to jump in here, but haven't had the time yet! But yes, being able to assign a name to a register in sections of the source would be nice.... a friend and I were just talking about wanting this the other day. We had a routine using a bunch of the 68K registers, and even with comments, it got tough to follow which reg was which (and woe if you change some! ;-). kev There is 1 Reply. #: 8975 S12/OS9/68000 (OSK) 31-Dec-90 20:44:50 Sb: #8966-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Kevin Darling (UG Pres) 76703,4227 (X) Kev, I remember a project at work on the Z8000, which has 16 general-purpose registers. The program had to be super fast ... among other things, it had to compute one sine, one cosine, an arctan, and a square root, in a millisecond. So I had to write almost all in-line code, and keep everything possible in registers. What an ordeal! Basically, I was doing global register optimization by hand. Had to keep a map of what was in each register, and deciding where to put the next item was like working out a chinese puzzle. It sure would have been nice for me to have been able to identify the registers by their contents, too. Which brings me to a thought: You'd need error messages to tell you when something's been overlaid, wouldn't you? Well, I guess that would be taken care of by the assembler: If you declare a variable x to be in D0, and then later declare it to be y, the assembler must remove x from the symbol table. Unless, of course, you redeclare it as RAM. Hm. Have to think about implementation on that one. I'd been thinking of a syntax something like assign x to d0 . . release d0 Perhaps I could set it up so that if there is an assignment x=d0 somewhere in between, x would be automatically set to refer to the RAM variable rather than the register. Sounds feasible. Jack There is 1 Reply. #: 8980 S12/OS9/68000 (OSK) 01-Jan-91 01:13:22 Sb: #8975-68000 ASM Language Fm: Kevin Darling (UG Pres) 76703,4227 To: Jack Crenshaw 72325,1327 (X) Hmmm. Interesting thoughts. I wasn't thinking that fancy (yet - grin). Just mainly wanted to be able to say: alias x d0 or similar, and so within that file section be able to say "move #3,x" and .... hmmm... another method might be: org d0 x reg 1 y reg 1 To reserve regs d0,d1 ... but this is too weird. Never mind ;-). Hafta think about it some first. #: 8968 S12/OS9/68000 (OSK) 31-Dec-90 10:14:16 Sb: #8965-#68000 ASM Language Fm: William Phelps 75100,265 To: Jack Crenshaw 72325,1327 (X) Re:MOVE I don't think there is much that can be assumed without making some programs difficult or impossible to write. The only place where it would be "safe" to assume size would be when a variable of a specific size is accessed. It would also be nice to be able to give the registers names; even a, b, c, is better than 0, 1, 2. On another note, I assume that you are writing a two-pass assembler, but are you making it a macro assembler? If so, then are you going to put the code in-line or in subroutines? William There is 1 Reply. #: 8976 S12/OS9/68000 (OSK) 31-Dec-90 20:44:55 Sb: #8968-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: William Phelps 75100,265 (X) William, whether it's one- or two-pass is an implementation issue. Shouldn't affect the appearance to the user either way. Actually, I'll probably use a one-pass with backpatching, but the first iteration may be two-pass. Yes, might as well support macros. As long as I'm doing it, best to do it right. Macros are _ALWAYS_ supported as in-line code, by definition. Jack There is 1 Reply. #: 8997 S12/OS9/68000 (OSK) 01-Jan-91 23:59:08 Sb: #8976-#68000 ASM Language Fm: William Phelps 75100,265 To: Jack Crenshaw 72325,1327 (X) Re:two-pass Actually the user would see it if the assembler has an "ifp1" type directive, but I suppose you will just fake that on INCLUDEs. I would also think that resolving variables would be more difficult if you want a separate data area. Re:macros Macros have always been supported as in-line code in normal assemblers. It is possible for TIL assemblers to put an equivalent subroutine call in-line. William There is 1 Reply. #: 9001 S12/OS9/68000 (OSK) 02-Jan-91 18:44:52 Sb: #8997-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: William Phelps 75100,265 (X) Well, I sure can't disagree, William, since I have no idea what an ifp1 or a TIL is. Jack There is 1 Reply. #: 9009 S12/OS9/68000 (OSK) 03-Jan-91 23:01:00 Sb: #9001-#68000 ASM Language Fm: William Phelps 75100,265 To: Jack Crenshaw 72325,1327 (X) ifp1 - if pass one TIL - Threaded Interpretive Language William There is 1 Reply. #: 9024 S12/OS9/68000 (OSK) 05-Jan-91 06:49:24 Sb: #9009-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: William Phelps 75100,265 (X) Ok on the defs, William. I understand the definition of the ifp1 keyword, but can imagine no earthly reason why one would want to use it. I' having a hard time imagining how a program, written in any programming language, could be or should be tangled up with the way the translator was implemented. Do you find it useful? Re TIL: Again, I understand. I used to be something of a fan of FORTH, so I can dig the concept. The idea of putting subroutines in line, though, doesn't fit very well with the idea of an assembler. In the latter, the whole point would seem to be to do the absolute minimum kinds of transformations to the language. It's just a one-for-one translation from mnemonics to machine codes. Jack There is 1 Reply. #: 9028 S12/OS9/68000 (OSK) 05-Jan-91 12:27:57 Sb: #9024-#68000 ASM Language Fm: Bud Hamblen 72466,256 To: Jack Crenshaw 72325,1327 (X) Jack, The best use of "ifp1" is when you have big include files that define labels (like skequate.lib) but don't generate code. Makes assembly a tad faster. ifp1 lib skequate endif That's about it. You should have your assembler accept Motorola's defined syntax without any changes, no matter what else it does to extend the assembler language. If you ever saw Grappel's and Hemenway's STRUBAL+ for the 6800 (yep, two naughts), you'd see what I was thinking about. The compiler recognized both 6800 assembler and a structured basic language. It was a one-pass basic compiler and a two-pass assembler that emitted a relocatble object file that you could link with other modules. The implementation was a dog, but the idea was a good one. Bud There is 1 Reply. #: 9033 S12/OS9/68000 (OSK) 05-Jan-91 19:23:47 Sb: #9028-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Bud Hamblen 72466,256 (X) Bud, in STRUBAL could you mix assembler language with BASIC? Jack There is 1 Reply. #: 9042 S12/OS9/68000 (OSK) 06-Jan-91 10:58:14 Sb: #9033-#68000 ASM Language Fm: Bud Hamblen 72466,256 To: Jack Crenshaw 72325,1327 (X) Jack, Here's an example copied from the Strubal manual: * INTEGER I(10),J(10),IADD,JADD * * MOVE CONTENTS OF J INTO I * USING CRUTCH CODING FOR SPEED * GETAD IADD=I GETAD JADD=J FOR K=IADD,IAAD+20 * LDX JADD POINT TO J LDA A 0,X GET BYTE FROM J INX STX JADD INCREMENT JADD LDX K POINT TO I STA A 0,X STORE BYTE IN I * NEXT K The syntax is clunky, but the idea of combining a higher level syntax with normal assembler syntax is interesting. Bud There is 1 Reply. #: 9049 S12/OS9/68000 (OSK) 06-Jan-91 21:11:50 Sb: #9042-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Bud Hamblen 72466,256 (X) I like it, Bud ... not the syntax, but the idea. The reason I asked was that I was prepared to say that I'd rather have a separate compiler and assembler. But if you can mix the two languages in one program, so much the better. I started down this road by writing a preprocessor for 68000 assembler language. I did this mainly because I found the 68K control constructs, branches, etc., too confusing. Every time I use DBcc, I have to think about it and hand-execute it, and I _STILL_ tend to get it backwards. So I decided to add Pascal-like control constructs. I had IF-ELSE-ENDIF WHILE-ENDWHILE LOOP-ENDLOOP DO-ENDDO (uses DBcc) BREAK For the conditions, I replaced the 68000 CC's by things like =, !=, <= ,etc. Carry clear was !cy, etc. It worked out really nicely, and turned out to be easy to write. Natch, all control constructs were nestable to any depth. Any other instructions besides the control constructs just pass right through to the assembler. I could play around with something like this. I've toyed with the idea of extending the HOL-like constructs. By that I mean that, if a MOVE X(PC),D0 gets translated as d0=x, then it's a small matter to let more complex expressions like x = y + z/2 be generated, too. [More] There is 1 Reply. #: 9050 S12/OS9/68000 (OSK) 06-Jan-91 21:12:09 Sb: #9049-#68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] I have mixed emotions about this, though. For one thing, if the idea of an assembler is to produce a 1-to-1 correspondence between source code and object code, this is violated if you allow expressions. Not only that, but it might not be immediately obvious that multiple instructions are going to be generated. And it would take someone who _REALLY_ knows assembler language to know when one instruction will be generated, and when it can't be. It seems that if the "compiler" is going to expand the code and produce what is surely likely to be more inefficient code than the programmer can do, you should at least give him some warning message that you've done the expansion. Too, once you get into general assignment statements, you have to use some intermediate storage .. either register, stack, or memory. And this might walk over the programmer's plans for register assignments. Finally, it's HARD! It turns out to be a lot more difficult to write a HOL-like assembler than a HOL compiler, itself. The reason in that the compiler writer can make his own decisions as to register assignments, parameter-passing conventions, etc., and enforce them autocratically. With a "pseudo-assembler," you have to honor the programmer's choices. Also, the compiler author is allowed to use a subset of the CPU instruction set, while the assembler writer must support them all. [More] There is 1 Reply. #: 9051 S12/OS9/68000 (OSK) 06-Jan-91 21:12:31 Sb: #9050-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Jack Crenshaw 72325,1327 (X) [Continued] All of this touches on some very deep issues of philosophy, about which I have some rather firm convictions (surprise!) First of all, I like to program in assembly language. Despite the general feeling that it's a MUCH more difficult medium to program in, I find that it's not that much harder than a HOL, _IF_ you have good tools (including macro facilities), a well-equipped subroutine library, and some well-defined conventions for things like parameter passing. With my preprocessor, you get a lot of the advantages of a HOL with no loss in efficiency. On the other hand, I've also become convinced, by personal experience, that writing a full-blown compiler is also very easy, _IF_ you don't care much about the quality of the code output. The trick is to combine both ideas into one program. The ideal language would be one in which you could write either way: Quick and dirty programs in a BASIC-like language, and to heck with tight code, or carefully tailored code approaching or equalling the efficiency of assembler, for those cases where it's needed. But writing a single language capable of doing this would seem to be a big challenge. Certainly it's one that people like Kernighan or Wirth haven't tried to tackle. Rather than trying to bite that huge bullet in one swallow, I'd prefer to start with something more modest and sneak up on the rest. Jack #: 8926 S12/OS9/68000 (OSK) 28-Dec-90 10:27:07 Sb: #8918-#68000 ASM Language Fm: Ed Gresick 76576,3312 To: Jack Crenshaw 72325,1327 (X) Hi Jack! First, you have my vote for a new assembler. A little background - I probably spend about half of my time programming or reviewing/testing programs written by others. Most of this is with data-base languages. Occassionally, I have to get into C and/or Assembler. While I don't employ full-time programmers, I do employ several part-time programmers as I need them. When they work in assembler or C, they all use 'tools' of various sorts to 'improve' their efficiency. (I'm not convinced that's necessarily true.) When I have work done in C, I insist that the code pass a 'lint' test. These programmers rely on volumes of libraries of sub-routines and macros they(?) have previously written. I doubt I get the most efficient code possible this way but the way these people have been trained and simple economics require that I accept the code (so long as it works and meets the requirements I had specified). I remember one bit of assembler code that gave me a real fit. Most of the time (three or four months), the program worked fine. Occassionally, it reacted in a weird fashion. Took me a long time to find the error - the programmer had tested the wrong condition code (which really wasn't a test at all in this case). The code fragment was - . (What it might look like under . your proposed assembler) . lea table(pc),a6 a6=table move.b (a6,d5.w),d7 d7=a6+offset or d7=a6+d5 bne there 'if n bit set' goto there . No, the first line above is wrong. . that would put the contents in d7 we want the address so - why not 'a6=adr(table)' There are 2 Replies. #: 8927 S12/OS9/68000 (OSK) 28-Dec-90 10:28:06 Sb: #8926-#68000 ASM Language Fm: Ed Gresick 76576,3312 To: Ed Gresick 76576,3312 (X) The offending code was the 'bne' - it should have been 'bmi' - he wanted to test the 'n' flag. Try to find it in about 12,000 lines of poorly commented code. So, is there a way for the assembler to pick the correct test? Please stay away from C-like constructs - they can get messy and are not always clear. There is no reason to stay with traditional mnemonics per se. Yes, in some cases what was selected may turn out to be the best but, more often than not, it' not the best today. One question, who is your intended user? If you're targeting the experienced C/assembler programmer, I suspect you'll get a lot of resistance. On the other hand, the new or casual user (really one and the same) will appreciate an assembler that is easy to use and does not require all kinds of 'tools' to increase programmers' productivity. And I fall into this category. Can the assembler use ordinary English words? In order to ease the requirements of the parser, a preprocessor might be used to tokenize these words and if the tokens are sensible, users will probably learn them. Another task the assembler should do is select whether the branch or jump is a long or short. Get tired of putting '.s's in only to get back error messages telling me I can't do that - especially if its because I added some code. There are 2 Replies. #: 8928 S12/OS9/68000 (OSK) 28-Dec-90 10:28:51 Sb: #8927-#68000 ASM Language Fm: Ed Gresick 76576,3312 To: Ed Gresick 76576,3312 (X) Something I've sometimes wanted, was the number of clock cycles necessary to execute a given instruction and a total for the program (or maybe for sub-routines). Sure, it can be looked up but what a job. Can that be added as an option? Another area I suspect may be hairy for you is handling the various addressing modes - especially if we want the assembler to select the proper mode for us. While we don't want a slow assembler, absolute speed isn't as important as ease of use and understanding. Code that is easy to understand will result in writing code with fewer errors requiring fewer assembly attempts. So, even if we want more from the assembler, if its easier to use, the total time should be less. And I assume a linker will be included so we can write short routines. Well, I've gotten pretty windy - only a good assembler should be this verbose! Ed Gresick - DELMAR CO There is 1 Reply. #: 8942 S12/OS9/68000 (OSK) 29-Dec-90 20:07:31 Sb: #8928-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Ed Gresick 76576,3312 (X) Ed, the main reason for wanting to do an assembler is to get relocatable code ... the current SK*DOS assembler only does absolute. It's ASM from Bud Pass. So the linker is a definite must. Right after the PT-68 came out, Sidney Thompson recruited me to build a linker. He and Bud Pass were developing a C compiler, but with no linker it makes building modular software pretty difficult! I did build the linker, but we had a chicken-and-egg problem: A great linker is not much good if the assembler and compiler can't generate the object modules for it! Really, the linker and assembler have to be built as parts of a system. So I had to begin with a linker format that ASM was capable of generating, i.e. I was limited to what I could inject into the object file via DC statements. The linker's been done for about two years now, but Sidney and Bud don't like it (not elegant enough for Bud, though he declined to offer any suggestions as to improvement). Neither has shown any interest in incorporating it into the assembler or compiler,and Bud's support of SK*DOS seems to have dropped off to zero. So I figure if we're ever going to get a good relocatable assembler/linker/compiler system ... in other words, adequate development tools, I'm going to end up writing them. Which brings us back full circle. In a few attempts at prototyping the assembler, I realized I was spending a lot of energy to handle a syntax that is fundamentally flawed. It seemed to me that, as long as I'm gonna do this, might as well make a few improvements along the way. Jack #: 8941 S12/OS9/68000 (OSK) 29-Dec-90 20:07:19 Sb: #8927-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Ed Gresick 76576,3312 (X) I agree with you on both counts, i.e. (1) There's no need to try to make the assembler "look like" C. In fact, it could make things worse, since the programmer might then want to write other C constructs that aren't supported. That was a problem with Ed Ream's approach. (2) The programmer shouldn't have to decide whether to use long or short branches, or short data forms (MOVEQ). Who in their right mind would want to use a three-word immediate when you could do it in one? The assembler should take care of that kind of thing. (3) {OK, I lied about the "both"} I need to define the audience. Experienced assembly programmers aren't going to want to learn a new language. I guess the main user I'm interested in is me. Anyone else who wants to tag along is welcome. Jack #: 8940 S12/OS9/68000 (OSK) 29-Dec-90 20:07:13 Sb: #8926-68000 ASM Language Fm: Jack Crenshaw 72325,1327 To: Ed Gresick 76576,3312 (X) Ed, in my preprocessor, the operative branch would have been if != there or if !0 there (both statements mean the same thing) The problem in your program was that the comment is N.G. Instead of saying "if n bit set," the programmer should have said what he really expected to happen, i.e. "If table entry is negative..." This would have alerted you much quicker to the problem, I'll wager. In that case, my syntax would have been if <0 there which is kinda hard to misinterpret! Jack #: 8929 S10/OS9/6809 (CoCo) 28-Dec-90 12:45:34 Sb: #bonk etc. Fm: Joseph Cheek 76264,142 To: all Now that you all have had a while to look at it, does anyone have any comments for my bonk.pak upload? while i'm at it, does anyone have a good random-number generator in C? I wrote one, but it's SLOW. anyone? anyone? thanks . . . There is 1 Reply. #: 9000 S10/OS9/6809 (CoCo) 02-Jan-91 18:27:42 Sb: #8929-bonk etc. Fm: Kevin Darling (UG Pres) 76703,4227 To: Joseph Cheek 76264,142 Question - what is the View command that's needed? Is it available here? thx! - kev #: 8932 S1/General Interest 28-Dec-90 19:45:02 Sb: #New OS9/68K Computer? Fm: NAM PUI 73347,3324 To: all Hi Everyone: Just have a chance to glance through the Jan 1991 Rainbow. I noticed a few interesting ads. What is this OS9/68000k PT68K4 single board computer that is being marketed by Peripheral Technology and Delmar Co. If they are what I think they are, then the new COCO 4 market (MM/1 and TC70 ) just got a lot more interesting then I expected. Not to mention the other 68030 system based on the AT bus plus a 32 bit bus(This one I heard through the grapevine). Anyone got any info on the 68000 system? Nam P.S. The ad on page 77 of the same magazine by NMSA about a CAT. It is very interesting. But What do they sale for $399.95? There is 1 Reply. #: 8934 S1/General Interest 29-Dec-90 03:54:36 Sb: #8932-New OS9/68K Computer? Fm: Ed Gresick 76576,3312 To: NAM PUI 73347,3324 (X) Look in library 15 Hot Topics and pull down sys/binary. You will find a complete description of the SYSTEM IV. We are planning a 68030 machine with an AT bus and 32 bit expansion adapter. This is still in the design stage - it will be quite a while before it will be available for sale. If you want further info re the SYSTEM IV, please call me. Ed Gresick - DELMAR CO #: 8933 S12/OS9/68000 (OSK) 28-Dec-90 21:18:36 Sb: #High Density drives Fm: Frank Hogg of FHL 70310,317 To: all I recall that there was a thread about sectors per track etc on the high density drives. Did anyone ever come up with a concensus(sp?) on that. I have only been able to get 29 sectors per track so far. We havn't played around with inter sector gaps yet tho. Frank There is 1 Reply. #: 8935 S12/OS9/68000 (OSK) 29-Dec-90 04:03:53 Sb: #8933-High Density drives Fm: Ed Gresick 76576,3312 To: Frank Hogg of FHL 70310,317 (X) Frank: We're using 34 sectors per track for 3 1/2" drives and 28 sectors per track for 5 1/4" drives (high density - of course). Ed Gresick - DELMAR CO #: 8936 S10/OS9/6809 (CoCo) 29-Dec-90 11:25:46 Sb: #Format Fm: REX GOODE 73777,3663 To: All What are the differences, if any, between an OS9 FORMAT and DECB's DSKINI0? Rex There is 1 Reply. #: 8944 S10/OS9/6809 (CoCo) 29-Dec-90 20:09:34 Sb: #8936-#Format Fm: Kevin Darling (UG Pres) 76703,4227 To: REX GOODE 73777,3663 (X) Rex - if there are any differences, they can't be much. A lot of us will format under one OS, and then write the needed info to make the disk work under the other OS. The biggest diff might be related to writing... L-II/coco no longer uses precompensation because they say that it's not needed with modern equipment and disks. Doesn't seem to matter much tho. There is 1 Reply. #: 9004 S10/OS9/6809 (CoCo) 03-Jan-91 12:12:15 Sb: #8944-Format Fm: REX GOODE 73777,3663 To: Kevin Darling (UG Pres) 76703,4227 (X) Kevin, Thanks for the tip. Suddenly I have been getting errors when formatting with OS9, yet formatting the same disk under DECB seemed OK. I'll try using the DECB disks. Rex #: 8937 S10/OS9/6809 (CoCo) 29-Dec-90 14:54:47 Sb: Osterm Fm: NEAL STEWARD 72716,1416 To: ALL Can anyone tell me how the ASCII upload works with OSTerm v.2.0.8? I input a prompt (that is sent by a local BBS) and the program just idles without attempting to send a file. #: 8945 S7/Telecommunications 30-Dec-90 06:00:24 Sb: #ACPDS7.DOC help needed Fm: PaulSeniura 76476,464 To: all Hi - I don't get on here much at all nowadays cuz it CO$T$ too much! But I can't get any decent help on Delphi after waiting for almost a whole month for someone to reply to our requests for help with our AciaPDS driver. I'm already way behind in letting people use our driver because it's not complete. If you can spare some time to read the ACPDS7.DOC file in the TelComm area (database #7 I believe here) which is the very same file I shared on Delphi by the name of ACIAPDS7.DOC, in it will be some details on the missing Status calls we need some help on. Tandy already supports these calls and we're wanting to make our driver 100% complete - we'd also like to incorporate even more support that Tandy didn't include and we've pointed out these calls, too, that *are* in the OS9DEFS file but none of the books on the market (even KD's "Inside OS9") describes these things. If you can help and can access Delphi, please send your replies over yonder instead of CI$$$$ here. I was hoping to make this driver available as a Christmas present, but as I said, it's been a month already on Delphi and only one person (who is a local acquaintance) mentioned it's too technical for him! Please help us ASAP so I can turn this critter loose and let everyone start using it, please, especially the RiBBS people who've been calling my beta test site night & day for it! (the docs are copyrighted & shared only for personal use right now, so that no one will misquote our text and use it in unscrupulous ways) -- Thx, Paul Seniura (76476,464 - PAULSENIURA on Delphi) There is 1 Reply. #: 8954 S7/Telecommunications 30-Dec-90 11:34:20 Sb: #8945-ACPDS7.DOC help needed Fm: Steve Wegert 76703,4255 To: PaulSeniura 76476,464 Paul, Nice to see you back where the action seems to be. Have you checked out FAST.DOC in LIB 1 here? It goes a long way on saving connect charges. Steve #: 8946 S1/General Interest 30-Dec-90 06:25:57 Sb: #CDROM - are we? Fm: PaulSeniura 76476,464 To: all Need to ask y'all about about CD drives. It's the June 1986 Rainbow on page 218 written by Dale Puckett -- before the CoCo3 & Level 2 and even before I got my Level 1 2.0.0 copy! And I can't believe I've kept these old copies! :-) Most of the OS-9 articles are *still* quite relevant, btw. Page 218 contains one paragraph with its own subtitle, which I'll quote here in its entireity for those who don't have this issue, if I may: -*- "Our Future {boldface} "The 68K version of OS-9 may very soon be the standard operating system on most home-oriented computer systems. At a recent conference sponsored by Microsoft, Sony and Phillips proposed a new file format standard for the new compact disc technology. OS-9 68K is at the heart of the standard that supports sound and graphics as well as data on the new disks. The CD-I system uses a Motorola 68000 processor and custom graphics and sound processors still under development by Sony and Phillips. The systems may be sold as complete systems or as add-ons to existing audio CD players." -*- That's the entire article in the June 1986 Rainbow. In 1988, we read that Sony & Phillips will be putting OSK in ROM "in" the CD drives, such that the host computers won't need anything special. Last year we started seeing all this stuff come out, BUT FOR THE IBMPC COMPATIBLES. There are a few books I found at B.Dalton's written in/around these years that will have you believe the CD-ROM standards will follow the CD-I pretty much, in order for everything to remain compatible. Yes one appendix did mention multiple-level directories, file ownerships(!), executable files(!!) and the "E" flag in the directory(!!!), etc.!!!! Get my point? But *still* not a single mention about OS-9 or Microware or "whomever". EXCEPT for the H.W.Sams book on CD-I technology: they mention OS-9 and Microware a-plenty, plus this Sams edition is published in the same year as the Rainbow article I just quoted! It's getting on to be 5 years OLD NEWS now. [more] There is 1 Reply. #: 8971 S1/General Interest 31-Dec-90 12:31:00 Sb: #8946-CDROM - are we? Fm: Ed Gresick 76576,3312 To: PaulSeniura 76476,464 Paul, I think where many people get confused is that since CD-I uses OSK (OS9), the interface to any machine running OSK is easy. Not so. As you pointed out, the application software to access the data on the disk is independent of the OS and is in fact, written to operate on the host machine. So far as I know, these are the IBMs and the MACs. Whether we like it or not, the fact is the OSK market is a miniscule market (almost non-existant in the home). The major software houses, including the providers of CD-ROMS, do not feel it is worth their while to convert their software to run under OSK. They require a much bigger market than currently exists or anyone has been able to convince them might exist. DELMAR CO is looking at various ways the SYSTEM IV might read and execute these application programs. At this time, we are not prepared to claim this capability. Further is the question as to which system will prevail - Philips/Signetics or Intel (Sony is playing in both camps). Assuming we can solve the application software problem, the SYSTEM IV is ideally positioned to handle either system. Ed Gresick - DELMAR CO #: 8947 S1/General Interest 30-Dec-90 06:27:48 Sb: #CDROM - are we? Fm: PaulSeniura 76476,464 To: all [continued] Microsoft has their "DOS extensions" to handle 'em. If you presently want to write programs to read the CDs, you must buy a $395.00 C-language component package (libraries & stuff) to the regular PC compilers (yep you can order these thru Tandy Express if'n ya want). MSDOS will let you treat the CD drive "as a drive" -- i.e. commands like "DIR D:" will work! -- and so will these programming packages. So ... the bottom line ... what is going on here? How are FHL, KLE/IMS, Delmar, Mustang, Disto, etc., going to support CDs? We already know these things use a SCSI interface, but that's not saying anything. I invite representatives from every OS-9 company & elsewhere to answer this question, please -- inquiring minds want to know! And I gotta tell 'em! -- Thx, Paul Seniura. (P.s. Intel is unveiling their DVI chips -- Digital Video Interface. It figures that the big-blue companies "gotta" do things their own way, eh? By the looks of all these el-cheapo CD drive sales coming up all of a sudden, maybe the world is going to do things Intel's ways, and all those companies are cleaning out their warehouses to make room for the real future. ... (DVI will show real-time video anywhere on any-size window area on the current screen. It's the kind of thing that the IBM MicroChannel [tm] is expressly designed for [that's a full 32-bit data & address buss path, among other things like the capability for a mainframe channel attachment, for those who don't know]. ... (Here we are with the TomCat and MM/1 etc., about 4 years behind technology IF/WHEN THEY *DO* become available and IF they DO support any of these CDs correctly. I might have to wait for one of those proverbial "cold days" before I buy *any* OS-9 upgrade. Get the point? (So I'm offering to help prototype new circuit designs for you companies out there -- I'm currently in the process of ordering tons of IC books from different manufacturers -- and I'm dead serious about making these items available for the home/office OS-9 user. I wouldn't be asking for these kinds of details if I wasn't serious & didn't car@w There is 1 Reply. #: 8963 S1/General Interest 30-Dec-90 22:52:02 Sb: #8947-CDROM - are we? Fm: John Ranck 73540,246 To: PaulSeniura 76476,464 Good I was hoping someone would work on that. #: 8948 S1/General Interest 30-Dec-90 06:30:53 Sb: #CDROM - are we? Fm: PaulSeniura 76476,464 To: all We have a local CDROM expert by the name of Bob Hall who's written books on different subjects including CDROM and Microsoft will be publishing his new book on CDROM technical information. Everything I've read points to the fact that CD-I was "first" and CD-ROM was suppose to be compatible in its storage format. We've also seen at least a few Specific references to the fact that "the format" is OS9/68000 directories & modules etc. Since the big conference in 1986, we haven't seen any further specific information! Not even Bob Hall has seen anything as specifically mentioning OS9/68K as the official format. But I have seen and I've told him where we found it, and have relayed this in my earlier messages on Delphi here. (If this thread is lost, I mentioned that this info is not just in the Rainbow magazine, but also in Howard W. Sams books. If CD-I is in OS9/68K format, it follows in other books I found at B.Daltons that CD-ROM is suppose to be compatible.) What I'm after is NOT the SCSI specs ... I'm trying to ask the 3 major OSK companies how they intend to run CDROM encyclopedias etc. KLE's MM/1 brochures as well as FHL's Tomcat flyers have both mentioned being able to hook in & run CDROMs specifically (not/just/only CD-I) or will do so in the future. Delmar hasn't really dealt with this in their text files here but I'd still like to know if they intend on supporting CDROMs as well. I *know* the players use SCSI protocols ... I'm not concerned about SCSI ... I'm concerned about how to find/search/view the databases and graphics and animation and speech etc. If KLE and FHL are saying they can run CDROMs, by golly they better know what they're talking about or they're falsely advertising the capabilities of their machines! [more] There is 1 Reply. #: 8964 S1/General Interest 30-Dec-90 22:53:58 Sb: #8948-CDROM - are we? Fm: John Ranck 73540,246 To: PaulSeniura 76476,464 What about the CD-Worms. Is anybody prospecting them? #: 8949 S1/General Interest 30-Dec-90 06:32:14 Sb: #CDROM - are we? Fm: PaulSeniura 76476,464 To: all [continued] And I am here inviting them to answer these inquiries. It'll drastically affect which system I pick to buy. OSK Windows is top on my list of priorities, but CDROMs is a *very* close Second on my list. If you developers want OSK to be useful in the home and schools, and CDROMs are not *already* being supported, then OSK is *already* about 3 years behind the times. Just look at the opportunities to make money ... else I fear OSK can't keep up with the Joneses and it'll eventually wither away like the CoCo is doing right now. Hey, I'm talking about HOME and EDUCATION MARKETS, not industry or business. Just this day I was trying to put the puzzle together. It will probably require writing some OSK applications (end-user friendly) based on the MSDOS and Macintosh functions of any particular CDROM database. For example, Compton's Encyclopedia comes with MSDOS application programs (besides the device drivers etc.). The drivers do the low-level I/O etc. The application programs do the actual find/search/retrieval of the needed info. There should be a version of Compton's that runs on the Mac whose application programs are possibly a "port" from the MSDOS ones (this is just an example; it might be that Compton didn't make a Mac version). Same database record I/O format, just a port of the same C source code, say. Well, of course Compton won't develop an OSK version because there ain't no $money$ in it -- right? Point made: someone's going to need to get the database format from Compton and write the application code ... the SCSI drivers etc. will already be in place under OSK as a device driver. If the sector & directory format of the CDROMs are not in OSK format (i.e. away from all the literature I've been reading), there'll need to be another system module to translate the raw sector data into OSK-meaningful format. See what I'm getting at? Are KLE & FHL going to commit to this kind of support for CDROMs? If not, they had better stop advertising this or someone will be going to the Fed. Trade Commission! -- Thx for your time, Paul Seniura. There is 1 Reply. #: 8960 S1/General Interest 30-Dec-90 13:48:26 Sb: #8949-CDROM - are we? Fm: Kevin Darling (UG Pres) 76703,4227 To: PaulSeniura 76476,464 Paul - I agree that there's a great deal of confusion (in the entire computer marketplace) about CDROMs. First. The CD-I players are (finally!) due out this summer... the Japanese have been showing units by many makers (a Sony portable is shown on Popular Science Jan 1991 page 41). Hard to judge yet, but with luck these players will become as common as VCRs are now. It's thought that perhaps 20% will be expanded by owners out into OSK personals. You are correct in reading that the directory structures on most CDROMs are of a standard (which is not the same OS9 dir format you use now. that's what different File Managers are for). But the data files have no standard. Each CDROM comes with its own program (you usually put it on your HD) for reading that particular disc. Mac users often complain about not having access to discs available for IBM machines, and vice-versa. So yes, we're in the same boat as Amiga, ST, Unix, and many other users (including Mac/IBM at times)... each CDROM app must be ported to the specific machine. Or, new apps/discs must be created (feasible, tho time-consuming). One of our "aces" in the hole is because of CD-I... the people creating those discs are already familiar with OSK. I hear that IMS is actively pursuing this avenue, for instance. So the possibilities are there. I don't think I've seen any KMA maker advertising that you can currently use Mac/IBM CDROM discs, tho. If you feel a need to complain to the FTC, start with the ads all around you for Mac/PC cdrom where they assume everyone has the correct machine ;-). The best way to help our community out is to become a good C/gfx programmer, and be available to help port Mac/PC cdrom apps should the opportunity arise. Happy New Year! - kev #: 8950 S12/OS9/68000 (OSK) 30-Dec-90 09:08:22 Sb: OS9/ST on Atari TT Fm: DENIS CHARTRAND 72561,2714 To: 70126,267 If we look inside the Atari TT, we can see that the MFP68901 are not in 40 pins DIP package anymore, they are in a grid-array type, like the 68030 and others chips. I don't know if it's a new version of 68901. BYE #: 8951 S10/OS9/6809 (CoCo) 30-Dec-90 09:34:01 Sb: patches Fm: Hugo Bueno 71211,3662 To: All I missed the Rainbow article by Bruce Isted concerning clock patches and such. Would anyone care to give me a synopsis of article? Hugo #: 8952 S14/misc/info/Soapbox 30-Dec-90 09:34:42 Sb: #512 upgrade Fm: MICHAEL ROSEN 73340,2756 To: Kevin Darling Kevin, I was wonderin if you could give me some info. on installing a Tandy 512k. board in a coco 3... I have a populated 512k. board but don't know what to pull out or clip.. Can you or some of the others give me some assistance in fixing my computer.. I know I have to pull the 4 memory chips that are in right now and I know where the board plugs in but thats about it.. All help appreciated.. Michael Rosen 73340,2756 There are 2 Replies. #: 8958 S14/misc/info/Soapbox 30-Dec-90 12:18:18 Sb: #8952-512 upgrade Fm: Kevin Darling (UG Pres) 76703,4227 To: MICHAEL ROSEN 73340,2756 (X) I believe (can't tell without pulling things apart :-) that you clip capacitors C65 and C66 (back/front inside the ram area). Will someone else please confirm this for us? Can't seem to find my old instructions. Then pull out the old chips, and plug in the 512K board... usually you press it carefully in, then pull out just slightly as you don't want the pins to touch the board (the sockets have no bottom and things won't work if the upgrade board pins touch the coco board). On the cap-cutting, btw, I usually clip just one side... so I have a chance of resoldering easier if/when I have to . I know C66 is one of the two. Just need confirmation on the other. Guys??? #: 8969 S14/misc/info/Soapbox 31-Dec-90 10:14:37 Sb: #8952-512 upgrade Fm: William Phelps 75100,265 To: MICHAEL ROSEN 73340,2756 (X) According to Tandy, you should only remove C65. According to everyone else, you should remove C65 & C66; if you have a heat problem then you should use the resistor mod. William #: 8953 S10/OS9/6809 (CoCo) 30-Dec-90 09:41:21 Sb: #bonk etc. Fm: Hugo Bueno 71211,3662 To: 76264,142 (X) I like Bonk a lot. The only thing that takes getting used to is mouse movement. Also, I'm never sure how the ball will bounce off the ship. It seems random. I also noticed that the ball is surrounded by a square. Is there any way to XOR or whatever, to just have the ball without an outline? Hugo There is 1 Reply. #: 8972 S10/OS9/6809 (CoCo) 31-Dec-90 12:31:21 Sb: #8953-#bonk etc. Fm: Joseph Cheek 76264,142 To: Hugo Bueno 71211,3662 (X) the ball bounces at a 45 deg angle if it hit the ship on the edges, or at a 23 deg angle if it hit in the middle. also, 1/4 of the time if bounces back the same direction. re: ball with outline. I'll see what i can do. There is 1 Reply. #: 8993 S10/OS9/6809 (CoCo) 01-Jan-91 21:49:18 Sb: #8972-#bonk etc. Fm: Hugo Bueno 71211,3662 To: Joseph Cheek 76264,142 (X) As far as ball bouncing, it would be better to be able to put "english" on the ball. Also, I noticed when I quit the game, the VIEW utility is not unlinked from memory. You should probably make sure that all graphics buffers are also KILLed. Hugo There is 1 Reply. #: 8999 S10/OS9/6809 (CoCo) 02-Jan-91 16:13:27 Sb: #8993-#bonk etc. Fm: Joseph Cheek 76264,142 To: Hugo Bueno 71211,3662 (X) english? please repeat . . . There is 1 Reply. #: 9002 S10/OS9/6809 (CoCo) 02-Jan-91 18:47:45 Sb: #8999-bonk etc. Fm: Hugo Bueno 71211,3662 To: Joseph Cheek 76264,142 Well, "english" a term used in billiards, means putting a spin on the ball. In video games, it means if the racquet is travelling to the left when the ball is hit, then the ball will also tend to travel to the left. Many versions of BREAKOUT had this feature. Hugo #: 8967 S10/OS9/6809 (CoCo) 31-Dec-90 09:25:13 Sb: Wanted to buy Fm: Paul Rinear 73757,1413 To: All Am desperately seeking a copy of OS-9 Level One, used or otherwise; preferably with docs. Missed the tent sale at Radio Shack and now there are no copies to be found. If you have one for sale, please send E-mail to: Paul Rinear 73757,1413 #: 8970 S10/OS9/6809 (CoCo) 31-Dec-90 10:49:18 Sb: Osterm208 Fm: Chris Bergerson 72227,127 To: Neal Steward 72716,1416 Neal, I met Vaughn at a party a few weeks ago, and asked him about the osterm ASCII upload problem. I had tried many times to get it to work. Well, I won't bother trying anymore... he said that it never did work, and that he has no intentions of fixing it! There is a rumor that the source might be available for the upload sections of the program... I'm investigating, and if true, I will probably fix it. In the meantime, to accomplish the same goal, I'd recommend flipping to another window, and outputting your text file to /t2, using a simple utility to send a character, pause, send a character, etc. BTW, good to see you here! #: 8978 S1/General Interest 31-Dec-90 23:13:36 Sb: Happy New Year! Fm: Zack Sessions 76407,1524 To: ALL HAPPY NEW YEAR!!!! #: 8979 S15/Hot Topics 31-Dec-90 23:40:02 Sb: #Tomcat TC70 Ships! Fm: Frank Hogg of FHL 70310,317 To: All >>>>>>>>>>>>>>>> FINALLY! <<<<<<<<<<<<<<<< On December 31st 1990, Frank Hogg Laboratory shipped the first of many Tomcat TC70 Computers. Serial #2 went out the door with a 40 meg Quantum hard drive and a 3.5" Hi Density floppy drive. (I have Serial #1) Volume shipments of TC70's will begin in a week or so. Meanwhile the Tomcat TC9 progresses at a fast pace with deliveries hoped to begin in February 1991. HAPPY NEW YEAR TO ALL! Frank Hogg There are 3 Replies. #: 8981 S15/Hot Topics 01-Jan-91 01:15:22 Sb: #8979-Tomcat TC70 Ships! Fm: Kevin Darling (UG Pres) 76703,4227 To: Frank Hogg of FHL 70310,317 (X) Congratulations! And Happy New Year to all of us! I think it'll be a good one... #: 8983 S15/Hot Topics 01-Jan-91 04:04:55 Sb: #8979-Tomcat TC70 Ships! Fm: Ed Gresick 76576,3312 To: Frank Hogg of FHL 70310,317 (X) >>>>>>>>>>>>>>>>>> CONGRADULATIONS <<<<<<<<<<<<<<<<<< And a very Happy and Prosperous New Year to You and to ALL! Ed Gresick - DELMAR CO #: 8986 S15/Hot Topics 01-Jan-91 11:13:35 Sb: #8979-Tomcat TC70 Ships! Fm: Steve Wegert 76703,4255 To: Frank Hogg of FHL 70310,317 (X) Congratulations, Frank! Here's to a very successful year for FHL! Steve #: 8982 S10/OS9/6809 (CoCo) 01-Jan-91 02:54:50 Sb: #MultiVue Fm: NAM PUI 73347,3324 To: all I got MultiVue since it hit the market. However, after the novelty worn off after the first month, I never bother with it again. Since then I have added hard drives to all my COCO IIIs. I have been getting along fine without the use of MultiVue. Just days ago I was going through the drives to clean out the garbage in my data files. I thought it would be great to be able to use a point and click enviroment to view and delete the unwanted files. So out come Multivue again. I have been pulling my hair off since. Here is my system hardware set up. 512K COCO III with J&M JFD-CP floppy controller and Owlware hard drive interface/Omti 5200 controller on a Y-Cable. Seagate St225 and 3-720k floppy(2-5.25" and 1 3.5"). Software set up is as follow. Module Directory at 03:28:41 REL Boot OS9p1 OS9p2 Init RBF CC3Disk D0 D1 D2 CCOmti dd h0 IOMan SIO SCF CC3IO WindInt Term W W1 W2 W3 W4 W5 W6 W7 PRINTER P CPPRINT P1 Clock CC3Go GrfDrv Shell Cat Dir Display Del gotoxy ds MDir CC3Disk is the version patched for msdos ccomti.dr, dd, h0 are the Owlware driver and descriptors Term starts up in 80 column. P1, CCPRINT are for the parallel port on the J&M. All the /d0s in the autoex file is patched to /dds. Autoex renamed to Mv for manaul start up. Now, here is the problem. Everytime I move from the root directory to a sub directory on the hard drive, the window in mv just hangs in the hour mode(wait). It seem to have effect the time share as well. The other windows slowed down as well. The whole things work well in the floppys. Hope someone can help. Thanks in advance. Nam There are 2 Replies. #: 8984 S10/OS9/6809 (CoCo) 01-Jan-91 10:27:59 Sb: #8982-#MultiVue Fm: Zack Sessions 76407,1524 To: NAM PUI 73347,3324 (X) Try downloading the GShell+ patches and apply them. They fixed some bugs which could cause what you're seeing. There is 1 Reply. #: 9008 S10/OS9/6809 (CoCo) 03-Jan-91 21:37:32 Sb: #8984-MultiVue Fm: NAM PUI 73347,3324 To: Zack Sessions 76407,1524 (X) Thanks. I am heading for DL10 right now. Nam #: 8985 S10/OS9/6809 (CoCo) 01-Jan-91 11:02:36 Sb: #8982-#MultiVue Fm: Kevin Darling (UG Pres) 76703,4227 To: NAM PUI 73347,3324 (X) Hmm. I think this can happen if you have lots of files and some 3-letter extensions. At the least, apply the MVFIX.SCR patch to gshell (from Lib 10).. that should help. If you do a "bro /key:gshell" there you'll find more patches. Some people began to use it after the patches ;-). There is 1 Reply. #: 9007 S10/OS9/6809 (CoCo) 03-Jan-91 21:36:06 Sb: #8985-MultiVue Fm: NAM PUI 73347,3324 To: Kevin Darling (UG Pres) 76703,4227 (X) Thanks. I will give it a shot. Nam #: 8987 S12/OS9/68000 (OSK) 01-Jan-91 13:40:10 Sb: #MegaFile44 Fm: DENIS CHARTRAND 72561,2714 To: Kevin Darling Hi, Kevin. Yoy know if the MegaFile 44 hard disk for the Atari ST with removable cartridge can work with OS9/68000 for the Atari? Thanks There is 1 Reply. #: 8992 S12/OS9/68000 (OSK) 01-Jan-91 19:53:46 Sb: #8987-MegaFile44 Fm: Kevin Darling (UG Pres) 76703,4227 To: DENIS CHARTRAND 72561,2714 (X) Denis - no, I sure don't know. If it otherwise looks like a regular Atari SCSI hard disk, then I don't see why not, tho. Anyone here had experience with removeable media HD's?? #: 8988 S4/MIDI and Music 01-Jan-91 15:12:07 Sb: Ped Fm: Dennis Skala 73177,2365 To: 73577,256 (X) Larry, I downloaded your 'ped.ar' file. Looks like it might be interesting. But contrary to your comment in the docs, most can't even view the program because we don't have a midi driver available. The program errors out when it attempts to open a path to the midi port. I own a Yamaha PSR-48. I kinda thought that it was the "big brother" to the PSS-480. Nowhere in the manual can I find any reference to inputing patches. Do you know if this synth has that capability? ***** Dennis ***** #: 8989 S1/General Interest 01-Jan-91 15:35:57 Sb: BBclock2.ar upload Fm: Dennis Skala 73177,2365 To: Sysop (X) I inadvertently uploaded a file into the Midi section which should have gone into the Coco section. Please correct, and get rid of the extra lines in the description - when I went to correct this, my new input was appended to the old for some reason. Sorry for the confusion. #: 8991 S10/OS9/6809 (CoCo) 01-Jan-91 18:49:04 Sb: disto&hardrv Fm: KENHEIST 71750,551 To: 76703,4224 kevin I'm using a disto scii w/ 4n1 and just got a Seagate 157n. I keep getting a 247 error when I bootup with ddd0 and do a chx /h0/cmds it takes two or more tries to get it to catch and of course if I try to do a ddh0 I get bootfail every time. Whats up? Used the hmode to change the cyls and hds and inittbl. i.e. cyls=615 hds=6 inittbl=026706 installed h0_4in1scsi.dd and cchdisk_scsi.dr. Did I miss something? #: 8994 S4/MIDI and Music 01-Jan-91 22:54:48 Sb: PED response Fm: R. Larry Miner 73577,256 To: Dennis Skala Dennis - Thanks for the info about PED. WELL! I know it was 0200 in the morning (redundant) but that is no excuse for shoddy testing in my shop. I'll go check out the problem and fix it so we all can look over(the ideas in tjis program. As far as the question about the other Yamaha, I know nothing - as the colnel on Hogan's Heroe's would always say - or was the large economy(sized guard? Oh well, no I have had no experience with any other Yamaha. My gut feel is that if it has MIDI, it probably has some form of SYSEX capability, but no tellin' what the format of the bits are. See you around. I'll go check on this "feature" you told me about. -larry #: 8995 S4/MIDI and Music 01-Jan-91 23:49:30 Sb: #PED response Fm: R. Larry Miner 73577,256 To: Dennis skala 73177,2365 (X) Dennis - Sorry about any typos/whatever on these messages... I am new to this CIS editor... talk about computer shock! I checked on the problem you were experiencing and I have an idea. I did test the uploaded version of the PED and checked it out thoroughly. The idea I have is that I forgot to mention that PED (right now, anyway) is expecting to use the "Inkey" program that is supplied with BASIC09 and I know it put up about most of the first screen, attempts to loa in the inkey subroutine module and if it is not there, crashes. A thought there - I suffered many an hour myself, until I realized that inkey was being loaded outside the workspace, but INSIDE the "memory limitation" of BASIC09 - I mean, if I went to a window, and typed "basic09 #32k " basic09 would load fine, but Inkey could not squeak into the memory area 'cause I had it all earmarked. But if I used "basic09 #29k " there is ample room for inkey... S%e what I mean? As to the midi descriptor, even if I have none at all, or if my midi port was named "/madd", PED would "run", it just wouldn't do midi. BTW, it really only opens "/midi" when you are inside the editor and hit "P"lay. So if some typed in "ped" and the ped"module was in their execution directory and "RUNB" was there and "inkey" was there, everything would work great. I sure hope this will help get things goin' fer ya' - I have used it enough now to come up wit six suggestions for changes already. See you around - Larry exit There is 1 Reply. #: 9056 S4/MIDI and Music 07-Jan-91 18:17:21 Sb: #8995-PED response Fm: Dennis Skala 73177,2365 To: R. Larry Miner 73577,256 (X) OK, I got 'ped' going - dunno what was wrong the first time. Probably a matter of what was loaded into memory, etc. Anyway, looks interesting, but won't do *ME* specifically (or anyone with a different synth) any good without the source, and without a driver for the bit-banger for that matter. Even then, I'd need to find some docs about how to talk to the PSR-48. The standard manual isn't too clear on that point. ***** Dennis ***** #: 8996 S3/Languages 01-Jan-91 23:55:16 Sb: #'C' help Fm: Jim Peasley 72726,1153 To: all Can anybody point me to some example code that uses the "tm" structure on pg. 31 of the Kreider lib docs?? I'm trying to implement a date routine and it looks as thohgh the LOCALTIME function in utime.h is what I'm after. Thanks, ...Jim There is 1 Reply. #: 8998 S3/Languages 02-Jan-91 13:18:00 Sb: #8996-#'C' help Fm: Tom Napolitano 70215,1130 To: Jim Peasley 72726,1153 (X) Jim, Your timing is perfect. For a use of localtime(), check out swave.ar in library 6. I used it in all three programs therein. Also, be sure to grab the latest of Carl's library uploads (December 1990). He fixed the utime function; the old version caused my programs to be off by a month. (Missing a month sometimes causes people problems). (Sorry about that). tom n There is 1 Reply. #: 9010 S3/Languages 03-Jan-91 23:44:58 Sb: #8998-'C' help Fm: Jim Peasley 72726,1153 To: Tom Napolitano 70215,1130 (X) Ahhh... Thanks, Tom! That was just what I needed!! Guess I'll have to re-DL the CLIBs again -- my version is dated 8/88. ...Jim #: 9003 S10/OS9/6809 (CoCo) 02-Jan-91 23:56:38 Sb: CoCo 3 discontinued Fm: James Jones 76257,562 To: All Well...after seeing an earlier message posted here about the change in the status of the CoCo 3 (from "active" to "discontinued"), I went over to a local RS store and asked the fellow there to look it up. At that time (mid-December), his system claimed it was "active." Yesterday, I got back from spending the holidays with family, and found among the messages on the answering machine one from the same fellow, saying that the CoCo 3 had indeed changed status to "discontinued," and he had one left at the store--so I'd better come on over if I wanted it. So...perhaps this store got the information later than others, but I guess it's true. #: 9005 S1/General Interest 03-Jan-91 16:09:51 Sb: 2400 baud modem for sale Fm: Pete Lyall 76703,4230 To: All I have a surplus 2400 baud modem that I'd like to sell. It's a US Robotics Courier 2400 (external) modem. Does all the expected stuff, has built in help (AT$), and is hayes compatible. Comes with manual and power supply. I'd like $85 for it. Leave me a note in email if you're interested. Thanks... Pete Lyall #: 9006 S8/BBS Systems/TSMon 03-Jan-91 18:59:15 Sb: #ribbs 2.0 Fm: Everett Chimbidis 76370,1366 To: all I Need V2update.ar for Ribbs ver 2.0 !! If you have it will you please upload it?? Thanks! There is 1 Reply. #: 9012 S8/BBS Systems/TSMon 04-Jan-91 01:45:02 Sb: #9006-#ribbs 2.0 Fm: WAYNE LAIRD 73617,3042 To: Everett Chimbidis 76370,1366 (X) Everett, if you need such why not call the man Ron Bieher himself at his bbs number->(303) 343-6707 best, wayne There is 1 Reply. #: 9014 S8/BBS Systems/TSMon 04-Jan-91 08:52:35 Sb: #9012-#ribbs 2.0 Fm: Everett Chimbidis 76370,1366 To: WAYNE LAIRD 73617,3042 (X) I have allready tryed this and no luck!! His BBS will not let me download the whole file!! (1976 blocks & all i get is 881 blocks then lockup!!) Do you have V2update?? There is 1 Reply. #: 9021 S8/BBS Systems/TSMon 04-Jan-91 23:21:45 Sb: #9014-ribbs 2.0 Fm: WAYNE LAIRD 73617,3042 To: Everett Chimbidis 76370,1366 (X) Everett, you don't say what baud you were using, although I imagine it was at least 1200 or above, there is several sysops who run ribbs why don't you leave a message for him. asking for the nearest sysop that runs ribbs, there is a list of several. Another idea is that he has a ribbs echo that most of these sysops attach to, leave a note there if he doesn't respond, lastly I don't know what section of the country that you're calling from, but I know one sysop who goes crazy trying to get people into ribbs, try calling his board @ 1-619-224-4878 ocean beach bbs Wayne #: 9015 S7/Telecommunications 04-Jan-91 12:55:14 Sb: #uucp Fm: Tom Napolitano 70215,1130 To: 76257,562 (X) Jim, I see mentioned on the coco echo that some folks are saying Mark's uucp does not communicate properly with 386 machines? What are the details? Who's 386 Unix port and which programs don't work? I found this surprising, since my coco3 at home exchanges mail quite nicely, thankyou, with the compaq 386 running Interactive's 386/ix at work. Could you elaborate please? tom n There are 2 Replies. #: 9016 S7/Telecommunications 04-Jan-91 17:33:58 Sb: #9015-#uucp Fm: James Jones 76257,562 To: Tom Napolitano 70215,1130 (X) The message I saw about this was, I think, on FIDO, and it mentioned problems using Mark's UUCP to talk to a 386 and a VAX. My guess--and it's only a guess, of course--is, considering that VAXen and 386s both have the bizarro leastsignificant-byte-first byte ordering, that there's some part of the protocol that contains byte-ordering-dependent values that aren't getting byte-swapped before use. I haven't looked in the (very large!) uucp.ar to see whether there is any indication of that's being the problem, though. There are 2 Replies. #: 9017 S7/Telecommunications 04-Jan-91 18:46:10 Sb: #9016-uucp Fm: Pete Lyall 76703,4230 To: James Jones 76257,562 (X) JJ - It's been a while, but VAX and Intel BOTH have different byte ordering schemes from a 68K box. I seem to remember: 68K - 1234 (MSB to LSB) VAX - 4321 (LSB to MSB) Intel 2143 .. Not sure on this last one. Pete #: 9054 S7/Telecommunications 07-Jan-91 08:09:30 Sb: #9016-uucp Fm: Tom Napolitano 70215,1130 To: James Jones 76257,562 (X) Empirically, that would be my view too. Byte ordering has bitten me when porting between os9 and the intel world. I have Mark's sources, but have not read them all. I do not have the Unix source for uucp. Like I said, I haven't the problem, so had no need to go looking for one. I was just surprised when another claimed to have one. Perhaps the error is on the 386 port, and not the os9 port of uucp. Thanks, tom #: 9023 S7/Telecommunications 05-Jan-91 04:53:04 Sb: #9015-#uucp Fm: Ed Gresick 76576,3312 To: Tom Napolitano 70215,1130 (X) Tom, I communicate the 3 machines (besides several CoCo boxes) using Mark's version of UUCP with my CoCo. 1 - The Tandy Regional Office in Randolph, Mass. at least twice a week. They are using a Tandy 4000 (386 box) running Tandy/SCO Xenix. The version of UUCP is Honey Dan Bear. I upload orders to them and receive stock updates from them using 'uucp' as well as mail back and forth using the 'mail' utilities. I've been communicating with them since last February (1990). (Previously I used either 'uulink' on an MSDOS box or the UUCP provided by SCO on a Xenix 386 box.) 2 - Tandy in Ft Worth occassionaly - no regular schedule. They're using a VAX of some sort and I don't know what version of UUCP they're using. This is primarily a mail link. 3 - A Company in Long Island once a week. They have a Wang computer and I don't know the version of UUCP they're running (neither do they). I upload orders to them once a week using 'uucp' as well as occassional mail back and forth. I did have problems setting up with Tandy. They use a hyphen '-' in the site names. I had to set-up a different 'alias' file and I modifed uucico, login, rmail and uuxqt to handle it. I was the first vendor to set-up a link with the Company in Long Island. They had problems setting up their system. They finally had the Wang people set them up. Ed Gresick - DELMAR CO There is 1 Reply. #: 9055 S7/Telecommunications 07-Jan-91 08:13:38 Sb: #9023-uucp Fm: Tom Napolitano 70215,1130 To: Ed Gresick 76576,3312 (X) Ed, Thanks for the reply. I have to admit my setting up Mark's uucp was not perfectly clean, due to my particular modem, but that wasn't his fault. However the connection between uucico and 386/ix went like it was designed. tom #: 9018 S3/Languages 04-Jan-91 21:31:42 Sb: #Not a hot topic Fm: Paul Rinear 73757,1413 To: Anyone At the risk of being rude: has anyone printed out the Kreider C library docs from clibdo.ar ? I can't find the mroff that is said to be in there. The source code is there, but there seem to be pieces missing that are needed to compile it. Bet nobody replies to this.... There are 2 Replies. #: 9019 S3/Languages 04-Jan-91 22:04:23 Sb: #9018-Not a hot topic Fm: Pete Lyall 76703,4230 To: Paul Rinear 73757,1413 (X) Lot's of us have... in fact I did some camera ready stuff a few years back, and distributed it to those interested. Before you ask, I no longer have it. Re: mroff - what's wrong/missing? Mroff is supposed to be here in either DL9 or DL6. Worst case, someone could shoot you a binary of it (I'm no longer running a 6809, or I would). Pete P.S. Not sure I understand your "bet nobody replies to this"... Actually, that was the only 'rude' part of your message. We pride ourselves on being responsive and accurate here. You'll find you'll get lots of help without resorting to reverse psychology. #: 9020 S3/Languages 04-Jan-91 22:07:17 Sb: #9018-#Not a hot topic Fm: Pete Lyall 76703,4230 To: Paul Rinear 73757,1413 (X) Did you do a "BRO mroff*" in DL6? There you'll find two files: Mroff.ar and Mroff2.ar. The latter is only executable and documentation, if that's all you need. Pete There is 1 Reply. #: 9044 S3/Languages 06-Jan-91 17:12:40 Sb: #9020-#Not a hot topic Fm: Paul Rinear 73757,1413 To: Pete Lyall 76703,4230 (X) Thanks, and sorry for being rude It was one of those days. There is 1 Reply. #: 9047 S3/Languages 06-Jan-91 18:09:22 Sb: #9044-Not a hot topic Fm: Pete Lyall 76703,4230 To: Paul Rinear 73757,1413 (X) No problem. #: 9031 S10/OS9/6809 (CoCo) 05-Jan-91 15:58:50 Sb: #VDG windows Fm: Denise Tomlinson 71021,3274 To: all Is there a way to have 2 vdg windows with shells and 2 programs running in them? I know about /w1 /w2 and soforth, and how to use the shell command and the key. The two programs I want to run at the same time use the standard 32/16 /term screens. I have to be operating out of that type of screen to boot the program. I try booting out of /w1 but it gives me a "no vdg window" error. Thanks, Denise There is 1 Reply. #: 9039 S10/OS9/6809 (CoCo) 06-Jan-91 02:24:40 Sb: #9031-VDG windows Fm: Kevin Darling (UG Pres) 76703,4227 To: Denise Tomlinson 71021,3274 (X) Yes, assuming you have enough system map space (for the text vdg windows), you can pick a descriptor and for example: xmode /w6 type=1 shell <>>>/w6& The "type=1" sets it as a vdg type window default. Other people sometimes make up a set of renamed descriptors (/v0, /v1, etc) just for this purpose (there may even be a set in Lib 10 here). But the xmode will work fine. Be sure to xmode back to type=80 afterwards... just in case later on when you exit your program, an open to /w doesn't accidentally find and use /w6 (or whatever) as a vdg window. I'm rambling, but I think you get the gist. kev #: 9036 S10/OS9/6809 (CoCo) 05-Jan-91 23:57:55 Sb: #pmap! Fm: Everett Chimbidis 76370,1366 To: 76703,4227 (X) Where do I find pmap? There is 1 Reply. #: 9037 S10/OS9/6809 (CoCo) 06-Jan-91 01:06:23 Sb: #9036-pmap! Fm: Dan Robins 73007,2473 To: Everett Chimbidis 76370,1366 (X) Everett, It (PMAP) is located in Kevin Darling's UTIL3.BIN upload, which is located in LIB 10. You can: BRO UTIL3.* and it should pop up. Dan #: 9038 S10/OS9/6809 (CoCo) 06-Jan-91 01:10:31 Sb: #FD501 power transformer Fm: Dan Charrois 70721,1506 To: all Just today the primary for the transformer in my disk drive died. The markings on the transformer are pretty well obscure so I was wondering if anyone could clue me in on what voltage it puts out. I know it is tapped in 4 places, but that's about all I can come up with when it doesn't work! Hopefully I can pick one up for cheaper than a whole power supply... Thanks for your replies Dan There is 1 Reply. #: 9086 S10/OS9/6809 (CoCo) 11-Jan-91 00:56:39 Sb: #9038-FD501 power transformer Fm: Wayne Day 76703,376 To: Dan Charrois 70721,1506 A disk drive power supply should be putting out +12v dc and +5v dc regulated, so... somewhere in the area of 13v and 6v respectively? Wayne #: 9040 S9/Utilities 06-Jan-91 07:46:21 Sb: #pmap Fm: Everett Chimbidis 76370,1366 To: 76703,4227 (X) Still cant find UTIL3. Can you give me more of a hint? looking for p map There is 1 Reply. #: 9041 S9/Utilities 06-Jan-91 08:04:40 Sb: #9040-pmap Fm: Mike Haaland 72300,1433 To: Everett Chimbidis 76370,1366 (X) Everett, try going to lib 10 and doing a BRO/KEY:PMAP. That'll bring up UTIL2.AR, UTIL2.DOC and UTIL3.BIN. The last file is an AR file and I think it's the one you're looking for. Mike #: 9043 S3/Languages 06-Jan-91 16:34:41 Sb: #'C' help Fm: Jim Peasley 72726,1153 To: All Got a question and I don't know whether it's related to the way OS-9 does redirection, or whether it's related to 'C'. Any input welcome! I'm developing a 'C' program that uses cursor positioning calls, and running it from the active window, it works just fine. However, when redirecting it to another window, even before starting a shell on the non-active window, the cursor positioning code seems to generate a LF rather than aligning the text in the proper column... i.e. all the text that is supposed to be tabular is at the left side of the screen! I'm using Bruce's window descriptors (they're all the same) and it exhibits the same behavior whether the window is hardware or gfx, type 07 or type 02. Anybody know what's going on here? Thanks, ...Jim There are 3 Replies. #: 9045 S3/Languages 06-Jan-91 18:07:16 Sb: #9043-#'C' help Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) Hmmm...sounds like somehow you're emitting a CR there, and if that is done using I$Writeln instead of I$Write, and the path descriptor has the option set to cause CRs to be followed by LFs, then that could happen. Could you post a code fragment to show what is happening? (Don't forget the SU (save unformatted) when you do that.) There is 1 Reply. #: 9057 S3/Languages 08-Jan-91 00:31:56 Sb: #9045-#'C' help Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; Originally, I had a \n after printing the date and name strings due to the difference in the way DOS and OS-9 handle flushing the buffer. With the newline, all the data is positioned at the left side of the screen -- only when redirecting. I have since added a fflush(stdout); statement after the name and date, and again, in an active window, things work fine, but redirecting causes the cursor positioning to get "eaten" and the following data is positioned right after the name string. -------- code fragment from pgm. ---------- #define CURSOR pos_cur ... ... CURSOR(1,curline); printf("%s %s",date,name); fflush(stdout); if (span > 0) { CURSOR(45,curline); printf("%2d%s %s\n",span,suff,eptr); } else { CURSOR(50,curline); printf("%s\n",eptr); } Any ideas on why redirecting stdout would cause cursor positioning to be hosed? ...Jim There is 1 Reply. #: 9060 S3/Languages 08-Jan-91 05:36:01 Sb: #9057-#'C' help Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) No, I can't think of any reason for redirection would do that. I lack experience with doing window-related stuff, so about all I can say is that folks have had trouble, or said they've had trouble, with situations in which they have emitted escape sequences containing CR because for some reason (if they use C standard I/O, it will happen for SCF devices) I$Writeln is used to write the data instead of I$Write, because in that case they got an extra LF. If that is what is happening to you, then the only solution I know of is to set the _RBF bit in the _flags field in the FILE structure that you're using before you do any output, since that will force it to use I$Write. This, unfortunately, also means that you'll have to explicitly emit LFs after CRs that you want to have LFs following, since SCF doesn't distinguish between CR as part of an escape sequence and other CRs (which is kind of a shame). There is 1 Reply. #: 9068 S3/Languages 08-Jan-91 22:07:36 Sb: #9060-'C' help Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; I guess your reply means that I'll have to go and read the manual, eh? (RTFM, if I remember my acronyms correctly ;-) ) Seriously, I'll reference your msg. while looking thru tee manual and see if I can dope out a solution. ...Jim #: 9046 S3/Languages 06-Jan-91 18:08:35 Sb: #9043-#'C' help Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Shouldn't be C, because C doesn't evem know about I/O (technically).. Anything differen't in the descriptors? Also - do you have the CC3io patch in place? Pete There are 2 Replies. #: 9058 S3/Languages 08-Jan-91 00:32:05 Sb: #9046-#'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; All the /w descriptors are dittos. And CC3io? I _think_ that I've patched it... I usually follow patches pretty closely. (This is one of my New Year's resolutions -- to *accurately* LOG all system changes on the MM/1!) See previous msg. to JJ for code fragment and more info. re: portability Not _too_ bad, if you start with it in mind, but somewhat of a pain. I've gotten the program to run on both machines, but there's just one more thing (isn't there always?) that I'd like to change. Taking a note from your 'more' program, I'm using "read(1,keyin,1);" where "keyin[1]" to get a user response without having to press . Under DOS, I've tried "read(stdin,keyin,1);" which the manual says SHOULD work, but alas, the value returned is "\5" rather that the "y" or "n" I'm expecting. What is different about the DOS version of "read"? Any ideas? I'd kindaolike to use the same function for both versions if I could. ...Jim There are 2 Replies. #: 9061 S3/Languages 08-Jan-91 05:37:24 Sb: #9058-#'C' help Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) I'd be very surprised if that worked. read() wants a path number (or a "file handle" in MS-DOSese). stdin is a FILE *, and goodness knows how it will be interpreted when handed to a function wanting a path number. There are 2 Replies. #: 9069 S3/Languages 08-Jan-91 22:07:39 Sb: #9061-#'C' help Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; Yep, I had this pointed out to me today by another 'greenhorn'. We tried it, but still it didn't work as the OS-9 version dsd -- required hitting to accept the keystroke. ...Jim There is 1 Reply. #: 9071 S3/Languages 08-Jan-91 22:47:09 Sb: #9069-'C' help Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) OK...that has to do with input, rather than output. Unless you do something to make C standard I/O do otherwise, like turn off buffering or set the _RBF flag, it will use I$ReadLn on SCF paths open for input to read data. That accumulates data until it either runs out of buffer or it reads a CR (well, the EOL character for the path, but that's usually CR). #: 9081 S3/Languages 10-Jan-91 23:21:04 Sb: #9061-#'C' help Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; RE: your Internet message about SIMM memory What did you have to pay for the 1Meg. SIMMS? Fry's had them about a month ago for $37.50 for 1x8's and $39.50 for 1x9's and I passed them up thinking they'd go down even more.... Now they're up to $44.50 for the 1x8's. Judging from the trade rags that I get to read at work, it looks like the 4Meg. SIMM production is being ramped up both here and in Japan, and we can look for falling prices RSN. One report I saw estimated < $200 by mid-summer, but I wouldn't hold my breath given the current world situation. ...Jim There is 1 Reply. #: 9088 S3/Languages 11-Jan-91 06:53:24 Sb: #9081-#'C' help Fm: James Jones 76257,562 To: Jim Peasley 72726,1153 (X) I paid about $47 each for them, which looked pretty consistent with everything else in the issue of *Computer Shopper* I scanned. I *do* hope that you're right about the 4M SIMMs. 9 Mbytes in my MM/1 would be very nice. There is 1 Reply. #: 9100 S3/Languages 11-Jan-91 23:09:54 Sb: #9088-'C' help Fm: Jim Peasley 72726,1153 To: James Jones 76257,562 (X) JJ; > hope that you're right about the 4M SIMMs. 9 Mbytes in my MM/1 would be > very nice. Yeah, but how would you ike 128 Meg? The NewsClip forum I get these tidbits from mentions that they're (Fujitsu?) starting a pilot line for 64Meg chips with limited delivery schedules starting in 1992-93 time frame. Also mentioned frequently are unbelievable capacities for 2" floppies- in the order of > 10MB, and credit card sized removable RAM memories with like capacities. Some truly amazing things coming down the pipeline! ...Jim /exit s reply 9089 Paul; I just went through the same thing. You'll need to "make" a new version of MROFF - see my previous message to Pete. Hmmm, wonder if Mark would object if I uploaded the binary for the updated MROFF? Anybody? ...Jim #: 9063 S3/Languages 08-Jan-91 08:47:43 Sb: #9058-#'C' help Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) JIm - In DOS, best bet is getch(), which is a non-echoing single key read. Pete There are 2 Replies. #: 9070 S3/Languages 08-Jan-91 22:07:43 Sb: #9063-#'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Hmmm.. I originally used getch() (or was it getc()? ), but the difference is that one returns an int and the other a *char. Maybe I'll try casting the result and see what happens. Wouldn't it be nice if all popular (and not so popular) systems had corresponding calls that worked alike?? ...Jim There is 1 Reply. #: 9074 S3/Languages 09-Jan-91 08:07:50 Sb: #9070-'C' help Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Getch() returns an int, which is the same as char in C. Pete #: 9082 S3/Languages 10-Jan-91 23:21:13 Sb: #9063-'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Thanks for all the input and advice... I got the program working on both systems to my satisfaction. For all those following the thread and wondering, the program I'm working on is a C version of my DATECK.B09 program in DL10. Tim Kientzle, I think, posted a message on the Net asking for such a program during a discussion of OSK software, and I though I'd try converting it as an excercise. If anyone would like to 'beta' test it, let me know and I'll mail you the code for your comments and input. The program, generally called from Startup, checks the next 30 days for significant events like birthdays, anniversaries, etc., and will let you search by month or name. This is a learning excercise for me, so any input on additional functions or bells/whistles is solicited. Program willrrun on both OS-9 systems and PC-DOS systems. I gave my boss a copy so he could track when performance reviews and appraisals are due. (brownie points?... Nahhh!) ...Jim #: 9059 S3/Languages 08-Jan-91 00:32:13 Sb: #9046-#'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; One more unrelated question if you please... my recent "C" class finished in the 'hurry-up' mode, and we didn't get to cover MAKE. I spent the better part of Sunday downloading the latest version of CLIB, CLIBT, and CLIBDOC between teenagers and line noise. Now I'd like to print out the MAN pages using MROFF, but ahe version I've got barfs on some of the added formatting codes, so I've got to re-compile the source in the CLIBDOC file. Could you give it a quick run through for me please? I've separately compiled the 4 .c sources using cc -r prgname.c and placed the output in a RELS directory which, if I'm interpreting MAKEFILE correctly is where they're supposed to be. Trying to run MAKEFILE though gives me an error #216g Where am I going wrong? Thanks, ...Jim There is 1 Reply. #: 9064 S3/Languages 08-Jan-91 08:53:33 Sb: #9059-#'C' help Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Running make usually requires that the Makefile be named just that (in Unix the capital is significant - is os9 it's not). The make file is a list of depenancies, and the Make program recurses down the list. Ex: foo: part1.r part2.r foo.h part1.r: part2.r: This makefile pretty much uses all defaults. That is, the .r's are implicity built from .c's. It first looks at the target (foo), and then what makes it up. It then checks the constituent parts, and sees what makes THEM up. For now, forget a RELS dir, and just put all your .r files in the current dir. Also, delete any macro relating to OBJS or RELS in the makefile. Pete There are 2 Replies. #: 9067 S3/Languages 08-Jan-91 22:07:33 Sb: #9064-'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Ahhh! Now I see the problem... I don't have the Make program!! Egads, and bosh! Will peruse the libs for same. ...Jim #: 9083 S3/Languages 10-Jan-91 23:21:18 Sb: #9064-#'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Pete; Nabbed Tim K's MAKE and got MROFF compiled with no problems... maybe I'm getting the hang of this stuff, eh? The learning curve seems to be flattening out a bit. Also played around a bit with yours and Mark's man.c, and got an idea for the next project... integrating a 'more'-like util into 'man' and using an environment file for the input to man so that the libs don't have to be 'hard-coded'. (dreams of grandeur, tempened by inexperience!!) ...Jim There is 1 Reply. #: 9085 S3/Languages 11-Jan-91 00:41:18 Sb: #9083-#'C' help Fm: Pete Lyall 76703,4230 To: Jim Peasley 72726,1153 (X) Jim - Already had a MAN with 'more' in it.... Didn't it surface? Durn - I have more code buried in the binary coffers around here.... Pete There is 1 Reply. #: 9099 S3/Languages 11-Jan-91 23:09:46 Sb: #9085-'C' help Fm: Jim Peasley 72726,1153 To: Pete Lyall 76703,4230 (X) Hmmm... dunno about an integrated version. I was talking about Mark's version that he included in CLIBDOC.AR which he had hacked for his system. That one does indeed have 'more' "in" it, but not integrated. ...Jim #: 9053 S3/Languages 07-Jan-91 06:47:48 Sb: #9043-#'C' help Fm: Bill Dickhaus 70325,523 To: Jim Peasley 72726,1153 (X) Jim, Are you using termcap, or just using the actual control codes? Bill There are 2 Replies. #: 9066 S3/Languages 08-Jan-91 21:35:14 Sb: #9053-'C' help Fm: Jim Peasley 72726,1153 To: Bill Dickhaus 70325,523 (X) Bill; I don know nuttin' about no stinkin' termcaps! ;-) I'm using the cursor positioning routine "pos_cur" that I found in screen.h. It works fine as long as I don't try to redirect output to another window. I can run the program from /w2 and things are as they should be, but if I to /w3 and redirect back to /w2, the cursor positioning gols to he** in a handbasket. See message #9057 for more details. ...Jim #: 9084 S3/Languages 10-Jan-91 23:21:27 Sb: #9053-'C' help Fm: Jim Peasley 72726,1153 To: Bill Dickhaus 70325,523 (X) Bill; Haven't gotten into the why's yet, but playing around with different ways of calling the program, if I call it like so - dateck <>>>/w2 , it works the way it's supposed to, but only redirecting stdout, messes up the cursor positioning. This prob is on my list of rainy day things to do, but after 5 rainless years, it may be a while! (that's a dry gryn) ...Jim #: 9048 S10/OS9/6809 (CoCo) 06-Jan-91 19:36:14 Sb: Disto Hard Drive Fm: james pottage 71750,2012 To: 71750,551 (X) The problem you are encountering with the disto 4 in 1 board and the seagate 157n is the same problem that I encountered with my St125n drive. Ken Scales has written a patch for the disto drivers that cure this problem and also allow formatting of the hard drive under OS9. You can contact Ken by leaving him a message on compuserve, although it would be quicker if you have access to Delfi and left him a message there. #: 9052 S10/OS9/6809 (CoCo) 07-Jan-91 00:31:32 Sb: Eliminator repair Fm: JOERG SATTLER 74016,631 To: 76625,2273 Hi there Bruce! I hope that there has been some progress toward the resolution of the problem with my Eliminator board in the meantime. I would just love to get back up and runnning if at all possible. please let me know as soon as possible. Thanks for your effort in resolving this little problem. oerg a Joerg Sattler 74016,631 #: 9062 S7/Telecommunications 08-Jan-91 08:01:22 Sb: UUCP problems Fm: Steve Wegert 76703,4255 To: All Mark replies to some UUCP questions: <<>> In Message 9015 Tom Napolitano says: > I see mentioned on the coco echo that some folks are saying Mark's uucp >does not communicate properly with 386 machines? What are the details? >Who's 386 Unix port and which programs don't work? I found this surprising, >since my coco3 at home exchanges mail quite nicely, thankyou, with the compaq >386 running Interactive's 386/ix at work. Could you elaborate please? Sigh, yes it is true...there are at least a couple machines that my UUCP protocol has trouble talking with. So far, I know about a DEC microVAX running ULTRIX and a Intel 386 box running an unknown 386 version of UNIX. I suppose there are more lurking out there someplace. I think one or more Apple implementations have trouble also. In Message 9016, James Jones says: >My guess--and it's only a guess, >of course--is, considering that VAXen and 386s both have the bizarro >leastsignificant-byte-first byte ordering, that there's some part of the >protocol that contains byte-ordering-dependent values that aren't getting >byte-swapped before use. I haven't looked in the (very large!) uucp.ar to see >whether there is any indication of that's being the problem, though. You may be right there, but I think it is something less bizzare. On all the machines that my port has problems with, you can send to the problem machine without any troubles, but you just can't receive anything from it, but only after the two machines go into the 'g' protocol transfer mode. I have looking into the problem, but it is very very obscure as you can imagine. On a lighter note, I do have a sliding windows version now running (actually, sorta limping) and will be cleaning it up in the near future for release. I hope to have the above mentioned bug fixed by then too. Dunno if any non-upgraded CoCo's will be able to handle sliding windows UUCP tho....those that had tried it failed. I think I'll have to do some fancy optimizing to get them to work OK. Mark #: 9065 S9/Utilities 08-Jan-91 16:43:04 Sb: #PC Diskette Formatting Fm: Lee Veal 74726,1752 To: All Is there an OS-9 Lvl II utility that will format a MS-DOS diskette so that it could then be used with the PCDOS utility. I'm aware of an RS-DOS-oid utility that will do MS-DOS diskette formats, but I don't want to drop down to brain-dead mode just to format a diskette. Lee There is 1 Reply. #: 9072 S9/Utilities 08-Jan-91 23:15:48 Sb: #9065-PC Diskette Formatting Fm: Bob Palmer 74646,2156 To: Lee Veal 74726,1752 (X) There is a utility package sold by D P Johnson which supports a complete set of transfer functions it also allows formatting. Another package is sold by Clearbrook systems and this has a similar collection ( I understand - not having actually seen it) What I have seen from Clearbrook is their IMS database 4th Gen Language and that was excellent. I never got past the demo system what with not being a very organized person and having no data to base. :-) Sorry - do not know of a public domain MSDOS formatter. #: 9075 S10/OS9/6809 (CoCo) 10-Jan-91 01:11:31 Sb: #data base Fm: Everett Chimbidis 76370,1366 To: all What the Best data base for the coco in os9?? AND where can i get it? There are 3 Replies. #: 9076 S10/OS9/6809 (CoCo) 10-Jan-91 07:15:49 Sb: #9075-#data base Fm: Ed Gresick 76576,3312 To: Everett Chimbidis 76370,1366 (X) Everett, We sell SCULPTOR by MPD for the CoCo. We think its the best. Frank Hogg sells IMS by Clearbrook - he thinks that is the best. There may be some others, but I'm not familiar with them. Ed Gresick - DELMAR CO 302-378-2555 There is 1 Reply. #: 9079 S10/OS9/6809 (CoCo) 10-Jan-91 08:03:07 Sb: #9076-#data base Fm: Steve Wegert 76703,4255 To: Ed Gresick 76576,3312 (X) Ed, I'm curious (really!) ... what's the going price for a CoCo version of Sculptor these days? I've lost track. Steve There is 1 Reply. #: 9087 S10/OS9/6809 (CoCo) 11-Jan-91 03:18:23 Sb: #9079-data base Fm: Ed Gresick 76576,3312 To: Steve Wegert 76703,4255 (X) Steve, Current price for CoCo Version (version 1.16) of SCULPTOR is $260.00. Ed Gresick - DELMAR CO #: 9077 S10/OS9/6809 (CoCo) 10-Jan-91 07:26:27 Sb: #9075-data base Fm: JIM HICKLE 76672,602 To: Everett Chimbidis 76370,1366 (X) Never used a commercial DB on the coco; If you wish to roll your own, check out Al Stevens' "C Database Development" (MIS Press). It has a relational database, b-tree indexing and other good stuff. -jim #: 9078 S10/OS9/6809 (CoCo) 10-Jan-91 08:02:06 Sb: #9075-data base Fm: Steve Wegert 76703,4255 To: Everett Chimbidis 76370,1366 (X) Everett, I've been monkeying around with IMS from Clearbrook, and find it facinating. I've had it for years ... and finally got around to setting up a few databases to help keep me organized (That's a full time job in itself!). Steve #: 9080 S15/Hot Topics 10-Jan-91 08:35:48 Sb: MM1KIT.TXT Fm: Mark B. Sheffield 76247,1332 To: SYSOP (X) Steve - I found a couple of typos in MM1KIT.TXT in DL 15, so have corrected them and re-uploaded the file. Thanks. -mark #: 9089 S10/OS9/6809 (CoCo) 11-Jan-91 12:01:23 Sb: #mroff & Kreider docs Fm: Paul Rinear 73757,1413 To: Pete Lyall I downloaded MROFF and was able to print the mroff docs using mroff. It worked nicely. When it came time to print the Kreider C-lib docs, mroff gave out scads of unrecognized command errors and no results. The command in question seems to be .de which is not mentioned in the docs. What am I doing wrong ? Paul R. There is 1 Reply. #: 9090 S10/OS9/6809 (CoCo) 11-Jan-91 15:32:10 Sb: #9089-#mroff & Kreider docs Fm: Pete Lyall 76703,4230 To: Paul Rinear 73757,1413 (X) The MROFF docs were prepared using a 'flavor' of Mroff created by Mark Griffith. You need Mark's copy, which _should_ be in DL6 or DL9. Pete There is 1 Reply. #: 9092 S10/OS9/6809 (CoCo) 11-Jan-91 16:03:56 Sb: #9090-#mroff & Kreider docs Fm: Paul Rinear 73757,1413 To: Pete Lyall 76703,4230 (X) I can't seem to find it in either library using keywords of "mroff" or "print". Will look some more. There is 1 Reply. #: 9093 S10/OS9/6809 (CoCo) 11-Jan-91 16:32:24 Sb: #9092-#mroff & Kreider docs Fm: Paul Rinear 73757,1413 To: Paul Rinear 73757,1413 (X) Still can't find it. The description of "clibdo.ar" in lib 3 says Mark Griffith's mroff is included. Upon de-arcing, only the C-source for mroff is there. I could probably compile it but I am missing one DEF file; scfstat.h . Paul There is 1 Reply. #: 9097 S10/OS9/6809 (CoCo) 11-Jan-91 21:38:35 Sb: #9093-mroff & Kreider docs Fm: Pete Lyall 76703,4230 To: Paul Rinear 73757,1413 Paul - Drop a note to Steve Wegert.... I believe he's in daily digital contact with Mark's system, and could probably have mark mail the file. Pete #: 9091 S15/Hot Topics 11-Jan-91 15:58:37 Sb: #MM/1 Kit Available Fm: Mark B. Sheffield 76247,1332 To: ALL All - Be sure to see MM1KIT.TXT in DL 15. This is an announcement from IMS about how you can get an MM/1 in kit form. The MM/1 kit is a great bargain, is easy to assemble, and is a way for you to have an MM/1 on your desk while FCC approval for the completed system is pending. -mark There are 2 Replies. #: 9094 S15/Hot Topics 11-Jan-91 17:21:07 Sb: #9091-#MM/1 Kit Available Fm: Robert A. Hengstebeck 76417,2751 To: Mark B. Sheffield 76247,1332 I lost track somewhere, Is the MM1 and the TomCat compatable with all the CoCo OS9 Level II softwhere, that I have? There is 1 Reply. #: 9095 S15/Hot Topics 11-Jan-91 17:56:54 Sb: #9094-MM/1 Kit Available Fm: James Jones 76257,562 To: Robert A. Hengstebeck 76417,2751 (X) The MM/1 is not, unless either someone does a 6809 emulator or the OS/Gateway is done. The TC70 (the 68070 board that plugs into the K-Bus box) is not, either. Both of those systems use 68070s. The TC09 (the 6309 board that plugs into the K-Bus box) *is* supposed to be able to run CoCo 3 OS-9/6809 Level Two software. (When discussing "the Tomcat," one has to be very careful to indicate exactly what one is talking about.) #: 9098 S15/Hot Topics 11-Jan-91 23:09:43 Sb: #9091-MM/1 Kit Available Fm: Jim Peasley 72726,1153 To: Mark B. Sheffield 76247,1332 Mark; Forgive my anxiety, but when will the UPS man get the first boxes? I'm starting a M68000 class tomorrow, and an MM/1 on the desk would make things a _whole_ lot easier! ...Jim #: 9101 S12/OS9/68000 (OSK) 12-Jan-91 07:00:01 Sb: OSK Clib.l Order Fm: Mike Haaland 72300,1433 To: All Has anyone else seen this problem with the OSK clib.l supplied with OSK version 2.3? It seems the and rdump -l or the lib shows some of the functions not in the proper order. Are the libs compiled for specific machines or is this how they come from MicroWare? definition of fflush in putc_c before reference in fseek_c definition of fflush in putc_c before reference in getc_c definition of fflush in putc_c before reference in setbuf_c definition of _tidyup in putc_c before reference in cfinish_a definition of _sysret in syscommon_a before reference in color_a If anyone has any idea if this will affect my programs and if there is a problem with the order, please let me know. Mike Haaland Press !>