informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/messages/ALANWESTON/1991/CIS01_12.txt

10223 lines
320 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
#: 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???
<Dave Kaleita>
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 <grin>!
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!)
<Dave Kaleita>
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??
<grin!>
<Dave Kaleita>
#: 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).
<Dave Kaleita>
#: 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 <smile>.
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 <grin>.
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 <grin>. 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: <big grin> 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 <grin>
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 (<grin>).
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 $<xxxx>"
*
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 #$<xx>"
*
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? <grin>
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! <grin>
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' <grin>.
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! <GRIN> 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 +
<cr>. 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?
<Grin>)
#: 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!
<<BIG Grin>>
--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 <stdio.h> #include <strings.h> #include <modes.h>
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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
There is 1 Reply.
#: 8609 S3/Languages
05-Dec-90 09:18:28
Sb: #8600-login shell tst prg
Fm: Pete Lyall 76703,4230
To: MAS 76336,3226 (X)
I have just snagged your message, and have not studied it in detail yet, but
the first thing I'd encourage is using SEPARATE pipes for stdin and stdout... I
wouldn't open the pipe in UPDATE mode. Who is mucking with the pipe buffer's
read pointer, for instance? Is it the parent reading responses? Is it the child
reading instructions?
Pete
#: 8601 S3/Languages
04-Dec-90 20:56:56
Sb: tst prg part 2
Fm: MAS 76336,3226
To: 76703,4230 (X)
PART 2 OF TEST PROGRAM
write(c[0], "name\n", 5);
printf("#### WRITE 1 #### name \\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "xxxx\n", 5);
printf("#### WRITE 2 #### xxxx\\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "p", 1);
write(c[0], "l", 1);
write(c[0], bs, 1);
write(c[0], "d", 1);
write(c[0], "\n", 1);
printf("#### WRITE 3 #### pl<BS>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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "logout\n", 7);
printf("#### WRITE 4 #### logout\\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
if (close(c[0]) == -1)
printf("Unable to close() pipe0 : #%d\n",errno);
if (close(c[1]) == -1)
printf("Unable to close() pipe1 : #%d\n",errno);
print@X }
#: 8602 S3/Languages
04-Dec-90 20:57:58
Sb: login shel tst prg 1
Fm: MAS 76336,3226
To: 76703,4227 (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 <stdio.h> #include <strings.h> #include <modes.h>
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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
#: 8603 S3/Languages
04-Dec-90 20:58:59
Sb: tst prg part 2
Fm: MAS 76336,3226
To: 76703,4227 (X)
PART 2 OF TEST PROGRAM
write(c[0], "name\n", 5);
printf("#### WRITE 1 #### name \\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "xxxx\n", 5);
printf("#### WRITE 2 #### xxxx\\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "p", 1);
write(c[0], "l", 1);
write(c[0], bs, 1);
write(c[0], "d", 1);
write(c[0], "\n", 1);
printf("#### WRITE 3 #### pl<BS>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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
write(c[0], "logout\n", 7);
printf("#### WRITE 4 #### logout\\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 <HEX\n",buffer[0],buffer[0]);
}
else
{ sleep(1);
break;
}
}
}
if (close(c[0]) == -1)
printf("Unable to close() pipe0 : #%d\n",errno);
if (close(c[1]) == -1)
printf("Unable to close() pipe1 : #%d\n",errno);
print@X }
#: 8604 S10/OS9/6809 (CoCo)
04-Dec-90 21:22:52
Sb: #Disto CCHdisk (SCSI)
Fm: james pottage 71750,2012
To: Kevin Darling
Kevin, this is Jim Pottage, I talked to you a while ago about a problem with my
ST125N (SCSI) hard drive. I mentioned that it would not access the drive in the
first attempt. Therefore, it would not run my startup file off the hard drive,
or boot to the hard drive. Well, after a lot of work with Ken Scales (he did
all the modifications and most of the work, I just tested the driver) Ken has a
version of CCHdisk that allows the drive to work on the first access. I believe
he has inserted a restore to track zero to accomplish this bbut for more
accurate information you could talk to Ken. Further, the driver seems to work
with the format command. I just thought I would let you know that the problem
seems to have been solved. Further, if any one else has this problem they might
try getting a hold of Ken.
Jim Pottage
There is 1 Reply.
#: 8607 S10/OS9/6809 (CoCo)
04-Dec-90 23:02:23
Sb: #8604-Disto CCHdisk (SCSI)
Fm: Kevin Darling (UG Pres) 76703,4227
To: james pottage 71750,2012 (X)
Thanks for the info, Jim!
Oddly, I had just run into a similar thing myself on an embedded SCSI drive,
and ended up having the cc3go module do a coupla chd/chx's to the hard disk in
order for it to finally "take". I believe that some tandy/coco-HD people found
they had to do the same thing.
I'll talk to Ken. thx! - kev
#: 8608 S14/misc/info/Soapbox
05-Dec-90 08:27:58
Sb: CoCo List traffic
Fm: Steve Wegert 76703,4255
To: All
After a slight delay, the CoCo List traffic is available once again in LIB 14.
Traffic from 11/27 -12/03 is available in LS1203.ar as a bulk upload. Daily
postings resume from that point.
Steve
#: 8613 S10/OS9/6809 (CoCo)
05-Dec-90 19:52:52
Sb: #How to install 512K?
Fm: MICHAEL ROSEN 73340,2756
To: KEVIN DARLING
KEVIN,
THE ONLY PROBLEM NOW IS I HAVE (2) COCO 2'S AND NOW A SET OF COCO 3'S I
HAVE AN UNPOPULATED 512K BOARD (TANDY) AND I'M WONDERING WHAT CHIPS TO USE TO
MAKE IT WORK.. HAVE YOU GOT ANY IDEAS ON HOW TO INSTALL 512K IN A COCO 3? ALSO
WHAT CHIPS DO I NEED? I GUESS I CAN HAVE 1 COMPUTER TO HACK ON <GRIN>.. 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.
<grin> 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! <grin>
#: 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..<grin> 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...<grin>)
-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? <wiggle eyebrows>
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 <sigh>.
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. <Merry Xmas!>
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<bes, wayne
There is 1 Reply.
#: 9073 S7/Telecommunications
09-Jan-91 05:31:53
Sb: #9011-BBS
Fm: edward langenback 73510,145
To: WAYNE LAIRD 73617,3042
Wayne, thanks for calling! and thanks for the u/l of COCOS9ER, i'll keep it
available in my xfer section for as long as space holds out. also, i thought
i'd let you know that there are two other CoCo run BBS's here in Columbus...
The Eastside Connection 1-614-228-7371 Betleguese 7 1-614-866-5949
"KMA-68!!"
>>>>>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 <grin>. 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 <grin>: 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 <grin>.
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 </d0/bootlist. Remember that the
bootlist must be in /d0. Have fun, Dave.
There is 1 Reply.
#: 8806 S10/OS9/6809 (CoCo)
17-Dec-90 20:01:05
Sb: #8805-Starting out (part 1)
Fm: DAVID DE FEO 71630,721
To: DAVID DE FEO 71630,721 (X)
Oops, some clarifications....you have to put this boot on a 35 track disk and
then make a startup file and put shell and grfdrive in CMDS along with whatever
other commands you want. Then you can format a disk for 40 ds. The disk you
format (format /d0) will have a double sided format. Then, load "cobbler" into
memory. Then, put your newly formated disk into your drive and do "cobbler
/d0". Now you have a bootable 40 trk doublesided disk(don't forget to put
startup on it as well as put shell and grfdrive in the Cmds dir).
Dave
#: 8816 S10/OS9/6809 (CoCo)
18-Dec-90 00:38:58
Sb: #8804-Starting out (part 1)
Fm: Jim Peasley 72726,1153
To: Carlyle Hudkins 72040,2754 (X)
Carlyle;
There's lots of startup help in the libs here - some of the ones that come to
mind right away are Bruce Isted's WINVDG.AR in lib 10, Kevin Darling's
BESTOF.TXT also in 10, Mark Griffith's tutorial on making boot disks painlessly
(can't remember the name, but a search on 76070,41 should get it for you.) and
many others.
If you have specific needs, ask and someone will remember where that 'just
what you need' file resides.
Oh, yeah, you asked about xmode'ing windows - that's what Bruce's WINVDG does
- it sets all the descriptors that you will EVER need, from w1 - w14 and v1 -
v7. There's also a WMODE.AR that'll let you modify descriptors in real time
(can't remember the author tho).
...Jim
#: 8831 S10/OS9/6809 (CoCo)
19-Dec-90 16:27:36
Sb: #8804-#Starting out (part 1)
Fm: William Phelps 75100,265
To: Carlyle Hudkins 72040,2754 (X)
If you don't know what you want to change, then don't change it until you need
to change it. I was guessing about the printer; do you use a full blown word
processor just for programs?
William
There is 1 Reply.
#: 8840 S10/OS9/6809 (CoCo)
21-Dec-90 12:18:31
Sb: #8831-Starting out (part 1)
Fm: Carlyle Hudkins 72040,2754
To: William Phelps 75100,265 (X)
I use the WP to for my poems and stories, and to compose mail. Haven't written
any progs with it yet.
Carlyle H
#: 8793 S10/OS9/6809 (CoCo)
16-Dec-90 19:21:20
Sb: Getting started (part 2)
Fm: Carlyle Hudkins 72040,2754
To: all
Continued from previous message:
The WP uses a BASIC boot program to set up defaults and load the ML--can
this be accomodated by a window?
Thanks for your time and trouble--
Carlyle H (I wrote the last message offline with Simply
Better--there may be a few glitches due to different character compatibilities
with CIS; I also unknowingly exceeded the msg size requirements, and I got hung
up while uploading! What a day!)
#: 8794 S10/OS9/6809 (CoCo)
16-Dec-90 20:59:31
Sb: #disto SCII boot disorder
Fm: KENHEIST 71750,551
To: all
General info to any in possible need.
I have used a Disto SCII for about 9 months and have had a lot of trouble with
dist format and a correct read and writes to dist. Called CRC ,even sent back
the controller and 4n1 card.They checked it out, even replaced the drive
card;but .... to no avail. The problem contenued. It was most pronounced with
the MPI and extra cards in place, allmost gone with just the disto in the
computers side slot.
Any way, even got Tony D. into the problem but still nothing.
Finally this evening after months of runnning in the sleep mod tried something
that I had not thought of in this connection. Reworked the boot
list.......BINGO!!!!
I'v had boot disorders be for but never this way. The problem only arises
when the IRd is used. Moved RBF.mn below the disk drive discriptors and driver.
This left OS9p1 OS9p2 OS9p3 INIT and IOMAN at the top of my boot.
Sometimes you just have to let go..... \exit
There is 1 Reply.
#: 8799 S10/OS9/6809 (CoCo)
17-Dec-90 06:09:42
Sb: #8794-disto SCII boot disorder
Fm: Dan Robins 73007,2473
To: KENHEIST 71750,551 (X)
Ken,
It's known as the BLOB....the Boot List Order Bug. It's not a definable bug,
with a known fix, but you did what many others have done...play with it until
it works. I think Kevin Darling placed a file in LIB 10 that discusses the BLOB
in better detail.
Dan
#: 8809 S3/Languages
17-Dec-90 21:07:31
Sb: #malloc() problem
Fm: Bob van der Poel 76510,2203
To: all
Does anyone know of any problems with the malloc() C function. I'm finding that
my data (saved in a malloc()ed buffer) is corrupted from time to time. I
suspect a wild pointer in MY code, but I thought I'd check since I can't find
the problem here. Also, I noticed that memory returned with free() does not
seem to get reused unless the request size is identical to the original. Is
there a fix for this? Or does it clear up when there is no more easy memory
available?
BTW, this question concerns the 6809 C compiler using the Krieder library, but
since I hope to port the code to 68K any comments in that area will also be
appreciated.
There is 1 Reply.
#: 8810 S3/Languages
17-Dec-90 22:22:05
Sb: #8809-malloc() problem
Fm: Pete Lyall 76703,4230
To: Bob van der Poel 76510,2203 (X)
If you're using Carl's malloc(), it's supposed to be clean...
Pete
#: 8812 S10/OS9/6809 (CoCo)
18-Dec-90 00:01:17
Sb: #Eliminator repair
Fm: JOERG SATTLER 74016,631
To: 76625,2273 (X)
Hi Bruce. A couple days ago Frank Hog Labs. informed me that my Eliminator
board was send 12/12/90) Would you please be kind enough to advise me via this
forum what the result of your investigation is, and also could you tell me what
if any other then the WD1002-05 might be an alternative controller to be used
with the Eliminator. It seems my controller crapped out at the same time that
the Eiminator decided to quit. It might be a case one causing the other to go
haywire, but if so I will have to replace the controller, and Frank tells me he
does not have access to the WD1002-05 any longer. So what next to do.
Thanks Joerg
There is 1 Reply.
#: 8884 S10/OS9/6809 (CoCo)
25-Dec-90 14:17:53
Sb: #8812-#Eliminator repair
Fm: MOTD Editor..Bill Brady 70126,267
To: JOERG SATTLER 74016,631 (X)
Joerg, call Frank back and get the number for EMERALD, I think. They will
re-work your WD board for you.
There is 1 Reply.
#: 8914 S10/OS9/6809 (CoCo)
27-Dec-90 16:29:02
Sb: #8884-Eliminator repair
Fm: JOERG SATTLER 74016,631
To: MOTD Editor..Bill Brady 70126,267
Thanks for the name of "EMERALD". And a happy new year to you to. Joerg
#: 8872 S10/OS9/6809 (CoCo)
24-Dec-90 18:02:14
Sb: Eliminator repair
Fm: JOERG SATTLER 74016,631
To: Bruce Isted (UG VP) 76625,2273 (X)
Thanks for the reply !!!!! And a merry X mass and and a Happy New Year.
#: 8820 S7/Telecommunications
18-Dec-90 23:24:36
Sb: Cu now in d/l 7
Fm: Brett Wynkoop 72057,3720
To: uucp users
Greeting-
I just left a Yule gift in the telcom D/L area. Hope you folks with the
UUCP package like it. It is cu. Works similar to the Un?x program of the same
name. Really neat for dialing out on your modem without having to think about
the details of killing tsmon removing and creating lockfiles etc.
-Brett
#: 8829 S12/OS9/68000 (OSK)
19-Dec-90 11:06:39
Sb: #uWare support user OSK?
Fm: Mike Passer 72750,420
To: All
Hello!
Does anyone know if Microware support for OS-9 68000 will apply to copies sold
with machines such as the MM/1 or TC-70 just the same as with their larger
customers?
Thanks, Mike Passer
There is 1 Reply.
#: 8833 S12/OS9/68000 (OSK)
19-Dec-90 18:33:17
Sb: #8829-#uWare support user OSK?
Fm: Kevin Darling (UG Pres) 76703,4227
To: Mike Passer 72750,420 (X)
Mike - I'd think that MW support would apply only to the companies buying the
licenses... not to the end customers buying machines that come with OS-9.
This seems natural to me. If a company licensed OS9 for a MIDI controller, for
example, I'd expect that they got the support... but not everyone who buys the
controller! <grin>
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 <grin>. 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! <grin>
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]
<expression>
<expression>(An)
<expression>(An, Rx)
<expression>(PC)
or <expression>(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)'
<more>
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)
<continued>
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.
<more>
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)
<continued>
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 <grin>. 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 <cr>" 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 <cr>" 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<cr>" 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 <clear> 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. <grin> 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 <ENTER>. 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 <enter> 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...<sigh>. 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
<clear> 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! <grin> (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 <CR> !>