I'm stumped on this one. I'm hoping here will read this and point me to something dumb I've done and can easily fix.

I'm building my second SBC, this time around a 65816. I'm still not confident just going right from design to PCB yet so I've been building this out on breadboards again, but at a slower clock (1 MHz). I'm using a Lattice 22V10D for my address decoding, but I'm having a weird issue it. Specifically, the address line inputs into the GAL appear to be stuck at around 3.3V. This happens even when I put the GAL onto its own breadboard with just VCC/GND connected. I know the 22V10D has internal pull-ups but according to the data sheet they're connected to VCC, so if it was the pull-ups causing this I'd expect the lines to float up to 5V as that's my VCC voltage.

I've tried a few different chips, though they are all from the same batch from EBay so there is always a chance I suppose that they're just all bad. However I also have one from the same batch doing some simple bus decoding for RD/WR/ROMWR (write signal for my EEPROM, so I can disable ROM writes) and that one appears to be working just fine. Also this doesn't appear to be affecting non-address inputs; I have VDA coming in to qualify I/O writes and that signal seems fine.

The GAL fuse map is being generated from GALAsm on Linux, and programmed with a TL866II-Plus (which, btw, burns all the ones my old TL866A complains about!). The original .pld file is attached.

My next step is to try different chips; the new burner claims it can do Atmel parts so I've got some Atmel 22V10Cs coming from Ebay in a few days. Failing that I may have to move over to something like the ATF1504AS, which would be nice from a feature perspective but that means shelling out $60 for the USB programmer, and not being able to breadboard test the design without a clunky adapter for the PLC44 part.

This probably isn't the full story, but I note that the output spec for these parts is that they pull up to at least 2.4V - in other words, high enough for a TTL input to register a 1, but by no means specced to pull up to the rail. Likewise the inputs are specified to pull up to a TTL logic one. The equivalent circuit diagrams show a pullup to an internal reference voltage, Vref.

I got that from the datasheet:
https://www.latticesemi.com/-/media/Lat ... ashx?la=en

Just checked one of my Lattice GAL 22v10Ds .. An unused input is sitting at 2.75v in a 5v system. I'm not convinced it's an issue though.

Nice to see someone else use GALasm, although after failing to get my TIL866 to program Atmel GALs I moved to Lattice and a G540 programmer which needs an old win XP Laptop I have to use. Are you using Linux with the TIL866II+ unit?

I bought 10 Lattice GALS via ebay - they were obviously socketed board pulls, but very clean and all erased successfully. I've been alternating 2 so-far and have probably done about 8 reprograms on each one without any issues.

Are you also using a GAL for the upper 8-bits of the '816 address latch?

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

A-Ha...

I had a good look through the datasheet... Page 16 - input pins are pulled up to Vref and not Vcc - Vref is mentioned on the same page as Typical = 3.2v.

So it seems that's just fine - maybe mine are a little low, but above the TTL input threshold.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Ahh ok I swear the datasheet I looked at said they were pulled up to Vcc. Good to know I'm not crazy.

So now I guess I need to figure out why they aren't being pulled low by the 65816. I will check for some loose wiring when I get home but I'm worried now that somehow the address drivers are burned out. It was working before I tore it all down to rebuild on better breadboards though.

It might be confusing as the datasheet shows the ESD protection being taken to Vcc in the blocks before the pullup to Vref..

Might be worth checking the BE pin on the 816 too - if it's low, then the buses will be tri-state..

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I use my TL866A on linux with Minipro, and have also successfully used it with the official software via Wine. There's a shim DLL out there you can drop into the C:\Minipro folder that lets it work with the Wine USB emulation. At some point I need to try that DLL with the XgPro software that ships with the II+ (same basic software, new name) but for now I'm just doing my burns on my Windows 10 gaming rig, My project folder on my Linux workstation is samba mounted to the Windows box so I can easily access the .jed files for burning.

I've also got a G540 coming from China sometime in the next month, though at this point I don't think I'll actually need it. FWIW a quick google search will find what are supposedly Windows 10 64-bit compatible drivers for it; I will be trying those out eventually as I'd rather not go through the trouble of locating or buying an XP license key at this point.



Nope the address latch is a '573. I'm using the standard 573+245 config for the address and data bus, though I will likely eliminate the '245 as it really isn't needed in my current design.

So far I've bought some 22V10-25LP GALs (which were advertised as -15LP...) and some -7LPs from Ebay. I also have some -15LPs on the way as well, which I'd completely forgotten I ordered until I got the shipping notification. The 25s all seem to program find in the 866II+, and two of them actually worked in the 866A as well (the rest all had the famous byte 32 mismatch problem). None of the 7s seem to work in either programmer. On the 866II+ they will give a pin 2 verification error; if I turn off pin verification I get an overcurrent error, which is also what I get on the 866A. I will eventually try them in the G540 when it arrives before giving up on them.

Ahh good call; that should be being pulled up with a 3.3k resistor but maybe it's loose. That didn't even occur to me because I see the VP signal cycling at a constant frequency as one would expect if the processor is constantly BRKing due to missing ROM. But, now that I'm checking the data sheet it says BE only disables the address, data, and RWB lines, so I guess if BE is not high but RDY is then the poor thing will be trying in vain to fetch vectors.

Can you post a monochrome schematic for us?

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

I'm going to be posting one in the next few days, once I finalize my design and am ready to get some extra eyes on it.

For now Drogon is the winner. My pull-up resistor for the BE line was off by one pin on the breadboard and was thus a pull-DOWN resistor. Once I fixed that things started acting more normal, and after a couple hours of debugging the wiring and my ROM code I've got the board booting up in a test state ($55 on VIA port B, and PB7 outputting the square wave from timer 1).

Tomorrow I'm going try wiring up a 28L92 (I've got a PLCC44->DIP44 adapter board for this) and see about getting the console output working.