Category - Badge Computer

SRAM PCB built, populated, and is testing good!
New SRAM PCB is being built
J68 can now speak with BEMICRO MAX 10 onboard SDRAM
Modified memory controller now functioning on BEMICRO MAX 10 board
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

SRAM PCB built, populated, and is testing good!

The circuit board arrived from Elecrow PCB in China, and it works without modification! My friend Brian from Canada helped me out again, laying out this PCB in short order. He did a great job!

Soldering the half-mm pitch and MEC6-140 connector turned out to be quite a challenge. This is mostly because I’m out of practice. I have since also added the necessary filtering caps to ensure a clean signal.

Here’s an image of the board attached to the FPGA eval board. It’s tiny. 1.9 x 1.6 inches!

I think it looks sharp, but more importantly, the SRAM has 10ns access time consistently, and the interface is easy peasy! No more messing around with SDRAM. We still have the 8MB SDRAM available, albeit with a longer latency.

This circuit board will be our frame buffer. The CPU will (mostly) write to it, and the video driver will read from it. The 4MB size is plenty of room for high resolution and color depth. Even better there’s room for another 4MB if need be!

New SRAM PCB is being built

So up to two SRAMs can be installed on this tiny 2″ x 2″ board. To the right is the connector, and the SRAMs are on the left. With current SRAM sizes, you can install 32-megabit SRAMs. That’s 4 Megabyte each. This will be in addition to the 8MB onboard SDRAM.

Our current memory controller, while integrated and functioning fine, is just too slow. I already have the SRAMs and the connectors, from my previous attempt hardwire attempt. See bottom photo at previous link. But there were hardware “bugs”, maybe solder bridges or wiring mistakes, that I simply didn’t feel like messing around with. This PCB is a heck of a lot cleaner solution, and the chance for problems will be lower. The signal quality will be much better.

I’m in the process of writing a Finite State Machine to perform an independent test of the memory. And then I’ve got to find a place in the memory map for it, and then write some glue logic to integrate it. This should be easier now that I’ve done the FLASH(the UFM) and the SDRAM.

The SDRAM controller has really high latency (on the order of 8+ cycles) and while there were probably workarounds, the single-cycle 10ns latency of these SRAMs is just so attractive, that I think I’m shooting myself in the foot by not chasing the solution down earlier.

I submitted this PCB to Elecrow PCB in China. I had originally tried using 3pcb/pcbway, but their lack of communication and bait-and-switch pricing quote practically ensured my lack of business. Elecrow, on the other hand, has been great with communication. Their pricing is great. I ordered red-colored PCBs for no extra charge and I’m really looking forward to getting them. I paid extra for their rush service, and for fedex. I could have them as early as the end of the week, but we’ll see!

Again, I have to thank my friend Brian for his kicad skills. It would have taken me much longer, with questionable results.

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.

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 : and

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:


UPDATE March 2017: You can download the entire Altera project directory here. The important files are the *_top.v file(contains the important serializer logic), dac_clocks(generates 256khz and 1.024mhz clocks from 50mhz onboard), and dacrom(loads the .MIF that contains the audio data). There might be other red-herring or unrelated (prior failed implementations) files in .rar, but I’m including them for completeness.

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!