Use The Source, Luke

I've just uploaded the disassemblies - those of which I am entitled to - of the remaining projects to the download page, with the exception of Donkey Kong, which is very much WIP and I have every intention of completing it.

A few of the earlier projects are rather incomplete, and will probably remain so.

I do have a handful of diassemblies - all very much incomplete - that were used when reverse-engineering the hardware in order to assist with an FPGA implementation. Since they're not really part of any (software) porting project, I won't include them here.

Enjoy.

Finally! Joy after getting past my sticking point!

To say that adding joystick support was frustrating is an understatement!

There's not a whole lot of information on the net about sampling the joysticks, less still about reading the buttons, and some of the information that is available is, well, wrong. And to confuse matters further, I was having issues in MESS with the 2nd joystick button. Not having a physical 2-button joystick to test on real hardware is fraught with impediments to success.

Still at this point unable to test on real hardware, I at least seem to have sorted out the details and MESS finally behaves as I'd expect, given the Coco 3 schematics. I guess I should have gone to them in the first place, rather than as a last resort.

I thought I'd post my joystick code here on the off chance that someone else has similar issues in the future.

Let's define some useful constants.

PIA0        .equ    0xFF00
PIA1        .equ    0xFF20
DATAA       .equ    0x00
DDRA        .equ    DATAA
CRA         .equ    0x01
DATAB       .equ    0x02
DDRB        .equ    DATAB
CRB         .equ    0x03

; equates to keyboard rows
; - phantom keys appear accordingly
RJOY_BTN1   .equ    (1<<0)
LJOY_BTN1   .equ    (1<<1)
RJOY_BTN2   .equ    (1<<2)
LJOY_BTN2   .equ    (1<<3)

;.define LEFT_JOYSTICK
.ifdef LEFT_JOYSTICK
  JOY_BTN1  .equ    LJOY_BTN1
  JOY_BTN2  .equ    LJOY_BTN2
.else
  .define RIGHT_JOYSTICK
  JOY_BTN1  .equ    RJOY_BTN1
  JOY_BTN2  .equ    RJOY_BTN2
.endif
; high and low thresholds
; for 'digital' operation
JOY_LO_TH   .equ    0x64                ; ~40%
JOY_HI_TH   .equ    0x98                ; ~60%

First up, the one-off initialisation, which sets all the appropriate PIA data-direction registers. Bear in mind that Knight Lore takes full control of the Coco 3 hardware, swapping out ROM and disabling all interrupts except a simple (F)ISR used to emulate the Z80 Refresh register. So the PIA's are immune to any reconfiguration behind-the-scenes.

  ; configure joystick axis selection as outputs
  ; and also select left/right joystick
        lda     PIA0+CRA
        ldb     PIA0+CRB
        ora     #(1<<5)|(1<<4)          ; CA2 as output
        orb     #(1<<5)|(1<<4)          ; CB2 as output
.ifdef LEFT_JOYSTICK
        orb     #(1<<3)                 ; CB2=1 left joystick
.else
        andb    #~(1<<3)                ; CB2=0 right joystick
.endif
        sta     PIA0+CRA
        stb     PIA0+CRB
  ; configure comparator as input
        lda     PIA0+CRA
        anda    #~(1<<2)                ; select DDRA
        sta     PIA0+CRA
        lda     PIA0+DDRA
        anda    #~(1<<7)                ; PA7 as input
        sta     PIA0+DDRA
        lda     PIA0+CRA
        ora     #(1<<2)                 ; select DATAA
        sta     PIA0+CRA
  ; configure sound register as outputs
        lda     PIA1+CRA
        anda    #~(1<<2)                ; select DDRA
        sta     PIA1+CRA
        lda     PIA1+DDRA
        ora     #0xfc                   ; PA[7..2] as output
        sta     PIA1+DDRA
        lda     PIA1+CRA
        ora     #(1<<2)                 ; select DATAA
        sta     PIA1+CRA

Now the joystick and button sampling. Note that Knight Lore uses a 'digital' joystick so it's only concerned with checking the position on each axis within three zones - left, middle and right.

        ; select hoizontal axis
        lda     PIA0+CRA
        anda    #~(1<<3)                ; CA2=0 horizontal
        sta     PIA0+CRA
        ; set comparator value to 40%
        lda     PIA1+DATAA
        anda    #0x03                   ; clear value
        ora     #JOY_LO_TH              ; low threshold
        sta     PIA1+DATAA
        lda     PIA0+DATAA              ; comparator
        bita    #(1<<7)                 ; joystick greater?
        bne     1$                      ; yes, skip
        orb     #INP_LEFT               ; aka #INP_W
        bra     2$
        ; set comparator value to 60%
1$:     lda     PIA1+DATAA
        anda    #3                      ; clear value
        ora     #JOY_HI_TH              ; high threshold
        sta     PIA1+DATAA
        lda     PIA0+DATAA              ; comparator
        bita    #(1<<7)                 ; joystick greater?
        beq     2$                      ; no, skip
        orb     #INP_RIGHT              ; aka #INP_E
        ; select vertical axis
2$:     lda     PIA0+CRA
        ora     #(1<<3)                 ; CA2=1 vertical
        sta     PIA0+CRA
        ; set comparator value to 40%
        lda     PIA1+DATAA
        anda    #0x03                   ; clear value
        ora     #JOY_LO_TH              ; low threshold
        sta     PIA1+DATAA
        lda     PIA0+DATAA              ; comparator
        bita    #(1<<7)                 ; joystick greater?
        bne     3$                      ; yes, skip
        orb     #INP_FORWARD            ; aka #INP_N
        bra     4$
        ; set comparator value to 60%
3$:     lda     PIA1+DATAA
        anda    #3                      ; clear value
        ora     #JOY_HI_TH              ; hi threshold
        sta     PIA1+DATAA
        lda     PIA0+DATAA              ; comparator
        bita    #(1<<7)                 ; joystick greater?
        beq     4$                      ; no, skip
        orb     #INP_PICKUP_DROP        ; aka #INP_S
        ; read joystick buttons
4$:     lda     #0xff                   ; no keys, only buttons
        jsr     read_port
        bita    #JOY_BTN1
        beq     5$
        orb     #INP_JUMP
5$:     bita    #JOY_BTN2
        beq     6$
        orb     #INP_DIR_PICKUP_DROP
6$:     bra     finished_input               

I haven't done any timing nor studied the BASIC joystick routines but short of hand-picking registers and instructions that minimise clock cycles, I don't think there's much you could do to get a faster sampling routine. Happy to be proven wrong by any astute reader.

Waiting for a 2-button adapter to turn up; hopefully that'll arrive in time for me to test before sending the final version off to John for demonstrating at the CocoFEST. I was going to try to experiment with some optimisation to speed up the rendering, but I think I'll take a short break from Knight Lore - or the 6809 port at least - until after CocoFEST.

I'm already thinking about the next port, which is dangerous before finishing off Knight Lore completely. But I've got a couple of new ideas which I need to investigate further. One is an actual arcade port; not a new game for the Coco (or any platform really) but it would be cool to have the actual arcade code and graphics, effectively, running on the Coco3. And reverse-engineering is already complete, so the port would be relatively quick. We'll see...

Phantom keys

No updates reflect the fact that I've had very little time to work on Knight Lore, and even less time to blog about it. I can say that I've got (2-button) joystick input working, after rolling my own joystick routines.

I've been optimising the code from the cocopedia article, moving much of it into a one-off initialisation. In fact it makes supporting either the left or the right joystick at run-time trivial (as-is it's a simple .define build option). The sampling routine now only needs to select the axis, write the sound register (twice) and read back the comparator output (twice). Repeat for 2nd axis.

One issue is the button reading, and the phantom key presses that result. I've still got some research on that to do, and I think I know how to avoid the problem (in Knight Lore) whilst retaining the current key mapping. Once it's all working I'll post my joystick initialisation and sampling routines and (hopefully) explain how I negated the phantom key press issue.

No real joy... yet!

Added support for directional controls. Joystick is still emulated with arrows plus two extra keys, but it has allowed me to test the directional code. All that remains now is to change the emulated joystick routine to read the real Coco3 joystick.

After having been sent some sample code with explanation from James, and reading up on a few blogs, most notably John Linville's The Making of Fahrfall: Reading The Joystick, it's clear that I only need to sample each of the two axes twice in order to obtain a digital reading - something best done internally in my Knight Lore code.

I haven't really looked into joystick support for the Coco3 in MESS, so I have no idea if I can even test it under emulation, but I do have a pair of the standard single-button Tandy joysticks. In the interests of productivity, the best option is probably Drivewire or, failing that, CocoSDC (which I've yet to use). Either of those options is certainly better than erasing and programming EEPROMs...

UPDATE: Was hoping I'd get time to implement reading the joysticks tonight, but after reading a great article on coco3.com that details everything I need to know, it's become apparent that it's a little more involved than I first thought. I'm sure at least some of the PIA configuration need only be done once for Knight Lore, since I have total control over the machine, but it will take some analysis to determine exactly which bits. For another night...

FORGOT TO MENTION: I have it reading the joystick buttons now at least.

CPC and fake joysticks

I couldn't resist starting to add support for CPC graphics. First task was to reorganise the memory map to cater for the 2BPP video display and buffer; it was a tight fit and for a few minutes I thought it wasn't going to work. But all good.

Ripping and adding the CPC sprite data was trivial. Adding support, however, won't be. The nature of the changes for the Coco3 are actually quite different to both the Amiga (planar bitmap memory) and the Neo Geo (hardware sprites pre-rendered in ROM). In addition, the panel sprites are quite different so there's a fair bit of work to do - likely too much to do before CocoFEST.

And so I returned to the issue of joystick - and directional - support. Since there was no code behind the main menu for input method selection, I added support for selecting Keyboard, Joystick and Directional Control, removing the other two ZX Spectrum-specific joystick options in the process.

The Main Menu is now tailored specifically for the Coco3 port

The ZX Spectrum uses flashing attributes to denote options selected in the menu - noticeably absent on the Coco3. Instead, I modified the text display routine to simply invert the character if the flash attribute was set, then added a blit to update the relevant lines on the menu each iteration through the main menu loop. Later I may invoke a timer and actually have it flash, but there's more important things to do first and CocoFEST is fast approaching.

Finally, I added a fake joystick read routine that - for now - simply reads an alternate set of keys from the keyboard. This will facilitate adding directional controls without complicating the issue with untried joystick code. I would expect that I'll have directional control working next session, which means all that remains is to replace the fake joystick read routine with the real one.

Shady dealings

I've had no luck getting my Coco 3 hooked up to anything other than the lounge room TV; none of my monitors like 50Hz composite and I can't get my fancy pants video converter to recognise the Coco RGB output either (though that's entirely my fault, I haven't modified the software to do it yet!) So no pictures of Knight Lore running on real hardware just yet unfortunately.

During the development of Knight Lore I've referenced many different resources on the net, one being the Knight Lore Walkthrough, ZX Spectrum video found on YouTube. A similar video by the same author caught my eye; Knight Lore (Graphics Mod) Walkthrough, ZX Spectrum. A chap by the name of Mick Farrow enhanced the original ZX Spectrum graphics back in 2002, adding more shading (via dithering) and sharpening the outline of some sprites. Unable to locate a binary of this version, I contacted both the video author and then eventually Mick himself, and received helpful responses from both - thanks again guys!

I received a .TAP file first, but couldn't for the life of me work out how to execute it in MESS. Before resorting to asking for help, Mick sent me a .Z80 which I had running in MESS a few moments later. After giving the game a quick spin, I restarted MESS with the debugger enabled, and dumped the entire 64KB to a binary file.

During development I wrote a utility that read the .SNA file and (besides a lot of other things) produced a text file with C data declarations (with nice names) for all the data structures in the game, figuring it would come in handy for the other filmation games as well (it did/will). When I started on the Coco3 port, I extended the utility to also produce a 2nd text file with the respective ASM data declarations. I had to add literally 3 lines of code - to instead read the above-mentioned 64KB memory dump of Mick's version - and seconds later had the modified graphics ready to compile/assemble. And as it just so happens, the sprite data resides in a separate .ASM file that is .included in the main .ASM file, so using alternate graphics is a matter of simply .including a different file. And now with a build option using a .define it's very easy to select which version to build.

So as of now, the Coco3 port has two build options - Original or Mick Farrow graphics. And to give you a taste of what they look like on the Coco3, I've got a couple of screen shots.

The splash screen, with an acknowledgement to Mick

A sample of Mick's shaded and sharpened graphics

I should hasten to add that Mick was nice enough to grant me permission to use his graphics mods. A Coco3 cartridge with at least 128KB capacity could theoretically contain versions with Original, Mick Farrow and Amstrad CPC graphics! It will be equally as trivial to add them to the C ports (Amiga, Neo Geo) as well (binaries will support all graphics options in the one build).

But for now, I should start looking at Coco joystick support!

UPDATE: I have one, really crappy, photo of Mick's graphics running on a real Coco3!

The Real Deal!

I was hoping to have some accompanying photos to commemorate the occasion, but circumstances didn't allow it. On the plus side, I got to sample the Firefly board game, which is pretty cool!

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