Re: [hatari-devel] TT emulation crashes when there is no ACSI drive

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

I'm afraid with my setup (TT, TOS 3.06) programs in the AUTO folder
(GEMDOS drive C:) are not executed anymore.

Best regards

Uwe

> Am Sun, 18 Aug 2019 09:46:07 +0200
> schrieb Thomas Huth <th.huth@xxxxxxxxx>:
> 
> > Am Fri, 16 Aug 2019 09:03:00 +0200
> > schrieb Thorsten Otto <admin@xxxxxxxxxxx>:
> > 
> > > On Freitag, 16. August 2019 08:39:24 CEST Christian Zietz wrote:  
> > > > No, it isn't! The new process gets its own initial user *and*
> > > > supervisor stack.    
> > > 
> > > Hm, maybe. I had something in mind that the supervisor stack was
> > > only used for OS calls, but maybe i'm wrong. Lets see how Thomas
> > > tries to solve the problem, and whether disabling interrupts
> > > helps.  
> > 
> > Disabling the interrupts seems to help in this case, to avoid the
> > crash, but unfortunately it is not a good solution either: If the
> > interrupts are disabled for too long (and clearing the of the BSS/heap
> > can take a while, especially with TT RAM), the mouse can not be moved
> > in that time frame anymore - and even worse, TOS gets confused of the
> > held back IKBD packages and recognizes wrong key presses afterwards.
> > 
> > So I think it's maybe best to finally get rid of this assembler kludge
> > now ... I'll try to rewrite the stuff in C in gemdos.c when I got some
> > spare time.
> 
> I've just committed the rewrite of the GEMDOS HD handling now. Please
> give it a try, it's been a major change, so there could be some
> regressions. Also worth to mention:
> 
> - The cartridge is not gone completely yet, it's still used for the
>   extended VDI resolutions
> 
> - The GEMDOS HD code still needs some few lines of 68k code - which 
>   is now patched into the end of the cartridge area. Not sure whether
>   that's the best spot and way to do it ... if someone has a better
>   idea, please let me know.
> 
> - The clearing of the BSS and heap is not blazing fast, especially
>   compared to the state before, when the FASTLOAD flag has not
>   been set in the program header (sorry, Vincent ;-) )
> 
> - The GEMDOS interception should now also continue if a PRG overrides
>   the GEMDOS vector, since we do not mess with the handler now anymore.
>   It might even work with MiNT now (but I haven't tried).
> 
> - I didn't check the symbol loading stuff in the debugger... Eero,
>   could you please verify that it still works right?
> 
>  Thomas
> 
>