Re: [hatari-devel] add support for TT ram ?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On keskiviikko 17 joulukuu 2014, Nicolas Pomarède wrote:
> Le 17/12/2014 21:15, Eero Tamminen a écrit :
> > I've changed TOS memory setup code to automatically disable 24-bit
> > addressing and fastboot if TT-RAM is used under TT emulation.  It
> > will notify user about about this.
> > 
> > As there's no point in using 32-addressing unless there's TT-RAM,
> > and it makes things less compatible, I'm forcing 24-bit addressing
> > when TT-RAM is not in use.  Should I remove 24-bit selection from
> > SDL GUI, options and config file too?
> 
> I think your changes are a little too restrictive at the moment, because
> basically it prevents me from working on TT RAM for falcon :)
> 
> -> don't force nTTRamSize=0 if machine is not a TT, the code in memory.c
> will not allocate RAM anyway.

NAK.  Otherwise statusbar shows bogus info, as there's no other variable
that could be checked for TT-RAM.


Btw. I noticed another issue with TOS v3, which isn't there with
EmuTOS... TT-RAM is detected only when there's 4MB or less of ST-RAM
(based on what Sysinfo application reports).


> -> don't force 24 bit addressing if not TT
> 
> Both cases should be removed, let's just force 32 bit and normal boot at
> the moment only for TT.
> 
> As for forcing 24 bit addressing, I think it should be forced only when
> CPU is a 68000, but in all others cases, even if no extra ram is added,
> it should be left as selected by the user.

Ok, I relaxed these.

You can remove the fast boot thing at the same time when you
start supporting it. :)


> 32 bits adressing are required when Falcon will have extra RAM, and it
> can be needed to for better compatibility with a real Falcon where it's
> the PMMU that does the translation.
> 
> And even if 32 bit is less stable (HD gemdos emulation at the moment for
> example), I'd rather have people test it anyway and report bugs, as it
> should work with recent TOS (this allowed to see the cartdridge bug at
> $FA0000 in EmuTOS and the DTA bug in HD gemdos)
> 
> > No need to wait, Vincent did EmuTOS CVS snapshot including the fix:
> > http://sourceforge.net/projects/emutos/files/snapshots/CVS-20141215/
> 
> Yes, but I meant wait for next official release, I don't think users
> want to look for the latest cvs devel version which might not be ready
> for "production".

I've found CVS snapshots to work fine.

Only issue in them is missing localization for other languages
than English, but that doesn't affect the fucntionality... :-)

(If somebody is already using Hatari snapshots, why he wouldn't
use EmuTOS snapshots?)


> >> So, only solution for now to have extra TT RAM and HD is to use
> >> a direct HD image, not the HD gemdos emulation.
> > 
> > Just use EmuTOS, only TOS v3 has that problem.
> 
> If we limit ourselves to stable release, EmuTOS is not ready yet.
> 
> > After these are done, the forcing part can be updated.
> 
> Yes, some changes will be needed


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/