little system monitor for TOS

[Guillaume Tello]

Hi,


I started writing a little monitor for TOS without the need of a script
interpretor or multitasking.

I named it SYSREC (system record), and here are the features:
- it runs a program with its command line
- records every system call Gemdos/Bios/Xbios/VDI/AES/LineA (you can
select what you want in this list)
- don't record other programs'calls 'in particular, doesn't record the
VDI calls from the AES)
- recording can start immediately or after a Alt+Help key press
- a second Alt+Help stops recording and so on.. (record, stop)
- at the end you get two files:
* the first with the mem copy of the recorded codes
* the second, a text file with functions names

I'm working on it, adding the use of a SYSREC.INF file containing the
settings, so you d'ont have to retype everything.

I'll put this on my page when it will be useable.

Another idea would be to keep track of the calling addresses displayed
as an offset from the TEXT start. This would ease patching programs when
they need some new features.

Guillaume.

As an example, here is the ouput for TSTSCR_E.PRG that tests the screen
encoding:


GEMDOS(074/$04A) : Mshrink
AES (010/$00A) : appl_init
AES (077/$04D) : graf_handle
XBIOS (004/$004) : Getrez
VDI (100/$064) : v_opnvwk
VDI (102/$066) : vq_extnd
VDI (123/$07B) : v_hide_c
AES (100/$064) : wind_create
AES (051/$033) : form_dial
AES (101/$065) : wind_open
VDI (014/$00E) : vs_color
VDI (014/$00E) : vs_color
VDI (014/$00E) : vs_color
VDI (014/$00E) : vs_color
VDI (020/$014) : vsm_color
VDI (007/$007) : v_pmarker
VDI (020/$014) : vsm_color
VDI (007/$007) : v_pmarker
VDI (020/$014) : vsm_color
VDI (007/$007) : v_pmarker
VDI (020/$014) : vsm_color
VDI (007/$007) : v_pmarker
VDI (109/$06D) : vro_cpyfm
AES (102/$066) : wind_close
AES (103/$067) : wind_delete
AES (051/$033) : form_dial
VDI (122/$07A) : v_show_c
AES (052/$034) : form_alert
GEMDOS(060/$03C) : Fcreate
GEMDOS(064/$040) : Fwrite
GEMDOS(062/$03E) : Fclose
VDI (101/$065) : v_clsvwk
AES (019/$013) : appl_exit
GEMDOS(000/$000) : Pterm0

[PeP]

Nice!

Please make sure to make it mint-compatible (including memory
protection), and you have a winner!

-- PeP

[Guillaume Tello]

Post by PeP
Nice!
Please make sure to make it mint-compatible (including memory
protection), and you have a winner!
-- PeP

I will need some help for that:
What happens in this conditions?
SYS REC runs the program to monitor through PEXEC.
And, every trap from the program is redirected to SYSREC before it is
executed.
Will this hang the system ??

Have I some flags to set? Some functions to call to share my code with
the child program?

Guillaume.

[PeP]

        Have I some flags to set? Some functions to call to share my code with
the child program?

From that description, it could definitely work. Make sure to set the
executable flags in the header of the binary to "Super", to ensure
that it runs in the same memory space as the kernel. Unless you're
using something like PEXEC mode 106, I think the child will share
memory with the parent.

[Guillaume Tello]

Post by PeP

Post by Guillaume Tello
Have I some flags to set? Some functions to call to share my code with
the child program?

From that description, it could definitely work. Make sure to set the
executable flags in the header of the binary to "Super", to ensure
that it runs in the same memory space as the kernel. Unless you're
using something like PEXEC mode 106, I think the child will share
memory with the parent.

Okay, that looks easy.
Will you be able to make some testing?
I didn't finish yest, but it won't take long now.

Guillaume.

[lp]

in article

Post by PeP
Nice!
Please make sure to make it mint-compatible (including memory
protection), and you have a winner!

Sysmon does all that already, so really 2 things. Mint as you suggest and
open source would be a nice bonus. :)

[Guillaume Tello]

Post by lp
in article

Post by PeP
Nice!
Please make sure to make it mint-compatible (including memory
protection), and you have a winner!

Sysmon does all that already, so really 2 things. Mint as you suggest and
open source would be a nice bonus. :)

I always give my source code with the binaries.
Even if it's not always a gift to read my code...

Guillaume :-)))

[PeP]

        I always give my source code with the binaries.
        Even if it's not always a gift to read my code...
        Guillaume :-)))

Can't be worse than mine :)

Anyway - it's awesome that you release the source code. If there are
any problems with memory protection, it can be fixed.

-- PeP

[Guillaume Tello]

Post by PeP

Post by Guillaume Tello
I always give my source code with the binaries.
Even if it's not always a gift to read my code...
Guillaume :-)))

Can't be worse than mine :)
Anyway - it's awesome that you release the source code.

I stopped expecting to earn a living with Atari software long time
ago..! So why not share the source code?
The shareware experience with M_Player/MP_STE was a cool moment and it
really helped adapting the software to many configurations and many
video formats.

If there are

Post by PeP
any problems with memory protection, it can be fixed.

Great.

I don't use Mint, but if it could be useful for others with a little
work, this is worth it.
Guillaume.

Post by PeP
-- PeP

[Guillaume Tello]

Hi,

the little monitor is on my page, you can try it.
The version runs, no more. No beautiful interface, no error control for now.

It comes with docs in french/english, an example and source code.

In the table "THE PROGRAMS", line "System Recoder":
http://gtello.pagesperso-orange.fr/downld_e.htm

Works with TOS, with Mint, memory protection can be a problem...

Guillaume.

[Helmut Karlowski]

Post by Guillaume Tello
Hi,
the little monitor is on my page, you can try it.
The version runs, no more. No beautiful interface, no error control for now.
It comes with docs in french/english, an example and source code.
http://gtello.pagesperso-orange.fr/downld_e.htm
Works with TOS, with Mint, memory protection can be a problem...

Just tested with tstscr_f.prg and memory-protection: No problem.
No messing with auto-folder, additional helpers etc. I think it's usable.

Would it be possible to also output the parameters of the calls?

Is it possible to trace the VDI-calls from the builtin desktop?

-Helmut

[Guillaume Tello]

Post by Helmut Karlowski

Post by Guillaume Tello
Hi,
the little monitor is on my page, you can try it.
The version runs, no more. No beautiful interface, no error control for now.
It comes with docs in french/english, an example and source code.
http://gtello.pagesperso-orange.fr/downld_e.htm
Works with TOS, with Mint, memory protection can be a problem...

Just tested with tstscr_f.prg and memory-protection: No problem.
No messing with auto-folder, additional helpers etc. I think it's usable.

Waow, good news!

Post by Helmut Karlowski
Would it be possible to also output the parameters of the calls?

Yes of course, but it would be a greater work.
If I have some energy, I'll try it.

Post by Helmut Karlowski
Is it possible to trace the VDI-calls from the builtin desktop

Supposing that VDI calls are made from AES calls, they all are done in
Supervisor mode, and if the AES is in ROM, then the calling address is
easy to identify.
Else, I think that the desktop has a VDI Handle of 1.

But... As there is no START or END of the desktop, when to save the files?

WIth a key combination such as Alt+Help to start/stop recording
and Shift + Alt + Help to save.

ANd SYSREC should be installed as a TSR to go on working with the desktop.

Well well... another idea for sure...

Guillaume.

Post by Helmut Karlowski
-Helmut

[Helmut Karlowski]

Post by Guillaume Tello

Am 11.02.2011, 23:19 Uhr, schrieb Guillaume Tello =

Post by Guillaume Tello
Hi,
the little monitor is on my page, you can try it.
The version runs, no more. No beautiful interface, no error control for now.
It comes with docs in french/english, an example and source code.
http://gtello.pagesperso-orange.fr/downld_e.htm
Works with TOS, with Mint, memory protection can be a problem...

Just tested with tstscr_f.prg and memory-protection: No problem.
No messing with auto-folder, additional helpers etc. I think it's =
usable.

Waow, good news!

Not THAT good any more: It works nearly perfectly when run from =

commandline, but crashes my system when started by XaAES-launcher. But =

cli-mode is sufficient for the start. But it does not read the sysrec.in=
f =

when started from cli.

Post by Guillaume Tello

Would it be possible to also output the parameters of the calls?

Yes of course, but it would be a greater work.
If I have some energy, I'll try it.

That would be nice.

Post by Guillaume Tello

Is it possible to trace the VDI-calls from the builtin desktop

Supposing that VDI calls are made from AES calls, they all are done i=

n =

Post by Guillaume Tello
Supervisor mode, and if the AES is in ROM, then the calling address is=

=

Post by Guillaume Tello
easy to identify.
Else, I think that the desktop has a VDI Handle of 1.

The handle of the physical workstation is 1, I guess the virtual has 2.

Post by Guillaume Tello
But... As there is no START or END of the desktop, when to save the =
files?
WIth a key combination such as Alt+Help to start/stop recording
and Shift + Alt + Help to save.
ANd SYSREC should be installed as a TSR to go on working with the =
desktop.
Well well... another idea for sure...

I imagine to start it from mint.cnf, set it up to trace a process called=
=

"GEM", save e.g. VDI-calls (with parameters) to a file.

-Helmut

[Helmut Karlowski]

Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski

Post by Helmut Karlowski
cli-mode is sufficient for the start. But it does not read the
sysrec.inf when started from cli.

Have to enter SYSREC.INF as arg :-)

-Helmut

[Guillaume Tello]

Post by Helmut Karlowski
Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski

Post by Helmut Karlowski
cli-mode is sufficient for the start. But it does not read the
sysrec.inf when started from cli.

Have to enter SYSREC.INF as arg :-)

That's the answer I wanted to write !!!

From the AES, it should be installed as an application with its
directory as default to find SYSREC.INF.

Post by Helmut Karlowski
-Helmut

[Helmut Karlowski]

Post by Guillaume Tello

Post by Helmut Karlowski
Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski

Post by Helmut Karlowski
cli-mode is sufficient for the start. But it does not read the
sysrec.inf when started from cli.

Have to enter SYSREC.INF as arg :-)

That's the answer I wanted to write !!!
From the AES, it should be installed as an application with its =
directory as default to find SYSREC.INF.

This worked right away. The crash is not related to memory-prot, but to =
an =

old MiNT/XaAES-bug, so don't bother.

Now an option to start/stop at any time without launching another prog, =
=

maybe filter for callers adress or similar - I need the VDI-calls of the=
=

desktop!

-Helmut