Today, 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. |
|
Today, 18:08 | #2062 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,110
|
|
Today, 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* |
Today, 20:39 | #2064 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 196
|
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. |
Today, 20:55 | #2065 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
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. |
|
Today, 21:00 | #2066 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
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. |
|
Today, 21:01 | #2067 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,462
|
|
Currently Active Users Viewing This Thread: 16 (7 members and 9 guests) | |
a/b, amigakit.com, Thomas Richter, peceha, daxb, Flux, arcanist |
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 |
|
|