Darrin wrote:
Doh! Where's the slaps-myself-on-head smiley!!! Sorry about that Sascha. Your core is still the one I use daily.
I see what you mean. Snapshot would at least let you know what is being worked on and what isn't so you could avoid duplication and allow you to pick up pointers, spot some bugs or suggest an alternative approach.
Don't hit yourself to hard Darrin
Compared to Dennis and Jakub I did just minor changes and addons to the core and currently Im just testing some little things.
One reason is the little time to code and (you hit the point) the unknown implementation of new features.
My skills in Verilog certainly is below Jakub and Dennis but still could be useful. At least to try out some features and make tests.
I love to find out bugs and report to help fixing them. Means also unfinished code and features can be quite interresting. On Linux some new kernel releases don't work properly on some platforms, but the community itself can help finding the bug by testing it and making bug reports!
My suggestion to this matter is: Releasing more little (imperfect) changes can also be very nice instead of waiting "a long time" for a big new release. In non open source projects one don't have any other choice but to wait. In open source all steps should be public property to share even the little steps.
In fact this is nothing new, it is GPL
Anyway, a new idea to Jakub:
What about using (selectable) scanline-emulation in 31KHz video mode? This would make the scandouble screenmode look more native as on retro 15KHz PAL/NTSC screen!
Realization: Every 2nd (doubled) line will be displayed half as bright as the original 1st line.
I gave it a try with some good ideas from RedskullDC, but unfortunately it did never work. Since your current modifications in Amber.v I never try again
The FPGA did not have enough room left for an additional scanline buffer, so Redskull & me tried to masquerade the 2nd line... I only saw a destroyed picture and passed out.
Here is the construct (in theory) by Redskull.
Code:
Hi Sascha,
Good to hear from you
[...]
To be able to know where on the screen it is, the Amber module needs the "sof" (start of frame) and "sol" (start of line) signals:
(same as the Denise modeule gets)
.sol(sol),
.sof(sof),
Inside Amber, track the Odd/even state of the vertical line with a 1 bit signal (verbeam):
//Amber local vertical beamcounter
always @(posedge vgaclk)
if(sof)
verbeam<=0;
else if(sol)
verbeam<=~verbeam;
At start of frame, verbeam is set to ZERO.
Will then flip state for each new vga line.
Next, have 2 hires bufs, 1 shifted to the right (half as intense)
discarding the least significant bit of the 4bit colour data
//latch data for hires pixel at falling edge of clk (hires is double pumped, see Denise)
always @(negedge clk)
hresbuf[11:0]<={redin2[3:0],greenin2[3:0],bluein2[3:0]};
hresbuf2[11:0]<={1b0,redin2[3:1],1b0,greenin2[3:1],1b0,bluein2[3:1]};
Down at the bottom of the module:
Set up a second line buffer ( if sufficient RAM avail in the S3400?)
using the shifted hirebuf2, plus similar shifts in low byte.
always @(posedge clk)
linebuf[addr[8:0]]<={hresbuf,redin2[3:0],greenin2[3:0],bluein2[3:0],_hcsync,addr[9]};
linebuf2[addr[8:0]]<={hresbuf2,1b0,redin2[3:1],1b0,greenin2[3:1],1b0,bluein2[3:1],_hcsync,addr[9]};
.....
always @(posedge vgaclk)
if(vce && !vgahorbeam[0])
if (!verbeam)
// even line, display as normal
vgadata<=linebuf[vgahorbeam[9:1]];
else
// odd line, show the half intensity data
vgadata<=linebuf2[vgahorbeam[9:1]];
Hope this helps.
Cheers,
Leslie
Redskull @ Digital Corruption
Since then many things have changed in the core.
Maybe you are able to build in this nice feature
Sascha
PS: See, some other parties are also developing on Minimig core and nobody knows for sure what and where the current state is.... Therefor we need a central place to share and base on. It could be this forum or the already mentioned sourceforge
Login
Register
FAQ
Search
