Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jato!hanauma!hyc From: hyc@hanauma.jpl.nasa.gov (Howard Chu) Newsgroups: comp.os.minix Subject: Re: MINIX on an ATARI TT Message-ID: <1991Mar19.024108.23177@jato.jpl.nasa.gov> Date: 19 Mar 91 02:41:08 GMT References: <47446@nigel.ee.udel.edu> <2034@Terra.cc.brunel.ac.uk> Sender: news@jato.jpl.nasa.gov Organization: SAR Systems Development and Processing, JPL Lines: 72 Nntp-Posting-Host: hanauma.jpl.nasa.gov In article <2034@Terra.cc.brunel.ac.uk> eesrajm wrote: >In article <47446@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >> Today, I tested a slightly modified MINIX (32-bit exception vectors) on >> a TT. It did not boot, but I must say that there was a high-resolution >> 19''-monitor attached to the TT, so I did not expect it to boot. >> If will look at the drivers if there are 24-bit I/O-adresses, if so, I >> have to recompile the stuff and re-test. Hm, I thought the MMU was set up to map these to the proper 32bit address anyway, but I guess it can't hurt. At least, it'll save a longword address fetch. >> But I have no hope MINIX will boot on that TT. >> C.v.W. > >I'm no more surprised about this than you are :-) > >In fact I'm beginning to wonder if a version of MINIX which runs on an '020 >will run without modification on a '030 anyway. A couple of Amiga owners have >told me that AmigaMINIX with my suggested mods will run on an '020, but >no-one seems to have had any joy on an '030. I wonder if this something >peculiar to the Amiga, or whether it's about time to think about things like >flushing the caches on a context switch. Since I don't have anything with an >'030 in it (apart from a 3/80 which is busy running SunOS) I can't really >experiment. As long as no hardware registers are involved, I can't imagine the caches becoming inconsistent. Who knows... >Whilst thinking about the TT, I have been told by a fairly reliable source >that the TT only has 80nS dynamic RAM in it. This sounds like about three or >so wait states for a 33MHz '030, which suggests that there isn't much >improvement over the 16MHz developer versions. Or to put it bluntly, the 33MHz >part is basically just a marketing ploy. Dunno 'bout the actual DRAM chip speed, probably correct. The original TT design was centered on a 16MHz 68020, Atari scrapped it for 68030 midstream and the 32MHz part was definitely an afterthought. The TT RAM uses nybble-mode chips, though, not just single-bit chips. This supports the 68030 burst mode, allowing it to grab 4 longwords in 4 cycles. So, for sequential access, no wait states. If you're branching outside the cache, I guess you might lose, but again, I don't know the actual speed of the TT DRAMs. > >I've also been told that the lower 4Mb of the TT memory (the so-called ST RAM) >is only 16-bits wide. If this is so, then the TT is not going to be much of >an increase in performance over the Mega STE. Correct, the lower 4MB of RAM is identical to the 4MB in a 68000-based ST. 16 bits, interleaved with video. Accessible by the ST DMA, e.g. ACSI and floppy drive, and probably the digital sound as well. This basically means that all "interesting" I/O is going thru 16bit memory with 8MHz bandwidth. The TT RAM previously described does not share its bus with anything other than the TT SCSI; I don't think any cycles are lost in that setup. What this really means is that to get ST Minix running properly on the TT, you're going to need to do a little more work... In TT TOS there is a new Malloc routine that lets you select either slow ST RAM or fast TT RAM. For TT Minix I would be inclined to force all user-mode memory requests to come out of TT RAM, and only let particular device drivers touch ST RAM. I suppose that would make user-mode animation code impossible, but would probably speed up everything else. Of course, this is also impractical because some people may have more ST RAM than TT RAM and not appreciate being cramped like that. (Considering that the TT will be sold in 2/2 configurations as well as 4/2 or 4/8 or whatever [ST/TT RAM]) -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here! -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!