English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 11 September 2021, 01:35   #1
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
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
Photon is offline  
Old 11 September 2021, 11:12   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
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.
Thomas Richter is offline  
Old 11 September 2021, 11:30   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,204
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.
mark_k is offline  
Old 11 September 2021, 11:41   #4
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,505
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
ross is offline  
Old 11 September 2021, 12:24   #5
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
Quote:
Originally Posted by mark_k View Post
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.
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.
Thomas Richter is offline  
Old 11 September 2021, 13:14   #6
admiral
Engineer
 
Join Date: Oct 2018
Location: Shadow realm
Posts: 103
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.
admiral is offline  
Old 11 September 2021, 13:58   #7
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
Quote:
Originally Posted by ross View Post
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
Heh. Thanks for reminding me of this thread. I'll check your bootblock right now.

Quote:
Originally Posted by Thomas Richter View Post
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.
Too late and Fragmented are truly the key points.

Quote:
Originally Posted by admiral View Post
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.
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?
Photon is offline  
Old 11 September 2021, 14:16   #8
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
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  */
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.
Thomas Richter is offline  
Old 11 September 2021, 14:54   #9
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
Quote:
Originally Posted by Thomas Richter View Post
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  */
Thus, creating a DEVS:System-Configuration on your disk that provides alternative values for them might possibly work.
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):

Code:
  $00e2   226  wb_Width
  $00e4   228  wb_Height
  $00e6   230  wb_Depth
  $00e7   231  ext_size
Edit: However, this affects nothing. The colors etc are loaded correctly from the system-configuration file. Wrong values?

Last edited by Photon; 11 September 2021 at 15:07.
Photon is offline  
Old 11 September 2021, 14:56   #10
lesta_smsc
Registered User

lesta_smsc's Avatar
 
Join Date: Feb 2012
Location: United Kingdom
Posts: 2,803
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.
lesta_smsc is offline  
Old 11 September 2021, 15:19   #11
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
Quote:
Originally Posted by Photon View Post
Wrong values?
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.
Thomas Richter is offline  
Old 11 September 2021, 19:07   #12
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
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.)
Photon is offline  
Old 11 September 2021, 20:11   #13
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
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).
Thomas Richter is offline  
Old 11 September 2021, 20:47   #14
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
Quote:
Originally Posted by Thomas Richter View Post
have you tried to set wb_Depth in above structure to 1
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!

Quote:
Originally Posted by Thomas Richter View Post
Under 1.3, everything after the bootblock is too late.
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...
Photon is offline  
Old 17 September 2021, 11:55   #15
Jope
-
Jope's Avatar
 
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 41
Posts: 8,742
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.
Jope is offline  
Old 17 September 2021, 15:20   #16
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
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

Photon is offline  
Old 17 September 2021, 18:04   #17
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,386
Quote:
Originally Posted by Photon View Post
Set 0 bitplanes, 200 height
0 is not a valid bitdepth. How do you plan to set it?


Quote:
Originally Posted by Photon View Post

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




Quote:
Originally Posted by Photon View Post

FreeMem (not FreeRaster)
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.



Quote:
Originally Posted by Photon View Post

Alloc 1 bitplane
With AllocBitMap().




Quote:
Originally Posted by Photon View Post
Set 1 bitplane
If that's already allocated with 1 bitplane, this is redundant.




Quote:
Originally Posted by Photon View Post

RemakeDisplay



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.
Thomas Richter is offline  
Old 17 September 2021, 19:18   #18
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 48
Posts: 8,196
What is your intention for this?

Once what you have loaded has loaded, do you still need the system active afterwards?
Galahad/FLT is offline  
Old 17 September 2021, 20:45   #19
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,103
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.
Photon is offline  
Old Yesterday, 10:13   #20
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 823
Quote:
Originally Posted by Photon View Post
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.
Seems a bit silly. Surely you only need enough to run the demos, games, utilities etc.?
Bruce Abbott is offline  
 


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 14 07 February 2020 16:34
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices" DemosongIHunter request.Music 44 27 October 2019 19:04
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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:08.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.10108 seconds with 13 queries