|
Post by gameblabla on Jan 22, 2022 5:28:40 GMT
So disabling shl 2, r10 or ld.w 0[r12], r10 does not freeze anymore but if done then it reports nothing, making it kind of useless. Alright, thanks! You've narrowed the problem down to a very specific narrow point ... and that's small enough that I feel that I should take a look and see if it's a simple fix. But, just to warn you ... it probably isn't, and I'll give up (sorry, but there's far too much to do to get distracted right now). I sort of narrowed it down yeah I thought initially it was because of the get phase thingy but even if i disable the jal call to it in status, then it still freezes. I feel like something causes a domino effect or maybe it is a timing issue ?
EDIT: Lol, it is get phase.
So this does not freeze :
_eris_low_scsi_status: mov lp, r15 shl 2, r10 movea lo(scsi_phase_status_tbl), r0, r12 movhi hi(scsi_phase_status_tbl), r12, r12 add r10, r12 ld.w 0[r12], r10 cmp 0, r10 be 1f blt 2f
mov 1, r13 out.h r13, 0x600[r0] out.h r0, 0x604[r0]
jmp [lp]
But this does
_eris_low_scsi_status: mov lp, r15 jal _eris_low_scsi_get_phase shl 2, r10 movea lo(scsi_phase_status_tbl), r0, r12 movhi hi(scsi_phase_status_tbl), r12, r12 add r10, r12 ld.w 0[r12], r10 cmp 0, r10 be 1f blt 2f
mov 1, r13 out.h r13, 0x600[r0] out.h r0, 0x604[r0]
jmp [lp]
So yeah, it is making things behave very strangely.
Time to look into the get_phase function i guess...
EDIT2: I also thought that maybe Mednafen was detecting that the CDROM drive was stopped and thus, rejecting the 0xD9 call. Well, it works of course, if you reset it... but by then it wll detect that the drive has been stopped and thus reject it. So yeah right now, as it is, i was able to fix the freeze issue but not the "can't issue another SCSI command" after a first one had been made without resetting it.
I think it would be easier to just fix the return status function right now and once that is done, use the 0x48 mode until we can figure out how to issue multiple SCSI commands without it ignoring the calls because this baffles me.
|
|
|
Post by elmer on Jan 22, 2022 18:42:15 GMT
I agree that the game programmer should not be concerned with underlying implementation. But the library which is linked into the game, also shouldn't be concerned with specific implementation... it should be a translation layer from "high level for game programmer" to "lower-level hardware-independent layer"... with the hardware-dependent stuff being on the hardware itself. ...But if we are, for some reason, concerned with specific SCSI codes so that they can be inserted into the linked-library layer... then a perfectly-working example is in the BIOS, and it may be the most straightforward implementation due to its simple hardware accesses. (So disassembly might be relatively straightforward) OK, that makes sense to me now. Yes, it is up to each manufacturer to decide were they want to draw the boundary of what is considered the firmware layer (routines in ROM), and what is considered the application layer (routines in libraries). While Sony didn't supply much in the way of hardware info for the PS1, Sega chose to deliver more, and NEC seems to have published complete hardware details in their documents ... which suggests that NEC were happy with developers hitting the low-level stuff directly, even if it was done through library code. Yes, looking at the routines in ROM may be a good idea ... but I think that the problem here may actually be much simpler. From the looks of it, neither Gameblabla nor OldRover were actually doing full SCSI transaction sequences, they're just sending out a command packet, and then not finishing off the transaction sequence, and so the SCSI bus is never released ... and then subsequent commands hang waiting for the bus to be clear. A quick look at Alex's high-level _eris_cd_read shows that his low-level routines *seem* to be working fine.
|
|
|
Post by elmer on Jan 23, 2022 17:11:09 GMT
From the looks of it, neither Gameblabla nor OldRover were actually doing full SCSI transaction sequences, they're just sending out a command packet, and then not finishing off the transaction sequence, and so the SCSI bus is never released ... and then subsequent commands hang waiting for the bus to be clear. If you're not familiar with SCSI programming, you can find the details in these old docs ... ANSI Small Computer System InterfaceSmall Computer System Interface - 2The 2nd doc is the final draft of SCSI-2, which was the version accepted as the standard, but actually getting the official standard costs money, whereas the final draft is free. Take a look at the SCSI Bus Phases part of either doc to see where you're going wrong. What you're doing in your code is to use the low-level function to send out a command, but then you're never moving on to the next phase. You can look at Alex's high-level CD-read for an example of doing that, but understand that your "play audio" command is different ... which is why you also need to look at NEC's documentation that I posted earlier. Looking again at Alex's low-level SCSI code, I'm pretty darned sure that it's just a disassembly of Hudson's library code, and so I expect that it is working fine. *Nobody* hand-writes code that looks like that source, it is almost incomprehensible due to its lack of equates, constants, label names or comments.
|
|
|
Post by dshadoff on Jan 23, 2022 17:17:06 GMT
*Nobody* hand-writes code that looks like that source, it is almost incomprehensible due to its lack of equates, constants, label names or comments. Oh I’ve seen code as you describe, written by “humans” in a business setting, but I shouldn’t derail the conversation…
|
|
|
Post by elmer on Jan 23, 2022 17:32:56 GMT
Oh I’ve seen code as you describe, written by “humans” in a business setting, but I shouldn’t derail the conversation… Hahaha ... yep, you're absolutely right, I concede! Looking at his assembly-language code *may* have been the final-straw that made me take a break from the PC-FX at the time. From my POV, a *lot* of the liberis low-level code needs to be either commented, or just plain rewritten. Maybe I'll get back to that after my current ASM and KickC work for the PCE, because the V810 CPU was really pleasant to program on. <EDIT> FWIW, ISOlink now supports building for the PC-FX.
|
|
|
Post by gameblabla on Jan 25, 2022 0:16:58 GMT
Hey guys, i finally managed to get my CD-DA track looping ! (At least on Mednafen, i will have to check on real hardware when my PC-FX will arrive in a few months) So elmer kinda gave me the idea that i should be looking at the cd_read examples since those are known not to cause the freeze. (i tested it on the SCSI_DMA example and i could make as many calls as i wanted) I was like : since i don't know a lot of V810 assembly, maybe i could just copy the cd_read assembly code, make GCC spit out my C code and then transplant that ? Well that shitty idea worked it seems It's on my github ( it's here) but i will post it here just in case also : _cd_playtrk: mov lp, r19 movea 0x7FF, r0, r10 not r10, r13 mov r6, r11 mov r7, r18 mov r8, r16 mov r16, r17 add r10, r16 # for rounding up and r13, r16 add -12,sp movea -40,r0,r10 st.h r0,-8[fp] st.b r6,-8[fp] st.b r10,-10[fp] mov -10,r6 mov 1,r10 st.h r0,-2[fp] st.b r10,-9[fp] add fp,r6 mov 10,r7 movea -128,r0,r10 st.h r0,-6[fp] st.h r0,-4[fp] st.b r10,-1[fp] jal _eris_low_scsi_command addi 32, sp, sp movea 0x800, r0, r10
1: nop nop nop nop add -1, r10 bne 1b
jal _eris_low_scsi_status
mov r18, r10 mov r19, lp jmp [lp]
_cd_endtrk: mov lp, r19 movea 0x7FF, r0, r10 not r10, r13 mov r6, r11 mov r7, r18 mov r8, r16 mov r16, r17 add r10, r16 # for rounding up and r13, r16 add -12,sp movea -39,r0,r10 st.b r7,-9[fp] st.b r6,-8[fp] st.b r10,-10[fp] addi -10,fp,r6 mov 10,r7 movea -128,r0,r10 st.b r10,-1[fp] jal _eris_low_scsi_command addi 32, sp, sp movea 0x800, r0, r10
1: nop nop nop nop add -1, r10 bne 1b
jal _eris_low_scsi_status
mov r18, r10 mov r19, lp jmp [lp]
It can probably be stripped down further but for now i will leave it as is. Also, HuC was actually of no help because they actually make a BIOS call to the System CD card for playing a CD track.
|
|