bkw777 / dl2

DeskLink+ is a Tandy Portable Disk Drive emulator or "TPDD Server" implimented in C.
GNU General Public License v2.0
30 stars 6 forks source link

TEENY.200 FC Error #3

Closed hackerb9 closed 1 year ago

hackerb9 commented 2 years ago

Ever since commit 2b07aa6, the file clients/teeny/TEENY.200 does not work on my Tandy 200. I get a function call error in line 2 when I run it (using RUN "COM:98N1ENN" and dl -b TEENY.200). However, the previous version of TEENY.200 from commit 1ed2c72 works fine.


This is probably not the issue, but it looks like the problematic commit changed the end of line character from the Tandy style (CRLF) to Macintosh style (CR). You may want to ensure that git knows that those files should have CRLF terminators by creating a file called .gitattributes in the project's root and adding something like this:

*.DO    eol=crlf
*.do    eol=crlf
*.100   eol=crlf
*.200   eol=crlf
*.102   eol=crlf
*.NEC   eol=crlf
*.nec   eol=crlf
*.M10   eol=crlf
*.m10   eol=crlf
*.K85   eol=crlf
*.k85   eol=crlf
bkw777 commented 2 years ago

I changed the line-endings on purpose because BASIC only actually needs the CR.

Maybe I should put them back because possibly it doesn't save anything except the serial communication time of one byte per line. IE, may not save any bytes of storage on the portable, even before tokenization, and definitely after tokenization, at least when being fed directly into BASIC. It might possibly save bytes if the file is copied to the unit as a .DO file using tpdd instead of feeding into BASIC via bootstrap. I haven't looked to see yet. If it doesn't save any space on the portable then it might as well be more convenient to use in ordinary editors when not on the portable. But really these loaders are so crunched anyway that they are practically illegible/uneditable anyway, with crunched code and the data statements that can't tolerate a byte of deviation without breaking the unpacker, so what's the difference. You already have to just treat them like a binary anyway, so what do CR's matter in that case. That was my thinking anyway.

I tested all machines including 200, but maybe I missed the specific combo of TEENY on the 200, so maybe 200 doesn't like the CR's the way the other do, or maybe there is some other error in that particular file. I did some manual refactoring of most of the loaders to compact the code more than it already was, improve some prompts and default behavior, and to use different hex encoding scheme in some cases. All that does open up a lot of chances to break stuff. Which is why I did test but maybe missed a test.

I'll check it out.

ghost commented 1 year ago

I am affected by the same error, making Teeny impossible to load on Model 200 indeed

?FC Error in 2

You can work around that by downloading the TEENY.200 from a previous release and overwrite the current one. The TEENY.200 that is 2513 bytes works.

hackerb9 commented 1 year ago

@bkw777: Would you be willing to consider reverting the changes to TEENY.200? At least in the main tree?

Of course, it's your project so you make the decisions, but I actually preferred the original formatting and found it more understandable than the new, "binary" form.

Alternately, if this file is to be treated like a binary, could there be a "source" version that the "binary" is automatically generated from? Thanks!

bkw777 commented 1 year ago

Reverted TEENY.200 until I can look at it again. I'm away from home for about another day. Leaving open until someone verifies it works or until I can.

hackerb9 commented 1 year ago

Hurray! It works again. Thank you.