Info-Atari16@SCORE.STANFORD.EDU (Info-Atari16 Digest) (11/05/86)
Info-Atari16 Digest Tuesday, November 4, 1986 Volume 86 : Issue 4
This weeks Editor: Bill Westfield
Today's Topics:
Re: Help with Desk Accessories: accessory loaders.
TRAPs from an interrupt handler and micro C Shell
Patches for the RAM disk program
SCODE - a program to code ST screens
problems with MultiTasking C shell
Re: copy pretection
Printer Problem
----------------------------------------------------------------------
Date: 2 Nov 86 14:13:48 GMT
From: imagen!turner@ucbvax.Berkeley.EDU (D'arc Angel)
Subject: Re: Help with Desk Accessories: accessory loaders.
To: info-atari16@score.stanford.edu
> In article <699@chinet.UUCP>, cabbie@chinet.UUCP (Richard Andrews) writes:
> > In article <1745@alvin.mcnc.UUCP> ravi@mcnc.UUCP (Ravi Subrahmanyan) writes:
> > >
> > >....Is there some
> > >way of putting a *desk acc. loader* into my AUTO folder, which would
> > >load the accessories?
> >
> > I believe that I have a file that will do that. As soon as I verify
> > that the critter runs(I have never ran it before) I will post it.
>
> It seems unlikely that the critter will run, since the desktop
> and AES have not been initialized at the time \AUTO folder
> execution takes place. Doing an AES call from an AUTO program
> will likely result in a crash ->thud<- and an endless cycle of
> reboots. Life is like that sometimes.
> --
>
> -Landon Dyer, Atari Corp. {sun,lll-lcc,imagen}!atari!dyer
sorry to disagree landon but if the program in question is acc_load
that was posted to the net awhile ago, it works just fine allowing
the user to even select which .acc are to be loaded
--
----
These are days for the locust to eat
- Winston Churchill
Name: James M. Turner
Mail: Imagen Corp. 2650 San Tomas Expressway, P.O. Box 58101
Santa Clara, CA 95052-8101
AT&T: (408) 986-9400
UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner
CompuServe: 76327,1575
GEnie : D-ARCANGEL
------------------------------
Date: 3 Nov 86 04:13:21 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: TRAPs from an interrupt handler and micro C Shell
To: info-atari16@score.stanford.edu
[]
Following this posting you will find a posting of source code
for a program that compresses ST pictures AND codes them into
a text file that can be sent through e-mail. The text file's
length depends on the picture, but for simple pictures (e.g.
an image of a desktop with some icons and an open dialog box)
it is about 4000 to 8000 chars, i.e. 12 to 25% of the bitmap
size in RAM. The combination code/compress algorithm is the
culprit for those ratios.
The program is installed in RAM, and activated later upon an
Alt-Help. Then, instead of printing the screen, it codes it
and saves it on the disk. (I have also written a program that
decodes and decompresses the text file, shows the picture on
the screen, and can also save it uncompressed in DEGAS format.
I am waiting for net.atari16.sources to post it, and the 2
executables.)
To do what it does, the program calls various OS routines (via TRAPs).
But, the program is called from the keyboard interrupt handler,
and it is officially verboten to do OS calls from there!!
I did it anyway, because I didn't know what else to do. And
it seems to work - from the desktop. But when called from
inside micro-C-Shell, the system hangs. Removing all the TRAPs
makes the program docile (but also futile...).
Can some expert out there tell us what to do about it, and/or how
to write files without TRAPs?
- Moshe Braner
------------------------------
Date: 2 Nov 86 20:15:44 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: Patches for the RAM disk program
To: info-atari16@score.stanford.edu
[]
If you want to use the RAM disk program I've posted as a drive other
than 'D', you have to patch it. This patch is essential if you want to use
a hard disk together with the RAM disk. Here is an old hint:
>From: jdg@elmgate.UUCP (Jeff Gortatowsky)
> {allegra,seismo}!rochester!kodak!elmgate!jdg
>Subject: Reset survivable RAM disk and Atari HD problem fixed!
>Date: 3 Oct 86
>
>Well after a bit of digging and disassembly my brother (a sharp troop)
>found the correct combination to get the reset surviving RAM disk to play
>as drive F: in a HD system (Atari 20meg). First, as was mentioned
>before on this news group you need to change the bit set in the 'drivebits'
>variable down in low memory. The BSET #3,d0 needs to be BSET #5,d0 (for
>drive F:). The other patch is applied to the compare instruction in the
>code that is executed when RWABS calls the RAM Disk. The RAM disk checks
>the device number and if it's not the right number it passes control
>through a JMP instruction to the Hard disk vector the RAM disk saved at
>boot time. The above patches imply that the RAM disk need be executed
>AFTER the hard disk driver is installed, so it may take over and save
>the hard disk vectors.
What I think was meant: Change the bytes at the following
offsets from the beginning of the ".prg" file:
offset old value(for drive D) new value (for drive F)
====== ====================== =======================
$145 (325) 03 05
$173 (371) 03 05
$181 (385) 03 05
$193 (403) 03 05
The first one is the "BSET #3,D0" in the installation, the other three
are "CMP #3,x(A7)"s in handling calls to disk device drivers.
For drive C instead of F, use the value 02.
To change the default RAM disk size, change the byte at offset
$B3 (179): The value is the size in units of 64K, e.g. 03 for
a default size of 192K, 09 for 576K.
WARNING: These are untested speculations!!!
If somebody tests this (with a hard disk, if possible), please tell us!
Jeff, if you're out there: please confirm &/or post the fix and the
disassembly!
- Moshe Braner
------------------------------
Date: 3 Nov 86 04:16:29 GMT
From: braner@tcgould.tn.cornell.edu (braner)
Subject: SCODE - a program to code ST screens
To: info-atari16@score.stanford.edu
[]
/*
* Program to code ST screens in a text file.
* By Moshe Braner, 861103.
*
* Run once, it stays in RAM and is activated by Alt-Help.
*
* This version written for the Megamax C compiler.
*/
#include <osbind.h>
/* register assignments: */
#define REPN D3
#define INDEX D4
#define REP D5
#define ROW D6
#define OUTN D7
#define OLD A2
#define COL A3
#define PHYS A4
#define COLS A5
#define VAR A6
#define BUF A6
#define SP A7
/* non-register variables: */
#define HAND -2
#define ROWS -4
#define RES -6
#define LINEN -8
#define CHKSUM -12 /* long! */
#define DTA -60 /* 44 bytes */
extern dump();
asm {
dump:
MOVE.W #1,0x4EE
MOVEM.L A6-A0/D7-D0,-(SP)
LEA vars+60(PC),VAR
MOVE.B 0xFF8260,D0 /* video resolution */
AND.L #0x00000003,D0
MOVE.L D0,CHKSUM(VAR)
MOVE.W D0,RES(VAR)
ADD.W #0x30,D0
MOVE.B D0,(BUF) /* output resolution (1 byte) */
LEA dumpname+8(PC),A0
MOVE.B D0,(A0) /* modify file name */
PEA DTA(VAR) /* check for last file name used */
MOVE.W #0x1A,-(SP) /* SETDTA */
TRAP #1
ADDQ.L #6,SP
chkname:
CLR.W -(SP) /* attribute 0 = normal files */
PEA dumpname(PC)
MOVE.W #0x4E,-(SP) /* SFIRST */
TRAP #1
ADDQ.L #8,SP
TST D0
BNE.S okname /* not found - use it */
LEA dumpname+4(PC),A0
CMPI.B #0x5A,(A0) /* was 'A' - up to 'Z' ? */
BLT.S incname
MOVE.B #0x41,(A0) /* back to 'A' */
BRA.S okname
incname:
ADDQ.B #1,(A0)
BRA.S chkname
okname:
CLR.W -(SP) /* attribute 0 = r/w file */
PEA dumpname(PC)
MOVE.W #0x3C,-(SP) /* CREATE */
TRAP #1
ADDQ.L #8,SP
TST D0 /* any errors? */
BMI cleanup /* - then skip */
MOVE.W D0,HAND(VAR) /* file handle */
MOVE.W #2,-(SP) /* PHYSBASE */
TRAP #14
ADDQ.L #2,SP
MOVE.L D0,PHYS /* video RAM */
MOVEQ #1,OUTN /* output char counter */
MOVE.W #1,LINEN(VAR) /* line length counter */
MOVE.L #0xFF8240,A0 /* palette */
MOVE.W #15,D2
palette: /* output palette (48 bytes) */
CLR.L D0
MOVE.W (A0)+,D0
ADD.L D0,CHKSUM(VAR)
BSR codeuniq
DBF D2,palette
LEA consts,A0 /* read constants from table */
MOVE.W RES(VAR),D0
ADD.W D0,D0
MOVE.W 0(A0,D0),ROW
MOVE.W ROW,ROWS(VAR)
MOVE.W 6(A0,D0),COLS
MOVE.W #0,COL /* set up for coding */
SUBQ.W #1,ROW
CLR.W REP
CLR.W INDEX
BSR nextw
MOVE.W D0,OLD
BRA.S comp2
comp1: /* compress the picture */
MOVE.W COL,D0
CMP.W COLS,D0
BGE.S endloop
MOVE.W ROWS(VAR),ROW
MOVE.W COL,INDEX
comp2:
BSR nextw
CMP.W OLD,D0
BNE.S notrep
TST.W REP
BNE.S oldrep
SEQ REP
MOVEQ #1,REPN
oldrep:
CMP.W #127,REPN
BLT.S loop1
notrep:
EXG D0,OLD
TST.W REP
BEQ.S uniq
CLR.W REP
BSR coderep
BRA.S loop
uniq:
BSR codeuniq
loop:
BNE.S close /* error writing file */
loop1:
ADDQ.W #1,REPN
DBF ROW,comp2
ADDQ.W #1,COL
BRA comp1
endloop:
TST.W REP /* in middle of repetition? */
BEQ.S done
MOVE.W OLD,D0 /* then go finish it... */
BSR coderep
done:
MOVE.W CHKSUM(VAR),D0 /* append coded checksum */
BSR codeuniq
MOVE.L CHKSUM(VAR),D0
BSR codeuniq
BSR crlf /* end last line */
BSR save /* save to disk */
close:
MOVE.W HAND(VAR),-(SP)
MOVE.W #0x3E,-(SP) /* CLOSE file */
TRAP #1
ADDQ.L #4,SP
cleanup:
MOVEM.L (SP)+,D0-D7/A0-A6
MOVE.W #0xFFFF,0x4EE
/* ADDQ.L #4,SP ROM does it, so me too? */
RTS /* return to interrupt handler */
coderep:
MOVE.W D0,D1
MOVE.W REPN,D0
LSR.W #2,D0
ORI.W #0x40,D0
BSR notz
LSL.W #4,REPN
MOVE.W D1,D0
LSR.W #6,D0
LSR.W #6,D0
OR.W REPN,D0
BRA.S code1
codeuniq:
MOVE.W D0,D1
LSR.W #6,D0
LSR.W #6,D0
code1:
BSR outbyte
MOVE.W D1,D0
LSR.W #6,D0
BSR outbyte
MOVE.W D1,D0
BSR outbyte
CMP.W #4600,OUTN /* buffer almost full? */
BLT.S nosave
save: /* save to disk */
MOVE.L BUF,-(SP)
EXT.L OUTN
MOVE.L OUTN,-(SP)
MOVE.W HAND(VAR),-(SP)
MOVE.W #0x40,-(SP) /* WRITE to file */
TRAP #1
ADDA #12,SP
CMP.W OUTN,D0
BNE.S error /* retain error code */
CLR.W OUTN
nosave:
CLR.W D0 /* no error */
error:
RTS
nextw: /* read 2 bytes from screen */
CLR.L D0
MOVE.B 0(PHYS,INDEX),D0
ADD.W COLS,INDEX
LSL.W #8,D0
MOVE.B 0(PHYS,INDEX),D0
ADD.W COLS,INDEX
ADD.L D0,CHKSUM(VAR)
RTS
outbyte: /* put byte in buffer */
AND.W #0x3F,D0
BEQ.S zzz
ADD.W #0x20,D0 /* offset by ' ' */
BRA.S notz
zzz:
MOVE.W #0x7A,D0 /* but avoid ' ' itself */
notz:
MOVE.B D0,0(BUF,OUTN)
ADDQ.W #1,OUTN
ADDQ.W #1,LINEN(VAR)
CMPI.W #64,LINEN(VAR) /* line long enough? */
BLT.S nocrlf
crlf:
MOVE.B #0x0D,0(BUF,OUTN) /* then append cr-lf */
MOVE.B #0x0A,1(BUF,OUTN)
ADDQ.W #2,OUTN
CLR.W LINEN(VAR)
nocrlf:
RTS
dumpname: /* filename: "DUMPA.CSn" - will be changed */
DC.B 0x44,0x55,0x4D,0x50,0x41,0x2E,0x43,0x53,0x6E,0x00
consts: /* rows/2-1, columns */
DC.W 99,99,199,160,160,80
vars: /* 60-byte variable space, */
/* then 4608-byte output buffer */
}
char dummy[4668]; /* ensure enough space in SBRK */
extern poke_it(); /* put our vector for screen dump */
asm {
poke_it:
LEA dump,A0
MOVE.L #0x000502,A1
MOVE.L A0,(A1)
RTS
}
char *text[] = {
"\033E\r\n",
"\t+--------------------------+\r\n",
"\t| SCREEN DUMP PROGRAM |\r\n",
"\t| (Compressed format) |\r\n",
"\t| for |\r\n",
"\t| Atari ST with TOS in ROM |\r\n",
"\t| by Moshe Braner, 8610 |\r\n",
"\t+--------------------------+\r\n",
"\r\n",
"\tProgram installed. Hit any key.\r\n",
"\r\n",
"\t(Later: press Alt-Help for a screen dump.\r\n",
"\t Dumps into files DUMPA.CSn, DUMPB.CSn, ...\r\n",
"\t where n = 0, 1 or 2 for lo, med or hi res.)\r\n",
"\r\n\n",
""
};
main()
{
register char c;
register char *cp;
register char **cpp;
Supexec(&poke_it); /* mess with vector */
cpp = &text[0]; /* print message */
while (*(cp=*cpp++))
while (c=*cp++)
Bconout(2, c);
Bconin(2); /* wait for keypress */
Ptermres((long)6000, 0); /* stay resident */
}
- Moshe Braner, Cornell U.
------------------------------
Date: 3 Nov 86 02:51:26 GMT
From: ssc-vax!benoni@beaver.cs.washington.edu (Charles L Ditzel)
Subject: problems with MultiTasking C shell
To: info-atari16@score.stanford.edu
YARG!
I am having problems with MT-C SHELL. I suspect it is something i
am doing...but who knows...
Problem one ... how do i get C SHELL to understand the command :
"ls ." (give me a directory listing of the current directory)
in fact all my problems stem from this one. If i have an executable
in my current directory i have to spell it out
\usr\root\inter\infer animal
to execute infer.prg in directory infer.
YES I know that in login.sh i should have :
set path = (. \bin \etc)
only when i have this then everything gets lost!!!
That is i try to do an 'ls' and the c shell says :
'ls' not found
If someone could send me their login.sh that works or tell me what I am
doing wrong i would be greatly in their debt. Thank you,
Charles Ditzel
...uw-beaver!ssc-vax!benoni
------------------------------
Date: 3 Nov 86 14:47:01 GMT
From: oyster@unix.macc.wisc.edu (Vicarious Oyster)
Subject: Re: copy pretection
To: info-atari16@score.stanford.edu
In article <224@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes:
>In article <246@bath63.UUCP> pes@ux63.bath.ac.uk (Paul Smee) writes:
>>I had a go at copying the Epyx disk. It appears to work, but...
>>It annoyed me enough to decide that I think I'll try to crack that one,
>>though.
>
>I copied Rogue over to my hard disk, and it runs fine from there, although
>it requires the original disk in 'A'... it just accesses it for a couple
>of seconds. Also, you can only save files to the original disk! But at
>least the loading time is slashed, especially for those l-o-n-g picture
>files.
Well, I've tried running it from a RAMdisk copy, and it wouldn't run,
even *with* the original diskette in drive A. Also, although I haven't
actually saved a game on an alternate diskette, I've subsequently copied
saved game files to another diskette, and have loaded them from that
diskette (in drive B). Works great!
Lastly, after reading (Ian Chadwick's?) column in the most recent
Analog, I took a look at the executatble file. It was entertaining
finding phrases like "Software Pirate", "Copy Protection Mafia", and
"Scum of the Earth." (Ian, by the way, changed the "die roll" figures
in the executable, thereby making his character much better, allowing
him to get the Amulet. Kinda defeats the purpose of the game, doesn't it?)
--
- Joel Plutchak
uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster
ARPA: oyster@unix.macc.wisc.edu
Can you say "opinion"? I *knew* you could!
------------------------------
Date: Sun, 2 Nov 86 15:25:21 EST
From: Flash%UMass.BITNET@WISCVM.WISC.EDU (Rick Flashman)
Subject: Printer Problem
To: Info-Atari16@SU-SCORE.ARPA
Hello,
I've got a problem with a printer here, and I was wondering if someone
here can help me out. We are trying to connect a Okidata ML-192 printer
to the ST. Problem is that the printer is randomly repeating a character
that is sent to it. Sooooo, we tried changing the printer cables, no luck.
Changing the ST to another ST, no luck. Changing the printer for another
printer, no luck. Tried the printer and STs with other printers and computers
and everything was fine, it is ONLY when we have an Okidata ML-192 printer
connected to the ST. Contacted OKIDATA, they are not aware of the problem
and insist that it is the Atari's fault. Contancted Atari, they were of no
help either. Does anybody out there have a Okidata ML-192 printer connected
to an Atari? Any help will be greatly appreciated. Is this something like
the ole SONY monitor that was advertised to work with the st, but didn't?
Rick Flashman
Flash%UMASS.BITNET@WISCVM.WISC.EDU
------------------------------
End of Info-Atari16 Digest
**************************
-------