[MiNT] CF

["Konrad Kokoszkiewicz" <draco@obta.uw.edu.pl>]

Di boni, I was quite successful in reading current mails last months, and
now all of sudden I am 70 posts behind due to mintlist traffic ;)

> Mmmm... We could as well allocate space for the private cookie jar
> and the private natfeat structure at the same time.

Yes, we could. But it already is becoming a bit complicated (from the point
of view of "few lines of Aranym specific code" as advertised previously ;)).

> Seriously, when we will need that much cookies, we won't care about
> allocating 8 more ko per process, as our systems will offer some
> gigabytes of ram.

Well, as Odd pointed out, such thinking is a bit dangerous. Atari
documentation stated that to run MiNT you need 2,5 MB of RAM. Six years ago
MiNT + an AES + a desktop was already practically unusable on 4 megs, now
the same stuff is hardly usable on 14 megs. How many megs offer you true
comfort, when working with MiNT? 64?

Obviously, MiNT is now much better than six years ago. But the price we pay
should not IMHO convince us that memory requirements is no problem.

>> You need speed? How move.w #xxxx,$yyyy.w is slower than an illegal
>> instruction or a JSR?
>
> Because this means doing a check for every RAM access.

Originally I wanted to answer that not "every" RAM access is the concern,
because in short absolute addressing only 32768 addresses (the "upper half")
are to be checked. Despite that Aranym already emulates memory accesses, and
with proper function table this does not have to be so slow (at least:
adding one more address would not cause any slowdown).

But obviously I keep forgetting about JIT (I personally use non-JIT version
of Aranym).

> We could, in the future, imagine dropping any hardware emulation from
> aranym and use everything through natfeat.

If memory accesses (page faults under JIT) is a problem, shouldn't it be
solved when the argument of an instruction (an address for example) is
treated like a part of the instruction itself? Like understanding "move.w
#x,$fffe.w" and "move.w #x,$fffc.w" as separate commands simply doing
something, but not accessing any memory?

On Atari this would be only necessary for the hw register area. I am of
course theoreticizing here, I have no clue about the actual implementation.

> Personnaly, I would have directly used illegal opcodes, without using
> the cookie jar. That would be a lot cleaner, OS-wise.

Probably. And having proper XDD drivers nobody would need NF cookie and such
stuff.

> I think we could do something like using some opcode already used on
> ColdFire. To test for the natfeat existence, we could call this
> opcode and :
> - If a illegal instruction trap is taken, we're on a real m68k,
> - If the opcode do what it is supposed to do on a ColdFire (let's say
> it update a register), we're on a CF,
> - Then we could check the natfeat response.

This makes sense.

> I know Petr won't like this because it means changing Natfeat again.
> This means a lot of work. And no other emulator would use such a
> moving target.

Well, this is the usual price people pay for design flaws :)

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).