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

Nice!

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

-- PeP

Le 09/02/2011 10:06, PeP a �crit :
> 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.

in article 
4c11cf91-2709-470f-be8e-0733b663180d@d23g2000prj.googlegroups.com, Peter
Persson wrote on 2/9/11 4:06 AM:

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

-- 
http://www.bright.net/~gfabasic/ [GFA-Basic, AtarIRC, Hades060, FreeMiNT]

Le 09/02/2011 17:09, lp a �crit :
> in article
> 4c11cf91-2709-470f-be8e-0733b663180d@d23g2000prj.googlegroups.com, Peter
> Persson wrote on 2/9/11 4:06 AM:
>
>> 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 :-)))

> =A0 =A0 =A0 =A0 I always give my source code with the binaries.
> =A0 =A0 =A0 =A0 Even if it's not always a gift to read my code...
>
> =A0 =A0 =A0 =A0 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

Le 10/02/2011 09:34, PeP a �crit :
>>          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.

Le 10/02/2011 09:34, PeP a �crit :
>>          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
> 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.
>
> -- PeP

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.

Am 11.02.2011, 23:19 Uhr, schrieb Guillaume Tello <houten.van@orange.fr>:

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

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

Le 19/02/2011 09:05, Helmut Karlowski a �crit :
> Am 11.02.2011, 23:19 Uhr, schrieb Guillaume Tello <houten.van@orange.fr>:
>
>> 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...
>
> 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!

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

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

>
> -Helmut

Am 19.02.2011, 09:24 Uhr, schrieb Guillaume Tello <houten.van@orange.fr>=
:

> Le 19/02/2011 09:05, Helmut Karlowski a =E9crit :
>> Am 11.02.2011, 23:19 Uhr, schrieb Guillaume Tello  =

>> <houten.van@orange.fr>:
>>
>>> 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...
>>
>> 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.


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

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

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

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

> 	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

Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski  
<helmut.karlowski@ish.de>:

> 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

Le 19/02/2011 10:24, Helmut Karlowski a �crit :
> Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski
> <helmut.karlowski@ish.de>:
>
>> 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.
>
> -Helmut

Am 19.02.2011, 10:29 Uhr, schrieb Guillaume Tello <houten.van@orange.fr>=
:

> Le 19/02/2011 10:24, Helmut Karlowski a =E9crit :
>> Am 19.02.2011, 10:05 Uhr, schrieb Helmut Karlowski
>> <helmut.karlowski@ish.de>:
>>
>>> 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