Tasks done
- Downloaded djvu OCR text from archive.org. The original article is okay but the listing is heavily mangled.
- Downloaded djvu listing scans.
- Cropped off adverts
- Cut into single columns
- OCR with Google Docs.
Results are worse than djvu, because Google looks for non-ASCII chars like bullets, Unicode symbols, etc. - Edited OCR into a C file (very tedious)
- Edited C file until it would compile
- Ran compiled code. It crashes horribly, with segmentation faults and a core dump
There's about a weekend work there.
I don't have the time to debug the code right now, but I have uploaded it for other people who might be interested in doing so.
The code itself is very old, in K&R instead of ANSI style. I took the liberty of updating it to ANSI style and standard include files.
The code uses short variable names like 'o' and 'l' which people used to do when disk space was limited. The OCR confused them with '0' and '1', requiring many corrections. Modern style is to use longer and self-explanatory names, but I shan't change variable names for now.
The code uses pointers a lot, which is not as readable as arrays. Rogue pointers are apt to crash programs, which is likely the cause of the current crashing.
The code use alloc(), which my compiler didn't recognise so I replaced it with malloc(). I have never written programs that required malloc, so I don't know if that is a big mistake or not.
2024-02-14
Alan Cox gets the code to a respectable state where it can do something before crashing.
I notice that it does note assemble the file you tell it to.
You have to give it the filename without extension.
It will then look for filename.s and create filename.hex
It assembles test_nop.s with the command
./A32000 test_nop
but
./A32000 test
produces
>>---> Error u at icu
>>---> Error u at zvers
>>---> Error u at realst
>>---> Error u at memszx
>>---> Error u at mem1
Segmentation fault (core dumped)
To do:
- Fix crashing
- Create a source code test file that will exercise all opcodes and features
- Verify correct operation by comparing with output of a trusted 32000 assembler
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.