Hi Vassili,

it's been a while since this arrived, so to help our memories I'll snip
carefully in the sections that are still relevant, but brutally in the
sections that we finished, or which are otherwise irrelevant now.


on Sun 07-11-1999 14:36 Vassilis Papathanassiou wrote:
>on Sat 06-11-1999 01:59 Ronald Andersson wrote:
>
>>----- snip ----- re: installation of the driver as MagiC DEV
>
>>Things don't get much more legal and compatible than that...  ;-)
>>
>Fortunately. But unfortunately MiNT developers don't seem very happy
>with HSMODEM and although several XDDs have been written to allow them
>to use it correctly, they still want to replace it completely. I'm
>afraid this will lead us to incompatibilities once more.

Yes, that could happen, but if they abandon compatibility to HSModem
to such as degree as dropping Bconmap and MAPTABs etc, then they are
going to lose lots of users.  Of that I am sure.

They want to replace everything with MiNT specific and MiNT dependent
variants.  One guy I discussed this with mentioned that some others
are working on a complete rewrite of all XBIOS functions...


>Maybe you already know their tendency. If something doesn't work under
>MagiC, it's MagiC's fault, it it doesn't work under MiNT, it's the
>program's fault :-(

I know.  They finally dropped the last remaining compatibility link to
old-style filesystems in version 1.15.1 (bye-bye MetaDOS and BetaDOS)
All they want to say about that is that all things that were available
in such filesystems is already available in better form as MiNT XFSs,
which I find a ridiculous statement. It only proves that they don't have
any idea of what they have done.  They simply don't value compatibility.


----- snip ----- re: TTD disassembler
>
>>Unlike other disassemblers, this allows me to keep on digging, interactively,
>>adding labels, bookmarks, comments, almost as if editing a source file, and
>>with the same effect on the source file which I can save at any time.  And
>>this can be done simultaneously for multiple files, which I really needed
>>with DRVIN and its modules.
>>
>I agree. I use it mostly for checking/correcting/updating Pure_C libs and
>it's really great. I wish it had Easyrider's options in the DATA/BSS areas.

I'm not sure exactly what options you mean here, I never use easyrider now,
and haven't for a long time.  If you try to explain it to me I could perhaps
convince Henk to add it in TTD.  He has added lots of things on suggestion.
(I am a TTD beta-tester.)


>>The drawback of most other disassemblers is that you can only do a fairly
>>small part of the analysis interactively, and then you have to abandon the
>>disassembler and do the rest of the job the hard way, in a text editor.
>>(Sorry about the digression, but TTD really is an excellent tool.)
>>
>It is excellent, no doubt, it works on every system with any resolution/
>colors, it has an easy way to update system traps/variables etc.
>It has two problems though. One is the user interface which is a bit
>tricky to use not to mention that the vertical slider changes in an
>undefined way. The second is that it can't identify correctly the object
>type of the code you throw at it.

The new versions can do this.  They differentiate between PureC format and
DevPac-format, and allow disassembly of pure binaries without any program
headers too.  As the latter are mostly (game) program parts to be loaded at
absolute addresses, the user is then prompted for a base offset, which will
be added to all local label positions and references in such a file.


>Worst, if you try to disassemble a
>program with all debug info in it, it would crash.

That does not happen with current versions.
There is still one type of PureC debug info that causes a non-fatal
problem, but I expect Henk will fix that too shortly.


>I had exchanged several
>mails with Henk during the summer concerning these problems and he told
>me that he can't do something about it, since DR object format is poorly
>designed. He did made TTD though to not crash anymore, it's just the
>disassembly that is garbage in such a case.

TTD is now completely compatible with DevPac, and handles all of its defined
formats for debug info and symbols (both the 8 char format and the extended
22 char format).  It also handles most PureC formats well, except for the
one combination mentioned above, and I'm sure that too will be fixed.

Henk's problem was only that he had little personal experience with DevPac
and no one who helped him find out all the necessary info.  Once I started to
give him that, he became almost as eager as I to have TTD DevPac compatible.
I am sure it is the same with the other problem, so I'll just do what I can
to help him again (if still needed).

I think many of those changes are already in the version on his page now,
which I believe was compiled in August.  But that is likely to change soon
anyway, as his work is still going on.  I received a new beta tonight, with
changes in the rules for local named label symbols, improved maintenance of
IDX filenames for multiple disassembly windows, and extended length of user
defined symbols and line comments (to 79 chars).

Those were some of the things I requested after my HSModem disassemblies,
and you know how recently they occurred, so I really can't agree that he
is unresponsive to requests.  Quite the opposite.


>But since its main usage is to 'sneak' to other's programs ;-) I also
>consider it a very valuable tool (the best to be exact).

That it is, without any doubt.  And the newest versions are far superior
to the old one that you must have.  If I were you I would write to him
and ask if you too can have the latest version.


----- snip ----- re: the enemy OS...  ;-)
>
>>Which says more about how this world works, than about that OS...  ;-)
>>
>You're opening a huge subject here. But of course it's the 'internals'
>of this world that make such crap a huge success.

Actually I see no way of discussing this huge subject meaningfully here,
so we may as well leave off at this point.  I think you and I understand
each other well enough on this from earlier discussions anyway.


>>>Let's get prepared for the next disaster: win2000!
>>
>>No, let's be consistent.  They've kept using the last two digits of the
>>year as version id for quite a while, so the next one is 'windows zero'.
>>
>Sure :-) Back to the roots! But don't get despair. They'll correct all
>the bugs until the year 3000.

Nope !  That's the year they'll have explored all possible bugs in
the universe and will start over, re-releasing 'windows zero' again.  :-)


>Hmm, being at borland.com the other day, I found that they're porting
>more and more of their development tools to other platforms. They
>started with Linux and now Solaris and some others. Light at the end
>of the tunnel ?

Could be. But m$ are so huge now that it is hard to see how any other
software company can compete on even terms with them.  Not with the
products of course, those can be lots better, but in other ways.
If only IBM had had more patience with DR, and let them do as good a
job as they were trying to do, we would not be in this situation.

Silly, isn't it ?  That m$ gained their position only because DR refused
to skimp on the job IBM had given them, though IBM wanted them to produce
a quick near-garbage version. DR insisted on quality and lost the contract.
Microsoft agreed to make garbage on demand, did so, and gained a software
monopoly that has made them one of the major economical forces on the planet.

There's a moral in there, but reading it right is not an obvious task.


>>----- snip ----- re: Serial 1 speed settings in SERIAL.CPX
>
>>I just checked in the docs, and there is a setting called RSVE, named after
>>the MFP speedup Harun Scheutzow himself designed.  With this setting the
>>port should go up to 115200, so that is probably it.
>>
>Yep, seems "install RSVE cookie" was the default setting for both MFP
>and MFP_TT. Removed from both and both now stop at 19200.

Good, so then no major changes are needed for the CPX, except possibly
for the MagiCPC Modem 2.  Right ?


>>----- snip ----- re: more on MagiCPC Modem 2  (current methods acceptable)
>>>
>>>For the moment we have no other option anyway. I did a quick disassembly
>>>of this driver and it contains calls to Intel code! This is a method
>>>I'd like to know since there are several peripherals on the PC I'd like
>>>to access, like eg. the ethernet drivers.
>>
>>I can think of several ways to include such an ability in an emulator.
>>
>>1:  Define a specific 68000 opcode (an illegal one) to cause emulation to
>>    halt and native Intel code execution to proceed at the next word after
>>    the special opcode.  The drawback is that some system procedure needs
>>    to be called to switch back then.  The advantage is that Intel code
>>    and 68000 code can be mixed rather freely.
>>
>AFAIK this is the method MagiC PC used up to now. Still I haven't seen
>any way to call an external PC program (eg a viewer) although it was
>possible (and probably still is) with Gemulator. You could define *.exe
>as executables for your desktop, so doubleclicking an exe program it
>was running from the ATARI desktop. Hmm, time to try it again with
>Gemulator 98.

I would not regard that as desirable, as it means a decreased compatibility.

Similar results can be achieved by other means.  For example, a program in
68000 code could take the name of a program in Intel code as argument. Then
it could switch to Intel mode using method '1:' and proceed to launch the
selected program.  This way the Pexec of TOS could still be identical to
that of standard TOS (or standard MagiC, in the case of MagiCPC). The way
of using such a method is identical to what you describe, but it has some
different implications for compatibility.


>>2:  As above, reserve an illegal 68000 opcode, but define this as a
>>    procedure call for native Intel code, so that the procedure returns
>>    into the calling part of the emulator which then proceeds with the
>>    68000 emulation at the address after the address argument of the
>>    special call opcode.
>>
>>3:  Instead of special opcodes it is possible to have reserved system
>>    routines that do the same thing.
>>
>Maybe 2 and/or 3 are used with MPC 6.1 which has a mystery 'Compile'
>option to mess with Intel code. I'll upgrade soon and then we'll know.

One user has reported problems using that mode with STinG.
NB: The conclusions below are made on scant information:

Personally I consider the very principle behind that mode erroneous.
It rests on the assumption that a built-in compiler can analyze the code
sufficiently well to translate it into Intel-code as a static copy, rather
than by interpretation (which is a safe method).  For complex software it
will inevitably lead to data being translated as code and/or code not being
translated in the belief that it is data. The result will then fail at some
point. No one else has been able to produce reliable code analysers before,
so I don't think ASH has one now either.  Such jobs need human minds.


>The problem is that Systems Solutions doesn't bother to publish newer
>versions of MagiC in english and the MagiC PC keyboard is really messed
>up, since it's not possible to correct it using KEYTABLS.SYS (they
>'steal' it from window$ before magic_pc.os (ie MAGIC.RAM) gets loaded).
>Thus I'll have to get a german version (again).

Have you tried my UKEX program.  (Available on my homepage.)
I have no idea if this will work with these MagiCPC versions, but it might.
As long as a compatible method of handling the keyboard IOREC buffer is used
it should work.  And some people use it both with MagiCPC and with MagicMc.
(But I don't know which versions.)


>>To identify the method with certainty you need many examples of such calls,
>>but fewer examples may suffice, when complemented with some experiments.
>>
>Unfortunately I have no time for such experiments at the moment.

I get your point.  Such stuff can steal a lot of time for small gains.


>>----- snip ----- re: using, calling, or emulating Fread/Fwrite
>
>>>If we get into trouble for the second method we can use the results to
>>>avoid using the first (!) and thus save passing through the GEMDOS
>>>handler which will be again a bit faster.
>>
>>Yes, but I have chosen an even faster method for the latest versions.
>>
>Should be the fastest really.

I think so too. At least I can't imagine any practical way to do it faster.


>----- snip ----- re: The new methods
>
>I've seen them now, they're really great!

I'm glad you think so, but I can't take all the credit.  It was Harun
who invented the basic method.  My contribution was only to reimplement
it in a form that can be used with all normal HSModem ports, so that we
can avoid all the system calls.


>>----- snip ----- re: SERIAL.CPX problem setting speed of PC Modem2
>>
>I'm saving this to make some tests first and let you know. ( Basicaly
>I agree with your points).

Ok, so we'll get back to this subject again later.


>>----- snip ----- re: illegal speed acceptance
>
>>>I've used an extra array with PC speeds in the CPX and detecting that
>>>we are at MgPC and the driver is MODEM2 this is used instead of the
>>>normal method. It currently works OK for my tests but of course it's not
>>>100% correct to get the speeds that way. Still it might be better for
>>>MagiC PC users to use the CPX that way than to give them an external
>>>program, since in this external program they'll have to supply the speed
>>>somehow (it can't be fixed of course).
>>
>>And then we'd have to make new releases of the CPX every time ASH feels
>>like changing something..., such as what baudrates should be supported.
>>
>No, they don't have control over this. PC serial speeds are so standard
>that even modems are build to accept them and nothing else (eg 76800).

That helps of course, but standards can change quickly sometimes.


>>Or when some PC standard changes, or whatever...
>>No thanks.
>>
>PC standard changes to serial speeds, no, I don't think so. They'll
>cancel the serial ports in the long run, since they want to move huge
>ammounts of data (and thus become richer).

Ok, so maybe they won't change serial speed then, but I really don't think
they will successfully cancel serial ports in any near time.  If they try,
then someone else will get rich selling add-on boards with such ports.


>>One solution here is to use a special patch program for it.  The driver
>>is simply not compatible enough to work well with any CPX setter, unless
>>the author wants to rely on alien systems for forced updates.
>>
>Yes, but it should be a TTP with speed as a parameter.

Or a GTP, and/or a collection  of PRGs, one for each speed needed.
Just drop the one you normally want into the auto folder, and use the
others or the TTP/GTP for the rare cases when you need another speed.
There are lots of ways to solve something like this...


>>Alternatively, if we must support this garbage in the CPX, it should
>>not be done by compiled-in constants...  that would not be acceptable.
>>Instead, use a simple text file holding on separate lines the rates
>>that should be allowed for this port.  This way the text can be fixed
>>without affecting the binary.
>>
>I think I'll go for that. But compiled-in constants... not acceptable...
>hmm, have a look at serial.cpx and you'll find what we feel are the
>constant speeds for the ATARI in an array called baudrate. I've just
>added a similar array like this:
>long  mgpc[] = {  230400, 115200, 57600, 38400, 19200, 9600, 4800,
>                    2400, 1200, 300, 110 };
>
>It works fine so far, I've saved the setting to CPX and forgot it.
>If you insist, I'll go for the external file method. But just think,
>is it worth it to include a file/line parser to the CPX for something
>that the probability is NOT to change ? (ie the PC serial speeds).

If the speeds really are that constant, then I suppose your method may
be acceptable.  I make no claim to being a PC expert. But if some more
port drivers appear for MagiCPC I don't want us to have to do it all over.


>>Best alternative (if feasible).  Convince ASH that this is the sort of
>>mistake they have to correct, as no comms programs will be able to use
>>the standard methods to find the available baudrates either, as it is.
>>
>Ok, I'll try that too.

Good.  They may ignore it, but it's worth asking about anyway.


>>----- snip ----- re: your wife's father
>
>>1 cm is a bit much I guess, but for smaller stuff I've heard that they can
>>use ultrasonics to pulverize them without surgery.
>>
>Yes, but with a 1 cm diameter they need very high ultrasonic power,
>enough to blow him up :-)

I don't really think so, but it would probably do serious internal damage.


>I'm fine now, but both my kids bring several viruses from school from
>time to time and although they can't heart me seriously (ie fever or
>bad colds) they try their best to do so, thus making me to not feel
>exactly well sometimes :-(

Just one of the many joys of fatherhood  ;-)


>Yes, it's a tricky part of the year, mainly due to large temperature
>differences during the day. Up to the end of October we had rather
>high temperatures from 15 degrees Celcius to 29. Suddently this came
>down, from 10 to 19 and doctors were happy once more :-)

Right, yet later in winter, when it is actually colder, there will usually
be less cases of cold-related illness, because then everyone have gotten
used to dressing in warm clothing regularly again.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
