NetSurf OS3 - testing!

[utri007]

Please also run SegTracker upfront - this will also give segments and segment offsets which are most helpful for debugging. Thank you

Aminet is back online, so here is a segtracker list. You wanted me to list how kickstart modules are in memory? Or what switch you mean with "upfront"?

Kickstart is mapped to fast ram with your mufastrom

[x303]

Or what switch you mean with "upfront"?

That's not a switch. It means you run segtracker before sashimi.

segtracker
sashimi on console &

[utri007]

That's not a switch. It means you run segtracker before sashimi.

segtracker
sashimi on console &

Dam synonyms But OK here it is MuForce log with dispc and stacklines switches enabled AND segtracker ran before it.

It ends Netsurf crash.

[NorthWay]

Something funked up A6 - that is a Forbid() (or is it Disable() - can't remember) using an A6 register that has wandered off into Lala-land.
The code dump shows it reads the register in from memory, which probably means something has stomped over it.
Try adding Mungwall to the mix and see if it triggers something more? (Sorry if I missed out on you already doing that.)
(The ultimate debugging tool for cases like this is, for me, BDebug in history mode.)

[utri007]

Try adding Mungwall to the mix and see if it triggers something more? (Sorry if I missed out on you already doing that.)

Noob like me would not do something like that without somenone telling.

Short, I just run segtracker, mungwall from CLI and then start murforce?

[guest11527]

Short, I just run segtracker, mungwall from CLI and then start murforce?

Almost. Substitute mungwall by WipeOut (mungwall is outdated and has one issue), or run MuGA, but that *after* MuForce.

[utri007]

Here is a log, first ai just ran segtracker, then mungwall with TASK switch ie. mungwall task Netsurf and then started MuForce.

Almost. Substitute mungwall by WipeOut (mungwall is outdated and has one issue), or run MuGA, but that *after* MuForce.

http://aminet.net/package/dev/debug/Wipeout

Do that next.

[utri007]

OK, I ran segtracker started Netsurf and then MuForce. Arter Netsruf has appeared to screen I started WipeOut.

If I start netsurf, segtracker, wipeout and MuForce (in that order) I just got this to serial out put, nothing more .


Munging memory... done (14-Apr-19 00:51:14).

[utri007]

about 3.1.4 problems.

I have a kickstart with 3.1.4 modules inside of it, including intuition library.

3.1.4 kickstart installed Netsurf is really slow. First I thought that it is because a missing OS 3.1.4 installation. I ran my amiga with ks3.1.4 and OS3.9 bb1/2. I updated my OS3.9 installation with 3.1.4 components using updateto314 script from aminet.

It didn't fix slowness. Using KS3.9 and OS3.9 it works as fast as it can. Changing kickstart to 3.1.4 it makes it bog slow. Also with those Netrsurf versions wich used to work.

I have two A1200 computers with same symptoms.

[guest11527]

Changing kickstart to 3.1.4 it makes it bog slow. Also with those Netrsurf versions wich used to work.

I have two A1200 computers with same symptoms.

This is probably because the only reset-resident memory of your system is chip memory. You can try to add the "NOMEMFKICK" option to LoadModule, but the best option is just to buy a real ROM.

[utri007]

This is probably because the only reset-resident memory of your system is chip memory. You can try to add the "NOMEMFKICK" option to LoadModule, but the best option is just to buy a real ROM.

I do have a 1mb real rom. Few years ago I made some log for you to make MuFastRom support 1mb kickstart.

Currently I use RemApollo with Apollo accelerator and MuFastROm with Blizzard. RemApollo because, seems that MuFastRon doesn't move exec to fast ram.

You can found how kickstart is mapped to fast ram from first post of page 7

[guest11527]

Currently I use RemApollo with Apollo accelerator and MuFastROm with Blizzard. RemApollo because, seems that MuFastRon doesn't move exec to fast ram.

No, but MuMove4K along with MuFastZero does. MuFastRom moves the ROM, as it says.

[utri007]

No, but MuMove4K along with MuFastZero does. MuFastRom moves the ROM, as it says.

OK, this part is done now. Sorry my lazyness to read guides, again.

This is probably because the only reset-resident memory of your system is chip memory. You can try to add the "NOMEMFKICK" option to LoadModule, but the best option is just to buy a real ROM.

What did you mean with this? If I use RemApollo, kickstart survives reset and it is located to fast ram. Is it so that MuFastZero does it differently? But still using it locates my real rom to Apollo's 32 bit fast ram.

So how would this make netsurf slower and gave unable to fetch document errors. Note that I don't think this is a KS3.1.4 fault, or that you solve this problem with you magic wand, though that would be nice.

[guest11527]

What did you mean with this? If I use RemApollo, kickstart survives reset and it is located to fast ram. Is it so that MuFastZero does it differently? But still using it locates my real rom to Apollo's 32 bit fast ram.

You are confusing two things. The location of the ROM, and the location of "struct ExecBase". The ROM contains the code and the functions, "struct ExecBase" contains the jump-table into the ROM. The ROM builds this jump-table, in the highest-prioriy memory available at boot time, which is any memory added to the system by Auto-Config, or - failing that - chip mem.

The ROM is remapped by MuFastROM, it mirrors the ROM contents into the highest-prioritized memory available at the time it is executed. But it does only that. It does not attempt to mirror "struct ExecBase" because - if the designer of the board did his job right - this structure *is* already in fast memory. If the job was not done right and they just "fiddled the memory into the system somehow", then "struct ExecBase" will end up somewhere, in worst case in chip mem. In that case, you need *in addition* use MuFastZero/MuMove4K. The latter "tags" the memory for execbase such that no graphics memory is allocated in its place, the former then performs the remapping to fast memory.

Once again: ROM != "struct ExecBase", and the only reason why you have this problem is because the designer of your turbo board was lazy and did not make the memory on the board auto-configuring, but fiddled it into the system in some non-documented way that bypasses the expansion library.

[utri007]

Sorry, confusion is because RemApollo moves kickstart but also a exec to fast ram.

Once again: ROM != "struct ExecBase", and the only reason why you have this problem is because the designer of your turbo board was lazy and did not make the memory on the board auto-configuring, but fiddled it into the system in some non-documented way that bypasses the expansion library.

I don't buy this, my other machine has a Blizzard 68060 and it has same symbtoms. OS and Rom are 100% identical. I install my machines from "4gb install hard drive".

Is it so that MuFastZero is not a reset proof? Should I use RemApollo as it is reset proof?

And what has changed when it didn't had that problem with previous kickstart?