Jim Battle

Members
  • Content count

    23
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

3 Neutral

About Jim Battle

  • Rank
    Member

Profile Information

  • Gender Male
  1. Alex, "Completely ignore the USB-IF and allocate your own VID/PID to yourself or reuse one for a similar product." There are practical reason not to do that -- I'm sure you know this, but the host computer identifies which driver to load via that VID/PID. If you sell a product with a vid/pid which collides with an existing product, it can lead to unhappy users unless your hardware is a (nearly) exact functional replacement for the board whose ID you are squatting on. The right technical solution would have been to have a 128b ID space and then there wouldn't be the need to be so miserly with allocation of this resource. Too late now, though.
  2. Holy cow -- it looks like a solder ball LX16 and a config eeprom, crystal, and USB fitting on a tiny, tiny board.
  3. Jon, in my case the can run at 3 Mbps and I've run many MB of data through at that speed without loss, but since I don't really know how much margin there is in the design, I backed off to 2 Mbps. And really, the 2 Mbps carries only 1.6 Mbps of data payload once the start/stop bit overhead is removed. Yes, I'm aware that USB packetizes the data, has flow control and error correction mechanisms (checksum, ACK/NAK, retry), but should the link get congested, the FTDI chip should drop the RTS status and let me know to throttle. How likely is that? Well, the 2232D that the Papilio Pro uses is a full speed USB link and uses a 128 byte transmit buffer. Although a full speed link is 12 Mbps peak, but the reality is that packetizing and flow control overheads means that throughput will be less, probably under 8 Mbps. If the USB link I'm connected to goes through a hub and is sharing the bandwidth with a scanner, which is capable of saturating the link, the FT2232D on the papilio pro will drop RTS but the FPGA will never know it. Sure, I could work around it by adding another FTDI or similar device, but my point is that it could all be avoided if the FTDI flow control signals were connected up to the FPGA.
  4. Ugh, that is exactly what I was afraid of. Rather than having a simple serial protocol, now I have to implement a protocol on top of an unreliable channel. That is a terrible feature. Jack, I vote for this with a high priority: fix the connection to the FTDI serial port so flow control works, removing a layer of complexity. Hamster, even what you propose is problematic. How am I to know how small the buffer size needs to prevent overflow? It seems in the worst case I have to assume it might overflow (no matter how small a buffer is used) and have a means of reporting that fact back to my device and retrying. In my case, I don't need to worry about flow control from the host to my device, as I have a 2KB FIFO to hold the command stream, and I can ensure that there is never more than 2K outstanding at a time. But I can imagine other applications where being able to throttle the host would be useful without having to create an in band flow control mechanism.
  5. Jack, maybe I'm completely misguided as I haven't worked with virtual com ports before, but here goes. I noticed in the schematic only the async rx/tx pins from the FTDI device are connected to the FPGA. In my particular application, I capture around 100 KB of data, then I stream it all at once over the serial port at 3 Mbps. One worry I have is that should I be connected to a full speed USB port and there is some other traffic which competes for the available bandwidth (say a multiport USB hub), what is to prevent data loss? If the ready to send/receive bits were wired from the FTDI device to the FPGA, it seems like I could guard against data loss, but as it is, I simply have to trust that things will be OK. Is this a misguided fear, or maybe something that could be addressed in the BGA-based design where you will have more I/Os to spare?
  6. A little more progress to report. My PCBs from iteadstudio.com arrived today, and 20 minutes later I received an email from the Hamster indicating that this thread had gotten featured on hackaday. I'm honored. I built up one of my PCBs -- it is a 3.3" x 3.5" board which connects directly to the papilio pro's "C" connector, has a couple voltage translation chips, and connectors for a standard 5.25" floppy drive, a standard 8" floppy drive, and a weird 16-pin DIP connector for the Compucolor II computer floppy drive. I ran into a couple problems: (1) I didn't notice that while all the through-hole parts used a 0.032" drill, the 16-pin strip I used to connect to the papilio was using 0.023" drill size. As a result, I spent a half hour filing down the connector strip so it would mechanically fit in the holes. Then after soldering it in, I realized I mounted it on the top of the board rather than the bottom. So I unsoldered it, filed down another strip, and soldered it in. (2) I messed up when I did the mental gyrations to figure out how to place the two 4-pin power connectors adjacent to the C[15:0] connector -- they are on the wrong side of it. So I soldered some jumper wires in the board and plug into the gnd/+3.3V/+5V connectors adjacent to the B[15:0] connector. It is not ideal, but it works for now. These connections draw very little power, and there is a few decoupling caps on the board, which helps. Once I got that all straightened out, I powered it up and it worked on the first try! I've attached a photo of the board mounted to my papilio pro. It is partially obscured by the 16 pin ribbon cable going to the floppy drive itself. The thick black cable on the left is from the power supply feeding +12V/+5V/GND to the floppy drive. Not shown is that the two-pin connector "P4" would normally have a twisted pair of wires going off to a high intensity white LED. The transistor immediately adjacent to it drives sufficient current to get enough current for it. The LED strobes 1 ms every 16.667 ms (ie, 60 Hz). This can be used to illuminate the tach label on the back of the drive in order to calibrate it to operate at 300 RPM.
  7. Jack, is BGA technology out of the question for the FPGA? If you could manage the CSG225 package, it is only $1 more than the TQFP option (digikey, unit 1), and would offer the possibility of having an LX16 option as well as LX9. If it is possible to route to some of the extra I/Os, you could stick with the x16 SRAM and not make any compromise there. If you could mange a CSG324 BGA, then LX9, LX16, LX25, LX45 are all possible. That would be great, even if most of the extra I/Os are not routed out. I realize that inspection of BGA soldering is probably an even bigger issue than the routing of it. At least with the routing, it is a one time problem and you know where you stand. Overall, I think SRAM is a lot more approachable than SDRAM design. On the other hand, some of the xilinx parts have integrated SDRAM controllers, paying attention to the routing and connecting the SDRAM to the right pins and making sure all the right traces have matching length, you get speed and capacity without too much pain.
  8. Thanks, everyone, for the kind words. If there is interest, I can add a more complete description of things on a sub webpage of the compucolor.org website. Just as a taste of this script which is shown in the video, here is the top level "help" description of my ccvfutil (compucolor virtual floppy utility) program, and a few commands: F:\Jim\Documents\compucolor\ccvfutil>ccvfutil.py port:com10 ccvfutil.py, version 0.8, 2013/12/07 Type "help" to see all commands Connecting to device at port com10 ccvf>help Usage: ccvfutil.py <source> [<command> [<args>]] [<redirection>] <source> is either a *.ccvf file name which is to be inspected, or it is of the form "port:com10" to specify that a connection is to be opened on the com10 serial port to real floppy capture hardware. With no command, enter into command line mode, where each subsequent line contains one of the commands, as described below. Arguments containing spaces can be surrounded by double quote characters. <redirection> is optional, and takes one of three forms: ... > <logfile> -- write command output to a logfile ... >> <logfile> -- append command output to a logfile ... | more -- send command output through a pager Type "help <command>" to get more detailed help on a particular command. analyze - produce a detailed bit-by-bit decoding log of a track capture - capture an entire disk to a file check - check the disk data structures for consistency compare - Compare two disks or selected files on two disks dir - display all or selected files on the disk dump - show contents of file or sectors in hex and ascii exit - quit program fill - fill a range of memory with a constant byte help - print list of commands more details of one command label - inspect or write a label on the virtual disk list - show program or data file as text load - read a disk image from a file mem - hex dump of a range of memory memtest - perform memory test on a range of memory meta - report virtual disk metadata normalize - rewrite each sector with canonical timing pound - step to track 0, and set the motor phase properly reset - reset the device save - write the in-memory disk image back to disk step - step floppy head in or out N tracks vol - display or change the disk volume label wp - report, set, or clear the virtual disk write protect status ccvf>help capture capture [-nov(erify)] [-r(etries) <#>] [-t(rack(s)) <tracklist>] [-b(ad)] Read the disk attached in the attached disk drive and dump the result into <filename>.ccvf and status into <filename>.log. -nov(erify): just read each track without verifying the contents. -r(etries): on read errors, how many times to try to read a given track before giving up. The default is 10. -t(rack(s)): specify a list of tracks or track ranges to capture. e.g, -t 19 captures track 19 -t 19,23 captures tracks 19 and 23 -t 19:23 captures tracks 19 through 23, inclusively -t 19:23,32 captures tracks 19 through 23 and 32 -b(ad): captures just the set of tracks which have errors ccvf>meta filename: F:\Jim\Documents\compucolor\disk_images\other\alltronics.ccvf write protect: no sectors: 400 label: .... DISASSEMBLER + ALLTRONICS ccvf>dir Volume Name: SC1179 Volume Directory Blocks: 3 ATR NAME TYPE VR SBLK SIZE LBC LADR SADR 03 MENU .BAS;01 0003 000E 5D 829A 8977 03 SCRMOD.LDA;01 0011 000D 7A 8200 8200 03 SCRMOD.SRC;01 001E 0099 36 0000 0000 03 MON .SRC;01 00B7 0097 33 0000 0000 03 EDITOR.PRG;02 014E 0023 17 8200 8200 01 <FREE SPACE> 0171 001F ccvf>help dump dump {<filename> | <secnumber> | <secnumber> <secnumber> } Prints a sector-by-sector dump in hex and ascii of the specified file. If the specified filename doesn't exist but looks like a number, the that sector will be dumped. If there is a pair of numbers, then all sectors in that range, inclusive, will be dumped. ccvf>dump 0 ### Disk Sector 0 ### 00: 00 02 41 11 53 43 31 31 37 39 12 20 20 e5 e5 e5 ..A.SC1179. ... 10: e5 e5 e5 e5 e5 e5 e5 03 4d 45 4e 55 20 20 42 41 ........MENU BA 20: 53 01 03 00 0e 00 5d 9a 82 77 89 4e 03 53 43 52 S.....]..w.N.SCR 30: 4d 4f 44 4c 44 41 01 11 00 0d 00 7a 00 82 00 82 MODLDA.....z.... 40: 3e 03 53 43 52 4d 4f 44 53 52 43 01 1e 00 99 00 >.SCRMODSRC..... 50: 36 00 00 00 00 00 03 4d 4f 4e 20 20 20 53 52 43 6......MON SRC 60: 01 b7 00 97 00 33 00 00 00 00 00 03 45 44 49 54 .....3......EDIT 70: 4f 52 50 52 47 02 4e 01 23 00 17 00 82 00 82 3e ORPRG.N.#......> ccvf> The same script can be used to manipulate disk images without any of the disk capture stuff. In fact, it is part of the plumbing of the compucolor website. All the disk images are online. When you click on a "directory" link for a given disk image, on the fly the script is invoked and it creates a web page containing the directory listing. Each file is a hot link and if you click on one of those, the script is invoked again to dump the file contents. If it is a format it knows (eg, .BAS or .TXT) it is listed as ASCII, but if it doesn't know the file type, it just does a sector-by-sector dump of the file. It is a feature I like a lot: http://www.compucolor.org/vmedia.html
  9. I've finally gotten far enough in my project to post some status. The task at hand is to capture (and maybe in the future write) data off of arcane disk formats. In the past I've used the catweasel card, but it is no longer supported, and isn't general purpose enough to support the needs of my current subject, the Compucolor II floppy disk. I turned to the kryoflux card, but soon realized that I didn't like the API much, and I was going to have to build an adapter card, as the CCII floppy interface is nonstandard. Also, some of my past arcane disk decoder projects used an 8" drive, and I would need yet another adapter for those. Since I was going to build an adapter, why not go all in and build my own capture hardware. So I bought my Papilio Pro and got to work. I wrote my own SDRAM controller, but then glommed on to Mike Field's (Hamster's) SDRAM design, before going back to my own. The FPGA work was actually the easy part. Once I was able to capture bits off the disk, I had to write a python script to decode the bits into sectors and tracks and whole disk images, to decode the file structure and detokenize BASIC programs and such. The python script has a mini-shell to allow me to interact with it, eg, if a disk has read errors, I can dump the contents of individual sectors, or ask for specific tracks to retry capture. Anyway, I've posted a 5 minute youtube clip of my setup showing it at work. This is my first attempt at narrating a video and it could be better, but it is good enough for now. I've used this system to capture about 250 disk images for the Compucolor II, and I may come into another large batch to process. PCBs should be showing up in a week or two, then I'm going to rewrite one of my old catweasel drivers (for the wang 2200 computer) to use this new system. This post has been promoted to an article
  10. DiskVaccuum project

    I've finally gotten far enough in my project to post some status. The task at hand is to capture (and maybe in the future write) data off of arcane disk formats. In the past I've used the catweasel card, but it is no longer supported, and isn't general purpose enough to support the needs of my current subject, the Compucolor II floppy disk. I turned to the kryoflux card, but soon realized that I didn't like the API much, and I was going to have to build an adapter card, as the CCII floppy interface is nonstandard. Also, some of my past arcane disk decoder projects used an 8" drive, and I would need yet another adapter for those. Since I was going to build an adapter, why not go all in and build my own capture hardware. So I bought my Papilio Pro and got to work. I wrote my own SDRAM controller, but then glommed on to Mike Field's (Hamster's) SDRAM design, before going back to my own. The FPGA work was actually the easy part. Once I was able to capture bits off the disk, I had to write a python script to decode the bits into sectors and tracks and whole disk images, to decode the file structure and detokenize BASIC programs and such. The python script has a mini-shell to allow me to interact with it, eg, if a disk has read errors, I can dump the contents of individual sectors, or ask for specific tracks to retry capture. Anyway, I've posted a 5 minute youtube clip of my setup showing it at work. This is my first attempt at narrating a video and it could be better, but it is good enough for now. I've used this system to capture about 250 disk images for the Compucolor II, and I may come into another large batch to process. PCBs should be showing up in a week or two, then I'm going to rewrite one of my old catweasel drivers (for the wang 2200 computer) to use this new system.
  11. Magnus, how many slices does it occupy?
  12. This is a great tip! Thanks.
  13. Mike, set the PLL's CLKFBOUT_MULT parameter to 25 and the various CLKOUT<n>_DIVIDE parameter to 8 and you get 100 MHz. 32 MHz * 25 yields an FB clock of 800 MHz. Pages 56/57 of the spartan 6 data sheet (ds162) give the min/max PLL operating range. Fvcomin is 400 MHz, and Fvcomax is 1000 MHz. If you feed the PLL 32 MHz and specify MULT=3, DIVIDE=1, you will be out of spec. BTW, the download link for your papilio pro zip file is messed up -- clicking on it leads to the message saying I don't have permission to upload that file!
  14. I took up Hamster on his offer to use his latest (in progress) SDRAM controller. Although my project uses verilog, it was no problem integrating his VHDL source. After one round of improvements and fixes on his part, I now have a working SDRAM controller! As I stated originally, I don't have high bandwidth requirements, so I'm not entirely taxing the design. Mike's design is designed for 100 MHz operation, but it wasn't working reliably at that speed, nor at 80 MHz. It works fine at 50 MHz and 66 MHz, but I didn't try any harder to find exactly where the breaking point is. Without suitable test equipment, I can't get a good view of what is happening at the pins of the SDRAM to know the nature of the problem. Perhaps it could be cured with some tuning of I/O pin drive strengths and slew rate control, perhaps some SDRAM clock phase tuning, but for the moment, this lets me get on with the rest of my project. Hats off to the Hamster!
  15. The needs of my current project don't require much bandwidth ( < 1 MB/s) but does require more capacity than the internal FPGA RAM blocks allow, so I'm happy with a really dumb and simple hand-rolled SDRAM controller. However, there is one thing I don't understand how to do -- I have two decades of verilog use, but this is my first time playing with FPGAs. The SDRAM requires 1 ns hold time on its control inputs relative to the SDRAM CLK input. What is the right way to do this? Should I add IODELAY to all the outputs except for the one driving CLK? Is the right way to use the PLL to generate two clocks, one 45 degrees delayed, with the earlier one driving CLK and the other driving the logic which feeds the control pins? I looked at Hamster's design but it doesn't include a .ucf file which indicates the driving cell strength. The module also accepts a clock input and a 3ns delayed clock input (from a PLL? From IODELAY or something like that -- I can't tell). He also uses a ODDR2 cell in a way that is somewhat voodoo to me. Can anybody shed light on these issues? Thanks FYI: I'm using the Pro as a device to capture floppy disk data timing information for software-based decoding and archiving purposes. I have both a catweasel card and a kryoflux card, but neither is suitable for this odd format.