Close

System Timer Interrupt

A project log for rosco_m68k

A full-featured Motorola 68k retro computer, starring a 68010 running at 10MHz

ross-bamfordRoss Bamford 06/16/2019 at 21:354 Comments

Now I have the MC68901 MFP integrated and the UART is working, I spent a bit of time this weekend setting up Timer C of the MFP as a timer tick I can use in the OS for multitasking.

For testing purposes, I've set the timer up at about 18Hz and have the interrupt handler just flash an LED connected to MFP GPIO 0. That way, I can visually see that the handler is being run. The code that sets up the MFP now looks like this (I've also upped the UART to 19200 baud):

* Initialise MFP
*
* Trashes: D0
* Modifies: MFP Regs
INITMFP:
* GPIOs
    move.b  #$FF, MFP_DDR   ; All GPIOs are output
    
* Timer setup - Timer D controls serial clock, C is kernel tick
    move.b  #$00, MFP_TCDR  ; Timer C count is 0 (equivalent to 255) for 18Hz
    move.b  #$0C, MFP_TDDR  ; Timer D count is 12 for 19.2KHz
    move.b  #$71, MFP_TCDCR ; Enable timer C with /200 and D with /4 prescaler
    
* USART setup
    move.b  #$08, MFP_UCR   ; Fundamental clock, async, 8N1
    move.b  #$05, MFP_TSR   ; Set pin state high and enable transmitter

* Interrupt setup - Enable timer C interrupt for kernel tick
    move.l  #MFP_VECBASE, D0
    move.b  D0, MFP_VR
    or.b    #$20, MFP_IERB  ; Enable Timer C interrupt...
    move.b  #$20, MFP_IMRB  ; ... and unmask it.
    
    rts

The code for the handler is very simple:

TICK_HANDLER:    
    bchg.b  #0, MFP_GPDR
    rte    

Because I'm using vectored interrupts, this should be on vector 0x45 (MFP_VECBASE is 0x40 and Timer C is at offset 5 in the MFP), but because of a limitation of my IO DTACK generation it's not actually working that way - the IO DTACK circuit doesn't take account of /IACK and so /DTACK is immediately asserted, presumably before the MFP can put the vector on the bus. This causes the vector to always be FF, so for now the handler is just mapped there for testing.

To actually fix this, I'll need to revisit the /IODTACK generator. I've not put anything down in EAGLE yet, but my plan is to build something like the following:

Which is basically the same as it is now, with the addition of /IACK into the logic to cause it to work when the CPU is doing an acknowledge cycle.

There may be a bit more to it, as I'm not 100% sure at this point what the CPU does with /LDS during an acknowledge. The MFP needs its /DS to be asserted along with /IACK so I may need to do a bit more work there, but I'll know tomorrow when I've had chance to look again at interrupt acknowledge in the MC68010 manual.

Discussions

Ross Bamford wrote 06/18/2019 at 08:05 point

It's certainly taking shape. I've done a couple of x86 and x64 OS projects in the past, so I'm looking forward to doing one where I don't have to jump through all the hoops that architecture requires just to get set up :)

  Are you sure? yes | no

Matt Lacey wrote 06/17/2019 at 03:47 point

I'm really going to have to get stuck back into mine. You've blown past me in no time! What OS are you planning on using? DIY or porting something else?

  Are you sure? yes | no

Ross Bamford wrote 06/17/2019 at 18:45 point

You definitely should! I've been kinda motivated to get mine to a point where it can do something interesting as I'm giving a talk on it next week at work! My long term plan is to put together a simple microkernel and basic OS on top of that, but in the short term I'm toying with the idea of getting something like TUTOR running to make it somewhat interactive for next week...

  Are you sure? yes | no

Matt Lacey wrote 06/18/2019 at 00:09 point

Flying along :) I've always been interested in OS dev and that's kind of what let me down to building this thing. Hopefully I can set aside some time on the weekend and get it running once more.

  Are you sure? yes | no