@wawa

understood...

What I'm trying to do here is simply use AROS as the "Kickstart ROM" and see just what it can do on "real" Amiga hardware, in this case an 060 using OS3.5...

Even with it's current stage of development I'm actually getting somewhere I have it running with OS3.5 Workbench (of course there are glitches & crashes but that's to be expected) but so far it's performing better than I had thought...

It means I don't have to use that "Wanderer" thing (I believe they're doing away with that anyway) and use Workbench instead for these tests...

I have my favourite file manager "DirWork" up and running quite well under AROS now so that's making things a bit easier (few colour and gfx glitches but nothing that makes it unusable)...

Think the problems I'm having are with these version 50+ files like DIR as they are not part of any standard Amiga release from 3.0 to 3.9 (not even OS4.0 which are 50+ versions but are in PPC)...

I'm going to try and write a script (or program if need be) that will assign the C: drawer (and whatever else needs assigned) to AROS specific ones that come with the distro witch should solve this part of the problem...

Those giant icons are a nightmare though, shame the developers wont change their minds about them as they really are a pain in the neck on real Amiga hardware...

_________________

@Franko


Jason's reply on icon sizing.

http://aros-exec.org/modules/newbb/viewtopic.php?post_id=64609#forumpost64609

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@Franko

this is of course a valid way of testing to see how aros kick behaves with 3.5 system. there are people testing it against 1.3 to ensure widest compatibility, but then it might be necessary to be very systhematic about it to narrow down the problems. im too lazy for that.

@terminills

Quote:

terminills wrote: @Franko Jason's reply on icon sizing. http://aros-exec.org/modules/newbb/viewtopic.php?post_id=64609#forumpost64609

Cheers for that..

Think I'll just have to make sure when I download any new distros that I simply skip the icon files, simple enough to do I suppose just makes things take a wee bit longer though...

@ Wawa

It's going to take me a wee bit of time to iron out these issues here, so I think I'll make a quick video showing AROS's speed on an 060 using Workbench 3.5 as it is...

Won't be quite as was I was planning on doing and will be a wee but kludgy but it'll give folk an idea of how fast AROS currently is using an 060 with regard to opening windows, resizing them etc...

Last edited by Franko on 07-Mar-2012 at 08:08 PM.

_________________

@wawa & Olaf

Gawd... this is turning into a major task getting it to work "reasonably" on an 060...

Main problem I'm finding is the lack of CHIPMEM (Gfx Mem) once AROS has installed itself like a KickStart...

Can't figure out why but there is only less than 900Kb of chip ram left out of the 2MB of chip ram...

This is even before the startup-sequnce has been executed and so is nothing to do with the screenmode set by iPrefs from the ENV:SYS/ screemmode.prefs file...

Just wondering if this is normal and if AROS uses a lot of chip mem during it's bootstrap operations as this is the main cause of the problems I'm having right now, the lack of chip mem/ gfx mem...

Do either of you know if this is "normal" or is there something I have to do to stop AROS using all the chipmem up before it even does anything !!!

Cheers

Franko

_________________

@Franko


I think the problem is the kickstart is being mapped to chipram. I will ask Jason if there is a way to change that.

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@terminills

Quote:

terminills wrote: @Franko I think the problem is the kickstart is being mapped to chipram. I will ask Jason if there is a way to change that.

I was wondering if that's the case myself, there is no way of checking where it has mapped in, I would have expected it to be in Fast Mem but I can't get any of my diagnostic tools running on it to see exactly where it's being mapped too...

The only clue I can get is from the Avail command but it shows more than enough memory being used up in both chip ram and fast ram, so I can't be sure where exactly it's being mapped too...

Would be able to find out if I could get some of my tools up and running but the lack of chip ram is either causing them not to run as they can't open their windows or just simply crash the machine...

If you can find out for me that would be much appreciated, thanks...

_________________

@Franko

Quote:

Just wondering if this is normal and if AROS uses a lot of chip mem during it's bootstrap operations as this is the main cause of the problems I'm having right now, the lack of chip mem/ gfx mem...

does it? i hadnt that impression but i have to check i admit.
this would have to beoversight of course. mapping rom to chip makes completely no sence, especially performancewise.
i rather think that consumption of chipram might be due to icon library computing displayable bitmaps for 25 bit icons and the like.

btw to avoid runniing out of chipram i wonder if it was possible to introduce a mechanism that could temporarily swap invisible background screens to fast ram.

besides your requested feature scaling icons is just being worked on. whadda you say?

Last edited by wawa on 09-Mar-2012 at 11:08 AM.
Last edited by wawa on 09-Mar-2012 at 11:07 AM.
Last edited by wawa on 09-Mar-2012 at 11:04 AM.

@wawa

Even booting up AROS without the startup-sequence into it's native screen resolution 640 x 256 there is only 870Kb of Chip Ram left as AROS seems to be using more than 1.2MB of it for something else...

After getting a few debugging tools up and running these have shown this to be the main reason for crashes and things simply not working as there is just not enough Chip Ram left for programs to open their screens or windows...

So as it stands because of the inability to run much more than one util at a time (providing it doesn't crash) then it's very hard to get it to do much or use debugging tools to help work out problems...

Oh well, it was interesting at least just to get a glimpse into AROS on "real Amiga hardware but as it stands there's not a lot one can do with it...

_________________

@Franko

i will look into it as soon as i am in my studio where the miggys stand. if you are right that might be another thing to look at the sooner the better. in the meantime you might test aros with a gfx card if you have one available (i guess not?) i can provide you with instruction how to get one running. its quite simple.

@Franko

one reason of higher chip consumption i just thought about : you may have noticed that aros unlike original 1.x-3.x allows to move windows outta the visible desktop. this obviously requires having memory reserved for that which i assume is chipram. i will talk to the devs about how that might be solved better.

@wawa

Nope, no GFX card I'm afraid, even though I own a BlizzardPPC I never managed to get hold of a GFX card for it and these days I wouldn't bother getting one anyway as it would be of very limited use to me...

The way I've developed my Amiga's over the years was always to consider that the vast majority of Amiga users don't own or use a Gfx card (let alone a PPC) so I've always made sure everything I write or do on the Amiga would work & fit in on it's native screen resolutions...

It's the only way I like to use an Amiga now and so a GFX card is not something I even consider anymore...

There's no need to look into it, I've checked it thoroughly using 4 different 030 boards and an 060 (still wont work on a Blizzard060/PPC board though) and the result is the same on each board, 1.2MB of Chip Ram eaten up even before the Startup-Sequence gets a chance to run...

Must be AROS itself using the Chip RAM for something but what, I don't know but the result is not enough Chip RAM left to do anything useful with...

_________________

@wawa

Quote:

wawa wrote: @Franko one reason of higher chip consumption i just thought about : you may have noticed that aros unlike original 1.x-3.x allows to move windows outta the visible desktop. this obviously requires having memory reserved for that which i assume is chipram. i will talk to the devs about how that might be solved better.

Could well be, I had noticed that and thought it was a bug, pretty weird and annoying when you go to resize a window and the mouse drags part of the lower & right hand borders of the visible screen, thanks for confirming that as like I say I thought it was a glitch/ bug...

_________________

Quote:

wawa wrote: @Franko one reason of higher chip consumption i just thought about : you may have noticed that aros unlike original 1.x-3.x allows to move windows outta the visible desktop. this obviously requires having memory reserved for that which i assume is chipram. i will talk to the devs about how that might be solved better.

Original also allows this when using PowerWindows, and afaict it doesn't result in such a chip ram consumption. So I think the reason for this problem is to be searched elsewhere.

@Franko

strange thing is that im using superhires interlace as desktop admittedly with a lower color depth such as 3-4 exaclty to save some chipram, and i seem to remember to have still a lot chip (close to 2 megs) available after bootup to wanderer. i admit though chip is being soon ate up opening further screens. would be a thing to find a solution for as i said.

im by no means trying to imply you should buy a gfx card..

@Franko

Quote:

Could well be, I had noticed that and thought it was a bug, pretty weird and annoying when you go to resize a window and the mouse drags part of the lower & right hand borders of the visible screen, thanks for confirming that as like I say I thought it was a glitch/ bug...

ist not a bug but a feature ive been waiting for so long using powerwindows in the meantime.
workbench has been so annoying with just some windows up coming in your way all the time.

@Ball000

Quote:

Ball000 wrote: Quote: wawa wrote: @Franko one reason of higher chip consumption i just thought about : you may have noticed that aros unlike original 1.x-3.x allows to move windows outta the visible desktop. this obviously requires having memory reserved for that which i assume is chipram. i will talk to the devs about how that might be solved better. Original also allows this when using PowerWindows, and afaict it doesn't result in such a chip ram consumption. So I think the reason for this problem is to be searched elsewhere.

Like I said the result is the same each time on the different boards I've tested 1.2MB of Chip RAM gone just by simply kicking up with AROS, nothing running, not even the startup-sequence launched...

So what is using all this has to be happening during the bootstrap and actual initialisation procedures of AROS and why that is I have no clue whatsoever...

_________________

@wawa

Quote:

wawa wrote: @Franko strange thing is that im using superhires interlace as desktop admittedly with a lower color depth such as 3-4 exaclty to save some chipram, and i seem to remember to have still a lot chip (close to 2 megs) available after bootup to wanderer. i admit though chip is being soon ate up opening further screens. would be a thing to find a solution for as i said. im by no means trying to imply you should buy a gfx card..

Like i say even without the startup-sequence and the Amiga kicking up into its default 640 x 256 4 colour screenmode, 1.2MB is gone leaving only 800KB before the startup-sequence even gets a chance to use up even more mem by using your screenmode.prefs via iPrefs...

I'm really wondering if for some reason AROS it putting its "ROM image" into Chip RAM and not Fast RAM here for some reason or producing a copy of it in CHIP RAM as well as FAST...

Think i'll fire up a Monitor program and scour the entire CHIP RAM to see if this is the case (provided I can get one to run long enough without crashing)...

_________________

@Franko

Can it be that the nightly build is dedicated to emulation of A1200 (2 MB Chip, no Fastmen) so that it uses (wastes) the chipram for the Kickstart?

@Franko

booting to aros68k with cv64 on my a4k gives me 2meg chip ram and 139,2 fast ram free upon wanderer is open.


edit:
booting to aros68k without gfx support on wanderer being set to pal highres-interlace 3bitplanes depth leaves me with 1.6meg free chip and 139,2 fast upon wanderer is open.

below i allow myself to quote an answer i just have received from toni on this subject:

Quote:

> post 152 for instance. the guy is testing aros on different amiga > hardware setups without gfx and claims to lose 1.2megs of chip ram at > bootup. i cant exactly confirm but i have noticed aros to be soon First check is to boot without startup-sequence: still 1.2M chip available? If yes -> Blizzard A1200 turbo (1230/1240/1260)? Those boards have non-autoconfig (configured by "diag" boot rom, not using autoconfig logic) fast ram which means it is unusable for softkicking, forcing rom image to chip ram. MMU is used to remap it to fast (if 68040/060) so it won't cause any slow downs but it still wastes chip ram.. There are workarounds but it is not trivial, not really worth the trouble at this point and it can break other expansions rom code. A3000/A4000 don't have this problem because they always have usable fast RAM (at least as long as MB Fast RAM chips/SIMMs are installed). btw, there really is reason why serial logging is required..

Last edited by wawa on 09-Mar-2012 at 03:14 PM.