6502 Design & concept questions.

[GARTHWILSON]

If I understand the data sheet correctly, IC3B needs to be an OR gate (not AND), because RAM will hold op codes, operands, and data.

If it makes your wiring or board layout easier, remember you can mix up the address lines to the RAM, and you can mix up the data lines to the RAM. (Don't do it with the ROM unless you also make a programming adapter or write a program to mix up the hex file for programming accordingly.)

[ElEctric_EyE]

GARTHWILSON wrote:

... remember you can mix up the address lines to the RAM, and you can mix up the data lines to the RAM. (Don't do it with the ROM unless you also make a programming adapter or write a program to mix up the hex file for programming accordingly.)

This is true. A certain "newer" style Synchronous RAM I use in a project doesn't even have the address or data pins numbered on the datasheet. Except A0 and A1 which is used for the internal burst R/W function.

[lordbubsy]

BigEd wrote:

We have debated VPA and VDA before... You very probably don't need them...

Hmm, I noticed in Daryl’s SBC3 that VPA and VDA weren’t connected at all. Could you point me to that discussion? I’m not sure whether I leave VPA and VDA out or not. Let’s first see how dense it gets.

GARTHWILSON wrote:

If I understand the data sheet correctly, IC3B needs to be an OR gate (not AND), because RAM will hold op codes, operands, and data.

If course, you’re right. IC3A should be AND and IC3B should be OR. Forgive my rookieness.

Quote:

If it makes your wiring or board layout easier you can mix up the address ... data lines to the RAM.

thanks for the reminder, I’m beginning to feel quite anxious about that. It’s getting big.

I’d like to choose one of the VIA ports as a configuration register. I want to take the port with lesser value. Which one could I use?

[GARTHWILSON]

lordbubsy wrote:

I’d like to choose one of the VIA ports as a configuration register. I want to take the port with lesser value. Which one could I use?

I'm not sure what you mean by "configuration register," but I view PA as having slightly less value than PB (because of capabilities).

[BigEd]

lordbubsy wrote:

BigEd wrote:

We have debated VPA and VDA before... You very probably don't need them...

Hmm, I noticed in Daryl’s SBC3 that VPA and VDA weren’t connected at all. Could you point me to that discussion?

We've revisited this several times, because BDD keeps bringing up the same advice (which indeed he genuinely thinks of as helpful) but several other experienced people sometimes take the time to point out that it's a judgement call depending on the situation.

Here are some pointers:
viewtopic.php?p=24907#p24907 - BDD says what happened. He's using an indexed addressing mode, and a DUART which can't handle two accesses in rapid succession.
viewtopic.php?p=9755#p9755 - the original discovery, with some helpful suggestions.
viewtopic.php?p=11901#p11901 - Garth points out that the only extraneous accesses you get when you don't qualify with VPA and VDA will be reads, and of predictable locations.

No-one is doubting that BDD had a bug which took some effort to track down. The idea that others are likely to hit the same problem is, I think, far-fetched. Certainly there's nothing mysterious happening, and it's not bad for a 6502 circuit designer to have an awareness of the stray read accesses.

Hope this helps
Ed

[lordbubsy]

GARTHWILSON wrote:

I'm not sure what you mean by "configuration register,"

I want to use that register to determine certain system settings.

At Startup I want to configure port A of VIA1 as output. The bits 0-5 are connected to an AVR. The AVR scans those bits continuously.

The AVR is also connected to the Flash memory’s A14, A15 and A16. Which selects the ROM bank.

Bit 3 enables or prohibits writing to flash. I added also a jumper as you suggested. Bit 4 and 5 determines the clock speed which is provided by the AVR. It will give the following frequencies:

Code: Select all

00 14,7456
01  7,3728
10  3,6864
11  1,8432

They go through a 74AC74 and the system can run on those frequencies, divided by two:

Code: Select all

00 7,3728
01 3,6864
10 1,8432
11 0,9216

According to your RS-232 primer, the 6551 could accommodate a baud rate of 115200 with a PHI2 of 7,3728 MHz.


In the meanwhile, before I get my WDC parts, I’m going to make a simplified version on PCB. Just for practicing. I need a simpler version, the PCB gets too crowded.

BigEd wrote:

The idea that others are likely to hit the same problem is, think, far-fetched.

so I could leave them unconnected without harm. But I’ll read those topics anyway.

[BigDumbDinosaur]

lordbubsy wrote:

According to your RS-232 primer, the 6551 could accommodate a baud rate of 115200 with a PHI2 of 7,3728 MHz.

In theory, that is correct. In practice, trying to run the 65C51 that fast will likely pose some problems. Specifically, you will need to account for how well you will be able to service the resulting interrupt flood.

A continuous 115.2Kbps data stream in 8N1 format will generate 11,520 interrupts per second (an IRQ every 87 microseconds), one for each byte that has been deserialized and buffered in the 65C51's one-byte receiver holding register (RHR). The catch is that if the previous byte in the RHR has not been read by the time another byte arrives and is deserialized, the new byte will be lost and your data stream will be corrupted. Therefore, it is incumbent on your system to react without delay to a 65C51 IRQ and get that byte out of the RHR before the next one is due to arrive.

This characteristic of the 65C51 (and the Motorola 6850) is one of several reasons why I went with the 2692. The 2692's RHR is actually a FIFO that is four bytes deep (eight bytes with the 26C92), so small delays in servicing receive interrupts are tolerable. They won't be readily tolerated with the 65C51 at the speeds you may be contemplating.

[GARTHWILSON]

Quote:

A continuous 115.2Kbps data stream in 8N1 format will generate 11,520 interrupts per second (an IRQ every 87 microseconds)

which at 7.3728MHz is one interrupt approximately every 160 instructions (or 640 cycles) which is quite doable if your ISR is efficient and not wasteful like many I've seen in books. The routine in the interrupts primer will take around one-sixth of the processor time at that rate, although it would be a little more if it has to poll for a couple of other possible interrupt sources too. Cycle-counting is always important if there's any chance you could be pushing the limits. In this case, the cycle-counting says we're pretty safe if other interrupts are not making like difficult. Obviously they have to be taken into consideration too. If the processor can service this one with room to spare but the the background program can't keep up, it will hit the

Code: Select all

         LDA  #1          ; Else, tell the other end to stop sending data before
         STA  ACIA_COMM   ; the buffer overflows, by storing 1 in the ACIA's
                          ; command register.

portion which will prevent overflows.

I've designed a few commercial products where the main critical job was in the ISR and it took 80% of the processor time, and every time I see I need to change it in the development process, I have to re-count cycles and check what the worst-case senario is. If it gets tight, there have always been several ways to remedy it without starting over with a more-powerful processor.

[BigEd]

What's more, the status register has an overrun bit which would tell you if you'd failed to service in time.

[Arlet]

Note that you don't have to use interrupts to handle the ACIA. In cases where you need to transfer a lot of data, e.g. a bootloader, the CPU can sit in a tight loop polling for data, and writing it to memory.

[GARTHWILSON]

True, although that would be for the limited use of just transferring data into memory and not actually processing it on the fly.

• You would gain a small amount of speed by the fact that you don't have to keep checking to see if the background program is keeping up and thus deciding whether or not to tell the other end to pause
• and you would gain a small amount by eliminating the interrupt overhead (which again can be small, unlike so many ISRs I've seen in books)
• but then you would need to increment a two-byte indirect pointer to where you're filling memory, losing a little performance,
• and compare to the final 16-bit address to know when to quit, again losing a little performance;

Here's a sample routine:

Code: Select all

; (2-byte variables in ZP:)
POINTER:  DFS  2
END_ADR:  DFS  2

    BEGIN
        LDA  POINTER            ; Has the low byte of the pointer reached
        CMP  END_ADR            ; the low byte of the ending address?
        IF_EQ                   ; If they match,
            LDA  POINTER + 1    ; go on to compare
            CMP  END_ADR + 1    ; the high byte also.
        END_IF                  ; (Actually, 16-bit comparisons could be made a macro also, cutting out 5 lines of source code.)

    WHILE_NEQ                   ; As long as they don't both match, go for another byte.  Otherwise, exit the program structure.
        BEGIN
            LDA  ACIA_STAT      ; Read the status register
        UNTIL_NEG               ; until it says there's a chage of status (indicated by bit 7).

        AND  #00000111B         ; Check the overrun, framing, and parity error bits (overrun should always be fine in this case)
        BNE  REPORT_ERR         ; and handle errors.  Normally, this branch will never be needed.

        LDA  ACIA_DATA          ; Get the data byte that just came in, and
        STA  (POINTER)          ; store it.  (NMOS 6502 must use Y here, previously loaded with 0.)

        INC  POINTER            ; Now we have to increment the 16-bit pointer, low byte first,
        IF_EQ                   ; and if it rolled over to 00,
            INC  POINTER + 1    ; increment the high byte too.
        END_IF
    REPEAT                      ; Then go back up to see if there's another byte, and if so, to get it.

which assembles:

Code: Select all

                        ; cycles
 top: LDA  POINTER      ;   3
      CMP  END_ADR      ;   3
      BNE  1$           ;   3  usually
      LDA  POINTER+1    ;   3 (usually not taken)
      CMP  END_ADR+1    ;   3 (usually not taken)
 1$:  BEQ  end          ;   2  usually
 2$:  LDA  ACIA_STAT    ;   4
      BPL  2$           ;   2  if we're going as fast as possible
      AND  #00000111B   ;   2
      BNE  REPORT_ERR   ;   2  normally
      LDA  ACIA_DATA    ;   4
      STA  (POINTER)    ;   5
      INC  POINTER      ;   5
      BNE  3$           ;   3  usually (but this could BRA directly to top)
      INC  POINTER+1    ;   5 (usually not taken)
 3$:  BRA  top          ;   3  normally
 end:

which is 41 clocks per byte, so at 7.3728MHz, you could go about 1.8 Mbps. The ISR posted in the interrupts primer could only go about 750kbps, but it's kind of an apples-to-oranges comparison because of the ring buffer. We could re-write the ISR this way (which still does not take into account any other interrupt sources):

Code: Select all

ISR: PHA
     PHX
     LDA  ACIA_STAT
     IF_MINUS
         AND  #00000111B
         BNE  REPORT_ERR

         LDA  ACIA_DATA
         STA  (POINTER)

         INC  POINTER            ; Now we have to increment the 16-bit pointer, low byte first,
         IF_EQ                   ; and if it rolled over to 00,
             INC  POINTER + 1    ; increment the high byte too.
         END_IF                  ; (Actually 16-bit increments could be made a macro too, cutting out 3 lines of source code.)
     END_IF
     PLX
     PLA
     RTI

which assembles

Code: Select all

                       ;   7 (for the interrupt sequence)
ISR: PHA               ;   3
     PHX               ;   3
     LDA  ACIA_STAT    ;   4
     BPL  1$           ;   2  usually
     AND  #00000111B   ;   2
     BNE  REPORT_ERR   ;   2  usually
     LDA  ACIA_DATA    ;   4
     STA  (POINTER)    ;   5
     INC  POINTER      ;   5
     BNE  1$           ;   3  usually
     INC  POINTER+1    ;   5 (usually not taken)
 1$: PLX               ;   4
     PLA               ;   4
     RTI               ;   6

which comes to 54 clocks per byte, which, at 7.3728MHz, would allow up to about 1.3 Mbps, but the background routine (which basically gets no processor time at 1.3 Mbps) has to watch for when the store pointer matches the end address.

Hopefully I didn't do this so quickly so as to have a dumb mistake like I did on my recent post about indexed table jumps which I had to go back and correct.

[Arlet]

Of course, in practical applications, the ISR is fixed, and needs to check for multiple interrupt sources, which includes at least the transmit side of the UART. While you're in tight polling loop downloading data, you know you aren't transmitting, so there's no need to check it.

Also, in the polling loop, maybe you know you only need to receive < 256 bytes in a burst, so you could use absolute indexed addressing.

[GARTHWILSON]

and another thing I forgot to say is that of course the ACIA won't go 1.8Mbps.

I don't know that I've ever had more than two or three IRQ sources enabled at once; but I have routines to modify the ISR so it doesn't have to check all the possible sources that are not even enabled.

[Arlet]

True. So, at least we can confirm that 115200 is possible, as long as you're a bit careful with the software. Having the hardware option to enable that speed is useful, and for applications that don't need 115200, you can easily divide it down to a slower rate.

[lordbubsy]

OK, I’ve made a simplified schematic and replaced the WDC’s for NMOS IC’s.
I hope there aren’t too many errors and loose ends?
If all is OK, I’d like to place the components on the board.

By placing them I look for the air wires the least tangled up and as short as I can.
My question is how do I place the components optimally?

I zipped all the files for compactness.