As I'm also intrigued by this SD card stuff I looked into it and converted the data to Sigrok input. At first I tried to do it with the Saleae format but that fails for some reason I can't put my finger on. Then I remembered some mention of the open source Sigrok project and that file format is very easy and it worked straight away
You can download the appimage for your system here: http://sigrok.org/wiki/Downloads
Edit1: Sigrok supports SD card (SD mode) protocol decoding. Saves on doing work on that
Edit2: Due to the ~50MHz signal speed and the way the logic analyzer probe is connected there are glitches in the data, but the protocol decoder seems to function properly. I noticed that the write is done with the multiple blocks command (CMD25). If the capture is not conclusive for your problem I can do another with some test software that only uses the one data line and CMD24. Just let me know if you need that.
Full final BrianHG_DDR3_Controller_v16 with VGA window system here...
@nockieboy, don't forget to update the Fork of my DDR3 controller in your Github repository using the 'Fetch upstream' function.
@pcprogrammer gets when his FNIRSI (is that what it is?) sends CMD25.
At least you found one difference between the two sets of data
Can you export the signal tap data to a file and use that in Sigrok PulseView? The protocol decoder might shed some light on the problem.
Edit: A bit strange that the clock has a different phase then yours. Could that be your problem? There is nothing on the PCB or the scope that could have inverted that signal. The SD card holder is connected straight onto the MCU with only pull-ups on the signals, and the scope logic analyzer probe was directly connected to the signals with no special settings on the scope.
That is a bummer. It's these kind of things that can drive you nuts
Did you post pictures of your project? Have not read this whole thread, but am interested to see what you have got. Believe you are using a genuine Z80 connected to the FPGA?
@nockieboy
Looks good your PCB stack. Did you design the boards yourself? If so, impressive for someone who knew next to nothing about it.
About the number of clocks, did you also see this in the capture I made?
Now I not sure whats going on, but I assume you had someone else's SD-card reader working.
Then, you piggie-backed your own writing module?
If so, this means you have to read the SD card spec anyways, right?
I did say around a month ago when this all started that you should write your own interface from scratch...
Like I was trying to tell you back then, if you wrote your own interface as a numeric 'case (program_counter_reg)' sequencer written like a assembly program with 'case(pc) ###: begin/end' using basic numbers as line counters to control the SD card, you would have been finished by now. I have even used such a sequencer in my DDR3 controller to power up & initialize the DDR3 & tune the PLL. so, I know it is well within your capabilities.
This FBGA-256 package you mention do you mount these your self or do you use an assembly service for them?
The trickiest I did so far is a lqfp-48, replacing a Chinese CS32F103 with a STM32F303. For the rest the smallest SMD was 0805 on some boards I designed for my central heating system. A raspberry pi based system with opto isolated valve control and also opto isolated 1 wire temperature sensors.
You are right about smt being easier then through hole. No snipping of the wires sticking out of the board. Having the proper tools also helps. And practice, lots of practice. A good microscope helps a lot.
Yeah compensation for a wrong size can easily be overlooked. Hopefully you get it sorted out soon. Success
//Check if 4 bit bus should be used
//Send application specific command follows command to the card
sd_command.cmdidx = 55;
sd_command.cmdarg = cardrca;
sd_command.resp_type = SD_RESPONSE_CRC | SD_RESPONSE_PRESENT;
result = sd_card_send_command(&sd_command, 0);
//Send set bus width command
sd_command.cmdidx = 6;
sd_command.cmdarg = 2;
sd_command.resp_type = SD_RESPONSE_CRC | SD_RESPONSE_PRESENT;
result = sd_card_send_command(&sd_command, 0);
Basically a command 55 followed by a command 6.
sddat_o[3:0] <= { 3'h7, writebyte[rlsb] } ;
sddat_o[3:0] <= { writebyte[7-rlsb], writebyte[6-rlsb], writebyte[5-rlsb], writebyte[4-rlsb] } ;
So, what's next?
Will we soon see a .bmp or .tif picture viewer working on your Z80. So long as you use the uncompressed variants, you should be able to copy the file into DDR3 ram and set the right window registers to view the picture with the one caveat of needing to copy the palette data to the lower palette address space for 256 color images.
Will we soon see a .bmp or .tif picture viewer working on your Z80. So long as you use the uncompressed variants...
Yeah, about that - I've just had a quick look to see how to save BMP and TIFF images without compression (I'm using Paint.NET) - it's saving them compressed, which doesn't help. I need to dig out my notes that I made previously when I put the parallax scrolling demo together on how to save uncompressed images, but I think that was raw data I was saving, not an image format like BMP or TIFF.
@BrianHG - As for what's next - aside from some minor work on CP/M programs - I'm probably going to start on moving the MMU from hardware on one of the memory cards to HDL in the FPGA, unless you have any more plans for the GPU side of things?
It looks like I'm temporarily retiring.
Maybe in a ~year I might re-visit GPU stuff.
You need to catch up and test everything I have done up until now. You will need a good strongly integrated file system and memory management working first for any new software attempts at running the sort of graphics processing you already have access to. I mean, you have access to hi-res, 32bit color, 16 or 32 layer graphics, fonts/tiles, geometry acceleration, bitmap copy and scaling. Anything new I generate will want to make use of all of that. Without some infrastructure to feed it all, if I make a major piece of HDL, how long will it take until you can show me all the new commands working?
I'll keep plugging away at the side projects in the meantime - moving the MMU to HDL will be my first priority. Once that's done I'll be able to read the MMU and discover the current bank mappings (it's write-only at the moment) without having to keep trace of them in a set of variables (which has hardly proved that accurate so far!)
I'll keep plugging away at the side projects in the meantime - moving the MMU to HDL will be my first priority. Once that's done I'll be able to read the MMU and discover the current bank mappings (it's write-only at the moment) without having to keep trace of them in a set of variables (which has hardly proved that accurate so far!)
Hmmph, well that didn't take me long. I guess I'll start playing with the AY-8910 PSG HDL and integrate that into the design.