6502.org

Posted: **Tue Nov 09, 2021 9:35 am**

On the subject of the instruction stream, you'll also need to deal with the fact that the reset process itself is a pseudo-interrupt which will read (and discard) a certain number of bytes before it gets to reading the reset vector. It may be that those reads will all fall outside the FT245 area, in which case no problem, but I suspect that is not the case - however I cannot remember the exact details off hand. There is a thread here on 6502.org somewhere where someone did some research into exactly what happens during reset, so that'll be worth a read.

Posted: **Tue Nov 09, 2021 9:45 am**

Hi Bill (plasmo) and gang:

Seems you're attempting a type of "blind interface" with the FT245? Not sure if this will help but here's a few basic microcontroller "blind interface" functions where the microcontroller controls the clock, memory, and reset on the 6502 system and uses push() and pull() clock cycle functions to convey instructions and data to/from the 6502 over the data bus;

Code: Select all

  void cpu_reset();                 // **************************************
  { reset_pin = 0;                  //  R65C02 reset sequence               *
    pull();                         //                                      *
    pull();                         //                                      *
    reset_pin = 1;                  //                                      *
    pull();                         //                                      *
    pull();                         //                                      *
    pull();                         //                                      *
    pull();                         //                                      *
    pull();                         //                                      *
    push(0x00);                     //  FFFC:00 reset vector lo             *
    push(0xC0);                     //  FFFD:C0 reset vector hi             *
  }                                 // **************************************

  void Wr_Byte(u16 addr, u8 data)   // **************************************
  { push(0xA9);                     //  lda <imm>                           *
    push(data);                     //   "                                  *
    push(0x8D);                     //  sta <abs>                           *
    push(addr.lo);                  //   "           abs address lo         *
    push(addr.hi);                  //   "           abs address hi         *
    pull();                         //   "           6502 write op          *
  }                                 // **************************************

  byte Rd_Byte(u16 addr)            // **************************************
  { push(0x4C);                     //  jmp <abs>    avoid page boundary    *
    push(0x00);                     //   "           abs address lo         *
    push(0xC0);                     //   "           abs address hi         *
    push(0xAD);                     //  lda <abs>                           *
    push(addr.lo);                  //   "           abs address lo         *
    push(addr.hi);                  //   "           abs address hi         *
    return pull();                  //   "           return value on bus    *
  }                                 // **************************************

Basically, a pull() clock cycle turns memory on for a 6502 memory read or write operation while a push() clock cycle turns memory off and allows the microcontroller to supply an instruction or data to the 6502. A clock cycle always starts and ends in the high state. Of course after using the microcontroller & "blind interface" to load RAM or burn a Flash ROM via hex file or X-modem, it can completely disconnect from the 6502 system.

I've been trying to figure out how to implement something similar with the FT245 but "no joy", so far.

I won't bore you or other members with details unless you feel it may help...

Regards...

Posted: **Tue Nov 09, 2021 2:37 pm**

GARTHWILSON wrote:

WDC's 65816 data sheet has a table of exactly what's on the buses in every cycle of every instruction, and applies to the '02 as well, using footnotes to separate the various conditions.

Garth is referring to Table 5-7 in the '816 datasheet. But FWIW a less confusing introduction to the topic of cycle-by-cycle operation is Appendix A of the MOS MCS6500 Family Hardware Manual, simply because it doesn't include umpteen '816-specific footnotes. However, for the 'C02 the WDC doc should be your final authority. The NMOS '02 detailed in Appendix A has some very minor differences compared to the 'C02 (the most notable being that the NMOS '02 takes 5~ for opcode $6C, whereas the 'C02 takes 6).

Rule #1 of cycle-by-cycle operation is, every opcode fetch gets followed by another cycle that reads the byte at PC+1 (or the byte at PC is read again if an interrupt is being recognized). Reading the byte at PC+1 is somewhat of a shot in the dark, given that the opcode is still being decoded while the read occurs. But it's a good guess, because often the opcode will be followed by one or more operand bytes.

GARTHWILSON wrote:

Two-cycle instructions like TAX don't care what's on the data bus in the second cycle.

Yes. Although TAX is only a one-byte instruction, the byte at PC+1 is fetched anyway, then discarded.

Alarm Siren wrote:

On the subject of the instruction stream, you'll also need to deal with the fact that the reset process itself is a pseudo-interrupt which will read (and discard) a certain number of bytes before it gets to reading the reset vector.

Perhaps you can use the VPB pin as a reference, since it'll go low during the fetch of the Reset vector... which occurs after the hard-to-ascertain number of cycles.

-- Jeff

Posted: **Tue Nov 09, 2021 3:00 pm**

I breadboard up a FT245 and captured bootstrap program execution with logic analyzer. I used 6502's SYNC output as the reference. I see some noisy signals around the reset that can cause extra read of FT245 FIFO and throw it out of synchronization. This may be an artifact of my breadboard, but to work around that I use a sequence of NOP (0xEA) followed by an illegal instruction 0x3 prior to normal program. This way the reset vector is at 0xEAEA which is still within the memory region of FT245. The illegal instruction 0x3 will execute in one clock so if the instruction stream is offset by one byte due to spurious read, it will realign and fetch the correct instruction after the illegal instruction.

I also use the illegal instruction 0x3 as padding. I find the single byte instruction, INX, needs padding, but STA addr,x instruction does not need padding. Here is a simple program that successfully assembles a "NOP, NOP, JUMP to NOP" loop in RAM and jump into RAM to execute it.
Bill

Code: Select all

; 11/8/21
;Instructions to be loaded into FT245 that assembles
;toNOP:
;  NOP
;  NOP
;  JMP toNOP
; in RAM and execute it
;STA index by X does not need dummy pad
;INX does need dummy pad
;RAM from 0x8000- 0xBFFF
;FT245 from 0xC000-0xFFFF

	.pc02

	.org $c000		;FT245 occupies space from 0xc000-0xffff
	NOP			;reset vector plus extra padding
	NOP
	NOP
	NOP
	NOP
	.byte 3			;illegal instruction executed in 1 cycle
				;for synchronization purpose
	LDA #$ea		;NOP instruction
	LDX #0
	STA $8000,x		;put a small program in RAM
	INX
	.byte 3			; dummy instruction for two-cycle INX execution
	STA $8000,x
	INX
	.byte 3
	LDA #$4c		;JMP instruction
	STA $8000,x
	INX
	.byte 3
	LDA #0
	STA $8000,x
	INX
	.byte 3
	LDA #$80
	STA $8000,x
	JMP $8000
	JMP $8000

Posted: **Tue Nov 09, 2021 4:18 pm**

Dr Jefyll wrote:

GARTHWILSON wrote:

WDC's 65816 data sheet has a table of exactly what's on the buses in every cycle of every instruction, and applies to the '02 as well, using footnotes to separate the various conditions.

Garth is referring to Table 5-7 in the '816 datasheet. But FWIW a less confusing introduction to the topic of cycle-by-cycle operation is Appendix A of the MOS MCS6500 Family Hardware Manual, simply because it doesn't include umpteen '816-specific footnotes. However, for the 'C02 the WDC doc should be your final authority.

Page 32 of the attached details the 65C02's behavior.

65c02_2000.pdf: 65C02 Data Sheet (published 2000/03/06); (492.05 KiB) Downloaded 66 times

Posted: **Wed Nov 10, 2021 10:28 am**

plasmo wrote:

I breadboard up a FT245 and captured bootstrap program execution with logic analyzer.

I'd love to understand how this works, Bill. May I ask if you send one character to the FT245 for each 6502 clock cycle? For example, what characters do you send for the STA abs,x instruction which is 3 bytes and 5 clock cycles ? My microcontroller "blind interface" method would account for all 5 clock cycles like this;

Code: Select all

    push(0x9D);         //  sta %8000,x
    push(0x00);         //   "    
    push(0x80);         //   "   
    pull();             //   "
    pull();             //   "

TIA. Mike

Posted: **Wed Nov 10, 2021 2:16 pm**

6502's clock is 7.37MHz, but the RDY input of 6502 is connected to the invert of FT245's RXF#, so it is single-stepping each data provided by FT245. The data sequence for "STA $8000,X" is "0x9D 0x00 0x80" The two other cycles are in $8000 memory region so do not generate read pulses to FT245.

Instead of understanding many different instructions' cycle-by-cycle characteristic, I focus on few instructions like "STA abs,X", "INX", "LDA #imm", and "JMP abs" to build a simple bootloader program in RAM and then jump into RAM to load bigger and better loader that loads the application software.
Bill

Posted: **Thu Nov 11, 2021 2:22 am**

plasmo wrote:

6502's clock is 7.37MHz, but the RDY input of 6502 is connected to the invert of FT245's RXF#, so it is single-stepping each data provided by FT245. The data sequence for "STA $8000,X" is "0x9D 0x00 0x80" The two other cycles are in $8000 memory region so do not generate read pulses to FT245.

Instead of understanding many different instructions' cycle-by-cycle characteristic, I focus on few instructions like "STA abs,X", "INX", "LDA #imm", and "JMP abs" to build a simple bootloader program in RAM and then jump into RAM to load bigger and better loader that loads the application software.
Bill

(1) /RXF starts out high which takes 6502 RDY low.
(2) Send character to FT245. /RXF goes low to indicate RX char available which takes RDY high.
(3) 6502 reads character from FT245. /RXF goes high after reading the character which takes RDY low again.

I can see how sending 0x9D, 0x00, and 0x80 to the FT245 are accepted by the 6502 but after sending the 0x80 the 6502 RDY is low again. Don't you need to send another character to the FT245 to make /RXF low and take RDY high to allow the 6502 to perform the next clock cycle of the STA $8000,X instruction?

Posted: **Thu Nov 11, 2021 2:53 am**

Hey guys... Is it correct that the STA abs,x instruction is 4 cycles on the W65C02 and 5 cycles on the R65C02 & G65SC02?

Posted: **Thu Nov 11, 2021 3:36 am**

If you're in full control of the data bus, why not get rid of indexed addressing altogether and just feed the ascending absolute addresses yourself? I know they're four cycles ...

Posted: **Thu Nov 11, 2021 3:51 am**

Quote:

Hey guys... Is it correct that the STA abs,x instruction is 4 cycles on the W65C02 and 5 cycles on the R65C02 & G65SC02?

I'm looking at a WDC datasheet that says sta abs,x is 5 cycles. But the date on the datasheet is March 6, 20000, so maybe it'll be 17,979 years before the info becomes valid!

What causes you to suspect the WDC chip takes 4 cycles, Michael? I'm not able to run a test ATM, but I'd be astonished to learn of a timing difference between the WDC and Rockwell C02's. I've successfully used both in my KK Computer, whose external circuitry is timing-sensitive in a way that'd almost certainly make any timing discrepancy inescapably obvious.

-- Jeff
Edit: oops, you asked about W65C02, and my datasheet pertains to W65C02S.

PS- good point, Mike B.

Posted: **Thu Nov 11, 2021 4:09 am**

Table 4-1 of the 2/25/20 data sheet says the abs,X addressing mode takes 4 cycles, with footnotes saying, "add 1 cycle if page boundary is crossed when forming address. Add 1 cycle for STA abs,X regardless of boundary crossing," and "Read-Modify-Write, add 2 cycles" (obviously not applying to STA). My Rockwell, Synertek, and GTE Microcircuits books all say 5 also, with no footnotes about adding a cycle for page boundary crossing.

Posted: **Thu Nov 11, 2021 5:12 am**

Michael wrote:

I can see how sending 0x9D, 0x00, and 0x80 to the FT245 are accepted by the 6502 but after sending the 0x80 the 6502 RDY is low again. Don't you need to send another character to the FT245 to make /RXF low and take RDY high to allow the 6502 to perform the next clock cycle of the STA $8000,X instruction?

Yes, the circuit requires /RXF low to run so it will run as soon as FT245 received a byte and will stop as soon as the last byte is read out of FT245's FIFO. For the program to run freely, it need to have an extra data in the receive buffer of FT245.

Received my PC boards from JLCPCB this afternoon (5-day turn around!) and built up a Prog65. I've already found a mistake that requires adding a 74LS10 in the prototype area. Right now it can receive bootstrap program from FT245 and execute simple program in RAM but having problem putting data out on FT245. Picture of it on my bench; putting all 16 channels of logic analyzer plus 2 channel of analog scopes to work, it looks like an open-heart surgery...
Bill

Posted: **Thu Nov 11, 2021 9:46 am**

plasmo wrote:

Received my PC boards from JLCPCB this afternoon (5-day turn around!) and built up a Prog65. I've already found a mistake that requires adding a 74LS10 in the prototype area. Right now it can receive bootstrap program from FT245 and execute simple program in RAM but having problem putting data out on FT245.

One little gotcha with these FT24x chips is that, while the RD strobe is active low, the WR strobe is active high. I almost got burnt by that one but caught it in a final check just before I sent the PCB for fabrication.

Posted: **Thu Nov 11, 2021 10:28 am**

plasmo wrote:

Michael wrote:

I can see how sending 0x9D, 0x00, and 0x80 to the FT245 are accepted by the 6502 but after sending the 0x80 the 6502 RDY is low again. Don't you need to send another character to the FT245 to make /RXF low and take RDY high to allow the 6502 to perform the next clock cycle of the STA $8000,X instruction?

Yes, the circuit requires /RXF low to run so it will run as soon as FT245 received a byte and will stop as soon as the last byte is read out of FT245's FIFO. For the program to run freely, it need to have an extra data in the receive buffer of FT245.

Ok, again, what characters did you send (0x9D, 0x00, 0x80, 0x??, 0x??) for the STA $8000,x instruction, please?

Since the fifth clock cycle of that STA $8000,x instruction is a 6502 write operation to $8000+x, how does the FT245 reset its /RXF flag? The FT245 won't get a /RD strobe from the 6502 for that fifth instruction clock cycle if the 6502 is writing to $8000+x so /RXF won't get reset high and RDY won't go low. That fifth character that initiated the fifth instruction clock cycle is still sitting in the FT245 unread.

Thank you for your patience. Mike

<added>

ok, wait a minute. after the 6502 performs the write clock cycle to $8000+x it will go back to read at PC in the FT245 region during the next clock cycle and that's when it will read that fifth character from the FT245. So that fifth character could actually be the opcode portion of the next instruction you'd like to send to the 6502. very cool!

6502.org

Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer

Re: Design challenge: 6502-based EPROM programmer