Protected demos

All about ST/STE demos

Moderators: lotek_style, Mug UK, Moderator Team

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Protected demos

Postby Steven Seagal » Sun Oct 30, 2011 9:41 pm

I just posted something that made no sense and deleted, sorry if someone was reading.

Image

I'll just brag that Steem may now boot demo Phaleon, and more randomly Transbeauce 2 (not patched). I wonder if TB2 also regularly crashed on a real ST. Probably not...

I thought I did something complicated involving stopping the Trace process for some exceptions as I thought it was explained in Hatari, but I realised it worked without doing that, and I wonder if this info is up to date:

/* 2007/12/07 [NP] If Trace is enabled and a group 2 exception occurs (such as CHK), the trace */
/* handler should be called after the group 2's handler. If a bus error, address */
/* error or illegal occurs while Trace is enabled, the trace handler should not be */
/* called after this instruction (Transbeauce 2 Demo, Phaleon Demo). */
/* This means that if a CHK is executed while trace bit was set, we must set PC */
/* to CHK handler, turn trace off in the internal SR, but we must still call the */
/* trace handler one last time with the PC set to the CHK's handler (even if */
/* trace mode is internally turned off while processing an exception). Once trace */
/* handler is finished (RTE), we return to the CHK's handler. */
/* This is true for DIV BY 0, CHK, TRAPV and TRAP. */
/* Backport exception_trace() from WinUAE to handle this behaviour (used in */
/* Transbeauce 2 demo). */


I tried to do that but in Steem we must call the trace handler or those demos will never load. In other words, in Steem, the trace handler was already called after all exceptions, and it works better if I don't mess with it.

What makes those demos now load in Steem is the simple following hack in the exception procedure (also based on Hatari explanations, but there was a bud in Steem):

Code: Select all

        if((_ir & 0xf000)==(b00100000 << 8))
        {
          int offset;
          switch(_ir)
          {
          // War Heli: 0x2285,
          // already in Steem 3.2
          case 0x2285:
            offset=2;
            break;
          // Phaleon, Transbeauce2: 0x21F8,
          // as in Hatari
          case 0x21F8:
            offset=-2;
            break;
          default:
            BREAKPOINT; // to detect others
            offset=-2;
            break;
          }//sw
          _pc+=offset;
          TRACE("Opcode %X exception PC offset;%d\n",_ir,offset);
        }


There are other comments in Hatari regarding TB2, I may have missed something that would explain the randomness. I noticed that when it passes, the PC goes at some time from 402AC to the Illegal vector to 402B2.
When it crashes, the PC goes from 402AC to the Illegal vector to 402B4.


Steem also boots Dragonnels and Pandemonium now, but I'm not sure it's protection. It depends on the famous div timing (I put ijor's routines in Steem).

By the way, this isn't as hard as it looked. Despite this message in Steem source:

/*---------------------------------------------------------------------------
FILE: cpu.cpp
MODULE: emu
DESCRIPTION: A full cycle-accurate Motorola 68000 emulation core. Trying to
follow the functions in this file is extremely difficult, we recommend
treating it as a black box. The only parts of this file really required by
the rest of the program are the macro m68k_PROCESS that executes the next
instruction and cpu_routines_init in cpuinit.cpp.
---------------------------------------------------------------------------*/


navigation in their M68000 emulation isn't too hard, especially with a debugger. All code is clear, it's no black box.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Protected demos

Postby Steven Seagal » Mon Feb 06, 2012 8:53 pm

Funny how little attention this post got. Anyway I finally found why the TB2 protection only passed some of the times in Steem even after the first fix. It's because when there's an illegal instruction, the illegal vector wasn't called if Steem thought it detected a bus error first, taking a rather random value in A3. Like for Beyond, it makes sense that it wouldn't work so on a ST. Steem rocks!
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Protected demos

Postby Dio » Mon Feb 06, 2012 10:50 pm

Probably not relevant in this case, but last I tested, Steem's bus / address error emulation was sometimes inaccurate to the exact PC stacked (that's something that's very hard to get right), so if protection is dependent on that it will be a bit hit and miss.

gilles504
Atari freak
Atari freak
Posts: 69
Joined: Thu Aug 11, 2011 4:17 pm

Re: Protected demos

Postby gilles504 » Tue Feb 07, 2012 10:27 pm

find me a 68k core with a prefetch-correct PC stacked and I'll be very interested.
If a bus error happens just after a jmp the PC will be more or less after the jmp and not where the bus error is.
To emulate properly the bus error you need the original microcode and all the prefetch rules... for now I did not find them..

So I use a hack (to emulate the Apple Lisa with Lisa OS):
I refine the PC based on the opcode (I used mame 68k core for this emulator).

Code: Select all

INLINE void m68ki_stack_frame_buserr(uint sr)

{

    uint32 stacked_pc;

    IDLE_INIT_FUNC("m68ki_stack_frame_buserr()");

    switch (REG_IR) {

    // Some instruction are special when a bus or address error occurs

    // since the next opcode is (pre)fetched, the PC value is near the JMP, JSR or RTS

    // and not near the destination address.

    // The REG_PPPC macro is the previous instruction (always valid)

    // The REG_PPC is the current instruction address

    // The REG_PC is more or less the PC value (but wrong since prefetch is not emulated)





    // these are the opcodes that were controled on real hardware



    // RTS

    case 0x4E75:                               

          stacked_pc=(REG_PPPC+2)&CPU_ADDRESS_MASK;

       break;

    // JMP immediate32

    case 0x4EF9:

       stacked_pc=(REG_PPPC+2)&CPU_ADDRESS_MASK;

       break;



    // these are the theorical opcodes (may be wrong)

    // (this one in particular (see german version of LOS2.0))

    // JMP (Reg)

    case 0x4ED0:
...

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Protected demos

Postby Dio » Tue Feb 07, 2012 10:52 pm

To emulate properly the bus error you need the original microcode and all the prefetch rules...

No, just a core verifier that means you can prove you have the same results as a real 68000 :D .

I've written a tester that checks both the PC location and the timing for the majority of the possible bus and address errors on a real ST - source read, dest read and dest write at least, the main ones I haven't been able to do are opcode read errors, although in theory it is possible.

It's not quite finished and so I haven't got around to fixing all the problems in Emu yet (although the default behaviour with Emu is pretty close because every access is coded rather than table driven). I've tried to use it to reverse engineer the exact prefetch algorithms and it does my head in :D . Every time I think I've worked it out I find some exception. But that's probably natural since the entire thing is hand-coded in the microcode.

gilles504
Atari freak
Atari freak
Posts: 69
Joined: Thu Aug 11, 2011 4:17 pm

Re: Protected demos

Postby gilles504 » Tue Feb 07, 2012 11:15 pm

the table makes sense for a microcoded processor :)
my modified core is also "correct" for my use but to achieve perfect prefetch would be better.
I just tried some opcodes on real hardware but only to confirm the vague information that was present in the motorola manuals (something like "the PC is near the jump that caused bus error").
Anyway, an MMU and virtual memory with a plain 68000 is a bit weird... but... It worked (slowly...) on the lisa


Social Media

     

Return to “Demos - General”

Who is online

Users browsing this forum: No registered users and 11 guests