1258 lines
40 KiB
Plaintext
1258 lines
40 KiB
Plaintext
|
|
|
|
#: 18354 S1/General Interest
|
|
27-Jun-93 19:17:10
|
|
Sb: COCO3 SALE
|
|
Fm: RONALD BYRAM 71705,1313
|
|
To: ALL
|
|
|
|
Hey I hate to say this But I have all of my coco 3/OS( stuff up for sale or
|
|
Donation. I hate to do it THe Coco has been a great friend over the past 13
|
|
years.... Anyone interested Leave me Email
|
|
|
|
512k coco 3 rs232 multi pak music board 2 disk drives. software.
|
|
|
|
if no one interested any idea who I can donate it too?
|
|
|
|
Ronald Byram Charlotte NC
|
|
|
|
#: 18361 S1/General Interest
|
|
30-Jun-93 19:14:11
|
|
Sb: PNW Coco Fest
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: all
|
|
|
|
Just thought I'd give you all a short report on the PNW coco-fest I attended
|
|
over the weekend. A good time was had by all!
|
|
|
|
I'm not sure of the exact number of attendees, but I figure there were about
|
|
75. About the same as last year.
|
|
|
|
Chris Burke was there with his Rocket. I understand that he is going ahead with
|
|
this and will ship in the early fall. This should be a neat way for folks to
|
|
get into 68K for very little (the board with OSk and 1meg memory is under
|
|
$300).
|
|
|
|
There were some other vendors there too (including BVDP Software <g>). Don't
|
|
know how well anyone did.
|
|
|
|
Oh, and someone had a KIX20 there too. Looks like a nice toy. Unfortunately,
|
|
FHL hadn't yet sent out the the video board so he was running it on a coco set
|
|
up as a terminal. FHL told the owner that the video board would be coming RSN.
|
|
|
|
Folks were there from Alaska, Georgia, California, and all around the PNW. I
|
|
enjoyed it and look forward to the next one.
|
|
|
|
|
|
#: 18367 S5/OS9 Users Group
|
|
01-Jul-93 13:37:36
|
|
Sb: PRM!
|
|
Fm: Tony van der Hoff 100113,2200
|
|
To: Richard Proctor 100031,604
|
|
|
|
Richard,
|
|
|
|
>> Actually I wonder what the average usage of CIS is? <<
|
|
|
|
My use doesn't come anywhere near yours...
|
|
|
|
On average, I log on twice a week, Wednesday evenings, and Saturday mornings,
|
|
but if something exciting is brewing, then other times as well. Very
|
|
occasionally, even at peak times, but only for urgent EMAIL.
|
|
|
|
Mostly this is to read/send EMAIL (about 3 messages/week each way), and to
|
|
access the forums: UKCOMP (read 05; scan 11), CEFORUM (scan 11), VIRUSFORUM
|
|
(scan 01, 02 & 05), MSLANG (scan 01, 15 & 17), OS9 (read 11, scan 01, 05, 12,
|
|
14 & 15). In all, about 3 minutes average on-line time per session.
|
|
|
|
Occasionally, interactive access to the various databases, (afraid I tend to
|
|
use CIM :-( for that, because it makes it easier to navigate around the system
|
|
if you don't know your way). On-line time varies, but may be up to 1/2 hour per
|
|
session.
|
|
|
|
I haven't (yet) distributed software through EMAIL, instead using Telix
|
|
point-to point; but hope to do so in the future, for which I would choose
|
|
Arctic.
|
|
|
|
My modem handles no more than 2400 baud I'm afraid. I thought I was really
|
|
pushing the limits of technology when I bought my first (300 baud) modem some
|
|
10 years ago; when that got hit by lightning (like yours - only it took my COM1
|
|
port on the PC out as well), I replaced it with the present WS3000 about 3
|
|
years ago. I don't think for my present usage 9600 would be cost-effective,
|
|
especially given the higher on-line charges.
|
|
|
|
Tony
|
|
|
|
#: 18387 S5/OS9 Users Group
|
|
05-Jul-93 16:52:30
|
|
Sb: OS9 Contractors
|
|
Fm: Nick Terry 100042,3116
|
|
To: All
|
|
|
|
Can anybody put me in touch with some contract software engineers with OS9
|
|
experience? We are located in Cambridge, England and have a number of contracts
|
|
that we need people for. Experience of machine control systems is of particular
|
|
interest.
|
|
All leads gratefully received,
|
|
|
|
Cheers
|
|
Nick Terry
|
|
|
|
#: 18392 S5/OS9 Users Group
|
|
06-Jul-93 17:16:08
|
|
Sb: OS9 Contractors
|
|
Fm: Nick Terry 100042,3116
|
|
To: Graham Trott 100115,1075 (X)
|
|
|
|
Thanks for the lead. I will contact them and see what their terms are. At the
|
|
moment we have 6 big projects on 5 of them using os9 and we are a bit overrun
|
|
with work. Still this should be seen as a good thing after months of silence!
|
|
Cheers
|
|
Nick
|
|
|
|
|
|
#: 18373 S6/Applications
|
|
02-Jul-93 16:06:31
|
|
Sb: #OS 2, v2.0 or 2.1
|
|
Fm: Anne Callot 71333,155
|
|
To: All
|
|
|
|
Hello! Does anyone have experience with the OS 2 v2.0 or 2.1 systems?
|
|
|
|
Entrepreneur Magazine is doing an article for our Computer Survival Guide this
|
|
Sept., and we'd like to interview you if you have knowledge of this system.
|
|
|
|
Email me your name and the location, name, duration, address, and phone number
|
|
of your business and someone from the magazine will get back to you soon.
|
|
|
|
Thanks!
|
|
|
|
Anne Callot
|
|
Entrepreneur Magazine Books Research Department
|
|
71333,155
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18378 S6/Applications
|
|
04-Jul-93 00:44:21
|
|
Sb: #18373-OS 2, v2.0 or 2.1
|
|
Fm: Bob Palmer 74646,2156
|
|
To: Anne Callot 71333,155
|
|
|
|
You may have more luck finding alternate views to OS2 on this SIG since it is
|
|
fairly clearly dedicated to OS9 and its younger brother OS9000 both of which
|
|
operating systems long predate OS2 (OS9 is over 10 years old) and offer many of
|
|
the same features such as multi tasking, loadable device drivers, memory
|
|
management. One major difference is that these systems support multi users as
|
|
well as multi tasking. Anyhow OS2 - them's fightin words. DOS - them's cuss
|
|
words. Bob
|
|
|
|
|
|
#: 18365 S10/OS9/6809 (CoCo)
|
|
01-Jul-93 04:32:39
|
|
Sb: #17723-#One Meg upgrade
|
|
Fm: OSSIAN WISECUP 70731,327
|
|
To: randy pischke 75460,205 (X)
|
|
|
|
WHOOOOPP , hold on, I must have missed something. Did you say there was a
|
|
2-meg upgrade? and if so where can I get it?
|
|
Thanx O.W.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18372 S10/OS9/6809 (CoCo)
|
|
02-Jul-93 03:29:29
|
|
Sb: #18365-#One Meg upgrade
|
|
Fm: randy pischke 75460,205
|
|
To: OSSIAN WISECUP 70731,327 (X)
|
|
|
|
Actually, I didn't say there was a 2-meg upgrade. Someone told me about it on
|
|
CIS. I did find out that one has to call Tony Distofano direct to get one. His
|
|
home number is 514-747-4851, and you should call him after 6 P.M. Central Time.
|
|
Good Luck.
|
|
Randy
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18375 S10/OS9/6809 (CoCo)
|
|
03-Jul-93 03:46:50
|
|
Sb: #18372-One Meg upgrade
|
|
Fm: OSSIAN WISECUP 70731,327
|
|
To: randy pischke 75460,205
|
|
|
|
Thanx, will do.
|
|
Ossian Wisecup [70731,327]
|
|
|
|
#: 18358 S10/OS9/6809 (CoCo)
|
|
29-Jun-93 17:52:15
|
|
Sb: #18348-Home Pub and File Cat
|
|
Fm: Rogelio Perea 72056,1204
|
|
To: Dan Robins 70007,3264 (X)
|
|
|
|
Thanks! I'll try that!!!
|
|
|
|
#: 18376 S10/OS9/6809 (CoCo)
|
|
03-Jul-93 13:55:30
|
|
Sb: #Upload
|
|
Fm: Brother Jeremy, CSJW 76477,142
|
|
To: SYSOP (X)
|
|
|
|
I mis-spelled Kent Meyers name in the description of Gshell.ar. I typed Keny
|
|
instead of Kent, could we please fix it? --Jeremy.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18380 S10/OS9/6809 (CoCo)
|
|
04-Jul-93 04:44:09
|
|
Sb: #18376-Upload
|
|
Fm: Mike Ward 76703,2013
|
|
To: Brother Jeremy, CSJW 76477,142 (X)
|
|
|
|
All taken care of.
|
|
|
|
#: 18381 S10/OS9/6809 (CoCo)
|
|
04-Jul-93 14:16:12
|
|
Sb: #Home Publisher
|
|
Fm: STEVE SANDISH 70712,2447
|
|
To: 72056,1204 (X)
|
|
|
|
Rogelio,
|
|
I too am looking for better fonts for the Tandy Home Publisher. I
|
|
couldn't find anything specific here on Compuserve but I suspect that something
|
|
like a Basic09 font editor may help. I find that I need someething to produce
|
|
a smaller font like a normal word processer 8 point style. I don't use any
|
|
other service but Compuserve but if you downloaded any shareware from someplace
|
|
else with a smaller font I would appreciate it if you could put it on
|
|
Compuserve.
|
|
Lacking that I will try and devote some time to a font editor.
|
|
|
|
Sincerely,
|
|
Steve Sandish
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18396 S10/OS9/6809 (CoCo)
|
|
07-Jul-93 14:45:44
|
|
Sb: #18381-#Home Publisher
|
|
Fm: Rogelio Perea 72056,1204
|
|
To: STEVE SANDISH 70712,2447 (X)
|
|
|
|
Steve, let me gather up my font collection for Home Publisher and I will upload
|
|
it as soon as I can. This collection I found it in several BBS's around the US
|
|
that support the CoCo....
|
|
|
|
Rogelio Perea
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18403 S10/OS9/6809 (CoCo)
|
|
08-Jul-93 19:16:01
|
|
Sb: #18396-Home Publisher
|
|
Fm: STEVE SANDISH 70712,2447
|
|
To: Rogelio Perea 72056,1204 (X)
|
|
|
|
Rogelio,
|
|
Sounds great, thanks! It is tough to send out a newsletter with font
|
|
taking up 1/3 more than it should.
|
|
Steve
|
|
|
|
#: 18395 S10/OS9/6809 (CoCo)
|
|
07-Jul-93 02:19:49
|
|
Sb: #CoCo chips
|
|
Fm: LEONARD H. REED 72400,1365
|
|
To: all
|
|
|
|
Need parts ! am out in the boonies and have broke CoCo3 need 6309 CPU and
|
|
21P. Who sells these ? Local RS doesn't seem interested.
|
|
reply Len Reed 72400,1365
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18404 S10/OS9/6809 (CoCo)
|
|
09-Jul-93 00:07:51
|
|
Sb: #18395-CoCo chips
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: LEONARD H. REED 72400,1365
|
|
|
|
If you are in the west, try calling Terry Laraway at 206-692-5374 (he is in
|
|
Bremmerton, WA).
|
|
|
|
#: 18366 S12/OS9/68000 (OSK)
|
|
01-Jul-93 08:28:52
|
|
Sb: #18320-#68k bus errors
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: ole hansen 100016,3417 (X)
|
|
|
|
OK Ole, sorry this has taken some time, however my project ends tomorrow and I
|
|
have not been able to get on. Also the PC I used had 512k and wouldn't send
|
|
this message!
|
|
|
|
The following is the last cut of my test program:-
|
|
|
|
* This is a short 'C' program that jiggers the bus trap and spurious
|
|
* interrupt traps on a Radstone 68-41 card to make them do something a
|
|
* good deal more sensible than the standard OS-9 reaction (crash in one
|
|
* case and system reset in the other!).
|
|
* Basically the program hijacks the bus error and also installs a system
|
|
* approved bus error handler, I have less time for the spurious interrupt
|
|
* so I increment a counter and 'rte'.
|
|
* On a bus error the system calls my handler, this saves some interesting
|
|
* info and then calls the system bus error handler. The system bus error
|
|
* handler deletes all the iteresting information, replaces it with stuff
|
|
* we can get from (a5) anyway, then calls the second bus error trap
|
|
* handler (the os-9 legal one) this looks to see if a continuation address
|
|
* has been given. If it has it restores the processor from one of the
|
|
* stacks and jumps there, if not it exits with a decent error message.
|
|
*
|
|
* I don't claim this is a fantastic cure all method, however it has made my
|
|
* system considerably more reliable ( reduces unexplained crashes by 95%).
|
|
*
|
|
* Obviously this is unlikely to be a plug in and go solution for similar
|
|
* problems on other machines, the VBR is unlikely to point to the same
|
|
* address on another machine for example, (look in systype.d) and I don't
|
|
* think you will have a great deal of joy on anything less than an '020,
|
|
* however here it is for what it's worth... sorry I can't devote more time
|
|
* to explaining but I have a customer to keep happy and a bos breathing
|
|
* down my neck!
|
|
*
|
|
* Good luck one and all (and why doesn't OS-9 do something like this, it
|
|
* was hardly difficult once I had found the vector table!).
|
|
*
|
|
* Chann
|
|
*
|
|
#include <stdio.h>
|
|
|
|
/* Define C function to provide user information at trap */
|
|
void bus_err_handler();
|
|
|
|
/* Define global variables to hold registers at trap */
|
|
unsigned r_a0,r_a1,r_a2,r_a3,r_a4,r_a5,r_a6,r_a7,
|
|
r_d0,r_d1,r_d2,r_d3,r_d4,r_d5,r_d6,r_d7,
|
|
r_pc,r_ccr;
|
|
|
|
unsigned program_counter,
|
|
effective_address,
|
|
fault_address,
|
|
os_berr_trap;
|
|
|
|
unsigned spurious_count = 0;
|
|
unsigned old_spurious;
|
|
unsigned spurious;
|
|
unsigned cont_addr;
|
|
unsigned test_result;
|
|
|
|
int isram();
|
|
|
|
/* Main function... installs trap then does something illegal */
|
|
int main()
|
|
{
|
|
|
|
int *i; /* Temporary variables for illegal access */
|
|
int j;
|
|
|
|
cont_addr=0;
|
|
|
|
printf("going to install trap\n");
|
|
|
|
|
|
#asm
|
|
move.l #0,a0 use current stack
|
|
lea ExcpTbl(pc),a1 Point to exception programming table
|
|
os9 F$STrap Install trap handlers
|
|
|
|
move.l ($40008),(os_berr_trap,a6) read and store bus error vector
|
|
lea FastBusError(pc),a0 get new bus error vector
|
|
move.l a0,($40008) overwrite vector in VBR
|
|
#endasm
|
|
|
|
/* Print out info on trap installation */
|
|
printf(
|
|
"old bus error = $%08x, new=$%08x\n",
|
|
os_berr_trap,
|
|
*(unsigned *)0x40008
|
|
);
|
|
|
|
printf("installed trap\n");
|
|
|
|
/* Now kill the spurious interrupt handler!!!!! */
|
|
#asm
|
|
move.l #$40060,a0 can't use a constant here... crap compiler
|
|
move.l (a0),(old_spurious,a6)
|
|
lea Spurious(pc),a1
|
|
move.l a1,(spurious,a6)
|
|
move.l a1,(a0)
|
|
#endasm
|
|
|
|
printf(
|
|
"replaced system spurious irq, wrote $%08x to $%08x... was $%08x\n",
|
|
spurious,
|
|
0x4003c,
|
|
old_spurious
|
|
);
|
|
|
|
/* Wait so printing is done before fault access */
|
|
tsleep(100);
|
|
|
|
if(isram(0x20000000)) printf("memory
|
|
agg82,b&z.620c&23d_63<6236*7zxx0<cf.b2xg2x6:7*j600000004bw.23Z2TF3,G/37V&
|
|
0000000000000000000000000000000000000000000g4h04r.72d23866r.3pfn62
|
|
z220c6/3<_z>03,7sn20_2t6/bgp&27*j6400000000t:7zp20N_+6*+_3+'"s :ep
|
|
"10000000(7.:7*3Nwd10+'"j600000000hv"30000 "g00000t:7zp200idq 6ep(_'&q :e00
|
|
"1,':722dz28&.3g(7.3_*720c6gyc300xgxp200"q "100000000000000<62307.33
|
|
22*7./j640000p6&zp200x~+'vC6*7gZ2GZ6'2GZ2 22*7./j60000T:7ZP200"Q,Z2_'22*S :g
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18382 S12/OS9/68000 (OSK)
|
|
04-Jul-93 17:51:56
|
|
Sb: #18366-#68k bus errors
|
|
Fm: ole hansen 100016,3417
|
|
To: Chris Hann (Mass UK) 100064,1431 (X)
|
|
|
|
hello Chris
|
|
|
|
I need your 'mail' once more. Some of it was scrambled.
|
|
|
|
regards ole
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18390 S12/OS9/68000 (OSK)
|
|
06-Jul-93 05:55:30
|
|
Sb: #18382-68k bus errors
|
|
Fm: Chris Hann (Mass UK) 100064,1431
|
|
To: ole hansen 100016,3417 (X)
|
|
|
|
For completeness here, I keep trying to post this reply... no joy, I think I'll
|
|
try and add it to the Library, never done that before.
|
|
|
|
Chann
|
|
|
|
#: 18350 S12/OS9/68000 (OSK)
|
|
27-Jun-93 03:25:15
|
|
Sb: #BGFX & Mouse
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: all
|
|
|
|
|
|
Has anyone got an idea of why the following Basic program doesn't work ?
|
|
|
|
This is just a test program to try to read the mouse on an MM1 using
|
|
Kevin's BGFX. The "MOUSE" function works fine, if you stay in the original
|
|
window, but if you try SELECT another window the MOUSE function returns
|
|
nothing. Is there a new version of BGFX ? I have version #4, crc DBE1D0.
|
|
|
|
|
|
PROCEDURE mtest2
|
|
|
|
DIM path:INTEGER
|
|
DIM Valid,Area,Control,wx,wy,b1,b2:INTEGER
|
|
DIM count:INTEGER
|
|
DIN response:STRING[1]
|
|
|
|
OPEN #path,"/w":UPDATE
|
|
RUN bgfx(path,"DWSet",0,0,0,80,26,0,1)
|
|
RUN bgfx(path,"Clear")
|
|
RUN bgfx(path,"Select")
|
|
|
|
count=0
|
|
REPEAT
|
|
count=count+1
|
|
RUN bgfx(path,"Mouse",Valid,Area,Control,wx,wy,b1,b2)
|
|
PRINT #path,"Valid = "; Valid;
|
|
PRINT #path," Area = "; Area;
|
|
PRINT #path," Control = "; Control;
|
|
PRINT #path," wx = "; wx;
|
|
PRINT " wx = "; wx;
|
|
PRINT #path," wy = "; wy;
|
|
PRINT " wy = "; wy
|
|
PRINT #path," b1 = "; b1;
|
|
PRINT #path," b2 = "; b2
|
|
UNTIL b1<>0 OR count=500
|
|
|
|
|
|
GET #path,response
|
|
RUN bgfx("Select")
|
|
RUN bgfx(path,"DWEnd")
|
|
CLOSE #path
|
|
END
|
|
|
|
|
|
Any help would be appreciated.
|
|
Larry Olson
|
|
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18351 S12/OS9/68000 (OSK)
|
|
27-Jun-93 11:22:26
|
|
Sb: #18350-#BGFX & Mouse
|
|
Fm: Zack Sessions 71532,1555
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Don't you need to use the path to the new window in the Mouse call?
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18352 S12/OS9/68000 (OSK)
|
|
27-Jun-93 16:19:40
|
|
Sb: #18351-#BGFX & Mouse
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Zack, I thought I did..
|
|
|
|
DIM path:INGEGER
|
|
|
|
OPEN #path,"/w":UPDATE
|
|
|
|
RUN BGFX(path,"DWSET",0,0,0,80,26,0,1)
|
|
|
|
RUN BGFX(path,"SELECT")
|
|
|
|
RUN BGFX(path,"MOUSE",valid,area,control,wx,wy,b1,b2)
|
|
|
|
|
|
Unless there is a different way to specify a path in the mouse command,
|
|
this should work.
|
|
|
|
Larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18353 S12/OS9/68000 (OSK)
|
|
27-Jun-93 18:42:08
|
|
Sb: #18352-#BGFX & Mouse
|
|
Fm: Zack Sessions 71532,1555
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
> Zack, I thought I did..
|
|
|
|
Hmmm, and so you did. Sorry, I obviously didn't look too close before I
|
|
replied. Your code looks OK to me, but I don't use basic or BGFX. If all of the
|
|
calls are working like the corresponding calls in the cgfx.l then I see nothing
|
|
wrong with your code.
|
|
|
|
For the heck of it, what happens if you use the standard input path JUST in the
|
|
mouse call?
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18355 S12/OS9/68000 (OSK)
|
|
28-Jun-93 00:26:08
|
|
Sb: #18353-#BGFX & Mouse
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Zack,
|
|
I tried that also, same result. That little test routine shows that for
|
|
some reason VALID is returning zero, whenever I try to read the mouse from
|
|
anything but the original window.
|
|
I was trying to do a quick port on some of this Basic09 stuff I have around
|
|
here, but this stopped me cold. I guess I will have to try reading the mouse
|
|
with syscalls, that should bypass any problems in BGFX.
|
|
|
|
Larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18357 S12/OS9/68000 (OSK)
|
|
28-Jun-93 18:34:46
|
|
Sb: #18355-BGFX & Mouse
|
|
Fm: Zack Sessions 71532,1555
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Yup, sounds like BGFX's Mouse routine is brain dead all right. Yes, you should
|
|
be able to do the same thing with SYSCALLs. Good luck.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
#: 18359 S12/OS9/68000 (OSK)
|
|
29-Jun-93 21:29:25
|
|
Sb: #c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: all
|
|
|
|
Does anyone know if there is an alignment problem when using GET/PUT buffers
|
|
in C on the MM1 ?
|
|
Is there a fix or a way to get around what seems to be a problem.
|
|
|
|
Does the alignment problem come from the location you GET an object or the
|
|
location where you PUT an object.
|
|
In the routine I'm trying to get working, I draw and fill a 24x8 box, then I
|
|
GET this box and put it in a buffer. Later I have a couple of FOR loops that
|
|
will PUT 200 of these boxes on the screen in a 20x10 grid.
|
|
The problem is that, horizontally every third box has part of the box missing.
|
|
|
|
I hope there is a fix for this....
|
|
larry olson
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 18363 S12/OS9/68000 (OSK)
|
|
30-Jun-93 22:30:04
|
|
Sb: #18359-#c GET/PUT
|
|
Fm: Zack Sessions 71532,1555
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Are you using Edition #48? A problem like what you describe was present in some
|
|
earlier versions of WindIO.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18364 S12/OS9/68000 (OSK)
|
|
01-Jul-93 04:11:59
|
|
Sb: #18363-#c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Zack, yes I'm using ed #48. The problem is definitly there but I have found a
|
|
way around it. I found that by using the LSet(path,code) function, I can get
|
|
around the problem. Maybe that is where the problem is, because LSet(path, 0)
|
|
(default) is where the problem shows up. Using a code of 1,2,3,4, or 5 the
|
|
problem isn't there.
|
|
Is anyone in contact with Kevin ? I wonder if he already has this fixed.
|
|
larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18369 S12/OS9/68000 (OSK)
|
|
01-Jul-93 22:28:44
|
|
Sb: #18364-c GET/PUT
|
|
Fm: Zack Sessions 71532,1555
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
> Is anyone in contact with Kevin ? I wonder if he already has this fixed.
|
|
>
|
|
|
|
Dunno. I'm not.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
#: 18368 S12/OS9/68000 (OSK)
|
|
01-Jul-93 14:00:51
|
|
Sb: #18359-#c GET/PUT
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Larry, I ran into a get/put alignment problem with earlier versions of windows
|
|
when I was still working on my cribbage program. However, with the current
|
|
version (#48) all seems to be okay. Better let us know the version of windio
|
|
you are using and the screen type of the application. As I recall, forcing a
|
|
get to a even pixel value and doing all puts to even values helped when the
|
|
problem as around.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18370 S12/OS9/68000 (OSK)
|
|
02-Jul-93 01:13:26
|
|
Sb: #18368-#c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob, I'm using ed #48 of windio. the screen type is 320x208 type 3, I'm GETting
|
|
a 24x8 rectangle. I'll upload a little test routine I have been playing with.
|
|
That should make it easier too see the problem I ran into.
|
|
|
|
larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18377 S12/OS9/68000 (OSK)
|
|
03-Jul-93 20:00:53
|
|
Sb: #18370-#c GET/PUT
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Larry, it appears that you PUTs are overlaying each other. If I change the x
|
|
increment in you code from 26 to 28 it all appears to work okay. It appears
|
|
that you are drawing the box at 10,10,33,17; the GET is from 10,10,24,8. Hmmm,
|
|
you have a type 3 screen which is only 320 pixels wide and I think that is the
|
|
problem. Try making the block a bit smaller?
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18379 S12/OS9/68000 (OSK)
|
|
04-Jul-93 03:24:16
|
|
Sb: #18377-#c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob, I maybe should have used some more remarks in the test program.
|
|
I'm drawing a box with the upper left corner at
|
|
10,10 these are the horizontal & vertical pixel locations, so I use:
|
|
SetDPtr(Wpath, 10, 10);
|
|
Now the BOX function wants the lower right corner info, it uses the
|
|
current draw position for the upper left corner, so now I use:
|
|
Box(Wpath, 33, 17);
|
|
|
|
The GET function only needs the upper left corner h & v, which would be
|
|
10,10 . You don't give GET the lower right info, you give it the width
|
|
and height in pixels. In this case (33-10)+1= 24 and (17-10)+1= 8, these
|
|
are what are given to Get.
|
|
GET(Wpath,10,10,24,8);
|
|
|
|
So these boxes are 24 pixels(actually 48) wide, and 8 pixels high, and
|
|
using a step of 26 in the loop there should be 1 blank pixel between the
|
|
boxes. The boxes would actually be 48 pixels by 8 pixels, with 2 pixels
|
|
between the boxes, because even though I'm in a 320 pixel wide screen,
|
|
you still have to calculate pixel width as if you were in a 640 wide
|
|
screen. A single POINT on a 320 screen would be 2 pixels wide, 1 high.
|
|
|
|
Did you try remarking out the fill ? That really shows something is wrong.
|
|
|
|
larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18383 S12/OS9/68000 (OSK)
|
|
04-Jul-93 20:49:18
|
|
Sb: #18379-#c GET/PUT
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Larry, I've not done the math on the get/put stuff. However, if memory serves,
|
|
setting lset to 2 enables ORing the data. Leaving it at default means that the
|
|
PUTs overlay the existing data. Could it be that there is a problem with the
|
|
get expanding to a full-byte boundary or something? Have you fooled around with
|
|
the GETs to try for a smaller area to see what happens?
|
|
|
|
Interesting...I assumed that successive puts were destroying the right edge of
|
|
the early ones. However, when I put in a 'wait' routine after the PUTs I see
|
|
that the right edge isn't being PUT at all. Guess we'll have to hammer at Kevin
|
|
to get an answer to this one.
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18384 S12/OS9/68000 (OSK)
|
|
05-Jul-93 01:40:04
|
|
Sb: #18383-#c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob, I have tried moving the drawn box to location 9, which would be the first
|
|
bit of byte two, and then GETting the box from there, but with the same
|
|
results. I just thought, what I didn't try was drawing the box, starting at
|
|
location 16, which would be the first bit of byte 3. Maybe its a 16 bit
|
|
alignment problem, not an 8.
|
|
What is strange is by using LSET(path,2), the box is put on the screen
|
|
correctly, so I would assume that the correct data is in the GET/PUT buffer.
|
|
It is when the buffer data is placed on the screen, the problem shows up.
|
|
Right now I'm kind of working around the problem. I leave LSet at 0 until its
|
|
time to put that grid on the screen, then I set LSet to 2, place grid, and then
|
|
reset LSet back to 0. This works ok for now, I'll have to wait and see if the
|
|
bug shows up again in this program I'm writing.
|
|
|
|
larry
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18388 S12/OS9/68000 (OSK)
|
|
05-Jul-93 22:45:58
|
|
Sb: #18384-#c GET/PUT
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: LARRY OLSON 72227,3467 (X)
|
|
|
|
Since some of the PUTs are working okay, I suspect the problem is not with the
|
|
GET...I recall Kevin mentioning a problem with 16 bit alignment when I was
|
|
having some problems...but that seemed to get fixed. Have you tried seeing what
|
|
happens in a type 0 screen?
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18389 S12/OS9/68000 (OSK)
|
|
06-Jul-93 00:37:38
|
|
Sb: #18388-c GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
I havn't tried other screen types, to see if this crops up. I can say that
|
|
I'm sure the problem is in Kwindows, and not CGFX.l, because the same thing
|
|
showed up when I tried at first to just convert this program from CoCo3 Basic09
|
|
to the MM1 using BGFX. When I ran into that alignment problem plus not being
|
|
able to read the Mouse on any windows that the program opens, I decided to
|
|
convert the Basic09 to C.
|
|
larry
|
|
|
|
#: 18371 S12/OS9/68000 (OSK)
|
|
02-Jul-93 02:05:15
|
|
Sb: get/put problems
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: all
|
|
|
|
/* GET/PUT block test */
|
|
|
|
/* This is a test routine, written to show the */
|
|
/* problem that cropped up with PUTting a GET block. */
|
|
|
|
#include <stdio.h>
|
|
#include <errno.h>
|
|
|
|
#define STDIN 0
|
|
#define STDOUT 1
|
|
#define STDERR 2
|
|
|
|
main()
|
|
{
|
|
|
|
int P_id, Wpath, xx, yy, chrcnt ;
|
|
char response;
|
|
|
|
P_id = getpid();
|
|
|
|
Wpath = open("/w",3);
|
|
DWSet(Wpath,3,0,0,40,26,7,0,0);
|
|
|
|
Palette(Wpath,7,0,140,170); /* Set color to med. blue */
|
|
|
|
Clear(Wpath);
|
|
CurOff(Wpath);
|
|
Select(Wpath);
|
|
|
|
SetDPtr(Wpath,10,10);
|
|
Box(Wpath,33,17); /* Draw box */
|
|
SetDPtr(Wpath, 12,12);
|
|
|
|
/* Remark this out to see problem clearer */
|
|
FFill(Wpath);
|
|
|
|
GetBlk(Wpath,P_id,1,10,10,24,8);
|
|
|
|
Clear(Wpath);
|
|
CWArea(Wpath,3,2,37,7);
|
|
writeln(Wpath," This example is with LSET(path,0)\n",35);
|
|
writeln(Wpath," notice alternating wide gaps.\n",32);
|
|
writeln(Wpath," To really see the problem, remark\n",35);
|
|
writeln(Wpath,"out the FFill(Wpath) function call.\n",36);
|
|
CWArea(Wpath,0,0,40,26);
|
|
|
|
/* LSet is not being called, I assume default LSET is 0 */
|
|
|
|
for (xx=60; xx <= 554; xx += 26) {
|
|
for (yy = 70; yy <= 151; yy += 9) {
|
|
PutBlk(Wpath,P_id,1,xx,yy);
|
|
}
|
|
}
|
|
|
|
CurXY(Wpath,9,23);
|
|
writeln(Wpath,"Press key to continue\n",22);
|
|
chrcnt = (read(Wpath, &response, 1));
|
|
|
|
Clear(Wpath);
|
|
CWArea(Wpath,3,3,36,5);
|
|
writeln(Wpath," This example is with LSET(path,2)\n",35);
|
|
writeln(Wpath,"notice, no alternating wide gaps.\n",34);
|
|
CWArea(Wpath,0,0,40,26);
|
|
|
|
LSet(Wpath, 2);
|
|
|
|
for (xx=60; xx <= 554; xx += 26) {
|
|
for (yy = 70; yy <= 151; yy += 9) {
|
|
PutBlk(Wpath,P_id,1,xx,yy);
|
|
}
|
|
}
|
|
|
|
CurXY(Wpath,9,23);
|
|
writeln(Wpath,"Press key to continue\n",22);
|
|
chrcnt = (read(Wpath, &response, 1));
|
|
|
|
Select(0);
|
|
|
|
KilBuf(Wpath, P_id, 1);
|
|
|
|
DWEnd(Wpath);
|
|
close(Wpath);
|
|
|
|
exit(0);
|
|
}
|
|
|
|
#: 18374 S12/OS9/68000 (OSK)
|
|
03-Jul-93 00:52:42
|
|
Sb: OS 2 upgrade
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: all
|
|
|
|
Referring to message #18373, here is a chance to really put one over for
|
|
OS9/OSK. It appears these people think OS9 is an advanced version of OS 2. When
|
|
I read that sentence back, I find I have to agree<g>.
|
|
Some creative writer could do a great article for this magazine, telling of
|
|
all the advanced features in OS9 compaired to OS 2. Then in the last paragraph
|
|
of the article they would mention that OS9 in available from Microware not
|
|
Microsoft.
|
|
|
|
#: 18393 S12/OS9/68000 (OSK)
|
|
06-Jul-93 19:04:49
|
|
Sb: #Kwindows
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: All
|
|
|
|
Just made an interesting discovery working with kwindows...and it probably
|
|
explains why some gfx programs return you to the original window when they exit
|
|
and others don't. The following section of code ends the program in a 'random'
|
|
window:
|
|
|
|
close(path); /* close the display window */
|
|
Select(0); /* select the original window */
|
|
|
|
However, reversing the order of the these calls returns the proper closing
|
|
window. Guess kwindows gets confused when the display screen is deselected or
|
|
something. Hope this helps someone.
|
|
|
|
There are 2 Replies.
|
|
|
|
#: 18398 S12/OS9/68000 (OSK)
|
|
07-Jul-93 18:02:12
|
|
Sb: #18393-#Kwindows
|
|
Fm: Zack Sessions 71532,1555
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
>
|
|
> close(path); /* close the display window */
|
|
> Select(0); /* select the original window */
|
|
>
|
|
> However, reversing the order of the these calls returns the proper closing
|
|
> window. Guess kwindows gets confused when the display screen is deselected
|
|
or
|
|
> something. Hope this helps someone.
|
|
|
|
This may be a legacy from Level 2. Seems there was some "bug" in Level 2 which
|
|
*required* you to select the original window's standard input path before
|
|
closing (after DWEnding) the application window for you to properly select back
|
|
to the original window.
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18400 S12/OS9/68000 (OSK)
|
|
07-Jul-93 23:34:21
|
|
Sb: #18398-#Kwindows
|
|
Fm: Kevin Darling 76703,4227
|
|
To: Zack Sessions 71532,1555 (X)
|
|
|
|
Hi guys! Yup, it (Select, then Close) is a L-II legacy... but it's there for a
|
|
purpose.
|
|
|
|
The reason you have to select the original (or any other) window *before*
|
|
closing the current window path, is that otherwise WindIO would have no way of
|
|
checking to see if your process has permission to flip windows.
|
|
|
|
In other words, if your program DOES have a path to the currently displayed
|
|
window, then we know that the computer user was looking at your program's
|
|
window on purpose, and thus your program can flip windows without surprising
|
|
the user.
|
|
|
|
But if your program DOESN'T have a path to the currently displayed window, then
|
|
most likely the user isn't using your program at that moment, and it would be
|
|
(to say the least) inappropriate for WindIO to allow window flipping. So what
|
|
happens is that the window select does not take place, and it's actually a
|
|
later DWEnd (automatic or on purpose) which causes the flip you see to a
|
|
previous (ie: "random") screen.
|
|
|
|
The "wrong" method (Close, then Select) is also handy, btw. If you select a
|
|
new window and then fork off a subprogram in it, then by closing the new path
|
|
before reselecting the original window, the new subprogram window stays as the
|
|
displayed one. Very handy for graphic-shells, etc.
|
|
|
|
best - kevin
|
|
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18405 S12/OS9/68000 (OSK)
|
|
09-Jul-93 00:07:51
|
|
Sb: #18400-Kwindows
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Kevin Darling 76703,4227 (X)
|
|
|
|
Hey...a message from the guru! How nice to hear from you. Hope you've not
|
|
forgotten about some of those promised fixes, etc.
|
|
|
|
#: 18406 S12/OS9/68000 (OSK)
|
|
09-Jul-93 04:03:22
|
|
Sb: #18393-Kwindows
|
|
Fm: Mark Griffith 76070,41
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob,
|
|
|
|
> Just made an interesting discovery working with kwindows...and it
|
|
> probably explains why some gfx programs return you to the original window
|
|
> when they exit and others don't.
|
|
|
|
Yeah, selecting the current window (actually, stdin) before closing a path to
|
|
another window has always been the method used to return to the parent window.
|
|
This was the same in Level II CoCo windows. I pointed this out in my skeleton
|
|
program a few years ago.
|
|
|
|
Glad to see someone else has 'discovered' this (grin).
|
|
|
|
/************* /\/\ark ************/
|
|
|
|
(uploaded with InfoXpress Ver 1.0)
|
|
|
|
#: 18394 S12/OS9/68000 (OSK)
|
|
06-Jul-93 21:22:29
|
|
Sb: #Cribbage+Kwindows
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: All
|
|
|
|
Okay, MM/1ers. I've just finished off my cribbage game (the same one I sell for
|
|
the coco) so that it runs on the mm/1. I know I'm not the only person who wants
|
|
to play crib on my computer....so I'm asking for some help: For now I've not
|
|
decided if (1) I should make this into a commercial product (rather tough to
|
|
market considering the limited number of kwindows users out there); or (2) if I
|
|
should post it as freeware; or (3) if I should just post it and forget all
|
|
about it. However, I figure that my time should be worth something (and product
|
|
sales do support my computer hobby) so I don't like (3); and I've heard that
|
|
very, very, few (none?) send in freeware registration fees; and I've already
|
|
commented on (1). So...what do you guys think I should do with the program. If
|
|
no comments ensue, I'll just keep it for myself. BTW, I'm only on this service
|
|
so if someone wants to repost this elsewhere, please feel free to do so.
|
|
|
|
There are 3 Replies.
|
|
|
|
#: 18397 S12/OS9/68000 (OSK)
|
|
07-Jul-93 17:31:58
|
|
Sb: #18394-Cribbage+Kwindows
|
|
Fm: Steve Wegert 76703,4255
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob,
|
|
|
|
Sounds as if you've answered your own question.
|
|
|
|
If it were me, I'd post it as Freeware and understand you're not gonna get rich
|
|
writing software for a limited market machine.
|
|
|
|
Just my two cents .... :-)
|
|
|
|
|
|
|
|
*- Steve -*
|
|
|
|
|
|
#: 18399 S12/OS9/68000 (OSK)
|
|
07-Jul-93 18:02:25
|
|
Sb: #18394-Cribbage+Kwindows
|
|
Fm: Zack Sessions 71532,1555
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob, I'd try to sell it first. Why not? Whatever you get back is gravy, and I
|
|
have found that the MM/1 user market is willing to shell out a few bucks for
|
|
some decent software, be it games or whatever. Judging on my guess of how many
|
|
people own an MM/1 and how many people use Level 2 on a CoCo3, a higher
|
|
percentage of MM/1 owners have bought my game programs than Level 2 owners
|
|
have. One thing though, MM/1 owners tend to prefer to buy in person like at
|
|
fests.
|
|
|
|
Later, post it as shareware, not really caring in any money comes in and if any
|
|
does, more gravy!
|
|
|
|
best of luck!
|
|
|
|
------------------------------------
|
|
Zack C Sessions
|
|
ColorSystems
|
|
|
|
via InfoXpress/OSK by Bill Dickhaus
|
|
|
|
#: 18407 S12/OS9/68000 (OSK)
|
|
09-Jul-93 04:03:31
|
|
Sb: #18394-Cribbage+Kwindows
|
|
Fm: Mark Griffith 76070,41
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Bob,
|
|
|
|
> Okay, MM/1ers. I've just finished off my cribbage game (the same one I
|
|
> sell for the coco) so that it runs on the mm/1. I know I'm not the only
|
|
> person who wants to play crib on my computer....so I'm asking for some
|
|
> help
|
|
|
|
It's really your choice. There are enough MM/1 owners out there to make a few
|
|
bucks off this. I'm having good success selling the stuff I have.
|
|
|
|
|
|
/************* /\/\ark ************/
|
|
|
|
(uploaded with InfoXpress Ver 1.0)
|
|
|
|
#: 18401 S12/OS9/68000 (OSK)
|
|
08-Jul-93 01:49:25
|
|
Sb: GET/PUT
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Kevin Darling 76703,4227 (X)
|
|
|
|
Kevin, did you happen to catch the discussion Bob and I were having about
|
|
problems with GET/PUT in windio #48 ?
|
|
If you could take a look at the thread, starting at message# 18359, and see
|
|
what you think is wrong, and what can be done to fix it.
|
|
I also uploaded a C test program, message #18371, that shows where the
|
|
problem crops up.
|
|
I was able to work around the problem, by setting LSet to something other
|
|
than zero, until yesterday. I'm PUTting a small dark blue square to the screen,
|
|
the size is 12x5 pixels, and the alignment problem showed up again, but when I
|
|
try setting LSet to something other than zero, I lose my blue square. The
|
|
closest I can get is by using LSet(path, 2), this gives me the complete square,
|
|
but it is green.
|
|
|
|
larry
|
|
|
|
#: 18402 S12/OS9/68000 (OSK)
|
|
08-Jul-93 01:56:15
|
|
Sb: BGFX-MOUSE
|
|
Fm: LARRY OLSON 72227,3467
|
|
To: Kevin Darling 76703 4227
|
|
|
|
Kevin, While I'm thinking about it, has anyone mentioned having problems with
|
|
reading the Mouse with BGFX ?
|
|
The MOUSE function works great, as long as you stay in the original window,
|
|
but if I open another window and select it, the MOUSE function returns nothing.
|
|
The window was opened and selected with no problem because I'm getting output
|
|
from it, but MOUSE returns no values. Valid stays at 0.
|
|
|
|
larry
|
|
|
|
#: 18408 S12/OS9/68000 (OSK)
|
|
09-Jul-93 19:33:25
|
|
Sb: #GNU-C
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: All
|
|
|
|
Does anyone know if it is possible to set the directory for .r files using the
|
|
GNU-C compiler. Using microware Make (maybe this is the problem) all command
|
|
lines have a '.r=' command in them (which gcc reports as an unknown flag, but
|
|
ignores). I like to have all my .r files in their own directory, which I do
|
|
with the microware compiler by setting $RELS in my makefile. There must be a
|
|
way to do this with GNU!!!! HELP!!!
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18409 S12/OS9/68000 (OSK)
|
|
09-Jul-93 20:50:18
|
|
Sb: #18408-#GNU-C
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Hi Bob, You have to make a new 'rule' for make. Here's the lines to add
|
|
before any command lines.
|
|
|
|
c.r:
|
|
$(CC) -c $(CFLAGS) -o $(RDIR)/$*.r $*.c
|
|
|
|
This will tell GCC to (-c) compile to .r and (-o) put the RFILE in the RDIR.
|
|
|
|
Hope this helps.
|
|
|
|
- Mike -
|
|
|
|
BTW: Did you get a chance to play with the newer FM I sent ya?
|
|
|
|
There is 1 Reply.
|
|
|
|
#: 18410 S12/OS9/68000 (OSK)
|
|
10-Jul-93 13:57:28
|
|
Sb: #18409-GNU-C
|
|
Fm: Bob van der Poel 76510,2203
|
|
To: Mike Haaland 72300,1433
|
|
|
|
I didn't realize that you could redefine make rules...thanks. BTW, the line
|
|
isn't "c.r:", it is ".c.r:"... also, if the new rule contains any macros, like
|
|
$(CC), you have to define the macros first. Oh well, it works! Thanks. Too bad
|
|
that MW didn't document this.
|
|
|
|
Yes, I have played with FM. Getting real good. I do have a problem with it
|
|
though...and that is the choice of keys. (I'm doing this as a public message so
|
|
that others can contribute...yours is not the only program with similar
|
|
problems, I have a similar problem with EPHEM). On my terminal the left arrow
|
|
key is defined as a CTRL-D (this is in the termcap). So, using the arrow keys
|
|
works fine. However, FM expects ctrl-d to have its own binding (in EPHEM this
|
|
is the exit key...which means I have to reset one machine to get out of the
|
|
program). I suggest that programs should check for duplicate keys like this and
|
|
then remap things if necessary. With a small command set like FM this shouldn't
|
|
be too big a deal. Guess the other solution would be to have a separate file
|
|
with the keybindings in it (that's what I ended up doing in Ved, but it is a
|
|
lot of work for a small program). I guess the only other solution is to only
|
|
use keys which have been explicitly defined in a termcap entry...but that might
|
|
leave too many functions undefined. Of course, if I finished off my Kn defs in
|
|
my termcap entries for the function keys that would solve the problem too...but
|
|
I've seen very few (none?) complete termcap entries. Heck, a lot of termcap
|
|
files are just plain wrong.
|
|
|
|
Oh, here's another interesting tidbit...one of the arrow keys on my terminal is
|
|
defined as a CTRL-W (xon!). Makes for real interesting interactive sessions
|
|
when the serial line is set for xon/off handshaking.
|
|
|
|
Also, the screen updates for FM are now very fast. I assume this is the new
|
|
curses library?
|
|
|
|
#: 18349 S14/misc/info/Soapbox
|
|
27-Jun-93 01:41:59
|
|
Sb: #18344-Good Sector Editor
|
|
Fm: Mike Haaland 72300,1433
|
|
To: Bob van der Poel 76510,2203 (X)
|
|
|
|
Ok the ascii side has been fixed, and can do <Alt>key entry now. Fixed the /dd
|
|
problem, I was opening directories in non-sharable mode, which was keeping the
|
|
terminfo routines from getting the TERM entry. &:-o Now only files are opened
|
|
with non-share set. dEd doesn't appear to use the non-share bit at all. <Hmmm>
|
|
|
|
The slow screen refreshes are the fault of the curses.l I'm using. It's the
|
|
version that uses terminfo. The EFFO version is supposed to be much faster and
|
|
uses termcap instead of terminfo. (I'm grabbing it now and will see if it
|
|
speeds things up).
|
|
|
|
Yeah, the edit-mode-all-the-time took a few time to get used to, but before any
|
|
writes are done, it always prompts. ESC will undo your changes before you
|
|
write to disk too. I'm trying to decide what to load the MM/1 Fn keys with, so
|
|
you won't have to use Cntl keys.
|
|
|
|
I thought about that too, but it seems like major work to get FM to scroll and
|
|
still keep you informed of any changes you've made, etc.
|
|
|
|
|
|
Press <CR> !>$f
|
|
The OS-9 Forum+ Read Menu
|
|
|
|
Read
|
|
1 [NEW] messages
|
|
2 Message NUMBER
|
|
3 WAITING messages for you (0)
|
|
|
|
Search [new] messages
|
|
4 FROM (Sender)
|
|
5 SUBJECT
|
|
6 TO (Recipient)
|
|
|
|
Enter choice !> |