The hang is a bit odd!
Is fle% definitely <=1024 ?
Just realized that the image I was using in BeebEm was way older than I thought and contained corrupt menu files...which were indeed over 1024. Just tried it on the real thing and it has cut the ANSI menu loading time down from 9.7 seconds to 4 second! Unfortunately whilst working great it is causing no room errors in Mode 7. I would need to change more of the program to get it to work properly in Mode 135 which is always an option.A great idea, they are already all in use, thanks for the info on CLEAR, I wasn't sure so wanted to cover all bases!Another idea is to use the integer variables if they aren't being used already - A% to Z% - which are available in BBC BASIC as standard, so can be used without taking up any more memory, and because of that, they don't get overwritten if data overruns corrupt the rest of the variable space.
Yes, to get around this I was using EXT to store the length of the file in fle% and then using this with max=fle% DIV 4, was this why it didn't speed things up?Yes, if the data you're sending is different length
Code:
3820DEFPROCVA(mn$):LOCALq:q=OPENINmn$:fle%=EXT#q:IF q=0 THEN TERM%=TRUE:CLOSE#q:ENDPROC 3830CLOSE#q 3850max%=fle% DIV4 3860DIM ctrl% 31:X%=ctrl%:Y%=X%DIV256 3870DIM data% max%-1 3890in%=OPENIN(mn$) 3900FOR pass%=1TO4 3910PROCgbpb(4,in%,data%,max%,0) 3920FOR n%=0 TO max%-1:PROCserial_send(data%?n%):NEXT n% 3930NEXT pass% 3940CLOSE#in% 3960ENDPROC 3980DEFPROCgbpb(A%,chn%,addr%,num%,ptr%) 3990?X%=chn%:X%!1=addr%:X%!5=num%:X%!9=ptr%:CALL &FFD1:ENDPROC 4010DEFPROCserial_send(byte%) 4020VDUbyte% 4030ENDPROC Statistics: Posted by vela025 — Thu Feb 22, 2024 8:49 am