VIA interrupt generation...

[kc5tja]

Please see the enclosed source code. This is the first time I've ever used the interrupt capabilities of the VIA chip.

The problem is that the VIA chip generates interrupts every 5 clock cycles. And, I'm not sure why this is happening. According to the documentation I have here via the VIA datasheet and all, I should *just* be getting an interrupt due to the CB2 line going low. CB2 is verified to be high -- it should not be generating IRQs, let alone IRQs this often.

The only thing I can think of is that it is related to the timers, BUT, again, I did NOT set the timer interrupt enable bits at all, so they should be quiet.

Any ideas?

(Note: the LDA+2 and STA+2 are forms which forces ACME to generate 2-byte absolute addresses. This is required since I relocate the direct-page, and therefore cannot use direct page to access the VIA registers. It's a heck of a lot easier to type than LDA $0000+VIA_PB, or STA $0000+VIA_IER.)

Code: Select all

;
; echo-server.a
; Kestrel Release 1p1
;
; Copyright (c) 2005 Samuel A. Falvo II
; See LICENSE.txt for more details
;   

    !to  "echo-server.b"
    !src "65816.i"
    !src "via.i"
    !src "spi.i"

    * = $FC00
    !src "spi.a"

RxBuffer        = $00       ; pointer to start of receive buffer
RxLength        = $02       ; length of data received
PacketReceived  = $04       ; -1 if packet has been received

__start:

    ; Establish runtime environment

    clc
    xce
    rep #P_MX
    !al
    !rl

    ldx #$E1FF
    txs
    lda #$E000
    pha
    pld

    ; Initialize the SPI bus

    lda #$E200                  ; Initialize the receiver's buffer area
    sta RxBuffer

    sep #P_MX
    !as
    !rs

    lda #SPIM_OUTPUTS-SPIF_CLK  ; Initialize SPI pins, sets idle bus device
    sta+2 VIA_PB                ; Setting PB first eliminates glitches
    ora #SPIF_CLK
    sta+2 VIA_DDRB

    lda #VIA_IERF_SET | VIA_IERF_CB2
    sta+2 VIA_IER
    lda+2 VIA_PB                ; Clear any pending interrupt, just in case

    ; Wait for a connection request from the client

Again:
    stz PacketReceived
    cli                         ; unlike x86, this *enables* interrupts
wait:                           ; busy-wait on a flag until interrupt
    lda PacketReceived
    beq wait
    sti                         ; Prevents spurious interrupts
    jsr EchoPacket              ; RxBuffer/Length are valid now
    jmp Again

EchoPacket:
    clc                         ; Somehow, tell engineer that we got here.
    xce
    sec
    xce
    jmp EchoPacket

;
; IRQ handler -- this is invoked whenever the ATN# signal goes low from
; the SPI slave.  Note that ATN# is attached to CB2 of the VIA chip, and
; is therefore able to generate interrupts.  This allows us to handle an
; in-coming packet at any time.
;

__IRQ:
    pha
    phx
    phy
    php
    sep #P_MX
    !as
    !rs

    lda+2 VIA_IFR
    and #VIA_IFRF_CB2       ; We only accept SPI-generated IRQs at the moment
    beq spurious
    lda+2 VIA_PB            ; Acknowledge the interrupt
    jsr ObtainPacket

spurious:
    plp
    ply
    plx
    pla
    rti

ObtainPacket:
    lda PacketReceived          ; Ouch!  We should never get a packet overrun
    ora PacketReceived+1
    bne Overrun

    ldy #$00

    lda #7
    jsr SPI_SelectDevice

.rxLoop:
    jsr SPI_ReceiveByte_Async
    sta (RxBuffer),y
    iny
    cmp #$00
    bne .rxLoop

.rxDone:
    sty RxLength
    stz RxLength+1

    dec PacketReceived          ; Huston, we have a packet.
    dec PacketReceived+1


Overrun:
    lda #15
    jmp SPI_SelectDevice

    * = $FEFC                   ; native-mode vectors
    !word __start, __IRQ

    * = $FFFC                   ; emulation-mode vectors
    !word __start, __IRQ

[dclxvi]

It looks like the native mode IRQ vector is not initialized correctly, since it is at $FFEE not $FEFE (by the way, there is no native mode RESET vector, since RESET sets the e flag).

There appears to be another bug in the 65816 datasheets (in both the February 2004 revision on 6502.org and the June 2004 revision at www.westerndesigncenter.com) on p. 34, which have the native mode interrupt vectors at $FFFX instead of the correct $FFEX. Oddly enough, the March 2000 datasheet (in the "Older" folder under the 6502.org WDC datasheets) is correct, regarding the native mode vectors (on p. 31), as well as the timing diagram (p. 29) mentioned in another post. The Programming Manual (at www.westerndesigncenter.com) also has the correct native mode vector addresses on p. 55.

[kc5tja]

dclxvi wrote:

It looks like the native mode IRQ vector is not initialized correctly, since it is at $FFEE not $FEFE

Doggone it!!! Hours and hours of debugging . . . for THAT!! I will need to change this after work. No time to fix it now. Thanks for the second set of eyes!

Quote:

(by the way, there is no native mode RESET vector, since RESET sets the e flag).

I'm well aware of this.

[dclxvi]

kc5tja wrote:

Doggone it!!! Hours and hours of debugging . . . for THAT!!

It's always the simplest errors that are the hardest to find, isn't it? This is where a label or macro named something like NATIVE_IRQ_VECTOR can be handy (says the guy who doesn't do this himself).

By the way, you never initialize PacketReceived+1 so it can overrun the first time (since you're using ORA PacketRecieved+1). Even if it is zero the first time, it'll be non-zero after the DEC PacketRecieved+1, so it would overrun if there were a second time (interrupts are disabled -- assuming STI is an alternate name for SEI, didn't you have problems with your assembler not generating code when you used TAS instead of TCS? -- and EchoPacket never exits)

Speaking of EchoPacket, note that with the current order of instructions, replacing the JMP with an RTS (if you wanted a single pulse on the E pin) will leave the processor in emulation mode. Anyway, you may want to have the native and emulation mode IRQ routines be at least slightly different so you can distinguish between the two as you're debugging.

kc5tja wrote:

Quote:

(by the way, there is no native mode RESET vector, since RESET sets the e flag).

I'm well aware of this.

I figured you were, but I thought I'd point it out for the benefit of other readers.

[kc5tja]

dclxvi wrote:

By the way, you never initialize PacketReceived+1 so it can overrun the first time (since you're using ORA PacketRecieved+1). Even if it is zero the first time, it'll be non-zero after the DEC PacketRecieved+1, so it would overrun if there were a second time (interrupts are disabled -- assuming STI is an alternate name for SEI, didn't you have problems with your assembler not generating code when you used TAS instead of TCS? -- and EchoPacket never exits)

Damn, you're right. Thanks for the sharp eyes.

Quote:

Speaking of EchoPacket, note that with the current order of instructions, replacing the JMP with an RTS (if you wanted a single pulse on the E pin)

No, I wanted a pulse stream. My oscilloscope is the only tool I have to determine what is going on inside the head of the Kestrel. This tells me that everything is done right. If I see a pulse-stream on the E pin, I just reboot and test again, or advance to the next problem and re-upload the software after implementing new code. Either way, the CPU is reset.

Quote:

will leave the processor in emulation mode. Anyway, you may want to have the native and emulation mode IRQ routines be at least slightly different so you can distinguish between the two as you're debugging.

If you look at the schematics for the Kestrel, you'll see that RAM is from $8000-$FFFF, and I/O is from $0000-$7FFF. I do this because it allows me to use a single 7400 chip for address decoding (I'm amazed it works as well as it does! ). Therefore, emulation mode is fundamentally incompatible with the Kestrel's hardware. Consequently, it'll never run in emulation mode, except while booting.

[dclxvi]

kc5tja wrote:

No, I wanted a pulse stream.

I was just thinking there might be some future use for one E pin pulse in EchoPacket (e.g. to trigger a scope or something), and noticed its current instruction order was backward for that purpose.

kc5tja wrote:

Consequently, it'll never run in emulation mode, except while booting.

I was thinking of when it's in emulation mode inadvertently. This can be more difficult to detect when both IRQ vectors head to the same place. Adding some delays to the E pin toggling would give you a different frequency, or something along the lines of:

Code: Select all

ORG $8000
JMP $F000
ORG $F000
JMP $8000

would (continuously) toggle A14 and leave A15 high, which would be relatively easy to look for. Then you'd know if the IRQ occured in emulation mode unexpectedly. It'd at least give you some idea if your program was close to working or had gotten way off course somehow.

[kc5tja]

Well, I fixed the source code according to the help given above, and I'm happy to say that it almost worked verbatim. It sometimes would work, and other times not.

After reviewing the code for another several iterations, I realized, "Duhh, moron, you're not initializing the PCR!!"



So once I got that done, everything *seems* to be working as expected.

Thanks for the help!

[ghaytack]

Hmmm I've been caught out by not intitializing the PCR properly on my first home built 6502 SBC some years ago. All it did was a interrupt driven "running LED" thing. Everything was (amazingly) working fine until I put my hand close to it. Then it went bezerk!

I hadn't set up the PCR properly and was getting spurious interrupts from CA1/CA2 caused by mains pickup from my hand 6" away from the board!

That took some head-scratching to find! The moral : if you're not using it, disable it!

Not as embarrasing as on a 6502 based on-board vehicle weighing system I was working on in the late 80's (some company called WeightWise if I remember, long since defunct).

Made some minor code chages and the system started going mental at switch on. I spent 4 HOURS! pouring over listings trying to find where I'd screwed up. Then it twigged. The listing I'd spent so long staring at was from the assember pass BEFORE I made the changes (stupid or what!). As soon as I looked at the assembly LST file for what was actually in the EPROM I spotted it!

The thing used a set of FP constants held in ASCI which it converted to BCD floating point at start-up (various vehicle measurements like wheel-base, gross vehicle weight etc). I'd accidentally deleted the string terminator for one of them so the conversion routine was just converting rubbish. As soon as the FP calcs kicked in they were also then working on complete garbage and producing the mandatory garbage on the 7-seg display!

One lives and learns! (politicians excepted)

[GARTHWILSON]

If the reset signal gets to the VIA, you don't have to write to every register to initialize it. I've used the 65c22 for so many things over the years, and never had any trouble from not writing to the PCR if I wasn't planning to use the CA1/CA2/CB1/CB2 lines. In fact one of our products flying in aircraft all over the world for the last 11 years uses a VIA, and nowhere does my code ever write to the PCR. Yet it has worked flawlessly.

What I'm still wondering though is why Samuel's circuit was producing an interrupt every 5 clocks. It certainly wasn't getting serviced that quickly and consistently, and the VIA will hold the IRQ\ line low until you go through the motions to clear the interrupt condition.

[kc5tja]

Well, remember, I'm *using* interrupts here. And I DID enable the interrupt. I just didn't initialize the PCR first.

Garth, I have no idea. It's still a mystery to me.

But I've certified at this point that the PC parallel port is a piece of $#!+ and utterly useless. Either that, or I blew it trying to get it to work with the Kestrel. Either way, it's ONCE AGAIN unable identify pulses from the Kestrel. With no explanation. (Since it never really worked right from the get-go, I'm inclined to believe the port was already b0rked from the get-go.)

For this reason, the Kestrel 1 is hereby declared a "finished" design, and I'll do a very, very quick and dirty PCB layout for anyone who wants to try building one with a PCB. I've already verified that it boots, and runs perfectly. I've bit-banged, I've interrupted, and even timed. It works. I'm done with it. I'm giving up trying to use it to talk to the PC, though.

The next Kestrel will be substantially improved over the Kestrel 1 anyway. 64K of RAM (maybe more; I haven't yet decided). A real EEPROM to boot from (IPLing is *nice* to have, but man, having a real EEPROM to boot from is nicer). An I/O space from $0000-$0FFF or $E000-$EFFF (I've been thinking of using the CPU's E output to determine I/O location. But, it's probably better to have it be programmable using one of the VIA's output pins). Speaking of VIAs, there will be at least two, not one. And, for host communications, an FTDI-based USB-to-FIFO interface module (DLP sells one for $25 that looks perfect for what I'm trying to use it for. Drivers are readily available for Windows, and they're actually integrated into Linux's source tree, so I rank this is highly compatible). There is a strong, strong possibility that it will also have its own PS/2 ports for the keyboard and mouse too. MMC support for removable, mass storage. If I had a readily available method of producing 640x480 video (even monochrome), I'd have it.

As independent from the PC as possible. That is my goal.

I'm sick of spending 4 weeks on something, making measurable progress along each step of the way, only to have everything come tumbling down again due to the alignment of the planets. I've had it.

[wirehead]

kc5tja wrote:

The next Kestrel will be substantially improved over the Kestrel 1 anyway. 64K of RAM (maybe more; I haven't yet decided). A real EEPROM to boot from (IPLing is *nice* to have, but man, having a real EEPROM to boot from is nicer). An I/O space from $0000-$0FFF or $E000-$EFFF (I've been thinking of using the CPU's E output to determine I/O location. But, it's probably better to have it be programmable using one of the VIA's output pins). Speaking of VIAs, there will be at least two, not one. And, for host communications, an FTDI-based USB-to-FIFO interface module (DLP sells one for $25 that looks perfect for what I'm trying to use it for. Drivers are readily available for Windows, and they're actually integrated into Linux's source tree, so I rank this is highly compatible). There is a strong, strong possibility that it will also have its own PS/2 ports for the keyboard and mouse too. MMC support for removable, mass storage. If I had a readily available method of producing 640x480 video (even monochrome), I'd have it.

Delcom can do it, ready with Linux drivers, for $11.60.

I've been spending a lot of time thinking about 640x480 monochrome. I'm pretty sure that with a mild leap of complexity over Daryl's LCD controller, you could do 640x480 monochrome. And you can sometimes find surplus LCD displays for reasonable amounts of money.... you'd either have to try to get it to work on the ATmega8515 with an external 64k SRAM chip, or just control an external SRAM with the memory pins. But since the LCDs generally take 4-8 bits at a time, you are going to have a much easier time than trying to control a VGA monitor.

[8BIT]

wirehead wrote:

I've been spending a lot of time thinking about 640x480 monochrome. I'm pretty sure that with a mild leap of complexity over Daryl's LCD controller, you could do 640x480 monochrome. And you can sometimes find surplus LCD displays for reasonable amounts of money.... you'd either have to try to get it to work on the ATmega8515 with an external 64k SRAM chip, or just control an external SRAM with the memory pins. But since the LCDs generally take 4-8 bits at a time, you are going to have a much easier time than trying to control a VGA monitor.

I am currently working on a 320x200 (or 320x240) color display that will work on a standard PC monitor. It will support 16 colors and be graphical with built in font support. Its in the design stages currently.

I have built a Compact Flash interface using an AVR and am working on converting some C Code to assembly. It will support the FAT file system so the CF cards can be interchanged from SBC to PC.

Also have an ethernet design on the books, working from an RT8019AS at 10MB speed.

Progress is slow as I cannot seem to find the time these days to work on it as much as I'd like.

Daryl

[kc5tja]

wirehead wrote:

Delcom can do it, ready with Linux drivers, for $11.60.

I'm not sure how those would benefit my project. I'm looking for a byte-pipe, not a bit-bang solution. The FTDI chipset solutions are perfectly suited for what I'm looking for.

Those bit-bang solutions might be good for something like in-circuit programming or whatever. But again, the FT245BM chips offer those too.

The $25 price tag I quoted was a module, not the chip. The module fits a bone-stock 28-pin DIP socket, and includes the clock oscillator and so forth. The FT245BM chip is only available surface mount, and at this time, I have no desire to work with surface mount components. I just don't trust them.

Quote:

control an external SRAM with the memory pins. But since the LCDs generally take 4-8 bits at a time, you are going to have a much easier time than trying to control a VGA monitor.

Actually, controlling a VGA monitor appears to be pretty trivial. You have three analog inputs for R, G, and B, and two TTL-compatible sync inputs. That's it. What can be easier?

I have heard over and over that controlling a VGA monitor is somehow more complex than driving an LCD interface. I have yet to see concrete proof of this. Moreover, all the *cheap* displays take analog input, not digital. I remember pricing out an LCD 640x480 display, and for the same price, I can get a smallish flat-panel that does color from PC Club that does 800x600.

The most difficult part of hooking a custom circuit up to a VGA monitor is the high-density DB15 connector. Those suckers are *mad* expensive. It's actually cheaper to purchase a VGA monitor extension cable and hack off one of the ends and use that to couple to the monitor.

[GARTHWILSON]

> I have no desire to work with surface mount components.
> I just don't trust them.

Actually, they're surprisingly easy to solder by hand. I take it what you don't trust is your handling and soldering of them. They are a bit intimidating at first.

> The most difficult part of hooking a custom circuit up to a VGA monitor
> is the high-density DB15 connector. Those suckers are *mad*
> expensive. It's actually cheaper to purchase a VGA monitor extension
> cable and hack off one of the ends and use that to couple to the
> monitor.

Here's a 15-pin high-density male DB-15 with solder cups at Jameco:
http://www.jameco.com/webapp/wcs/stores ... ctId=15077
The $.69 in singles seems to be pretty run-of-the-mill.