mbuhidar / retro_typein_tools Goto Github PK

Currently, the checksums generated are displayed only in the terminal. Would be beneficial to have a text file for the output also to make it easier to compare side to side with magazine image. Perhaps leading to automated comparison in the future.

pytest currently runs properly only from the tests directory. The issue is with the path to the 'test_infile.txt' file used for testing the read_file() function. Find a way to add a generalized path for 'test_infile.txt' or find a better way to test the read_file() function.

Starting to see opportunities to reduce duplicate code themes via object oriented approach for some elements.

The ahoy_lines_list() function checks for loose braces in each line. Currently is simply prints the error from within the function. Need to gracefully return the error for processing in main() instead.

Disassemble in preparation for reverse engineering the encryption logic for this version.

Since this info guides which source a user will select based on the dates listed, this change should prompt a new release to PyPi.

Missing test coverage in debug_tokenize_test.py for function check_overwrite().

In the add_ahoy_checksum branch, the function ahoy_checksum() is functionally working but is yielding incorrect checksum values. The algorithm was reverse engineered from disassembled code from the original C64 repellent checksum program. See assembly code walkthrough at the following location:

https://github.com/mbuhidar/C64_Bug_Repellent/blob/master/disassemblers/white-flame_disassembler_good/walkthru_10_quotes_H.asm

Seems to be an 'off by one' type of issue, but I haven't been able to isolate the issue.

Add exception handling to the split_line_num function for cases where lines do not begin with a line number.

The regex used to split the lines on special characters enclosed in braces is including loose open braces.

Code lines not generating the correct checksum when more than one set of numerically repeated codes in brackets is present.

Issue to specifically change the way special characters preceded by shift of commodore keys are represented in the typed-in listings. It also makes common the way unique characters like English Pound and Pi are represented for consistency across all ahoy debug-tokenize options.

Simplify interface by eliminating support for petcat-ready file output and removing internal conversion of type-in codes to petcat codes. Functionality is no longer required since the debug_tokenize tool converts directly to C64 executable format.

There are tests for the functions, but no tests for overall application function. Need this prior to refactor since some of the functions may change.

Release to PyPi as version 1.0 since interface changed since v 0.8 was released.

Source flag 'ahoy4' was added previously when it was thought that Ahoy entries starting with the May 1987 issue would need different special character handling than issues from Nov 1984-Apr 1987. The implementation for 'ahoy4' is a superset of functionality that will also cover the Nov 1984-Apr 1987 issues (planned ahoy3), so support for the two sets of issues will be combined into the 'ahoy3' source flag.

The function key characters in char_map.py are incorrectly mapped.

Currently, loose brace errors are detected in the ahoy_lines_list function. The way the error is handled is via return of None by the function making it inconsistent with the form returned when no error exists.

Add documentation to help and README to cover special character entry using shift and commodore keys on original hardware.

In November 1984, Ahoy introduced a new method of representing special type-in characters in their code listings moving from using braces to brackets to indicate how to type them in. For this issue, the means of handling special characters represented in this way need to be added. The November change also introduced a notation for duplicating special (and regular) characters multiple times, e.g. [5 "[LEFT]"] indicates entry of the cursor left key five times.

Issue #30 will outline other advancements that change the API formerly used for entering certain special characters.

For Ahoy November 1985 issue, the game Slither has a few unusual remark lines starting with a colon that are not in the program flow.
For lines that contain text corresponding to BASIC tokens, the checksum values produced by the app do not match those printed in the magazine. Examples below:

999 : * ML DATA *
1099 : * CHARACTER DATA *
3099 : * COORDINATE DATA *

November 1984 issue of Ahoy added support for entry of characters (special or regular) more than twice with the following notations:
[5 "[LEFT]"] - enter the special character for cursor left five times
[10 "."] - enter the regular period character 10 times

As a user, I want to be able to see the output checksums in a matrix format based on the current terminal width.

Step towards refactor to support library of classes.

Need additional checks for proper line ordering when there are 1 or 2 line in the program.

Plan would be to change the README doc to recommend 'basename.bas' as the preferred input format to provide for BASIC syntax highlighting in most editors. Output for executable would remain the same, but reference to output for VICE emulator conversion format would need to be 'basename_vice.bas' or similar to avoid overwrite of source file.

Bug Repellent had an initial version for the first two issues for the code (Issues 4 and 5). Need to add a CLI option to cover those two issues.

Add support for 3rd and final version of Ahoy's Bug Repellent. Need to add CLI options and doc. Will need to disassemble and reverse engineer the 6502 Assembly similar to the first two versions.

The November 1984 issue of Ahoy introduced a different way to represent characters entered with shift or commodore keys being held during entry. This issue will update the prior way these characters were represented in typed-in code for consistency. In addition, other characters like English Pound were formalized in a different way than defined in prior releases of debug_tokenize - these should be adjusted for consistency across all versions of Ahoy Bug Repellent. This will break the prior API and require revision to any prior listings entered with the former definition.

Issue 31 will address the other extension that Ahoy introduced related to handling multiple entries of the same character (special or not).

For use in reverse engineering to test input -> output relationships.

For Commodore 64 type-in programs, a common special character entry method was to precede certain letters with either the shift key or the Commodore key to access special control or graphics characters. Ahoy magazine indicated these entry methods in the program listings with an underscore on characters that should be entered while holding SHIFT and an overlined on characters that should be entered while holding the Commodore key. We need another method for entering these characters in a modern code editor.

List is here for reference: https://sta.c64.org/cbm64petkey.html

Action is to add another reference dictionary to the char_maps.py file to cover these cases.