01.01.10
Posted in Uncategorized at 11:54 pm by admin
So tonight I fooled around with ISIM, which is Xilinx’s simulator. I was doing behavior simulation and wrote a small testbench for the block ram state machine that I wrote a few days ago.
Really neat stuff.
Xilinx’s ISE really makes it easy for you because it will create a testbench fixture of any module automatically. This type of help and framework template is simply invaluable. It gives you a fantastic starting point, and I really need a push in the right direction for most of this. It’s not as if I wouldn’t have figured it out, but it simply does it for you. And the more and more I look thru ISE, the more I find this to be true. Nice, useful things although you’ve got to look for them.
Reminds me of photoshop in lots of ways. Photoshop hides theirs……ISE leaves in plain sight, along w/ 45000 other options. 
Pretty neat to watch the state machine switch states based on counter rollovers, etc….. I’m surprised it handles trillions of picoseconds of time so quickly… I’ve got a nice machine, but it really doesnt get bogged down despite all of the “entries”
It’s almost 2am local time so I better go to bed. But this simulation stuff is definitely neat. It lets you test this stuff w/o running it on the actual hardware……
Permalink
12.28.09
Posted in Uncategorized at 1:06 am by admin
So since I first picked up this Xilinx Spartan-3E starter kit evaluation board, I’ve been trying to get some memory working on the FPGA. The DDR is as elusive as beast as I can find. I’ve not yet given up, but I tried something today and got it working at 3am local time.
I used the block memory generator from coregen, generated a single port RAM, and then instantiated within my own project. Which is a state machine. I write a value in state 1 in address 0, write a value in state 2 in address 1, and then read address 0 and read address 1 in states 3 and 4. Pretty neat.
Not at all tough, and there’s alot more hidden documentation and templates/code examples built into ISE. Now knowing the stuff was there, was, the umm, hard part.
Anyways, I was able to add 64k bytes, which I think is impressive…..I am using 8 of the 20 RAMB16’s to do it…..
More after I get some sleep!
Permalink
12.23.09
Posted in Uncategorized at 8:35 am by admin
I hate when this happens.
The Parallax SX microcontroller line has reached production EOL. The owner of the SX design
(www.ubicom.com) has given Parallax final notice that we are to place a lifetime buy of wafers. We
recognize this announcement will be difficult for customers who have designed the SX into their products.
We share your disappointment.
http://www.parallax.com/Portals/0/Downloads/docs/prod/sx/SX_EOL_Notice.pdf
Permalink
12.09.09
Posted in Uncategorized at 10:54 am by admin
Here’s a histogram of one track off an amiga floppy disk. Notice the peaks near 4us, 6us, and 8us.
I’ve got this data from my logic analyzer, crunched through my little C proggie, and then graphed with Excel.
This shows roughly 45,000 delta Ts, the time between each transition. The first group, of course, the ’10’s, second ‘100’s and the third, ‘1000’s.
Permalink
12.02.09
Posted in Uncategorized at 11:24 pm by admin
I bought at Saleae Logic which is an inexpensive logic analyzer. See link here.
It isn’t nearly as fast (only samples at 24mhz max), and it doesn’t have as advanced triggering capabilities, but it does do millions->billions of samples.
So, of course, I put it to the test! I recorded 5 million samples at 24mhz which works out to be 210ms, just slightly over a floppy track time of 203ms. I sampled an entire track, which is FANTASTIC if you know anything about logic analyzers. They just don’t usually store much.
Then I wrote a small C program which converts the exported binary data to RAW AMIGA MFM. I searched for binary patterns of the sync code 0×94489, and exactly 11 of them came up. Which means that my little code is working, the logic analyzer is correctly reading the data. I still have to try to decode this track and see if it decodes properly, but this is pretty neat. It’s like third party verification of what I’m doing.
I have these odd exception cases where sometimes a track refuses to read although the amiga reads it perfectly. I’m going to get the bottom of those cases.
I hate to say this, but everything just worked tonight. No problems. Brought back up the java client, programmed the SX, and off I went. Pretty neat.
I’ll have more to say on this logic analyzer, but the software is really nice, clean, simple. It does its job.
I can’t tell you for how long I’ve wanted to sample a whole track w/ some test equipment. You can buy $$$ logic analyzers and not get this type of buffer space…. It achieves it by doing real-time samples straight to the PC’s ram……
Permalink
07.18.09
Posted in Amiga Floppy at 1:30 am by admin
So I bought an FPGA eval board and a book on Verilog awhile back. I made some progress learning things, and had some simple things like UARTs, writing to the LCD, and even some small VGA software(hrrrm, maybe I should call it Hardware…) working. Some of it from scratch, some heavily borrowed from existing sources. But then I got stuck. Stuck on being able to access the DDR on board. The included memory controller, produced by Xilinx’s MIG and the CoreGen app, was hard to use and I didn’t (and still don’t) understand verilog enough to simply run with that controller. Now don’t get me wrong. Xilinx has pretty decent documentation for some of this stuff. And they described pretty well the steps needed to initialize the controller, and perform reads and writes. But you have to remember that their controller is 7300 lines of code broken up across about 40 source files. Now if this was C/C++ or Java (or even assembly language), and it was commented properly, I could probably follow what is being done. Their code is poorly commented IMHO.
I digress, right, but I am really an anal commenter. I comment A LOT. But there really should never be a time where I’ve got explain what’s being done in a particular code block. If something goofy is being done, or if I got sloppy, I explain it in-line with the code. Right on the same line. The comments help me when I’m reading the code. And plus they sometimes reveal bugs in my code where what I say I’m doing in the comments don’t match what’s happening in the code. < digression mode off >
So I’ve been looking for other ways to skin the cat. I’ve asked guys at work. I’ve checked out literally every memory controller on opencores.org. The problem is, basically, that DDR sucks. It first sucks because high frequencies are required and so pathways through the FPGA are restricted. I don’t know enough about FPGAs to tell you which path (from which pin to which pin) meets the timing requirements for DDR. The first D in DDR is double, and that implies that if you have a clock, both the rising edge and falling edge of the clock pulse are reading or writing data. Even if my actual application doesn’t require 100+mhz data rates, I’m forced to read/write to the memory at a fast rate. Oh, and the other D stands for Dynamic. And this sucks too. Why because Dynamic memory has to be refreshed constantly, and on-time. That’s another thing to worry about. And to think I actually contemplated writing my own controller. Sheeeesh.
The Spartan-3 eval board, instead of the 3E (which is what I have), contains 1MB of SRAM. Now the S here is STATIC — aka opposite of Dynamic, no refresh required. It’s fast memory, around 10ns, but it doesn’t do any crap double data rate junk. I’ve seen example controllers for this board, and for this memory, and it’s like one page of code. It’s absurd the difference in complexity. However, I’ve got 64mb, and this is 1mb.
Suffice to say, I don’t own the S3 board. While it’s nice, there are very limited connectors, LED displays instead of LCD, etc
ENTER EDK w/ MICROBLAZE and C
So the embedded design kit, available from Xilinx, contains MicroBlaze which is a 32-bit softcore processor that has BUILT-IN controllers for things like Memory, Ethernet (cool), Serial (UARTs), etc. And guess what, you program it in C. And so you first download the FPGA with the HDL for the softcore, and then you download the .elf executable that is make’d from your code. The Base System Builder (called the BSB) will build some initial framework for you and then you can expand from that. Pretty neat because I can select my exact rev of my starter kit, and it handles many things like making sure that the various chips and onboard peripherals are setup properly and interface to the right pins. So the RS232 port is wired in right, and the ethernet is attached properly. And then, they’ve tested the controllers. To make a long story short, I’ve finally got some code running that accesses the DDR and then spits out some messages via the RS232 port. Now this isn’t my code, but you’ve got to start someplace.
– Entering main() –
Starting MemoryTest for DDR_SDRAM:
Running 32-bit test…PASSED!
Running 16-bit test…PASSED!
Running 8-bit test…PASSED!
– Exiting main() –
So what happens is that the different peripherals are mapped into memory at different locations. On my board, my 64mb of ram is mapped at $8C00 0000-$8FFF FFFF. And how easy is it to read and write to the memory? Check this out:
Defined in an automatically generated header: #define XPAR_DDR_SDRAM_MPMC_BASEADDR 0×8C000000
Xuint32* myram = XPAR_DDR_SDRAM_MPMC_BASEADDR; //declare a pointer to the start of the memory block
myram[0] = 0xAAAA4489;
DONE. That’s it. How much easier can it get!@#
I’m hoping that on Sunday I get some time to spend extending their provided examples. Maybe set up something where it can read in stuff via the serial port, store it in ram, and then spit it back out…
Permalink
06.28.09
Posted in Amiga Floppy at 9:24 pm by admin
So awhile ago I bought a quad core machine which runs Vista 64. Once I had the new machine, I tried getting my build environment for the AFP working again. NetBeans, the java IDE I use, has 64-bit support but there were a host of issues regarding FTDI drivers, jd2xx, etc which I fought over and eventually gave up. I was getting error messages like “Can’t load IA 32-bit .dll on a AMD 64-bit platform” and there was a serious conflict between 32 bit and 64 bit JVM, JDK, DLL’s etc etc. Pain in the butt.
I’ve had some time to work on stuff the last couple days and sit down and re-attack the problem. I did manage to solve it by uninstalling anything Java that is 64-bit. I believe it was just the JDK and JVM. I also had to reinstall NetBeans because it links itself to a JDK —- once it was uninstalled, NetBeans would literally not boot with a link. I looked all over NetBeans for something that defines a “target.” You know, something where I can say “I want to build applications for 64-bit” or “32-bit” or whatever. I couldn’t find it. I uninstalled NetBeans, reinstalled it (this time it detected and recognized the 32-bit JDK), and voila, my java client now loads, builds, and runs correctly!@#
I hooked up my AFP again, and attempted to image and disk, and there were major problems. Do you remember this post? This time it actually wasn’t that bad. Another time somehow one of my SX28 pins were fried.
I’ve always wanted to do an extended UART data transfer test. I’ve never really done this and I think it has been a big source of problems from the beginning. Even though I checked the UART carefully for cycle counts(and done this 239408 times), put it on the logic analyzer, and even had someone else review it, there must have been a mistake. I was corrupting about 3-5 bytes for every 100,000. Not tons, but enough to show up during a disk transfer.
I started out really looking into my UART. When bytes were corrupted, they were corrupted in exactly the same way:
The first data bit that was a 1-bit was ignored, and the data only started being received after the next one bit. Let me give an example:
Let’s say the correct byte was : dec 138, or binary 1000 1010. It would be received as dec 10 or 0000 1010.
correct byte might be : dec 39 or binary 0010 0111. It would be received as dec 7, or 0000 0111.
correct byte might be: dec 166 or binary 1010 0110. It might be rx’d as dec 38, or 0010 0110.
Remember, this only happened as an exception.
I eventually tweaked my UART by shortening the delay between the start bit and the first data bit, and also the time between bits by 20ns. I’m honestly not sure why that worked, and it was mostly found by trial and error. But it had a profound and instant effect. I was running trials and counting the number of bad bytes per 655k of transfer. I was anywhere between 33-42 bad bytes per 655k. When I made the change, it jumped to 0 !!
As a matter of fact, I just finished sending 284 megabytes (or 2.84 gigabits) of traffic through it without a single bit error! I think that’s pretty decent. The funny thing, I fired up “calc” to do some quick math, and I think the cpu interruption, or disk access, or something, caused me to lose some data. In the actual real client, it would have automatically retransmitted the track, so it’s not the end of the world.
Once I fixed the uart, it started reading disks correctly again.
I’m pretty happy to see this thing working again. Maybe I’ll read in some more amiga floppies tonight!
Permalink
06.25.09
Posted in Amiga Floppy at 6:31 pm by admin
So I’m using an XOR checksum to detect errors in the transfer between the SX and the PC. I always thought it was a reasonably strong checksum, even though it’s still an 8 bit checksum.
I found a neat article today here.
“The XOR checksum has the highest probability of undetected errors for all checksum algorithms in this study, and is not as effective as addition-based checksums for general purpose error detection uses.”
There were around 6 or 7 different checksums presented.
More later.
Permalink
05.18.09
Posted in Amiga Floppy at 1:21 am by admin
So tonight, just for the fun of it, I decided to sand, by hand, a 556 timer IC.
I just bought an extremely inexpensive microscope and was very interested to see what pictures I could get from it.
Unfortunately, for me, this was a trial and error process. I started with something like this:
and then after some sanding with 60grit sandpaper to remove basically the top half, this is what I ended up with
And then I switched to 320 grit, and after a couple of hours of sanding by hand, I ended up with
And then after some more time sanding, the center copper piece w/ what was left of the traces simply plucked off. I sanded and sanded more, but there was nothing left.
Now, just before this, I had just a center block of shiny copper, and then after some brief sanding ended up with some gray-ish speckled “layer.” I put it under the microscope and couldn’t see any pattern, couldn’t see anything discernible from just some scratches. I didn’t try putting it under a lot of power or anything, perhaps only at 80x or so — nothing in the least bit interesting.
I can’t help but now feel that I screwed up and should have tried that gray-ish layer under more power, I believe that might have been what I was looking for.
Permalink
04.25.09
Posted in Amiga Floppy at 1:54 am by admin
I followed the instructions at http://www.bumwine.com/tivo.html but when I tried to expand the partition after the copy, it failed with the following error:
Primary volume header corrupt, trying backup.
Secondary volume header corrupt, giving up.
mfs_load_volume_header: Bad checksum.
Unable to open MFS drives.
So I downloaded the MFSLive Linux Boot CD 1.4 from http://www.mfslive.org/
and issued the command mfsadd -x /dev/sda -r 4. Where /dev/sda is the name of the destination copied drive that needs expanding, from cat /proc/partitions.
Everything (edit: did not — see below) work(ed) perfectly. I would probably just suggest following the FAQ/guide for MFSLive Boot CD, using the backup/restore commands.
The drive I bought was the Western Digital 1.5TB green drive from newegg.
Permalink
« Previous entries Next Page » Next Page »
