Re: FW: [MiNT] Best CAB.OVL for MiNT-Net? (fwd)

[Odd Skancke <oskancke@online.no>]

On Sun, 24 Oct 1999, Torsten Lang wrote:

> Hi Odd,
> > 
> >  Yes, I did use splitram (by Bernd Ebert, I think). But now I use my own
> >
> splitram was done by myself since otherwise some programs cause trouble. Since
> Fredi didn't split the Hades accessory into AUTO folder part and ACC like I
> asked him for again and again I did write this little proggy.

 Yes, I know for sure that my machine runs a LOT better with the ram
split. ;-)

> > really is the problem somehow. And I'm investigating it.
> > 
> The trouble stays even with Fredis new RagePro driver. As far as I can see there
> are two possible reasons for these problems:
> 1. The PCI bus itself is not very stable on the Hades. I gave up trying to
> install an scsi card Fredi wrote a driver for. Depending on the positions of
> gfx board, ethernet board and scsi board I got scrambled images (or none at all)
> or the ethernet board was not found or the scsi board (or at least my harddrive)
> were not found or behaved strange. The PCI gfx boards only behave stable when
> the processor cache is disabled...
> 2. The gfx board itself dislikes very fast accesses to its I/O area. I already
> saw this misbehaviour on ET4000W32 boards together with NVDI).

 I think Martin found the problem for me ;-) Someone said that to get the
Mach64 to function correctly in his AB, he had to mark the I/O and memory
area as cache inhibited, Precise model (or non-cahcable, serialized as the
040 books calls it). And this is what the config file for set_mmu.prg
comes with, but I also remembered that the pci memory area was covered by
the trasparent translation settings in those files. In addition, I vaguely
remembered reading that the transparent translation regs are consulted
before the translation tree when determing the access-mode to a given
logical address. So, I asked Martin if he could try to turn off the
transparent translation, and voilah, his machine now works with set_mmu
;-) This really made me happy, because I just didn't understand what was
wrong. So, Torsten, if you have access to a RagePro Hades, could you
please test this? Could be that it even fixes some of the other problems
mentioned above.

 Atm, I'm trying to write some drivers on my own, and I have a Mach64 with
the ATI-264VT2 chipset. This card is responding as I expect it to on the
PCI-bus, so I don't think there is anything wrong with the Hades PCI bus.
Mind you, I'm no expert on these things, but the code I work on can now
initiate and setup this card, while the et6000 and a PCI64 is also on the
bus. I haven't done any real tests, like DMA programming and such, but
most of the specs I have looked at says PCI rev 2.1 compliant. And knowing
that the 2.0 rev was consulted for the Hades PCI, this could be a factor
for any problems we have. The real fun starts, I guess, when I want to
implement DMA playback/recording drivers for the PCI64. The docs says that
only burst-mode DMA transfers are possible with this card. I don't know if
this will work on the PCI specs rev 2.0 bus in the Hades. I wonder if it
would be possible for Fredi to update the PCI-chips to be 2.1 compliant..

 Btw, Torsten, do you own a Milan too? 


 Anyway, this was very much offtopic. If these things are too offtopic to
be on the mint-list, let me know, and I'll stop it...



 Odd Skancke - ozk@atari.org