Page 1 of 1

z80 busreq problem / GEMS

Posted: Tue Sep 16, 2014 8:43 pm
by powerofrecall

Code: Select all

_gemsholdz80:

          move.w    #$100,BUSREQ        ; Z80 bus request on
.hzlp:
		btst.b    #0,BUSREQ      ; spin on bus grant
          bne.s     .hzlp

          rts
This bit of code isn't working for me; when I call it in my vblank routine before reading the joypads, it hangs on the btst loop and never completes, at least in emulators and according to the MESS debugger. I don't have any way yet to really check this behavior on the real hardware other than seeing if it hangs. Is there some kind of other setup I need to be doing before I call this?

Posted: Tue Sep 16, 2014 8:54 pm
by powerofrecall
Do 68k interrupts need to be disabled first?

Posted: Tue Sep 16, 2014 9:58 pm
by powerofrecall
I guess gemsinit() needs to be called first? Which isn't very intuitive when you're calling gemsholdz80() in your vblank and enabling interrupts before jumping to main() is causing the gemsholdz80() call to beat it there. Maybe someone else can benefit from this info but I don't fully understand why this is so (wouldn't the busreq work normally anyway, regardless of what is loaded on the z80? Maybe it's my startup code.)

Posted: Tue Sep 23, 2014 2:58 am
by r57shell
_gemsholdz80 - is just busreq.
if you hold it somewhere (in main for example), and then interupt occured, and if it contains another hold call, it will deadlock, because you can't hold bus TWICE.

_gemsholdz80 - syscall, it's not user api. Call it on your own risk.

Actually, GEMS very powerfull driver, so you don't have to hold z80.
All you need to do with GEMS is call gemsdmastart before using DMA, and gemsdmastop after using DMA.
Why?
gemsdmastart = gemsholdz80 + set flag DONT_ACCESS_M68K + gemsreleazez80
gemsdmastop = gemsholdz80 + clear flag DONT_ACCESS_M68K + gemsreleazez80

Posted: Tue Sep 23, 2014 4:41 am
by powerofrecall
r57shell wrote:_gemsholdz80 - is just busreq.
if you hold it somewhere (in main for example), and then interupt occured, and if it contains another hold call, it will deadlock, because you can't hold bus TWICE.
I think this is what happened because refactoring my code eliminated the problem. Now that I am aware of it I can avoid doing this. It is good to know about the gemsdmastart/gemsdmastop as well.

Posted: Wed Sep 24, 2014 4:45 pm
by powerofrecall
Also, thank you for your GEMS tools. The splitter, combiner and instrument converters are very helpful :)

Posted: Wed Sep 24, 2014 9:56 pm
by r57shell
I need to update them :C
I need to do many other things too so, noone knows when it happen. :(