#CoComm 3.05
14 messages in this thread
Rick, this thread is too good to pass up. You are correct that the system does
maintain the necessary lists and tables for you to write resource management
routines that will supplement the os. There are also times when I wish we had
an os that had some of the features of RSX or VMS. BUT, as it says in the
system manuals 10^n times, it is left to the various tasks to manage their
system resources in an orderly and efficient manner. Why do we have so many
programs that fragment memory by grabbing little hunks of memory and then
releasing them outof-sequence? Why not let the user configure the task for an
acceptable amount of working memory, or at least have the task do some
intelligent auto-sizing and then don't keep playing with allocations? Why
don't more task overlay their initialization code with buffer space? Why don't
more tasks use intelligent disk paging, especially if you tell them task you
have a fast hard disk?
Your idea of using ram to buffer downloads is great. A fixed allocation to
cover the download maximum size would be sensible. A system that has expansion
ram (1 meg or more) could configure for 256K buffering as a permanent option.
A tighter system could configure for 64K, split in two parts as a permanent
option. Again, some intelligent task auto-sizing would assist the user in
making the decision.
It's interesting that both you and Larry are making some thoughtful suggestions
and at the same time, some really spaced-out comments. Now if Ben would just
fix the parity and stop-bit menu options in CoComm, we could bring him back
into this thread.
<waiting for fan to point in my direction with semi-solid objects>
Ted
What, pray tell, is wrong with the baud/parity options in CoComm?
I didn't say "baud". I said "stop-bits". <chuckle..chuckle..chuckle>
So what's wrong with the stop bitz?
Actually, to be perfectly accurate, I said "parity and stop-bit menu options".
Lest you get too annoyed, a real answer is forthcoming. <chuckle>
Arggghhhhhhh!
Ben, here are the test results at 300 baud from the log window of CoComm
version 3.02, for the various combinations of word length and parity:
7N1 LF=012Q
CR=015Q Stop bit at bit position 8
7O1 LF=212Q
CR=015Q Stop bit at bit position 9
7E1 LF=212Q (this is wrong, equal to marking parity)
CR=215Q Stop bit at bit position 9
8N1 LF=012Q
CR=015Q Stop bit at bit position 9
8O1 LF=P012
CR=_012 Stop bit at bit position 10
8E1 LF=P012Q (this is wrong, equal to marking parity)
CR=P015Q Stop bit at bit position 10
Since you don't even have marking or spacing options on your menu, it's rather
clear that you're not handling the serial port correctly.
I'm not trying to rub it in, but I tested the current version of OnLine,
version 2.10, and it handles all the possible combinations correctly.
Ted
Well, ted, looks like you did all the research I would need to fix it – and
from what you say, I assume it IS broken. Now… if only I knew what "_012" or
"P012Q" meant… not to mention the more normal looking, but just as
mysterious to me, numbers ???? –Ben–
A quickie course in assembly language:
012Q means an 8 bit word who's value is 012 in octal.
P012Q means an 8 bit word as above with an extra parity bit active.
_012Q means an 8 bit word as above with the parity not active (space).
LF = line feed = 012Q in ASCII
CR = carriage return = 015Q in ASCII
7N1 = 7 data bits, no parity bit, one stop bit.
7O1 = 7 data bits, odd parity bit, one stop bit.
7E1 = 7 data bits, even parity bit, one stop bit.
8N1 = 8 data bits, no parity bit, one stop bit.
8O1 = 8 data bits, odd parity bit, one stop bit.
8E1 = 8 data bits, even parity bit, one stop bit.
7M1 = 7 data bits, marking parity bit, one stop bit.
7S1 = 7 data bits, spacing parity bit, one stop bit.
Ted
aha. I was familiar with the 7N1 and so on, but octal…. Geeezzz… I thought
that went obsolete with fortran, basic, ibm computers, and the notion of
"stealing is bad". <grin> Octal? <muttering to self> I only use bases 2, 10,
and 16. 8? (same as base 10… if you're missing 2 fingers) Assembly
language? For a pdp8, maybe! hehehe. Octal! <shaking head> –ben–
Ok, so next time I'll put in excess three!
Ted
Gee ben…
The paper companies love octal. 50% more characters yto say what you can in
hex. To me, octal and assembly language have no relation to one another, other
than in a historical perspective.
Regards, Larry.
Ben,
Try doing an alert string with anything but Octal, I couldn't get it to
work until I used octal for positioning, etc. within the alert.
Don
Spaced-out comments? Who, US??? <Putting arm around Larry's shoulders and
grinning widely>
BTW, my REMIND program allocates memory on a record-by-record basis. Although
this SOUNDS like the same thing, it's really a different issue. As has been
pointed out, with downloads you would be grabbing blocks one at a time,
seperated by a considerable time period, possibly resulting in significant
memory fragging. REMIND, however, pulls in all its records at once upon
startup. To cause significant fragging you would have to be running another
task which was loading/generating data as quickly as REMIND was loading it in
off disk. Nearly impossible to cause any problems, but the discussion of
terminal programs DID cause me to analyze the question.
"Spaced-out comments" notwithstanding, you are 100% correct: discussions of
this sort are terribly useful for opening one's mind to new approaches and
non-obvious problems. I'm glad I got to be a part of this one.
Rick