Adapting Microchess 6502 assembly code to run on C8P

[lowrybt1]

As will become obvious in this post, I have not worked with assembly language for decades and then only briefly (in 1978) writing simple routines for a PDP-11/70.

I have the 6502 assembly code for the MicroChess program originally authored by Peter Jennings in 1976 and modified to use routines that call a 6551 ACIA to print the chess board via serial port as the game progress. It was posted online years ago and permission has been given for non-commercial use of it. I want to try to modify it so that it can be saved and run under OS65Dv3.3, relying on the serial output routines for generating the status of the chess board move by move. Thankfully, the code is extensively labeled with very few direct calls within the program -- the ones I see are basically to OS restart routines and ACIA status registers/parameters.

For someone who has not tried working with assembler in the OS65D environment, I have three starting questions:

1) Is there a useful tutorial or set of articles somewhere that could serve as a reference for how to proceed with writing, saving, debugging and running assembly language within OS65D?

2) Given the extensive use of labels for code segments and of named variables that refer to page zero, I'd like to try -- if it's possible -- to copy-paste or or otherwise load the current code modified only to reflect new starting locations in RAM for the program code and block data that are compatible with free program space in OS65Dv3.3. Are there capabilities within OS65D or WINOSI that would facilitate quick loading and debugging of existing code?

3) The code contains the hard addresses/locations for accessing ACIA 6551 registers and handling flow control. I'll need to change those addresses to work with the ACIA used by OSI (6850, right?) Is there a resource that might help with that crosswalk?

Many thanks - Tom

[bxdanny]

Tom,

Is it doing anything with the 6551 other than outputting a stream of ASCII characters to it, and accepting typed characters from it? I doubt that it would be. If not, then it is a simple matter of replacing calls to the character-output routine with calls to the analogous routine in 65D ($2443), and calls to the character-input routine with calls to 65D's input routine ($2336). Initialization of the ACIA can be ignored, since that was done when the OS booted.

If input is only accepted when it is the user's turn, at which time it waits to receive it and does nothing until it is received, then no changes are needed other than using the appropriate input and output calls as just mentioned, and that will allow the program to work with both serial and video systems. If it needs to accept typed characters at any time, doing other things when there is no waiting character, then you will need to directly address the ACIA, or call the keyboard-scanning routine yourself, to check if a key is ready. But even that is fairly simple to do. The keyscan routine in 65D 3.3, unlike the ROM routine used through version 3.1 (and in the 8" version of 3.2), does return with a zero in the accumulator if there is no key pressed, IIRC.

The Extended Monitor includes a Relocate command that can fix address references (JMPs and JSRs) when code is moved to a new location, but it only works on continuous blocks of code. When there are data blocks interspersed, it gets more complicated, but not by that much if there are only a few interruptions of the program code for data. You could use the Relocate function on the entire program, then the Move function on the data blocks to ensure that changes are not made within them. You would then need to inspect the beginning and end of each data block to check it and manually fix up small sections where the Relocator failed to resynchronize correctly right after a data block, usually only a few bytes long. Where does the original program reside? OS-65D 3.3 occupies $2300 to $3A7D, and you can basically use any other locations.

[lowrybt1]

Thanks Danny. The data block is at the very end of the code, which should help with the move. The code was written on a KIM-1 or AIM-65 with the program starting at $1000 and block data located between $1580 -$15FF.

I'll start reading up on the EM and Relocate command.

I need to look further into the code regarding use of the ACIA for retrieval of keypresses and output of characters. On first pass, it looks as if a call to the OS65D keyscan routine is not needed. There's a simple segment of code that checks/waits on the status of the ACIA for the player's input and acts accordingly if the receiver buffer/register is full.

input chr from ACIA1 (waiting)
;
syskin lda ACIASta ; Serial port status
and #$08 ; is recvr full
beq syskin ; no char to get
Lda ACIAdat ; get chr
RTS ;

[bxdanny]

It doesn't sound like you need to make any changes at all, other than calling the right 65D routines for input and output. $1000 to $15FF is within the area normally used by BASIC or the Assembler, and you can put your own programs there without difficulty. If all character input is done by calling the routine you posted, and all character output is done by calling another routine, you can "adapt" the program by changing a grand total of six bytes: replace the first three bytes of the input routine with JMP $2336 (4C 36 23), and replace the first three bytes of the output routine with JMP $2343 (4C 43 23). Put the resulting program into a six-page sector, then at the 65D prompt call that sector into RAM starting at $1000, and enter GO 1000. If you want to get a little fancier, you can preface the program with a block-move routine and have the whole thing load from a named file that would execute at $3A7E.

-Danny

Anyway, Happy Thanksgiving to you and all forum members.

[Lowrybt2]

First, Happy Thanksgiving to you Danny, and to all members of this forum.

I'm taking my first pass at using the Assembly Editor in OS65Dv3.3 in an effort to port Peter Jennings MicroChess program. I've cleaned up the assembly source code and made some edits to elements of the code related to grabbing and printing characters via the serial port. The assembly code is saved in a txt file with approx 830 lines totaling about 22,000 characters, each line of code numbered. This includes the source code and block data at the end of the file. The code is wonderfully labeled (came that way). The only direct calls are to OS routines related to serial I/O

Tried uploading the code and running the assembler this evening. It looks like procedurally I am missing a few steps and would welcome any and all guidance.

Using the WinOSI emulator, I'm booting a 8" OS65Dv3.3 image, exiting out of BEXEC*, typing NEW then CLEAR and EXITing to A*. Then entering ASM and arriving at .

At this point:
1. I open a serial input file which is the TXT file containing the cleaned up MicroChess code. The code begins to load at something like 300/600 BAUD (evening though the configuration for WinOSI has serial port speeds set to max.

2. The load seems to go okay (it's echo'd on the screen) but pauses every 300 or so lines at which point I'm prompted to open (again) the serial input file (the TXT source); once that is done, loading of the code continues where it left off until all of the code is in.

3. When I invoke the editor to proceed with assembly (typing A or A1), it seems that the editor is at work (the . disappears for a few moments) but I am not receiving the expected line-by-line listing of the code (and no indication of errors).

4. Interestingly, the system prompts me at some point to (re-)open the serial input file during this process. Ultimately, the process seems to complete. The . reappears. Issuing the PRINT command results in a clean read-back of the code.

5. The code that I'm uploading sets *=$5A7E. When I exit the assembly editor and try GO $5A7E, the WinOSI emulator enters the Debugger and begins running from a memory location well below 5A7E. I do see opcode and operands directly related to MicroChess but the line-by-line presentation in the debugger does not completely match the uploaded source code. The debugger consistently halts on errors related to AND commands in the source code (AND #$NN).

This is as far as I've gone. I'm wondering if the size of the code base may be problematic. Perhaps I should load it in chunks and figure out how to stitch it together. Here are a few basic question:
A. when the Assembly Editor is loaded, where does it reside in the memory space under OS65DV3.3?
B. when I upload source code into the editor, where does it reside in memory?
C. when A3 is invoked, the machine language generated is placed at 5A7E (or whatever starting memory location is indicated in the assembly code, right?

Addendum... I just realized that i need to get rid of some of the serial I/O code from the original KIM-1 version of microchess that slipped through. Regarding the OS65D serial input/output character grab/print routines, I'm calling the right addresses but am not sure that the characters that are input and output are being passed to/from the MicroChess code correctly. Also, I'm not certain that the characters flowing through the serial i/o routines will be echod on the screen output of the 540 board. That's essential since I'm not using an actual rs-232 connected terminal.

Many thanks for your patience with these questions. I'm sure more will follow.

Tom

[bxdanny]

First of all, which configuration of WinOSI are you using, video (C8P) or serial (C3-OEM)? I thought you said you had a C8P, so I am unclear why you keep talking about serial I/O. The OS calls you should be making are to the general input and output "distributor" routines ($2336 and $2343 respectively), not specifically to serial I/O drivers.

To answer the last questions first:

A. The Assembler/Editor resides from $0200 to $16FF. (Actually, much of the $15xx page and all of the $16xx page are empty and filled with $00 bytes, but that's the area allocated to it.)

B. Source code starts at $3A7E. (In 65D versions 3.0 to 3.2, it started at $317E on 8" systems, and $327E on 5.25" systems.) These are the addresses that named files always load to under 65D, whether they are BASIC or Assembler source files, or executable machine code for use with the XQ command. All files actually include a five-byte header, so loading of the disk image of the file really begins at $3x79.

C. Yes, the code assembled by A3 should be placed wherever the start of assembly (* = <address>) directive in the source code specifies. Make sure that directive appears at the beginning of the file; only comments should precede it. [There is, though, a command that can cause code to be assembled elsewhere than the source file specifies. Entering M2000, for example, would set an offset of $2000, meaning code intended for $3A7E would instead be assembled to $5A7E. I haven't really tested this much. I think the command needs to be typed at the Assembler's prompt, and not included in the source file. The specified syntax doesn't include "$" but instead assumes hexadecimal values. M0000 would presumably set the offset to zero and restore assembly to the location specified in the source file.]

Now, back to the numbered questions.

First, though, there is no need to type NEW or CLEAR before exiting BASIC (although doing so does no harm). Certainly not both, since the functionality of CLEAR is included in what NEW does.

1. The 65D 3.3 output routine (to video) is not the fastest, but why it should appear that slow, I don't know. You didn't mention using the command !IO 01 to start taking input from the serial port, but I am assuming that's what you did, if you are using the C8P configuration. If it's not, please explain what you did.

2. Are there any square bracket characters ([ or ]) in the source code? If so, they could be invoking the "indirect file" feature of 65D. When "[" is encountered in the input stream, it doesn't echo, but instead starts writing all subsequent input characters into memory starting at $8000 (in addition to processing them normally). When "]" is encountered, this stops, and also input returns to the console (keyboard), regardless of where it had been coming from. But I would expect that re-opening a "serial" file in WinOSI would restart it from the beginning, not continue from where it left off, so something else may be happening. To continue taking input from an open "serial" file in WinOSI, you would instead reissue the !IO 01 command.

3. and 4. I have no explanation for this. I again ask that you clarify the procedure you use to take input from the attached file.

5. The GO command at the 65D prompt should not include the "$" symbol. But you would just get an error message if you included it, so I will assume you didn't really. So I really have no explanation for what you are describing here.

I strongly recommend that, before trying to run newly assembled code, you check it with the Extended Monitor to see if it looks right. You can use !RE E to switch from the Assembler to the EM, and !RE A to switch back to the Assembler without losing your work/source code. In the EM, use (for example) Q5A7E to examine what has actually been assembled.

Can you post the source code here? (If you'd rather not, that's OK.) Do you have only the source code, and not an assembled binary of the original?

[Lowrybt2]

Thanks Danny. I've been trying to load the mnenomic source code into the assembly editor (*ASM) provided with OS65DV3.3 using the WinOSI emulator. Whenever I try to enter the assembly editor, it (the emulator) prompts me immediately to attach a serial input/read file and I've assumed it's looking for the code. So I've been attaching a txt file (see the attached uchess2OSI -LN6.txt) with the code. The code begins to load but pauses 2 or 3 times during the load when the emulator prompts me to reattach/reopen the txt file. The code reads into the editor without any apparent errors. I realize that there must be something I'm doing wrong because whenever I issue the A, A1, A2 or A3 commands, there is no visual feedback from the editor. It does seems as if the editor is running -- the interface freezes for a time as the '.' prompt disappears and eventually reappears. Ultimately I can't find the assembled code where its supposed to be using EM. I do see evidence of the mnenomic code at 3A7E using the WinOSI debugger but its seems corrupted/changed.

-The original MicroChess code posted on 6502.org is contained in the attached file: uchess2.txt. The distribution site is http://6502.org/source/games/uchess/uchess.htm

-A somewhat modified version of the uchess2.txt code is contained in the attached file uchess2OSI -LN4.txt. This file adds line numbers to the uchess2 code, removes some of the descriptive notations at the start of uchess2, and shows lines I deleted before trying to load the code into the editor -- any enumerated line preceded by an x was deleted before being loaded. The portions of code deleted relate to initialization of the 6551 ACIA and calls to subroutines related to read/writes from/to the ACIA.

- The file uchess2OSI -LN6.txt shows the final, cleaned-up code with ACIA-related instructions removed, and JMPs added to invoke the I/O routines in 65D at the addresses you indicated.

The code related to printing the chess board and capturing input (single character) commands resides largely at lines 674-844. Subroutines labeled SYSKIN and SYSCHOUT are where the calls to 65D I/O reside. Other subroutines POUTnn, SYSHEXOUT and PRINTDIG help determine what gets printed.

Much obliged for your time looking into this. Tom

[bxdanny]

Taking a quick look at the uchess2OSI -LN6.txt file, and searching for the output address $2343, I found this:

Code: Select all

814  SYSCHOUT       PHA                     ; save registers
815                 JMP   $2443		    ; OS65DV33 char output routine
819  		    PLA                     ; get chr
821                 RTS                     ; done 

It won't do to push a value on the stack from within a subroutine, and then do a JMP to a different subroutine that returns without first pulling that value back off the stack. It will return to the wrong place, since it will take that character pushed on the stack as part of its return address. You need to use JSR instead of JMP. Or actually, you could omit the PHA/PLA pair and stick with JMP, since the 65D output routine saves the registers on entry and restores them on exit (as does the input routine).

[bxdanny]

[Second reply - please see preceding message]

After looking at the Microchess source code a little more closely, I see two other problems with trying to assemble it using the 65D Assembler.

1) Square brackets

[Actually, I see you have already changed the square brackets to angle brackets (< and >), so you (Lowrybt2) can ignore this section, but I will leave it here for the benefit of other readers.]

As I suspected, there are square brackets ([ and ]) used in the source code, specifically in the comments. The close-square-bracket character is what was causing input from the file to pause, since 65D recognized it as an "end indirect file" indicator. There are two possible solutions:

a) When booting 65D, while in BASIC immediate mode, enter the command POKE 9549,96. This will disable indirect files altogether, allowing square brackets to be used as normal characters.

OR

b) On the PC, when editing the source file, do a global search-and-replace for the square bracket characters. Change all occurrences of [ to ((, and all occurrences of ] to )). Then the problem will not occur.

2) Accumulator vs. implied addressing (LSR instruction)

There are several instances of an instruction that is given simply as LSR, with no operand specified. This may work with some assemblers, but it doesn't work with the 65D assembler. Instead, you need to use the syntax LSR A, since the accumulator (A) is the operand of the instruction. All occurrences of LSR should be changed to LSR A. (If there were instances of ASL, ROL, or ROR with no operand, the same would apply to them, but there aren't.)

Finally (well, almost), I'll note that, when I was searching for those square brackets, I noticed two errors in the original source code, on the same lines as uses of square brackets. It lists $40 and $41 as the hex codes for P and Q, respectively, when in fact the hex codes for P and Q are $50 and $51, respectively. ($40 is @ and $41 is A.)

And finally (for real), I'll point out that, if you want to be able to exit back to 65D from Microchess, you should change the zero-page location used for PMOB, which was $EF. You could perhaps change it to $AF or $FF. The reason is that the 8-inch versions of OS-65D (3.2 and 3.3) use location $EF to hold the step rate of the floppy drive, either 6 or 8 ms. This is the only location (other than location 0) in the "OS context" page zero whose value must be preserved from one OS call to the next. (The 5.25-inch versions do not require this, nor do versions 3.0 and 3.1.) So if you make this change, you can change the instruction at label DONE to JMP $2A51, to re-enter the 65D kernel. Otherwise, it might be best to make it JMP ($FFFC), an indirect jump through the reset vector.

[Lowrybt2]

Danny,

Many thanks for your quick analysis of the code. I'm making the changes and will give it another go in the next few days. Tom