FPGA VGA Controller for 8-bit computer

[nockieboy]

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.

What a stroke of luck, I'd already downloaded PulseView last week when I was first looking at decoding the .CSV file you'd posted.  It works really well with the .SR - makes viewing the data very easy.  Yes, there are some glitches in the data and the protocol decoder seems to be confusing commands with responses in the decoded values, but that's no problem - the important thing is that I can see what's going on at a clock-by-clock level.   It's a shame there isn't a single block write in there, that would really allow me to make a direct comparison with my SignalTap traces (no idea how or even if you could do that), but it's an excellent start - thanks very much for your work on this, pcprogrammer!

Hopefully I'll have more time later this week to really dig into the data.

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.

Will do BrianHG and thanks again for this fantastic project.  Once I've got the SD interface sorted, I'll have to write a game like the one you linked previously.

[nockieboy]

Quick update.  Had a little time to look at the data @pcprogrammer posted of his SD write transaction in PulseView and do some graphical comparisons with my own SignalTap data from the uCOM's SD interface.

Nothing major to report so far, other than the clock is inverted in the data you've provided, @pcprogrammer.

Other than that, I've compared the response to my CMD24 (single block write) with the CMD25 (multi-block write) command in your data, and found that what I previously thought was an error report in this post actually appears to be a correct and normal response, as it mirrors the response @pcprogrammer gets when his FNIRSI (is that what it is?) sends CMD25.  Here's a pic to illustrate the point:



So as far as I can tell, my SD interface is sending the command to write to the SD card okay.  I'm going to have to look at other issues - the first being the timing.  There's a large gap between the response from the SD card after CMD24 is sent and the data block being written to the SD card, due to how the HDL handles the CMD transaction (I didn't write that HDL, but looks like I'll have to have a closer look at it).

(The image shows the SignalTap trace from my SD interface's CMD24 response, overlaid with the CMD25 response from @pcprogrammer's data.)

[pcprogrammer]

@pcprogrammer gets when his FNIRSI (is that what it is?) sends CMD25.

Yes it is the FNIRSI-1013D, but it will be the same for all these devices using the F1C100s MCU.

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.

[nockieboy]

At least you found one difference between the two sets of data

Yes, and it's cleared up some confusion over the response to the write command!

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.

Unfortunately no, it would appear not.  SignalTap is fairly restrictive in how it can export the data - CSV is the only format compatible with PulseView, and I haven't worked out how to import it into PulseView yet without crashing it.

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.

Nothing is ever straightforward, is it?    I did consider that the difference in phase might not be due to error and could be the cause of the issue, but that possibility can be discounted when you realise I have a fully functional READ side to the interface, using the same clock and phase.  Unless reads are done differently.

You gave me sufficient doubt to compile a new version of the interface with an inverted SD clock - this didn't work at all (reads were broken), so I tried another build with just an inverted WRITE clock, just for the hell of it.  SignalTap reports identical waveforms to the ones you've provided from your FNIRSI.  Communication with the SD card still worked - the commands being sent were being responded to in exactly the same way as before without the inverted sd_clk - unfortunately, still no change in the outcome of the write process, though; the block of 512 bytes is written, CRC and STOP bit but still no response from the SD card. 

[pcprogrammer]

That is a bummer. It's these kind of things that can drive you nuts

Have you considered trying it with a lower clock speed?

FPGA retro computing is on my to do list and I believe the Xilinx Artix 7 board I have has a four bit SD card connection, but I'm still in infancy stage with modern FPGA. Also at the moment busy with the last bits of our house and that is taking a lot of energy, so not enough left to undertake such a new adventure

At first I'm thinking about just recreating a Tandy TRS-80, which was my first computer, on a Xilinx Spartan 6 board I have. Getting back in to it with ISE and work up to the Artix 7 and Zynq in Vivado. But also have to finish my DDS project Brian helped me with. The FPGA is done, but the software on the MCU needs to be made.

Lost of projects and ideas to work on.

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]

That is a bummer. It's these kind of things that can drive you nuts

Yes, this one sure is, but I've uncovered what I think could be an interesting lead.  Whilst looking at other sources of documentation about SD interfaces, I came across this application note which talks about interfacing SD cards with BlackFin processors.  I have no idea what a BlackFin processor is, but found an interesting nugget of information on page 17 under the heading 'Send Data'.  Item 5 in the list specifies exactly 4,121 clock cycles for the transaction.

Now I'd normally be very careful and sceptical about plucking random numbers from unknown sources and ascribing mystical importance to them, but in this case that number of clock cycles exactly matches the number of 'transfer cycles' (SD clock cycles, basically) used in the SD-card-controller IP core I tried previously with no luck to use (with the Wishbone interface).  I'm going to have to go back to the write function in its sd_data_serial_host module and really pick it apart to understand what those extra clocks are being used for.

My interface currently only sends 4,114 clock cycles - it is ~8 clock cycles short (give or take the STOP bit), which would explain why there's no response from the SD card at the end of the block transfer - as far as the SD card is concerned, it's still waiting for the final 8 clocks to complete the write transaction.   

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?

There've been screenshots of the video output when we were working on that, I think I posted a picture once earlier in the thread (about a year or two ago, maybe), so here's some more at the end of the post.    Yes, it's a classic Z80-based 8-bit computer, modular design but vertical-stacking instead of the more common 'cards into a motherboard'-type setup, like the RC2014.  My goal was to create something more powerful than my first computer - an Amstrad CPC 464.  That has been achieved in spades..  It has 4MB of memory, runs at 8 MHz, has a CF card for storage (hopefully soon to be upgraded to SD card!), battery-backed clock, FRAM/anything else you can stick on I2C, had an authentic AY-8192 sound card at one point (looking to replicate that in HDL at some point), and graphics on par with 16-bit consoles of the early 90's.

This breadboard shot is where it all began, with a 7-chip computer I built thanks to Grant Searle.  I knew next to nothing about electronics before that.  Still don't, now. 



This is my uCOM at an early stage.  There's a couple more cards on the stack and a DECA at the bottom of it all at the moment:



Here's a part-built prototype GPU card:



And this last one is the uCOM with an early-prototype GPU card on the top, based on the Intel/Altera EP4CE10.  I'll get round to designing and building another card one day, once supplies of Cyclone V's and/or MAX10's improve.

[BrianHG]

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.

If you don't think so, read lines 1028 and up here: https://github.com/BrianHGinc/BrianHG-DDR3-Controller/blob/9bf047511a7b38ac3fdf6dd8d5c34ce3bbeaddcc/BrianHG_DDR3/BrianHG_DDR3_PHY_SEQ_v16.sv#L1028

Look, I have a program counter called 'init_pc', and inside my line numbers, I have the equivilant of GOTO, CALL/GOSUB, Wait for interrupt, and do a specific thing at any line number I like.

[pcprogrammer]

@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?

[nockieboy]

@nockieboy

Looks good your PCB stack. Did you design the boards yourself? If so, impressive for someone who knew next to nothing about it.

Thank you. Yes, I designed them myself, although the GPU card was with a lot of help from this forum.  I know my way around a 3D graphics program so I guess PCB design just flowed on from that - I've learned a hell of a lot from the guys in this forum, especially when it got to designing the GPU card.  Up to that point, the smallest components I'd soldered were a couple of 0805 resistors, the rest was through-hole.  Now I'm happily designing for an FBGA-256 package, with 0402 components, QFNs etc. and have produced these little cards to test a suitable USB host solution - I know you can buy RP2040 cards really cheaply, the same for SAMD21 cards from Adafruit etc, but nothing I could find had a full-size (Type A) USB socket where I needed it so I could plug a keyboard in and use it as a USB host.  The CH559 is a real niche chip too with no open-source test cards for it, so I built my own:

About the number of clocks, did you also see this in the capture I made?

I haven't counted the clocks in your capture - I wasn't sure if there was some glitching and clocks were being missed out - there's gaps in the clock signal every 8 bits or so.  Plus, the transaction you've recorded is a multi-block write, so it's unlikely to have the same clock count as a single-block write.

[nockieboy]

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...

Essentially, yes.  I have a working READ example which I have built upon to add the WRITE function.  To be fair, I'm not sure where I'd have started if I'd attempted to do it all 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.

I have no issue with using a numeric sequencer - it's not too different to the state machine I'm using now, but I guess it'd be easier to read.  The problem I've had is the lack of information I can make use of.  I know it should all be in the SD spec docs, but accessing and understanding that information is no mean feat when I've been as busy as I have been.  I haven't found any explicit documentation, tables or charts explaining what a single-block WRITE transaction should look like, clock-by-clock, aside from this:



But that doesn't explain the discrepancies I've found when I calculate the bit count for a WRITE transaction and compare that with what is used in the IP core I tried initially:

START bit + 512*8 data bits + 16 CRC bits + STOP bit = 4,114 bits - not 4,122 bits which the IP core uses and now appears to be backed-up by a separate source which I found last night, so I'm going to have to look into that in more detail.

[pcprogrammer]

Well hats off to you, and indeed the forum is great. Lot of knowledge among all of us.

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.

" alt="" class="bbc_img" />

[nockieboy]

This FBGA-256 package you mention do you mount these your self or do you use an assembly service for them?

No, I'll be mounting it myself, unless I get really lazy.  I have a hot plate and a half-decent hot air gun, so I'm fairly confident I'll be able to manage it successfully after checking out lots of online information/videos and picking the brains of the good people here.   There's plenty of people in this forum who have DIY-soldered BGA chips to seek advice from.

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.

LQFPs shouldn't be an issue at all once you've gained a little confidence in mixing and using some solder paste.  My prototype GPU (pictured above) uses the EP4CE10 in an E-QFP144 package.  The only awkward part of soldering it was the ground pad beneath the package - just had to add some paste, position the chip, solder a couple of legs to pin it in place, then heat from underneath with my hot air gun to get the pad hot enough to melt the solder.  Worked fine.  For the pins, I just mixed a little flux with some cheap Chinese solder paste to make it easier to spread (and less likely to ball or form bridges) and drag-soldered the pins.  Once you get confident with the technique, you can use the flux/solder-paste for just about everything and now I find it easier than through-hole soldering. 

re: SD timings
I've had a close look at the original IP core and realise why it was calculating the payload size as 512*8 + 8.  Because the block size was set to 511, not 512 - so it was actually 511*8 + 8, which clears up the confusion about the extra 8 bits.  I think I may have identified a couple of timing issues with my HDL too, so I'll need to look closer at those.

[pcprogrammer]

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

[nockieboy]

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.

I use a loupe at the moment, but might invest in a microscope of some description as and when I get started on the final graphics card.

Yeah compensation for a wrong size can easily be overlooked. Hopefully you get it sorted out soon. Success

I'm tying myself up in knots with 0-based and 1-based counting - such basic math concepts are real issue to me for some reason, which I think is causing me a lot of confusion and mistakes in the HDL. 

[nockieboy]

Finally.

I have the write module working for the SD card.  My stubbornness has finally paid off and I've fixed the two remaining bugs that were preventing it from working!   I can now read/write to the SD card at the sector level in 512 byte blocks.  I still need to give the module the ability to switch between 1-bit and 4-bit SD modes, but it's working fine in 1-bit mode currently.  Then I just need to write some drivers for it to replace the CF card in the uCOM - yay!

[pcprogrammer]

The bus width switching is simple.

Code: [Select]

    //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);

(Left out the checks on result)

Basically a command 55 followed by a command 6.

[nockieboy]

Basically a command 55 followed by a command 6.

Yes, sending the command is simple enough, I just need to update my HDL to work in 1-bit and 4-bit mode.  It's simple enough too - just need to change from sending single bits of data down D0 like this:

Code: [Select]

sddat_o[3:0]  <= { 3'h7, writebyte[rlsb] } ;
to sending 4 bits at a time down D3-D0 something like this:

Code: [Select]

sddat_o[3:0]   <= { writebyte[7-rlsb], writebyte[6-rlsb], writebyte[5-rlsb], writebyte[4-rlsb] } ;
... and decrementing rlsb by 4 instead of 1 each sd_clk.  CRC calculations will also be modified in the same way.

Before I do that, though, I've made a start on the SD driver for the uCOM.  It won't make any material difference to the driver if the SD card works in 1-bit or 4-bit mode - one will just involve waiting about a quarter of the time for stuff to happen.

[BrianHG]

   Way to go...

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.

[nockieboy]

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.

That'd be nice, but first I have to get CP/M working with the SD card.  I'm at the bug-hunting and fixing stage with the SD BIOS and CP/M driver currently. 

[nockieboy]

Okay the operating system seems to be happy now and I've got it all running on the uCOM without the CF interface card in the stack, which is an achievement in itself.  I'm finally rid of Compact Flash as the uCOM's storage medium.  Plus the SD card is slightly quicker, even in 1-bit mode.

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?

[BrianHG]

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.

Funny, most .bmp arent compressed at all.  For .tif, there is usually a feature in the save dialog to choose since not all .tif readers can handle compressed .tif.

Anyways, here is one of my old .bmp savers : https://github.com/BrianHGinc/SystemVerilog-TestBench-BPM-picture-generator/blob/06fd942d861b9408b6644238e501734a1bc3aa7c/ellipse_generator_tb.sv#L177

Though, I believe I got the header info from wiki.

[BrianHG]

@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?

[nockieboy]

It looks like I'm temporarily retiring.
Maybe in a ~year I might re-visit GPU stuff.

Well, thanks for all your help and hard work so far!  I hope the work trying to fix that final bug in the DDR3 controller didn't burn you out.

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!)   Then I've got to finish my work on the USB HID interface.   Then integrate the sound generator.  Plenty to keep me busy for years to come at the rate I'm working currently.   I'll create new threads for any questions I have about those specific sub-projects.

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?

Good question. I don't have the free time to dedicate to software development AND HDL development at the same time, currently.  Let me spend some time putting a game or two together to see what can be done with the existing setup.

[nockieboy]

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.

[BrianHG]

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.

Ok.  So quick and simple, care to share what you did?
What did the code look like?
Can you address all 512mb?