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

1258 lines
40 KiB
Plaintext
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
#: 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 !>