6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 1:08 pm

All times are UTC




Post new topic Reply to topic  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Wed Sep 24, 2014 11:08 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Guys, thanks for your thoughts!
BigEd wrote:
Thanks EEye for taking us on this journey with you! It's easy enough for two years to pass without any visible progress, so congratulations for showing the determination to bring this design to a demo-worthy state and posting about your problems and progress...

The help I've received early on, from it seems, the most knowledgeable folk has really inspired me to continue to as far as I have progressed. If they would have said "no, that won't work" well then I probably would have believed them. But I was told the parallel video board idea would work and so I made it work even though sometimes troubleshooting was very laborious. In fact, I think I would've never even considered the project, nor even posted the idea, if I was expecting my 'ignorant' questions not to be answered.

BigEd wrote:
... I'm sure you feel satisfied that you've learnt a huge amount by battling through this far: we don't often cast ourselves back to the beginning of a project and consider what used to be mysterious to us, or what we felt to be beyond our understanding...

Looking back, the very first thing that worked in my initial Verilog coding, was reading the Synchronous RAM consistently and sending the data to the videoDAC. I think the resolution was 640x480 with a pixel clock of 25MHz (The core was capable of running 4x that speed soon afterwards). That got the wheels turning and the motivation was high., but...

Recently from my point of view, things have stagnated abit these past couple of weeks. I realized something had to change. I was making no progress, so a new board design will have to flex some more mental muscle, but my brain needs a rest from the disciplines of Verilog and PCB construction! This is the problem with a one man team.

Time for some more fun stuff with software for the next week or 2...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 25, 2014 12:30 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
The next idea was supposed to be simple but I think it shows a flaw somewhere in modification of the rng generator. It plots 65536 random pixels, random X, random Y and random color...Not spending too much time on this. There's a bit of a problem on the 1024 border vertical and horizontal, there seems to be a concentration of pixels, also too many zero values. Oh well, F it, I'm on to the next one. Pseudo Random Number Generators in HDL are not suited for the purpose I had envisioned.
1)read the rng, put a value in the color variable.
2)read the rng, put the value in X position register
3)read the rng, put the value in Y position register and autoplot.
Code:
LDA #1920               ;2430 (2200 ideal for 67.5kHz) total H cycles      @148.5MHz 16.363uS ->  61.111kHz         
                  STA hVIDEO                                                                       
                  LDA #205                 ;205                                                     
                  STA hFRONT                                                                       
                  LDA #50                  ;50                                                   
                  STA hSYNC                                                                       
                  LDA #255                 ;255                                                     
                  STA hBACK
                 
                  LDA #1080                ;1139 total     @148.5MHz ->  1139 x 16.363uS = 18.638mS = 53.654Hz
                  STA vVIDEO                                                                               
                  LDA #2                   ;2                                                             
                  STA vFRONT                                                                               
                  LDA #55                  ;55                                                           
                  STA vSYNC                                                                                 
                  LDA #2                   ;2                                                             
                  STA vBACK                                                                                                             
                 
                  LDA #%0000000000000000                  ;16-bit 565 RGB               
                  STA color
                 
                  LDA #1919
                  STA fXlen
                  LDA #1079
                  STA fYlen
                  LDA #0
                  STA fXs
                  STA fYs                  ;FILL!

                  LDX #$FFFF
rock              LDA rng
                  STA color
                 
                  LDA rng
                  STA Xp
                  LDA rng
                  STA Yp

                  DEX
                  BNE rock
                 
im                JMP im


The current rng generator:(I have modified the original code which is shown below. All credits remain, so one can search out the original code from the original authors)
Code:
//------------------------------------------------------------------------------
//    File Name:  PRBS_ANY.v
//      Version:  1.0
//         Date:  6-jul-10
//------------------------------------------------------------------------------
//
//      Company:  Xilinx, Inc.
//  Contributor:  Daniele Riccardi, Paolo Novellini
//
//   Disclaimer:  XILINX IS PROVIDING THIS DESIGN, CODE, OR
//                INFORMATION "AS IS" SOLELY FOR USE IN DEVELOPING
//                PROGRAMS AND SOLUTIONS FOR XILINX DEVICES.  BY
//                PROVIDING THIS DESIGN, CODE, OR INFORMATION AS
//                ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
//                APPLICATION OR STANDARD, XILINX IS MAKING NO
//                REPRESENTATION THAT THIS IMPLEMENTATION IS FREE
//                FROM ANY CLAIMS OF INFRINGEMENT, AND YOU ARE
//                RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY
//                REQUIRE FOR YOUR IMPLEMENTATION.  XILINX
//                EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH
//                RESPECT TO THE ADEQUACY OF THE IMPLEMENTATION,
//                INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
//                REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE
//                FROM CLAIMS OF INFRINGEMENT, IMPLIED WARRANTIES
//                OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
//                PURPOSE.
//
//                (c) Copyright 2010 Xilinx, Inc.
//                All rights reserved.
//
//--------------------------------------------------------------------------
// DESCRIPTION
//--------------------------------------------------------------------------
//   This module generates or check a PRBS pattern. The following table shows how 
//   to set the PARAMETERS for compliance to ITU-T Recommendation O.150 Section 5.
//   
//   When the CHK_MODE is "false", it uses a  LFSR strucure to generate the
//   PRBS pattern.
//   When the CHK_MODE is "true", the incoming data are loaded into prbs registers
//   and compared with the locally generated PRBS
//
//--------------------------------------------------------------------------
// PARAMETERS
//--------------------------------------------------------------------------
//   CHK_MODE     : true =>  check mode
//                  false => generate mode
//   INV_PATTERN  : true : invert prbs pattern
//                     in "generate mode" the generated prbs is inverted bit-wise at outputs
//                     in "check mode" the input data are inverted before processing
//   POLY_LENGHT  : length of the polynomial (= number of shift register stages)
//   POLY_TAP     : intermediate stage that is xor-ed with the last stage to generate to next prbs bit
//   NBITS        : bus size of DATA_IN and DATA_OUT
//
//--------------------------------------------------------------------------
// NOTES
//--------------------------------------------------------------------------
//
//
//   Set paramaters to the following values for a ITU-T compliant PRBS
//------------------------------------------------------------------------------
// POLY_LENGHT POLY_TAP INV_PATTERN  || nbr of   bit seq.   max 0      feedback   
//                                   || stages    length  sequence      stages 
//------------------------------------------------------------------------------
//     7          6       false      ||    7         127      6 ni        6, 7   (*)
//     9          5       false      ||    9         511      8 ni        5, 9   
//    11          9       false      ||   11        2047     10 ni        9,11   
//    15         14       true       ||   15       32767     15 i        14,15   
//    20          3       false      ||   20     1048575     19 ni        3,20   
//    23         18       true       ||   23     8388607     23 i        18,23   
//    29         27       true       ||   29   536870911     29 i        27,29   
//    31         28       true       ||   31  2147483647     31 i        28,31   
//
// i=inverted, ni= non-inverted
// (*) non standard
//----------------------------------------------------------------------------
//
// In the generated parallel PRBS, LSB is the first generated bit, for example
//         if the PRBS serial stream is : 000001111011... then
//         the generated PRBS with a parallelism of 3 bit becomes:
//            data_out(2) = 0  1  1  1 ...
//            data_out(1) = 0  0  1  1 ... 
//            data_out(0) = 0  0  1  0 ...
// In the received parallel PRBS, LSB is oldest bit received
//
// RESET pin is not needed for power-on reset : all registers are properly inizialized
// in the source code.
//
//------------------------------------------------------------------------------
// PINS DESCRIPTION
//------------------------------------------------------------------------------
//
//      RST          : in : syncronous reset active high
//      CLK          : in : system clock
//      DATA_IN      : in : inject error (in generate mode)
//                          data to be checked (in check mode)
//      EN           : in : enable/pause pattern generation/check
//      DATA_OUT     : out: generated prbs pattern (in generate mode)
//                          error found (in check mode)
//
//-------------------------------------------------------------------------------------------------
// History:
//      Version    : 1.0
//      Date       : 6-jul-10
//      Author     : Daniele Riccardi
//      Description: First release
//-------------------------------------------------------------------------------------------------
// no timescale needed

module PRBS_ANY(RST, CLK, EN, DATA_OUT );

  //--------------------------------------------      
  // Configuration parameters
  //--------------------------------------------      
   parameter CHK_MODE = 0;
   parameter INV_PATTERN = 0;
   parameter POLY_LENGHT = 31;
   parameter POLY_TAP = 3;
   parameter NBITS = 16;

  //--------------------------------------------      
  // Input/Outputs
  //--------------------------------------------      

   input RST;
   input CLK;
   input EN;
   output reg [NBITS - 1:0] DATA_OUT = {NBITS{1'b1}};;

  //--------------------------------------------      
  // Internal variables
  //--------------------------------------------      

   wire [1:POLY_LENGHT] prbs[NBITS:0];
   wire [NBITS - 1:0] data_in_i;
   wire [NBITS - 1:0] prbs_xor_a;
   wire [NBITS - 1:0] prbs_xor_b;
   wire [NBITS:1] prbs_msb;
   reg  [1:POLY_LENGHT]prbs_reg = {(POLY_LENGHT){1'b1}};
   reg  [NBITS - 1:0] DATA_IN;

  //--------------------------------------------      
  // Implementation
  //--------------------------------------------      

   assign data_in_i = INV_PATTERN == 0 ? DATA_IN : ( ~DATA_IN);
   assign prbs[0] = prbs_reg;
   
   genvar I;
   generate for (I=0; I<NBITS; I=I+1) begin : g1
      assign prbs_xor_a[I] = prbs[I][POLY_TAP] ^ prbs[I][POLY_LENGHT];
      assign prbs_xor_b[I] = prbs_xor_a[I] ^ data_in_i[I];
      assign prbs_msb[I+1] = CHK_MODE == 0 ? prbs_xor_a[I]  :  data_in_i[I]; 
      assign prbs[I+1] = {prbs_msb[I+1] , prbs[I][1:POLY_LENGHT-1]};
   end
   endgenerate

   always @(posedge CLK) begin
      if (RST) begin
         DATA_OUT <= {NBITS{1'b1}};
         prbs_reg <= {POLY_LENGHT{1'b1}};
         DATA_IN <= DATA_OUT;
      end
      else if(EN) begin
         DATA_OUT <= prbs_xor_b;
         prbs_reg <= prbs[NBITS];
         DATA_IN <= DATA_OUT;
      end
         else begin
            DATA_OUT <= 16'h0000;
            prbs_reg <= prbs[NBITS];
            DATA_IN <= DATA_OUT;
         end
  end

endmodule


Attachments:
File comment: 65536 pixels.
rnd pixels.JPG
rnd pixels.JPG [ 4.71 MiB | Viewed 1646 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 26, 2014 8:57 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
There is something seriously wrong with the HDL rng.

I did modify the Verilog awhile ago and it seemed to be OK for most uses, but I may have done a modification incorrectly.

Now when I utilize it for a random sample for an X coordinate, then mask the value for 1920 (AND #1919) and then another sample for a Y coordinate and mask that value for 1080 (AND #1079) I see something strange. I will post a pic before further experimentation with the rng generator code. In real-time, all random colored dots are being placed within the rectabgles as seen in the pic.

In the modified software code below (from the one above) for the random PLOT, there is the BCF0C $FFFE. BCF0C stands for Branch if Control Flag 0 is clear (i.e. zero). This branch opcode is in a constant loop testing the hsync signal as it has been wired to this control flag 0 bit in the status register of the 65Org16 cpu in the top_level design. As soon as it goes high, the cpu sends the final command to the LineGen accelerator for it to perform a single cycle plot, well within the time of an inactive hsync pulse, I'm not sure how many cycle it is though. The hardware accelerator then puts the cpu in a RDY state until the hardware accelerator is done. This results in a no address conflict between the VGA controller and the hardware accelerator, otherwise the result would be the snow effect.

Code:
rock              LDA rng
                  STA color
                 
                  LDA rng
                  AND #1919
                  STA Xp
                  LDA rng
                  AND #1079
                 
                  BCF0C $FFFFE            ;Branch if Control Flag 0 is Clear (0). CF0 is HSYNC input, so branch to itself and wait until hsync = 1, a non display period
                 
                  STA Yp                  ;PLOT! (single cycle).
                 
imp               JMP rock


Attachments:
File comment: Pseudo Random Number Generator in Verilog. Code above
PRNG incorrect function.JPG
PRNG incorrect function.JPG [ 91.37 KiB | Viewed 1616 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 26, 2014 10:08 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
EEyE:

I don't think that there is something seriously wrong with the RNG. Instead, I am thinking that the equation you are using for the modulus operation, i.e. AND #1919 and/or AND #1079, is the issue.

Using the AND #xxxxx instruction to perform a modulus operation which is intended to restrict a pseudo-random value to a particular range only works if the desired range is a power of 2. Neither the 1920 nor the 1080 ranges to which you wish to restrict your RNG samples are powers of two.

Expanding these two numbers into the binary equivalents will show you why the values are falling into little rectangles: 1919 => 111_0111_1111, and 1079 => 100_0011_0111. Those zeroes in the masks are not at all desirable.

You could try masking it with 111_1111_1111 and then checking if the number exceeds 1919 or 1079, and if does, get another sample.

_________________
Michael A.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 26, 2014 11:14 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
MichaelM wrote:
...You could try masking it with 111_1111_1111 and then checking if the number exceeds 1919 or 1079, and if does, get another sample.

Ah Michael, thanks very much!
Absolutely right. I had forgotten. There must be a mental block in there somewhere in my brain.
I've mod'd the software and it looks like this and is working almost 100%, but I've not yet added the part that checks if the number exceeds the borders...

Code:
...
rock              LDA rng
                  STA color
                 
                  LDA rng
                  AND #%0000011111111111
                  STA Xp
                  LDA rng
                  AND #%0000011111111111
                 
                  BCF0C $FFFFE            ;Branch if Control Flag 0 is Clear (0). CF0 is HSYNC input, so branch to itself and wait until hsync = 1, a non display period
                 
                  STA Yp                  ;PLOT! (single cycle)
                 
imp               JMP rock

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 27, 2014 10:16 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I needed a refresh on my 6502 software, it has been awhile! Sorry about that and thanks for the help. I took Michael's suggestion and the following software works. I will have 2 videos for this speed comparison. One using the software below, where it waits for hsync retrace to plot with no 'snow effect'. The other video will use the same software but with the 'BCFOC $FFFE' line commented out, so the hardware accelerator will plot AFAP but with the 'snow effect'. The speed difference is dramatic and I aim for the higher plotting speeds being shown in these videos, without the 'snow effect', in the next build of these video boards.

Code:
                 
rock              LDA rng
                  STA color
                 
NG                LDA rng                  ;get 16-bit sample from HDL pseudo random number generator
                  AND #%0000011111111111
                  CMP #1919
                  BCS NG                   ;if random sample is >1919 get another random sample
                  STA Xp
NG1               LDA rng
                  AND #%0000011111111111
                  CMP #1079
                  BCS NG1                 ;if random sample is >1079 get another sample
                 
                  BCF0C $FFFFE            ;Branch if Control Flag 0 is Clear (0). CF0 is HSYNC input, so branch to itself and wait until hsync = 1, a non display period
                 
                  STA Yp                  ;PLOT! (single cycle)
                 
imp               JMP rock

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 6:19 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Hit a delay. Had to backup files, reinstall OS and troubleshoot slow internet speeds. The videos are blurry, I'll have to try to fix this...
The pixel plot without delay is difficult to see what's going on since this function takes a single cycle, it creates alot of interference.
The second video is easier to see what's going on and shows artifacts from the PRNG.
Pixel Plot function with no delay.
Pixel Plot function waiting for hsync.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 8:49 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Rectangle Fill Software for 256 random rectangles to test rectangle fill HDL Still needs some work:
Code:
                  LDX #255                 ;plot 256 rectangles using PRNG and Fill Function
rock              LDA rng
                  STA color
                 
NG                LDA rng                  ;get 16-bit sample from HDL pseudo random number generator
                  AND #%0000000011111111   ;mask off 2^8 bits
                  CMP #255
                  BCS NG                   ;if random sample is >255 get another random sample
                  STA fXlen
NG1               LDA rng
                  AND #%0000000011111111   ;mask off 2^8 bits
                  CMP #255
                  BCS NG1                  ;if random sample is >255 get another sample
                  STA fYlen
NG2               LDA rng
                  AND #%0000011111111111   ;mask off 2^11 bits
                  CMP #1919
                  BCS NG2
                  STA fXs
NG3               LDA rng
                  AND #%0000011111111111   ;mask off 2^11 bits
                  CMP #1079
                  BCS NG3
                         
                  BCF0C $FFFFE            ;Branch if Control Flag 0 is Clear (0). CF0 is HSYNC input, so branch to itself and wait until hsync = 1, a non display period
                 
                  STA fYs                  ;Rectangle Fill!
                  DEX
                  BNE rock                 
imp               JMP imp

Initial static pic for testing rectangle fill:
(EDIT: I see a problem in the Verilog that is limiting the starting coordinates of the fill to <1024)


Attachments:
P1060260.JPG
P1060260.JPG [ 5.01 MiB | Viewed 1346 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Last edited by ElEctric_EyE on Mon Sep 29, 2014 11:11 am, edited 1 time in total.
Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 8:53 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 411
Location: Minnesota
This wouldn't affect much, but are the values 1919 and 1079 correct? As written it seems to me they will never be accepted, so the last column and last row will never have anything plotted on them. If the values were 1920 and 1080, then all values in the ranges 0..1919 and 0..1079 would show up on the screen.

So..writing to the color and X-position registers do nothing directly, and it's only when the Y-position is written that all three are used to produce something on the screen? Otherwise it seems there'd be no point in waiting for H-sync before writing the Y-position, as writing to any of the three would use any values that happen to be in the other two. So for instance one color would be written three times: at Old-X, Old-Y; New-X, Old-Y; and New-X, New-Y (which then become Old-X, Old-Y for the next color). Which I assume is not what you want.

Regarding the PRNG, you're throwing away a lot of the randomness by tossing out the high five bits. Restricting the range to 0..2047 instead of 0..65535 means you wind up accepting a lot more values than you otherwise would. For 1920, restricting the range that way means you're going to accept almost 97% of the values produced by the generator. If you used the full range you'd accept only about 3% of them. The restricted range does mean you do a lot less looping, but it might have something to do with your artifacting problem.

Or not. But you can try it and see.


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 8:57 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 411
Location: Minnesota
I see some code was posted while I was writing.

Code:
NG                LDA rng                  ;get 16-bit sample from HDL pseudo random number generator
                  AND #%0000000011111111   ;mask off 2^8 bits
                  CMP #255
                  BCS NG                   ;if random sample is >255 get another random sample


Um...after masking the value in A will be in the range 0..255. It will never be greater than 255, but this code will grab another sample if it happens to be exactly 255.


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 9:14 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
teamtempest wrote:
...So..writing to the color and X-position registers do nothing directly, and it's only when the Y-position is written that all three are used to produce something on the screen?...

That is correct, but there are other functions I am testing. I'm going down the list...Here are the spec's:
Code:
[code]8/26/2014 smg    Programming the 16-bit 2D Graphics 'LineGen' Accelerator
               
FUNCTION...............VARIABLE = 'description'....................R(ead)/W(rite)
________________________________________________________________________________
   
Line Generator............color = pixel color..........................RW
                            lx0 = X position start.....................RW
                            ly0 = Y position start.....................RW
                            lx1 = X position end.......................RW
                            ly1 = Y position end(*)....................RW
                     
Rectangle Fill............color = pixel color..........................RW
                          fXlen = Horizontal length....................RW
                          fYlen = Vertical length......................RW
                            fXs = X position start.....................RW
                            fYs = Y position start(*)..................RW
                     
Pixel Plot................color = pixel color..........................RW
                             Xp = X position...........................RW
                             Yp = Y position(*)........................RW

Read Pixel Color.............Xr = X position...........................RW
                             Yr = Y position(*)........................RW
                      colordata = 5-6-5 16bit R-G-B color data.........R
                                             
Copy & Paste Rectangle....bXlen = Horizontal length....................RW
                          bYlen = Vertical length......................RW
                            bXc = X position start of copy.............RW
                            bYc = Y position start of copy.............RW
                            bXp = X position start of paste............RW
                            bYp = Y position start of paste(*).........RW
                       
Character Plot............color = pixel color..........................RW
                         bcolor = background pixel color...............RW
                            Att = ASCII character + font...............RW
                             (0000000axxxxxxxx. xxxxxxxx = 8bit ASCII)
                             (a = 1 C64, a = 0 DOS. FONTS)
                             cX = X position...........................RW
                             cY = Y position(*)........................RW
                       
SIN LUT Generator........Xblock = (0..15) BRAM LUTs for X coordinates..RW
                         Yblock = (0..15) BRAM LUTs for Y coordinates..RW
                        Xoffset = placement within 1920 Horizontal.....RW
                        Yoffset = placement within 1080 Vertical.......RW
                          xfreq = # of SIN repetition within LUT1......RW
                          yfreq = # of SIN repetition within LUT2......RW
                         Xphase = (0..1023) Phase input to LUT1........RW
                         Yphase = (0..1023) Phase input to LUT2(*).....RW
                       
Square Root Generator........Xs = 16bit number.........................RW
                             Ys = 16bit number(*)......................RW
                           Root = SQRT(Xs^2 + Ys^2)....................R
________________________________________________________________________________
NOTES:
(*) This Verilog Hardware Function is initiated after a write to these registers.

[/code]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 28, 2014 9:16 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
You may have something TT, I'll check it out tomorrow! Thank you for your anaysis.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 29, 2014 2:09 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
teamtempest wrote:
...Regarding the PRNG, you're throwing away a lot of the randomness by tossing out the high five bits. Restricting the range to 0..2047 instead of 0..65535 means you wind up accepting a lot more values than you otherwise would. For 1920, restricting the range that way means you're going to accept almost 97% of the values produced by the generator. If you used the full range you'd accept only about 3% of them. The restricted range does mean you do a lot less looping, but it might have something to do with your artifacting problem.

Or not. But you can try it and see.

Very interesting. I think I could make the NBITS value programmable in the PRNG. I'll try this tomorrow. Thanks!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 29, 2014 11:47 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
teamtempest wrote:
This wouldn't affect much, but are the values 1919 and 1079 correct? As written it seems to me they will never be accepted, so the last column and last row will never have anything plotted on them. If the values were 1920 and 1080, then all values in the ranges 0..1919 and 0..1079 would show up on the screen...

I believe so. I was refreshing my knowledge from the old MOS Programming manual. From page 45 regarding the CMP instruction and associated flags, regarding the carry flag it says "...the carry flag is set when the value in memory is less than or equal to the accumulator, reset when it is greater than the accumulator.". After writing this just now, I see you're correct. I was never a strong programmer! :lol:

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
PostPosted: Mon Sep 29, 2014 12:34 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
After I noticed the problem with the random rectangular fill, I thought I should test random line drawing. Seems functional.
Code:
LDX #512                ;plot 512 random lines, during HSYNC, using HDL PRNG for Line Function
rock              LDA rng
                  STA color
                 
NG                LDA rng                  ;get 16-bit sample from HDL pseudo random number generator
                  AND #%0000011111111111   ;mask off 11 bits
                  CMP #1920
                  BCS NG                   ;if random sample is >1919 get another random sample
                 
                  STA lx0
                 
NG1               LDA rng
                  AND #%0000011111111111   ;mask off 11 bits
                  CMP #1080
                  BCS NG1                  ;if random sample is >1079 get another sample
                 
                  STA ly0
                 
NG2               LDA rng
                  AND #%0000011111111111   ;mask off 11 bits
                  CMP #1920
                  BCS NG2
                 
                  STA lx1
                 
NG3               LDA rng
                  AND #%0000011111111111   
                  CMP #1080
                  BCS NG3
                         
                  BCF0C $FFFFE            ;Branch if Control Flag 0 is Clear (0). CF0 is HSYNC input, so branch to itself and wait until hsync = 1, a non display period
                 
                  STA ly1                  ;draw Line!
                   
                  DEX
                  BNE rock                 
imp               JMP imp


Attachments:
random lines.jpg
random lines.jpg [ 1.33 MiB | Viewed 1305 times ]

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: