Hesitant to post as very Work in progress, not yet complete and most certainly still very buggy:
See
https://github.com/xahmol/OricScreenEdi ... dirparse.s
And then specifically these parts:
_ORIC_DIRParse_start_core:
DIRParse_nextX:
DIRParse_Stormem:
_ORIC_DIRParse_end:
ORIC_DIRParse_process:
It is not complete yet as I thought already I still miss a phase (skip from the right column to the left), but I think the first thing to understand is why solely capturting the dir to memory (did so for testing purposes in a memory area I actually can not miss, but wanted to see if the raw input was received correctly). This is the DIRParse_Stormem function that is called first in ORIC_DIRParse_process.
In memory I see this dump:
- Schermafbeelding 2022-08-15 085609.png (10.09 KiB) Viewed 2649 times
Compared to this actual dir just in BASIC on screen:
- Schermafbeelding 2022-08-15 091030.png (11.56 KiB) Viewed 2649 times
First thing I encounter is that the coloured part of the disk name gives output with escape codes ($1B) instead of just attribute values that can be plot directly. So have to figure that one out, as I assume that the number of escape codes will differ from dir to dir, so might be different on reading other disks. Parked that one for later if I can get the rest working.
But more worrying is that somehow the output of the filenames seems to be inconsistently weird sometimes in the extensions.
See:
- on the first file OSEHS1.BIN the extension suddenly misses a dot, but more worryingly, there is a weird sequence of 0D 08 2E 06 20 40 4F behind the BIN that I really can not place and do not see further on. $0D is an ENTER, weird, as it should keep printing on the same line, see output in plain BASIC. $08 is a backspace, why? And why does it do that here, but with further files sometimes (not always) that $0D but not the rest?
- On the second file OSEHS2.BIN there is suddenly a dot within the .BIN extension instead of before (so B.IN instead of .BIN)
The code to print things to screen is also far from functional still. It also is not complete and WIP yet as I know I still miss a phase (skipping chars going from right column to left column again). But solving the bugs that must be there is rather pointless if I can not understand what is happening with those irregularities in the raw stream in the first place, as my parser logic only works if distances between two file names are always exactly the same or at least follow a standard predictable pattern.
That is why I for now gave up on this rote, and reverted to the simple way of not interfering with the DIR output, Which works great with the caveat of breaking on too many files.