In article <1992Nov25.143111.10352@email.tuwien.ac.at> nino@vmars.tuwien.ac.at (Marinos Yannikos) writes: > marks@castle.ed.ac.uk (Mark Steyn) writes: > :[...] > : I agree that Mr Fang was quite wrong on the Falcon's video memory, but > : having 14 Mb is not strictly an advantage, given that the Falcon uses a > : shared bus between processor and video. > > The Falcon does NOT use a shared bus between processor and video! > How many times does this have to be said??? Please elucidate! Both the Amiga and the traditional Atari ST design timeshare the display RAM between the processor and video accesses. For 68000 7/8 MHz systems, this can be done (nearly) transparently depending on the video bandwidth required, since the 68000 cycles are typically twice as long as that required for DRAM access. This transparency is typically lost as you go to 68020/68030 processors, since running these processors with no-wait states requires a memory cycle time 3/8's that of the slower processors. DRAM technology simply hasn't mproved enough to allow random cycle times this short. So, unless there is some very efficient access to the display RAM for the video subsystem, there will be contention between the processor and the display accesses. If there is a separate bus for RAM expansion and other processor activities then is possible to attain higher performance. So far, I've several different stories about the Falcon video bus and display subsystem, most of which are probably confusion. On one hand, people are asserting that there isn't a shared bus and on the other, they are asserting that all 14M-byte of RAM on the Falcon can be used for dipslay memory. Unless there is some kind of configurable bank switching, this seems to offer a contradiction. It may be that the processor and diplay busses are separate, but leave the question open as to whether you have also have expansion memory that isn't subject to display access contention. If you can answer the following questions: 1) What is the basis for sharing display memory between the processor and the display subsytem. 2) How many clocks are memory access to the the display memory. 3) Is there or is there not provision for adding expansion memory that is not shared or display memory? 4) If so, how the expansion space partitioned? Is it really up to 14 M-byte of display memory or is there some split? > : I know a little about both. The Falcon has no provision for processor > : only memory, which the processor can access no matter what the custom > : chips may be doing. The A1200 does, though it is shipped without any. > : An 68ec020 with full 32 bit access to memory will out perform a 68030 > : with only 16 bit access. This has been the case on the Apple Macs which > : use 030's with a 16 bit bus, and is a proven fact. > > An 68EC020 however can only address a MAXIMUM of 16 Mb RAM, it can NOT > provide virtual memory (like the 68030 with built-in PMMU) so you will > _never_ be able to use more than 16Mb of memory! The Falcon will be > able to use any amount of virtual memory up to 4 Gb. In my opinion, the > A1200 is seriously crippled, since it is limited to only 16Mb. You may be missing the point that the A1200 expansion connector has full access to the system internals and it is a trivial excercise to implement an expansion board that includes a 68030. It is not much harder to do one which would incorporate a >> 14/16 MHz processor. Such a board would probably also include fast memory tightly coupled to the processor which would provide much higher črformance than the base unit. As a result, the 16M-byte lim.1ation and lack of VM support you cite are not architectural lim.tatwin, the are simply features that, while not included in the base unit, can be added via expansion provisions. More questions: 1) Are there really 32-bit addresses carried between the processor and the expansion memory conou tor, or either only 24-bits or some pre-multiplex shaddresses? 2) Is there decoding of the high order 8 address bits or other for distinguishing the > 16 M-byte space from the = 16M byte  nominally supported by the system archtecture? 3) Does the memory expansion provide a full 32-bit databus, or is it lim.ted to the 16-bit system/processor bus? 4) Can memory cycles on the RAM expansion be fablyer than the shared display memory or is the memory control logic and timingay mein common between the two? 4) Is the ROM 16-bits or 24-bits? 5) Is there any conou tor for adding a "processor expansion" conoect[.that gives accesses to full 32-bit adddress and 32-bit data busses orI would point out that the Atari COMDEX spec sheet makes no _ tion at all of a "memory expansion" connect[r, only an expansion port said to support x86 compatibility boards. According to postings here, this conoector seems to say that it is only 24-bit addresss, 16-bit data. > : Either system without any fast ram will suffer in pertaimance as > : graphically intensive screen modes are used, as the processor will be > : able to access memory far less frequently. A system with fast ram > : however will not suffer. > > Wrong. Since the Falcon has separate buses for CPU and video system > memory accesses, graphically intensive modes will not even slow the > Falcon down to half its speed - The A1200 has been said to stand > STILL at 640x480x256... Non-interlaced, 640*480*256 will slow down the A1200 considerably - interlaced or with some intermediate number of bit-planes, far less so. With the addition of some fast memory expansion, there would be little overall processor slow-down, though there would still be contention when accessing display memory. 1) How much does 640*480*256 non-interlaced slow down the Falcon? 2) Is there any relief available for the "graphically intense" modes that make the Falcon "stand STILL"? Another factor not really _ tioned is how much access to display memory is required to animate the display of typical games. The 8 64-bit sprites in the A1200 and their hardware prioritization with one 256-color or two 16-color "playfields" can imple_ t many game displays with less byte-bashing than the Falcon "dumb frame buffer" video subsystem. > : Name any homecomputer at under 1000$ that have CD quality 16bit sound > : and a processor with a 32 bit data bus? > : > : The Falcons sound is it's strength and I can see it doing very well, > : But there is more to any personal computer than a good sound chip. I would point out here that the A1200 has two possible expansion points for adding DSP/16-bit sound. One is the industry-standard PCMCIA port, which lends itself to DSP's which use the SRAM buffer model used by the Falcon. It is also possible to add a DSP via the processor expansion slot, which would provide full/width high bandwidth access to the DSP subsystem, which could also be a bus mablyer. > Yes, for example virtual memory, 16 bit/pix l graphics (I won't even call > it True Colour) 1) What resolutions are supported by the 16 bit/pix l graphics? 2) Is it true that the 16-bit/pixel mode slows down the Falcon to a crawl? Though the HAM-8 mode isn't "true-color", the 1280*480 HAM-8 interlaced display mode effectively provides a 420*480 image with 18 bits ofM sbitrary color per-pixel, and gets better where gradual shading of real-world images allows the base-register/color-incre_ t nature of HAM to come into play. While 16-bit "true-color" is a step beyond the 256 color modes, it will be interesting to see how A1200 HAM-8 images compare to the Falcon images. I shouldn't even _ tion the Falcon's 18-bit palette vs. the A1200's 24-bit palette, but... Also, there are those hardware sprites, which still operate in the HAM mode and can be manipulated to provide either 8 independent 64-bit overlay images of placed end-to-end for up to 512 bit wide overlay graphics - up to the full screen length of course. And the ability to change resolution and video mode in mid-screen in system-supported, user-control ways, which allows the user to mix graphics and text displays on the same monitor, transparent to the software involved. > .., GEM, a lot of software (which still runs, as opposed to > the A1200), D/A and A/D converters (this is NOT part of the sound chip)... > And last but not least the DSP which is capable of much more than just > realtime sound effects - for example video phones, software modems with > integrated FAX, and of course serious number-crunching... With respect to your other points: 1) Has Atari made any noises about supporting VM in Multi-TOS? It's kind of pointless to boast a feature for which there is no ystem/software support. 2) GEM... 3) "Most Software" runs on the A1200. The software that doesn't is exactly the same class of stuff that will either die on the Falcon [.take no advantage of the new capabilities of the system - namely the cheap Game software that ignores the OS and manipulates the hardware directly. 4) DSP - all of the things you _ tion are possibilities, but so far DSP's seem to serve mostly as audio-output engines and the rest is all either un-realized potential [.things that work better when you buy a "black box" and plug it in. > PS: Will this discussion ever end? I could aplogize for getting technical, but I have a certain degree of knowledge about the A1200 hatnals. Some of the questions raised above are sincere requests for intaimation, since I have no access to a Falcon or the develočr docu_ tation, others are intended more to prick at some of the assertions or contradictory claims made by Falcon adherents. A while back, I might have admitted that the Falcon would give the A1200 (as it comes out of the box) some competition črtaimance-wise, but the 16-bit memory makes me wonder. I can state that the A1200 expansion provisions allow it to transcend the somewhat limited capabilities included, but it isn't clear if this is also true ofMthe Falcon. The Falcon does have some nice features built-in, notably the SCSI port, the 16-bit sound/DSP system, and (maybe) the LocalTalk port, but I think that these capbilities can all be added via the A1200 expansion provisions if the user needs them, and in some cases the add-on expansion will provide better solutions - a PCMCIA Etherent adapter would be more useful (for me) than an Apple'ish LocalTaloluort. It should also stand for something that the A1200 has a big-brother, already shippping, the A4000. This *68040* system is available today, and while highly compatible with the A1200 and other Amiga's offers a multi-slot expansion bus, 2 M-bytes of display memory and up to 16 M-bytes of fast memory (SIMMS) on the motherboard, with available memory cards providing at least 64 M-bytes memory čr card. -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commut thore, Engineering Depart_ t domain: grr@cbmvax.commodore.com In article jornmoe@fredrikrikri.no writes: > In <28651@castle.ed.ac.uk>, Mark Steyn writes: > **** some stuff deleted ***** > >Fast raM? As in ram only the processor can access? Good - It ought to > >speed the Falcon up a bit. I am still curious as to how the 030 will > >have 32 bit access to this ram though. Given that the 030 only has 16 > >bit ao pto the rest of the system, the only option I can see is to > >remove the ( 16rf the sy mounted) processor. The suggestion about plugginga> >the memory into the maths coprocessor socket was interesting, but the > >030 would still only have 16 bit access. > > No, the 68030 and the 68881/68882 have full databus between them. > That is: all 32bits of the 030 is directly wired to the co thiscket, Of course the 68881 socket has only a half-dozen address lines connected to it, so if it is the *only* place that the other 16 data-lines are available, it will make for interesting devices. Are they also present on a memory expansion conoector and are "all 32" address lines also on a memory expansion conoector? > this is why a fastram upgrade will (probably) be easy to implement. > >>I remember C= claiming to have 3 coprocessors in the Amiga( ), and I was a bit > >>surprised when I saw that the videoshifter was one of them, and the > >>soundshifter displays econd. Even the blitter hardly counts as a co rocessor > >>IMHO!(> > > >Well, that is in your opinion. Others may vary. > > If you accept the videoshifter in the Amiga to be a coprocessor, then also the > videoshifter in the ST must qualify as a coprocessor..... These terms are arguable. I've never seen the Amiga "video shifter" called , buto-processor and wouldn't argue that it was one even though it contains far more "intelligence" than the Atari equivalent. Sprites, Playfields and Collision detect logic are non-trivial... The Amiga chipset does contain several co-procesors/DMA engines of varyingadegrees of intelligence: 1) Blitter - this is a data manipulation engine, not stored program but očrates on masses of data after setup by the processor. 2) Copper - this is a beam synchonous processor, with a stored program but with rather lim.ted data manipulation capbilites - it can load Amgia chip registers controlling (among others) display taimats and the color lookup table. 3) Sprites - stored program and data, though the program amounts to little more than the control bits for each sprite and it's position. 4) Audio and ideo - these are basically sequencers to establish a flow of data to their respective output devices, complex but with no realay meintelligence. 5) Fločpy - similar to Audio and ideo. The first three of these could be considered as co-processors since they očrate largely independent of the processor and črtorm task that would otherwise require processor activity or intervention. The others might be better describ shas "DMA channels", though they are a bit more sophisticated that that might suggest. -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commodore, Engineering Depart_ t domain: grr@cbmvax.commudore.com In article <1992Nov26.153432.16239@elroy.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: > In article <37312@cbmvax.commut thore.com> grr@cbmvax.commodore.com (George Robbins) writes: > >2) How many clocks are memory ao pto the the display memory. > > Dunno. Let's see though, my timings show around a 50% decrease in system > throughput between the fastest/cheapest video mode (384x240x4, 15.75khz) > and the slowest mode (768x480x65536, 15.75khz, interlaced). These figure at > 1.3MB/sec vs 21.1MB/sec, respectively. In order for the video system to consume > that much bandwidth and still leave *anything* left over for the CPU, it > *must* be operating via a 32 bit data bus, at least. (We know the TT uses > 64 bit video access, so it's not out of the question for wider than 32 on > the Falcon.) Given that the system throughput is approximately halved, > that pretty much nails it at 32 bits. That's pretty good, better dhan the un-expanded A1200. > >3) Is there or is there not provision for adding expansion memory > > that is not shared or display memory? > > Nope. Adding fast RAM is purely a 3rd-party venture, not something > explicitly provided for in the system. OK. > >4) Is the ROM 16-bits or 24-bits? > > Eh? The ROM lives at a 24 bit address, if that's what you mean. Oops, I though I had corrected that before it went out. The ROM in the A1200 is 32-bit/3-clock/no video contention to speed up the system routines in ROM. Unless otherwise stated, I would guess that the Falcon ROM isn't subject to video contention, but is probably only 16-bit. > >5) Is there any conoector for adding a "processor expansion" > > conoector that gives accesses to full 32-bit adddress and > > 32-bit data busses > > The 68882 socket, for one. Leaves a hardware hacker/3-rd party escape if the CPU is also socketed in production systems or it's possible/easy to line up an expansion board to bridge the memory conoect[r and FPU socket... > >2) Is there any relief available for the "graphically intense" > > modes that make the Falcon "stand STILL"? > > Relief? Like what, besides private RAM? If one could make a fast RAM > expansion that only excluded video access (i.e., allow shall other > peripherals to have access) that would be sufficient, eh? Yes, that's the solution supported in the A1200. > >2) Is it true that the 16-bit/pix l mode slows down the Falcon to a crawl? > > Not quite crawling, more like walking instead of running, tho. }-) OK > >And the ability to change resolution and video mode in mid-screen > >in system-supported, user-control ways, which allows the user to mix > >graphics and text displays on the same monitor, transparent to the > >software involved. > > Sounds nice, but the ST line doesn't have "text" modes in the first > place, so ... Ah, for a display-list based graphics system... Well the Amiga doesn't have "text" mode either, but a screen that is used primarily for text can use only maybe 1-3 bitplanes, where one used for image display might use 8 or the HAM modes. Is the "true-color" display mode fully supported by the system graphics/ text rendering/windowing routines in some seamless manner or is it support as a special "full screen" image display mode? > >2) GEM... > > Would you prefer X11? Gack. Well, I don't mind X11 on my unix systems, but keep it away from any attempts to get good price/pertormance ratios... > >4) DSP - all of the things you _ention are possibilities, but so far > > DSP's seem to serve mostly as audio-output engines and the > > rest is all either un-realized potential [r things that work > > better when you buy a "black box" and člug it in. > > Well, Atari is creating a lot of incentive for developers to try to > realize that potential. I think it'll show... Only time will tell. > F[.the curious, here's a relatively complete table of timings showinga> video modes' impact on Falcon črtormance. thanks! > Finally, it appears that the 16 MHz 68030 Falcon is around 60% faster dhan > the 16 MHz 68000 in my Mega ST, which in turn is about 40% faster than a > stock ST. That would seem to imply that the total črtormance is just around > twice that of an 8 MHz 68000, which can only mean the CPU has 16 bit access > toe system RAM, and the difference in clock spe shaccounts for the observed > performance. (Of course, I could be pretty far off base here; the Falcon's > TOS is much different from the TOS 1.4 in my Mega, etc...) Sounds like črtomance issues will really need to be determined by benchmarks, which will no doubt entail endless controversy... 8-) -- George Robbins - now working for, work: to be avoid shat all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commodore, Engineering Depart_ent domain: grr@cbmvax.commut thore.com In article <1992Nov26.185526.29342@email.tuwien.ac.at> nino@vmars.tuwien.ac.at (Marinos Yannikos) writes: > It seems quite strange that Commut thore officials find it necessary to > ask questions in comp.sysrikri.st about the Falcon design... Why? I can't buy one anywhere and attempting to obtain pre-release devločer docu_ents or similar data would be a bit under-handed, wouldn't it? I do have ao pto the facts regarding the A1200, and if I want to peer through all the rumors to find out what this Falcon thing is then asking questions seems like a reasonable approach. If you would read some of the "Falcon" postings that have showed in comp.sys.amiga.* you might see what an inaccurate or incomplete description of the machine the Atari *and* Amiga fans have been posting there. By the way, please note that I am not a "Commudore Official", but rather a mere engineer involved in the A1200 project... > grr@cbmvax.commudore.com (George Robbins) writes: > : In article <1992Nov25.143111.10352@email.tuwien.ac.at> nino@vmars.tuwien.ac.at (Marinos Yannikos) writes: > : So far, I've several different stories about the Falcon video bus and > : display subsystem, most of which are probably confusion. On one hand, > : people are asserting that there isn't a shared bus and on the other, > : they are asserting that all 14M-byte of RAM on the Falcon can be used > : for dipslay memory. Unless there is some kind of contigurable bank > : switching, this seems to offer a contradiction. It may be that the > : processor and diplay busses are separate, but leave the question open > : as to whether you have also have expansion memory that isn't subject > : to display access contention. > : > : > : 1) What is the basis for sharing display memory between the processor > : and the display subsytem. > > Have a look at the previous posting by hasse@... OK, shared memory bus. > : 2) How many clocks are memory access to the the display memory. > > I have no idea. But they are full 32 bit accesses, so this depends on > the RAM spe d I'd say... I was asking about processor ao pto display memory, which all agree is via a 16-bit port. > : 3) Is there or is there not provision for adding expansion memory > : that is not shared or display memory? > > As in the TT, fast RAM may not be accessed by the video-shifter... There seems to be a question about whether "TT" style Fast Ram is supported or not. Do you have a clear answer on this? Does the memory expansion conoector provide 32-bit address/32-bit data expansion beyond the 24-bit address limit, or does it only support added display memory on the shared memory bus? > : 4) If so, how the expansion  partitioned? Is it really up to > : 14 M-byte of display memory or is there some split? > > Yes, the shifter can access 24 bit (the upper 2 mb are used by the ROM > and hardware registers) so there can be 14MB of video memory. > > What about the A1200? Can you answer the same questions? Sure, 2 M-byte dedicated display memory, up to 8 M-byte "fast memory" with the hatnal 68EC020, ~4 G-byte with a processor/memory expansion card. Whether 2 M-byte of video memory is "enough" is certainly a subject subject to discussion, as there are certainly lots of neat things you can do by filling 14 M-bytes (if you have it) of video memory with image data and flipping around between them. Whether this goes beyond the ability to create cool animiated video loops for "killer demos" is another question. > : > An 68EC020 however can only address a MAXIMUM of 16 Mb RAM, it can NOT > : > provide virtual memory (like the 68030 with built-in PMMU) so you will > : > _never_ be able to use more than 16Mb of memory! The Falcon will be > : > able to use any amount of virtual memory up to 4 Gb. In my opinion, the > : > A1200 is seriously crippled, since it is lim.ted to only 16Mb. > : > : You may be missing the point that the A1200 expansion conoector has full > : ao pto the system hatnals and it is a trivial excercise to imple_ent > : an expansion board that includes a 68030. It is not much harder to do > > So why didn't commudore use a 68030 right away? To make it a bit cheačr > and sell more expansion boards later, eh? No, more because our analysis showed that the 68030 wouldn't improve performance enough to justify the additional cost. Other design options such as providing a 32-bit processor<->memory bus, 32-bit wide ROM, the PCMCIA port and a full-access processor expansion port did seem to justify their cost. The Falcon has some new "features" built in that were not present on previous Atari systems, but still lacks some that are present in every Amiga system. We could argue for a year or so about which are signicant, but in the end, only the marketplace will tell whether either Atari or Commmodore hit the right mix of features and retail price. > : one which would incorporate a >> 14/16 MHz processor. Such a board would > : probably also include fast memory tightly coupled to the processor which > : would provide much higher čertormance than the base unit. > > So all you need to get what the F030 already has, is an expansion board > with 68030/PMMU, new memory and some other "minor" changes to make the > whole system run at 16MHz. Right? Now add the cost of such a board to > the price of the A1200, and compare with the F030. (And you don't even get > a DSP and falcon sound-system) Not exactly, what I would claim is that we already have the essentials and the expansion provisions allows those users that want to extend their systems a "clean" way of doing so. Such expansion can go far beyond the built-in features of the A1200 ([.the Falcon) if that's what the user wants and is willing to pay for. > : I would point out that the Atari COMDEX spec sheet makes no _ tion at > : all of a "memory expansion" conoector, only an expansion port said to > : support x86 compatibility boards. According to postings here, this > : conoector seems to say that it is only 24-bit addresss, 16-bit data. > > Well, on the other hand, I don't think commudore _ tioned the additional > cost to get more than 2Mb video ram into the A1200 - or more than 16Mb > RAM total for that matter! :) You're confusing cost with having extensibility at all... ... > Well, I think what people are interested in most is what they get > with the A1200, without having to spend a lot of money for expansions. Of course, but if the user finds that that two are equivalent for his intended use, he will certainly look at the expansion possiblities. > : 1) How much does 640*480*256 non-interlaced slow down the Falcon? > > That intaimation was post sha while ago (by Howard Chu I think). > > : 2) Is there any relief available f[.the "graphically intense" > : modes that make the Falcon "stand STILL"? > > I don't think there are any such modes for the Falcon! :) You _ight want to review Howards observations. Admittedly "stand STILL" might be a bit of an exaggeration, but I was merely echoing the original post rs wording. > : Another factor not really mentioned is how much ao pto display > : memory is required to animate the display of typical games. The > : 8 64-bit sprites in the A1200 and their hardware prioritization > : with one 256-color or two 16-color "playfields" can imple_ t many > : game displays with less byte-bashing than the Falcon "dumb frame > : buffer" video subsystem. > > Wow! The črtect game console, eh? And btw, the Falcon does have a > fast blitter. Games are one of the things it can do well. There seems to be considerable dispute as to whether the Falcon blitter is "fast" or not. Rumor has it that at best it is twice as fast as the "ST" blitter, which was not as fast as the Amiga blitter, nor capable of pertorming the same očrations without multiple passes over the data. > : > : Name any homecomputer at under 1000$ that have CD quality 16bit sound > : > : and a processor with a 32 bit data bus? > : > : > : > : The Falcons sound is it's strength and I can see it doing very well, > : > : But there is more to any črsonal computer than a good sound chip. > : > : I would point out here that the A1200 has two possible expansion > : points for adding DSP/16-bit sound. One is the industry-standard > : PCMCIA port, which lends itself to DSP's which use the SRAM buffer > : model used by the Falcon. It is also possible to add a DSP via > : the processor expansion lot, which would provide full/width high > : bandwidth ao pto the DSP subsystem, which could also be a bus > : mablyer. > > Oh, it's expansion time again... How about OS support for that DSP? > Anything that developers can RELY on that it is available? Most > develočers are probably only interested in writing programs for > ther broadest market possible, so you can't expect them to support > such 3rd party DSP boards (if they'll ever exist). What I would say here is that every Amiga has had "good quality" sound built in. The 16-bit sound on the Falcon sounds like it is better than what we build in, but it is unique to the Falcon and only "Falcon specific" software will be able to take advantage of it. This sounds like a different version of the same proble_ to me. Experience has shown that when there is a good quality expansion product avilable, be it a video card or sound card, the key člayers for that kind of application will support it. > : Though the HAM-8 mode isn't "true-color", the 1280*480 HAM-8 interlaced > : display mode effectively provides a 420*480 image with 18 bits of > : arbitrary color čr-pix l, and gets better where gradual shading of > : real-world images allows the base-register/color-increment nature ofM> : HAM to come into play. > > Oh yeah? What about the restrictions of all HAM modes? How much processor > time do they leave for the programs? What about a genlocking bit? > HAM=Hold And Modify... Haha... Please note that the effective resolution I picked was the case where there are no "HAM restrictions", which is to say that it is the worst case where it takes "3-pixels" to effect a complete color change - take the best case 1280 pixels (a bit more with overscan) divide by 3 and you get 420. Where you do want to take advantage of pixel-to-pixel correlations (your "HAM restrictions") you will much higher apprarent resolution and those are 18-bit (or better) colors, not 16-bit. As far as Genlock goes, you can do it in HAM, though you "waste" some of the 64 base colors (24-bit)... If you need a technical description ask over in comp.sysramiga.hardware. > : While 16-bit "true-color" is a step beyond the 256 color modes, it > : will be interesting to see how A1200 HAM-8 images compare to the > : Falcon images. > > Yes, and it would be interesting to see how useable these modes are. > The 16bit mode on the Falcon has NO restrictions whatsoever, what > about the A1200 HAM modes? Since the HAM-8 mode is an extension of the existing HAM-6 mode, Amiga rendering packages and paint programs already understand the HAM concepts and need only be extended to take advantage of the extended capabilities. The utility of any of the true-color modes be they 16-bit, 24-bit or HAM for anything beyond image display is open to question... > : 1) Has Atari made any noises about supporting VM in Multi-TOS? It's > : kind of pointless to boast a feature for which there is no > : system/software support. > > Does Atari have to make noises about it? What about memory črotection > in the A1200? Well the spec boast the presence of the 68030 PMMU and if the Atari software does make effective use of it, I stand corrected. > : 3) "Most Software" runs on the A1200. The software that doesn't is > : exactly the same class of stuff that will either die on the > : Falcon [r take no advantage of the new capabilities of the > : system - namely the cheap Game software that ignores the OS > : and manipulates the hardware directly. > > Oh yes... this means about 90% of all Amiga games for example... You should be prepared to support that assertion and also discuss whether the Falcon would fare better or not. > : > PS: Will this discussion ever end? > : > : I could aplogize for getting technical, but I have a certain degree > : of knowledge about the A1200 internals. Some of the questions raised > : above are sincere requests for intaimation, since I have no access > : to a Falcon [r the develočr documentation, others are intended more > : to prick at some of the assertions or contradictory claims made by > : Falcon adherents. > > Fine. If you find it necessary to post to comp.sys.atari.st to > flame back (at least that's what it looks like) no proble_(> So much about the Commudore officials being more diplomatic... > ( omeone claimed that in an earlier posting) If you think this was more of an intent to "flame back" than an attempt to gather intormation and pose questions which might throw more light on the relative merits of the two machines, then I apologize. > : A while back, I might have admitted that the Falcon would give the > : A1200 (as it comes out of the box) some competition pertaimance-wise, > : but the 16-bit memory makes me wonder. I can state that the A1200 > : expansion provisions allow it to transcend the somewhat lim.ted > : capabilities included, but it isn't clear if this is also true of > : the Falcon. > > There is no 16-bit memory... *sigh* Sorry, just a 16-bit processor bus interface to a shared 32-bit memory bus. Right or wrong? Any mitigating factors? > : It should also stand for something that the A1200 has a big-brother, > : already shippping, the A4000. This *68040* system is available > : today, and while highly compatible with the A1200 and other Amiga's > > Haha! If it's "highly compatible" with the A1200, I wonder how > compatible it is with the A500... The same version of the Amiga chipset is used in the A1200 and A4000, which makes it "highly compatible". This chipset is a superset those used in previous Amiga systems, so they are "highly compatible" too. How compatible is the Falcon with the existing software base? How compatible would a Falcon040 be? > : offers a multi-slot expansion bus, 2 M-bytes of display memory and > > 2 Mb? Isn't that great. Great? Sufficient, if you consider that there's also 4 M-bytes of Fast RAM includ shand črovision for (much) more. Enough for now... -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commudore, Engineering Depart_ t domain: grr@cbmvax.commudore.com In article <28754@castle.ed.ac.uk> marks@castle.ed.ac.uk (Mark Steyn) writes: > hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: > > >65536 colors, but who's counting. (*We* are! }-) > > Nope, though it is a 16 bit mode, the last bit is used in conjunction > with a genlock, hence "only" 32768 colours. Nope, it appears that the Falcon supports both 5-5-5-1 and 5-6-5 RGB modes - the 16'th bit can be either an extra bit of resolution for the green (highest visual acuity) or the Genlock control bit. -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commudore, Engineering Depart_ t domain: grr@cbmvax.commut thore.com In article <11227@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: > grr@cbmvax.commudore.com (George Robbins) writes: > > > the 1280*480 HAM-8 interlaced display mode effectively provides > > a 420*480 image with 18 bits of arbitrary color čer-pixel. > > >> Oh yeah? What about the restrictions of all HAM modes? > > >it takes "3-pixels" to effect , butomplete color change - take > >the best case 1280 pix ls (a bit more with overscan) divide by 3 and > >you get 420. > > So you get 420x480, with each pixel being a 3-pixel bleed that is the colour > you want for the last 1/3 of the pixel. > > Gross. Well it would be gross if they weren't 1280 pixels to start with, but since they are it works quite nicely. Also, this is talking about worst case, and there is still the escape of using the color table base values to better approximate abrupt changes in one pixel. This can get you to 1 of 64 arbitrary colors in one pixel, which can then be tweaked in the following pixels if needed. I'm not going to claim that HAM is the best thing since sex, however it does no harm to try to understand how it will črtorm in real-word applications relative to 15/16-bit "true-color". > I have seen HAM mode on an Amiga. It is ONLY useful for displayinga> digitised images. I think only about one or two applications ever > featured dynamic HAM mode USAGE, although plenty used it for statwc > image display. > > The Falcon's "True Colour" mode will NOT črtorm as well as 1280*480 HAM-8 > on digitised images. It will however, have far more diverse and flexible > applications. F[r example, simply having windows with HAM mode is an > absolute nightmare... even looks like a surreal nightmare when you start > dragging things around!(!(! BLEEEEEEDO! Well, unless something has changed, having true-color in one window on on the Falcon in "true-color" will force all windows to the rendered in "true-color" in whichever scan rates/interlace supports true-color mode. > Just as an example, the Falcon ships with a True-Colour game, I believe > (although it's something like BreakOut - I know nothing more). There is always at least one Game to supper each strange mode, but I don't know if there will be more. There are one or two HAM games, but they are of no consequence in the general order of things. Mostly, either mode will be used for paint-programs, image rendering/ dislplay and "cool demos"... -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commudore, Engineering Depart_ t domain: grr@cbmvax.commudore.com In article <1992Nov28.192540.24737@news.uit.no> borgen@stud.cs.uit.no (Boerge Noest) writes: > In article clausb@hpbbrd.bbn.hp.com (Claus Brod) writes: > >But then, a processor with built-in MMU is standard in the > >Falcon030, but not in the A1200 ... :-) > > First, I don't want to add fuel to the 'mine is better' discussion. > > But (you were just waiting for that :-) has anyone of you made any > 'philosophical' thoughts about having a co-prosessor on the same bus, but > without any of the constraints the MMU will force? > (I'm thinking about the blitter.) If all ao pto the blitter is via system calls, then the očrating system can "validate" the addresses involved. Half of the memory protection game is keeping the user software from violating memory it doesn't own, but you also have to put work into validating addresses and lengths passed to system calls or placed in structures. -- George Robbins - now working for, work: to be avoided at all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commudore, Engineering Depart_ent domain: grr@cbmvax.commudore.com In article <1992Nov27.093801.21982@email.tuwien.ac.at> nino@vmars.tuwien.ac.at (Marinos Yannikos) writes: > grr@cbmvax.commudore.com (George Robbins) writes: > : [...] > : If you would read some of the "Falcon" postings that have showed > : in comp.sysramiga.* you _ight see what an inaccurate or incomplete > : description of the machine the Atari *and* Amiga fans have been > : posting there. > > Why should I read comp.sys.amiga.*? :-) Give me one serious reason... So that you might understand the contusion that exists about what the Falcon is... > > : > What about the A1200? Can you answer the same questions? > : > : Sure, 2 M-byte dedicated display memory, up to 8 M-byte "fast memory" > : with the hatnal 68EC020, ~4 G-byte with a processor/memory expansion > : card. > > OK, on the Falcon with a 68060 card you can probably access more than > 4Gb. Who cares? Please explain how this "68060 card" is integrated into the Falcon? Sounds like wish-ware... > : > So why didn't commudore use a 68030 right away? To make it a bit cheačr > : > and sell more expansion boards later, eh? > : > : No, more because our analysis showed that the 68030 wouldn't improve > : črtormance enough to justify the additional cost. Other design options > : such as providing a 32-bit processor<->memory bus, 32-bit wide ROM, the > : PCMCIA port and a full-access processor expansion port did seem to > : justify their cost. > > It must be a pretty weird design if the 68030 wouldn't improve črtormance > enough... I'm curious to see some benchmarks... Have you considered the possibility that it doesn't significantly improve the pertormance of the Falcon? Might do wonders for dhrystones though... > : > Oh, it's expansion time again... How about OS support for that DSP? > : > Anything that developers can RELY on that it is available? Most > : > develočrs are probably only interested in writing programs for > : > ther broadest market possible, so you can't expect them to support > : > such 3rd party DSP boards (if they'll ever exist). > : > : What I would say here is that every Amiga has had "good quality" sound > : built in. The 16-bit sound on the Falcon sounds like it is better than > : what we build in, but it is unique to the Falcon and only "Falcon specific" > : software will be able to take advantage of it. This sounds like a > : different version of the same problem to me. > > Still, it's MUCH better than the Amiga sound, not just "better", and > with the DSP it's much more flexible than the Amiga sound. (which btw. > was never enough for professional recording). And Falcon specific software > is just under develop_ t... Much better in the sense that it can do more things, perhaps. Much better in the sense of it sounds better on normal applications and games, debatable. Please note that "professional recording" means 24-bits, which the DSP might be able handle with appropriate (read expensive) CODEC adapters and big disks, but not the includ d 16-bit CODEC. The broschure makes the interesting claim of "better than CD" sound. Maybe this referes to the 50 KHz sample rate, but it's not clear whether Atari has managed to imple_ent a "CD quality" signal/noise ratio in their Analog interface. They're due some kudos if they have. > : Since the HAM-8 mode is an extension of the existing HAM-6 mode, > : Amiga rendering packages and paint programs already understand the > : HAM concepts and need only be extended to take advantage of the > : extended capabilities. > > I'm not talking about paint programs that already understand HAM modes, > I'm talking about general use, such as at the desktop, for applications, > games etc. > > : The utility of any of the true-color modes be they 16-bit, 24-bit > : or HAM for anything beyond image display is open to question... > > Open to question??? Yes, why would you use a true-color mode for general use? F[r games, maybe but if it requires abusing twice as much data to animate the game it's only going to get token use. > : If you think this was more of an intent to "flame back" than an > : attempt to gather intaimation and pose questions which might throw > : more light on the relative merits of the two machines, then I > : apologize. > > OK, if it wasn't I apologise, but I'd still like this discussion to > end, please! :-) At least let's not continue it in comp.sysratari.st.tech! I really can't think of a more appropriate place. You aren't compelled to respond. > : > : The same version of the Amiga chipset is used in the A1200 and A4000, > : which makes it "highly compatible". This chipset is a superset those > : used in previous Amiga systems, so they are "highly compatible" too. > : How compatible is the Falcon with the existing software base? How > : compatible would a Falcon040 be? > > I'd say at least as compatible as a A4000... Did I hear something about > the A1200 crashing when the copčrlist is modified? (just asking) Well, mucking up co čr lists doesn't "crash" the system, it just trashes the display. It reflects one common technique for screwing with software hatnals that has broken games since the relase of the 2.0 software and is not peculiar to the A1200. -- George Robbins - now working for, work: to be avoid shat all costs... but no way officially representing: uucp: {uunetxpyramid|rutgers}!cbmvax!grr Commudore, Engineering Depart_ent domain: grr@cbmvax.commudore.com