@m3x

5.WORKBENCH:> WORKBENCH:WBStartup/Sam440ep_setup verbose

Found a Sam440ep

Patch #1 ------------------------------
OLD SPR[0x03b2]: 0x000d0000
NEW SPR[0x03b2]: 0x00010000

Patch #2 ------------------------------
Found a Radeon GFX card
BaseAddress = 0xa8000000
Size = 134217728 bytes
POM2 pre : a8000000
f8000003
a8000000
0
POM2 already in use... not patching


Just for information.

Size: 134217728 bytes ??? not 64 MB.

Quote:

Why with SAM440, we are limited to 50 MB/Sec for WRITE ?

thanks for the Sam440 Patch for the READ speed and we have big chance Crisot made Ragemem !

@samo79 and kas1e

Thanks for looking on warzone

For sure, not aproblem is not the last version but explain why on the readme (if this game for AOS4 will be finished) for not receiving lots of requester for the last version

@ssolie

Quote:


A hidden stack on AOS4 secure program with GUI if the programmer put less than 60ko of stack on his code source of his program.

You recommend 80ko on the code source of the program (example code on one of the previous thread).


- And for the stack on the Icon ? (become not usefull at all).

- This advice also true for shell program or for shell program ported fom linux ?

Hello,

If I use program like scout or stacksnoop (triton+68k), I can see verry big stack used by programs (on the task list) and just few stack really used when the program run on the system.

In fact most of the workbench original programs from AOS use 65ko of stack on the scout.


- Scout or another stack reporter program report really the good number of stack used by all the program on AOS4.1 ???

- Why big stack for all WB programs used on AOS4 ???


NOTE: This is strange to see a big program like dopus4 use just 8ko and contextmenu used 65 ko !!!

@kas1e

gdb nzbget

give a DSI:

Crash log for task "gdb"
Generated by GrimReaper 53.2
Crash occured in module elf.library.kmod at address 0x015320F8
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 0001656C 59E347C0 00000000 0100DE54 01529FEC 01503924 01503924 00000000
8: 008C0000 0000000C 008C0000 014154A8 24424048 00000000 5A8F4BC8 59E40000
16: 59E348D8 5AD0D3E0 5A8F4B40 01CA97C4 00000000 5A01C4A0 80000001 59E3FBE0
24: 59E40000 59E34818 00000000 80000001 00000000 5AD0D3E0 0152B6F4 5A01CAC0


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 2.11725e+214 1.18795e+190 3.29513e+180
4: 1.16106e-72 2.69823e+78 7.05954e+64 1.96185e+247
8: 4.25323e+174 1.0296e-71 1.20586e-71 1.97412e+26
12: 5.73688e+228 9.80175e-72 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 1.61029e-231 0

FPSCR (Floating Point Status and Control Register): 0x82000000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x44424042
Instruction Pointer (ip) : 0x015320F8
Xtended Exception (xer) : 0x20000003
Count (ctr) : 0x014154A8
Link (lr) : 0x015320F0
DSI Status (dsisr) : 0x00000000
Data Address (dar) : 0x00000008



680x0 emulated registers:
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x015320F8 belongs to module "elf.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module elf.library.kmod+0x000081f8
native kernel module elf.library.kmod+0x000026e8
native kernel module elf.library.kmod+0x000061f4
module gdb at 0x6F725C28 (section 5 @ 0x21C08)
module gdb at 0x6F725F00 (section 5 @ 0x21EE0)
module gdb at 0x6F70B808 (section 5 @ 0x77E8)
module gdb at 0x6F710190 (section 5 @ 0xC170)
module gdb at 0x6F70EB44 (section 5 @ 0xAB24)
module gdb at 0x6F710BD8 (section 5 @ 0xCBB8)
module gdb at 0x6F710C28 (section 5 @ 0xCC08)
module gdb at 0x6F710CE0 (section 5 @ 0xCCC0)
module gdb at 0x6F704C5C (section 5 @ 0xC3C)
module gdb at 0x6F70EB44 (section 5 @ 0xAB24)
module gdb at 0x6F710BD8 (section 5 @ 0xCBB8)
module gdb at 0x6F710C28 (section 5 @ 0xCC08)
module gdb at 0x6F7041DC (section 5 @ 0x1BC)
module gdb at 0x6F704198 (section 5 @ 0x178)
module gdb at 0x6F8DAF30 (section 5 @ 0x1D6F10)
module gdb at 0x6F8DB3B0 (section 5 @ 0x1D7390)
native kernel module dos.library.kmod+0x0001b524
native kernel module kernel+0x00036290
native kernel module kernel+0x00036310


PPC disassembly:
015320f0: 813d0024 lwz r9,36(r29)
015320f4: 801f0030 lwz r0,48(r31)
*015320f8: 817c0008 lwz r11,8(r28)
015320fc: 7c004b96 divwu r0,r0,r9
01532100: 935c0004 stw r26,4(r28)


And If I use attatch to GDB:

GNU gdb 6.3 (AmigaOS build 20050719)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-amigaos".
Reading symbols from WORKBENCH:SDK/C/gdb...(no debugging symbols found)...done.
0x00000000 in ?? ()
(gdb)


But If I do the same with another tool, I haven't crash. My example is compiler on cross-compiler on Linuxbox and also I have just the minimal SDK installed with your GDB.

Kas1e, do you have a more recent GDB somewhere ?

EDIT:

Hum, as db101 also crash with the same example, maybe the example is wrong or the elf.library.kmod (update2 one) not work also with gdb ? (I know elf.library.kmod from update2 not work well with db101).

EDIT2:

hum, copied elf.library.kmod from update1 to the amiga and make a cold reboot. same test and same DSI.

EDIT3: removed some ?

Thanks.

@kas1e

zaphod has beeen translated in french by murakami and proofreaded by me.

don't know if alleady relased or not (not remember).

will ask

@nubechecorre

Uboot 06/2010: Hum, interesting (we have uboot 04/2010).

@samo79

http://fabportnawak.free.fr/misc/

I haven't checked if source is on the fab archive port for morphOS...

@samo79

Quote:

And you haven't tried with the MorphOS FAB1 version ???

@Fransexy

No allways the Boost port missing (or be updated).

Boost came verry verry often as a problem for porting something

@Joeled

boring at job. Somed reaming for you

http://www.gamingonlinux.info/item_search.php

or

http://www.moddb.com/games

Need to found opensources games on the link (indie ?)

@samo79

Quote:

effectively, this project exist on sourceforge.

http://sourceforge.net/projects/warzone2100/

Do you have tried to 3.0 beta or version 2.x ???

@all

see this thread here:

http://amiga.comscripts.com/phpBB/viewtopic.php?topic=100&forum=2

- an archive
- a sourceforge link
- some a fxgroup comments and work
- .....

@kas1e

Epiar seemed to be verry good. It's great to try to have at least one kind of range of game for AOS4.

dangerdeep: submarine.
warzone 2100: strategy realtime.
epiar: space simulation aka epic.
spring1944: WW2 simultaion, etc....

or another example of course (for sure I like a lot FPS and more against computer than on an arena).

thanks a lot for your work on theses games

@Joeled

visual C++, SDL and FTTW mainly (Maybe It's possible).

I think kas1e will port this game just for not seing us on amigans too often !!

@kas1e

this is great to see good feedback from original opensource game authors. I really would like to know their reactions when you said that the post will be for an Amiga computer...

@RNS-AMiGA-Club

Quote:

Hello to you and welcome here ;)

First loaned SAM440 found

What is your project with the SAM ??

@all

on the 56 mhz grab, MMU is in use

thanks for the memory timing explanation also.

Understand more the accelerator card now.

@Joeled

Don't give me a silent service for AOS4 !!!! (I have played 68k silent service 1 and 2 a lot).

I could kill for this game (like spring 1944 for example).

strategy WW2 games.

@HammerD

yes, I have seen after on the amikit site that is modern RAM on the accelerator.

with 56mhz, the accelerator board will be a verry good success.

user informations:

- blizzkick will be usable with this board ??

- amikit could post a memory test (or better CPU speed test) between this card and a blizzard 030 ?? (hum, curiosity, curiosity