SpritesMind.Net

matich wrote:AamirM,
Have you ever thought of enabling the link cable support ?

PS:
"Contra Hard Corps" bug (ReGen 0.6).
-> See video <-

Needs correct VRAM DMA FILL implementation (read charles mc donald document)

Shiru wrote:X-perts (UE) - game hangs after start (door not opens, any buttons has no effect). I remember that many old emulators had this problem.

Related to the VBlank flag : need correct timing and to be cleared after being read if i remember correctly.

Doing more intensive VDP access will cause Z80 to "slowdown" when it accesses ROM too.

I guess this is when you fill the VDP FIFO, the next write to the VDP port will lock the 68000 (and then the bus) until it free a FIFO emplacement. On real hardware you can avoid that by testing the "FIFO full ...

Of course i was speaking of example where we use the 68000 BUS from Z80, but i assure you i never met any problems. I think it can happen but rarely in fact.

Yes, but SEGA says it will give SOME people a problem SOMETIMES. If your stuff is aimed at a small group, you can probably ignore a lot of ...

HOHOOOO... I never halt Z80 when reading control pads, and my sound engine doesn't go crazy then... I must be lucky or something. It works on my MD2 and on my MD1s without TMSS.

Same here and honestly i'm happy we don't need that !

If you only run the Z80 on it's own memory and use the 68000 ...

Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the ...

Ok, i done all possible tests and i can confirm it is *not* possible to access 68k RAM from Z80. Any read from the Z80 return $FF and write doesn't work, they are simply ignored...
I tested on each possible areas ($E00000 to $FF0000) and it gave always the same result. I tested on a PAL model 1 and ...

Well, the addendum makes it sound like it's always, but it probably varies according to the exact revision of the chips used. It's possible it's even fixed on certain models.

There's also that issue on bus requesting the Z80 during an interrupt. That combined with the $A100xx issue is something to ...

Is it possible to do a real genesis debugger which work as GDB ?
I mean : you can interface it with IDE as Code::Blocks and you can watch your variables, do step by step execution etc... like a real debugger ! That would be totally awesome ! But i do know that is a lot of work

Well, there IS a bug in the real hardware associated with the Z80 accessing the 68000 bus: if the 68000 ever accesses $A100xx (the pads) without first requesting the Z80 bus, the Z80 will no longer be able to read/write the 68000 bus correctly. Apparently, the hardware cuts the Z80 cycles to the ...

Hi,

Steve Snake said(its also written in Charles MacDonalds's docs) that it was indeed possible on very early models. These were used for developing games. Later models would either lock-up or as in my case return 0xFF. I think only some models allowed it.

stay safe,

AamirM

Yeah i remember ...

Lately i was playing with z80 and i done some 68k ram access test. it works perfectly on emulator but my attempts failed on real hardware. At least the z80 isn't able to modify the 68k ram. I've rarely saw any games doing that (except '777 casino' but with inexpected result, i guess devers did ...

It can sound stupid but are you not simply doing division by 0 exception (%0) ?
This was first that I check. Of course not, especially in case %40 in code above.

If not, do you checked the i_ldiv function in sega.s file ? as you don't have the base library you need manual implementation of 32 ...

Can you wait for 3 minutes :( ? Unless you tell me a better way of testing how much RAM is available 8) ...

Also I've just uploaded a new version, it should be a little faster in the initialization...

3mn for RAM checking ???
Can't you just test one byte each 256 bytes of the memory map ?
If you ...

I think i'll have a look on the source code to understand how this is possible, i though the SVP couldn't be dumped ;)
It's simple - SVP uses the first 128K of game ROM for it's code, so there was no need to dump anything :)

ok, so the chip on the SVP board is a simple DSP without any internal ...