Sozobug 1.33i

Sozobug 1.33i

Post by cse0.. » Wed, 22 Jan 1992 22:59:35



   Would somebody else please try a particular call in Sozobon 1.33i?
The offending call is vqf_attributes, and I'm getting back trash
for the fourth array parameter.  What's more, it crashes my TT really
bad.  Using vdicall, I can code it up by hand, but...geez.  Is it me, or
is it Memorex?
--
?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?!?


?   / | \      the above address does not work - please use it!
 
 
 

Sozobug 1.33i

Post by Steve Yelvingt » Fri, 24 Jan 1992 03:17:36




 >    Would somebody else please try a particular call in Sozobon 1.33i?
 > The offending call is vqf_attributes, and I'm getting back trash
 > for the fourth array parameter.  What's more, it crashes my TT really
 > bad.  Using vdicall, I can code it up by hand, but...geez.  Is it me, or
 > is it Memorex?

It's probably a bug in VDIFAST.A; not all of the VDI functions have been
extensively tested. It would be great if you could mail me a little program
demonstrating how you called the function (to make sure that we're all
working off the same function description!) I can forward it to the author.

Also, could you post your rewrite that uses vdicall? That way everybody can
use your code while waiting for Ian to fix the GEMFAST bug.

 --

 Note: Mail to the .mn.org domain has been failing for about a month.
       If your mail bounces, try cs.umn.edu!thelake!steve.
       It's probably another side effect of the Super Bowl.
       (I'm praying for a blizzard on Super Sunday.)

 
 
 

Sozobug 1.33i

Post by davi.. » Thu, 23 Jan 1992 23:31:27



> ...not all of the VDI functions have been extensively tested.

Just a note to let folks know that there is at -least- a problem with one of
the example programs that comes with the 1.33i release and STe computers.

I installed the 1.33i release on an STe last night, during the local MAST+
programmers meeting.  We then 'tested' the program by clicking on the makefile
in the example programs folder.  It compiled and ran the test programs without
a  hitch.  However, the 'minicolr' pallette changer doesn't work with STe
machines.  I didn't go through the code enough to learn whether it was a
special call or not; I assume that the program makes assumptions about the
color pallette information (which is 4 bits for the STe vs. 3 bits for the ST).

It -did- produce an interesting Moire pattern before locking up though. :)

--


"The most important fact about Spaceship Earth: An instruction book didn't come
with it." -- R. Buckminster Fuller

 
 
 

Sozobug 1.33i

Post by Bob Brig » Fri, 24 Jan 1992 11:01:26



>Just a note to let folks know that there is at -least- a problem with one of
>the example programs that comes with the 1.33i release and STe computers.

>I installed the 1.33i release on an STe last night, during the local MAST+
>programmers meeting.  We then 'tested' the program by clicking on the makefile
>in the example programs folder.  It compiled and ran the test programs without
>a  hitch.  However, the 'minicolr' pallette changer doesn't work with STe
>machines.  I didn't go through the code enough to learn whether it was a
>special call or not; I assume that the program makes assumptions about the
>color pallette information (which is 4 bits for the STe vs. 3 bits for the ST).

There are also problems with minicolr that don't have anything to do
with whether it's running on an STe.  When run as a prg, my mouse
locks up on exit and I have to reboot.  This occurs on both of my
machines, a 520ST/TOS1.2 and 1040ST/TOS1.0.  Minicolr seems to work
OK on both machines when it's actually running, though.

BBB
--

Dept. of Philosophy       |    FAX:    (204) 261-0021
University of Manitoba    |    Voice:  (204) 474-9105
Winnipeg, Man  R3T 2N2    |

 
 
 

Sozobug 1.33i

Post by Harry Karayiann » Sat, 25 Jan 1992 08:59:34




>>Just a note to let folks know that there is at -least- a problem with one of
>>the example programs that comes with the 1.33i release and STe computers.

>>I installed the 1.33i release on an STe last night, during the local MAST+
>>programmers meeting.  We then 'tested' the program by clicking on the makefile
>>in the example programs folder.  It compiled and ran the test programs without
>>a  hitch.  However, the 'minicolr' pallette changer doesn't work with STe
>>machines.  I didn't go through the code enough to learn whether it was a
>>special call or not; I assume that the program makes assumptions about the
>>color pallette information (which is 4 bits for the STe vs. 3 bits for the ST).

>There are also problems with minicolr that don't have anything to do
>with whether it's running on an STe.  When run as a prg, my mouse
>locks up on exit and I have to reboot.  This occurs on both of my
>machines, a 520ST/TOS1.2 and 1040ST/TOS1.0.  Minicolr seems to work
>OK on both machines when it's actually running, though.

  Although I might be totally wrong here, I suspect (guess) the problem
is that there is a call to wind_update(END_UPDATE) missing from the source
code...  Take a look at the code and make sure that for every call to
wind_update(BEG_UPDATE) there's a corresponding call to
wind_update(END_UPDATE).
  However, if the code contains #ifdef directives the above search may turn
out to be rather tedious, 'cause you have to make sure that every pair of
calls to wind_update() lies (sp?) in the same context.

  Note that I haven't looked at the code of the program so I am just
_suggesting_ a possible cause of the problem.

>BBB
>--

>Dept. of Philosophy       |    FAX:    (204) 261-0021
>University of Manitoba    |    Voice:  (204) 474-9105
>Winnipeg, Man  R3T 2N2    |

=============================================================================
Author of ATZENTA2         Harry Karayiannis           ________E-Mail________
                    15 N.Beacon, #316   Boston Univ.  |INTERnet:

** /||\ MegaST **   U.S.A.                            |BITnet:

                                                       ----------------------
 
 
 

Sozobug 1.33i

Post by cse0.. » Sat, 25 Jan 1992 00:04:04


>Steve-o at The Lake writes:

>>    Would somebody else please try a particular call in Sozobon 1.33i?
> It's probably a bug in VDIFAST.A; not all of the VDI functions have been
> extensively tested.
> Also, could you post your rewrite that uses vdicall? That way everybody can
> use your code while waiting for Ian to fix the GEMFAST bug.
>  --
>  Steve Yelvington

Because S. Yelvington begged for one of my famous bug fixes to be
posted to the net, I have graciously obliged.  :-) :-)

----Sozobon 1.33i Alleged Bug work-around.

/* Clear a given portion of a window.  No error checking done. */
/* Inputs:  window handle, VDI-style coordinate quad           */
/* Outputs: a nicer looking display, hopefully                 */
/* This code is old-style (pre-ANSI) C.                        */
wipe_win(winhan,r)
int winhan, r[4];
{
    int settings[4], temp[4];

    temp[0]=r[0];temp[1]=r[1];   /* I don't know why she swallowed */
    temp[2]=r[2];temp[3]=r[3];   /* the fly.  I guess she'll die.  */                  

/*  vqf_attributes(winhan, settings);   does not work!            */
/*  So, we use.... (for those keeping score, the next 7 lines are */
/*      the actual workaround)   */  
    contrl[0]=37;
    contrl[1]=contrl[3]=0;
    contrl[6]=winhan;
    vdicall(contrl, intin, ptsin, intout, ptsout);

    settings[0] = intout[0];  settings[1] = intout[1];
    settings[2] = intout[2];  settings[3] = intout[3];
/* Whew.  What a pain.  (contrl, intin, etc. were previously  */
/* set up as globals.  See your friendly local VDI manual.)   */

    vsf_color(winhan, 0);               /* set fill color   */
    vsf_interior(winhan, IS_SOLID);     /* set fill pattern */
    vr_recfl(winhan, temp);             /* phasers on kill  */
    vsf_interior(winhan, settings[0]);  /* reset f pattern  */
    vsf_color(winhan, settings[1]);     /*     and color    */

Quote:}

/* Ok, ok.  int contrl[12], intin[128], ptsin[128],     */
/*              intout[128], ptsout[128];               */
/* Flame off, huh?  I know it's not very clean, but...  */

                       Bob "What bug?" Schulze

 
 
 

Sozobug 1.33i

Post by Mark Lehma » Tue, 28 Jan 1992 13:01:47


I was not able to get Sozobon 1.33i "Heat and Serve" to install on my
1040ST with TOS 1.0 and 2.5MG.  When I get part way through the
installation the "-" minus signs turn into a series of random looking
characters then I get two bombs.  After the two bombs, a error message
from the Heat and Serve installtion program says that the "CC.PRG" program
cannot be found.

Here is what I did to attempt to fix the problem:

1) Downloaded the UUENCODED files again
2) UUDECODED the files again
3) ran the zoo 2.1 integrity check (it passed)
4) un-arced the zoo file again
5) tries the install program again (not luck)
6) checked my disk for problems
7) re-fromated my 60Mg hard disk and mapped out 6 bad sectors
8) did steps 1-6 again and got the same error

Here is what I need to know?

Is the "Heat and Serve" intended to work only with a certain level of
TOS?  Has anyone installed it succesfully on a 1040ST with TOS 1.0 and
2.5MG or less of memory?  If so, will you send the SOZO133I.ZOO file to
the atari archive?

Thanks a bunch (especially to Steve Yellington, who always seems to have
useful comments about everything)
Mark Lehmann
tamuts.tamu.edu!n160ao

 
 
 

Sozobug 1.33i

Post by Ben Gilbe » Tue, 28 Jan 1992 16:23:49



>I was not able to get Sozobon 1.33i "Heat and Serve" to install on my
>1040ST with TOS 1.0 and 2.5MG.  When I get part way through the
> .
> .
> .
>Is the "Heat and Serve" intended to work only with a certain level of
>TOS?  Has anyone installed it succesfully on a 1040ST with TOS 1.0 and
>2.5MG or less of memory?  If so, will you send the SOZO133I.ZOO file to
>the atari archive?

>Thanks a bunch (especially to Steve Yellington, who always seems to have
>useful comments about everything)
>Mark Lehmann
>tamuts.tamu.edu!n160ao

I got the heat-n-serve to install on my 520STFM with 2.5 megs and TOS 1.0
 I unzoo'd the file and it went to six files I believee, the install.prg,
install.doc, gemenv.prg, and three .pdf (packed) files...  Then running
the install.prg as mentioned in the .doc, it set up my directories and
unpacked the stuff for me...  I found that to have enough space, I told
it to unpack the docs onto one disk and everything else to another (all
this in the install program), this should work...  (also I was using an
826K disk, but I'm pretty sure it would even work on a 720K one, as long
as the docs are on a separate disk).  Hope this helps...


 
 
 

Sozobug 1.33i

Post by davi.. » Tue, 28 Jan 1992 19:53:23



> I was not able to get Sozobon 1.33i "Heat and Serve" to install on my
> 1040ST with TOS 1.0 and 2.5MG.  When I get part way through the
> installation the "-" minus signs turn into a series of random looking
> characters then I get two bombs.  After the two bombs, a error message
> from the Heat and Serve installtion program says that the "CC.PRG" program
> cannot be found.

I had a similar problem.  Of course, I had multiple AUTO programs and DC
Desktop running, along with QuickST and a few other things...

My solution was to go to a bare-bones DeskTop (ie, the only AUTO programs
running were FOLDRxxx.PRG and the TOS 1.4 'fix' programs).  Apparently, the
LHarc program used during the installation process does a few flips and giggles
if you're running non-compatible TSRs.

--


"The most important fact about Spaceship Earth: An instruction book didn't come
with it." -- R. Buckminster Fuller

 
 
 

Sozobug 1.33i

Post by Steve Yelvingt » Wed, 29 Jan 1992 01:44:40




 > I was not able to get Sozobon 1.33i "Heat and Serve" to install on my
 > 1040ST with TOS 1.0 and 2.5MG.  When I get part way through the
 > installation the "-" minus signs turn into a series of random looking
 > characters then I get two bombs.  After the two bombs, a error message
 > from the Heat and Serve installtion program says that the "CC.PRG" program
 > cannot be found.

I don't know what's causing that problem. The .PDF files are self-extracting
LZH archives. The "-" sign is a progress indicator that is supposed to turn
into "*" as the archive is melted. All INSTALL.PRG does is load the .PDF
files, change to the appropriate drive, create the directories, and execute
the .PDF program.

I'll run some tests on this as soon as I get a power supply for my TOS 1.0
machine, but I note that Ben Gilbert installed it on his (on floppies)
without trouble, so I have to wonder if there might be something in your
machine that's stepping on memory -- a bad chip, a wild desk accessory,
etc.

Meanwhile, you can install everything manually by creating the directories
and then running LHARC (any recent Questor version) to unpack the .PDF
files. You then should run INSTALL again, skipping the steps that unpack
the .PDF files, so that it can install GEMENV.PRG and update your DESKTOP.INF
file for you.

 --

 Note: Mail to the .mn.org domain has been failing for about a month.
       If your mail bounces, try cs.umn.edu!thelake!steve.

 
 
 

Sozobug 1.33i

Post by David Broo » Wed, 29 Jan 1992 05:24:15


|> I'll run some tests on this as soon as I get a power supply for my TOS 1.0
|> machine, but I note that Ben Gilbert installed it on his (on floppies)
|> without trouble...

I had no trouble on a 520, TOS 1.0, double-sided floppy.  Had to de-install
in pieces, though; I don't think there's room on one floppy for all the
.PDF files and their progeny.
--

Systems Engineering, OSF                uunet!osf.org!dbrooks
For thy sweet love remember'd such wealth brings...

 
 
 

Sozobug 1.33i

Post by Mohammad A. Rah » Thu, 30 Jan 1992 02:21:50



>I was not able to get Sozobon 1.33i "Heat and Serve" to install on my
>1040ST with TOS 1.0 and 2.5MG.  When I get part way through the
> .
> .
> .
>Is the "Heat and Serve" intended to work only with a certain level of
>TOS?  Has anyone installed it succesfully on a 1040ST with TOS 1.0 and
>2.5MG or less of memory?  If so, will you send the SOZO133I.ZOO file to
>the atari archive?

I installed it on my 520STFM with TOS 1.0, 2 floppies & 1 Meg memory. The
installation procedure really went very smoothly & I did not have any problem.
However, one thing I noticed was that the example programs after compilation
& run occassionally freezes the machine. The mouse works ok, but none of the
menus or buttons (in the example program that showes the GEM capability) can
be activated. Could be that this program (& MINCOLOR as well) is having a
compatibilty problem with my AUTO programs or DAs. I have to check on that.

The GEMENV.PRG that came with this package is quite large & took comparatively
large amount of memory. I substituted this with ENVIRON.PRG (from the showdvi
package). The latter is much smaller in size & saved me about 30k of memory,
when checked with FREERAM DA.

Quote:>Thanks a bunch (especially to Steve Yellington, who always seems to have
>useful comments about everything)
>Mark Lehmann
>tamuts.tamu.edu!n160ao

Thanks a lot to Ian Lepore for giving us this version.


 
 
 

Sozobug 1.33i

Post by davi.. » Thu, 30 Jan 1992 23:38:02



> I had no trouble on a 520, TOS 1.0, double-sided floppy.  Had to de-install
> in pieces, though; I don't think there's room on one floppy for all the
> .PDF files and their progeny.

The 1.33i installation to double-sided floppy disks requires two disks.  The
first disk holds the binary distribution (ie the programs, the include files
and the libraries), the second disk holds the documentation and example
programs.  The documentation in the distribution tells you how to go about
doing this.

Incidentally, if you put source code on a RAM disk (and remember to back it off
to floppy afterwards!), the program works fine on a 1 meg system with a single
floppy drive.

--


"The most important fact about Spaceship Earth: An instruction book didn't come
with it." -- R. Buckminster Fuller

 
 
 

1. Toshiba 8x in NEC Powermate 486/33i

Does anyone know if the above combination is possible? I am trying to
add a 8x Toshiba CD-ROM and Yamaha sound card to my older NEC powermate
computer. The problem is that it will not recognize the CD-ROM unit at
all. I tried every combinations possible.

The only time I got it to read the CD-ROM was when I disconnected the
hard drive and booted on a floppy disk. The CD came up as C: drive.
Does the PC not register more than one drive? IS this a BIOS, MB jumper
problem. I don't have the manuals for the PC and NEC doesn't post
anything about older PCs.

Any experts out there have a solution.

Thanks
jeff tibben

2. opening web page using C++

3. Toshiba CD-ROM into a NECPowermat 486/33i

4. plextor cdr which software

5. Sozobon v1.33i -- current status

6. Umax Astra 4700/6400

7. Sozobon 1.33i Heat'n'Serve bugs

8. Sozobon v1.33i - fixed MINSTART.S acc startup source

9. Sozobon 1.33i

10. Sozobon 1.33i vs. Sozobon 2.0

11. memcpy bug (dLibs 1.2 / Sozobon 1.33i)

12. MiNT & Sozobon 1.33i `make'