czei@osupyr.UUCP (Michael S Czeiszperger) (01/01/70)
In article <1660@ulowell.cs.ulowell.edu> page@swan.cs.ulowell.edu (Bob Page) writes: > >So why are people complaining? > >They're not. One person read one article in a magazine that stated >the version of the music program he tried didn't handle MIDI well. >The normal forces of USENET mangled that observation into a couple >of religious wars and machine bashing, as well as tons of theoretical >banter from the Amiga folks, but Peter still didn't get an answer. I hate to break up your catch-all answer, but I've read comments in MIX Magazine where a certain freelance writer made noises about how the Amiga cannot timestamp income MIDI events with an greater accuracy than ~20-30ms. This rumor was repeated in other magazines, thus giving it credibility. (I subscribe to no less than 6 music and technical journals, giving me lots of information, but a terrible time remembering where I read what) Michael S. Czeiszperger | Disclaimer: "Sorry, I'm all out of pith" Sound Synthesis Studios | Snail: Room 406 Baker Phone: (614) College of the Arts Computer Lab | 1971 Neil Avenue 292- The Ohio State University | Columbus, OH 43210 0895 UUCP : {decvax,ucbvax}!cbosgd!osupyr!czei
bryce@COGSCI.BERKELEY.EDU (08/19/87)
In article <628@cup.portal.com> Henry_Burdett_Messenger@cup.portal.com writes: > > These memory systems are *all* compatible with the new blitter chip, and, > unlike the Amiga, all memory on the ST is created equal (no "fast" and > "slow") Oh, come on!! If you are going to claim a feature "win" of the ST, pick one of the real feature "wins". Using the Amiga terminology of "fast" and "slow" memory, *all* Atari ST memory would be defined as "slow". Sure, two types of memory can cause problems (especially for developers with only one type...), but at least you get to reap the benifits! Facts, not flames. (Replace "slow" with "chip" to be more technically correct.) > Henry B. Messenger, a DECperson, but in no way representing Digital. > USENET: henry_burdett_messenger@cup.portal.com CIS: 72477,3356
sansom@trwrb.UUCP (Richard Sansom) (08/21/87)
In article <8708191439.AA07072@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU writes: >In article <628@cup.portal.com> Henry_Burdett_Messenger@cup.portal.com writes: >> >> These memory systems are *all* compatible with the new blitter chip, and, >> unlike the Amiga, all memory on the ST is created equal (no "fast" and >> "slow") > >Oh, come on!! If you are going to claim a feature "win" of the ST, pick >one of the real feature "wins". Using the Amiga terminology of "fast" and >"slow" memory, *all* Atari ST memory would be defined as "slow". I think you got this one wrong. The ST's memory is clocked at 16MHz - the odd cycles belong to the CPU, and the even cycles belong to the DMA chip (or the other way around). In this way, there is never a time when the CPU is idle due to "stolen cycles" (during screen refreshes). I think that means the ST's memory should be defined as "equal" as the fellow stated in his original article. >Facts, not flames. Ditto. -Rich -- /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /// Richard E. Sansom TRW Electronics & Defense Sector \\\ \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA /// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/22/87)
In article <2489@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: )In article <.AA07072@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU writes: )>In article <628@cup.portal.com> Henry_Burdett_Messenger@cup.portal.com writes: )>> )>> These memory systems are *all* compatible with the new blitter chip, and, )>> unlike the Amiga, all memory on the ST is created equal (no "fast" and )>> "slow") )> )> Oh, come on!! If you are going to claim a feature "win" of the ST, pick )> one of the real feature "wins". Using the Amiga terminology of "fast" and )> "slow" memory, *all* Atari ST memory would be defined as "slow". ) )I think you got this one wrong. The ST's memory is clocked at 16MHz - the )odd cycles belong to the CPU, and the even cycles belong to the DMA chip (or )the other way around). In this way, there is never a time when the CPU is )idle due to "stolen cycles" (during screen refreshes). I think that means )the ST's memory should be defined as "equal" as the fellow stated in his )original article. Wrong again. The situation you describe is exactly the way the Amiga's "slow" memory works. *Exactly*. The memory in the Amiga that runs at twice the processor speed, and shares alternate/odd cycles with the video is "slow". Read the posting... "Using the Amiga terminology of "fast" ^^^^^^^^^^^^^^^^^ and "slow", *all* Atari ST memory would be defined as "slow". This is true. The Amiga also can access fast memory. The memory allocator has a bit for "fast". True "fast" memory is *not* shared with the video at all. Even if the Amiga is displaying a lo-res screen with 64 colors/line (*twice the ST's maximum*) _and_ running the blitter to do an area fill, "fast" memory is 100% avalable for the processor. If you manage to get an Atari blitter and then do a blit your ST's processor will hit a slowdown. Thus it's "slow" by Amiga terminology. As was said in the part of the article you chopped off, "chip" is the more technically correct term for what people call "slow" memory on the Amiga. BTW: The ST will have "stolen cycles" on instructions that don't hit even video/ processor slots. Check carefully, I think that you will find that "exotic" instructions (like all the branches and branch subroutines :-) will often cause a wait of two clocks. Amiga "slow" memory = ST main memory = "chip" memory (= "equal" memory :-) >>Facts, not flames. >Ditto. Di-Ditto. Please check your "facts". ----- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "You are welcome to prove me wrong, but make sure I'm wrong first."
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/22/87)
In article <> I wrote: >...is displaying a lo-res screen with 64 colors/line (*twice the ST's >maximum*)... Aw crum. Sorry to take up more bandwidth... that should have been *four times* and not *twice*. 4 bits = 16 colors. 6 bits = 64. -Arghhhh! They have cooling-off periods for gun purchasers... now how about the same for netnews? :-) :-)-
jesup@steinmetz.steinmetz.UUCP (Randell Jesup) (08/23/87)
[ This is NOT a flame. As Rich Sampson says, Facts, not Flames ] In article <2489@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: >In article <8708191439.AA07072@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU writes: >>In article <628@cup.portal.com> Henry_Burdett_Messenger@cup.portal.com writes: >>> These memory systems are *all* compatible with the new blitter chip, and, >>> unlike the Amiga, all memory on the ST is created equal (no "fast" and >>> "slow") >>Oh, come on!! If you are going to claim a feature "win" of the ST, pick >>one of the real feature "wins". Using the Amiga terminology of "fast" and >>"slow" memory, *all* Atari ST memory would be defined as "slow". >I think you got this one wrong. The ST's memory is clocked at 16MHz - the >odd cycles belong to the CPU, and the even cycles belong to the DMA chip (or >the other way around). In this way, there is never a time when the CPU is >idle due to "stolen cycles" (during screen refreshes). I think that means >the ST's memory should be defined as "equal" as the fellow stated in his >original article. ... > /// Richard E. Sansom TRW Electronics & Defense Sector \\\ Factual point: Just as the ST's memory is clocked at 16Mhz, the Amiga's is clocked at 14Mhz. If you use the Amiga with a 640x{200,400}x2 screen (4 colors), the screen refresh doesn't steal from the processor either. You can, if you wish, trade processor speed for more colors, unlike the ST. Yes, all ST memory is created equal. It loses little by that, as it was not designed for high-bandwith color (640x400 in more than 4 colors) and was not designed for a blitter with multi-tasking. The ST memory system is appropriate for the rest of the hardware/os design. As Richard says, Facts, not Flames. Randell Jesup jesup@steinmetz.UUCP (uunet!steinmetz!jesup) jesup@ge-crd.arpa
pes@ux63.bath.ac.uk (Smee) (08/24/87)
Well, everyone is close in describing the ST memory. Including my first try if it's escaped. The real true story is -- The ST memory is approximately 125 nanosecond memory. It is clocked at the same notional 8 MHz as the processor. (Or maybe I should say 'referenced' at the notional 8 MHz, since I don't know that it's not a multi-phase clock.) The video shifter references the memory at a guaranteed 4MHz. It is given alternate memory reference cycles by the memory management chip. It always, and no matter what gets every other reference cycle. The CPU and any other DMA devices attached compete for the remaining 4MHz. The 68000 CPU is not capable of generating a memory reference every clock cycle -- the best it can do is a ref per 2 clock cycles. (And usually this is the pattern it follows.) So, generally speaking once the CPU has got one of the 'every other cycles' available to it, it will tend to stay out of step with the video shifter, and so a 'free' (non-video) memory cycle will be there when the CPU wants to hit memory. Occasionally (with some rarer instructions) the CPU will want a memory ref an odd number of cycles after its last previous one. In this case, the CPU will be 'stalled' for one cycle by the memory manager in order to force it back out-of-step with the video shifter. Also, the CPU may occasionally get out of phase due to the fact that the CPU and the video shifter are not tightly synchronized. (The shifter, after all, has to work to the sync rate required by the monitor.) If the CPU and the video shifter drift into phase, again the memory manager will stall the CPU for one cycle to bring them back out of sync. The video chip always wins. Any other DMA devices (e.g. hard disk) steal cycles from the CPU. (The video chip *always* wins.) According to the 'official rumours', the probabilistic memory access rate of the 68000 running normal sorts of things is such that very few cycles need to be stolen from it to keep it out of step with the video shifter. This 'feels' reasonable by subjective comparison with the apparent response of 68000 machines which do not have video shifters running at a 'half the references' priority guarantee. Ultimately, though, this is all irrelevant. There is **NO** best machine in an independent and objective sense. Taking everything into account (task to be done, price and availability of hardware, price and availabitlity of software, 'feel' (which effects user productivity), quality of service available from local dealers, etc...) one machine *can* be better than another *for a particular user with a particular set of needs*. Among other things, this is how the 8086 machines have held on for so long. It would make life a lot more pleasant if everyone would keep firmly in mind that just because machine X is the best *FOR THEM*, it doesn't therefore follow that it is the best for everyone. I can't think of a machine on the market which isn't the IDEAL machine for some particular purpose...
peter@sugar.UUCP (Peter da Silva) (08/24/87)
In article <2489@trwrb.UUCP>, sansom@trwrb.UUCP (Richard Sansom) writes: > In article <8708191439.AA07072@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU writes: > >In article <628@cup.portal.com> Henry_Burdett_Messenger@cup.portal.com writes: > >> These memory systems are *all* compatible with the new blitter chip, and, > >> unlike the Amiga, all memory on the ST is created equal (no "fast" and > >> "slow") > >Oh, come on!! If you are going to claim a feature "win" of the ST, pick > >one of the real feature "wins". Using the Amiga terminology of "fast" and > >"slow" memory, *all* Atari ST memory would be defined as "slow". > I think you got this one wrong. The ST's memory is clocked at 16MHz - the > odd cycles belong to the CPU, and the even cycles belong to the DMA chip (or > the other way around). In this way, there is never a time when the CPU is First of all, the man was being nice crediting Atari with a blitter in the first place... 'cos it ain't soup yet. This has nothing to do with the existing DMA... this has to do with the as-yet-unseen ST blitter. Secondly, as the man pointed out, when the Amiga is running in the modes available to the ST (640 by 200 by 16 colors, or 640 by 400 by 2 colors), it also runs without having any cycles (unicycles :->) stolen. When the ST blitter appears, it will steal cycles. But (like the Amiga blitter) it's still a net win: it makes the machine faster. Which is the bottom line, isn't it? -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
page@ulowell.cs.ulowell.edu (Bob Page) (09/09/87)
peter@sugar.UUCP (Peter da Silva) is continuing to ask "What's wrong
with the Amiga's MIDI?"
Nothing. So why are people complaining?
They're not. One person read one article in a magazine that stated
the version of the music program he tried didn't handle MIDI well.
The normal forces of USENET mangled that observation into a couple
of religious wars and machine bashing, as well as tons of theoretical
banter from the Amiga folks, but Peter still didn't get an answer.
The package was EA's DMCS version 1, which didn't handle MIDI very
well. Don't bother asking WHY it didn't handle it well ... why
are there bugs in operating systems? Certainly not because the
hardware is bogus. The application software just didn't work right.
DMCS version 2 now has working MIDI. All the other software packages
commercially available for the Amiga that support MIDI do not have
the problems that the original DMCS had.
So is there a MIDI problem on the Amiga? No, and there never was.
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} page@ulowell.cs.ulowell.edu (Bob Page) (09/11/87)
czei@osupyr.UUCP (Michael S Czeiszperger) wrote: >I've read comments in MIX Magazine where a certain freelance writer >made noises about how the Amiga cannot timestamp income MIDI events >with an greater accuracy than ~20-30ms. Ah, well... now we get to the root of the matter. This observation on the part of the freelance writer is false, of course. The fact is, the Amiga has no problems with MIDI. One package once did, the new packages do not. Some programmers took what they considered to be a shortcut (using the device meant for normal serial communications) and found that it was not designed for MIDI. It's partially the fault of the device driver for allowing people to think that MIDI data rates mean MIDI support. Once again ... all the currently available MIDI programs that I have seen, commercial and public domain, do NOT have any problems with MIDI timestamping. Anything else? ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}