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
deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/05/89)
In article <1388@bnr-fos.UUCP> protcoop@leibniz.uucp () writes: >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 (?) I thought about what would be involved in using a TI 340x0 in an Amiga system before. The format of the video memory leads me to say it's not practical. The Amiga is bitplane oriented, as all the graphics.library structures indicate, while the TI chipsets are pixelpacked. Thus, on the Amiga a pixel is formed by grabbing bits from a bunch of different bitplanes, with the number of bitplanes being completely variable [up to a maximum that is always too small :-)]. The Custom chips do one dma cycle for each bitplane then get 16 pixels out of it [16 is memory bit width]. A 32bit bitplane solution would be able to display twice as much 16bit bitplane solution. Greater pipelining or extensive fifo usage could make it even better. On the 340x0, it's a little different. If you have one bit/pixel it works the same. If you have two bits/pixel, then two consecutive bits in memory generate a pixel. If you have 16 colors, you have 4 consecutive bits to a pixel. Because the shifting gets icky, you don't get non power-of-two bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy when you get to the end of the word :-) It is easier to build video shifting circuitry for pixel packing. There is a National graphics chip set [not sure about availability] that has a super blitter/display chip for each bitplane, the entire architecture is 32bit, and has a full graphics processor. I looked at a 10 or so page pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING, but it probably takes up a ton of board space.. the main processor had 50ns cycles for some stuff... I certainly would much rather stay with a bitplaned approach. Everytime I think of displaying text on a nonbitplaned multi bit/pixel screen it scares the heck out of me. Of course these systems do text for you, but I still think bitplaning is better. I suspect the difficulty in switching to a pixel packed chip such as the 340x0 using just a new graphics.library is probably prohibitive. Too much bitplaned data in structures would have to be repeatedly converted to and from pixel packed format. <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
ckp@grebyn.com (Checkpoint Technologies) (08/11/89)
In article <1671@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: >I thought about what would be involved in using a TI 340x0 in an Amiga >system before. The format of the video memory leads me to say it's not >practical. The Amiga is bitplane oriented, as all the graphics.library >structures indicate, while the TI chipsets are pixelpacked. Look at the way graphics memory for the Bridgecard is arranged. It's addressed in three different locations, and in each one, the same memory is organized differently. I can easily imagine that a simple system can be devised to make the same region of memory look both pixel-packed and bit plane'd. Then, both the graphics.library and the 34020 would be happy. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/12/89)
In article <12258@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article I wrote... >>I thought about what would be involved in using a TI 340x0 in an Amiga >>system before. The format of the video memory leads me to say it's not >>practical. The Amiga is bitplane oriented, as all the graphics.library >>structures indicate, while the TI chipsets are pixelpacked. > > Look at the way graphics memory for the Bridgecard is arranged. >It's addressed in three different locations, and in each one, the same >memory is organized differently. I can easily imagine that a simple >system can be devised to make the same region of memory look both >pixel-packed and bit plane'd. Then, both the graphics.library and the >34020 would be happy. No, there are still major problems. Ok, let's not talk 34020 yet, it's not out yet. The methods used to communicate to the 34010 are pretty bogus. You have a 16bit databus, and a little address bus. You have access to a couple of registers inside the chip. One of the registers is an address register. Another is a control register that specifies whether the address is to remain the same, or increment each read/write cycle. Another register is a data register, read/write a value to here, and it gets interleaved with the 34010's memory accesses. The address register also gets incremented if you set a control bit... Ok that's probably not exactly it, but not far off,.. I don't have the book on my shelf anymore.. Ok, so you can't use that port to talk to the memory. It's not a high performance bus, to say the least. Now you are talking about letting the Amiga dual port into the 34010's video rams. That's bloody scary. A friend and I just dual ported a 68020 and an ACRTC in static rams. Video rams are sorta like DRAMS.. sorta.. Ugh. Scary. What you are saying, is that if you have a bitmap in a program, and you want to blit in it, you are going to use the 68000 to blit it into the 34010 memory. Of course! It does not have access to the memory where the program has kept it's data. And transferring that little bitmap (wherever in memory it is) into pixel packed format so the 34010 can blit it in is not much better than letting the 68000 just blit it in itself. WHAT'S the the 34010 for then? Sounds like a doomed project to me... <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
addison@pollux.usc.edu (Richard Addison) (08/13/89)
In article <1671@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: >I thought about what would be involved in using a TI 340x0 in an Amiga >system before. The format of the video memory leads me to say it's not >practical. The Amiga is bitplane oriented, as all the graphics.library >structures indicate, while the TI chipsets are pixelpacked. Furthermore, those bitplanes can be scattered around quite a bit unlike the bitplanes of something like the Inconsequential Bit Mover's EGA where the planes are at fairly fixed locations. >Thus, on the Amiga a pixel is formed by grabbing bits from a bunch of >different bitplanes, with the number of bitplanes being completely >variable [up to a maximum that is always too small :-)]. The Custom chips >do one dma cycle for each bitplane then get 16 pixels out of it >[16 is memory bit width]. A 32bit bitplane solution would be able to >display twice as much 16bit bitplane solution. Greater pipelining or >extensive fifo usage could make it even better. Of course, VRAMs would be nice as well since they have the fifos built in. >On the 340x0, it's a little different. If you have one bit/pixel it works >the same. If you have two bits/pixel, then two consecutive bits in memory >generate a pixel. If you have 16 colors, you have 4 consecutive bits >to a pixel. Because the shifting gets icky, you don't get non power-of-two >bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy >when you get to the end of the word :-) It is easier to build video >shifting circuitry for pixel packing. The bitplane method gives the Amiga much more flexibility in memory consumption. Building video shifting circuitry for bitplane method is not so ugly because of the consistency between working with various numbers of bits per pixel. Video shifting a pixel packed architecture with variable bits per pixel is, on the other hand, rather ugly since it has to unpack in different ways. >There is a National graphics chip set [not sure about availability] that >has a super blitter/display chip for each bitplane, the entire architecture >is 32bit, and has a full graphics processor. I looked at a 10 or so page >pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING, >but it probably takes up a ton of board space.. the main processor had >50ns cycles for some stuff... Could you summarize the pamphlet? >I certainly would much rather stay with a bitplaned approach. Everytime >I think of displaying text on a nonbitplaned multi bit/pixel screen it >scares the heck out of me. Of course these systems do text for you, >but I still think bitplaning is better. Everytime I think about image processing with a bitplane approach I get discouraged. In that case, I'd prefer 8 bits per color component available in one byte. (Yes, and an 8 bit alpha channel, too! How about 12 bits per channel so I can handle overflow? And enough memory for, say, 32 million pixels?) Furthermore, it's a bit easier to do anti-aliased fonts. Of course, you'd want some sort of convolver on it. >I suspect the difficulty in switching to a pixel packed chip such as >the 340x0 using just a new graphics.library is probably prohibitive. >Too much bitplaned data in structures would have to be repeatedly >converted to and from pixel packed format. > <tdr. > >Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada Would the National chip be better suited? Also remember that the graphics library has no restrictions on the relative positions of the various bitplanes. Richard Addison "Time flies like the wind. Fruit flies like bananas."
deraadt@enme3.ucalgary.ca (Theo Deraadt) (08/13/89)
In article <19145@usc.edu> addison@pollux.usc.edu (Richard Addison) writes: >In article <blah blah> I wrote: >>...display twice as much 16bit bitplane solution. Greater pipelining or >>extensive fifo usage could make it even better. >Of course, VRAMs would be nice as well since they have the fifos built in. You mean shift registers, not fifos. A video ram, like a dram, has rows of columns of bits. It also has an extra column which happens to be a shift register. Based on some timing signals that the VRAM has coming in, such as DOTCLOCK, VBLANK, HBLANK, etc.. it will grab a column out of the memory, into the shift register and shift these bits out, straight to your CLUT (Color LookUp Table). This shifting happens automatically, you don't have to make it shift, it just shifts out pits. This is very convenient for pixel packing. It can also be used for bitmapping I think. >>On the 340x0, it's a little different. If you have one bit/pixel it works >>the same. If you have two bits/pixel, then two consecutive bits in memory >>generate a pixel. If you have 16 colors, you have 4 consecutive bits >>to a pixel. Because the shifting gets icky, you don't get non power-of-two >>bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy >>when you get to the end of the word :-) It is easier to build video >>shifting circuitry for pixel packing. >The bitplane method gives the Amiga much more flexibility in memory >consumption. Sorta true. For any resolution with a power of two bits/pixel, bitplaned and pixel packed memory architectures use the same amount of memory. If you only needed 5 bit video, you would waste 3 bits/pixel of ram. >Building video shifting circuitry for bitplane method is not so ugly because >of the consistency between working with various numbers of bits per pixel. >Video shifting a pixel packed architecture with variable bits per pixel is, >on the other hand, rather ugly since it has to unpack in different ways. Shifting pixel packed video out is easier. You have one DMA circuit, with one complicated shift register. With bitplaning, you need multiple DMA circuits, with simple shift registers. I would not call either ugly, just better for certain things. >>There is a National graphics chip set [not sure about availability] that >>has a super blitter/display chip for each bitplane, the entire architecture >>is 32bit, and has a full graphics processor. I looked at a 10 or so page >>pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING, >>but it probably takes up a ton of board space.. the main processor had >>50ns cycles for some stuff... >Could you summarize the pamphlet? I will get it off the friend that has it, send me mail if you want info on it.. >Everytime I think about image processing with a bitplane approach I get >discouraged. In that case, I'd prefer 8 bits per color component available >in one byte. (Yes, and an 8 bit alpha channel, too! How about 12 bits per >channel so I can handle overflow? And enough memory for, say, 32 million >pixels?) Furthermore, it's a bit easier to do anti-aliased fonts. Of >course, you'd want some sort of convolver on it. Yes, but it is worth in a small system of losing the capability to do 5 bit video? We are designing a board that does 800 pixels across at 8bit each. The memory is arranged 64 bit wide, and it's 100ns ram. To be able to interleave our main processor and our drawing processor, we needed to do that. Not many a home system has that much memory bandwidth. Oh sorry, when we run in 800x8bit mode, the drawing processor gets not memory slices except during vblank and hblank... In 800x4 mode it does though.. >Would the National chip be better suited? To attempt to clone the functionality that the Amiga offers, I guess yes. The National has no sprites, but it's probably fast enough to fake them with blits. Copper lists are out, screens can be faked by memory copies, you get the idea.. actually it might do screens.. <tdr. Theo de Raadt (403) 289-5894 Calgary, Alberta, Canada
thompson@savax.UUCP (thompson mark) (08/15/89)
In article <1671@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes: >On the 340x0, it's a little different. If you have one bit/pixel it works >the same. If you have two bits/pixel, then two consecutive bits in memory >generate a pixel. If you have 16 colors, you have 4 consecutive bits >to a pixel. Because the shifting gets icky, you don't get non power-of-two >bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy >when you get to the end of the word :-) It is easier to build video >shifting circuitry for pixel packing. > >There is a National graphics chip set [not sure about availability] that >has a super blitter/display chip for each bitplane, the entire architecture >is 32bit, and has a full graphics processor. I looked at a 10 or so page >pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING, >but it probably takes up a ton of board space.. the main processor had >50ns cycles for some stuff... The processor you refer to is the National DP8500 RGP and its associated BITBLT processors (DP8511's). It is in fact only a 16 bit processor and requires one DP8511 per bitplane. This means two things, many colors chew up lots of board space (not to mention $$) and the number of bits per pixel is essentialy fixed. The planar approach in RGP is a bit different than the Amiga. In the RGP, all planes are accessed simultaneously in 16 pixel blocks. In a 256 color design (8 bitplanes) this comes to a 128 bit data bus, which is where it attains its BITBLT performance. It also means MANY MANY ram chips. As far as BITBLT engines go though, it is the fastest one I know of. >I certainly would much rather stay with a bitplaned approach. Everytime >I think of displaying text on a nonbitplaned multi bit/pixel screen it >scares the heck out of me. Of course these systems do text for you, >but I still think bitplaning is better. If all you ever want to do is move raster data around in memory quickly, BITBLT architectures like the RGP and the Amiga are fine. But for doing real graphics scene generation (ie. color shading), these systems fall flat on their face. Shading requires pixel by pixel interpolation and unless the architecture is optimized for fast single pixel access, rendering speed will be horrible. Some sort of pixel cache can help, but when you include Z-buffering, that becomes a mess. Most High-End systems organize the image memory in a planar fashion, but it is accessed like a packed pixel (one pixel at a time with all the planes at once). -------------------------------------------------------------------------- | Mark Thompson | | decvax!savax!thompson Designing high performance graphics | | (603)885-9583 silicon today for a better tomorrow. | --------------------------------------------------------------------------