In short, my Knight Lore cartridge boots up and plays fine on a real Coco 3. A few artifacts that aren't apparent on the emulator are noticeable, though very minor and perhaps I'll ignore them as they don't really affect the finished product. I only got to play it for about 5 minutes before I had to shut it down, but it was enough to prove that it's basically working.
The version I have now is definitely sufficient to demonstrate at CocoFEST, even with the lack of code optimisation. I'm undecided whether I'll press on and try to squeeze a few more features in before then, or take a short break and continue after CocoFEST is over.
I'm tempted to add joystick support, especially since I've had an offer of assistance with the code. Might be nice to show off the newly-designed Sega gamepad adapter that I believe will also be debuted at the 'fest. Though of course I probably won't have one in time to test with...
I'll update this post with some pictures ASAP.
 |
| The world's first Coco3 Knight Lore cartridge |
Excellent work! You've made great progress and you have one of the new Sega gamepad adaptors? Does the game fit into a single 32K ROM?
ReplyDeleteI'm trying to arrange one of the adapters to add support before CocoFEST!
ReplyDeleteThe game is currently about 30.5KB!
Here's my little detection program:
ReplyDeletehttp://x128.speccy.cz/coco/DETECT.zip
It includes ASM, machine-agnostic CAS as well as (CoCo) BIN & DSK.
RUN"DETECT for DSK
CLOADM:EXEC for CAS
The BIN has the usual CoCo 5 bytes before and after.
It's a simple program which tests PAL/NTSC, CoCo/Dragon, 4K/16K/32K/64K (although 4K won't work in the current version unless it is recompiled at $0A00).
It is compiled with A09, which I'm sure will puzzle you. It has excellent macros, but poor local labels, hence lots of BRA 1B, BRA 1F, etc. The parts you need will be easy to change into what you want.
Crucially, it also reads the keyboard and joysticks. This will be the bit that interests you.
; EQUs
JOY_DEADZONE EQU 12
CTRL_UP EQU 8
CTRL_DOWN EQU 4
CTRL_LEFT EQU 2
CTRL_RIGHT EQU 1
CTRL_FIRE0 EQU 1
CTRL_FIRE1 EQU 2
; Variables
KeyMatrix
RMB 10 ; 9th row = joystick fire. 10th row = UDLR, UDLR2.
JoyMatrix
RMB 4
; How to call (once per frame/game loop)
LDX #KeyMatrix
JSR KEYREAD
LDX #KeyMatrix
JSR JOYFIRE
LDX #JoyMatrix
JSR JOYREAD
The first 8 bytes of KeyMatrix are the 8 keyboard rows, as you'd expect.
The 9th byte contains the fire buttons from the joysticks.
Mask with CTRL_FIRE0 (right joystick: the main fire button, as used in CoCo/Dragon)
Mask with CTRL_FIRE1 (right joystick: the other fire button, only used in CoCo 3)
Mask with CTRL_FIRE0 << 2 (left joystick: the main fire button, as used in CoCo/Dragon)
Mask with CTRL_FIRE1 << 2 (left joystick: the other fire button, only used in CoCo 3)
The 10th byte contains the digital directions of both joysticks!
CTRL_UP/DOWN/LEFT/RIGHT masks for the right joystick
CTRL_UP/DOWN/LEFT/RIGHT << 4 masks for the left joystick
Note how it clears out the rogue keyboard columns when joystick fire buttons are pressed. This is essential and means you have to be careful when picking keys, if you have a situation where joystick and key controls are active at the same time.
JoyMatrix contains the standard analogue values of the joysticks, as read by the ROM routine (right joystick first). I think it's Right X, Right Y, Left X and then Left Y.
The right joystick comes first in all of these, as that appears to be the CoCo/Dragon standard, with player 1 using the right joystick. (I may be wrong in this, but that's what it has appeared to be so far).
JOY_DEADZONE can be changed, if you have any problems when reading your joystick as digital values, but so far it has been fine for me.
Note that it calls the ROM joystick routine, so it pages in 32K RAM mode, then goes back to 64K RAM mode, you may want to change this, depending on your circumstances.
You can use this program on a real machine to check for joy/key clashes and keyboard matrix ghosting.
Also, you may find on a real machine that you can hear a clicking sound when you read the joystick. If that happens, you have to switch off the sound output when you're reading the joystick and then you can switch it back on immediately, if required.
I hope that helps. I can also do cassette loaders, if needed!
Thanks, much appreciated!
ReplyDeleteThe first cross-assembler I used for the Coco was A09, although that was so long ago I can't recall much about it.
I'll have to study your code for a bit before it sinks in. I'm running in 64K RAM mode, executing out of $C000 upwards so I'll have to research the implications of trying to switch in the joystick ROM routines. There's a chance I'll have to replicate what the ROM code is doing myself anyway, since I'm pushing the CPU to its limits now I might have to thread the joystick reads carefully throughout cycle-counted code, but for a 1st pass it'll be sufficient to use the ROM. Thanks again!