Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 219
=========================================================================
INFO-ATARI16 Digest Sat, 17 Feb 90 Volume 90 : Issue 219
Today's Topics:
Manipulation of Courtroom Evidence
Piggybacking RAM into the 1040ST
terminating a TSR
Tick-tick-tick-CRASH! is not dead in TOS 1.4 (2 msgs)
----------------------------------------------------------------------
Date: 16 Feb 90 20:17:11 GMT
From: thorin!johnson!oliver@mcnc.org (Bill Oliver)
Subject: Manipulation of Courtroom Evidence
Message-ID: <12098@thorin.cs.unc.edu>
In article <102034@pyramid.pyramid.com> wniren@pyrtech (Walter Nirenberg)
writes:
>
>Photos and videos are still admissable as courtroom evidence in most
>situations. However, with these new "advances", can we trust these
>forms any more? Think of the impact..a criminal could possibly be
>let loose based on a photo showing someone else perpetrating the crime.
>Newspapers and TV networks could change what the public sees. We're
>talking about a tremendous potential for "disinformation" to quote
>our wonderful government (by the way, isn't that a fancy word to mean
>"to lie"?).
>
I am a forensic pathologist, and have acted as an expert witness in
numerous trials. I almost always bring photos along with me, which
counsel uses as evidence.
As far as I know, photographic evidence that *I* am involved with,
and all the photographic evidence that I have ever seen admitted
from other scene investigators has always been admitted only on the
conditions that
1) It can be shown that the photo is a "true and accurate representation,"
of what was there, and
2) It has usefulness in explaining my or some other investigator's
testimony, e.g. it is not admitted as evidence in and of itself.
Your question is about problem (1). The way this is almost always done
is for the person who took the photo to be on the stand and testify
thay this is, indeed, a true and accurate representation. Thus, if
I took the photo, then I would be the one who did the testifying that
the photo is not tampered with.
The tampering question is an old one for us folk who do autopsies,
but the question was of tampering with the body rather than with
the photo. For instance, let's say that John Doe has been shot in the
stomach. John survives long enough to get to a hospital, where
they open his abdomen to try and close off the bleeding arteries, but
he dies anyway.
Joe's body comes to the morgue with this itty-bitty hole in the belly,
and a huge old surgical wound running right through it. Defense will
often get any photographs of the wound ruled inadmissible because
of the gross looking surgical wound -- the judge will rule that the
jury will react viscerally (no pun intended) to the large wound,
rather than intellectually to the evidence of the bullet wound.
I have also had photos ruled out because there was too much free blood.
The wound wasn't cleaned (I often take one shot uncleaned and one
cleaned), and bloody wounds often look much larger than they are,
expecially in photos. I have also had one ruled out because
skin traction caused a knife wound to gape open, again making
it appear larger, in some sense, than it really was.
Thus, when I take a morgue shot, I often spend a lot of time carefully
draping towels, arranging the body, etc. to hide any extraneous stuff
in order to make my photos of the wound admissible. Then, when I get
on the stand, I testify that the photo is a true and accurate
representation, with the exception of whatever modifications I have made.
I suspect that digitization problems will be handled the same way.
Since photographic evidence is almost always admitted only as an
"illustration" of personal testimony, it will ultimately be admissible
to modify a photo to "clean up" extraneous stuff, as long as somebody
is there to testify that the stuff appropriate to the case is true and
accurate. Haggling over what consitutes "cleaning up" and what
should be left in is something that counsel should get settled
during disclosure. As far as the question of being able to
sneak in a modified photo, this has always been a possibility and
this is why 1) it is usually admitted only as "illustrative" evidence, and
2) there has to be someone there to hang for perjury.
The precedents are pretty much there already.
Now, the ease of proving perjury might be made very much more difficult.
But that is a different question.
Bill Oliver
------------------------------
Date: 16 Feb 90 09:16:52 GMT
From: mcsun!ukc!harrier.ukc.ac.uk!pfg@uunet.uu.net (P.F.Gisby)
Subject: Piggybacking RAM into the 1040ST
Message-ID: <3864@harrier.ukc.ac.uk>
You should not realy 'PIGGY BACK' RAM chips on a 1040 as the process was
designed to upgrade a 520st to a 1040. (I was taught how to do this upgrade
by a technician and you need a very small tipped iron to do it)
To do it on a 1040 you need to do a bit more than just take one line
to the MMU. As you already have the two banks of RAM the line has already
been used. To upgrade a 1040 to 2.5 (or even 4mb) was someting I looked into
for a very long time, as I was continualy running out of RAM in my 1040.
However Uncle Jack made the MEGA 4 so I got one.
The internal structure (I.E. MMU and GLUE) of the MEGA is the same as the 1040
so you can access up to 4mb of RAM in any ST (up until the STE which can access
8mb). Some say you can upgrade to 16mb but Where would you fit the RAM in the
memory map???. If you could the the case would lie that you can upgrade a 520
to a 16mb machine.
Anyway back to the question......
To upgrade a 1040 is NOT as easy as upgrading a 520. First (You don't have
to do this it's just safer, and it gives you 16 4256's to upgrade you friends
520st) you must remove a whole bank (YES ALL 16) of your RAM chips. This is
not a task to be taken lightly as the quality of all circuit boards are very
low so you could break you board without meaning to. Then you must get the
pinouts of the 1 megabit chips that you are going to use. These cost an
awfull lot of money over here in England. After this you MUST (or at least
you may find it easier to fix if it dies, if you do) is put in DIL sockets
in the place of the 4256's. Then comes the fun bit with loads of beding
up pins and wiring them to different places using wire-wrap wire (The pins
that you will need to connect to are mentioned below). Then comes testing
If you've done it right you will have 2.5mb of RAM. If you've done it wrong
OOPPSS and see if you have connected them to the right pins (I.E. DATA) and cut
the three tracks that come from the pins you use on the MMU. There was a
letter going round on how to do this which was quite good and if anyone has it
could they repost it!!!
CONNECTIONS:
MMU PIN 63 MAD8 : memory address data pin 8 (This gives a memory size of 1mb/b)
MMU PIN 64 MAD9 : memory address data pin 9 (This gives a memory size of 2mb/b)
Then you must connect your row and column address stobe lines up, these will
vary depeding on which bank you change. There are 2 column lines and 1 row
line.
The pins that you need to connect up on the RAM chips should be ducumented
where you buy them.
No one to my knoledge has ever tried putting 1mb on one bank before so I think
it can not be done.
GOOD LUCK.
Pete.
(UKC at CANTERBURY. IN THE PHYSICS LAB)
/-----------------------------------------\
| |
| ***** *** *** **** *** |
| * * * * * * * * ** |
| * * * **** * * * |
| * * ** * ** * ** * |
| * *** *** *** *** |
| |
\-----------------------------------------/
------------------------------
Date: 17 Feb 90 03:59:54 GMT
From: snorkelwacker!usc!brutus.cs.uiuc.edu!jarthur!cstein@tut.cis.ohio-state.edu
(Clifford Stein)
Subject: terminating a TSR
Message-ID: <4446@jarthur.Claremont.EDU>
I'm writing a TSR application which installs itself using the scrdump vector
found at location $502. The program seems to run correctly, although some
of the XBIOS calls I make don't (such as changing the resolution and colors.)
My program will not terminate properly, though. How should it end?
I've tried Ptermres(), RTS and an RTE.
My program is making some XBIOS calls, and using some ALINE routines.
What should I not do in this program? (i.e. what is, or is not, "legal")
How can I get it to terminate? I've gotten 3-bomb crashes, other times the
computer just locks up, depending on how it ends. What's wrong?
Thanks for any help.
---Clifford Stein
--
cstein@jarthur.claremont.edu | "Cops and women don't mix. It's like
cstein@jarthur.uucp | eating a spoonful of Draino: sure it'll
...uunet!jarthur!cstein | clean you out, but it'll leave you
cstein@hmcvax.bitnet | feeling hollow inside."-- Naked Gun
------------------------------
Date: 16 Feb 90 10:15:00 GMT
From: mcsun!unido!fauern!fauern!csbrod@uunet.uu.net (Claus Brod )
Subject: Tick-tick-tick-CRASH! is not dead in TOS 1.4
Message-ID: <2435@medusa.informatik.uni-erlangen.de>
hafer@tubsibr.uucp (Udo Hafermann) writes:
>Add Calamus to the list. Calamus likes to crash for all sorts of
>reasons, but yesterday it definitely was the phantom typist. (Including
>the effect that you had to move the mouse slightly to get the system
>to react to keys and/or menu selections.)
Has anybody tried to push some of the SHIFT/CTRL/ALT keys when the
phantom typist shows up? Somebody wrote somewhere that this might
prevent the application from crashing so that you can save your
work before system breakdown.
Claus Brod
------------------------------
Date: 16 Feb 90 10:12:45 GMT
From: mcsun!unido!fauern!fauern!csbrod@uunet.uu.net (Claus Brod )
Subject: Tick-tick-tick-CRASH! is not dead in TOS 1.4
Message-ID: <2434@medusa.informatik.uni-erlangen.de>
bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes:
>> Since we have recompiled GEMDOS and BIOS source code, but no AES and
>> VDI source code, the only people to solve the problem are ATARI US.
>>
> Who is "we". the reason i ask is that atariUS is refusing to
>distribute source code for gemdos/bios here like they used to with the
>developer kit. i am curious if atari germany if distributing it to
>developers there.
"We" means: There are some German ST users who delved into GEMDOS and BIOS
very very deeply. Among them are Alex Esser, the author of a series of
articles on GEMDOS in the German magazine "ST-Computer" (can be reached
via FIDO), and Andreas Kraemer, author of a book called "TOS intern".
In this book you'll find a completely recompiled listing of GEMDOS
(taken from TOS 1.2). The book has quite a few bugs, but it serves well
to gain some general insight in the workings and in the failings of
GEMDOS. It is available from Heise Verlag, Hannover. (If you are interested,
I can find out the complete address.) I know that some other German hackers
have extracted parts of GEMDOS, some others have done the same for
VDI and AES but this work is not completed yet. BIOS source code is
available since 1985 as commented disassembler listings in severals books
here in Germany.
ATARI Germany definitely doesn't distribute any GEMDOS source code.
Claus Brod
------------------------------
End of INFO-ATARI16 Digest V90 Issue #219
*****************************************
