Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add note about BOOT SYS needing $4c to be the first byte of the boot sector #589

Open
dansanderson opened this issue Jan 20, 2024 · 1 comment
Labels
new New report, not classified yet

Comments

@dansanderson
Copy link
Collaborator

BOOT SYS is under-documented and under-tested. There appears to be a need for the first byte in the boot sector to be $4c for it to succeed.

This belongs in the upcoming KERNAL API documentation, but could be added (briefly) to the BOOT SYS BASIC reference for now.

@dansanderson dansanderson added the new New report, not classified yet label Jan 20, 2024
@lgblgblgb
Copy link

lgblgblgb commented Jan 20, 2024

I can confirm it works, at least I've tried with Xemu. However I was unaware that the first byte of the "HOME" sector must be $4C (JMP abs opcode), otherwise it returns with error what BASIC interprets as "BAD DISK ERROR", the same error message whatever the problem was (could not load the sector - real disk error -, or "only" missing $4C as the first byte). The ROM source (especially the comments) confirms this theory.

So I quickly used a hex editor to modify a D81's first sector, something like this (without using assembler, so the strange layout of the code ...):

00000000  4c 10 04 00 00 00 00 00  00 00 00 00 00 00 00 00  |L...............|
00000010  ee 20 d0 4c 10 04 00 00  00 00 00 00 00 00 00 00  |. .L............|

That is basically (the sector is loaded to $0400!):

0400  JMP 0410
[...]
0410  INC D020
0413  JMP 0410

The first JMP is needed to give the desired "$4C as the first byte" rule. Indeed, then BOOT SYS caused the border to flicker, so my code could run. Without $4C as the first byte, I get "BAD DISK ERROR" as I expected after learning about the "4C rule".

One interesting thing though, that the source and comments indicates something, that multiple "HOME sectors" are checked, one for "1581" one for "MS-DOS" compatibility, I can't see exactly why, or what's the purpose of this though. It would be interesting to know. I assume the "MS-DOS compatibility" means that the disk sides are handled reversed (?) it seems or something like that, but I still can't see why it's useful to have an MS-DOS formatted disk with 65xx code in the boot sector, sounds odd. That's why I am very much interested what was the reasoning of this "dual try" stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new New report, not classified yet
Projects
None yet
Development

No branches or pull requests

2 participants