sbasm3
sbasm3 copied to clipboard
sbprojects
fix MOS format for testing using ugly hack. Bumped to 3.03.06mosfix1
Together with a friend we developed something for KIM1 using sbasm because we had trouble to create the MOS-file. When uploading MOS format files to KIM1 it was not responding after transfer complete. After changing the last line of the generated MOS-file manually the transfer was successful. Then I changed sbasm to generate a MOS-file which is accepted from KIM1. It maybe not the best way to implement this but this ugly hack works.
@BeeRed Thanks for your patch. I'm happy it works for you. I will have to clean up the code a bit though. Your patch ignores the code/eeprom targets for instance.
I have a few questions: The first question is about the checksum of the last line. The second link you mention states that the last line doesn't have a checksum, but instead repeats the record counter. By pure coincidence these two values can be the same (for short programs). My question is, does the KIM really require a checksum, or is it indeed a repeat of the record counter?
Is the XOFF character really necessary? It is not mentioned in the second link.
You haven't mentioned the 6 NULL bytes after each record. I assume they are not required? Perhaps they were there to slow down the communication to allow the teletype to keep up with the communication.
@BeeRed I have officially implemented a fix for the MOS end of file record for the KIM-1. The version of the latest release is now V3.03.07. You can read my comment on the matter on https://www.sbprojects.net/sbasm/directives.php?directive=tf at the end of the page.
KIM is processing the last record beginning with ";00" as all other records. (but it will stop reading records) It will compute the checksum for next 2 bytes which is the number of records (normally the address) because of zero data it go to the end and compare the next 2 bytes which is the expected checksum. Depending on the result "ERR KIM" or "KIM" is sent to the terminal.
XOFF is not expected/checked The 6 NULL bytes are not expected/checked but if included it will not hurt because if a line is successfully processed ANY char is dropped/ignored until next ";" is seen.
The send to paper tape function will send out $0a, $0, $0, $0, $0, $0, $0 after checksum think you are right this is to give old mechanical teletype some more time ant the end of the line.