jimomura@lsuc.on.ca (Jim Omura) (05/30/91)
I don't know what's going on here. After receiving the 26
uuencoded parts I tested the 'only_ste.lzh' file with 'fstlzh20'
and it passed. So I unpacked the files and it turns out to be
'msa.prg' and 'only_ste.msa'. Ok. So I ran the 'msa' program
and in theory I unpacked the disk. It turns out that on that
"huge" disk there were only a few files, none of which was all
that big. Is this some kind of joke? I think I could repackage
all the relevant files in a single LZH file of about 40K.
I've passed the disks on to a fellow who works at a store
that sells STEs and he's going to report back to me around the
end of the week. Has anybody finished testing this thing?
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomurajansteen@cwi.nl (Jan van der Steen) (05/30/91)
jimomura@lsuc.on.ca (Jim Omura) writes: > I don't know what's going on here. After receiving the 26 >uuencoded parts I tested the 'only_ste.lzh' file with 'fstlzh20' >and it passed. So I unpacked the files and it turns out to be >'msa.prg' and 'only_ste.msa'. Ok. So I ran the 'msa' program >and in theory I unpacked the disk. It turns out that on that >"huge" disk there were only a few files, none of which was all >that big. Is this some kind of joke? I think I could repackage >all the relevant files in a single LZH file of about 40K. Since it's a pity if anyone with an STe would miss this beautiful demo I'll explain in some more detail how to unpack it: 1. Transfer only_ste.lzh to your system 2. Unpack the archive using lharc This will give you two files: a. only_ste.msa b. msa.prg There is no documentation included for the msa.prg. Now execute msa.prg and press the disk-->file button. It will change to file-->disk. Insert an empty floppy in your disk drive and press the F:\FILENAME.MSA button to select the only_ste.msa file which you have unpacked previously. Finally press the DOIT button and the msa file will be unpacked to a full floppy disk image. As Jim Omura mentioned a listing of the files on A:\ will only show an auto folder and three or four other files. At this stage do a soft reset (!). After the intro screen has been build up hit space and while a message and credits story will flow over your screen you can select one out of two modes using arrow up or down. The top mode (sorry, I forgot the exact name) is the music demo. The bottom mode is a music sample editor (called Esion). If you select the editor you'll return to the desktop and you can execute the program esion.prg on A:\. Jan van der Steen PS. Amazing sounds and user interface. Beautiful! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jan van der Steen jansteen@cwi.nl Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
larserio@IFI.UIO.NO (LarsErikOsterud) (05/31/91)
The ONLY_STE disk is AUTO-BOOTING and contains PURE DATA for the AUTO-BOOTING DEMO. In addition ONE SMALL PART of the disk is a NORMAL DISK with a few program files - THIS IS NOT the demo. DO NOT use a virus killer on the disk as this will remove the autoboot and make it unusable.... Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ Osterud / larserio@ifi.uio.no / /___ / The norwegian ST __________/ ______________________/ ____/ / Klubben, user association
rjast1@unix.cis.pitt.edu (Robert J Anisko) (05/31/91)
In article <CMM.0.90.2.675623718.larserio@kvart.ifi.uio.no> larserio@ifi.uio.no writes: >The ONLY_STE disk is AUTO-BOOTING and contains PURE DATA for the AUTO-BOOTING >DEMO. In addition ONE SMALL PART of the disk is a NORMAL DISK with a few >program files - THIS IS NOT the demo. DO NOT use a virus killer on the disk >as this will remove the autoboot and make it unusable.... > > Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ > Osterud / larserio@ifi.uio.no / /___ / The norwegian ST For any users that might have been Atari 8-bit users at one time, the MSA (Magic Shadow Archiving) works in the same way as DISCOMM or Scrunch - it simply takes data from the whole disk (including boot sectors) and puts it into a file, so it can be transmitted via modem. Then when the file is received, you just reverse the process and unpack it to a full disk, boot and all. For some programs and demos, this is the only way to go about it (say an author doesn't want you messing with his/her data (by loading a file into an editor such as Edhack) - so he/she wipes out the directory and makes the program autobooting - kinda a method of file protection... Robert Anisko rjast1@cis.unix.pitt.edu
jimomura@lsuc.on.ca (Jim Omura) (05/31/91)
In article <134302@unix.cis.pitt.edu> rjast1@unix.cis.pitt.edu (Robert J Anisko) writes: >In article <CMM.0.90.2.675623718.larserio@kvart.ifi.uio.no> larserio@ifi.uio.no writes: ... > For any users that might have been Atari 8-bit users at one time, the >MSA (Magic Shadow Archiving) works in the same way as DISCOMM or Scrunch - >it simply takes data from the whole disk (including boot sectors) and >puts it into a file, so it can be transmitted via modem. Then when the >file is received, you just reverse the process and unpack it to a full >disk, boot and all. For some programs and demos, this is the only >way to go about it (say an author doesn't want you messing with his/her >data (by loading a file into an editor such as Edhack) - so he/she >wipes out the directory and makes the program autobooting - kinda >a method of file protection... Now that's getting down right, uh, not-very-intelligent. Anybody with enough knowledge to analyse an object code file probably has sufficient tools to read sectors anyway. For the rest of us who have no intention of playing with their object code they do us the great honour of create a situation where virus distribution can increase. All we need now is somebody forging a copy of this 'only_ste' demo kit with a virus in place of the original boot sector and dozens of STE owners are going to find themselves doubting the wisdom of their purchases. While we're on the topic of viruses, I was very impressed with the "finish" of VKiller. It got me to thinking about such programs. VKiller identifies ST boot sectors and where possible specifically identifies viruses. But even the warning about boot sectors is well done. I was just thinking that many of us use Atari ST's in "mixed environments" with MS-DOS machines and it would be helpful if VKiller identified MS-DOS boot sectors as well. I wouldn't go so far as to try and keep up with the MS-DOS virus situation completely, but just give a warning like this: "MS-DOS Executable boot sector found. If this disk was not supposed to have one, you might want to discuss this with whomever supplied the disk." That way you could alert an MS-DOS user that s/he might have a virus. > > Robert Anisko > rjast1@cis.unix.pitt.edu -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
mforget@ersys.edmonton.ab.ca (Michel Forget) (06/02/91)
jimomura@lsuc.on.ca (Jim Omura) writes: > > I don't know what's going on here. After receiving the 26 > uuencoded parts I tested the 'only_ste.lzh' file with 'fstlzh20' > and it passed. So I unpacked the files and it turns out to be > 'msa.prg' and 'only_ste.msa'. Ok. So I ran the 'msa' program > and in theory I unpacked the disk. It turns out that on that > "huge" disk there were only a few files, none of which was all > that big. Is this some kind of joke? I think I could repackage > all the relevant files in a single LZH file of about 40K. > > I've passed the disks on to a fellow who works at a store > that sells STEs and he's going to report back to me around the > end of the week. Has anybody finished testing this thing? The *VISIBLE* files may ammount to 40K, but the actual data on the disk may be far greater. I don't have an STe, so I can't check for sure. Have you ever bought a game and looked at the directory just to see what is there? Often, there is nothing, yet the game is still there. I don't know why things are like this, but they sometimes are. If a file is MSA'd, like the demo you mentioned, then it is a good indication that there is more to the demo than meets the eye. Many demo's do this. I suppose it is a form of protection. After all, would you want people to steal the stuff you worked so hard to create? << ---------------------------------- >> << ersys!mforget@nro.cs.athabascau.ca >> << mforget@ersys.edmonton.ab.ca >> << Michel Forget >> << ---------------------------------- >>
woodside@ttidca.TTI.COM (George Woodside) (06/03/91)
In article <1991May31.150318.20441@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: > While we're on the topic of viruses, I was very impressed with >the "finish" of VKiller. It got me to thinking about such programs. >VKiller identifies ST boot sectors and where possible specifically >identifies viruses. But even the warning about boot sectors is >well done. I was just thinking that many of us use Atari ST's in >"mixed environments" with MS-DOS machines and it would be helpful >if VKiller identified MS-DOS boot sectors as well. I wouldn't go >so far as to try and keep up with the MS-DOS virus situation completely, >but just give a warning like this: > >"MS-DOS Executable boot sector found. If this disk was not supposed >to have one, you might want to discuss this with whomever supplied >the disk." > > That way you could alert an MS-DOS user that s/he might have >a virus. Thank you. I put a lot of effort into the user interface. MS-DOS uses exactly the same technique to identify an executable boot sector as the ST. Well, actually, it's the other way around. GEMDOS was built to MS-DOS compatibility in that way. An MS-DOS executable boot sector will be identified by Vkiller as "executable", but as unrecognized. It would be extremely complex to attempt to look at the code in the boot sector, and attempt to determine if it were MS-DOS code or ST code. The vast majority of MS-DOS viruses, now, are of the link type, which infect files, rather than the boot sector. ST versions of these link viruses are now appearing in Europe infecting ST files. They will be appearing on this side of the Atlantic soon, I expect. I have revieved data on a couple of the ones captured in Europe, and am working on tools for the ST to combat them. -- * George R. Woodside - Citicorp/TTI - Santa Monica, CA * * Path: woodside@ttidca.tti.com * * or: ..!{philabs|csun|psivax}!ttidca!woodside *
jimomura@lsuc.on.ca (Jim Omura) (06/05/91)
Well, today I finally got a chance to try out this demo kit.
Having verified the file I uploaded it to a local BBS in its original
form. I thought about adding a documentation file, but changed
my mind. It needs one, but frankly I was just too tired at the time.
The music is indeed *very* good. So is the overall finish of the
package. The only thing I don't like about that is the concept of the
packaging as an autobooting disk in an MSA file.
But I'm a bit worried about the comments I've been hearing
about this demo. I don't want to sound overly negative about this,
but with all the enthusiasm of the postings, I'm wondering if
somebody might end up showing this around expecting to impress
some heavy duty "stereo nut", or a really hip musician who has
a few thousand tied up in Yamaha and Roland, or even some of
the other brands of computers. Don't think you're going to impress
an Amiga owner or even an old Apple II owner who has a good music
card -- say, 1982 vintage. 8 bit resolution is 8 bit resolution and
though this demo is really good, it's not going to "blow [anybody]
away" who is really experienced in the field. It shows aliasing at
times and even clipping, and the dynamic range is generally flat.
That's not the fault of the programmers. It's simply the limits of
the hardware showing themselves.
Guys, it's *really good*! In fact, it may well be the best we'll
ever see on the STE as it now stands and indeed it's about as good
as anything I've heard on the Amigas and Tandy MS-DOS boxes. But
it's not better. . . .
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura