Chipmem usage different from real machine?

mombasajoe · 11 February 2010, 23:30

It´s not really a problem but I am indeed interested in why the following happens. If you look at the attached screenshot-combo you see a worbench on a TV-set with about 1.737 free chipmem and a WinUAE-workbench with about 1.924 free chipmem. Both "Amigas" have just booted, nothing else has been done. TV-set = my real 68010 A500+ with 2 MB Chip, Kick 3.1 and an ALFA-Power-controller mith 8 MB Ram and a 1 GB CF-card as HD. WinUAE = full ECS, 2 MB chipmem, 8 MB fastmem, Kick 3.1 (not A1200 of course), 68010.....and the same CF as HD (= really the same workbench).

Did I configurate WinUAE a wrong way? Where comes the difference from? The Workbench is based on the ClassicWB 68k, in the startup-sequence only DECIGEL (for 68010) and ADD32BIT (for 8 MB) have been added by me. But - as said before - in WinUAE it is the same CF-card.

??

Galahad/FLT · 11 February 2010, 23:32

Isn't it to do with Hard drive buffers being different in WinUAE? I.e. thats taken care of by WinUAE outside of Amiga memory?

mombasajoe · 11 February 2010, 23:35

I do not know...but even the "other" memory is different

Photon · 12 February 2010, 00:11

Looks like about 200k of 'stuff' end up in chipmem on your real Amiga, whereas in WinUAE 'your type of' fastram hasn't been added, but rather 'just fastram'.

If you boot without startup-sequence and type avail at first power-on, do you have 0mb fast then? I think it's just a matter of fastmem not being available for the kickstart to put stuff in, before it boots from any disk - whereas on WinUAE the fastmem IS available during reset.

This is the case for my 68040 board with 4MB, before I run Init040, I had 0MB fastmem.

You can get around it simply by inserting a 512k slowmem expansion in the trapdoor. I think I have one extra with clock left over if you want to buy it.

Mad-Matt · 12 February 2010, 00:19

Id have said the difference would be that under winuae, rom libs (and wb) are being put in fastmem durring boot time. This isnt happening on real amiga as fastmem doesnt exist until add32 is seen so all the libs are in chip mem.

That said, the chipmem use should be higher for uae too to show the hires 8 colour screen/backdrop.

mombasajoe · 12 February 2010, 08:38

Okay, the WinUAE fastmem ist available when starting the emulation, the 32-Bit mem of the ALFA-controller isn´t. Good Idea. That´s sounds logical to me. Maybe it´s a mixture of this and what Galahad said. I´ll try what happens without any RAM except of chipmem.

Quote:

Originally Posted by Photon

You can get around it simply by inserting a 512k slowmem expansion in the trapdoor. I think I have one extra with clock left over if you want to buy it.

It´s an A500+, not an A500. There is already an 1MB expansion inside the trapdoor. A 512kb expansion would reduce 2MB chipmem to 1,5 MB chipmem (a plain/unmodified A500 would have 0,5 chipmem and 0,5 slowmem with such an expansion, that´s right)

mombasajoe · 12 February 2010, 17:51

I disabled the 8 MB

The A500+ now has about 1.391 free chipmem, WinUAE has 1.390. So I think the ideas are right. Thank you very much!

ceztko · 12 February 2010, 20:21

I think there so many variables to consider that very few computer/console emulators are able to offer a system with predictable, 100% correct memory consumption "emulation".

mombasajoe · 12 February 2010, 23:30

Sure, but in my opinion that example was very extreme (I wanted to optimize my WB on WinUAE and thought "wow! soooo much free chipmem!" then have started my A500 and thought "oops!?"). It´s just good to know that this is not a matter of WinUAE-configuration so I can stop trying.

Photon · 22 February 2010, 18:37

Great

But if you want, you could still try to make your real Amiga put the OS stuff in Fastmem.

You can check if your fastram automounts by putting 'avail' on the first line of the dh0:s/startup-sequence. Could you do that and report if it shows fastram?

You already have kick 3.1, so if the ram isn't auto-added at boot by the kickstart, maybe there is some utility Aminet that does it? I had one for a 68030 board once which I put first in the startup-sequence. On cold boot it ran, reset, and the fastram was always available until power-off.

Since you have a 68010, maybe there is a slim chance that you could add the line 'CPU FASTROM' after the FastRam-command for your board, and it would work?

(I forget if that just copies the whole ROM to fastram, or if there is another switch to move the kickstart's used memory to fastram.)

mombasajoe · 24 February 2010, 00:27

I´ve already tried some things. But there is a problem. My workbench is a slightly modified "project.ClassicWB6k". It messes something up with the "reset-proof" 32bit-RAM. Everything works fine but after a reset I get a yellow screen, the 32bit-RAM is "gone".

So I made a boot-disk for testing. The startup-sequence contains the following:

Add32bit-special resetfest (means "reset-proof")
wait 2 sec (it´s time to eject the disk now)
reboot (makes a reset)

After the reset:

-32bit-RAM is still available
-Workbench boots (HD)
- 128kb more free chipmem
- SysInfo says: The libraries etc. are now in 32bit-RAM

The next try was to play with the HD-startup-sequence to get rid of this bootdisk. The quick´n´dirty solution I´ve thought of was this one:

Preparation: Copy a file with the name "switch0" to the HD (as a flag)
Then change the HD-startup-sequence:

*************
IF EXISTS switch0
add32bit-special resetfest >NIL:
rename switch0 switch1 (use filename as a flag)
reboot
ENDIF

rename switch1 switch0 (unset flag)

[...]

*************

...and yes, you´ve guessed right: This ended with an error at the command "rename switch1 switch0": "Volume is not validated"
Actually I haven´t got any idea how to solve this problem. At least I think that there are only two ways:

1.
Find out why the reset-proof 32bit-RAM doesn´t get along with a reset from ClassicWB (this can take weeks)

2.
Find another solution containing a forced reset during the booting-procedure without getting a "not validated"-error (no idea how)

or...okay...

3. Let it be. Keep the boot-disk if some extra chipmem is needed.

Photon · 24 February 2010, 03:19

I don't really see why the bootdisk startup-sequence commands won't work just because you boot from harddisk?? You would think that all you had to do was paste that bit at the start of dh0:s/startup-sequence.

But I guess you're using the disk eject button instead of a 'flag', right?

I guess that disk doesn't include a reset command but that you do it manually? Otherwise I don't see why using that command would reset properly.

Haven't used add32bit, but it really should have a resetproof flag as option, and a flag to reboot if it's not set. In an ideal world

If you find that it doesn't have that, maybe there is a substitute.

Why ClassicWB's reset command doesn't work (if it came with it, I don't know?) is unknown, maybe it's a special command which requires some ClassicWB initialization before invoking, or just works in WB.

Anyway, it doesn't work, so you should use another reset command that works.

Volume not validated: if your harddisk setup has been working reliably for writing files before, then it's a strange error. If you type 'info' after it happens again, does the harddisk volume say 'Read/Write' or 'Validating'? If Validating, then something is unreliable in the setup or filesystem, or you need to BindDrivers first.

If it's the rename command that for some reason is buggy(?), then you could use the Move command instead, or 'Makedir dh0:MemOK', or any number of commands that will be able to make a change on the harddisk.

cosmicfrog · 24 February 2010, 07:55

move , rename are essentially the same command

mombasajoe · 24 February 2010, 18:35

Problem solved. I´ve chosen alternative ... 4....
An also quick´n´dirty compiled GFA-Basic prg

It´s now the first entry of the HD-startup. The code is like this:

-check if available mem is < 3MB
-yes: execute add32bit and execute reboot
-no: do nothing

Works fine. The Amiga boots, installs fastram, resets and then boots the full startup-sequence. No manual reset. No boot disk. No yellow screen when resetting from wb. Available chipmem: 1.866 at HiRes x8 and with background picture.

If think that I´ll leave at that way. It´s fine the way it is.

thomas · 24 February 2010, 18:57

Quote:

Originally Posted by mombasajoe

...and yes, you´ve guessed right: This ended with an error at the command "rename switch1 switch0": "Volume is not validated"

1. this is not an error. You just need to wait until the HDD stops working, then click on Retry to continue.

2. you missed the "wait 2" before the reset in you startup-sequence. This would let the HDD access finish before the reset.

3. have you checked all options of add32bit-special ? Doesn't it have an option to reset if the memory is not present and to silently continue if it has already been added ?

mombasajoe · 24 February 2010, 20:48

Quote:

Originally Posted by thomas

1. this is not an error. You just need to wait until the HDD stops working, then click on Retry to continue.

Okay...but that isn´t a smart start up, is it?

Quote:

Originally Posted by thomas

3. have you checked all options of add32bit-special ? Doesn't it have an option to reset if the memory is not present and to silently continue if it has already been added ?

I have no docs about add32bit. If somebody knows with which options add32bit does the same it would be very nice to know. The little GFA-prg (compiled incl. the necessary libs < 8kb) runs fine though.

Photon · 25 February 2010, 12:10

Heh, yes I was about to mention a wait in there, but I held my tongue. Adding a wait command is such a s-seq programming failure

If you want to 'just fix it', use a conditional+a mouse button checker command. At first power-on you hold left mousebutton and it adds the resetproof ram, then you can reboot as much as you want, and you won't need to modify a file on the hdd and wait before rebooting.

I coded MouseCond for this type of thing, but certainly there are plenty of alternative ones.

If the reboot command doesn't work, get one that does (and really there must be plenty of reboot commands that work), or in the worst case add a wait or let the s-seq end to allow a manual reset.

But Christ Almighty, Add32bit really should have an autoreboot switch. Did you try typing "add32bit -help" or something in the shell? Didn't find it on aminet, so if you want you could upload it to The Zone?

mombasajoe · 25 February 2010, 21:16

I´ve found German docs for add32bit: There is nothing written about a reset-flag. I´ve zoned it all (prg+doc). I´ve also watched add32bit-special inside a hexeditor (ASCII only) and did not find anything that looks like that. So I guess that there simply isn´t such an option.

I also think that there are some misunderstandings (please don´t hurt me if this is not true

)

1.The yellow-screen-error
-------------------------
Has nothing to do with the "reboot" command of ClassicWB. So what happens?
- Amiga boots the workbench (incl. "add32bit-special resetfest" in s-seq without any resets)
- Workbench-screen opens
- 32bit-mem is active
- everything works fine (except of the high chipmem usage as described in the first post)
- now (from workbench) a MANUAL reset brings a yellow screen (Amiga+Amiga+CTRL) -> Crash, memory is gone

2. The non-working "rename-switch0-switch1-solution"
-----------------------------------------------------
-a changing filename is used as a flag
-no manual reset
-reset is performed by the command "reboot" in the s-seq
-leads to "not validated" during the second boot

3. The working bootdisk-solution
-------------------------------
Works this way:

-insert disk in DF0: and turn Amiga on
-s-seq (DF0: ) does "add32bit-special resetfest" and "reboot" (two commands)
-in the moment of the reset (caused by "reboot"-command) eject the disk manually
-Amiga boots Workbench from HD
-everything works fine (much chipmem, no yellow screen after manual reset, 32bitMem is reset-proof)

4. The working GFA-Basic-App-solution
-------------------------------------
- Amiga boots
- resets (app activates 32bit mem and executes "reboot"-command )
- Amiga boots again
- app does nothing because it recognizes that the mem has already been activated
- workbench is loaded
- everything works fine (much chipmem, no yellow screen after manual reset, 32bitMem is reset-proof)
- no manual steps needed (no mouseclick, no manual reset, no disk to eject)

Photon · 01 March 2010, 01:11

So you have no problems anymore, did I get that right? That some GFA-app runs fine really didn't tell me anything, especially since you didn't write its function. I guess it's something that calls add32bit and reboots if needed.

Thx for zoning, I'll grab those files for future reference - if you want you can upload them to aminet too, as they don't seem to be there.

mombasajoe · 01 March 2010, 07:58

Hi...I´ve described it in post #14

Yes, everything runs fine now. A big "Thank you!" for your ideas.

22 February 2010, 18:37	#10
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	Great But if you want, you could still try to make your real Amiga put the OS stuff in Fastmem. You can check if your fastram automounts by putting 'avail' on the first line of the dh0:s/startup-sequence. Could you do that and report if it shows fastram? You already have kick 3.1, so if the ram isn't auto-added at boot by the kickstart, maybe there is some utility Aminet that does it? I had one for a 68030 board once which I put first in the startup-sequence. On cold boot it ran, reset, and the fastram was always available until power-off. Since you have a 68010, maybe there is a slim chance that you could add the line 'CPU FASTROM' after the FastRam-command for your board, and it would work? (I forget if that just copies the whole ROM to fastram, or if there is another switch to move the kickstart's used memory to fastram.) Last edited by Photon; 22 February 2010 at 19:00.

25 February 2010, 12:10	#17
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	Heh, yes I was about to mention a wait in there, but I held my tongue. Adding a wait command is such a s-seq programming failure If you want to 'just fix it', use a conditional+a mouse button checker command. At first power-on you hold left mousebutton and it adds the resetproof ram, then you can reboot as much as you want, and you won't need to modify a file on the hdd and wait before rebooting. I coded MouseCond for this type of thing, but certainly there are plenty of alternative ones. If the reboot command doesn't work, get one that does (and really there must be plenty of reboot commands that work), or in the worst case add a wait or let the s-seq end to allow a manual reset. But Christ Almighty, Add32bit really should have an autoreboot switch. Did you try typing "add32bit -help" or something in the shell? Didn't find it on aminet, so if you want you could upload it to The Zone? Last edited by Photon; 25 February 2010 at 12:19. Reason: s/a/an

01 March 2010, 07:58	#20
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	Hi...I´ve described it in post #14 Yes, everything runs fine now. A big "Thank you!" for your ideas. Last edited by mombasajoe; 01 March 2010 at 08:17.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ChipMEM Bug.	FOL	support.WinUAE	4	09 January 2013 22:41
A604: New chipmem expansion - and more!	Schoenfeld	News	58	11 September 2011 12:50
Wasted Dreams chipmem problem	ancalimon	support.Games	7	28 January 2010 18:53
Chipmem bandwidth question.	Thorham	Coders. General	8	16 December 2009 00:31
ChipMEM and FastMEM on A500	Iznougoud	support.Hardware	6	20 June 2008 12:05

11 February 2010, 23:30	#1
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	Chipmem usage different from real machine? It´s not really a problem but I am indeed interested in why the following happens. If you look at the attached screenshot-combo you see a worbench on a TV-set with about 1.737 free chipmem and a WinUAE-workbench with about 1.924 free chipmem. Both "Amigas" have just booted, nothing else has been done. TV-set = my real 68010 A500+ with 2 MB Chip, Kick 3.1 and an ALFA-Power-controller mith 8 MB Ram and a 1 GB CF-card as HD. WinUAE = full ECS, 2 MB chipmem, 8 MB fastmem, Kick 3.1 (not A1200 of course), 68010.....and the same CF as HD (= really the same workbench). Did I configurate WinUAE a wrong way? Where comes the difference from? The Workbench is based on the ClassicWB 68k, in the startup-sequence only DECIGEL (for 68010) and ADD32BIT (for 8 MB) have been added by me. But - as said before - in WinUAE it is the same CF-card. ?? Attached Thumbnails

11 February 2010, 23:32	#2
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,997	Isn't it to do with Hard drive buffers being different in WinUAE? I.e. thats taken care of by WinUAE outside of Amiga memory?

11 February 2010, 23:35	#3
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	I do not know...but even the "other" memory is different

12 February 2010, 00:11	#4
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	Looks like about 200k of 'stuff' end up in chipmem on your real Amiga, whereas in WinUAE 'your type of' fastram hasn't been added, but rather 'just fastram'. If you boot without startup-sequence and type avail at first power-on, do you have 0mb fast then? I think it's just a matter of fastmem not being available for the kickstart to put stuff in, before it boots from any disk - whereas on WinUAE the fastmem IS available during reset. This is the case for my 68040 board with 4MB, before I run Init040, I had 0MB fastmem. You can get around it simply by inserting a 512k slowmem expansion in the trapdoor. I think I have one extra with clock left over if you want to buy it.

12 February 2010, 00:19	#5
Mad-Matt Longplayer Join Date: Jan 2005 Location: Lincoln / UK Age: 44 Posts: 1,849	Id have said the difference would be that under winuae, rom libs (and wb) are being put in fastmem durring boot time. This isnt happening on real amiga as fastmem doesnt exist until add32 is seen so all the libs are in chip mem. That said, the chipmem use should be higher for uae too to show the hires 8 colour screen/backdrop.

12 February 2010, 17:51	#7
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	I disabled the 8 MB The A500+ now has about 1.391 free chipmem, WinUAE has 1.390. So I think the ideas are right. Thank you very much!

12 February 2010, 20:21	#8
ceztko Registered User Join Date: Aug 2006 Location: Italy Posts: 109	I think there so many variables to consider that very few computer/console emulators are able to offer a system with predictable, 100% correct memory consumption "emulation".

12 February 2010, 23:30	#9
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	Sure, but in my opinion that example was very extreme (I wanted to optimize my WB on WinUAE and thought "wow! soooo much free chipmem!" then have started my A500 and thought "oops!?"). It´s just good to know that this is not a matter of WinUAE-configuration so I can stop trying.

24 February 2010, 00:27	#11
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	I´ve already tried some things. But there is a problem. My workbench is a slightly modified "project.ClassicWB6k". It messes something up with the "reset-proof" 32bit-RAM. Everything works fine but after a reset I get a yellow screen, the 32bit-RAM is "gone". So I made a boot-disk for testing. The startup-sequence contains the following: Add32bit-special resetfest (means "reset-proof") wait 2 sec (it´s time to eject the disk now) reboot (makes a reset) After the reset: -32bit-RAM is still available -Workbench boots (HD) - 128kb more free chipmem - SysInfo says: The libraries etc. are now in 32bit-RAM The next try was to play with the HD-startup-sequence to get rid of this bootdisk. The quick´n´dirty solution I´ve thought of was this one: Preparation: Copy a file with the name "switch0" to the HD (as a flag) Then change the HD-startup-sequence: *********** IF EXISTS switch0 add32bit-special resetfest >NIL: rename switch0 switch1 (use filename as a flag) reboot ENDIF rename switch1 switch0 (unset flag) [...] *********** ...and yes, you´ve guessed right: This ended with an error at the command "rename switch1 switch0": "Volume is not validated" Actually I haven´t got any idea how to solve this problem. At least I think that there are only two ways: 1. Find out why the reset-proof 32bit-RAM doesn´t get along with a reset from ClassicWB (this can take weeks) 2. Find another solution containing a forced reset during the booting-procedure without getting a "not validated"-error (no idea how) or...okay... 3. Let it be. Keep the boot-disk if some extra chipmem is needed.

24 February 2010, 03:19	#12
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	I don't really see why the bootdisk startup-sequence commands won't work just because you boot from harddisk?? You would think that all you had to do was paste that bit at the start of dh0:s/startup-sequence. But I guess you're using the disk eject button instead of a 'flag', right? I guess that disk doesn't include a reset command but that you do it manually? Otherwise I don't see why using that command would reset properly. Haven't used add32bit, but it really should have a resetproof flag as option, and a flag to reboot if it's not set. In an ideal world If you find that it doesn't have that, maybe there is a substitute. Why ClassicWB's reset command doesn't work (if it came with it, I don't know?) is unknown, maybe it's a special command which requires some ClassicWB initialization before invoking, or just works in WB. Anyway, it doesn't work, so you should use another reset command that works. Volume not validated: if your harddisk setup has been working reliably for writing files before, then it's a strange error. If you type 'info' after it happens again, does the harddisk volume say 'Read/Write' or 'Validating'? If Validating, then something is unreliable in the setup or filesystem, or you need to BindDrivers first. If it's the rename command that for some reason is buggy(?), then you could use the Move command instead, or 'Makedir dh0:MemOK', or any number of commands that will be able to make a change on the harddisk.

24 February 2010, 07:55	#13
cosmicfrog The 1 who ribbits Join Date: Apr 2006 Location: leek, Staffs, UK Age: 56 Posts: 3,557	move , rename are essentially the same command

24 February 2010, 18:35	#14
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	Problem solved. I´ve chosen alternative ... 4.... An also quick´n´dirty compiled GFA-Basic prg It´s now the first entry of the HD-startup. The code is like this: -check if available mem is < 3MB -yes: execute add32bit and execute reboot -no: do nothing Works fine. The Amiga boots, installs fastram, resets and then boots the full startup-sequence. No manual reset. No boot disk. No yellow screen when resetting from wb. Available chipmem: 1.866 at HiRes x8 and with background picture. If think that I´ll leave at that way. It´s fine the way it is.

25 February 2010, 21:16	#18
mombasajoe Registered User Join Date: Mar 2006 Location: D Age: 49 Posts: 528	I´ve found German docs for add32bit: There is nothing written about a reset-flag. I´ve zoned it all (prg+doc). I´ve also watched add32bit-special inside a hexeditor (ASCII only) and did not find anything that looks like that. So I guess that there simply isn´t such an option. I also think that there are some misunderstandings (please don´t hurt me if this is not true ) 1.The yellow-screen-error ------------------------- Has nothing to do with the "reboot" command of ClassicWB. So what happens? - Amiga boots the workbench (incl. "add32bit-special resetfest" in s-seq without any resets) - Workbench-screen opens - 32bit-mem is active - everything works fine (except of the high chipmem usage as described in the first post) - now (from workbench) a MANUAL reset brings a yellow screen (Amiga+Amiga+CTRL) -> Crash, memory is gone 2. The non-working "rename-switch0-switch1-solution" ----------------------------------------------------- -a changing filename is used as a flag -no manual reset -reset is performed by the command "reboot" in the s-seq -leads to "not validated" during the second boot 3. The working bootdisk-solution ------------------------------- Works this way: -insert disk in DF0: and turn Amiga on -s-seq (DF0: ) does "add32bit-special resetfest" and "reboot" (two commands) -in the moment of the reset (caused by "reboot"-command) eject the disk manually -Amiga boots Workbench from HD -everything works fine (much chipmem, no yellow screen after manual reset, 32bitMem is reset-proof) 4. The working GFA-Basic-App-solution ------------------------------------- - Amiga boots - resets (app activates 32bit mem and executes "reboot"-command ) - Amiga boots again - app does nothing because it recognizes that the mem has already been activated - workbench is loaded - everything works fine (much chipmem, no yellow screen after manual reset, 32bitMem is reset-proof) - no manual steps needed (no mouseclick, no manual reset, no disk to eject)

01 March 2010, 01:11	#19
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,604	So you have no problems anymore, did I get that right? That some GFA-app runs fine really didn't tell me anything, especially since you didn't write its function. I guess it's something that calls add32bit and reboots if needed. Thx for zoning, I'll grab those files for future reference - if you want you can upload them to aminet too, as they don't seem to be there.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)