6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:00 pm

All times are UTC




Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 9  Next
Author Message
PostPosted: Fri Apr 07, 2017 5:48 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
I used a Minipro TL866A. I was aware that there were some issues surrounding their programming, but I did not know what they were. Their page does say that it supports that specific Atmel part, but when I contacted them over a wierd transient problem(I hope it was transient), they said they hadn't actually tested it.

Hmph. If it doesn't use the standard programming algorithm, they shouldn't be allowed to market the thing as a standard part. And they shouldn't be allowed to advertise that a programmer can blast this thing if they haven't actually tested it. I suppose it makes business sense to someone who's only really in it for the money, and not too honest...

But if the VIA test program works, does that not point to the GAL working? I'll pull it out and test it, see if I've wasted my money on a falsely advertised part...


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 07, 2017 8:25 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
DerTrueForce wrote:
I'll pull it out and test it, see if I've wasted my money on a falsely advertised part...

If you unplug EEPROM, RAM, DUART and VIA and then wire (use 3K3 resistors) the databus with the pattern $EA = 11101010 binary, you present your CPU a NOP instruction all the time. So it cycles (beginning at $FFFC,$FFFD then hopping to $EAEA through all addresses, endlessly. If you then additionally connect one of the various /CS you have to the RUN pin at your CPU the test will stop at the first address the GAL considered to be part of the address range related to that /CS.
Once halted check the addresslines.


edit(1): added "use 3K3 resistors"


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 07, 2017 11:35 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
I managed to pull the equation files for the PLD. They were in a virtual machine disk on an ext4 partition of my portable hard disk. I need them if I want to tweak the equations later, so I probably should have kept them closer to hand...
Anyroad, I have attached the CUPL equation file.

I also tested the chip select with the X-spitter rom(by tying to RDY), and it suspended with the DUART address on the upper four pins.


Attachments:
ITTIARAPLD30.PLD.txt [1.62 KiB]
Downloaded 51 times
Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 4:20 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
Anyroad, I have attached the CUPL equation file.

The logic mostly looks fine. However, as written, the following statements will not work as expected:

Code:
PIN 16   = RD                      ; /*                                 */
PIN 17   = WR                      ; /*                                 */
   ...

RD   = PHASE_2 & RW;
WR   = PHASE_2 & !RW;

In the above, you have declared the RD and WR pins as active high outputs, which is incorrect. RD = PHASE_2 & RW will cause RD to go high when Ø2 and RW (the 65C02's RWB output) are high. Similarly, the expression WR = PHASE_2 & !RW will cause WR to go high when Ø2 is high and RW is low.

The correct code would be:

Code:
PIN 16 = !RD;        /* declare as active low output */
PIN 17 = !WR;        /* declare as active low output */
   ...

RD = PHASE_2 & RW;   /* RD will go low when Ø2 & RWB are high       */
WR = PHASE_2 & !RW;  /* WR will go low when Ø2 is high & RWB is low */


The declaration of the pin name with the negation symbol (!) tells WINCUPL this is an active low output.

Some of your other logic can be rewritten as well, viz.:

Code:
PIN 13   = !UART;               /* declare UART chip select as low true     */
     ...
UART = !A15 & A14 & !A13 & A12; /* select UART if A15-A12 = %0101, or $5xxx */

Depending on the device being used, the above may use fewer product terms than the same statement as you wrote it.

Give it a try and see if it will work.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 6:42 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
DerTrueForce wrote:
I used a Minipro TL866A.
...
But if the VIA test program works, does that not point to the GAL working? I'll pull it out and test it, see if I've wasted my money on a falsely advertised part...
I am really amazed that some of your small test programs did work anyway :?

Thx to BDD it is clear that /RD and /WR didn't work correctly. During accessing the DUART this is evident while accessing the VIA RWB is used and /RD or /WR doesn't matter.

What puzzles me is how any program could run. Accessing the ROM uses /RD but /RD becomes 1 during phase_2. So only during the narrow spot where PHI2=0, A15..0 and RWB finally becomes valid the ROM was adressed and selected. All along PHI2=1 nothing drives the databus and only stray capacitances could preserve the information. Looks like the VIAs "bus holding devices" perform this "magic".

But perhaps once you have reprogrammed your GAL and get your DUART running we know that using the Minipro TL866A for ATMEL GALs is possible (at least for basic logic).


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 2:30 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
GaBuZoMeu wrote:
while accessing the VIA RWB is used and /RD or /WR doesn't matter.
Yes, good point.

GaBuZoMeu wrote:
What puzzles me is how any program could run. Accessing the ROM uses /RD but /RD becomes 1 during phase_2. So only during the narrow spot where PHI2=0, A15..0 and RWB finally becomes valid the ROM was adressed and selected.
Hmm, the spot isn't as narrow as you might think. It would be narrow if the CPU were running at or close to its 14 MHz limit. But it rapidly becomes wider as clock frequency is reduced. That's because the delay from the start of a cycle until A15..0 and RWB are valid is rated as 10 ns max. The 10 ns figure remains in effect even at lower clock frequencies.

GaBuZoMeu wrote:
All along PHI2=1 nothing drives the databus and only stray capacitances could preserve the information. Looks like the VIAs "bus holding devices" perform this "magic".
Good point about capacitance. That would preserve the information.

-- Jeff

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 3:16 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Dr Jefyll wrote:
Hmm, the spot isn't as narrow as you might think. It would be narrow if the CPU were running at or close to its 14 MHz limit. But it rapidly becomes wider as clock frequency is reduced. That's because the delay from the start of a cycle until A15..0 and RWB are valid is rated as 10 ns max. The 10 ns figure remains in effect even at lower clock frequencies.
:) you are right, I have to get rid of the NMOS figures (tADS = 300ns, tACC = 575ns) in my mind.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 5:49 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
GaBuZoMeu wrote:
During accessing the DUART this is evident while accessing the VIA RWB is used and /RD or /WR doesn't matter.

Absolutely correct. My focus was on why the DUART was not responding.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 6:28 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
BigDumbDinosaur wrote:
GaBuZoMeu wrote:
During accessing the DUART this is evident while accessing the VIA RWB is used and /RD or /WR doesn't matter.

Absolutely correct. My focus was on why the DUART was not responding.
I was shure /RD (at least) was working correct, due to the other running test programs. That side effect the bus holding devices of the VIA implements wasn't obvious to me.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 6:45 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
GaBuZoMeu wrote:
I was shure /RD (at least) was working correct, due to the other running test programs. That side effect the bus holding devices of the VIA implements wasn't obvious to me.
I thought if anything the bus hold devices would be on the VIA's peripheral ports (ie, not on the data bus). Am I mistaken? To me, bus capacitance is an adequate explanation for why the defective circuit still worked. (But bus hold devices would also explain it.)

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 6:52 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
The "actual" datasheet http://6502.org/documents/datasheets/wdc/wdc_w65c22_sep_13_2010.pdf , page 50:
Quote:
5.3
Bus Holding Pins
All W65C22S pins except PHI2 have bus holding devices. The original NMOS 6522, W65C22N,
G65SC22, and R65NC22 did not have bus holding devices.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 8:03 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Still, the capacitance goes a long way in holding the bus value, assuming all loads are CMOS which basically take no DC input current. When I was writing the code to test the memory modules I sell, I noticed the value on an undriven bus being held for at least a millisecond (not just microsecond)! I did not experiment to find out how long I could drag it out.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 9:14 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
The read/write logic to the VIA would work correctly, as it has nothing to do with the GAL. All the GAL would be responsible for on a VIA access would be generating a chip select.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 10:06 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
Ouch, I hadn't seen that! I've fixed that now:
Code:
RD   = !(PHASE_2 & RW);
WR   = !(PHASE_2 & !RW);

I did it this way because I think in terms of the electrical signal, not necessarily what that level means. I haven't burned the GAL yet, because I need a copy of WinCUPL, and I never put the install file on a portable disk.

Speaking of WinCUPL, does anyone know if it works under WINE? Or if there are any alternatives for Linux?

EDIT: I should say that I just need it to do 16V8s, and it doesn't necessarily have to be CUPL.
EDIT 2: I got hold of WinCUPL(I had to go to the Microchip site to do it, and the Atmel site says absolutely nothing about it). I have compiled the file, and I'm about to restart into Windows to write the PLD, because the Linux minipro software crashes(with a floating point exception, of all things) when I try to use it for 16V8s. Pain in the butt, but there's not really anything I can do about it.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 08, 2017 11:54 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
BigDumbDinosaur wrote:
DerTrueForce wrote:
The GAL is an Atmel ATF16V8B.
I suspect that the CUPL equations for the 16V8 are on the computer I used to use. I'll have to see.

Are you aware that most burners cannot correctly program Atmel GALs? Atmel GALs require the use of a non-standard (i.e., proprietary) programming algorithm. A burner that can correctly program an Atmel GAL is an expensive piece of hardware, typically around 500USD. The programming run with the inexpensive types of burners many hobbyists use seems to be successful but the GAL ends up being non-functional. Unless you had access to the proper type of burner, it's highly likely your GAL is the culprit.


Good advice on the programmer and GAL compatibility. The Atmel stuff is a bit different it seems, as many folks out here have noted issues trying to program them. I bit the bullet a few years ago and splurged on a Dataman 40Pro. Not cheap at $595 but they update their software frequently which includes an extensive list of devices they support. It's been a great programmer, but for the high cost I expect nothing less. I also picked up some adapters for PLCC chips, like 28 and 32-pin PLCCs and the cost can ramp up with these options.

In short, I prefer the hobby side working towards a finished product that works and either meets or exceeds expectations and design goals. I don't want to spend a lot of additional time experimenting and fighting the tools and such to get there. After all, I work on all my own cars as well, but I buy top quality tools and many of the manufacturer specific tools and test equipment, otherwise it's not a rewarding hobby but more of a garage nightmare, which can be quite dangerous.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 9  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: