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