protcoop@leibniz.uucp (08/03/89)
Something has been on my mind for the last while and I want to bring it to the net community to see if my theory is plausible. Let us *suppose* that the Amiga 3000 did not use Commodore's custom chips but used some 'off the line' parts by other companies, for example the TI 34000 (?) blitter. Let us further suppose that all of the system software looks the same to the programmer, i.e. all of the function calls are the same. Would it not be possible for current software to work on both the new hardware and the old hardware? The way I see it is that in my programs I have to open libraries to call routines. If I am on the current Amiga then the library I get is one that supports that machine. If I am on the new Amiga 3000, then the library that gets opened is one that supports the new hardware. The programmer (at least in 'C') need never know what hardware is being used. Is this the way it would work? If not, why not? ------------------------------------------------------------------------------------------------ Alan W. McKay | My opinions are mine, yours are yours. | Eat Food | NEPEAN, Ont. | I in no way pretend to represent the | and | 613-763-8980 | the options of my employer. So there. | LIVE !! |
esker@abaa.uucp (Lawrence Esker) (08/04/89)
In article <1388@bnr-fos.UUCP> protcoop@leibniz.uucp () writes: > ...Let us *suppose* >that the Amiga 3000 did not use Commodore's custom chips but used some >'off the line' parts by other companies, for example the TI 34000 (?) >blitter. Let us further suppose that all of the system software looks >the same to the programmer, i.e. all of the function calls are the same. >Would it not be possible for current software to work on both the new >hardware and the old hardware? The way I see it is that in my programs >I have to open libraries to call routines. If I am on the current Amiga >then the library I get is one that supports that machine. If I am on >the new Amiga 3000, then the library that gets opened is one that >supports the new hardware... In the land of dragons, unicorns and faeries, you are absolutely correct in your assumptions. From what I've seen in the Amiga and from Comodore in the last 4 years, what you suggest is why Comodore stresses the proper use of library routines, etc. But, a big but, there are alot of developers out there who, for whatever reasons, beleive they can get squeeze better performance out of the machine by doing things their own way. Look at how much software breaks when there have been operating system changes. EVERY ONE OF THESE FAILURES IS DUE TO VIOLATING AMIGA "RULES", imho. In the land of schedules, costs, and profits, what you say is not conceivable. In my years of experience, the more that is changed, the longer things will take, the more money is lost, and the more bugs will be introduced. I would say that changing the hardware foundation is the extreme of change. Did I mention that even gremlins exist in the land of dragons. By the way, you touched on THE reason the Amiga is superior to all other computer systems on the market, including UNIX and VAX machines. The common programmers interface that operates every feature of the machine in a unilateral and upward compatible means. All this despite the "braindamaged" BCPL and AmigaDOS that other threads on this net are shoving down our throats. Yes, BCPL and AmigaDOS do not integrate well with the rest of the system, but this is the land of reality. Besides, I am sure there are people where BCPL and TripOS originated that beleive C, Exec and Intuition do not integrate well with AmigaDOS. (Oh well, I'm rambling on. Time to shut up.) >Alan W. McKay | My opinions are mine, yours are yours. | Eat Food | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-> Devon, take heed. -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any \ * * * ******* / computer that is not IBM compatible. \ * * * * * / \ * * * * * ***** / Sr. Hardware/ASIC Design Engineer \ * * * * * * / Allen-Bradley Communications Div. \ ******* * * ******* / Phone: (313)668-2500 (313)973-8561 ----------------------------- Compuserve: ?????-???? UseNet Smart: esker@abaa.uucp or abaa!esker@itivax.iti.org UseNet Other: __!uunet!mimsy!rutgers!citi!itivax!abaa!esker Nothing left to do but :-) ;-) ;-D
wendell@medsys.UUCP (bbs amiga user) (08/05/89)
Good idea, and I'd say it would almost work... Most productivity software would work the way you've outlined it I assume. The only things that would break in large numbers are commercial games. (Seems that way with everything else: HD's, 010/020's, more ram...). A LOT of the game programmers skip right by the standard AmigaDos library calls, and address the disk drives, custom chips, etc.. directly thru their registers. Plug in a different blitter, and the registers will be totally different. All Non-Standard code would probably die.... Too bad, the Amiga's shared library scheme is the best I've seen on any micro. American, Canadian, etc... productivity programmers agree, and use the standard library calls. It's the European game programmers that kick out the Operating System first thing. shame... -- Wendell Dingus UUCP: uunet!medsys!wendell
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (08/06/89)
In article <713@neptune.UUCP> esker@neptune.UUCP (Lawrence Esker) writes: >In article <1388@bnr-fos.UUCP> protcoop@leibniz.uucp () writes: >>that the Amiga 3000 did not use Commodore's custom chips but used some >>'off the line' parts by other companies, for example the TI 34000 (?) >>blitter. Let us further suppose that all of the system software looks >>the same to the programmer, i.e. all of the function calls are the same. >>Would it not be possible for current software to work on both the new >>hardware and the old hardware? >In the land of dragons, unicorns and faeries, you are absolutely correct >in your assumptions. From what I've seen in the Amiga and from Comodore >in the last 4 years, what you suggest is why Comodore stresses the proper >use of library routines, etc. But, a big but, there are alot of developers >out there who, for whatever reasons, beleive they can get squeeze better >performance out of the machine by doing things their own way. Look at how >much software breaks when there have been operating system changes. EVERY >ONE OF THESE FAILURES IS DUE TO VIOLATING AMIGA "RULES", imho. Not every feature of the machine is available in a hardware independent fashion. Sometimes, a programmer really needs to build a custom COPPER list, or directly manipulate the blitter registers. There are *legal* system supported ways to do these things which are manifestly not hardware independent, and which would break if an "Amiga" were built with off-the-shelf parts instead of the custom ICs. Clearly it's better to use the system supplied routines whenever possible, but it just isn't always possible, and not just for games. Your typical spreadsheet or wordprocessor should work on such an "Amiga", but some high-performance graphics applications certainly wouldn't without some rewriting. This should become less common as more powerful CPUs become more common, since the blitter has a much smaller speed advantage over a '20 or '30 with a fast clock (as long as the manipulations can be done in 32-bit ram, and are complex enough to justify copying in and out of chip ram). >By the way, you touched on THE reason the Amiga is superior to all other >computer systems on the market, including UNIX and VAX machines. The common >programmers interface that operates every feature of the machine in a >unilateral and upward compatible means. Both Unix and VMS have standard programmer interfaces. They couldn't work otherwise--especially UNIX, which runs on a wide variety of very different architectures (where VMS only runs on variations on the same basic VAX). In fact, VMS and UNIX are better because memory protection forces you to use the standard interface--you can't twiddle the bits in the hardware registers without shifting to a priveleged processor mode. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
bear@bucsb.UUCP (Blair M. Burtan) (08/09/89)
>list, or directly manipulate the blitter registers. There are *legal* >system supported ways to do these things which are manifestly not hardware >independent, and which would break if an "Amiga" were built with >off-the-shelf parts instead of the custom ICs. Clearly it's better to ^^^^^^^^^^^^^^^^^^ >use the system supplied routines whenever possible, but it just isn't >always possible, and not just for games. Your typical spreadsheet or >wordprocessor should work on such an "Amiga", but some high-performance >graphics applications certainly wouldn't without some rewriting. This >should become less common as more powerful CPUs become more common, since >the blitter has a much smaller speed advantage over a '20 or '30 with a >fast clock (as long as the manipulations can be done in 32-bit ram, and are >complex enough to justify copying in and out of chip ram). Think about this. The original IBM-PC was and can be built with off the shelf parts. All one need do is buy a bare board and copy the ROMS on to blank EPROMs. The result, every fly-by-night computer company is making PC clones. It's easy, it's cheap, and obviously profitable. You can't do that with an Amiga. Not only would you have to raid CBM manufacturing facilities for PCB and the custom chips, but you'd have to find someone to copy PALs for you. And you'd have to find DB-23 connectors (Blech!!). Basically, CBM created a monopoly for themselves. Thus, they can do whatever they want to the machine. They don't have to keep improving themselves just to stay ahead of the competition because there is none. definitely IMHO, Bear -- ------------------------ Signature Version 0.2 ------------------------------ Disclaimer: I'm the one you're mother wants you to marry. Blair "Bear" Burtan, Boston University's Resident Amiga Expert which isn't saying much. bear@bucsb.edu bear@bucsf.edu bear@buengf.edu bear@bu-pub.edu enge05c@buacca.edu -----------------------------------------------------------------------------
rtczegledi@crocus.waterloo.edu (Richard Czegledi) (08/09/89)
Hey.... Idea. Since it is generaly un-economical to create a double buffered display for scrolling multi-bitplaned screens to eliminate the annoying flicker, why not try to reduce the flicker somewhat. I think that most of the flicker is due to the delay while an entire bitplane is blitted up and might possibly be resolved by scrolling the display in 2 or 3 horizontal sections (reduce the time that one bitplane is disjointed from it's corresponding pixels in another plane). Flicker would probably still be there, but atleast it wouldn't be as great, or dominate the entire screen. just a thought.
jms@tardis.Tymnet.COM (Joe Smith) (08/12/89)
In article <15769@watdragon.waterloo.edu> rtczegledi@crocus.waterloo.edu (Richard Czegledi) writes: >Hey.... Idea. Since it is generaly un-economical to create a double >buffered display for scrolling multi-bitplaned screens to eliminate the >annoying flicker, why not try to reduce the flicker somewhat. I take it you mean "color smear", as opposed to "interlace flicker". <I think that most of the flicker is due to the delay while an entire <bitplane is blitted up and might possibly be resolved by scrolling the <display in 2 or 3 horizontal sections (reduce the time that one bitplane <is disjointed from it's corresponding pixels in another plane). Flicker <would probably still be there, but atleast it wouldn't be as great, or <dominate the entire screen. Here's an idea on how to do it. (The following describes a 640x200 16-color screen.) Instead of allocating 4 independent bitmaps, allocate one big array. Define the first bitmap to be the start of the array, the 2nd to be start+40, the 3rd as start+80, and the 4th as start+120. Then set the modulo for each one as 120 (making it looks sort-of like a super-bit-map). You could draw onto the array as if it were 4 independent 640x200 bitmaps. If you could convince the graphics library that you want the array to be treated as if it were a screen with a single 2560x200 bitplane, the color smear would go away. The blitter would move all the bits of all the "planes" of the first line before it moved the second line, etc. It would look better than the current case, where all the bits of the entire first plane gets moved before any of the bits in the second plane. But the current blitter only goes up to 1024 bits. Until you get the ECS, you'll have to use some tricks to get the blit accomplished. Or is this idea too crazy to be of use? :-) -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/15/89)
In article <506@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: [Interesting idea edited out (see the reference)] >But the current blitter only goes up to 1024 bits. Until you get the ECS, >you'll have to use some tricks to get the blit accomplished. >Or is this idea too crazy to be of use? :-) Actually it looks like a pretty neat idea, you can try it on current technology screens by using a low res 250 X 200 screen (1000 X 200 bitmap) Make the viewport think it is a 5 plane screen tho so that you can check it with full DMA contention. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
farren@well.UUCP (Mike Farren) (08/17/89)
The problem with the proposed scheme is that it wins you little over the current scheme. Blitting images is not done on a line by line basis - if it were, the blit might be a little cleaner, but would be one hell of a lot slower, as the overhead involved in setting up the blitter for each line transfer would be immense. Making CHIP RAM out of 60ns chips and doubling the blitter's transfer rate would help a lot more... at a price. -- Mike Farren farren@well.sf.ca.usa
jms@tardis.Tymnet.COM (Joe Smith) (08/18/89)
In article <13167@well.UUCP> farren@well.UUCP (Mike Farren) writes: >The problem with the proposed scheme is that it wins you little over >the current scheme. Blitting images is not done on a line by line >basis - if it were, the blit might be a little cleaner, but would be >one hell of a lot slower, as the overhead involved in setting up the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >blitter for each line transfer would be immense. No, it wouldn't, because the blitter hardware is capable of doing it. Take a look at the Hardware Reference Manual (or get Tom Rokicki's BlitLab from Fish Disk #84). You can tell the blitter how many bytes are on a line, and you tell the blitter how many bytes it should skip over to get to the next line. Setting the "modulo" register to zero means that the bits for the second line immediately follows the first line. The graphics.library and the blitter fully support this - that's how SuperBitMaps work. For instance, when showing only a 640x200 section of an 800x200 bitmap, the blitter is told to process 80 bytes per line and skip 20 bytes to get to the start of the next line. (Actually it's 40 words and 10 words since the blitter processes 16 bits at a time.) There are all sorts of neat tricks that you can pull by lying to the graphics.library. For instance, I've heard that the 3D picture player that comes with the Haitex 3D goggles does not read two independent 320x200 pictures from the IFF file, but instead reads a double-wide 640x200 lo-res image. By giving the appropriate offsets and modulos to the graphics.library and telling it to display a 320x400 interlaced picture, the left and right halves of the double-wide image will be displayed on consecutive frames. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
shadow@pawl.rpi.edu (Deven T. Corzine) (08/18/89)
On 16 Aug 89 18:09:26 GMT, farren@well.UUCP (Mike Farren) said:
Mike> The problem with the proposed scheme is that it wins you little
Mike> over the current scheme. Blitting images is not done on a line
Mike> by line basis - if it were, the blit might be a little cleaner,
Mike> but would be one hell of a lot slower, as the overhead involved
Mike> in setting up the blitter for each line transfer would be
Mike> immense. Making CHIP RAM out of 60ns chips and doubling the
Mike> blitter's transfer rate would help a lot more... at a price.
Huh? The proposed scheme sounds like it would work beautifully. The
whole point of the matter was that the problem was multiple bitplanes
being disjoint with respect to specific lines... One bitplane the
text of a line is on the new line while the other(s) are on the old
line...
The proposed scheme was to make one large bitplane (as far as the
blitter is concerned) and manipulating the Copper to display the
bitplanes, resetting the address for each line. This way you get this
sort of layout:
<---------- layout in memory --------->
+---------+---------+---------+---------+
| | | | |
| | | | |
| | | | |
+---------+---------+---------+---------+
<--bp0--> <--bp1--> <--bp2--> <--bp3-->
At the beginning of each scan line, the display address would be reset
by a Copper interrupt to the next scanline in the bitplane. Given a
screen, resolution x by y, number of bitplanes n=3, length of a
scanline in bytes len, and starting address addr, organized as in the
above figure. Starting scanline addresses would look as follows:
Bitplane Scanline Address
-------- -------- -------
0 0 addr
1 0 addr+len
2 0 addr+2*len
0 1 addr+3*len
1 1 addr+4*len
2 1 addr+5*len
. . .
. . .
bp line addr+(bp+line*n)*len
number of bitplanes=3 --------------^
The copper would interrept the processor at every scanline to reload
the address registers, as the address of the next scanline would
otherwise point to what is actually the same scanline in the next
bitplane.
Now, to scroll, the blitter is told to scroll a region starting at addr,
len*3 bytes wide and y lines long vertically by the height of a line
of text. It doesn't matter to the blitter that the region is not
displayed as a single bitplane. If the size of that region is too
large for the blitter to handle at once, split it into several
requests. Regardless, the blitter will scroll the region(s) smoothly,
without disjoint text. Which was the idea behind the whole thing in
the first place...
I hope this makes things clearer for someone.
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.jms@tardis.Tymnet.COM (Joe Smith) (08/20/89)
In article <SHADOW.89Aug18060254@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >The proposed scheme was to make one large bitplane (as far as the >blitter is concerned) and manipulating the Copper to display the >bitplanes, resetting the address for each line. Actually, my idea doesn't need to bother the Copper at all. Just set BPL1MOD and BPL2MOD (registers 108 and 10A). > <---------- layout in memory ---------> > +---------+---------+---------+---------+ > | | | | | > | | | | | > +---------+---------+---------+---------+ > <--bp0--> <--bp1--> <--bp2--> <--bp3--> That's a good diagram. The Blitter can handle this format if BLT[A-D]MOD are set (registers 060 thru 066). Again, no Copper hacking is required. >Now, to scroll, the blitter is told to scroll a region starting at addr, >len*3 bytes wide and y lines long vertically by the height of a line >of text. It doesn't matter to the blitter that the region is not >displayed as a single bitplane. Right. The only problem, as I mentioned, is that the current Agnus has a limitation of 1024 bits for the total width. However the new 1-meg Agnus is supposed to respond to requests for 32K bit wide blits. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
shadow@pawl.rpi.edu (Deven T. Corzine) (08/20/89)
Deven> The proposed scheme was to make one large bitplane (as far as Deven> the blitter is concerned) and manipulating the Copper to Deven> display the bitplanes, resetting the address for each line. On 19 Aug 89 21:49:22 GMT, jms@tardis.Tymnet.COM (Joe Smith) said: Joe> Summary: No need to use the copper Joe> Actually, my idea doesn't need to bother the Copper at all. Just Joe> set BPL1MOD and BPL2MOD (registers 108 and 10A). Okay, I stand corrected. [still, I had the right idea...] :-) Deven> <---------- layout in memory ---------> Deven> +---------+---------+---------+---------+ Deven> | | | | | Deven> | | | | | Deven> +---------+---------+---------+---------+ Deven> <--bp0--> <--bp1--> <--bp2--> <--bp3--> Joe> That's a good diagram. Gee, thanks! :-) Joe> The Blitter can handle this format if BLT[A-D]MOD are set Joe> (registers 060 thru 066). Again, no Copper hacking is required. On the other hand, if you *want* to do copper hacking, [:-)] you could use a scheme suggested earlier by someone to scroll by manipulating the addresses the copper displays from... Can you say FAST scrolling, boys and girls? [it requires only register shuffling, not memory copying] Of course, that would only really work as a screen, and might be hard to get it to cooperate with Intuition, but it would scroll quickly and smoothly... Deven> Now, to scroll, the blitter is told to scroll a region starting Deven> at addr, len*3 bytes wide and y lines long vertically by the Deven> height of a line of text. It doesn't matter to the blitter Deven> that the region is not displayed as a single bitplane. Joe> Right. The only problem, as I mentioned, is that the current Joe> Agnus has a limitation of 1024 bits for the total width. However Joe> the new 1-meg Agnus is supposed to respond to requests for 32K Joe> bit wide blits. 1024 bits not being enough for 2 hires bitplaces. *sigh* It's a nice idea, anyhow. You could do 3 lores bitplanes this way, but it's tough to do 80 columns that way... Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (08/22/89)
In article <522@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes: : In article <SHADOW.89Aug18060254@pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: : Actually, my idea doesn't need to bother the Copper at all. Just set BPL1MOD : and BPL2MOD (registers 108 and 10A). : : > <---------- layout in memory ---------> : > +---------+---------+---------+---------+ : > | | | | | : > | | | | | : > +---------+---------+---------+---------+ : > <--bp0--> <--bp1--> <--bp2--> <--bp3--> : : That's a good diagram. The Blitter can handle this format if BLT[A-D]MOD : are set (registers 060 thru 066). Again, no Copper hacking is required. : : >Now, to scroll, the blitter is told to scroll a region starting at addr, : >len*3 bytes wide and y lines long vertically by the height of a line : >of text. It doesn't matter to the blitter that the region is not : >displayed as a single bitplane. : : Right. The only problem, as I mentioned, is that the current Agnus has : a limitation of 1024 bits for the total width. However the new 1-meg : Agnus is supposed to respond to requests for 32K bit wide blits. Except that that blitter is just way too slow to do smooth scrolling, except for maybe low-res 4 bitplane stuff. High-res 4 bitplane, requires over 100ms even just to clear the memory, a simple one source blit. Wayne Knapp
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/23/89)
NEW LAYOUT OF BITPLANES
Addr <---------- layout in memory --------->
0x0000 +---------+---------+---------+---------+
0x0140 | | | | |
... | | | | |
0xF9FF +---------+---------+---------+---------+
<--bp0--> <--bp1--> <--bp2--> <--bp3-->
Figure 1. Deven's drawing. (Addresses Assume 640 X 200 X 4 screen)
TRADITIONAL LAYOUT OF BITPLANES
Addr <- layout ->
0x0000 +----------+
0x0050 | |
... | |<--bp0-->
0x3E80 +----------+
0x3F00 | |
... | |<--bp1-->
0x7D00 +----------+
0x7D80 | |
... | |<--bp2-->
0xBB80 +----------+
0xBC00 | |
... | |<--bp3-->
0xF9FF +----------+
Figure 2. My Drawing (Addresses still assume a 640 X 200 screen)
In article <4705@tekig5.PEN.TEK.COM> (Wayne Knapp) writes:
> Except that that blitter is just way too slow to do smooth scrolling,
> except for maybe low-res 4 bitplane stuff. High-res 4 bitplane,
> requires over 100ms even just to clear the memory, a simple one
> source blit.
> Wayne Knapp
Wayne you overlooked what was being said. Would someone with a 1M Agnus
*please* code this up. I'd do it, but I don't have such a beast yet.
The key is that the "new" way of laying out the bitmaps can scroll the
entire screen with all four bitplanes with a *single* blit. And while
the blit will not complete in a single frame time, the absolute worst
side effect you would see would be *one line* of pixels that were the
wrong color. Contrast that to the current situation where *every* pixel
on the screen can be the wrong color because of one blit is finished
and the next is setting up.
As Deven mentioned the only problem is that Amiga's with the old Agnus
can't take advantage of this technique because their blitters can't do
the big blit necessary.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"