Make CLI 1 bitplane on OS1.3-3.1 CORRECTLY? ("Add21k")
 

Maybe a niche question, but programs like

• add21k (pacman, galaga hit)
• add36k
• add44k (fish 095 hit)
• bpls (which can set the number of bitplanes back to 2, 3 etc.)

...have been widely used, but with issues on some systems.

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 :great

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.

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.

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
;)

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.

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.

Heh. Thanks for reminding me of this thread. I'll check your bootblock right now. :great

Too late and Fragmented are truly the key points.

This would be great, and maybe also fix a pet peeve - the CLI window being NTSC-sized on PAL systems. :)

Ideas for doing the "impossible" (or averting it)

1. bitplane reduction command could exit on OS>1.3 (not ideal, but it would be great if all Add#?K commands were patched!)
2. command or bootblock could change the height of the CLI screen to 128 (PAL) or 100(NTSC) instead (yes!)

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? :)

There is a Kick 1.3 extension to the preferences structure <intuition/prefs.h> that contains the following fields:

Thus, creating a DEVS:System-Configuration on your disk that provides alternative values for them might possibly work. Note that the system-Configuration file is just a binary dump of the Preferences structure in the above include file.

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.

That would be kinda neat :)

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):

Edit: However, this affects nothing. The colors etc are loaded correctly from the system-configuration file. Wrong values?

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.

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.

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! :agree

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! :great

(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.)

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).

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! :agree

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...

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.

Right now I'm thinking:

1. Set 0 bitplanes, 200 height
2. RemakeDisplay
3. FreeMem (not FreeRaster)
4. Alloc 1 bitplane
5. Set 1 bitplane
6. RemakeDisplay

:confused

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.

What is your intention for this?

Once what you have loaded has loaded, do you still need the system active afterwards?

Thomas, thx for info :great 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.

Seems a bit silly. Surely you only need enough to run the demos, games, utilities etc.?