Wait-States with a GAL

[HiassofT]

kc5tja wrote:

3) Developer tools require Windows to really work right. Some claims of success running software in Linux can be found here and there on the 'net, but seemingly without fail, when things go wrong (and they do), the support forums I've read all indicate, "You should use Windows."

At least for the Xilinx environment this situation has significantly improved. Xilinx provides a native Linux environment, which now also works fine on 64bit Linux (which is what I'm using here, Debian Lenny AMD64).

I'm using this here (to develop XC95..XL stuff) and can't complain too much about it (other than the software being REALLY HUGE - be prepared to download a ~3.5GB tarball).

Of course the Xilinx software ("impact", to be specific) only supports Xilinx JTAG cables - just like the Lattice software ("ispVM") only supports Lattice cables. This is a little bit annoying, but not a big problem:

I just create an SVF file (using the vendor specific programming software, but without a vendor cable) and then program the device using UrJTAG. UrJTAG supports several different USB and parallel JTAG cables, currently I'm using a homebrew Lattice parallel cable to program my XC95..XLs.

Creating the SVF file and programming the device can easily be automated using a few lines of batch files / shell scripts.

Here's a snippet of the shell script to convert the Xilinx .JED file into an SVF ($IN=.jed file, $OUT=.svf file):

Code: Select all

cat <<EOF > $TEMPFILE
setMode -bs
setCable -port svf -file $OUT
addDevice -p 1 -file $IN
Program -p 1 -e -v
Quit
EOF

impact -batch $TEMPFILE

And this is the snippet of my shell script to program the SVF into the device using UrJTAG:

Code: Select all

jtag << EOF
include ${HOME}/.jtag/rc
detect
part 0
svf $IN
instruction BYPASS
shift ir
EOF

Some 5-6 years ago I was running the Lattice software in a Win2k VM (using VMware Workstation) and had a lot of problems if the project files resided on a Samba share. It seemed there were some file-locking and/or timing problems. I don't know how the situation is today, could also have been a Samba/Windows/VMware issue.

so long,

Hias

[BigDumbDinosaur]

kc5tja wrote:

4) Programmers sold separately, which couple to ports no longer in production. It's as if vendors are incapable of making USB-native programmers.

Huh? USB programmers are readily available from a variety of sources (including eBay, where you can buy lame 50 dollar Chinese units that connect to a USB port). For more advanced programming tasks, Digi-Key, Jameco and Mouser, among others, sell USB units.

Quote:

2) Developer tools are necessarily vendor specific. I can't stand this. No open standards exist, except for ISO Verilog and VHDL. We've played the Tom and Jerry game about this elsewhere on this forum.

That's an unfortunate reality of the marketplace. Each vendor is attempting to differentiate itself from the others, a lamentable situation that is reminiscent of the "UNIX wars" of the 1980s. Fortunately, VHDL is VHDL, no matter the vendor.

Quote:

3) Developer tools require Windows to really work right.

Also an unfortunate reality of the marketplace. Microsoft has succeeded in turning the computing masses into sheep. Vendors are going to target the OS that has nearly 90 percent adoption. Adding insult to injury, the Open Source crowd has repeatedly shot itself in the foot by not producing a standard windowing API that will flawlessly function on any Linux distro when operated by the clueless. So it's hardly a surprise when a vendor doesn't port their software to Linux. Until the desktop/single user side of Linux achieves some degree of stability and parity with Windows, this is not likely to change.

[8BIT]

I have my new Wait-State generator code completed for a GAL16V8 and tested on the WinCUPL Simulator.

It supports one or two wait-states that are auto-selected based on the address decoding that is built in.

As a bonus, there are 3 I/O pins left over that could support more decoding inputs or provide some decoding outputs.

Pins 12,13,15, & 16 don't need to be connected to anything - they are just the intermediate outputs needed to generate the RDY signal.

Here's the code:

Code: Select all

                         /*             __   __              */
Name     WaitStateGen;   /*   PHI2 -> 1|  |_|  |20<- VCC     */
PartNo   1;              /*    VDA -> 2|       |19->         */
Date     12/04/2010;     /*    VPA -> 3|       |18->         */
Revision 01;             /*    RWB -> 4|       |17->         */
Designer Daryl Rictor;   /*    A15 -> 5|       |16-> ws2     */
Company  ;               /*    A14 -> 6|       |15-> ws1     */
Assembly ;               /*    A13 -> 7|       |14-> RDY     */
Location ;               /*    A12 -> 8|       |13-> FF2     */
Device   g16v8ms;        /*   /RES -> 9|       |12-> FF1     */
Format   j;              /*    GND ->10|_______|11<- GND     */


/* INPUTS  */

pin 1     = clk;                        /* FF clock input */
pin 11    = oe;                         /* FF Output Enable */

pin 2     = VDA;                        /* MPU valid data address */
pin 3     = VPA;                        /* MPU valid program address */
pin 4     = RWB;                        /* MPU read/write */
pin 5     = A15;                        /* address bus */
pin 6     = A14;                        /* address bus */
pin 7     = A13;                        /* address bus */
pin 8     = A12;                        /* address bus */
pin 9     = RES;                        /* system /RES input */

/* OUTPUTS */

pin 12    = FF1;                        /* Flip-Flop 1 */
pin 13    = FF2;                        /* Flip-Flop 2 */
pin 14    = RDY;                        /* MPU RDY signal */
pin 15    = ws1;
pin 16    = ws2;


/* LOGIC */

Cxxx      = A15 & A14 & !A13 & !A12 & (VDA # VPA) & RWB;     /* Cxxx = ROM 1 ws */ 
Dxxx      = A15 & A14 & !A13 &  A12 & (VDA # VPA);           /* Dxxx = IO 1 ws */ 
Exxx      = A15 & A14 &  A13 & !A12 & (VDA # VPA);           /* Exxx = IO 2 ws */ 
Fxxx      = A15 & A14 &  A13 &  A12 & (VDA # VPA) & RWB;     /* Fxxx = ROM 2 ws */ 

/* Combinatorial OUTPUTS */

ws2       = Exxx # Fxxx;
ws1       = ws2 # Cxxx # Dxxx;
RDY.oe    = ws1 ;                       /* tri-state RDY when not needed */
RDY       = !FF1 & !FF2;                /* condition MPU RDY input */

/* Register OUTPUTS */

FF1.d = (ws1 # ws2) & !FF1 & !FF2 & RES;
FF2.d = ws2 & !FF2 & FF1 & RES;

I'll provide a zipped file with all the code and simulator files soon.

Daryl

[faybs]

BigDumbDinosaur wrote:

kc5tja wrote:

4) Programmers sold separately, which couple to ports no longer in production. It's as if vendors are incapable of making USB-native programmers.

Huh? USB programmers are readily available from a variety of sources (including eBay, where you can buy lame 50 dollar Chinese units that connect to a USB port). For more advanced programming tasks, Digi-Key, Jameco and Mouser, among others, sell USB units.

Quote:

2) Developer tools are necessarily vendor specific. I can't stand this. No open standards exist, except for ISO Verilog and VHDL. We've played the Tom and Jerry game about this elsewhere on this forum.

That's an unfortunate reality of the marketplace. Each vendor is attempting to differentiate itself from the others, a lamentable situation that is reminiscent of the "UNIX wars" of the 1980s. Fortunately, VHDL is VHDL, no matter the vendor.

Quote:

3) Developer tools require Windows to really work right.

Also an unfortunate reality of the marketplace. Microsoft has succeeded in turning the computing masses into sheep. Vendors are going to target the OS that has nearly 90 percent adoption. Adding insult to injury, the Open Source crowd has repeatedly shot itself in the foot by not producing a standard windowing API that will flawlessly function on any Linux distro when operated by the clueless. So it's hardly a surprise when a vendor doesn't port their software to Linux. Until the desktop/single user side of Linux achieves some degree of stability and parity with Windows, this is not likely to change.

You do realize that 3 is actually a direct result of 2: people were sick and tired of dozens of different and incompatible types of computer and OS, so they pushed for a single standard. Intel and Microsoft just happened to suck less than anyone else so they became it. Please don't insult the hundreds of millions of doctors, architects, etc who don't want to have to learn how to use their computer all over again (not to mention buy all their software and most of their peripherals all over again) if they decide to switch vendors. I was there during the 80s, and either you were a dedicated Commodore/Apple/IBM outfit or you suffered the pain.

[GARTHWILSON]

Quote:

people were sick and tired of dozens of different and incompatible types of computer and OS

I was sick and tired of Bill Gates' big-brother tactics, his high prices, and the computer problems that had me constantly angry at the computer and wanting to throw it out the window. Going to Linux has not been 100% smooth-sailing, but it did get rid of 90% of my computer problems. I won't go back to Windoze, not even to save my job. It's not worth my health. I've told my employer that, and my insistence got the other engineer in the company to try Linux, and now he's a convert

Quote:

who don't want to have to learn how to use their computer all over again if they decide to switch vendors.

I had to re-learn very little when I switched to Linux, and some parts of it are much easier, like downloading and installing new software from Ubuntu's software center.

As for the number of versions, many of them are Debian-based, and Ubuntu seems to be emerging as the popular leader.

[kc5tja]

faybs wrote:

You do realize that 3 is actually a direct result of 2: people were sick and tired of dozens of different and incompatible types of computer and OS, so they pushed for a single standard. Intel and Microsoft just happened to suck less than anyone else so they became it.

Actually, I grew up during that time myself, and saw everything unfold first hand. Intel and Microsoft were world-renowned for their total suckage -- so much so that Microsoft had to resort to:

(1) four major (and somewhat mutually incompatible) revisions of Windows before they got something usable (Windows 1, Windows 2, Windows 2/386, and Windows 3.0 were all pretty much the laughing stock of the industry at the time),

(2) contractual agreements with PC vendors that guaranteed fiscal income to Microsoft even when Windows was not desired by a customer, thus providing financial motivation to pre-equip PCs with Windows against customer will (OS/2 was kicking its ass at the time),

(3) a litany of corporate technology purchases which ensured competing OSes lacked appealing applications. Bars & Pipes for the AmigaOS platform comes readily to mind, and of course, and,

(4) software embedded in Microsoft's code which actively sought out competitor's software and refused to work with them (e.g., Windows 3.1 bootstrap code which sought out DR-DOS code signatures, and failed the boot process when found).

In every case, Microsoft has been shown to manipulate the market. Their hegemony has not been earned, it was strong-armed.

Quote:

Please don't insult the hundreds of millions of doctors, architects, etc who don't want to have to learn how to use their computer all over again

Honestly, they didn't have a problem before, and they still won't have a problem today. I wrote software for several platforms back then, and frankly, customers just didn't give a $#!+ which platform the code ran on, and were quite willing to work with multiple systems. If the computer had a keyboard, a mouse, and a graphical interface, they were just peachy keen.

The superficial differences between GEM, AmigaOS, Windows, and MacOS are so small that it has not one bit affected the productivity of our industrial or medical sectors. In fact, one could argue that this era was our most productive in terms of economic output. Amigas found home in nuclear reactors and movie studios alike for their real-time capabilities, PCs on the shop floor for its ISA bus, and Macintoshes in the publishing industry. These systems all got along, thanks to established communications standards at the time, ranging from RS-432-based interconnects to 10-base-2 Ethernet.

You speak of hundreds of millions of people crying out in pain as though they felt the demolition of Alderan through the force. Having reviewed the technical literature available at the time, I don't seem to recall this ever being mentioned with sufficient frequency to justify your claims. In fact, the only time I ever heard any complaint from one of my customers was when dealing with a single platform: interoperability between Novell versus LANTastic, for example, primarily because neither Commodore nor Atari ever had a strong impact on the PC industry what-so-ever. At the time, nobody ever got fired for buying IBM or Microsoft.

Knowing that the over 90% of the IT infrastructure at the time was IBM or compatible, all running primarily MS-DOS-based systems, I really find it utterly disingenuous for you to call me out on this matter, using platform diversity as an excuse.

Furthermore, none of this is relevant anyway -- Windows, Linux, BSD, QNX, and numerous other OSes have POSIX APIs now. It is possible to develop software, even in C, which runs on a wide diversity of OSes thanks to POSIX and similar API standards. Even ignoring those, you also have widget libraries like wxWindows which allows you to support native GUI interfaces on whichever environment wxWindows has been ported to. So, even if this weren't possible 20 years ago, it is possible today, and I find the business case for not using such toolkits, frankly, quite unconvincing.

[BigDumbDinosaur]

8BIT wrote:

I have my new Wait-State generator code completed for a GAL16V8 and tested on the WinCUPL Simulator.

Cool! I'll have to play around with it.

Quote:

Pins 12,13,15, & 16 do need to be connected to anything...

You mean pins 12,13,15 and 16 do not need to be connected? In other words, you're using them as nodes.

[8BIT]

BigDumbDinosaur wrote:

You mean pins 12,13,15 and 16 do not need to be connected? In other words, you're using them as nodes.

Yes - I needed them to reduce the number of OR combinations as the 16V8 can only support 8 max. If you wanted to do away with the tri-state feature on the RDY (and just use the diode), you could free up pin 15 & 16 also.

Daryl

[8BIT]

Here's the capture of the Simulator for my Wait-State Generator.



The PHI2 clock cycles from column 5 - 12 are for ROM addressed in the Cxxx range and provide 1 wait state.

The PHI2 clock cycles from column 13 - 20 are for IO addressed in the Dxxx range and provide 1 wait state.

The PHI2 clock cycles from column 21 - 32 are for IO addressed in the Exxx range and provide 2 wait states.

The PHI2 clock cycles from column 33 - 44 are for ROM addressed in the Fxxx range and provide 2 wait states.

Daryl

[faybs]

Wow, I seem to have touched a nerve here. I was commenting on the paradox of both lamenting the multitude of incompatible standards for PLDs on the one hand while also lamenting that most desktop software follows one single standard on the other. Since Microsoft seems persona non grata around these parts, look at the history of Linux instead. For years Linux was harmed by the refusal of its developers to follow a single set of standards (I still remember having to deal with multiple versions of different runtime libraries because the guys who wrote programs I needed were running a different distro than I was - I was a Slackware user back then) until Mark Shuttleworth decided to do something about it. Not very surprisingly, his standardized version of Linux made most of those problems go away and so it's the most popular.

As an aside, I must say that I'm mystified that people in the tech industry are still going on about dodgy business dealings that happened over a decade ago, while companies like Monsanto and BP, who are right now trading our health for their profits, get a free pass - I guess it's up to a younger generation to fight the good fight while the old coots still shake their fists at their old foes.

[BigEd]

Everyone
could I make a heartfelt request that we try to keep each thread at least tangentially related to the 6502, electronics, and preferably the original thread posting?

We all have our beliefs and opinions, but isn't it better to keep certain topics to their own territories? We know which are incendiary.

The crucial think, I think, is not to respond to everything - if it's not on topic, if it's not polite, then ignore it, take it to PM, or at least start another thread, please.

This forum is an excellent resource, not just for technical conversation but also as something near the top of relevant Google searches and has hundreds of non-posting readers. Please don't dilute it.

Sorry for the interruption: normal service will be resumed. I speak of course only for myself.

Cheers
Ed

[BigDumbDinosaur]

8BIT wrote:

BigDumbDinosaur wrote:

You mean pins 12,13,15 and 16 do not need to be connected? In other words, you're using them as nodes.

Yes - I needed them to reduce the number of OR combinations as the 16V8 can only support 8 max. If you wanted to do away with the tri-state feature on the RDY (and just use the diode), you could free up pin 15 & 16 also.

Daryl

BTW, in the chip pictorial in your code, you show that pin 11 is grounded. Actually, it should be a no-connect.

[BigDumbDinosaur]

I took a quick look at Daryl's wait-state thingie and will shortly have pics up of my attempt at simulating it.

[BigDumbDinosaur]

8BIT wrote:

Here's the capture of the Simulator for my Wait-State Generator.

I tried it out this morning and it seems to work fine. For some reason, I had a mental block about implementing the flip-flops in the 16V8. The combinatorial logic leading up to the wait-state wasn't a problem (I see you implemented part of it) but I just couldn't seem to get past the flop part.



Here I put $E000 on the address bus. At vector 6, VDA is asserted, indicating the address bus is valid, at which point RDY switches from tri-state to high. At vector 7, Ø2 goes high, RDY goes low and the wait-state starts. According to the rules in Daryl's CUPL code, the $E000 block gets two wait-states, which occurs as expected. Finally, at vector 15, two Ø2 clocks later, RDY goes high and the MPU proceeds.

Interesting aside related to wait-states: in the PLD code I'm developing for POC V2, I generate the signal /WD, which goes low only when RWB is low and Ø2 is high. This signal is to avoid write-enabling hardware when Ø2 is low, during which time the 65C816 data bus holds the bank address, not data. If the MPU is wait-stated during a write cycle, logic is required to keep /WD low during the wait-state, even when Ø2 goes low. Otherwise, the affected hardware will possibly get confused by the fluctuating /WD signal.

-----------------

Edit: Couldn't seem to get the picture size down to manageable proportions.

Edit: Finally got the picture size under control.

[8BIT]

BigDumbDinosaur wrote:

BTW, in the chip pictorial in your code, you show that pin 11 is grounded. Actually, it should be a no-connect.

Pin 11 is the OE for the two flip flops. If you want to see the outputs on pins 12 & 13, you need to have pin 1 grounded. However, the flip flops will work with pin 11 high as well. Since it is an input, it should be connected to either Vcc or Gnd.

One part I had trouble with was the lack of /CLR input in the 16V8's flip flops. I finally figured that having RES ANDed with the D input provide at least a synchronous reset.

Glad to hear this was helpful!

Daryl