BigDumbDinosaur wrote:
What’s the purpose of defining A15 as OE in your GAL code? To me, that’s unnecessarily confusing, since all chip-select equations are evaluating address bus conditions (and VDA for the I/O block), and you are not defining the GAL’s output-enable features anywhere in your code.
Namely because the datasheet has that pin labelled as OE; easy enough to change.
Quote:
I would use the FIELD keyword to define the address bus, e.g., FIELD addr = [A15..10]; in your application, which makes for more concise expressions in your output equations. I would then write the UART chip select equation as UART = VDA & addr:['h'84xx], which is much easier to understand, and less likely to be in error due to forgetting to use a negation (!) where needed. Similarly, I would define the ROM chip select as ROM = addr:['h'Exxx];, which, again, is much easier to understand.
Figured there was a better way to do it; but it was late, I was tired, and this is what my two brain cells could conjure up at that hour.
I did have the foresight to test the logic of the PLD itself on another breadboard, so I know it works. (For the record, I'm not planning to keep this on a PLD/Breadboard)
Quote:
Also conspicuous by its absence is any definition for RAM. Is there no RAM in this system? Also, it would be very helpful if you posted a full schematic, not bits and pieces.
RAM is the lower 32K of the 64K address space, and is controlled directly by the A15 line. I'll draw up a full schematic; lost the previous one.
Quote:
Yuri wrote:
Rails dropped by about .5V when I had it plugged in.
You need to fix that power problem—a loss of a half-volt under load is unacceptable, in my opinion. It wouldn’t surprise me if you also have a ground bounce problem in this unit.
Entirely possible; I've tortured these bread boards for a while now, so there's no telling what condition they actually are in. That being said, this is what I noticed when I put JUST the PLD on a breadboard all by itself and connected my bench supply to it.
(Could be I have a bad bench supply? Maybe my multi meter is being wack? IDK, I'm sure I have the less than ideal set of equipment here.)
Quote:
Something else to consider would be adding a bus transceiver to isolate the data bus from the 65C816 during Ø2 low. I’m speculating as to whether or not that would help—data bus contention right after Ø2 goes high is a potential problem with the 816. If that is happening, you should be able to see its effects on the scope by monitoring VCC at the 816, with the scope being triggered by the rise of Ø2.
Yea, I threw a '245 in there to see if that would help, but no luck with that either. I even went as far as moving back to a single stepped clock and manually pulsing the write line.
On the 6502 there's a bit a junk I see on the data lines that comes through, but the UART seems fine with that.
The 65816 looks absolutely perfect as far as I can tell, and yet it just sends junk. The scope shows it just absolutely blasting the bits as fast as possible even though I set it down to 1200.
Quote:
I have a feeling your breadboard construction is behind most of your problems. Also, do you have a bypass capacitor at each chip?
No doubt, been wanting to get off the breadboard for a while. Though seems really odd that it is reliably working on the 6502 without any issues what-so-ever, but completely looses it when the 65816. I'd think I'd seem more random issues if the breadboards were at fault. *shrug*
Yes, I've put caps all over the place, as close to the power rails of the chips as I can reasonably get them.
I finally threw up my hands and broke out the 44 LCC breakout board and hooked up one of the SC26C92s I have.
Got that working just fine with both the 6502 and the 65816.
At this point the CPUs @ 2MHz are just blasting the characters so fast it's overrunning the TX buffer at 1200 baud, no surprise, but easy to fix in software.
(Full schematic will be forth coming once I get it drawn up)
Login
Register
FAQ
Search
Here's it's 
