Hi Per
Nice first stab at the problem. Taking some of your questions:
"Fewer, well-chosen but random, samples from the file?"
I was thinking about this last night.
I don't think that randomising which sub-set of pixels to test would enhance the accuracy over pre-selecting a fixed sub-set of pixels. It would also be difficult to determine if randomising would reduce the time (on average) to find a positive test, though any number-theorists out there may know different
The question is then how to define a fixed-set of pixels to test. Some - conflicting - criteria ('positive test' here means we are most sure its MODE 4):
a) to test as much of the typically used screen-area as possible (to reduce possibility of missing a positive test.)
b) to start from the most likely points to find a positive match (to reduce the average time.)
c) to test as few pixels as possible overall (obviously, to reduce the maximum time to run.)
I'm wondering if a spiral pattern, starting from the centre and stretching outward might meet the above criteria. This assumes a random-access approach to reading the dump-file, which for speed of access on older media such as microdrives would point to using LBYTES and PEEK in place of channel/character-access.
If memory is not short, then allocating the 32k for the LBYTES of the dump-file and pre-calculating the test-pixel co-ords * to test and storing in an array (or loaded from a pre-saved file) shouldn't be problematic.
* Once the test-pixel co-ords are calculated for a given shape-vector, you'd want to convert these to equivalent byte-offsets within the 32k dump-file one-time and save for later use.
"A way of eliminating mode 4 files earlier in the process?"
This should be the aim anyway, as we are testing to see if _any_ FLASH-bit is set (from our chosen test-set of pixels) - if it is, then we meet our ninety-something % criteria that this is really a GREEN, MODE 4 bit, and return accordingly.
BTW - in your code extract below, you were testing for 170 - i.e. _all_ 4x GREEN bits set in a contiguous row - rather than testing for _any_ of 4x FLASH bits being set, which would need bit-wise AND'ing against 85 (= %01010101).
Partial code idea:
----------------------
REMark *** the below approach - using X,Y co-ords would ideally be pre-converted to byte-offsets one-time, but this example sticks with co-ords
DIM testPointX%(numberOfTestPoints%-1), testPointY%(numberOfTestPoints%-1)
populateTestPointArray testPointX%,testPointY%
:
_scr_llen%=128
flashMask%=21760 : REMark *** 21760 = %01010101 00000000 -or- 85 * 256
POSSIBLE%=1 : UNLIKELY%=0
:
screenBuffer=ALCHP(32*1024) : IF screenBuffer < 0 THEN STOP : REMark *** Ooops...
:
PRINT GetScrMode("MyTestFile_scr")
:
RECHP screenBuffer
:
DEFine FuNction GetScrMode(fnm$)
LBYTES fnm$, screenBuffer
couldBeMode8%=POSSIBLE%
:
FOR testPoint%=0 TO (numberOfTestPoints% - 1)
testX% = testPointX%(testPoint%) : testY%=testPointY%(testPoint%)
pixelWordOffset% = testY% * _scr_llen% + ( (testX% DIV 4) * 2 ) : REMark *** (testX% DIV 4): gives byte offset, * 2: shifts to word-alignment (I think...)
pixelWord%=PEEK_W( screenBuffer + pixelWordOffset% )
IF pixelWord% && flashMask% THEN couldBeMode8%=UNLIKELY% : EXIT testPoint%
END FOR testPoint%
:
RETurn (couldBeMode8% * 4) + 4 : REMark *** RETurns either 4 or 8
:
END DEFine GetScrMode
: