Can you let me know your thinking behind the preference? The Hirose connector is around 7cm long... Reasonably similar to the DIP, so as I'm planning on simplest signal routing, it'll actually be both simpler with a DIP and it will make for a shallower board (as the PLCC is wider than the DIP).

I'm off on vacation soon, but once I'm back I'll order the parts. In the mean time I've created a connector model for Eagle CAD. I realized that it's not clear to me how the pins from the Digilent side of the connector map to the ones on the 6502 side, so I'll get the parts and figure it out using a meter before I draw the PCB (measure twice, cut once... I'm in no hurry).

This will be my first attempt at building a board, so I'll see how I get on with OSH Park. This thing is so simple even I can't mess it up (challenge accepted!). But as long as I don't do something extraordinarily stupid, like short the FPGA board, I should at least be able to get some life out of the processor... Even if it's just fetching NOPs.

There are pros and cons, so if you prefer DIP then that's probably enough to tip the balance. PLCC uses less board area and has better ground and Vcc connections. But the latter point is diluted somewhat if the PLCC is socketed.

Unless you need the speed, you might want to consider using a 65C02 other than the modern WDC product. The WDC have significantly faster slew rate on their outputs compared to, say, a Rockwell. Also the Rockwell offers less drive current, and that's an advantage should you ever stumble into a situation where a 'C02 output is in contention with an FPGA output.

Edit: another option is to use the WDC CPU but allow space on your PCB for a SMD series resistor on every pin capable of being an output.

We'll be following your progress with interest... after your vacation. Hope it's a good one!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Nintendo's collision and sprite building routines spend more time pushing and pulling registers, and passing arguments then they do actually calculating collision detection and building sprites.

Is that from compiled C code though?

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

What you are describing is characteristic of the object output of a C compiler. When a function (subroutine) call is made in C, space is allocated on the stack for the variables that have been declared within that function. Hence significant stack activity is to be expected. In pure assembly language, there are more ways to structure functions, so the amount of stack activity will vary according to the programmer's preferences.

Until you have experience with MPUs that handle the stack in an adroit fashion, it may be difficult to see the advantages of using the stack as a scratchpad the way C does. The 65C816 makes this a relatively painless task, as the 16-bit stack pointer can be copied to and from the (16-bit) accumulator, making it easy to perform arithmetic on the stack pointer and thus allocate temporary stack workspace. This feature can be augmented by temporarily pointing direct (zero) page at the stack workspace, viz:

Code:

;stack workspace example
;
         rep #%00100000      ;16 bit .A
         cld                 ;ensure binary mode
         sec
         tsc                 ;copy stack pointer (SP) to .A
         sbc #size_of_ws     ;make room for workspace
         tcs                 ;set new SP
;
;   ——————————————————————————————————————————————————————————
;   At this point, SIZE_OF_WS bytes have been allocated on the
;   stack, the 1st byte being at SP+1.  We can make that work-
;   space become a fugacious direct page by setting the direct
;   page pointer (DP) to SP+1.
;   ——————————————————————————————————————————————————————————
;
         phd                 ;save current DP, SP = SP-2
         inc a               ;.A = .A+1, actually SP+3 at this point
         tcd                 ;copy to DP
;
;   —————————————————————————————————————————————————————————————
;   Now, DP points to the 1st byte of the workspace.  An instruc-
;   tion such as LDA $00 would actually fetch from SP+3, instead
;   of from the physical zero page.
;   —————————————————————————————————————————————————————————————
;
   ...program continues...
;
;   ——————————————————————————————————————————————————————————————————
;   When processing has been completed the workspace can be discarded.
;   ——————————————————————————————————————————————————————————————————
;
         pld                 ;restore previous DP value
         rep #%00100000      ;16 bit .A
         clc
         tsc                 ;current SP to .A
         adc #size_of_ws     ;get rid of workspace
         tcs                 ;set new SP
;
   ...program continues...

Note that in the above example, the addition and subtraction operations are working on 16-bit operands.

If the above code is being run on a system with a formal operating environment, caution must be exercised in handling direct page. For example, an interrupt handler would have to be careful to preserve DP, change it to point to the ISR's direct page, and then restore DP before returning to the foreground.

Similarly, if the function that pointed direct page to stack workspace calls another function, that called function must be aware of the state of DP so it doesn't accidentally "step" on the calling function's stack space by writing to what it thinks is the real direct page.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

If you are going to interface with any legacy 5V TTL, you *will* need level shifters. If you are truly going to run the 6502 at 3.3V, then the LVTTL or LVCMOS33 I/O types should work fine. Unless you have specific reasons to adjust the drive current, I would leave them at the defaults (which I think is 12). If it really bothers you, then maybe set the drive to 6 or 8. I'm not sure why you would want to drop it down to the minimum of 2?

For the long distance you may need an external buffer, but I would try it without one first and see how it goes. If you do need to drive the bus a long distance, you can look at something like the TI-99/4A computer's PEB expansion cable schematic. It is called the "fire hose" because it is the full system bus extended to about 4 feet or so, and is a really large flat cable.

Something else to note: while the Spartan 3E does have a lot of I/O options (that was the focus of the "E" version), it is becoming hard to source and *more* expensive as time goes on. Digikey still generally has them, but for the same $20 you will spend on something like the Spartan-3E 250K, you can get a Spartan-6 LX9 with double the capacity. The Spartan-6 also has flexible I/O, and a lot of new features that the Spartan-3E does not.

Anyway, just food for thought in case you are considering availability of parts at some point in the future. Even the Spartan-6 is starting to get replaced by the Spartan-7, but the costs are not quite equal yet.

By the way, that 100-pin HiRose connector sucks for the hobbyist. Digilent made a prototype expansion board with the mating connector, but I don't know if they still have it for sale.

Hmm, why do you say that? In one direction, the concern is whether parts are 5 tolerant, and in the other direction, the concern is whether a logic 1 is a sufficiently high voltage. If a signal is unidirectional, only one of these applies. Are you thinking of a very specific case? (For example, a clock input may need a very high logic 1, but any buffer would do the job. It's acting as a level shifter, but it needn't be a level shifter as such.)

That is true, 3.3V logic can normally drive the input of the 5V 74LSxxx logic that is typical in the retro computers we are usually dealing with. I have had situations where it has worked, worked but needed an in-line resistor (100ohms), and totally failed.

On the flip side, driving a 3.3V input from the 5V TTL side is risky. A 5V TTL logic high is usually around 3.4V to 3.6V, but it does not have to be. In most cases you might get away with it. In the worst case you will blow your FPGA or microcontroller inputs. If you are making a circuit that you plan to distribute or use for a long time, level shifting should be used. It is definitely a pain to deal with, but necessary if you want a reliable circuit (and don't want to pull your hair out trying to figure out what is wrong).

For a specific example, my F18A project has all 3 cases. All inputs from the host system to the FPGA are level shifted, but single direction outputs from the FPGA to the host are directly driven. The only exception is the output interrupt signal, which could not trigger the Z80 NMI input for some reason. I added a 100ohm series resistor to the interrupt output and it started working. That was a frustrating situation, and I'm still not happy with the "solution", since it still has a problem with certain games on European ColecoVision systems.

IMO, sadly, dual voltage level shifters are the only way to interface with the legacy 5V TTL.

Hi, matthew180. Issues of drive current and slew rate were discussed upthread. I wouldn't say we established that 12 mA is too much, but OTOH it's clear that 2 mA is certainly enough, and we're inclined to go with that because there's seemingly no downside and it might improve signal integrity. (Freedom from ringing is the main concern.) We also settled on the "Slow" slew rate setting for the same reason. Xilinx explicitly says to "use the slowest slew rate and lowest output drive current that meets the performance requirements for the end application."

You're saying the FPGA output was driving a Z80's NMI input (nothing else), and adding a 100 ohm series resistor improved matters!? Just checking the details in case I misunderstood. But this doesn't sound like any kind of DC phenomenon, as the inputs on MOS and CMOS chips are extremely high impedance, and an extra 100 ohms in series is nothing. But what does change is the AC behavior. It sounds as if you might've been dealing with a problem of ringing and/or overshoot/undershoot, and the added resistor acted as series termination which reduced transmission-line effects in your wiring. I could be wrong about that, but it's maybe worth considering. I'm also interested in the other F18A project signals you mentioned, but one thing at a time!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Correct, an output going from the FPGA directly to the Z80's NMI input, with no other connections, was not working. A 100ohm resistor in-line got it working. I went down a rabbit-hole on that one, and it was no fun. Very frustrating actually, especially since it seems to be cropping up again on specific hardware running specific games. I have no idea what that has to do with the physical wiring, which makes it even harder to comprehend. I put my scope on the line and could not detect any ringing, but measuring a signal always changes it too. I tried all the drive-current setting too, nothing changed. I even had a 74LS inverter in the mix at one point, and still had problems, but that test might have been messed up due to changing too many things at once, etc.

Basically my opinion is, when mixing voltages and technologies (CMOS to TTL, etc.), I have learned my lesson the hard are about not using proper level shifting. I'm sure there are easier ways to achieve this if you understand all the analog electronics at the low transistor levels in these chips (and I do to a certain amount, the theories anyway), but I don't want that complication. My solution for the NMI input problem does not make me happy, but the suggestion came from a friend of a friend who deals with that kind of stuff all the time. I tried the resistor and it "just worked".

Yes -- unfortunately true. (But even more unfortunate when one is unaware of this pitfall! )

Is there a Slew Rate setting on the FPGA you were using, and if so did you try the Slow setting? I'm also curious about wiring details -- how long the signal path was from the FPGA to the Z80, and what sort of conductor was used (eg: a simple wire, or a trace on a PCB? And if a trace, does the PCB have a Ground Plane?) Some photos would be especially helpful.

Connected in this fashion (where the destination device has a higher supply voltage), the 100 ohm series resistor in no way changes the signal levels. But I don't believe a level shifter is necessary or even desirable. As Ed already mentioned, the concern is whether a logic 1 is a sufficiently high voltage, and in this case (and many similar cases) you're probably in the clear. You need to check, but probably your Z80 accepts TTL levels on its inputs (most vintage MOS and CMOS CPU's do, excepting the Clock inputs in some cases). And the 3 volts or more which I expect you're getting from the FPGA is well above the threshold for a TTL "1."

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The FPGA is the Spartan-3E, and it does have the slew setting. I tried both fast and slow, did not help. The FPGA is on my F18A board, the trace is 8mil width and less than half an inch long. The particular system where it has problems with the Z80 is the European ColecoVision, and the VDP interrupt line is a single trace on the CV motherboard that goes directly to the Z80 NMI. I don't know how long that trace is exactly. The original 9928/9928 VDP has no trouble driving the Z80 NMI, and my board is a pin-compatible replacement for the original VDP. The problem is, electrically the FPGA is not the same as the original NMOS VDP, and apparently that matters in weird cases. Of course all the other 20+ systems that my board is used in do not have problems. This is also way off-topic at this point, apologizes to the O.P.

I used to wonder why it was so deceptively hard to optimize DMA code to fit within Vblank. It turns out I didn't account for DRAM refresh.

Here's a quick update. My board came back from OSHPark this morning. I soldered the connector and 65C02 and powered it up. Here's a photo:

The 6502 is running code from the Micron SDRAM attached to the FPGA.

I'll post some more progress once I get it to do something interesting.