Important (for MagicPC Users): Patch
19) only works as planed with a MagicPC version which will be published
sometime later in 2000+x.
This patch is supposed to bring the Pure Debugger to modern times. The problem is, that (AFAIK) ASH is not allowed, for license reasons, to make an update by themselves. Therefore somebody else had to do it, without the source code. Since I like using PD I did so.
Problems of PD I know of, their conditions of occurrence, and their
status (S = solved, N = not solved, U= understood but still unsolved):
Nr. | SNU | occurrence | Explanation |
1 | U | Multitasking | Sometimes at leaving PD the left mouse button seams pressed. |
2 | S | MagiC | PC can't start PD as single task. |
3 | S | MagiC... | PD does not closes open files on 'Program reset' -> on restart Fopen produces an error. |
4 | S | always | PD does not uses XBRA. |
5 | S | always | PD redirects vectors but does not test if a program, jumping over these vectors is PD or anybody else -> for example if a program, running parallel to PD finishes (Pterm), PD assumes, that this means, that the program to debug has finished. |
6 | U | graphic card | changing screen per Setscreen does not work. |
7 | S | always | On running the first program, PD prints an ESC H -> if a console window (Gemini,...) is open, the Cursor goes to the upper left corner. |
8 | S | Multitasking | sometimes the wrong menu is visible. |
9 | S | MiNT | PD does not work at all, I was told. |
10 | S | 2 monitors | this is not solving an error, but adding a new feature: you can now run PD on 2 monitors. |
11 | S | ? | Sometimes the mouse cursor disappears. |
12 | S | Multitasking | PD sometimes tries to get memory at the top end, this routine sometimes fails under multitasking OS and always under MagiC. Normally this has no direct effect, since PD reserves memory at a random position in this case. |
13 | S | ? | For some time the one monitor version, including the unpatched PD, crashed when it tried to change the screen by Setscreen. Since changing the method in the option menu didn't helped an other patch become necessary. |
14 | S | >Gemdos 0.19 | PD memorizes all Malloc actions to be able to free this memory in program reset. But it ignores Mxalloc. |
15 | S | always | View File opens a file, reads it, but never closes it. -> Handles get lost and on OS which test if a file is already open, a file can not be written back again. |
16 | S | PCI-MAC | PD tests if a MegaST(E) FPU is present, this test causes a crash on PCI-Macs |
17 | ? | CPU>68030 | The Cache is always cleared according on the 68020/30 way. |
18 | S | >= TT | In 'Program info' Addresses and Length are given as 6 digit HEX numbers. This is not enough on 32 bit address bus machines. |
19 | S | MagiC PC>6.1 | MagiC PC 6.1 has a compiler-modus which is incompatible with PD. Therefore the Compiler is automatically switched off. |
20 | S | MiNT/N.AES | PD takes no input from Keyboard. |
21 | U | always | To enter a watch expression a form which accepts 63 characters is used, but only 49 are processed. |
22 | S | Drives>P: | Pd only accepts pathes on drives <=P |
To add new routines, some addresses in PD have to be known. This
addresses are stored in PD_ADDR.DAT. On the first run Patch tries to find
this addresses and stores them for future use. But this is not foolproof:
If none or more then one occurrences are found, an error message is issued. Since not all addresses are needed for every patch, you can still try. If a needed address is unknown the patch will stop. For easier control, there will be a text version of pd_addr.dat written: pd_addr.txtThe searched routines have changed (different PD version than mine)-> wrong or no address found. Somewhere else something has changed, so that by chance it looks like the routine -> it seams to be found twice.
usually I also have -Y set in all 3 categories, but this is not mandatory. Now I also set this options in the PRJ-File, so setting them explicitly in PC is probably not necessary anymore. If for whatever reasons you are using an other Compiler but PC, don't expect to have no problems.Compiler: -C, -P Assembler: -S Linker -G, -L, -F, Stacksize 100000
Since menus, windows and the like are not drawn by AES in PD, but
are drawn directly by VDI on the screen, they are kind of invisible to
mouse clicks. The only reason there are not more problems is because PD
runs in supervisor mode, but at the end of the program problems occurre.
I tried solving this problem using wind_update(BEG_MOUSCTRL) but received
some strange effects.
To be able to run PD out of PC in single task I wrote a starter
(START_PD). It starts PD by sending a message (AV-Protocol) to the shell.
If this shell understands AV it should find out, if PD has to be run in
single task and if so starts it in single task. There has been a problem
with the desktop EASE, it didn't gave PD the comandline. If you press the
ALTERNATE button while starting START_PD it will ask some questions:
To make it clear, telling the starter to start PD as singletask only works, if the AV-Server does it.singletask or multitask? 1 or 2 monitors? (PD_1.PRG or PD_2.PRG)
If at the end of the program (the one to be debugged) or on a break
there are still files open, they will still be open on a new run. Some
OS like MagiC realize, that this file is tried to be opened for a second
time and exit an error. My solution is to log the calls of Fcreate, Fopen
and Fdelete. On 'program reset' these files are closed automatically. Until
now only handles between 6 and 63 are observed. If this should not be enough,
change p_flags in PDX, and all routines using it. But the worst case possible
is that PD reacts for files with handle >63 as it used to with any handle.
I introduced a XBRA structure for all routines changed by Setexc.
The ID is 'PDeb' for PD_1 and 'PDEB' for PD_2. The XBRA-Implementation
is complete now, meaning, that also deinstalling is done by XBRA. But since
PD is to be used with unfinished software, this is not always possible.
So if the deinstalling routine does not find it's own ID, it will reset
the vector to the original state. The reason for using 2 ID's is, to be
able to debug PD_1 with PD_2.
PD does not test who is jumping over changed vectors. In single
task this is fine, but not in multitasking. One very 'nice' error occurs,
when you end a program running parallel to PD. PD exits the message 'program
terminated' and exits the run modus. But the program which was debugged
is still running, even after finishing PD! Don't ask me what this can cause
for problems (who owns the memory,...). Before finding out I always pressed
reset. Now PD saves the address of its Basepage at the beginning. Every
time a changed vector (XBRA) is used, it is tested if it's PD or not. Either
the original routine is used or the PD one. This patch needs 4)
and is needed for 3). For every rule there is an exeption.
PD uses the hardcopy Interrupt as a break. (<ALT><HELP>) If this
would be only active while PD is executed, this would mean that you have
to press <ALT><HELP> for some time. Since this routine only sets
a flag, there is no problem of letting it being active even if an other
program is executed. This flag is tested during the vertical Blanc routine.
Meaning, that the <ALT><HELP> is memorized at all time, but that
PD only reacts if there is a vb during the time PD is executed. So if PD
does not react try pressing a button, moving a Window of the program debugged,...
PD reserves ST-RAM for a 2nd and 3rd screen, then it tries out if
Setscreen is working. Setscreen would work on some graphic-cards (NOVA,...)
if their RAM and not ST-RAM would be used. So I tried to fake the malloc,
but without success. The problem seems to be that NOVA-RAM starts at 0xFEC00000
which is negative... . As a partial solution TT-Ram is used in case a graphic
card is recognized. By now only NOVA cards are recognized by:
if (get_cookie('IMNE',(long *)&icb))for other graphic cards, the if-condition can either be changed to recognize other cards by adding '||...' or if the card is always used by deleting the "if" totally. X_pd.p_bs_m includes the Mxalloc modus. It is usually 0, but will be changed here to 3. This patch is only included in the one-monitor-patch.
X_pd.p_bs_m=3;
On the first RUN PD prints ESC H, if a console window(Gemini,...)
is open, the cursor goes to the upper left corner. If this is wanted or
not can be chosen by everybody self. I introduced 3 possibilities:
In multitasking environments sometimes the wrong menu is visible,
even if the right one is active. I didn't found all circumstances under
which it occurs. Therefore I only added an automatic redraw of the menu
shortly after the start of the program, and for all other cases I added
an manual possibility. Just click in the menu line (y<18) and the menu
is redrawn. Of course this should be done in the right unused part of the
menu. This is only included in the one-monitor-solution, since this problem
does not exist with 2 monitors.
I don't know. I never installed MiNT, I am not actually interested
in it. But Thomas Künneth and Chris Felsch wrote a starter which makes
it possible to run PD under MiNT. I included this starter in my own ( see
2)
) and so it should be possible to use PD under MiNT now.
This was the reason I started writing this patch in the first place.
With this version it is possible to use 2 monitors, similar to the very
good program, SYSMON. It is quite difficult to redirect AES-output, even
more to a different resolution. But luckily this is not necessary, since
PD only uses VDI-calls. Therefore it is only necessary to open a OFF-Screen
Bitmap and return PD that handle instead to the one expected of v_opnvwk.
Besides the mouse cursor has to be drawn by PD itselve. But all this problems
are solved under some conditions:
Problems could occur, if a second program, uses two monitors too, but the only other program doing so I know off, SYSMON works together with my one just fine.VDI which supports OFF-screen bitmaps, either per v_opnvwk2 (NOVA-VDI) or by v_opnbm (NVDI, NOVA and others if the EdDI-cookie is present with version >=1.1) ATARI-compatible monitor and second monitor by graphic card is present.
As I never observed this error while using my TT, which probably
is mainly caused by the fact, that I almost always used PD with 2 monitors,
I only introduced a symptomatic solution. Now on the PC I did had that
error, but debugging PD while it is debugging on a one monitor machine
would be verry difficult. So if the cursor disappears, just press the right
mouse button and it should reappear.
While trying to further improve my XBRA implementation (see
4)) I analyzed a routine and realized, that it had 2 errors. PD sometimes
try to get memory at the top end. Therefore it first reserves all memory
(in a loop containing Malloc(-1)), but this fails if a other program reserves
memory in the meantime. This could be solved by changing the break - condition.
Then PD looks for the highest so reserved block and tries to split it so,
that the top part gets the needed size. This doesn't function under MagiC,
since there 32 extra Bytes are reserved with any Malloc. For example if
the Block has 3000 Byte and PD needs 1000, PD shrinks (Mshrink) the Block
to 2000 and tries to reserve 1000. But under MagiC there are only 968 Bytes
left. To be on the safe side I now always shrink to 64 Bytes less then
required under TOS -> I spoil 64 Bytes under TOS, 32 under MagiC. But maybe
some other OS needs more. Of course I could calculate the exact length
needed, but to save a few byte this is not sensible, certainly not if the
produced code would be longer than the saved memory.
This patch is optional and should only be used if PD otherwise does
not run. I just exchanged the original Setscreen by an empty function:
{}
this works because PD checks after using Setscreen if it was successful,
and if not uses an other way of changing the screen.
Since I already introduced my own Fopen, Fcreate and Fclose I decided
to include a complete Version of the Gemdos Dispatcher into the Patch.
This also includes Mxalloc, where, as with Malloc in the original PD, all
memory allocation is memorized.
View File opens a file, reads it, but never closes it. -> Handles
get lost and on OS which test if a file is already open, a file can not
be written back again. Therefore I included a Fclose.
Now it is possible to deactivate the test for an MegaST(E) FPU so
it should work an PCI-MACs, which I can not test myself.
The Cache can now be cleared alternatively on the 68020/30 or 68040
way or not at all. To decide which method to use, the _CPU cookie is analyzed.
This patch is in a ß-stadium, I can not test it, so please if you
can tell me if it works and if not try to change the routine clear_cpu_0
in PD_LIB_s.s.
I increased the size of the output of the addresses and length to
8 digit.
The new MagicPC compiler mode causes problems with PD, for example
there are problems with the keyboard. Therefore the compiler is switched
off by PD. This does not work with MagicPC6.1 (before 7.OCT.99), so the
compiler has to be switched off by hand (get an update). And with versions
before 2000 the compiler will always be switched on at the end. With the
next MagicPC Version it will be returned to the status at which PD was
started.
MagiCPC Version | Compiler mode | controlable per Software | Problems with PD |
<6.10 | no | no | all OK |
6.10 before 7.OCT.99 | yes | only manually | Problems with keyboard entries |
6.10 of 7.OCT.99 | yes | switching on/off : yes, checking actual state : no | PD doesn't restores state at the end but always switches compiler on. |
after 1.1.2000 | yes | checking too | all OK |
Under some configurations PD takes no input from keyboard. This
is due to the fact, that there is a problem with this configurations and
input by BIOS functions. This is no error of PD but can be solved here.
The solution is to use Gemdos functions instead.
as said in 9) I will try to solve other problems
with PD anybody tells me off. It has a good reason, that I include the
source code. So anybody can include patches by himself, this is needed
either when I am not reachable or if it's a problem I don't have with my
configuration. But I recommend, that every change/addition is brought to
my attention. Then I'll include it in a new public version. This definitely
includes the case, that GET_ADDR doesn't find an address by itself but
you find it by yourself.
This program is Fairware, it may be copied freely, but if somebody
needs to get rid of some money...
On no circumstance PD, either the original or a patched version
may be exchanged without the prior approval of ASH.
This program may only be used to patch officially bought versions of the
Pure Debugger. This is especially true, since some routines (xbra_exc and
xbra_Gd_trm) included in the source code are variations of the original
PD code. These are specially marked. Exeption, I will give a patched version
to ASH. Probably they will put it in their BOX, so that it is accessible
to registered users. But since there are some options on patching PD, this
is only 2nd best to patching it by yourself.
Bernhard Held volunteered as ß-tester.
Thomas Künneth and Chris Felsch for their Mint-starter
Wilfried Behne for his help in searching an error (in my patch) in
connection with NVDI.
Oliver Buchmann for answering many question about MagicPC.