Mouse Attack

[mantadoc]

What goes wrong here ?

 

Bin file attached

 

Richard

MOUSEBIN3.BIN

[Asmusr]

The version I could find includes a GROM. Do you have an E/A#5 version?

[Tursi]

I looked at this and it seems like it is a copy cart that starts with a GROM simulator -- it copies code to RAM then executes it which "restarts" the console and adds MOUSKATTACK to the menu (and still sees the ROM cart MOUSE ATTACK). Selecting it crashes, though... at that point I don't know what has gone wrong. Most likely the copy went awry, but we'd need the original program to compare against to see where.

[mantadoc]

Here´s the files i used

 

yes it makes option 2 for mouse attack and 3 for mouse attack , and all go to title screen ?

MouseAttack.dsk

[Asmusr]

This disk seems to be relying on RAM at >6000 (a Supercart), which appears to be enabled in Classic99 by default? If I'm right then it will never work on a ROM cart.

[Asmusr]

My guess is that it's uploading a modified version of the Mousk Attack ROM to the Super Cart RAM. Modified in a way that allows it to work with a GROM emulator in 32K RAM. It then performs some soft reset trickery (using the GROM emulator?) to make the game appear in the menu.

 

So in order to make a ROM only cart out of this we would need to place the modified ROM in one of the banks of the cart. We would also need a loader in the startup bank that restores the RAM contents, switches to the bank with the modified ROM, and executes the program.

[sparkdrummer]

Try this'n

 

SSSD.dsk

 

 

[+Schmitzi]

cool, starts directly

[mantadoc]

WOW thanks guys , it works as cart now, but don´t get the point with the mouses in the game , or is it just me nothing happens

Edited April 2, 2016 by mantadoc

[mantadoc]

MOUSE ATTACK

MOUSE ATTACK3.BIN

[+Schmitzi]

.

if you mean that nothing happens on collision, I have the same so it´s a good run

[mantadoc]

Maybe a TI Wizard here can fix that

[Asmusr]

Collision detection is working in MAME/MESS, but not in Classic99 or JS99'er (checked with with ROM/GROM cart files). I assume it works on 9918A, but does it work on the F18A?

 

BTW, the game is called Mouskattack - not Mouse Attack - right?

 

Edit: It looks like the game tries to read the VDP status byte directly, but the console ISR is also reading it (which will clear it). Only MESS has the accurate enough timing for this to work. In JS99'er the ISR is always clearing the status byte before the game gets a chance to read it.

so_mousk_attack.rpk

[Tursi]

(Using Mouse Attack3.bin from post 10)

 

It seems to be a timing issue... I didn't get a chance to look too deeply, but collisions appear to be checked here:

 

   A8CC  D020  movb @>8802,R0              (34)
         8802
>  A8D0  0240  andi R0,>2000              
         2000
   A8D4  1350  jeq  >a976    

The main console interrupt also runs and so clears collisions. Because Classic99's sprite processing is desynchronized to the frame instead of during the frame, sprite collisions are not necessary reported at the exact correct moment in time. Games that poll frequently will probably get away with it, but this is one case that seems not to.

 

To try and prove it, I patched the code to read the status byte from the scratchpad mirror at >837B instead of directly from the VDP (so I simply changed the bytes at >A8CE from >8802 to >837B), and that got collisions working under Classic99. I'm not proposing that as a long term fix, this is definitely Classic99's fault.

 

I can't say why JS99er also fails -- you set the bits per scanline, don't you?

Edited April 3, 2016 by Tursi

[Asmusr]

I can't say why JS99er also fails -- you set the bits per scanline, don't you?

I came the the same conclusion as you (see Edit in post above). JS99'er has a scanline renderer for the F18A emulation and a less accurate renderer for the 9918A emulation. But in both cases the screen is drawn all together before the CPU gets a chance to kick in. Immediately after the ISR will execute and clear the status byte. The exception from this is code performed by the F18A HSYNC trigger, which will be executed while the screen in drawn. This makes F18A raster effects possible to emulate.

 

[Tursi]

Yeah, that'll do it. Sorry, I didn't see your edit, I had the thread open for a while before I looked at the issue.

[Flottmann1]

here on a real TI