Topic: pokey.vhd

Hi Mike,

I know you were involved in fixing the mame version of pokey.c  Does your version of pokey.vhd include all the latest fixes?  Specifically 4.6 with the changes to the poly generation?

Re: pokey.vhd

Actually we have two versions I need to merge.
I believe the poly generation is correct, but I'll look into it.

Re: pokey.vhd

MikeJ wrote:

Actually we have two versions I need to merge.
I believe the poly generation is correct, but I'll look into it.

Another problem I found was that the PIN(7 downto 0)  input seem to be inverted when I use them to read switches.  Have you used these inputs on other games as switch closures?

pin => "000" (not sw4) & (not sw3) & (not sw2) & (not sw1) & (not sw0) ;

I'm using version 002

Re: pokey.vhd

I have fixed the problems I found with pokey.vhd:

1. When reading all_pot, the bits should be inverted
2. the poly17 should be forced to all '1's when reset = '1' is asserted
3. the read of the random register should return the inversion of the bits in the poly.

Know issues.  poly9 is probably still broken, I only fixed poly17

Post's attachments

pokey.vhd 18.69 kb, 8 downloads since 2015-05-11 

You don't have the permssions to download the attachments of this post.

Re: pokey.vhd

Super, thanks. SVN is nearly up now.
I still need to merge the two versions actually....

Re: pokey.vhd

scott451 wrote:

I have fixed the problems I found with pokey.vhd:
2. the poly17 should be forced to all '1's when reset = '1' is asserted

BTW mame has this wrong as it initializes to 0x1FF7F and then a read of the random register returns the not of the first 8 bits 0x80.  The correct return value is 0x00.  My code is correct and consistent with a real pokey.

7 (edited by scott451 2018-06-02 09:50:35)

Re: pokey.vhd

Hi Mike,

I found another issue with the pokey that I have not fixed.  Do you have a newer version on the SVN?

the problem is with this code:

if (poly_sel_hp(i) = '1') and (poly_sel_hp_t1(i) = '0') then -- rising edge
    tone_gen_final(i) <= not tone_gen_final(i);

if two channels are playing the same tone, it is possible that tone_gen_final(i) starts out in opposite states for the two channels.  Then when they are summed together by:

sum12 := ('0' & vol(1)) + ('0' & vol(2));
sum34 := ('0' & vol(3)) + ('0' & vol(4));
sum := ('0' & sum12) + ('0' & sum34);

Then the two channels will cancel each other.

Thoughts?