Here are some files if anyone wants to laugh at my code.

My feeble Tic Tac Toe attempt.
full.asm is the full listing from the assembler
the .rar file is the CBM prg Studio project (you may have to fiddle with the directories. I don't know if CPS uses relative or absolute).

Next is to code the logic for the computer choosing a square and determining a winner.

[Edited to attach the files to this post. I can't attach the binary files.]

In the future, you can attach files to your posts and thus spare others from having to deal with other sites when it comes to looking at source code, schematics, etc. Aside from a matter of convenience, external links can break with time, whereas attachments to your posts will be around as long as 6502.org is around.

I, in particular, studiously avoid anything to do with Google, and find Github a royal pain in the tush.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Noted. I'll edit post as soon as I get back home.

As a slightly different point of view, I find GitHub and similar sites to be great, especially if you can use it just for handling stuff in Git repos, and avoid letting important things leak out to other areas such as issues and project wikis (or anywhere where the data don't get fetched when you git clone the repo.) It allows anybody who wants the full system to grab it easily, and also allows easy browsing of source files. And it basically comes free with using Git, which is worth learning: most developers consider a revision control system as essential as a good editor (though I'm sure some would disagree).

That said, it's definitely still a good idea to attach particular versions of files here as well, since keeping the data close to the message is useful and even if you do provide links to specific commits and their files on GitHub (as opposed to a link to the whole repo, containing every version of the file) those can still vanish if you're linking to a branch that you later remove without merging the commit into the mainline or other long-term branch.

(For reference, a link to a specific version of a file on GitHub will look something like this: https://github.com/0cjs/8bitdev/blob/b246ba674109e5ed0aeaf85fbf79d6f7d88dab3d/src/bigint.a65.)

The issue with your Google links was that it was kind of the worst of both worlds: the files at that link can change and vanish, and they still need to be downloaded anyway before they can be viewed.

_________________
Curt J. Sampson - github.com/0cjs

As they say, anything that works is better than anything that doesn't. Still, there are possibly useful changes that could be made in spots. Consider this:



and later this:



The first thing I notice is that you are using numbers for things that conceptually are not numbers. You might make the code easier to read by writing something like this:



Or you might use an equate somewhere to attach a label to the keys you're using:



and then use that label wherever you've been using a hard-coded number. That would make it both easier to read and easier to change (not that that's very likely in tic-tac-toe - but what if you port the game to system that doesn't use ASCII?).

Second, taking a branch of any sort does not change the contents of any register you can easily get at (it does change the program counter, but that's harder to read - not impossible, but not especially easy). So when you branch after comparing the contents of the accumulator, when the program gets to where the branch leads, the accumulator still has that same value. You don't need to re-load it. And since you store the contents to the same location, you don't really need two branch destinations either:



For this bit:



I have an old book by Adam Osborne that says one of the defining characteristics of microcomputer programs is blatant and promiscuous intermixing of code and data. Maybe so, but I've personally never been comfortable with it. Here you've got a variable buried in the midst of your program. You already know that you can use zero page to store things. You can also use anywhere in memory that isn't already used by something else. The memory directly following your program, for instance. Doing would not change the size, speed or functionality of your program, but it would be cleaner, IMHO.

It would also make it a lot easier to put the program in ROM one day, should you decide to do that.

_________________
Curt J. Sampson - github.com/0cjs

Thanks for the great info! As for zero page... most of it is already used by something else so I'm not sure what locations are safe and what locations aren't. I could blank out BASIC and I assume that would make all of the BASIC zp available.

Though you can, there's no need to switch out the BASIC ROM. That's not exactly a time critical variable where an extra cycle is going to bog down your program.

You've started your program with a BASIC stub to switch control to your machine code, but I don't see use of the BASIC ROM after that. Which means that all the memory from the end of your program to the start of the BASIC ROM at $A000 is free for you to use for whatever you want. Essentially the same as what you're doing now by using the RAM that the BASIC ROM would use for a BASIC program for your own program instead. There's no reason you can't use that RAM for variable storage as well as code storage.

If that's not enough, as has been pointed out before IIRC, the RAM from $C000 to $CFFF is untouched by anything in the BASIC or Kernel ROMs. Four kilobytes of space lying fallow, just aching to be put to constructive use.

If that's not enough, you could switch out the BASIC ROM if you don't need it and use all the RAM from the end of your program to $CFFF for your own purposes, an additional eight kilobytes normally "hidden" by the BASIC ROM (you can actually write to this RAM any time you want, but reading back from it will get values from the BASIC ROM until it's switched out).

Incidentally, if you do want to switch out the BASIC ROM but not mess up its use of zero page so badly you have to cold start it after switching it back in, you could copy the portion used by the BASIC ROM to somewhere else - like to a page somewhere between the end of your program and start of the BASIC ROM - or even "underneath" it, since the write will go "through" and into the underlying RAM, and it will be easy to copy back when the time comes since the BASIC ROM is switched out and the underlying RAM is exposed.

And if you want to be sneaky, you can temporarily map out the I/O block and copy zero page there, and then map I/O back in. Just be sure to bracket the process with SEI - CLI, since the source of the jiffy IRQ, CIA #1, won't be accessible to the ISR.

If you carefully study the C-64's architecture, you will see that it is possible to expose contiguous RAM from $02 to $FFFF. That isn't very practical, however, since a computer with no I/O is pretty limited in what it can do.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

There's plenty of I/O left! On the 6510's built-in PIA you have cassette motor and cassette write lines for output, and the cassette sense line for input. You can hook pretty much any hardware you like to this, so long as you're willing to do some simple interfacing, so the possibilities are unlimited. :-)

_________________
Curt J. Sampson - github.com/0cjs