Eagle parts for 16-bit input buffer wing and 16-bit I/O buffer wing


Matt Ownby

Recommended Posts

Hi, I want to make a wing-styled PCB that allows me to comfortably interface a Xilinx FPGA with an original Motorola 6809E CPU.  I am going to need read-only voltage conversion from the 6809E's address pins, and safe bidirectional I/O for the data pins.  I've been looking at how the input buffer wing and I/O buffer wing accomplishes this and it looks like I might want to go the same route.  So I downloaded the .SCH and .BRD files hoping to steal the Eagle parts for the voltage conversion ICs but it looks like it's in a .LBR file that I cannot find.  Any idea where this is located?  And am I on the right track or is there a newer better approach to this? (I noticed there was an older thread that mentioned some problems with one or both of these boards)

 

thanks,

Matt

 

Link to comment
Share on other sites

Ok, I am a little confused.  It seems on this latest Eagle schematic/board that you've ditched the IDT QuickSwitch in favor of a part from TI.  Was there something wrong with the QuickSwitch line?  Someone recommended that I look into these and I am really confused about which one would meet my needs.  I see that they have 5V and 3.3V QuickSwitch parts, and this confuses me because I don't understand what the difference is.  Do they both do the same thing and one is powered by 5V and one is powered by 3.3V ?  I just want something that does what the I/O wing is supposed to do (always output at 3.3V, accept 5V input).  Some of the tips I've read say that a diode is needed, others don't seem to make mention of any diode.  I just wanna have the 6809E CPU's data bus go through some kind of IC and have 3.3V come out on the other end and I want to send back 3.3V and have the 6809E receive 3.3V and interpret it as a logic high.

 

Is the new TI part bi-directonal?  I looked at the data sheet and it seems that the direction must be explicitly set.

 

Sorry for my newb questions :o

Link to comment
Share on other sites

Hehe... ok in the interest of learning the answer on my own, I did some more reading and concluded that if I want to use QuickSwitch to clamp all voltages to 3.3V, I need to have the QuickSwitch's VCC be about 4.3V and I can use a diode from a 5V source to achieve this.

Link to comment
Share on other sites

Here is the attached BOM, it is important to use the right Bus Switch. I made the mistake of using the wrong one with version 1.2 and it did not do the job as expected.

 

There is an app note, I'm pretty sure from TI, about using these bus switches as voltage level translators. It explains in detail how everything works, I did a quick search for it but didn't come up with it. You might need to dig a little bit, or I'll search again later.

 

But basically, you are right on track, you use a diode to drop the voltage down to 4.3V. Then the FET will not allow the voltage to rise above 1V below its voltage so you effectively limit the voltage to a maximum of 3.3V. That's what I remember off the top of my head. The nice thing about this approach is its super fast, up to 2GB/s, bidirectional, and it will pass lower voltages through at the same voltage level. So if you have 2.5V it will pass through as 2.5V instead of 3.3V.

 

Jack.

BPW5015-IO_Wing-BOM-V1.3.zip

Link to comment
Share on other sites

Any particular reason you have to use a real 6809E CPU? There is a VHDL model of that CPU that has been used successfully (see the Robotronic Adventures thread).

 

I found your thread and read it.  It is very interesting!

 

The reason I want to use a real 6809E CPU is to avoid all of the problems that you had using the VHDL version :)

 

When I googled for existing 6809E VHDL cores I didn't find much, and what did find proudly proclaimed that it was not cycle accurate to the original.

 

I am actually working on something pretty related to your Robotronic adventures: I am very deep into reverse engineering another Williams game, Star Rider.

 

My ultimate goal is to offer a hardware replacement for the laserdisc player used in this game.

 

But in order to do that, I need the game to work well enough to prove that my hardware replacement works.  This game is pretty dang rare these days.

 

So I decided that the best way to learn how the game works is to emulate it.  I have been working on this since January and I have actually got the game's attract mode running and I can even coin up and play the game although it definitely does not work yet.  You can see videos and blog posts about my exciting progress at : http://my-cool-projects.blogspot.com/search/label/starrider .

 

A friend had the original hardware and he shipped it out to me.  As you can see from my blog post, I spent a lot of time rigging up a power supply and finding a way to see the output of the game without having an original RGB monitor.

 

But when I powered the game on, it DID NOT WORK.

 

After some troubleshooting, I determined that the main CPU board had become destroyed due to corrosion (alkaline battery leakage?).  And since I had just spent months and months studying the schematics to this game, I realized that I almost completely understood the hardware on the main CPU board.

 

At this point, I determined that if I used an FPGA, I could whip up a replacement PCB of the main CPU board without "too much" effort and then I'd be able to plug it into the rest of the original hardware and actually play this dang game and proceed with my original goal (testing the laserdisc interface!).  I hate getting derailed by things like this but it is sure fun!!!

 

Anyway, so that's what I am working on.

 

My status is that while I am trying to keep the PCB board size small, the original components are HUGE and this is a big problem for me.

 

The main CPU board has quite a few of the massively huge molex connectors which I have put on my current Eagle implementation but boy, I am wondering if I should shrink them down and build cable adapters or something.

 

Like I said, I want to use the original 6809E because I do not have time or desire to debug a buggy VHDL 6809E and I know enough from emulating this game that accuracy matters a lot.

 

Another problem I'm running into is FPGA capacity.  I've put the RAM (and NVRAM) onto the FPGA successfully but when I tried to shove the CPU's ROMs on there I ran out of room.  So I am looking at the prospect of exploding the PCB's size to massive proportions by putting sockets for the original EPROMs on the PCB.  I really don't want to do this.  I am thinking maybe I can use my Papilio One as a "ROM server" (if the ROMs will fit) or if the ROMS won't fit, maybe I will try using my Papilio One as a "RAM server" instead.  I am trying to do something that is accurate but also somewhat quick n' dirty since I Don't want to get too derailed on perfecting this board.  (Although it would be awesome to come back later and perfect it).

 

So basically what I am trying to do is still use the original CPU and I will still need to talk to the Video Graphics Generator board from the main CPU board using TTL-compatible voltage (and possibly will need to talk to original EPROMs with the TTL voltage) but otherwise I've got this thing on the FPGA.

 

In other words, I've finished writing the VHDL for the rest of the CPU board and just need to figure out how to get the ROMs on there somehow.

 

So I'm open to any and all suggestions :)

 

--Matt

 

EDIT: I almost forgot.  I also found John Kent's PIA6821 VHDL code and am using it but I am somewhat tempted to just drop it and use original PIA6821's as well (even though they are huge).   The reason is that I found several things about Mr. Kent's VHDL code that I did not like.  For one thing, his IRQA' and IRQB' implementation outputs high or low but a real PIA is open drain and should output low or "open".  This actually matters a lot for Star Rider because the game has the IRQ lines from two PIAs daisy chained together.  So I fixed this bug in Mr. Kent's code but then noticed that he has a few other problems like reset being active high (instead of low), and only one active high Chip Select pin (the original PIA has three chip select inputs).  This seemingly arbitrary decision to not expose the original interface of the PIA has made me suspicious of how dedicated Mr. Kent was to preserving accuracy when he designed it.  I am still using it for now but I will be very sad if I have to spend a lot of time debugging it if the game doesn't work.  Really, if the original PIAs weren't DIP40, I'd slap them on my PCB because Jameco.com still sells them for cheap.  *end musings/rant* :)

Link to comment
Share on other sites

Regarding your last edit, yeah I understand your frustration. I personally prefer active high logic and I tend to use it whenever possible when I write HDL because it's real easy to slap an inverter on the inputs or outputs if you need the module to be "true" to the original chip that may be using active low logic on its pins.

 

I have personally used two types of bidirectional voltage level translator chips, both from TI, one is the so called smart "auto direction sensing" TXB0108 and the other is the SN74LVC8T245 chip. I personally prefer the latter because the auto sensing TXB0108 has weak output drivers in order to maintain its state but also to allow you to override their direction by overdriving them externally. This may or may have not been the cause of some issues I had, all I know is that when I switched to the 'T245 my problems went away. The 'T245 has a direction pin so you can control the direction in which the signals flow. If you only need unidirectional you can tie the direction pin low or high depending on the direction. For data buses the direction pin can be tied to the R/~W signal for example.

 

You can get both types either naked or mounted on breakout boards from ebay.

 

As for your ROM issue, I'm not sure how much capacity you're needing for the game (not familiar with Star Rider). It also depends if all your ROMs are aggregated into one memory space (so only one ROM is accessed at a time, as is typical for a CPU ROM) or if multiple ROMs are accessed simultaneously as is often the case for Video circuitry that stores sprites/graphics in the ROMs. Another consideration is how fast are the ROMs accessed.

 

One possible idea is to use a fast serial FLASH or a SD (or microSD) to store the contents then have a controller (FPGA or micro) that presents a parallel ROM interface to the CPU. Depending on access times you may or may not have time to read the data from the serial FLASH and place it on the outputs. If this is a feasible idea you've just shrunk many full size ROMs into the space of one SMT chip and one SD card socket. Also "programming" the EPROMS is as easy as copying files to the SD card.

Link to comment
Share on other sites

As for your ROM issue, I'm not sure how much capacity you're needing for the game (not familiar with Star Rider). It also depends if all your ROMs are aggregated into one memory space (so only one ROM is accessed at a time, as is typical for a CPU ROM) or if multiple ROMs are accessed simultaneously as is often the case for Video circuitry that stores sprites/graphics in the ROMs. Another consideration is how fast are the ROMs accessed.

 

One possible idea is to use a fast serial FLASH or a SD (or microSD) to store the contents then have a controller (FPGA or micro) that presents a parallel ROM interface to the CPU. Depending on access times you may or may not have time to read the data from the serial FLASH and place it on the outputs. If this is a feasible idea you've just shrunk many full size ROMs into the space of one SMT chip and one SD card socket. Also "programming" the EPROMS is as easy as copying files to the SD card.

 

Like other Williams games, Star Rider uses a paging system to address more than 64k of RAM/ROMs.

 

The ROMs that can be addressed by the main CPU include two 8k ROMs and three 16k ROMs.  I guess that means 64k :)  Only one can be read at a time.  The CPU's clock is 1 MHz so this isn't exactly speedy.  However, I would be skeptical of whether an SD card would always be able to guarantee delivery on time.  I have no experience with serial flash.

 

The RAM size is the same 0xcc00-0xcfff 4-bit nvram area you mentioned for Robotron, as well as five 8-bit 2k chips (10k).  I have attempted to implement this with block RAM and, without being able to test it, ISE isn't complaining so I'm probably on the right track.

 

EDIT : maybe I could put all the ROM on something like this: http://www.onsemi.cn/pub_link/Collateral/CAT28C513-D.PDF

 

EDIT #2 : did more googling, it seems that parallel ROMs are pretty obsolete these days.  I guess I am one of the last to realize this hahaha

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.