From: csg019@cch.coventry.ac.uk (-~=Zaphod=~-)
Subject: Re: New hardware reference guide?
Organization: Coventry University
Date: Tue, 17 Nov 1992 13:40:10 GMT

In article <1992Nov17.022129.24772@mpifr-bonn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
>In <Bxnwno.6ns@cck.coventry.ac.uk> csg019@cch.coventry.ac.uk (-~=Zaphod=~-) writes:
>>>This is hardly right. In most cases you will end with a program that
>>>a) runs on some machines only (most likely A500's and A3000's with no expansion)
>
>>It would work on any amiga with the custom chips at location $DFF000.
>
>Really ? What would a single interrupt from another hardware cause when
>the programmer didn't lock out that possibility before ? How many demos
>simply fail because 'self-modifying' code is soooo cute ?

Demo creators are not as bad as you seem to think, sure a few years back things
were pretty bad, but your average demo writter does not write self modifying
code, i never did, and the only time i've ever seen this, is in the sound
tracker replay routine.
As for the interupts, these are disabled after about 4 lines of code.

>>>b) crashes with a new OS version or when started from system that is booted further
>>>   than the initial CLI.
>
>>It would not crash under new OS versions, because it would only use a few
>>bare essential routines like Forbid() and Permit().
>
>There is more to it. A large couple of demos I have seen load straight to
>some absolute address (or the decompactor does that). With different OS
>version the chip memory usage varies and it is likely for the decompactor
>that it hits the copperlist :)

Then thats the decompactors fault, not the demo writters fault.

>>And whats the point about booting got to do with the price of fish?
>
>The point is that you have to reboot your computer even to _start_ the
>demo.

Jeez it must be murder pressing the 3 keys together...

>
>>>c) does generate bogus displays on either NTSC or PAL systems.
>>Depends what you mean by bogus displays.
>
>Oh.. even non-synchronizing displays. Or that neat loss of the correct
>bitplane pointers in the Elite game.

Whats a non-sync'ing display?

>
>>NTSC users would loose a portion of the screen due to the fact that the
>>NTSC screen can't display as many lines at a PAL screen.
>
>>Easy enought to avoid, just :
>
>Heh.. 'just' ? did I write the demo/game ?
>
>>1.. Write another version where the graphics are kept withing a smaller
>>area on the screen.
>
>>2.. Write a just an NTSC version, so all the lucky PAL owners have a chunk
>>of screen missing (*not big OR clever CINEMAWARE*).
>> 
>>>d) risks hardware damage with things connected to the serial or parallel port.
>
>>How could it *dammage* hardware?
>>Your not one of them guys that think that some viruses write to the disk
>>label are you?  :)
>
>I have seen programs that simply write to the parallel or serial port.
>That is not wise when you don't know what hardware is connected. Ah sure..
>to run a demo I have to turn off my computer, disconnect everything and
>boot from disk.. NOT! 
                   ^
		   |
		(Ooh, dear...)
		
I've never seen these demos, and i've seen thousands of demos.





-- 
*******************************************************************************
*        ///  A member of S.H.I.T. (Super High Intelligence Team)    ///      *
*       ///        Fight, defeat and kill organized laming.         ///       *
****\\\X//********Steven Haggerty**csg019@uk.ac.cov.cck ok?*****\\\X//*********
Xref: sparky comp.sys.amiga.programmer:16215 comp.sys.amiga.hardware:20111