Matt Ownby

Members
  • Content count

    26
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Matt Ownby

  • Rank
    Member

Profile Information

  • Gender Male

Recent Profile Visitors

198 profile views
  1. Citation needed I'd be interested in looking into this.
  2. 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
  3. 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*
  4. Awesome reading! Thanks for the info!
  5. 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.
  6. 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
  7. Thanks! Now that I see these files, I realize that I was somehow looking at the wing template Eagle file instead of the buffer wing Eagle file. Not sure how I got so far off! At any rate, I appreciate the help! --Matt
  8. 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
  9. That is really cool. Since the flash is only connected to the FPGA, I figured that the FPGA had to be temporarily configured to write to the flash instead of read from it. That's a pretty neat idea to cut down on hardware costs I just read the Spartan 3E datasheet (section about Master SPI) and looked at the Papilio One Eagle schematics and have concluded that it is set up the following way: M[2:0] is 001 (Master SPI mode) VS[2:0] is 111 (use "fast read 0x0B" command) HSWAP: 0 (enable pull-up resistors on all I/O pins during configuration) Thanks for helping me learn!
  10. Hi all, I've recently been looking into the possibility of making my own PCB with an FPGA on it so I've been studying how my Papilio One configures the FPGA. I was expecting to see a little microcontroller on the board to do this task but instead, to my astonishment, the only thing on this board that can configure the FPGA is the SPI Flash itself (and the JTAG interface via the FTDI chip). This is like black magic to me I briefly skimmed the datasheet for the SPI Flash and it does not appear to have any inherent "auto FPGA configure" setting that I could see So my question is, how does this work? Does the FPGA bootstrap the SPI Flash chip or does the SPI Flash chip bootstrap the FPGA?
  11. Hello guys, I am in the western USA myself. As Alex says, it appears that blogspot mirrors itself.
  12. Ok, I've got a v1.0 release of working code now at 50 MHz! Many thanks to Hamster for the help! You can find the code (with readme) here: http://www.rulecity.com/browsetmp/sd_card_writer-17Feb2013.7z Please feel free to suggest improvements to the stupid bone-headed newbie VHDL mistakes I make! -------------------------------------------------------- VHDL SD card writer v1.0 By Matt Ownby (http://www.daphne-emu.com and http://www.laserdisc-replacement.com) 16 Feb 2013 This is VHDL code (for the Papillio One FPGA board) that shows how to write to an SD card in a high-speed mode. Features: - Uses 4-bit SD mode, not 1-bit SPI mode (faster) - Uses 50 MHz "high speed" mode, not 25 MHz "normal speed" mode (also faster) - Logs to Papillio USB serial port (230400 bps) so you can see what is going on Requirements: - An SDHC card (older probably won't work) that supports high-speed aka 50 MHz mode. How to use: - Get the pins of an SD card (or adapter) somehow connected to Papillio pins. Not discussed here as you are expected to have enough expertise to figure this out on your own What you will see on serial port (230400 bps) if everything is working correctly (this is very terse since string handling is a pain in VHDL): - C00 C08 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C02 C03 C07 C55 A06 C06 C24 C13 S Explanation of above data: "-" gets sent on reset, it means the process is starting over "C00" is the reset command sent to the SD card. It expects no response. "C08" is the voltage-request command and is only supported on newer cards. The Papillio requests normal 3.3V operation. If I/O is not working, or if the SD card does not support this command, this is the last line you will see. "C55/A41" is the init command. It usually needs to be repeated over and over again until initialization is finished which is normal. "C02" is the "get SD card CID" command. It is required otherwise I wouldn't bother sending it. "C03" is the "get SD card's relative address" command. It is also required. "C07" puts the SD card into transfer mode. "C55/A06" switches the SD card from a 1-bit bus into a 4-bit bus (4x speed increase). "C06" switches the SD card from 25 MHz mode to 50 MHz mode (2x speed increase). If you see an "E" after this, it means that the CRC check failed (this happened to me occasionally during development). "C24" starts writing a single 512 byte block at address 0 (beginning of card). "C13" requests the card's status and is optional but it makes me feel better to see it working since at this point we are communicating at 50 MHz. "S" means 'success' and means that the SD card responded that the write operation was completely successful. If you see an "E" here it means that the CRC check probably failed. If you see anything with "X" in front of it, it means that an unexpected response was received and the unexpected response has been dumped out in ASCII hex format. This is for troubleshooting purposes. This post has been promoted to an article
  13. Original forum thread. Ok, I've got a v1.0 release of working code now at 50 MHz! Many thanks to Hamster for the help! You can find the code (with readme) here: http://www.rulecity.com/browsetmp/sd_card_writer-17Feb2013.7z Please feel free to suggest improvements to the stupid bone-headed newbie VHDL mistakes I make! -------------------------------------------------------- VHDL SD card writer v1.0 By Matt Ownby (http://www.daphne-emu.com and http://www.laserdisc-replacement.com) 16 Feb 2013 This is VHDL code (for the Papillio One FPGA board) that shows how to write to an SD card in a high-speed mode. Features: - Uses 4-bit SD mode, not 1-bit SPI mode (faster) - Uses 50 MHz "high speed" mode, not 25 MHz "normal speed" mode (also faster) - Logs to Papillio USB serial port (230400 bps) so you can see what is going on Requirements: - An SDHC card (older probably won't work) that supports high-speed aka 50 MHz mode. How to use: - Get the pins of an SD card (or adapter) somehow connected to Papillio pins. Not discussed here as you are expected to have enough expertise to figure this out on your own What you will see on serial port (230400 bps) if everything is working correctly (this is very terse since string handling is a pain in VHDL): - C00 C08 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C55 A41 C02 C03 C07 C55 A06 C06 C24 C13 S Explanation of above data: "-" gets sent on reset, it means the process is starting over "C00" is the reset command sent to the SD card. It expects no response. "C08" is the voltage-request command and is only supported on newer cards. The Papillio requests normal 3.3V operation. If I/O is not working, or if the SD card does not support this command, this is the last line you will see. "C55/A41" is the init command. It usually needs to be repeated over and over again until initialization is finished which is normal. "C02" is the "get SD card CID" command. It is required otherwise I wouldn't bother sending it. "C03" is the "get SD card's relative address" command. It is also required. "C07" puts the SD card into transfer mode. "C55/A06" switches the SD card from a 1-bit bus into a 4-bit bus (4x speed increase). "C06" switches the SD card from 25 MHz mode to 50 MHz mode (2x speed increase). If you see an "E" after this, it means that the CRC check failed (this happened to me occasionally during development). "C24" starts writing a single 512 byte block at address 0 (beginning of card). "C13" requests the card's status and is optional but it makes me feel better to see it working since at this point we are communicating at 50 MHz. "S" means 'success' and means that the SD card responded that the write operation was completely successful. If you see an "E" here it means that the CRC check probably failed. If you see anything with "X" in front of it, it means that an unexpected response was received and the unexpected response has been dumped out in ASCII hex format. This is for troubleshooting purposes.
  14. Ok, I got the RAM working using this inference method. Slick! Thanks for the tip! It would've taken me forever to find that on my own! Now I've got a question about clocks. The way the SD card works is during initialization its clock needs to run at 400 kHz but at some point it can be configured to run at 50 MHz (which is my goal). So I am using a 100 MHz clock generated from the DCM to derive both of these target clocks from. I've got a little clock divider thingy going on but being the newbie that I am I'm probably doing something wrong (plus I am getting a new warning now). The new warning is: "Phase 8 : 0 unrouted; WARNING:Route:455 - CLK Net:myclk100 may have excessive skew because 0 CLK pins and 2 NON_CLK pins failed to route using a CLK template." And here is my clock divider: divider: process(sd_clk100_in, bDivideClock)variable clock_counter : integer range 0 to 62;beginif bDivideClock = '1' thenif rising_edge(sd_clk100_in) then-- if we are dividing the clock-- 100,000,000 Hz / (400,000 Hz * 2 for double clock * 2 for falling_edge) = 62.5-- see section 4.2.1 for 400KHz frequency noteif (clock_counter = 62) thensd_clk_2x <= NOT(sd_clk_2x);clock_counter := 0;elseclock_counter := clock_counter + 1;end if;end if;-- else let it go full blast!elsesd_clk_2x <= sd_clk100_in;end if;end process; (I divide the sd_clk_2x in another process down to just sd_clk due to me seeing someone else doing that with his SPI SD card code, so I figure it may come in handy) The problem area is in bold. I am pretty sure this is bad practice. But I'm not sure what else to do. I could have two clocks but I have a bunch of utility stuff inside one of my processes (which I can't figure out how to get out due to my inexperience) so if I had two clocks I'd have to duplicate the utility stuff which I definitely know would be the wrong approach. I know that having huge processes is a Bad Thing but I have not been able to avoid it here even though I've looked for ways. The good news is that despite this warning, I am reading and writing to the SD card (apparently at 50 MHz!) which is awesome!
  15. Thanks! I will play around with this soon and hopefully report back with a successful tale