Coding challenge: Maximize-contiguous-chipmem bootblock
From this simple question, I started thinking. While there are some commands you can add in startup-sequence, this fragments the precious contiguous chip RAM needed to squeeze in some games and demos on A500.
There have been a few bootblocks that have allowed the user to manually disable DF1 (and reboot), but it made me want to find out if there is a way to disable all external floppy drives, shrink the CLI window to, let's say, two lines of text high, and reduce it to one bitplane in depth, jerry-rigged by the bootblock before the startup-sequence. Previous solutions have not been compatible between Kickstarts. So is there a way which is compatible on all machines from kick 1.2 to 3.1? I'm posting here even though it's a boot block, because I think the focus is knowledge of the system. So if you want, give some ideas for the components, C, Assembler, or pseudocode - doesn't matter! :great |
Nothing I've tried, but as for the diskdrives, one idea is to check io_Unit in your IOStdReq to see what drive you've booted from, then open disk.resource and check dr_Flags to see what other units are enabled, and call GetUnit() and FreeUnit() to disable them.
|
Pretty sure Quartex did something like this from a bootblock (disable all external drives).
|
Thx Leffman!
Galahad - without rebooting tho? And compatible. If so then it could interesting to have a look if you can find it. The rebooting kind as you know is common, although I dunno many more than mine that are updated to be compatible. Toggle fastmem is easier to do without reboot. Anyway the thing would be to strip external drives and strip one bitplane (or "1.5") and carry on booting normally from Kick 1.2 up. |
Isn't it possible to never have the CLI show? Or does 1.x always pop it up even if you redirect to NIL:?
|
Quote:
But... There is plenty of track loaders from Bootblock. In the last days i'm writing a file loader for non-system environment (yes, there are plenty also, but no one safe, small, functional and with good source code available). My code ended up as about $250 bytes (i will publish the source). With a little parser for startup-sequence we can 'emulate' everything from bootblock. Strange idea? Bye! ross |
You could experiment with SetFunction-ing OpenWorkBench or OpenScreen to change the depth used by the WB screen to 1.
(Somehow) patch the DOS CON handler to open the initial CLI window much smaller. Or maybe an OpenWindow patch would be simpler? |
You could just detach from CLI and call intuition.library/CloseWorkBench.
Using area $100-$3FF to move some code is possible as well ; from there you can run a small loader for whatever game or demo that follows. If the game does not use some libs you can perform RemLibrary() on them. Anyway, it all depends on what you really want to achieve. Is this purely academic or is there some specific goal ? Taking over the system might be a better solution for new games/demos needing lots of chipmem. |
Ah, if $100-$3FF are unused, you could copy any patch code there. And/or use AddMemList to add that small amount of memory to the system list. Make its priority one higher than chip RAM.
|
You could relocate the header for chipmem to (fake) fastmem and then free it. That is some 16-32 bytes IIRC.
|
Quote:
So the CLI window should open, just smaller, and in 1 bitplane. Not opened big in 2 bitplanes and then re-allocated which while showing a higher number in Avail fragments the memory and is generally not usable. And the system should be prevented from allocating chip buffers for DF1-DF3 (or if already done, a way to unmount them and free the chip+fastmem used by them). |
Can we assume there is only chipmem in the system, or is moving things to other mem wishable ?
|
Well you couldn't move floppy buffers or bitplanes into fastmem anyway (or what do you mean?)
I just mean "click to disable DF1"+"Add21k", but do it automatically in the bootblock before running the startup-sequence. |
You mean something like EndRun ?
|
Googled "endrun aminet", and that's the best I can do until you say what it is. It can't be an AmigaDOS program, obviously since it would likely be too late to reduce CLI colors (1.3) without fragmenting the chipmem like Add21k etc does.
|
|
Quote:
|
I did a bootblock back in the day that let's you disable floppy drives - I'll see if I can remember to dig it up for you...
|
Quote:
In KS>=2.0 sstack is actually in real fastmem. The initial request is related to A500 so the stack moving is for quite rare situations. Bye :) ross |
Quote:
I suppose it's the same for other kick versions. If Exec is in chip, you've got big chances supervisor stack also is. And it is by default. |
All times are GMT +2. The time now is 11:44. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.