J68 can now speak with BEMICRO MAX 10 onboard SDRAM
Modified memory controller now functioning on BEMICRO MAX 10 board
Something old, something new: building a NAS with a few older parts
New project: modifying Logitech C920 webcam for PCB inspection
Badge Computer gets battery and mounted
Memory controller work continues….workaround 4MB SRAM add-on
Cirrus Logic CS4335 DAC problems finally identified and fixed.
left-justified DAC problems continue
Trying to debug my design for an Audio DAC Cirrus Logic CS4334
J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board

J68 can now speak with BEMICRO MAX 10 onboard SDRAM

So for the longest time, I’ve wanted to use the onboard 8MB SDRAM that is present on the BEMICRO MAX 10 fpga eval board. This is now a reality!

I’ve successfully integrated a controller with some glue logic to connect to the J68.

I’ve mapped the $20000-$81FFFE to the SDRAM. All calls to ROM (stored on-FPGA FLASH) are retrieved properly, some low level RAM calls access the on-FPGA M9K memory blocks, and the UARTs are all handled fairly seemlessly.

Here’s the very simple 68K memory check routine. Obviously this can be expanded on, but it’s passing!!

lea $81fffe,a5
lea $20000,a6


move.w a5,(a5)
andi.w #$0000,d5
move.w (a5),d5
cmp.w a5,d5
bne.w printfailz
suba.l #$000002,a5
cmpa.l a5,a6
bne.w chklop
lea passesz,a0
bsr writs


Sometimes the results of success are with minimal fanfare. That’s ok with me. I understand how important this is to the project. With the J68 now being able to speak with the memory, there’s no limit in the number of applications.

There’s much more to do, though.

  • There is so much room for optimization everywhere.
    • The glue logic is probably very conservative. Working takes priority over speed.
    • I’ve got the J68 CPU at 66.67mhz, but I’ve probably got room to take it to around 90mhz.
    • The memory controller itself doesn’t allow for queued up reads.
    • There’s no cache, which should really help things.
  • I’ve got to add a simple priority arbiter for the wishbone interface to the memory. Other things have got to have access too. Like the video driver.
  • I’m currently using the ROM monitor (see previous posts for link) VUBUG.TXT to boot. This is unnecessary but we barely know what we’re doing here. Eventually, I’d like to pare down the monitor, and get the UART setup code for the console port (only a few lines of assembly), and keep some of the utility routines. Booting mostly our own code is the goal.
  • I’ve managed to add a new command the “f”-command for finally fu*king working to the rom monitor. It calls a batch of assembly, and that’s where my SDRAM test code from above sits. This gives us a way of calling our code and having access to some form of library routines.
  • Right now, I’ve got to recompile the whole system, and reprogram the whole system. I should be able to rewrite just the MIF in on-fpga flash (UFM, as it’s called) which contains memory initialization code containing the 68K machine code which spit out from the assembler.
  • and much more……..

I did manage to write a module (or two) that drives a small sainsmart serial LCD:


This allows me to display up to (8) 32-bit numbers in hex on the display at one time. Could be really useful in the future.

I also bought one of these Papilio Computing shield, because we need connectors! This is the cleanest presentation I’ve found, and should interface easy enough.


The most important interfaces are probably the VGA, for a monitor, and a couple of PS/2’s for keyboard and mice. The serial ports and audio could be real useful, too. Certainly the SDCARD slot.

So the project is moving along nicely!


Modified memory controller now functioning on BEMICRO MAX 10 board

So after some minor heartache, I’ve managed to get a working memory controller on the BEMICRO Max 10 board that is easy to use. It uses a wishbone interface.

The heart of the controller is from here but there were a few problems with it:

  • It uses a burst mode of 2. For 16-bit RAM like the IS42S16400 chip that is found onboard the Max 10, this means the user interface is 32-bits wide. The planned use for this memory controller is with the J68 softcore 68000 CPU in our Hope Badge Computer. As a result, this CPU needs a 16-bit wide interface.
  • It didn’t support byte masking. Byte masking is where you ask the controller to just return a single-byte from the lower or upper portion of the particular column location. This means that you might want the [15:8] portion of the 16-bit word, on the [7:0] portion of the 16-bit word. The CPU needs to support opcodes like “MOVE.B” — and needs a memory subsystem that can support it.
  • There was a bug in the synthesizable test bench code sdram_rw.v. The bug involves the Maximum number of reads/writes during the test. This was set to an arbitrary 200,000 32-bit writes, which works out to be about 800KB. Well the chip is 8MB, so clearly this isn’t right. The right number is 2097152. * 4 (aka 32-bits) = 8,388,608. The right number of bytes.

The changes were relatively minor for the controller itself:

  • Changing the MODE register from 12’b000000110001 to 12’b000000110000. (Set burst length from 2 to 1)
  • Removing the WRITE1_ST and READ_PRE_ST states from the “data” state machine, simply skipping to the next state.
  • Changing the wishbone interface bus widths to 16-bit instead of 32-bit
  • Adding the SEL_I() wishbone interface to support byte-masking. I think this is right choice looking at the WishBone Spec.
  • Pass the wishbone byte selection through to the DQM pins on the memory chip.

These changes will decrease the latency for a completed single cycle read by one. I have some future plans to add a cache to the front of the memory. I’ve got to read more about how these interfaces work and potentially add some priority arbitration in front of the controller.

This brings me one step closer to integrating the onboard SDRAM to the J68 softcore.

Something old, something new: building a NAS with a few older parts


About eight years ago, I bought a Dell XPS 420 pictured above. This was an Intel Core 2 Quad Q9550 running at 2.83ghz. With 8GB of ram. Despite running reliably for over 8 years, the main problem was that the case was a piece of crap. The ventilation on it was horrible, and the (2) supported hard drive slots were just ran too hot. I modded the case adding multiple 120mm fans for an improvement, but this case was never going to support more than a couple drives. Never mind, also, that the motherboard was a BTX format. You’ve read right, BTX. Not ATX. Not microatx. Not ITX. BTX. As in the supposed next gen motherboard format. It didn’t pan out. Despite being (8) years old, this processor still ran like a champ, though, and due to previously virtualizing the physical Windows 10 machine with VMware Workstation, I had no other use for the hardware.

Now enter http://www.reddit.com/r/datahoarder. These guys are my heros. I feel at home with other people storing tens to hundreds of terabytes. at home. for no reason other than to do it! I was in heaven! This was my inspiration.

Here were my goals:

  • Use my existing processor and 8GB ram. There’s nothing wrong with them, plus this processor can be OC’d, if necessary.
  • Build something with reasonable performance and obvious bottlenecks removed.
  • Make sure that the solution that I implement can be upgraded at a later date. Don’t spend money that will simply be thrown away.

Here’s what I ended up with:

PCPartPicker part list / Price breakdown by merchant

Type Item Price
CPU Intel Core 2 Quad Q9550 2.83Ghz Quad-Core Processor Purchased For $0.00
CPU Cooler Cooler Master Hyper 212 EVO 82.9 CFM Sleeve Bearing CPU Cooler $24.88 @ OutletPC
Motherboard Intel DQ45CB Micro ATX LGA775 Motherboard Purchased For $22.50
Memory Wintec Value 4GB (2 x 2GB) DDR2-800 Memory Purchased For $0.00
Memory Wintec Value 4GB (2 x 2GB) DDR2-800 Memory Purchased For $0.00
Storage PNY CS1311 120GB 2.5″ Solid State Drive $39.99 @ Best Buy
Case Cooler Master Storm Scout 2 (Black) ATX Mid Tower Case $96.99 @ Best Buy
Power Supply Antec 550W 80+ Gold Certified Fully-Modular ATX Power Supply $89.99 @ SuperBiiz
Other SAS9211-8I 8PORT Int 6GB Sata+sas Pcie 2.0 $99.35 @ Amazon
Other iStarUSA BPN-DE340SS-RED Red Color 3×5.25 to 4×3.5 SAS / SATA Trayless Hot-Swap Cage $91.00
Prices include shipping, taxes, rebates, and discounts
Total (before mail-in rebates) $474.70
Mail-in rebates -$10.00
Total $464.70
Generated by PCPartPicker 2016-11-30 17:28 EST-0500

Rationale for new parts:

CPU Cooler: Pretty popular one, and could easily dissipate the 95W from that processor. I might overclock, so that cooler gives me headroom.

Motherboard: It was $22.50 shipped, supported my processor, supported my DDR2-800 RAM, had (5) onboard SATA II’s which should support most hard drives just fine. I don’t think new compatible motherboards are made any longer for this processor. Onboard video is nice because then I can use the PCI-e 2.0 x16 slot for the SATA card below. Gigabit LAN. This part would be thrown away (along with the CPU and RAM) once I decide to upgrade.

Storage: PNY1311. This is basically the cheapest SSD that still got decent reviews. It was about $40 for the 120gb model. I’m planning on running linux. I think my current install takes around 9gb. I’ll have plenty of room. Besides, I’m not actually copying any large amounts of data to or fro on it. I don’t want to use a spinning drive for the OS boot device.

Case: Although I’m not a big fan of the shape, it has a few things going for it. It has a nice carry handle at the top. It has plenty of venting including room for (9) fans — (3) included with the purchase. It has a side window. The INTERNAL hard drive slots number about 7. The hard drive slots face OUT of the case which makes AMCs very good. The (3) external slots are very useful for the drive cage below. Supports both 2.0 USB on the front panel AND 3.0. This is perfect — 2.0 for now, 3.0 for later!

Trayless hot-swap cage: This is very nice feature. I bought the 4-banger instead of the 5-banger because the 4 inserts better than the 5. It’s great to add, move, change a drive without taking the case side off. It fits because it has specific support for rails in between the three external slots. The other versions will likely require you to mod your case! Pay attention to the slots cuts into the sides of certain units.

Power Supply: 550W should be sufficient. The processor takes 95W. I wanted to add plenty of headroom for powering drives. Fully modular is really nice for cable management.

LSI 9211-8i SATA card: This card supposedly has great Linux support, and many people in the datahoarding community recommended it. I sent an email recently about support and got emailed a useful answer back within 5 minutes!! This card supports (8) SATA ports at 6.0gbps each. I’m willing to bet this interface is faster than the on board ports!


  • (4) hot-swap trayless drive bays available with easy in/out. I’m a little worried about the small 80mm fan on the back of this. I’m going to monitor temps on these drives.
  • Physical support for about (10) drives. I’m using one of the bays for the OS boot drive SSD.
  • Proper power supply. Those drives might take as much as 250 watts PEAK on startup.
  • I think a 2.83ghz quad-core (non HT though!) should be beefy enough for a NAS box. We’ll see!
  • 8GB of RAM should also be sufficient for a mostly headless Ubuntu install.
  • While this is the physical SETUP, what’s the logical one going to be? I’m not sure. I think Ubuntu 16.04 LTS, SnapRaid, mergerfs, with rclone/crypt going to Amazon Clone Drive.

Wish list for next upgrade

  • USB 3.0 for fast flash drive access. I might buy a PCIe 2.0 x1 card for this soon!
  • Modern hyperthreaded processor. I have to learn where the bottlenecks for this current/new system would be!
  • Maybe dual gigabit with some bonding capability. Yes, I’d have to upgrade the switch too. Not sure how cost effective this is. I can see how 125MB/s isn’t going to cut it if I end up striping somehow.
  • ECC RAM for sure. Again, how much does that increase my overall costs?
  • I’d love to have most/all drives be external drive cages. Support for 10-12 drives externally!
  • NAS box pictures
  • case_verticalx900
  • case_close21800x

Please feel free to comment below. Especially if you have ideas for how to provision this box. My LSI card comes in a couple days.

UPDATE Dec 2016

I had major compatibility problems with the DQ45CB motherboard and the LSI 9211-8i card. The main problem was that the mobo detected the LSI card as a video card, and shut off the needed onboard video. When I added a PCIe x1 video card, then Ubuntu started throwing a bunch of errors. And Windows 10 wouldn’t even boot. After days of fighting to resolve the various conflicts, I simply ended up buying some new stuff. More expensive, yes, but simpler with a better end result. I ended up adding:

  • Intel E3-1275v5 processor at 3.6ghz. Quad Core / 8 Threads. Supports ECC RAM
  • Supermicro motherboard x11ssh-F-O. Supports ECC, 8 onboard SATA ports, plenty of PCIe slots, USB 3.0, and everything else you’d expect
  • 32GB of DDR4 ECC. It’s the slowest DDR available, but this is what’s supported with the CPU/mobo combination
  • A couple WD 4TB Gold drives, and a couple WD 8TB Gold drives. These are probably the best drives in the world for my application, have long 5-year warranties, high MTBFs, and I’m really hoping I get the ROI I think I’m paying for.

This is now probably more than just a NAS. It could easily host a few VMs, with processor time to spare.


  • Windows 10. Ubuntu 16.04 LTS isn’t directly supported by my motherboard, and again, I’m taking the path of least resistance. Windows 10 is fine and supports my preferred pooling solution.
  • StableBit DrivePool. Really sweet software, and it’s driving my OS choice. mergerfs on Linux seems to still have many issues to work out, and StableBit (despite being ~$56 commercial) just seems more reliable with tons of configuration features to really dial in what I need. Love it so far.
  • rclone with encrypted Amazon Cloud Drive for backup. This is my current backup solution, although it’s lacking in many ways. ACD will accept my full 150mbps pipe, which just kicks butt for fast uploading. It’s free. I still have to come up with versioning and better backup support. rclone is fantastic, but it just lacks some key features that I’d like to layer on top.
  • SnapRaid for my hashing, silent bit corruption detection, and repair needs. This software seems plenty mature, and it essentially works but I’m simply not happy with how it’s working with the rest of my setup. Maybe my setup needs to stabilize a bit before SnapRaid will make sense?


New project: modifying Logitech C920 webcam for PCB inspection



I’ve recently spent some time modifying a Logitech C920 webcam for PCB inspection and soldering. Head over to the page for project pictures, links to the various components, tricky gotchas I found during the project, and more!

Modifying Logitech C920 webcam


Badge Computer gets battery and mounted


I needed a safe way to transport the badge computer for my trip to/from Hackers on Planet Earth, and so I put this together in typical hacker fashion.

I used  small piece of plywood to mount the components. Trying to find hardware that would work and be safe was pretty tricky, but I decided that this blue painters tape does the job nicely.

You’ll see there’s a couple additions:

  • a 3800mah 7.2v NIMH cell, used for powering this via battery, making it truly portable
  • I’m using a couple of low drop out voltage regulators: LD1117V33 for the 3.3v one, and L4940V5 for the 5.0v one.
  • a FPC extension cable that allows the screen to be remotely connected to the interface board

As many of you probably know, when you use a voltage regulator, you need to account for the drop out voltage. This voltage is the smallest allowable difference allowed between the INPUT voltage (in my case +7.2v) and the desired OUTPUT voltage (which is either +5.0v or +3.3v). Otherwise the voltage regulator fails to regulate.

See wikipedia : https://en.wikipedia.org/wiki/Dropout_voltage and https://en.wikipedia.org/wiki/Low-dropout_regulator

Normal voltage regulators would not work here, because as the NIMH discharges, the voltage continuously drops from a nominal 1.2V(with this battery, in practice a little higher, about 1.36V) per cell, and then drops to 1.0V per cell when it’s exhausted. We are using a 6-cell pack, so this translates to a starting voltage of about 8.2V, and a finishing voltage around 6V.


If we used a normal 5V voltage regulator like the 7805, whose dropout voltage is as high as 2V, then as soon as we got to 5+2=7V, then we’d fail to have +5V that we could count on. This leaves plenty of battery left, but unusable given those parts.

The L4940V5 low drop out regulator I chose only has a worst-case 900mv dropout. So this gives us until 5.9V. The battery dies at 6V, so this works out perfectly. Now the actual drop out voltage is dependent on the current being pulled through it, with higher currents increasing the dropout voltage. In our case, we don’t need maximum current, which means we won’t be”paying” with the maximum drop out voltage either. The actual dropout voltage is probably closer to 200mv than 900mv.


Memory controller work continues….workaround 4MB SRAM add-on


SO here’s a couple hundred dollars of SRAM parts ordered to add on to the FPGA. It goes like this: the memory controller isn’t fully integrated yet into the J68 soft-core, so I’ve decided to whack on 4 megabytes of 10-12ns SRAM. SRAM is expensive! About $24 for good quality ISSI ram.

What you see in the center of the image above are three (80) pin card edge MEC6-140 connectors that are designed to mate with the FPGA board. I needed something to mount the SRAM chip (48-pin TSOP I) on and something to mount these 80-pin connectors on. It turns out my closest match are these Schmartboard PCBs, which I’ve wanted to check out for the longest time.

It turns out that I really don’t care for these Schmartboards, partially because I don’t have the right 0.4mm tip required for the pitches, but there’s other reasons. These likely deserve their own review which I will do in a separate post.

It turns out that when you are creating memory boards, you’ve got to deal with a lot of pins. How many? 16 data bits wide, 21 bits of address, plus 5 control pins, oh yeah (2) power and (2) ground as well. So that’s a solid 46 pins you’re using. The 80-pin connector has about (60) usable data pins, so at least the FPGA can support this application.

I do love the fact that the memory I’m using are 10-12ns chips. Really fast access times. Here’s a link to the digi-key part.

Here’s what $75 in memory chips looks like:



Of course you’ve got to create a pinout and hope you get everything right.

Below you’ll see a half-finished board with the 80-pin connector on the right, and the SRAM soldered to the board underneath the wires.


I’ve just recently completed the entire board, more photos to come on this.

While a couple initial writes and reads functioned, some reads or writes are failing. I need to write a small state machine that loops through all addresses, and then reads them back to check for errors.

Cirrus Logic CS4335 DAC problems finally identified and fixed.

I had some assistance in fixing this problem. My always helpful friend Brian from Canada as well as some help from Steve @ the Audacity forums contributed to solving the problem. They filled in some blanks for me, and encouraged me to LOOK at the data to see the problem.

This is the “Quit thinking and look” solution found in this book called “Debugging Rules”. Absolutely love this book!! Amazon link.

  • I used Signal Tap II on the Altera FPGA as an internal logic analyzer to see both address values and ROM data values, so that I could correlate them with the serial data going outbound. This was an invaluable tool. There are also tutorials on youtube. Here’s an example of the data I was able to get: (CLICK FOR FULL SIZE)


  • I was also able to use my new mixed signal scope to capture the waveforms. The data is 8khz sample rate and 16-bit audio. Check out how nicely spaced these samples are — exactly 125ms apart!


  • The data coming out of Audacity’s Export Audio (Header: RAW, Encoding: Signed 16-bit PCM) was the opposite endianness that the DAC was expecting. I switched the bytes from 0xABCD to 0xCDAB and that fixed it.
  • My overall electronic design in Verilog for this was just ugly. And initially did not work — I wasn’t putting the right data on the serial pin at the right time. The right Verilog was ridiculously simple once I distilled it down properly.
  • I’ll post the Verilog with data files once I clean them up a bit. Feel free to email me (contact info above at menu) to nudge me if I haven’t done this yet.
  • I used SRECORD to convert the output of Audacity into a .MIF to load into a virtual ROM on the altera. I could have byte-swapped during the conversion, but currently do it on the FPGA. Either way is easy enough.
  • The initial 700hz tone that I have been fighting with for awhile finally came out alright tonight. It really was music to my ears.

Voice_011 (as a .wav file download or use Embedded Player below)


Voice_012 (as an .wav file download, or use Embedded Player below)

  • I added a little more interesting sound below:

left-justified DAC problems continue

Here you see the analog sound waveform coming out of the DAC at the top in yellow.

I think I’m getting closer……I switched from the I2S DAC to a left-justified DAC just because the LJ one is a little simpler to design around….the MSB for the DATA is lined up with the LRCLK transition……

The digital channels below are the input to the DAC:

D3 is the serial data

D2 is SCLK


D0 is the MCLK


Latest audio clip:

Trying to debug my design for an Audio DAC Cirrus Logic CS4334

I purchased a CS4334 to eventually use as an Audio DAC for the badge computer. I’ve never worked with DACs before, and my knowledge of audio is somewhat limited.

This audio DAC is a Cirrus Logic CS4334 with datasheet available here.

This chip is the I2S variant, specifically not the LEFT justified or RIGHT justified one. Each variant has slightly different timing requirements. The I2S specification is located here.

The audio data is a simple 700hz tone for 4 seconds with sample rate of 8000hz, and using signed 8-bit export. The audio file is here. 8k_signed8bit_straight700hz4s <— rename the .txt to .aiff. Use “Import Raw” feature of audacity, specify 8000 sample rate, signed 8-bit pcm. I generate an altera .mif using srecord, and here’s the resulting .MIF —–> 8ksigned_700_4s.

Here’s the output that I’m hearing. There are (8) chunks of sound as far as I can tell.

There IS my 700hz sample found in one of those eight chunks. It’s the “purest” sounding chunk of sound. You’ll know it as soon as you hear. LINK if the player below doesn’t work for you.

Any help to what the heck I’m doing wrong here would be appreciated!!

Here’s my verilog:

dac_clocks dac_clocks_inst (
.areset ( 1'b0 ),
.inclk0 ( SYS_CLK ),
.c0 ( SCLK ),
.c1 ( LRCLK ),
.c2 ( MCLK ),
.locked ( USER_LED[1] )

reg [7:0] sendbyte;
wire [7:0] romout;
reg [13:0] address;

reg SDATA;
wire SCLK; //128khz
wire MCLK; //1.024mhz
wire LRCLK; //8000hz to match the sample rate

assign PMOD_B[0] = SDATA;
assign PMOD_B[1] = SCLK;
assign PMOD_B[2] = LRCLK;
assign PMOD_B[3] = MCLK;

//setup the edge detection for LRCLK

always @(posedge MCLK)

assign LRCLKfalledge=LRCLK_OLD & !LRCLK;
assign LRCLKriseedge=!LRCLK_OLD & LRCLK;

dacrom dacrom_inst (
.address ( address ),
.clock ( MCLK ),
.q ( romout )

/*this is to satisfy "In I2S mode, the MSB of the left channel is valid on the second rising
edge of BCLK[my SCLK] after the falling edge of LRCLK. Similarly, the MSB of the right channel is valid on the
second rising edge of BCLK after the rising edge of LRCLK"

reg [7:0] twocycledelay;
always @(posedge LRCLKfalledge or negedge SCLK)
if (LRCLKfalledge) twocycledelay <= 8'b0;

if (!SCLK) begin
twocycledelay <= twocycledelay + 8'b1;

if (twocycledelay == 8'd2) begin

sendbyte <= romout;
//counter <= 3'b0; //reset the bitcounter because we have a new byte

//else counter <= counter + 3'b1; //send next bit if we're not resetting



always@(posedge LRCLKfalledge) //when it's true that there's a falling edge, read the next byte
address <= address + 14'b1;
if (address == 14'd32000) address <= 14'b0; //data in rom is 32000 bytes deep

reg [2:0] counter;

//send data MSB first. is it already two's complement from audacity?
always@(negedge SCLK) //put the data on the falling edge so that the receiver can read it on rising.

SDATA <= sendbyte[3'd7-counter];
counter <= counter + 3'b1;

J68 is now booting from User Flash Memory on the BEMICRO MAX10 FPGA board

I’ve been struggling for quite a few nights and weekends over the last month or so.

I’ve now successfully attached the J68 to the built-in User Flash Memory. This means that the 16KB (actually about ~13KB) of the ROM monitor VUBUG is now out of the pre-initialized m9k’s configured as a ROM, and now into FLASH. Which is non-volatile, and will survive a reboot. The most important part of this is that it frees up our valuable high-speed on-chip m9k’s.

The solution involved waiting for rd_ena (read enable) to go high, and combining that with the address that makes it a ROM READ, and then passing that to the Altera IP Flash avalon-mm bus interface. Since the latency is a fixed-cycle delay, then I just shift that read-enable pulse to become the “data is ready pulse”, aka data_ack and feed that back to the J68.

I had some more complicated solutions including a state machine, but this way is clearly superior. I had created some bolt-on hardware to help troubleshoot the problem. While it helped initially, when I had the problem fixed, some symptoms in the add-on hardware hid the fact that it was actually working….

The SDRAM controller works in simulation when connected to the J68, and hopefully will be tested on hardware very soon. This puts the ROM code in FLASH, and the RAM on the 8MB memory chip where it belongs. This will give us what we need for future development, including the GPU!