[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Improving Performance



Stefan,

Yes, the Falcon IDE is not too fast. But loading the OS needs 10 minutes.
That can't honestly be the fault of a slow IDE bus.

Just saying your comparison wasn't entirely fair.

I wouldn't mind losing all ST RAM. The option to NOT load kernel into
ST RAM is there, but it simply hangs. I guess this is because of the
Atari tries to allocate video memory in ST RAM, which in this case is not accessible, correct?

Correct.

People that need to use ST RAM because the have too little TT RAM, could still use the -s kernel option and enable ST RAM for kernel.

Perhaps an option to specify the video RAM adress space is easier to implement to the existing memory model?

The address space set aside for video still needs to be mapped. The current stram_alloc() interface does reqire that mapping to be set up by the generic memory map initialization first. That's what I mentioned below - I haven't found a quick and easy way to change that at first glance. Suggestions welcome - I can't spend much time on this at present.


There is an PCI bus upgrade to the Falcon, which enables tu use ATi Radeon 7500-9250 cards and there also exists (i have this) a Supervidel. Supervidel is an extension card to the Falcon 060 upgrade. Its register compatible to the original Videl graphics chip of Falcon 030.

Both, ATi Radeon and SuperVidel have video RAM outside the ST RAM.
Thus a kernel option like "VRAM = adress" would probably get it going...

I'm aware of other video options - some will need to write the necessary code to make use of these.

Adding an option to the atafb video driver make use of the SuperVidel hardware would be the easiest option. The SuperVidel base address is fixed, and it can use any chunk of FastRAM for frame buffer, presumably?

In that case, it might be sufficient to change the fixed Videl base address to a variable one in the atafb driver, and perhaps use kmalloc instead of stram_alloc to allocate the frame buffer. If someone with access to this hardware is interested in giving this a try, I'd be happy to elaborate.

(You'd need to compile your own kernels, and having a serial cable between the SCC modem port and some other computer for capturing kernel boot logs would be a clear bonus.)

Cheers,

	Michael




Greetings,
Stefan


Am 08.03.2014 00:19, schrieb Michael Schmitz:
Stefan,

your point regarding ST-RAM performance is well taken - in fact, it has
been raised before. Repeatedly.

What keeps us from placing the kernel in TT--RAM is the simple fact that under the current memory model used by m68k, we will lose all of ST-RAM
for use by either the kernel or user space. Traditionally, the memory
chunk that the kernel is located in will be the first chunk listed in
the bootinfo, and also the first one to be initialized for use by the
kernel. The currently employed memory model does require memory chunks
to be in ascending order. ST-RAM as second chunk violates that
assumption. There may be a way to make use of defined portions of ST-RAM
as IO memory, but that has not been tested so far. I need to look into
how much effort this would take.

Switching to a different memory model will need someone to dig into the
arcana of memory management - this ought to be possible to test on
ARAnyM. Both Atari and Amifga stand to benefit from this, by the way.
The port has recently procured RAM expansions for Amiga that don't work with the current memory model either, and need a different memory model for much the same reason. What we lack is someone with enough Linux and
m68k memory management skills, apparently.

Bear in mind that disk I/O on the Falcon is bound to be slower than on
the Amigas (IDE on the slow bus vs. SCSI, I would presume). If you're
feeling bold, give the Falcon SCSI driver a try, but please apply all of
the recent patches posted to linux-m68k first.

Cheers,

     Michael


Am 08.03.2014 um 06:33 schrieb Stefan Niestegge:

Hi debian/68k people,

i know, while using Aranym for running debian-68k on Atari-compatible
machine, it doesn't make a noticeable (if any) performance difference
to boot the kernel with -s option (put Kernel in ST-RAM).

But if you run it on a real 680x0 machine, which in my case is a
Falcon with 100 MHz 68060 CPU, 512MB TT-RAM (read: FAST RAM, clocked
at full CPU clock on a 32 bit bus) and 14MB ST-RAM (read: SLOW RAM,
16MHz on a 16bit bus), there is a huge performance loss.

Last weekend i attended to a computer meeting, where someone ran
debian-68k on his Amiga 1200 (Blizzard 1230 CPU upgrade, 50 MHz CPU
clock, 64MB FAST RAM (but iirc on Blizzard 1230 RAM clock is half CPU
clock). This machine _easily_ outperformed mine, though having much
lower raw power.

Wouldn't it be the right way to fix the Atari-branch kernel to get
it running from TT RAM as on the Amiga? The Amigas 2 MB Chip RAM is
not used by the linux kernel, only for video-RAM.

If some developer lives halfway near me, i'd even lend him/her my
(precious) Falcon to have hardware to test.

I am on my way to write a good debian-68k install walkthrough for
Atari Falcon, because its quite tricky to get it running.

But with this poor performance, i don't know if its worth the effort.


Any suggestions are very welcome, i have my Falcon set up on my main
desk and latest debian-68k is installed. Network support works nicely.
I even compiled my favorite console IRC client on it.

greetings,
Stefan


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Archive: [🔎] 531A0303.7000600@osnanet.de">https://lists.debian.org/[🔎] 531A0303.7000600@osnanet.de




--
To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 531B272C.2050108@abbuc.de">https://lists.debian.org/[🔎] 531B272C.2050108@abbuc.de


Reply to: