11 September 2021, 01:35 | #1 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Make CLI 1 bitplane on OS1.3-3.1 CORRECTLY? ("Add21k")
Maybe a niche question, but programs like
I'm looking for a command to put in my startup-sequence to do this correctly on OS1.3-3.1, or code, snippets or instructions to Assemble one. Gimme your thoughts. Cheers |
11 September 2021, 11:12 | #2 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
I afraid that the only answer to this question is "there is no way to do it correctly". If you want to save as much chip memory as possible, make an "install df0:" on the affected floppies, this will not only save 21k, but it will save the entire two bitplanes of the screen, and the window structure, and much more - no screen will be opened at all.
The problem of these programs is that they are intrusive to private Os structures, and these may have changed, and also the logic by which bitmaps are allocated changed. They "steal" one bitplane from an intuition bitmap. Unfortunately (or fortunately?) intuition v40 and beyond opens by default "interleaved" bitmaps for which this trick does not work anymore. Hence, I afraid, "this won't work". Except for the "install" hint, which does work on 3.1 and beyond, and which saves even more memory than the above hacks. |
11 September 2021, 11:30 | #3 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,343
|
Commodore made a program called EndRun which was used to run a program after closing the intial CLI window and Workbench screen. It was used by some CDTV titles. May not be what you want though, since then the initial CLI window is closed.
|
11 September 2021, 11:41 | #4 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,474
|
Thomas is probably right, there is no way to do it correctly/effectively when CLI is already open, so do it before:
https://eab.abime.net/showthread.php?t=87859 |
11 September 2021, 12:24 | #5 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
That's correct - this can be done in a safe way. Essentially, you detach the program you want to start from CLI (i.e. NIL: &) and then start a program that continuously attempts a CloseWorkbench(), and then run into an EndCLI. The EndCLI closes the shell, the helper program closes the workbench the shell run on, and the memory is released for your program that started in the background. Unfortunately, it might have been too late already at this point as chipmem is then fragmented, and the additional 42K may not be helpful anymore.
|
11 September 2021, 13:14 | #6 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
I'd try and open the initial screen at 1 bitplane from the bootblock, before returning to let dos.library start to then find existing screen.
Initializing dos.library from the bootblock is also possible, but then the bootblock is never freed. Returning is better. |
11 September 2021, 13:58 | #7 | |||
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Quote:
Quote:
Quote:
Ideas for doing the "impossible" (or averting it)
I like the second option because it works with interleaved CLI screens, and there's at least enough space to do simple things (list a directory, show requester). It would be nice if it was a command which could also make it full-height (256 PAL, 200 NTSC) with a parameter! Then for packdisks/games etc we could use Ross's bootblock separately to squeeze every byte. The command would not fragment when shrinking (assuming it's first in s-seq), but fragmenting is OK when setting it to full-height. How would I go about writing one? Maybe there's one on Aminet already? |
|||
11 September 2021, 14:16 | #8 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
There is a Kick 1.3 extension to the preferences structure <intuition/prefs.h> that contains the following fields:
Code:
UWORD wb_Width; /* override default workbench width */ UWORD wb_Height; /* override default workbench height */ UBYTE wb_Depth; /* override default workbench depth */ Also note that calling SetPrefs() in the boot code will not work. The dos.library startup code will read DEVS:System-Configuration if it exists, and will install it into intuition, reverting any change you made. Thus, placing changes in the file is a way to try. This does not require any custom boot block. |
11 September 2021, 14:54 | #9 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Quote:
I changed these offsets in the file, to 640, 100, 2, and 6 for ext_size (I did try with 0 for ext_size first): Code:
$00e2 226 wb_Width $00e4 228 wb_Height $00e6 230 wb_Depth $00e7 231 ext_size Last edited by Photon; 11 September 2021 at 15:07. |
|
11 September 2021, 14:56 | #10 |
Registered User
Join Date: Feb 2012
Location: United Kingdom
Posts: 3,175
|
Very interesting, as I was using these commands to maximise the available memory for use on Amiga A600 with 2MB for WHDLoad. Sometimes that extra kb is all that is needed for games to run. Here were some issues I found:
If you do not have CLI window then it will fail / hang. If the command is written straight from startup (so on A600 you get a more rounded CLI interface as opposed to the more refined squared CLI) then it also hangs. I had collated a few of these apps (some work and some did not - if I'm not mistaken the add44k caused system to reboot/hang) to do the needful. Some were better than others. The other thing you can do is flush the RAM AFTER using the command. I forgot about the EndCli command! Just realised this it what would be handy as I run the AG-Launch interface anyhow so hopefully removing the CLI window will add a few extra kbs! BTW You can also reduce the CLI window to be as small as possible and that also adds quite a bit of kb. I'm still seeking the most compatible outcome with the maximum memory available. Another option is to disable DF0 etc as these free up RAM too. I should have my set up somewhere on that Amiga as I called upon it when needed... once I get to it, I'll try and post here. |
11 September 2021, 15:19 | #11 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
I don't know. There are two hyptothesis I have. One is that this was simply never implemented. The second that the dos.library startup code only loads the initial part of the System-Configuration and ignores the extension. In such a case, it *may* help to call SetPrefs() in the bootblock. That is, allocate a buffer large enough, make a GetPrefs() to retrieve the default, set the values, call SetPrefs(). If the dos startup code only loads parts of the file, your extensions will survive.
|
11 September 2021, 19:07 | #12 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Thanks Thomas. However for me this has shifted to an after-bootblock solution, since Ross has a working solution in the thread he first linked!
So since OS1.3 and OS3.1 loads the other values correctly but not my changed value, it either ignores them or the values are wrong (or perhaps some other part of the file must be changed to read them). It's a really nice idea, and I'd hate to let it go if we can find the truth! (Side comment WRT values: 200 is the lowest height OS1.3 will go, when set from the bootblock. Ross's code had that as comment and I verified it.) Height 200 on PAL might still be worth it for a command. It will save 80*2*56 ~= 9K chipmem. (Oh! That reminds me that the command must work on chipmem-only machines like A1200. There was some problem IIRC.) |
11 September 2021, 20:11 | #13 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
I afraid this would be a bootblock solution, though have you tried to set wb_Depth in above structure to 1 (not 2?). Actually, I don't know whether the workbench supports it (actually, intuition...).
Under 1.3, everything after the bootblock is too late. The boot block will initialize the dos.library, and the dos.library bootstrap will necessarily open CON:, which will open the screen. (Under 3.2, there is another component which does that, it is not longer dos). |
11 September 2021, 20:47 | #14 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Yes, 640x256x1, 640x200x2, no extension values change anything. Only values set by WB1.3 prefs/preferences are loaded. It would be so sweet if possible!
Do you mean change screen height only? Because I have at least two working solutions with FreeRaster() and normal FreeMem() which work on 1.3 for reducing depth. The problem is rather with the later interleaved OS versions. (This is the fix/workaround I seek.) And I've definitely seen a disk with a very tiny window, like 640x64. If I could only remember which demo disk... and it wouldn't make sense at all if it didn't save chipmem... |
17 September 2021, 11:55 | #15 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,863
|
Larger than standard values for the system-configuration screen size do work in WB1.3, naturally they only take effect when the system-configuration is read at boot.
|
17 September 2021, 15:20 | #16 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Right now I'm thinking:
|
17 September 2021, 18:04 | #17 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
0 is not a valid bitdepth. How do you plan to set it?
This only rebuilds all copper lists and moves them to the hardware. This is necessary when changing the bitdepth to let the display hardware only show one plane. FreeMem and FreeRaster are very closely related. Actually, the only difference is that FreeRaster() computes the size value for FreeMem(). However, as the system bitmap was never allocated by AllocRaster(), but by AllocBitMap(), and is most likely interleaved, this is not the right call. FreeBitMap() is. With AllocBitMap(). If that's already allocated with 1 bitplane, this is redundant. See above for what this does. Some things worth understanding: The bitmap is the bitmap of the screen, which is IntuitionBase->FirstScreen (when it is open, and if there is only one screen). The bitmap of the screen is in Screen->RastPort.BitMap (and NOT Screen->BitMap, which is a bogus bitmap). That is the bitmap you need to release or dispose. Screen->BitMap is just a deep copy of this bitmap, at least it is for native screens. RemakeDisplay rebuilds the copper lists from screen->ViewPort and the information therein. Screen->ViewPort contains a pointer to the bitmap that represents the screen content in its RasInfo, that is, Screen->ViewPort.RasInfo->BitMap points to Screen->RastPort.BitMap (and not Screen->BitMap). So that would be another pointer you need to adjust when "changing" the bitmap. Finally, whether "replacing the bitmap" under the feed of intuition is maybe or maybe not going to work, keeping in mind that other programs using the screen may potentially have cached the bitmap - namey in their own RastPort. Thus, for example, the console window has its own RastPort (window->RastPort) which has a bitmap pointer of its own (window->RastPort->BitMap) and this bitmap is also that of the screen (i.e. window->RastPort->BitMap == screen->RastPort.BitMap). Thus, you cannot simply replace one without also replacing the other. There are potentially other RastPorts involved (gadgets may have one, the console.device may have one), so it's really not that easy. |
17 September 2021, 19:18 | #18 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,994
|
What is your intention for this?
Once what you have loaded has loaded, do you still need the system active afterwards? |
17 September 2021, 20:45 | #19 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
Thomas, thx for info Perhaps I can free both bitmaps, alloc a 1 bitplane 640x200 bitmap, correct the structures and remake the display for 1 bitplane AND 200 height?
Galahad, I think you know A correct Add21k that does so on KS2+ without creating gaps in the Chip Memory map. It's for any kind of bootable floppy where 1 or more demos, games, utilities, songs, or pictures are distributed. The files being distributed mustn't be changed to take over the system permanently, but you should just be able to put them on the disk and have as much contiguous Chipmem available as possible. The old commands don't work as intended, and since the CLI screen can be minimum 200 high, I'd like to make it so, again: without creating gaps in the Chip Memory map. |
20 October 2021, 10:13 | #20 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,581
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Diabolik" & "Dylan Dog" & "Tex" & "Time Runners" series | DamienD | request.Old Rare Games | 20 | 21 July 2022 16:58 |
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices" | DemosongIHunter | request.Music | 45 | 23 May 2022 20:07 |
AmigaDOS: Open file with "default tool" from CLI | Steffest | support.Other | 8 | 08 February 2019 09:16 |
My "Hello World" Text will not be printed to cli | Fireball | Coders. General | 6 | 28 January 2019 23:53 |
Cli program to "execute" .info files | olesio | support.Apps | 4 | 05 September 2010 19:19 |
|
|