cpca@iceman.jcu.oz (C Adams) (11/07/90)
I was wondering whether C= supported directly writing to the chips registers. I know you would have to do a Forbid()/Permit() and make sure blitter DMA was finished etc. to be multitasking friendly, but does C= state that any new chip set will be compatible with the old one. ie. would my program break on an Amiga 4000 if I wrote to the chips for speed. Colin Adams Email: cpca@marlin.jcu.edu.au
rsbx@cbmvax.commodore.com (Raymond S. Brand) (11/07/90)
In article <1220@iceman.jcu.oz>, cpca@iceman.jcu.oz (C Adams) writes: > I was wondering whether C= supported directly writing to the chips > registers. I know you would have to do a Forbid()/Permit() and > make sure blitter DMA was finished etc. to be multitasking friendly, No, you would have to get control of the resource in system-software compatible way. (Hint: see OnwBlitter) > but does C= state that any new chip set will be compatible with > the old one. No. > ie. would my program break on an Amiga 4000 if I wrote to the > chips for speed. Count on it. > Colin Adams > Email: cpca@marlin.jcu.edu.au rsbx ------------------------------------------------------------------------ Raymond S. Brand rsbx@cbmvax.commodore.com Commodore-Amiga Engineering ...!uunet!cbmvax!rsbx 1200 Wilson Drive (215)-431-9100 West Chester PA 19380 "Looking" ------------------------------------------------------------------------
daveh@cbmvax.commodore.com (Dave Haynie) (11/08/90)
In article <1220@iceman.jcu.oz> cpca@iceman.jcu.oz (C Adams) writes: >I was wondering whether C= supported directly writing to the chips >registers. I know you would have to do a Forbid()/Permit() and >make sure blitter DMA was finished etc. to be multitasking friendly, >but does C= state that any new chip set will be compatible with >the old one. In general, you shouldn't write to any machine register. There are some hardware specific things you can do in a quasi-system-supported manner, via hardware "resource" descriptions and calls like OwnBlitter(). >ie. would my program break on an Amiga 4000 if I wrote to the >chips for speed. The underlying chip registers don't change unless there's a good reason for them to change. But if there's a good reason, then they change. The most recent such change was rather trivial -- the A3000 got a different realtime clock, so that we could have a small amount of battery backed RAM for the software folks to play with. But it's certainly possible for other things to change. One other example is the color table. If you wanted a particular color setup on a custom screen, you might try to poke color values into color registers. Now, the OS will reset this, but ignore that for a minute. We recently introduced the ECS chipset in the A3000. If you set up a 35ns pixel display with that 3000, the color mapping physically changes. As long as you used the system call for setting colors, though, everything works properly. So my advice is, use the OS for absolutely everything, and at as high a level as you can. Leave the hardware alone, and you can expect to run on the Amiga 10,000 or whatever. Bang on the hardware, and you may even break on the A3000. If you have any detailed questions on a particular point, ask away -- the software folks probably have a better idea about what they expect to support in future system, and what's properly isolated from the hardware. >Colin Adams >Email: cpca@marlin.jcu.edu.au -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
mt87692@tut.fi (Mikko Tsokkinen) (11/08/90)
[System call stuff deleted] > >ie. would my program break on an Amiga 4000 if I wrote to the > >chips for speed. > The underlying chip registers don't change unless there's a good reason for > them to change. But if there's a good reason, then they change. The most > recent such change was rather trivial -- the A3000 got a different realtime > clock, so that we could have a small amount of battery backed RAM for the > software folks to play with. But it's certainly possible for other things > to change. One other example is the color table. If you wanted a particular > color setup on a custom screen, you might try to poke color values into color > registers. Now, the OS will reset this, but ignore that for a minute. We > recently introduced the ECS chipset in the A3000. If you set up a 35ns > pixel display with that 3000, the color mapping physically changes. As long > as you used the system call for setting colors, though, everything works > properly. I must say my .02fmk worth. If commodore really moves registers in hardware area like BLTSIZ or COL00 that means NO programs without OS interface will work (as well as old OS revisions). This means they actually can call the new machine for example NEXT because amiga programs will not run on it. > So my advice is, use the OS for absolutely everything, and at as high a level > as you can. Leave the hardware alone, and you can expect to run on the > Amiga 10,000 or whatever. Bang on the hardware, and you may even break on > the A3000. If you have any detailed questions on a particular point, ask > away -- the software folks probably have a better idea about what they > expect to support in future system, and what's properly isolated from the > hardware. > >Colin Adams > Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" MIT -- Lets buy a dog!
mrush@ecst.csuchico.edu (Matt "C P." Rush) (11/08/90)
In article <15683@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > >The underlying chip registers don't change unless there's a good reason for >them to change. But if there's a good reason, then they change. The most >recent such change was rather trivial -- the A3000 got a different realtime >clock, so that we could have a small amount of battery backed RAM for the >software folks to play with. But it's certainly possible for other things Does this mean we can have a REAL "Clock Virus" now? Oh boy, viri that survive Power-Down... PLEASE tell us there is SOME protection against "incorrect" usage of this battery backed RAM (other than the obvious 'the CPU must be TOLD to execute this RAM')... >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "I programmed three days % Beam me up, Scotty. % % And heard no human voices. % There's no Artificial % % But the hard disk sang." % Intelligence down here. % % -- Yoshiko % % E-mail: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
peter@sugar.hackercorp.com (Peter da Silva) (11/08/90)
In article <MT87692.90Nov8025556@kaarne.tut.fi> mt87692@tut.fi (Mikko Tsokkinen) writes: > I must say my .02fmk worth. If commodore really moves registers in hardware > area like BLTSIZ or COL00 that means NO programs without OS interface will > work (as well as old OS revisions). So? What sort of programs are we talking about? Games? Programs should not go around the OS until all other alternatives have been tried and found wanting. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@cbmvax.commodore.com (Peter Cherna) (11/09/90)
In article <1990Nov08.025521.20590@ecst.csuchico.edu> mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: > Does this mean we can have a REAL "Clock Virus" now? Oh boy, viri >that survive Power-Down... > PLEASE tell us there is SOME protection against "incorrect" usage of >this battery backed RAM (other than the obvious 'the CPU must be TOLD to >execute this RAM')... PLEASE DON'T jump to rash conclusions. It took forever to squelch the preposterous rumor that there could be a clock virus on the 2000. It wouldn't surprise me if the last rumor started with a Usenet posting just like yours. Let it be said here then: there are only 64 bits of battery-backed memory. That's not enough for a virus, even if the CPU ever executed that memory, which it doesn't. Oh, and lots of viruses survive powerdown. They live on your floppy and hard disks. So be vigilant, and thank folks like Steve Tibbett. > -- Matt Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "She read him like a book: she liked to peek at his end."
daveh@cbmvax.commodore.com (Dave Haynie) (11/09/90)
In article <1990Nov08.025521.20590@ecst.csuchico.edu> mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: >In article <15683@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The most recent such change was rather trivial -- the A3000 got a different >>realtime clock, so that we could have a small amount of battery backed RAM >>for the software folks to play with. > Does this mean we can have a REAL "Clock Virus" now? Oh boy, viri >that survive Power-Down... Man, some of the rampant paranoia going on. If you worry TOO much about disease, you're never going to have any fun. NO, YOU CAN'T HAVE A CLOCK VIRUS. There's only a tiny amount of RAM in there in the first place (don't recall exactly, something like 64 bytes, or was it 16...). Secondly, as mentioned at least a zillion times back when clock virus rumors went around the first time, the clock is only a 4 bit device. There is no 680x0 family processor that can execute code out of any 4 bit memory. On the 68000 you must have 16 bit memory, on the 68020/30 you must have at least 8 bit memory, and at that it must be on D31..D24 and mapped as an 8 bit port (I think the clock is still mapped as a 16 bit device, like in the 2000, though I could be wrong). > PLEASE tell us there is SOME protection against "incorrect" usage of >this battery backed RAM (other than the obvious 'the CPU must be TOLD to >execute this RAM')... That's not a trivial excuse, anyway. What clever virus could you write with 16-64 bytes of battery backed RAM that must be triggered by a disk loaded routine anyway that you couldn't write without the battery backed RAM. Note also that the code would have to be very careful about its instruction mix, since those bits mean something to a number of OS elements that wake up long before the virus could ever be activated, and if the wrong bits are set, they could easily be reset by the OS. But, again, it's a non-problem. >>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > -- Matt -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/10/90)
In <MT87692.90Nov8025556@kaarne.tut.fi>, mt87692@tut.fi (Mikko Tsokkinen) writes: > > I must say my .02fmk worth. If commodore really moves registers in hardware >area like BLTSIZ or COL00 that means NO programs without OS interface will >work (as well as old OS revisions). That's about the size of it. If you go directly to the hardware, or to the ROMs, or in any other way, bypass the system supported methods of doing things, you will have only yourself to blame > This means they actually can call the new >machine for example NEXT because amiga programs will not run on it. It will still be an Amiga as long as Amiga programs run on it. The designers of the hardware and OS do not consider ill-conceived hacks and kludges to be Amiga programs. CBM has laid down the rules you need to follow to remain compatible, and if you decide to ignore them, your program will break. SImple. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
mt87692@tut.fi (Mikko Tsokkinen) (11/12/90)
> It will still be an Amiga as long as Amiga programs run on it. The designers of > the hardware and OS do not consider ill-conceived hacks and kludges to be Amiga > programs. CBM has laid down the rules you need to follow to remain compatible, > and if you decide to ignore them, your program will break. SImple. > -larry Check out Hardware Programming Guidelines from RKM libraries and Devices (ISBN 0-201-18187-8) and you'll see it's legal to use direct hardware registers. MIT -- Lets buy a dog!
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/12/90)
In <MT87692.90Nov12013045@uikku.tut.fi>, mt87692@tut.fi (Mikko Tsokkinen) writes: >> It will still be an Amiga as long as Amiga programs run on it. The designers of >> the hardware and OS do not consider ill-conceived hacks and kludges to be Amiga >> programs. CBM has laid down the rules you need to follow to remain compatible, >> and if you decide to ignore them, your program will break. SImple. > >> -larry > > Check out Hardware Programming Guidelines from RKM libraries and Devices > (ISBN 0-201-18187-8) and you'll see it's legal to use direct hardware >registers. Well, I am not about to read it from cover to cover to try to spot what you are referring to. Care to point it out by reference to a specific operation, page number etc.? Our definitions of 'direct reference' and 'legal to use' may differ considerably. >Lets buy a dog! My cat agrees.. she says "Yum yum". -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+