MMC hard drive emulation?

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sat Feb 27, 2016 6:22 pm

I was wondering about a script that searches binaries for JMP instructions ( if it is data we will just get false results) then works out if they could be branches .

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 6:28 pm

dp11 wrote:I was wondering about a script that searches binaries for JMP instructions ( if it is data we will just get false results) then works out if they could be branches .
Not a bad idea as such, but to make a couple of probably obvious points/suggestions:
  • During my initial optimisation pass, I simply did a global search and replace for JMP->BRA and then manually reverted all the ones which failed at assembly time. This was tedious but may be less effort in the short-medium term than writing a script. I'm willing to do this once or twice more, say at the point at which the current stream of optimisations peters out (because you get fed up finding them, or all the relatively obvious ones have gone).
  • Now the code is getting "label-ised" this is a bit harder at the source level (perhaps, maybe it doesn't make that much difference). It might be easiest to write such a tool to operate on the beebasm -v output which shows the generated code along with the source. I'd be happy to zip up a sample such output if you want to take a look at one.
ETA: Sorry, I see you actually said to search the binaries. But maybe searching the beebasm output would be less false-positive prone, if perhaps less generally applicable. Your suggestion is quite clever now I think about it properly.

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 6:38 pm

dp11 wrote:Just having a little look at mmc.asm
I've applied the STZ change in MMC_SetCommand and the CLC removal from setAddressFromStack.

I'm leery of making the other changes you've proposed given Dave's comments about the inner loop. What do you think?

Cheers.

Steve

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 6:41 pm

hoglet wrote:So optimize away!

But try to avoid adding overhead to any of the inner loops.
hoglet wrote:I would be wary of speeding up the inner loops, unless you check they meet the guidelines in the tube app note.
Cheers Dave, but you have kind of scared me off now :-)

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sat Feb 27, 2016 6:47 pm

SteveF wrote:
hoglet wrote:So optimize away!

But try to avoid adding overhead to any of the inner loops.
hoglet wrote:I would be wary of speeding up the inner loops, unless you check they meet the guidelines in the tube app note.
Cheers Dave, but you have kind of scared me off now :-)
The most important hard requirement is we don't read or write the tube data register (&FEE5) faster than every 10us, or some Co Pro's (e.g. the original Z80) won't be able to keep up.

I believe some of the code is timed to be exactly 10us.

Slower will work, but err, will just be slower.

Dave

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sat Feb 27, 2016 7:51 pm

Re script: this could be extend to actually be the start of a peep hole optimiser the CLC, ROL A => ASL A is just manual peep hole . I don't mind false positives as it is quicker than find in an editor.

The other mmc change should be perfectly safe with respect to timing

Code: Select all

.nmi_lda_imm_rom_bank
       LDA #&00		;; replaced with actual ROM bank
       STA &F4
       STA &FE30
Stz can be used and the LDA removed

Code: Select all

.LBD55 ;** remove LDA #&00
       STZ &A3
       JSR chunk_13_a0
       BRA LBCE5
..

.LBE5C LDA &A2
       AND #&08
       BEQ LBE77_rts
       JSR LBD46
       LDA #&08
       TRB &A2
       INC &A3
       JSR LBD40
 ;;* remove      LDA #&00
       JSR chunk_13_a0
       BPL LBE41       
 
 ...
.chunk_13_a0
	LDA	#&00 
 .chunk_13
       ORA &0D5C
       STA &FE28        ;; FDC Status/Command
       RTS      
       

Code: Select all

.L9D05 PHY
       JSR LA744  ; this is defined to return a=0
       LDY #&AC
       LDX #&09
       LDA #&00 ; this can then be removed
.L9D0F ORA (&BA),Y

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 9:51 pm

OK, I've knocked up a first version of a Python peephole optimiser; it's committed as peephole.py. It only does JMP->BRA, but I think that's actually the most important thing - especially given the regular formatting of the source code with only one opcode per line, things like 'CLC:ROR A'->'LSR A' could probably be handled more conveniently via a sed/awk script which operates directly on the source. (Or maybe jsr-maker.py, which parses the source, could be used as a base.) The JMP->BRA case is special as it requires knowledge of exact addresses which is only obvious when operating on the resulting binary.

All it finds at the moment is a false positive in the IDE build and two JMPs in the SD build MMC code, but I want to apply your optimisation there before taking those.

Edited to add: However, given it would be near trivial to add things like 'CLC:ROR A'->'LSR A' to peephole.py, perhaps that's the way to go. Do you want to have a play with this? I can attach a zip file with some recent binary builds if that would make things easier for you.
Last edited by SteveF on Sat Feb 27, 2016 10:13 pm, edited 1 time in total.

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 10:11 pm

dp11 wrote:The other mmc change should be perfectly safe with respect to timing
Cool, I've gone and committed that. I've also made the two JMP->BRA changes found by peephole.py
dp11 wrote:

Code: Select all

.nmi_lda_imm_rom_bank
       LDA #&00		;; replaced with actual ROM bank
       STA &F4
       STA &FE30
Stz can be used and the LDA removed
I don't think it can; I made this exact mistake earlier on. That LDA #&00 is patched up at run time to contain the actual ROM bank; see the code at LBC4B.

I've committed the other changes, thanks!

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 10:18 pm

FWIW, here are the latest numbers:

Code: Select all

         IDE2   IDE   ORIG   SD
master   759    759   707     49 bytes free
scratch2 954    954   896    234 bytes free
         ---    ---   ---    ---
saving   195    195   189    185 bytes
vs       166    166   158    143 bytes (yesterday)
Not too shabby!

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sat Feb 27, 2016 10:24 pm

Guys,

I continue to be amazed that you keep on finding bytes! =D> =D> =D>

I'll do a bit more testing tomorrow to make sure things are still functional!

Dave

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sat Feb 27, 2016 10:30 pm

hoglet wrote:I'll do a bit more testing tomorrow to make sure things are still functional!
Cheers Dave, that would be good. I was planning to do a code review of the changes on the scratch2 branch as a whole at some point, but if you're willing to test anyway without waiting for that that's great. (The code review is perhaps less essential than it was, since most of these have been examined by both dp11 and myself, but it would still be a nice thing to do, I think.)

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sat Feb 27, 2016 10:31 pm

Please do test Dave. I think having both of us looking at the changes is really good, all my stupid changes get rejected early on :D

Maybe a filing system test suite is needed.

I think the changes so far are low hanging fruit. I think there is more possible with great understanding of the code and the better labelling will certainly help me.

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 9:40 am

MMCUserport.asm

I'm in the red zone. :)

Code: Select all

.WaitForShiftDone
{
    LDA #4            ;; Bit 2 of IFR is the Shift Reg Interrupt flag
    CPX #1            ;; test if the last byte
    BEQ lastByte      ;; so we can return to mode zero before reading it
.notLastByte
    BIT ifr%          ;; wait for the SR interrupt flag to be set
    BEQ notLastByte
    LDA sr%           ;; read the data byte, and clear the SR interrupt flag
    RTS
.lastByte
    BIT ifr%          ;; wait for the SR interrupt flag to be set
    BEQ lastByte
    JSR ShiftRegMode0 ;; returning to mode 0 here avoids an addional byte read
    LDA sr%           ;; read the data byte, and clear the SR interrupt flag
    RTS
}

.WaitForShiftDoneNotLast
{
    LDA #4            ;; Bit 2 of IFR is the Shift Reg Interrupt flag
.notLastByte
    BIT ifr%          ;; wait for the SR interrupt flag to be set
    BEQ notLastByte
    LDA sr%           ;; read the data byte, and clear the SR interrupt flag
    RTS
}
can become this I think, no change in timing just 8 bytes saving.

Code: Select all

.WaitForShiftDone
    CPX #1            ;; test if the last byte
    BEQ lastByte      ;; so we can return to mode zero before reading it

.WaitForShiftDoneNotLast  ;; move to here to reuse the code
    
.notLastByte
    LDA #4            ;; Bit 2 of IFR is the Shift Reg Interrupt flag
.notlastBytewait
    BIT ifr%          ;; wait for the SR interrupt flag to be set
    BEQ notLastBytewait
    LDA sr%           ;; read the data byte, and clear the SR interrupt flag
    RTS

.lastByte
    LDA #4            ;; Bit 2 of IFR is the Shift Reg Interrupt flag
.lastBytewait
    BIT ifr%          ;; wait for the SR interrupt flag to be set
    BEQ lastBytewait
    JSR ShiftRegMode0 ;; returning to mode 0 here avoids an addional byte read
    LDA sr%           ;; read the data byte, and clear the SR interrupt flag
    RTS

Dave , if I understand things correctly below the INY isn't needed and though affects the timing , it doesn't matter as in this case it is much quicker anyway as the second STA (xx),y doesn't exist and as we have two card reads we can't exceed the tube transfer speed. ( A lot of work for one byte and too risky ?)

Code: Select all

.MMC_ReadToTube
    JSR WaitForShiftDoneNotLast
    STA TUBE_R3_DATA
    JSR WaitForShiftDone   ;; Dummy read
    INY
    DEX
    BNE MMC_ReadToTube
    RTS

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sun Feb 28, 2016 10:16 am

dp11 wrote:MMCUserport.asm

I'm in the red zone. :)
Indeed.... :shock:

The WaitForShiftDone change looks good to me, and as you say doesn't change any of the timing. I'll pull that one back into MMFS, as the Sideway Ram builds there are now very tight on space.
dp11 wrote: Dave , if I understand things correctly below the INY isn't needed and though affects the timing , it doesn't matter as in this case it is much quicker anyway as the second STA (xx),y doesn't exist and as we have two card reads we can't exceed the tube transfer speed. ( A lot of work for one byte and too risky ?)

Code: Select all

.MMC_ReadToTube
    JSR WaitForShiftDoneNotLast
    STA TUBE_R3_DATA
    JSR WaitForShiftDone   ;; Dummy read
    INY
    DEX
    BNE MMC_ReadToTube
    RTS
Actually, it's not there for timing.

It was there because in MMFS the calling code expects Y to contain the number of bytes read:
https://github.com/hoglet67/MMFS/commit ... c017a06f9b

ADFS actually does this differently, so I don't think it relies on Y.

Code: Select all

IF PATCH_SD
.L8B9B PHX
       JSR MMC_StartRead
       PLX
       PHX
       JSR MMC_ReadX
       PLA
       EOR #&FF         ;; Calculate 256 - bytecount
       TAY
       INY
       JSR MMC_Clocks	;; ignore rest of sector
       JSR MMC_Clocks	;; twice, as sectors are stretched to 512 bytes
       JSR MMC_16Clocks	;; ignore CRC
So you could take it out I think.

Dave

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 1:02 pm

If you are happy, another 8 bytes form the red zone for TurboMMC.

Code: Select all

    
;; *** Write 512 byte sector from datptr or tube, skipping alternative bytes ***
.MMC_Write256
IF _TURBOMMC
    JSR ShiftRegMode6
ENDIF
    LDY #0        
    BIT &CD
    BVS MMC_WriteFromTube
.MMC_WriteFromMemory
    LDA (datptr%),Y
IF _TURBOMMC
    STA sr%
    LDA #4
{
.wait
    BIT ifr%
    BEQ wait
}
    LDA #0                 ;; dummy write
    STA sr%
    LDA #4
{
.wait
    BIT ifr%
    BEQ wait
}
ELSE
    JSR UP_WriteByte
    LDA #0                 ;; dummy write
    JSR UP_WriteByte
ENDIF
    INY
    BNE MMC_WriteFromMemory
IF _TURBOMMC
    BEQ ShiftRegMode6Exit
ELSE
    RTS
ENDIF
in here there is

Code: Select all

    LDA #0                 ;; dummy write
    STA sr%
    LDA #4
    


which could be come :

Code: Select all

  
    STZ sr%				 ;; dummy write
This same transform can be also done in .MMC_WriteFromTube

I may be wrong here, but I think the write loop is is faster than the shift register in TurboMMC mode. Also the V flag isn't corrupted in the loop. So the test for getting the data from memory or the tube could be in the loop and the duplicate copy of code removed. In the non TuboMMC case the penalty is minimal compared to the loop time.

If you don't want to think about the above thats fine I understand .

Code: Select all

;; Write byte (User Port)
;; Ignore byte in
.UP_WriteByte
{
IF _TURBOMMC
    PHA
    JSR ShiftRegMode6
    PLA
    STA sr%
    LDA #4
.wait
    BIT ifr%
    BEQ wait
    JMP ShiftRegMode6Exit
ELSE
    ASL A
    FOR N, 0, 7
        ROL A
        AND #msmask
        STA iorb%
        ORA #2
        STA iorb%
    NEXT
ENDIF
    RTS
}
in the above I think really the RTS should be before the ENDIF

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sun Feb 28, 2016 3:26 pm

hoglet wrote:
dp11 wrote:MMCUserport.asm

I'm in the red zone. :)
Indeed.... :shock:

The WaitForShiftDone change looks good to me, and as you say doesn't change any of the timing. I'll pull that one back into MMFS, as the Sideway Ram builds there are now very tight on space.
dp11 wrote: Dave , if I understand things correctly below the INY isn't needed and though affects the timing , it doesn't matter as in this case it is much quicker anyway as the second STA (xx),y doesn't exist and as we have two card reads we can't exceed the tube transfer speed. ( A lot of work for one byte and too risky ?)

Code: Select all

.MMC_ReadToTube
    JSR WaitForShiftDoneNotLast
    STA TUBE_R3_DATA
    JSR WaitForShiftDone   ;; Dummy read
    INY
    DEX
    BNE MMC_ReadToTube
    RTS
Actually, it's not there for timing.

It was there because in MMFS the calling code expects Y to contain the number of bytes read:
https://github.com/hoglet67/MMFS/commit ... c017a06f9b

ADFS actually does this differently, so I don't think it relies on Y.

Code: Select all

IF PATCH_SD
.L8B9B PHX
       JSR MMC_StartRead
       PLX
       PHX
       JSR MMC_ReadX
       PLA
       EOR #&FF         ;; Calculate 256 - bytecount
       TAY
       INY
       JSR MMC_Clocks	;; ignore rest of sector
       JSR MMC_Clocks	;; twice, as sectors are stretched to 512 bytes
       JSR MMC_16Clocks	;; ignore CRC
So you could take it out I think.
Cheers guys, I've committed these changes to my scratch2 branch. I'll wait for Dave to take a look at the other proposed change before I commit that.

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sun Feb 28, 2016 4:02 pm

SteveF wrote: Cheers guys, I've committed these changes to my scratch2 branch. I'll wait for Dave to take a look at the other proposed change before I commit that.
The STZ changes and moving the RTS inside the ENDIF both seem fine.

Dave

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sun Feb 28, 2016 4:13 pm

hoglet wrote:The STZ changes and moving the RTS inside the ENDIF both seem fine.
Cheers, I've committed these. What I haven't committed is this:
dp11 wrote:I may be wrong here, but I think the write loop is is faster than the shift register in TurboMMC mode. Also the V flag isn't corrupted in the loop. So the test for getting the data from memory or the tube could be in the loop and the duplicate copy of code removed. In the non TuboMMC case the penalty is minimal compared to the loop time.
Let me know if you think this is OK (and a hint or two on the details of the change wouldn't go amiss either).

Steve

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 4:29 pm

This is what I'm thinking of subject to approval. I only want to do changes that Dave is happy with as I think the code base should be the same.

Code: Select all

       
;; *** Write 512 byte sector from datptr or tube, skipping alternative bytes ***
.MMC_Write256
IF _TURBOMMC
    JSR ShiftRegMode6
ENDIF
    LDY #0 
.MMC_WriteFromMemory
    BIT &CD
    BVS MMC_WriteFromTube
    LDA (datptr%),Y
.MMC_WriteFROMA
IF _TURBOMMC
    STA sr%
    LDA #4
{
.wait
    BIT ifr%
    BEQ wait
}
    STZ sr%		   ;; dummy write
{
.wait
    BIT ifr%
    BEQ wait
}
ELSE
    JSR UP_WriteByte
    LDA #0                 ;; dummy write
    JSR UP_WriteByte
ENDIF
    INY
    BNE MMC_WriteFromMemory
IF _TURBOMMC
    BEQ ShiftRegMode6Exit
ELSE
    RTS
ENDIF

.MMC_WriteFromTube
    LDA TUBE_R3_DATA
    BRA MMC_WriteFROMA
If non Turbo mode performance is important. Then an optimised Write 0 would give a significant improvement at the expense of a little extra space. It might be even possible to use .UP_ReadBits4 if it doesn't matter that the SR is read here.

Steve, I think the second LDA #4 can also go as the result of the BIT instruction is 4 ( commit dp11 optimisation (post Sun Feb 28, 2016 1:02 pm))

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sun Feb 28, 2016 5:02 pm

dp11 wrote: If non Turbo mode performance is important. Then an optimised Write 0 would give a significant improvement at the expense of a little extra space. It might be even possible to use .UP_ReadBits4 if it doesn't matter that the SR is read here.
Non-turbo mode performance is pretty important, as turbo mode needs different hardware that few of us have.

My feeling is probably not to do this change, until we really need that space.

Maybe leave a comment in the code indicating a saving could be made, at the expense of performance. You could also add a link to Dominic's post describing the change.

Dave

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 5:24 pm

I fully understand. I think a special case of a write Zero for the second byte would improve sector performance by about 20%.
Something like the the following could be done I think if reading the SR is safe at the end

Code: Select all

.UP_WriteByteZero
	PHX 				;; may not be need 
	LDX #0
	LDA #2
	STX iorb%           ;;0
    	STA iorb%
    	JSR fall into UP_ReadBits7  ;; Can fall into  UP_ReadBits7 if x doesn't have to be preserved
    	PLX

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 7:25 pm

back to adfs for a few more bytes

Moving code about a bit

Code: Select all

;;*** changed       BCS IOWrite

.IORead
       LDA &FC40
       STA (&80),Y
       BRA TransferByte
.TransTube
       BCC TubeRead
.TubeWrite
       LDA &FEE5        ;; Get byte from Tube
;;****removed       STA &FC40        ;; Write byte to SCSI data port
;;*** removed       BRA TransferByte
;; *** new optimised 
       BRA IOWrite_STA&FC40
.TubeRead
       LDA &FC40        ;; Get byte from SCSI data port
       STA &FEE5        ;; Write to Tube
       BRA TransferByte
.CommandDone
       JSR GetResult    ;; Get IDE result
.CommandExit
       PHA              ;; Release Tube
       JSR L803A
       PLA
       LDX zp_control_block_ptr          ;; Restore registers, set EQ flag
       LDY zp_control_block_ptr+1
       AND #&7F
       RTS
;;*** moved IOWrite so BRA is nolonger needed 
.IOWrite
       LDA (&80),Y
.IOWrite_STA&FC40       
       STA &FC40
 ;;** remove      BRA TransferByte

.TransferByte
Can .CommandDone be placed after .CommandRestore ?

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sun Feb 28, 2016 7:52 pm

dp11 wrote:back to adfs for a few more bytes

Moving code about a bit

Code: Select all

;;*** changed       BCS IOWrite

.IORead
       LDA &FC40
       STA (&80),Y
       BRA TransferByte
.TransTube
       BCC TubeRead
.TubeWrite
       LDA &FEE5        ;; Get byte from Tube
;;****removed       STA &FC40        ;; Write byte to SCSI data port
;;*** removed       BRA TransferByte
;; *** new optimised 
       BRA IOWrite_STA&FC40
.TubeRead
       LDA &FC40        ;; Get byte from SCSI data port
       STA &FEE5        ;; Write to Tube
       BRA TransferByte
.CommandDone
       JSR GetResult    ;; Get IDE result
.CommandExit
       PHA              ;; Release Tube
       JSR L803A
       PLA
       LDX zp_control_block_ptr          ;; Restore registers, set EQ flag
       LDY zp_control_block_ptr+1
       AND #&7F
       RTS
;;*** moved IOWrite so BRA is nolonger needed 
.IOWrite
       LDA (&80),Y
.IOWrite_STA&FC40       
       STA &FC40
 ;;** remove      BRA TransferByte

.TransferByte
I've committed this but I'm a bit worried it will perform worse and it will matter - previously .TubeWrite used to do STA &FC40:BRA TransferByte, it now does BRA IOWrite_sta_fc40->STA &FC40:BRA TransferByte, so there's an extra BRA in this code path. Could this mean we don't keep up with a parasite which is sending data very rapidly? Let me know if we think it's too risky and I will revert it.
dp11 wrote:Can .CommandDone be placed after .CommandRestore ?
Unfortunately when I tried this it gave a branch out of range error (IIRC, on BRA CommandExit); I tried a little bit of reshuffling but couldn't make it any better.

User avatar
hoglet
Posts: 8734
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMC hard drive emulation?

Post by hoglet » Sun Feb 28, 2016 7:56 pm

SteveF wrote: I've committed this but I'm a bit worried it will perform worse and it will matter - previously .TubeWrite used to do STA &FC40:BRA TransferByte, it now does BRA IOWrite_sta_fc40->STA &FC40:BRA TransferByte, so there's an extra BRA in this code path. Could this mean we don't keep up with a parasite which is sending data very rapidly? Let me know if we think it's too risky and I will revert it.
All parasites use flow control for sending/receiving data, so the host can actually go a slow as it likes.

Dave

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 8:17 pm

Should be quicker

I think you have missed that the last BRA in .IOWrite_sta_fc40 can now be removed.

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sun Feb 28, 2016 8:35 pm

dp11 wrote:Should be quicker

I think you have missed that the last BRA in .IOWrite_sta_fc40 can now be removed.
D'oh! Fixed in the latest commit.

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 9:10 pm

Steve, I think the second LDA #4 can also go as the result of the BIT instruction is 4 ( commit dp11 optimisation (post Sun Feb 28, 2016 1:02 pm))

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 9:51 pm

mmc.asm

Code: Select all

.MMC_INIT
{
     LDA #0
     STA mmcstate%
STZ can be used instead

Code: Select all

.il0
}
     ;; LDA #&01 - A is already 1
     STA cardsort%
     LDA #&48
     JSR MMC_SetCommand
     LDA #&01
     STA cmdseq%+4
     LDA #&AA
     STA cmdseq%+5
     LDA #&87
     STA cmdseq%+6
     JSR MMC_DoCommand
     CMP #1
     BEQ isdhc
CMP #1 can be replaced with DEC A

Code: Select all

.ifail
     ;; Try again?
     DEC attempts%
     BEQ ifaildone
     BRA iloop
     
can become :

Code: Select all

.ifail
     ;; Try again?
     DEC attempts%
     BNE iloop
     ; fall into ifaildone
     

SteveF
Posts: 516
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: MMC hard drive emulation?

Post by SteveF » Sun Feb 28, 2016 10:56 pm

Cheers, I've committed the changes from the last two posts.

FWIW, here are the latest numbers:

Code: Select all

         IDE2   IDE   ORIG   SD
master   759    759   707     49 bytes free
scratch2 959    959   896    249 bytes free
         ---    ---   ---    ---
saving   200    200   189    200 bytes
vs       195    195   189    185 bytes (yesterday)
Much better than I expected, given you've found some savings which are Turbo MMC only and thus not actually active in any of these builds.

Cheers.

Steve

dp11
Posts: 962
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: MMC hard drive emulation?

Post by dp11 » Sun Feb 28, 2016 11:08 pm

My target was to get to a page of free space. But I have been doing the same sort of task as side line for a work project on a pic processor.

Post Reply