Here's a PDF of the awesome reference card Glitch mentioned forever ago in this thread: http://www.classiccmp.org/cini/pdf/Rockwell/R6500%20Microprocessor%20Program...
From an incredible resource: http://www.classiccmp.org/cini/systems.htm
See ya! -Todd On Tue, Jan 17, 2017 at 5:58 PM Dean Notarnicola via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
- *Patching LOGO to use your code. There are two parts to this. * -
*Hooking your code into to LOGO so you can use your "functions". Here is where you learn enough about LOGO to make patches to the LOGO system while it is in memory to augment LOGO to use your new code. This is some detective work with disassemblers and guesses on where the code is you need to patch, setting break points in a monitor program, stepping through the logo code, deciding where a good surgical place is to modify the flow to call your code and allow LOGO to use the results. * -
*Modifying the original executable file (of LOGO) while maintaining its ability to be reloaded from disk. There's got to be someone here familiar with specifics of the Apple II executable file format. Some systems have check sums or other methods to insure that a file to be loaded is "valid". There may be copy protection stuff that gets in the way. I might suggest enlisting the help of someone to work on this part independently- to prove they can make a change to the file and still have it work. Then when you have your new code ready to integrate, they will be ready to add it to the LOGO executable and patch it in. What this might look like in the end might be that you would run a program to load your code into some available place in memory, then load a modified version of LOGO that assumes your code is in place. Or, if you get really good, the modified version of LOGO may have your code and the LOGO code all in one file*
This is getting to be what may be an insurmountable challenge. The Logo in question is Lego Logo, and the disk is in a non-standard format, as I discovered when I tried to convert it with ciderpress (I wanted to use a very nice disassembler I found for the IIgs). The disk is self booting, so even if I can get the code into a disassembler, writing changes back to a usable format is going to be a major challenge. So far I have not found a way to do it.
On Tue, Jan 17, 2017 at 1:43 PM, Douglas Crawford via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On 1/17/2017 1:41 AM, Evan Koblentz via vcf-midatlantic wrote:
After posting my assembly-for-newbs question, it occurred to me that perhaps I should be asking this instead: with no experience other than LOGO and then BASIC, which (period 1980s) language should I learn next? Was it normal to go from BASIC directly to assembly (is BASIC enough preparation), or were people better off getting some in-between experience with a language such as Pascal or something else?
Keep in mind that my natural aptitude is liberal arts, not math. :)
Evan, knowing what you are trying to accomplish, it is completely reasonable to move on to 6502 assembly language for the Apple II as you were planning in order to perhaps lead to augmenting LOGO. As testified here, many went from BASIC to assembly language directly.
I'll take a shot at trying to define the distinct challenges you face:
- Learning the 6502 machine and instruction set. Perhaps helpful here would be publications that were written to take folks from what they know about BASIC and introduce them to 6502 assembly would be specifically helpful for you. In Commodore land hobbyists had Jim Butterfield to look to. I don't know who was a similar author in Apple II land. Hopefully you can find some pubs written for Apple II users. Or the one you are working from now that prompted the original question is this sort of thing. - Selecting and using the available Apple II tools for assembly language programming Beginning with a machine language monitor like you were trying to do is a good place to start. With that, you can work on small exercises that illustrate assembly program principles. Awesome. Eventually you may move on to a more full featured assembler setup like what Jeff recommended at the workshop - Merlin Pro I recall, he said was a really good one. But that's only at the point where you want to write your program in a file and make use of more sophisticated features of the assembler. - Writing the assembly language routines that implement the new features and testing them apart from LOGO as best you can. You take what you learned in exercises and put it to doing the work you want LOGO to do. - Patching LOGO to use your code. There are two parts to this. - Hooking your code into to LOGO so you can use your "functions". Here is where you learn enough about LOGO to make patches to the LOGO system while it is in memory to augment LOGO to use your new code. This is some detective work with disassemblers and guesses on where the code is you need to patch, setting break points in a monitor program, stepping through the logo code, deciding where a good surgical place is to modify the flow to call your code and allow LOGO to use the results. - Modifying the original executable file (of LOGO) while maintaining its ability to be reloaded from disk. There's got to be someone here familiar with specifics of the Apple II executable file format. Some systems have check sums or other methods to insure that a file to be loaded is "valid". There may be copy protection stuff that gets in the way. I might suggest enlisting the help of someone to work on this part independently- to prove they can make a change to the file and still have it work. Then when you have your new code ready to integrate, they will be ready to add it to the LOGO executable and patch it in. What this might look like in the end might be that you would run a program to load your code into some available place in memory, then load a modified version of LOGO that assumes your code is in place. Or, if you get really good, the modified version of LOGO may have your code and the LOGO code all in one file.
Hopefully is more helpful than telling you the way to put four elephants in a volkswagon is two in the front and two in the back. :)