ZX Spectrum on Pipistrello


mkarlsson

Recommended Posts

  • 3 weeks later...

In case anyone else wants to play with a Speccy and doesn't want to waste their time like I did, re-doing all the work that Joco has already done but not shared, here's some source code (and yes I tried to contact him, no response). Aaaaanywaaay...

 

The link above has Xilinx projects in the top directory for:

  • Papilio+Megawing VGA output,
  • Pipistrello+PS2_Pmod HDMI output,
  • Pipistrello+Megawing VGA output

Please note that I'm using only internal FPGA RAMB so the Papilio doesn't have enough for a 48K Spectrum, it is exactly one RAMB16 short, I guess if you don't need the scan doubler you could get away with it. Do read the readme.txt in the /docs directory for how to reduce the memory footprint to a 32K Spectrum so the project synthesizes for a Papilio (or make it use external DRAM, heh). The cool thing with the Spectrum is that it does a memory test at power on and figures out its memory range then sets some memory location with the detected RAM. The user can then run 

PRINT PEEK 23732 + PEEK 23733 * 256

to find the top of useable RAM.

 

Also something weird is going on with the Papilio, there is a 50Hz hum on the audio that seems to get louder/quieter depending on the colors on screen at the time but this hum is not there on the Pipistrello. The weird part is that there is no real difference between the Papilio and Pipistrello VHDL, literally the Papilio has some reduced RAM and different ratio on the DCM since it has a different external xtal, but the rest is the same. perhaps someone can test on their board and feed back here in case there's something dodgy with my board. Frankly, it wouldn't surprise me given my luck.

 

I just spent a few hours the other day troubleshooting another weirdness on my Pipistrello board where I had a problem with the blue VGA component color. After heaps of simulations, analyzing VHDL code, etc, it turned out to be a hardware issue, the ball on the FPGA corresponding to pin G18 had detached (or not been soldered correctly to begin with, who really can tell) as pressing down on the FPGA chip or slightly flexing the board would correct the problem. I ended up carefully reheating the FPGA with my hot air rework station and plenty of flux and it seems the problem is fixed, for now, fingers crossed :)

 

Oh and Magnus, if you want another piece of code to showcase the Pipistrello, I have Bombjack running on it with HDMI output. I did that back in March but forgot to tell anyone, eh.

Link to comment
Share on other sites

nice work as usual Alex!

Thanks especially for sharing the code. (latest revision seems to default to a 16K speccy which was nice since I forgot to edit the ram :)

No hum on my ppro board, will have to test a bit later with less background noise.

Link to comment
Share on other sites

Yeah, 32K actually. The total RAM is set by these two lines in ram.v
// virtual RAMs
reg [7:0] vram [0:16383];
reg [7:0] sram [0:16383];
Normally you'd set the SRAM to 32767 if you have enough FPGA resources to implement that amount of RAM

Thanks for testing the sound. I might have to check my board out with a scope and see what shape the waveform has. might give me a clue where it's coming from.

 

UPDATE: OK so I figured it out. I should mention that the volume on my amp was turned up pretty high so the hum was obvious to me, not so much at normal volumes. In any case in the .ucf file I had routed the audio output to one of the stereo channels and then lazily connected the "EAR" input to the other stereo channel. Because the "EAR" is an input it floats, therefore that stereo channel picks up all sorts of noise hence my problem. It is noteworthy that the Pipistrello does not have this behavior indicating it is possibly is a much quieter board, perhaps due to the use of 4 layer board, better ground planes or filter caps, not sure, just guessing here. This is not really a problem as such, unless you do silly things like me and connect things in such a way that they pick up random noise. Make sure if you use my source code to re-assign the I_EAR pin to somewhere sane, ie not to your amps input hehehe.

Link to comment
Share on other sites

I just spent a few hours the other day troubleshooting another weirdness on my Pipistrello board where I had a problem with the blue VGA component color. After heaps of simulations, analyzing VHDL code, etc, it turned out to be a hardware issue, the ball on the FPGA corresponding to pin G18 had detached (or not been soldered correctly to begin with, who really can tell) as pressing down on the FPGA chip or slightly flexing the board would correct the problem. I ended up carefully reheating the FPGA with my hot air rework station and plenty of flux and it seems the problem is fixed, for now, fingers crossed :)

 

Yeah, quality of the first set of hand-built boards was not so good, lessen learned.  The quality of the boards built in Austin is really good though, all boards in the first batch just worked without any touch-up.  Like they say in the ads, "This is done by professionals, do not try at home".

 

BTW, if anyone has a problem with one of these boards pls contact me (magnus@saanlima.com) for a board swap.

 

Also, the next batch of boards are on the way and expected in by mid-August.  Built by the same assembly shop in Austin, TX.

Link to comment
Share on other sites

  • 1 month later...

Nice - have had this working on the Papilio Pro with 32K mem and VGA on the Arcade MegaWing, and just now also on the Pipistrello over HDMI with 48K.  I notice though that in the Pipistrello HDMI version, red and green channels are swapped round - "Border 2" is supposed to give you a red border, gives green, and likewise "Border 4" gives green where it should give red.  I fixed this editing the UCF to swap the <2>s and <1>s round on TMDS_P and _N, but I don't know if there's a more 'correct' place to fix it.

Link to comment
Share on other sites

  I notice though that in the Pipistrello HDMI version, red and green channels are swapped round - "Border 2" is supposed to give you a red border, gives green, and likewise "Border 4" gives green where it should give red.  I fixed this editing the UCF to swap the <2>s and <1>s round on TMDS_P and _N, but I don't know if there's a more 'correct' place to fix it.

 

Opps, that will most likely be my fault - my DVI-D output project has this error, and it might have just been inherited .. I should really fix that! ;-)

Link to comment
Share on other sites

No, no. My fault, I should have checked :)

 

Edit: I pushed an update to the SVN fixing this issue. It was of course a pin swap error. I now went by HDMI spec 1.3 page 89 that specifies that in 24 bit RGB 4:4:4 color mode the assignment of the differential pairs (channels) is as follows: 0=blue, 1=green, 2=red

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.