HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/13/91)
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. But I have no hope MINIX will boot on that TT. C.v.W.
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/15/91)
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. > > 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. 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. 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. Andy Michael -- Andy Michael "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton - `House of Cards' Middlesex email: eesrajm@brunel.ac.uk UB7 9PA or Andrew.Michael@brunel.ac.uk
hyc@hanauma.jpl.nasa.gov (Howard Chu) (03/19/91)
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!
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/19/91)
well... I found that all addresses in staddr.h are wrong, you have to change 0x00FFXXXX ==> 0xFFFFXXXX perhaps I can test MINIX after this modification. I think a severe problem might be situation where the ST polls an I/O-port without telling the cache to be quiet.... but I do not know if this happens C.v.W.
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (03/23/91)
In article <48126@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: [Some stuff deleted] > I think a severe problem might be situation where the ST polls an I/O-port > without telling the cache to be quiet.... but I do not know if this happens > > C.v.W. This is a hardware feature which I hope Atari have got right. The TT wouldn't run otherwise. It is up to the memory decoding logic to assert the CIIN pin when in the I/O area in order to stop the cache being loaded. Not getting this right is a common problem when trying to put an '030 in an existing '020 system (grin) !! Andy Michael -- Andy Michael "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton - `House of Cards' Middlesex email: eesrajm@brunel.ac.uk UB7 9PA or Andrew.Michael@brunel.ac.uk