forum.defence-force.org

Update: found the cause of the inconsistent byte grabbing. It was not the speed of the code that was the issue, it was that apparently that SEDORIC routine really does not like if you change the X register

Did as suggested: first just a byte grabber, nothing else. Works fine, consistent stream caught.
Then added delay as suggested by having an ldx dex bne loop. Was giving all kind of funny results even with a delay of ldx #$01 (so really no delay with the dex right after).
Added now safeguards to (to be sure) safeguard processor state, A, X and Y registers. And now it seems to work even with a delay ldx $ff.

So will now proceed with the actual parser. Which by the way I already found could never work also because I forgot to actually increase the X coordinate after plotting (duh.....) so every character would be plotted at exactly the same spot. Keep you posted. Will incorporate DBugs suggestion on auto modifying jump addresses.

xahmol wrote: ↑Wed Aug 17, 2022 11:08 am Update: found the cause of the inconsistent byte grabbing. It was not the speed of the code that was the issue, it was that apparently that SEDORIC routine really does not like if you change the X register

*kaboom*

Great progress: disk parser almost works!

It now works great on the OSE system disk: Routine now puts its output where the program wants it, can fit a lot more files by having three columns instead of two (gaining the space by skipping the extensions and file block lengths) and even if there are to many files, it just ignores the files that do not fit on the screen instead of screwing everything up by scrolling.

Not entirely there yet though as I found out that it does not correctly parse two other disks I tried purely by parsing the diskname not entirely correct. Which is almost certainly caused by me not implementing the logic to deal with the fact that colours are allowed in the disk name and that SEDORIC outputs escape codes for that. I see that my logic dealing with escape codes goes wrong in the charcounter. So should be easy to solve, but takes more time to analyse than I have today, so leave that for another day.
Also noticed that I work very close to completely full memory (had to do already some hack to deal with being just 54 bytes short), so have to extensively test if all the rest is still working and not having quirks by memory errors.

But excited I already got so far! The rest should be easy.

Yay! Seem to have solved also that final issue. Found that also the escape chars count in the character count (which of course does make sense, else a diskname with colours would take more room than one without). Also forgot to actually adjust string length in C for it, so it had no trailing zero to find, which of course creates some printing mess.

I have tested it now with many of my TAP2DSK images. which all parse correctly.

SEDORIC4 images as exected create an utter mess. but preventing let alone solving that mess is more than I can hope to do in the memory still left. So will leave it with a warning, do not try to use SEDORIC4 discs.
DiskBuilder images also create utter mess, so do not try that

Tried one non TAP2DSK SEDORIC3 image. Aigle d'Or, that one parsed correctly mostly but end of dir could not be detected. Now scan for an asterix in the **xx sectors free, but Aigle d'Or image had 1115 sectors free and starts not with an asterix. That is an issue, as I do not know yet how to distinguish that that 1115 is not a filename but end of dir without making the logic WAY more complex.

So certainly for now I will definately stick with documenting the limitation that only TAP2DSK created images are supported, anything else almost certainly will not work and breaks the program. Good enough for my own uses for sure.

New disk images:
DSK: HFE: Source code still at:
https://github.com/xahmol/OricScreenEditor

(see the https://github.com/xahmol/OricScreenEdi ... assembly.s file for the dirparser ML)

Video demo:


Recorded from a real Oric Atmos and Cumana Reborn, so yes, it works on real hardware as well At me at least.

Glad you managed to solve it

If there's one thing maybe, I find it disturbing that the selected menu item loses the highlight color when you show the menu list, would be nicer I think if the "File" background stayed white when the Save screen/Load screen/Save Project... options are displayed (@ 0:33)

Dbug wrote: ↑Thu Aug 18, 2022 7:01 am the selected menu item loses the highlight color when you show the menu list

Good one. Will look at it and see if that is an easy fix (which I think and hope) or not.

Dbug wrote: ↑Thu Aug 18, 2022 7:01 am the selected menu item loses the highlight color when you show the menu list

Solved. Will post the new image on release, but Github already updated.

EDIT: Hmm, to quickly, this gives another issue of the menu option staying highlighted if you move left/right from the pulldown to another menu option. So needs another fix
EDIT2: Also solved. Although code gets slightly longer with every fix