A little proggie...

[ppill]

I know a couple of skilled or aspiring ASM coder dwell here so I've got a favor to aks . I want to include a simple gauge proggie in Hombre but all the ones I've found so far lack in features or simply refuse to work.

This little utility would:

• run on 1.3 kick
• open a small window (or just the titelbar) and displays the following:
• - free memory
• - track position of each drive
• - time, date
• adjust window's position via cli arguments
• allow to adjust the display format
• use as little memory as possible

for example:
gauge -drive 0 -chip -date -time -w=0,0 -f=%cb,%d,%t,%s

would open the window in the top-left corner, display the current track postion in DF0:, available chip memory, date and time like so

910123 bytes | 04-12-80 | 12:14 | 41

So if you wanna make one amiga user very happy...
Please, pretty please

[ppill]

*Bump*

The next version of Hombre is coming along nicely and something like described above would be great... anyone?

[Leffmann]

Displaying the track position could be a problem because the hardware itself doesn't tell the exact position, and IIRC access to the trackdisk.device is exclusive, but I could be wrong on that. At least I can't think of any neat method to get the track positions of the drives.

What was wrong with the existing utilities? Do you need some fancy displays or graphics for this? Just putting some text in a thin titlebar-sized window is not a problem.

[ppill]

Originally Posted by Leffmann

Displaying the track position could be a problem because the hardware itself doesn't tell the exact position, and IIRC access to the trackdisk.device is exclusive, but I could be wrong on that. At least I can't think of any neat method to get the track positions of the drives.

What was wrong with the existing utilities? Do you need some fancy displays or graphics for this? Just putting some text in a thin titlebar-sized window is not a problem.

Right now I'm using a program called TD (TrackDsiplay) by Preben Nilsen:
http://aminet.net/package/misc/fish/fish-0543

source in assembler included so have a look how he goes about it... (pretty sure not in a very system friendly way)

I don't need anything fancy just what I've described in the first post. The problem right now is that you'd have to use two separate programs for it and none of the ones I found were small enough or didn't let you change the format of the display.

As for now I use zshell's built in MemClock feature (displays free mem and time but disappears after you open a new window together with TD which only displays head positions for each drive).

Any help would be greatly appreciated

http://aminet.net/package/misc/fish/fish-0399

Here's another one by Olaf Barthel (c source included)

[Leffmann]

Thanks I'll take a look at how they read track positions.

[Leffmann]

Here's a first version, only displaying time, date and amount of free memory for now.

I decided to move the text out of the title bar because changing the title causes flickering on 1.3, and drawing text in the title bar using other methods is error prone. And also because on 1.3 the gadgets use up a bit of space and you quickly fill the screen width when you start adding status items.

[ppill]

Originally Posted by Leffmann

Here's a first version, only displaying time, date and amount of free memory for now.

I decided to move the text out of the title bar because changing the title causes flickering on 1.3, and drawing text in the title bar using other methods is error prone. And also because on 1.3 the gadgets use up a bit of space and you quickly fill the screen width when you start adding status items.

That's great!!! Thanks a ton Will check it out ASAP.



Works great!

[Zetr0]

OOooOOOo

interesting =)

[Leffmann]

Just a small update, you can now format the status text freely. Will look into the diskdrive status next.

It uses the standard C formatting flags for time, which you can f.ex find here: http://www.cppreference.com/wiki/chrono/c/strftime
and also %C for free chip memory, %F for fast and %T for total.

gauge "Chip %C Fast %F | %X | %A %d-%b-%Y" gives full memory, time and date status f.ex.

[ppill]

@Leffmann

Looking good Thanks for taking the time to make it happen. It will be a great addition to the next version of Hombre.



Here it is running with the following options:

run gauge "Memory: %T bytes free | %H:%M | %d-%m-%Y"

Some further suggestions:

- maybe it could detach itself from the current CLI process (no need to run it)
- an option to open it as a borderless/notitlebar/backdrop window (save an extra line of the text for another window). Of course this would come after the window position option...

really happy with this

[Leffmann]

Added diskdrive status on %0 through %3. It displays -- when a drive is either not available or has no disk inserted, and updates the status 10 times a second which should be enough. Test it to make sure it behaves like you expect it to. The command line is now gauge x y "formatting", but there are no sanity checks on that input yet.

Originally Posted by ppill

Some further suggestions:

- maybe it could detach itself from the current CLI process (no need to run it)
- an option to open it as a borderless/notitlebar/backdrop window (save an extra line of the text for another window). Of course this would come after the window position option...

really happy with this

I'm looking into these things to make it look and behave a bit better.

I agree the proper thing would be to have it detach itself from the CLI, but the AmigaOS APIs are horribly arcane and the code needed to detach from the CLI process is almost a small application in itself. If you already have the run command available in Hombre it would be great for now.

[ppill]

Transferring it right now

By sanity checks you mean that the position is not verified before opening the window (so you could end up trying to open a window outside of the display)?

The 'run' bit as you said is a small detail. Nothing to worry about.

Just a small question. Does it lock the CON: window it was started from? Do you have to provide 'run <NIL: >NIL: gauge...' redirections?

I keep repeating myself... thanks!

Just the backdrop/borderless thing and we're set

Or maybe another small thing... free space on a volume/disk like %vdf0 %vSystem

EDIT:
It works! Just like it's supposed to
And just another note... it seems to lock CON: for output... but again nothing to worry about as '>NIL:' will take care of that

[Leffmann]

Originally Posted by ppill

By sanity checks you mean that the position is not verified before opening the window (so you could end up trying to open a window outside of the display)?

Neither that nor the order of the arguments. I've just been adding in all the functionality for now, will polish all the details later.

Originally Posted by ppill

Just a small question. Does it lock the CON: window it was started from? Do you have to provide 'run <NIL: >NIL: gauge...' redirections?

The C startup code might, but my own code doesn't touch the standard in and out, and only accepts the command line as sent by the C startup code. I'm not too familiar with this part of the AmigaDOS, what behavior are you looking for?

Originally Posted by ppill

Or maybe another small thing... free space on a volume/disk like %vdf0 %vSystem

Ok, I'll look into that too.

[ppill]

Neither that nor the order of the arguments. I've just been adding in all the functionality for now, will polish all the details later.

It works... that's the important bit. There's already an alias that configures everything as it should be.

The C startup code might, but my own code doesn't touch the standard in and out, and only accepts the command line as sent by the C startup code. I'm not too familiar with this part of the AmigaDOS, what behavior are you looking for?

When you run something it starts a different process so the command prompt is free but when you try to end the parent shell process (endcli for example) the prompt disappears but the window remains because it still expects messages from the command issued (via run) from it. So you end up with a pretty much useless window that will close only when the program quits.

Have a look here:
http://aminet.net/package/util/cli/RunBack

Nothing major really as >NIL: suppresses that window lock.

Ok, I'll look into that too.

Great

[Leffmann]

Added volume sizes on %vvolume: and %Vvolume: which prints free space in bytes and in abbreviated form as 1.2M, 345K, 678 or a dash character if the volume is not available. For the diskdrives it currently only works properly if you have a disk already inserted and leave it there, but looking into fixing this next.

Memory flags changed to %fc %ff %ft to show number of free bytes or %Fc %Ff %Ft to use the abbreviated form.

The abbreviated sizes are rounded down and count in amounts of 1000 and 1000000 bytes (as opposed to 1024 and 1048576).

Originally Posted by ppill

When you run something it starts a different process so the command prompt is free but when you try to end the parent shell process (endcli for example) the prompt disappears but the window remains because it still expects messages from the command issued (via run) from it. So you end up with a pretty much useless window that will close only when the program quits.

Nothing major really as >NIL: suppresses that window lock.

Right, that makes sense. I don't see this little app ending up on desktops everywhere so I think it's ok to specialize it for Hombre and just let your scripts handle this detail. It saves me a lot of coding, and this way we're both helping eachother out.

[ppill]

Added volume sizes on %vvolume: and %Vvolume: which prints free space in bytes and in abbreviated form as 1.2M, 345K, 678 or a dash character if the volume is not available. For the diskdrives it currently only works properly if you have a disk already inserted and leave it there, but looking into fixing this next.

Really cool feature there... the more choice the better. Maybe you could go full monty and add a percentage (free/full) display as well

Right, that makes sense. I don't see this little app ending up on desktops everywhere so I think it's ok to specialize it for Hombre and just let your scripts handle this detail. It saves me a lot of coding, and this way we're both helping eachother out.

Believe me, you're doing most of the hard work

The whole detach thing is nothing to worry about. It's not really a case of good vs sloppy coding. Sometimes you want to know what a program returns to its standard output (errors, warnings, info on what the hell it's doing etc.). Dozens of programs have to be started that way, especially patches. It just bloats the executable with unnecessary code. What's the point anyway when you could add redirection or use programs like RunBack or AsyncRun...

As always any updates appreciated

[Leffmann]

Moved the text into the title bar, and you can also specify -1 as X and/or Y window position to make it pop up at right side and bottom of the screen directly at startup, maybe you can test it and see if it looks and behaves like you expect. Diskdrive volume information still needs fixing.

[ppill]

Will check it tonight (been busy with finishing up the next release of Hombre).

Thanks for sticking with it... keep 'em coming

[StingRay]

Originally Posted by Leffmann

I agree the proper thing would be to have it detach itself from the CLI, but the AmigaOS APIs are horribly arcane and the code needed to detach from the CLI process is almost a small application in itself.

Detaching your process from the CLI is not too hard, you can use CreateProc() for that. I'll attach an example for you so you can see how it works, it's not much tested but should do the trick. Hope it helps.

; Create task

START	move.l	$4.w,a6
	lea	DOSname(pc),a1
	moveq	#0,d0
	jsr	-552(a6)		; OpenLibrary()
	lea	DOSbase(pc),a0
	move.l	d0,(a0)
	beq.b	.exit
	move.l	d0,a6

	lea	TaskName(pc),a0
	move.l	a0,d1			; name
	moveq	#0,d2			; priority
	lea	START-4(pc),a1
	move.l	(a1),d3			; seglist
	move.l	d3,Segment-TaskName(a0)
	clr.l	(a1)
	move.l	#4096,d4		; stack size
	jsr	-138(a6)		; CreateProc	
	moveq	#0,d0
	rts

	

.exit	rts

DOSname		dc.b	"dos.library",0
TaskName	dc.b	"TestProc",0
		CNOP	0,4
Segment		dc.l	0
DOSbase		dc.l	0




	SECTION	CODE,CODE
TEST	move.w	#$f00,$dff180
	btst	#6,$bfe001
	bne.b	TEST

	move.l	Segment,d1
	beq.b	.out
	move.l	DOSbase,a6
	jsr	-156(a6)		; UnLoadSeg()

	move.l	a6,a1
	move.l	$4.w,a6
	jsr	-414(a6)		; CloseLibrary()

.out	rts

[Leffmann]

Originally Posted by StingRay

Detaching your process from the CLI is not too hard, you can use CreateProc() for that. I'll attach an example for you so you can see how it works, it's not much tested but should do the trick. Hope it helps.

Thanks, I've got code for this now that takes care of the directory lock and picks up the process to unload the C startup code (I'm writing the app in C) in the end as well, though I've already decided to let the Run command handle all of this. Thanks for posting the code though.

What I need to do now is find a way of seeing if a device or volume is available, without having AmigaDOS open the "Insert volume ..."-requester, that can also handle removable media like diskettes and PCMCIA devices properly.