Yesterday, 18:05 | #2061 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,110
|
Quote:
Whow, you want to made with every Amiga debugging machine? For what? This is very useless option for average Amiga user. And for about 99% cases, 1KB of zero page is enough to find wrong access bugs. As choosable OPTION it can be acceptable. As DEFAULT this only wasted Amiga resources. And is totally useless for Amigas with 68000, 68010, 68020,68080, 68040 (PiStorm version). Too bad that you are not Amiga games player. You can learn how bugs are catched by WHDLoad. |
|
Yesterday, 18:08 | #2062 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,110
|
|
Yesterday, 18:16 | #2063 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 873
|
Just a curio: I patched my KS(3.1) to start chipmem from $0000F000, but I have a well expanded machine so I'm not bothered.
Oh, and I tried using $00010000 but I'm not sure what happened there: I just got a grey screen. I looked a lot at it, but couldn't find any obvious bug in what I did. *Shrug* |
Yesterday, 20:39 | #2064 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 197
|
Maybe it would be possible to ~delay the 32k reservation in boot sequence. Make it such that ~relocatable "stuff" ends up in this low memory area and somewhere later in startup-sequence (a chip memory hungry game would start before that) move the stuff out of the way.
Relocatable things may be copperlists, buffer for sprite, bitplanes, ... Known/~fixed MEMF_CHIP allocations that happen at every boot would/could be built into a table at kickstart build/compile time and early in the boot sequence the entries in the table would be AllocAbs()ed. So they are basically pre-allocated at build time. |
Yesterday, 20:55 | #2065 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,464
|
Quote:
No, getting rid of bad patches. Which is not so uncommon because that was already the reason for enlarging the zero page to 4K in 3.1 Oh well.. It *is* an option in case that wasn't clear to begin with. |
|
Yesterday, 21:00 | #2066 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,464
|
Quote:
Again, you cannot *delay* the reservation because something is already *initialized* in this region to begin with when the system starts before it even boots. That is expansion, graphics, trackdisk... whatever runs early, and sometimes so early not even a KickTag can kick in. Which is exactly *why* PrepareEmul is such an ugly hack that, depending on the machine, has to choose between several strategies to work from, and is even kickstart depending in some cases. Yes, I'm really serious, the entire thing is a really really ugly hack that is absolutely not future proof, and no, it does not make sense to write a different version for each kickstart to come. |
|
Yesterday, 21:01 | #2067 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,464
|
|
Today, 00:27 | #2068 | |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,134
|
Quote:
|
|
Today, 04:36 | #2069 | |
Registered User
Join Date: Mar 2019
Location: Poland
Posts: 66
|
Quote:
How about this approach: Reserve 32kb as of now but, depending on an option from boot menu, leave it as is for emulation or mmu tables use, otherwise add 24kb from 32kb of reserved memory as another chunk to free memory list. The option should be by default off, so users can have this memory available for allocations. Maybe even would be possible to merge back this chunk with main free chip ram memchunk, making the largest block larger Last edited by Docent; Today at 04:49. |
|
Today, 06:04 | #2070 |
Registered User
Join Date: Sep 2018
Location: California
Posts: 369
|
Hey guys, didn’t boemann say this chip ram thing is going to change in a future update?
Might I request that if this IS the case, that the entire chip ram argument move into a different thread so that this thread can continue to focus on other things? I feel like the point of this thread is completely derailed at this point. |
Today, 07:22 | #2071 | |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 197
|
Quote:
With "boot sequence" I did not mean the late stuff that is done from startup-sequence onwards. I meant from the earliest code executed when machine starts up. Said otherwise: you keep having your 32k reserved very early as it is now, but you still put - through whatever means - some of memf_chip requiring stuff in this low memory area if it's such stuff that can be relocated (moved out of the low 32k) sometime after startup-sequence starts being processed (and after chip hungry game would be started) before there is any program (Mac emu) that relies on this 32k being available for use. So at very beginning of s:startup-sequence free chip memory is higher. Then ~"Relocate32k" is executed: stuff in reserved area gets removed, rebuilt, whatever and it ends up in memory after 32k area. Free chip memory gets lower. But a chip hungry game is not affected, because it would start before that. And an mac emulator would only run after. Just need to find/identify those memf_chip allocations done by the OS during boot(strap) that are safe for such relocations. |
|
Today, 07:50 | #2072 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,464
|
Quote:
What you can do is to reinitialize the chip memory pool MemHeader structure to also include additional memory at lower end. While that formally gives you memory back, it probably does not help much because at this point the memory is already fragmented - the part above the allocated structures, and the new area below what has been allocated already. You cannot, simply because that's not under control of the Os. |
|
Currently Active Users Viewing This Thread: 8 (2 members and 6 guests) | |
meynaf, h0ffman |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmigaOS 3.1.x v 3.9 | steve_mynott | New to Emulation or Amiga scene | 35 | 19 April 2020 06:23 |
AmigaOS 3.9 | PoLoMoTo | support.WinUAE | 8 | 27 August 2011 18:06 |
AmigaOS 3.5 or 3.9 | maddoc666 | support.Apps | 12 | 22 February 2010 08:02 |
AmigaOS | koncool | request.Apps | 6 | 04 June 2003 17:45 |
AmigaOS XL | sturme | New to Emulation or Amiga scene | 4 | 15 January 2002 02:13 |
|
|