Re: Pac-Man Hardware (multiple games)

Wolfgang, changed to 5K. Have a check of the signed/unsigned conversion when you have a moment.
We need to move/clone the rc_bypass module somewhere common.
lib\generic or lib\sound ?

27

Re: Pac-Man Hardware (multiple games)

Ok, will do tomorrow. Would like to check in some simple scripts for Octave to compare the real analogue setup with the simplified digital one (and the digital values can be also used to check the VHDL implementation). With usual analogue tolerances (5% R + T, 10% C or even more) this one should be still good enough in most cases, but such a tool will provide some way to check it properly.

Nevertheless, beside this rc setup using just some adders it might be useful to have one with actually using a multiplier stage to get a much better matching of the filter coefficient. If only one or two of these are used in a design, it should not be a big ressource topic for the FPGA...?

And yes, I would prefer a move to avoid multiple files to maintain. The general specification and interface should be/stay stable and any optimisation of its implementation will automatically end up in all designs using it. For simplicity, we can also setup one without this bypass feature?

/WoS

Re: Pac-Man Hardware (multiple games)

Ok, sounds good wink
We should certainly use the multipliers, they are highly underused.

I'd keep the bypass in the design, it's easy enough not to use it and the logic should be optimized away.
/Mike

29 (edited by olekk77 2015-02-14 22:28:26)

Re: Pac-Man Hardware (multiple games)

I know, i know, i know..., Wolfgang... except for the complex sigma delta hybrid stuff you say was used back then.
I am a realist too btw.

I doubt that half drunk youth in the 80's gave a fuck about the switching noise in the audio when they were at the arcade..
But yes.. i know what you are saying.


...............

Wolfgang... about multipliers...... what ARE you using for filter calculations if not MACS???
I have not even whiffed at filter calc in hdl yet, because i do not know how to do floating point in one clock in hdl myself (hand coded).

you don't use integer math do you?

................

whaaaat??? are you using just adders to do the filters??

hmm..... i wonder.....

Selvgjort er velgjort! wink

Re: Pac-Man Hardware (multiple games)

Nobody uses floating point. Integer maths is used - but with sufficient precision.
56 bits is enough to multiply accumulate two 24 bit samples without overflow. 48 bits gives you a SNR of over 280 dB.

Often add/subtract is all that's required if the coefficient scaling is carefully chosen. A multiplier gives you more flexibility.
In this case we are discussing using the "hard" 18x18 multipliers in the device rather than the logic array.
Each of these multipliers can do more than 100M multiplies per second, so you can time share one multiplier and use it many times in the computation of one output sample.

/MikeJ

p.s. I see you have found the edit button, progress wink

31 (edited by JimDrew 2015-02-14 23:12:00)

Re: Pac-Man Hardware (multiple games)

Yep, Pacman in the UK sounds different than Pacman in the U.S. due to the 50/60Hz noise from the power supply passed through the system.  Personally, I would like to hear a clean version of the woka-woka-woka sound.  smile

Re: Pac-Man Hardware (multiple games)

Wolfgang will be adding parametrizable 50/60Hz PSU noise before you know it .... wink

33 (edited by WoS 2015-02-14 23:58:53)

Re: Pac-Man Hardware (multiple games)

olekk77 wrote:

Wolfgang... about multipliers...... what ARE you using for filter calculations if not MACS???
I have not even whiffed at filter calc in hdl yet, because i do not know how to do floating point in one clock in hdl myself (hand coded).

you don't use integer math do you?

whaaaat??? are you using just adders to do the filters??

hmm..... i wonder.....

A multiplier is nothing else than a bunch of adders. As Mike said, the idea is to optimise the coefficients, basically only the "1" in binary representation will add up (for binary/integer math) and you can omit the adders for the "0" bits - this only makes sense in an ASIC/FPGA design, of course. There are other ways than binary as well (eg. signed digit representation) for HW design of filters with fixed coefficients, depends on the desired filter function and structure. Floating point is usually only (rarely) used on DSP processors which need to be extremely flexible for everything to come (and with pretty high effort). This is not needed/applicable in HW design, especially not for a fixed filter with the complexity required here (and then not even on a DSP).

Here we use integers for the signal and coefficients (or fixpoint which is just a scaled representation of integers). But I "calculate parameters on the fly" from physical floating point parameters of the real filter to replicate (R, C, sample freq. of the system) during the synthesis process of the VHDL code, so no need to bother with calculating coefficients for this filter to use it. And this step I have optimised to the accuracy the real filters of such arcade boards (20% corner freq. variation or even worse sometimes).

A MAC is just a generic, predefined structure to build filters (sequential with one instance or pipelined with several instances). I use as well a multiplier/adder plus register so to say - just spent some time and optimised it for this classic RC Butterworth filter setup - so I would not call it MAC as you can't simply take the structure and build some other filter without adopting it.

Edit: What is still missing is a better implementation of the simple R network DAC set up with discrete elements. Mike (Pacman,...) and I (Galaga,...) have a design which assumes perfect matching of these (so a linear D/A conversion). Practically it is far away from linear, they have a horrible DNL/INL which makes for sure a significant part of the sound. So what I would like to set up next is a block which allows to specify the resistor values used to define a proper transfer characteristic of this converter. Then it will behave basically the same as the real design does.

/WoS

Re: Pac-Man Hardware (multiple games)

OK! Wolfgang.

Yeeeees, Mike, i found the edit button... damn it was well hidden... big_smile
About the paramed psu noise "feature"..... hahahaha big_smile good one!

Selvgjort er velgjort! wink

Re: Pac-Man Hardware (multiple games)

"So what I would like to set up next is a block which allows to specify the resistor values used to define a proper transfer characteristic of this converter. Then it will behave basically the same as the real design does."

We need something similar for the SID as well, especially given the DAC error in the 6581.

36 (edited by olekk77 2015-02-15 00:59:57)

Re: Pac-Man Hardware (multiple games)

What are you saying, Mike?...... a block?? a hdl block??
Also... about personification of older dacs when replicated in fpga and played back via a modern and more precise dac....... a look up table for each dac value?? so that one can "emulate" the errors in the older dac's linearity??? not a bad idea?!.... not too large a table either... so few bits.... it would still be "static" though.. and not dynamic in regard to modelling opamp behaviour..

Is it all worth it??...... sigh..... to some...

Hmm.....

Lookups for older dacs non linearities....
It's dirty, but i like it.... i hate look up tables though...
Would it be worth the ram resources on the fpga though... that's another question...
I don't know if this is at all what you were talking about, Mike.. but....

Selvgjort er velgjort! wink

37 (edited by WoS 2015-02-15 12:38:21)

Re: Pac-Man Hardware (multiple games)

I did something like this already, just need to dig it up.

You can then just specify the size of the DAC (input bit width), the desired bitwidth of the output signal (wider signal -> better reproduction of the nonlinear stages, but again it does not make sense to go better than lets say 5% of the accuracy of the resistors used in a real setup, which means output width ~ input width + 5 bit or so is more than enough) - we could have this even hardcoded - and the resistor values (again as "real" parameters in Ohms) to calculate the actual weight of each bit for synthesis.  The very same block could be also used for the RGB DACs on video out and is very simple to set up without doing any manual math and will be always correct by design.

A full LUT for the whole DAC would require (2^bitwidth) entries, this would work for this small 4 bit DACs in Pacman and Galaga (16 x output width bits), but it is not really efficient anymore for larger DACs. So I would not go this way for a generic IP block.

The cost can be reduced to just one conditional adder for each input bit of the DAC summed up to the output value (not as LUT but as parallel adder chain), exactly the same happens in the analogue setup (it is just a summation point of currents from "pull-up" resistors  to "pull-down" resistors which are defined by the input bits set 1/0 resulting in the output voltage). I'd just add a output register running with the (fast) system clock to ensure we get a proper timing at P&R, this delay is not visible as long as the system clock is higher than the actual sample clock used by the original setup.

And we can have one more adder with some pseudo-random noise generator with a period of 50Hz/60Hz (e.g. a LFSR) to replicate the distortions from the supply line, if someone want's to have the sound really dirty, similar to the good old scanlines  big_smile

The ressource costs of the FPGA should be quite negligible for this.

Edit: yes, can be used for the SID DAC as well, but there it still the need for a nonlinear MOS model to implement the proper saturation effects of the audio signal in some cases. I read some interesting papers on this on the web, proposing some solutions. For analogue it would mean to set up a transistor design using devices with the very same properties - which is either not practical (as long as you have not bought the fab these days to set up your own dies in this technology wink ...) or not accurate enough. This can be really the strength of the digital setup (e.g. using some spline line interpolation methods, maybe even handled by a small DSP/sequencer to save ressources), and the only way to replicate this sound close to the reality for the future.

/WoS

38

Re: Pac-Man Hardware (multiple games)

MikeJ wrote:

Wolfgang, changed to 5K. Have a check of the signed/unsigned conversion when you have a moment.

Checked the code, should be ok this way. I tried to set up a simulation with the actual code checked in, I got out it is not compile-able yet? Some files seem to be renamed and some PS2 stuff (constants) are not found...

I had a look how the rc filter is sampled. Currently it uses directly the system clock as I can see. This has some disadvantages: the corner frequency of the filter is much, much lower than the sample frequency (3k/24.5M = 1.2e-4), this means the required coefficient for the filter needs to be unnecessarily large in width to be "good enough" (which is not the case with the current implementation).

This causes that the resulting corner frequency is quite a bit off the desired one. It would be better to use clk_en_i with some lower frequency, e.g. the sample frequency the Pacman board is using for its frequency synthesis setup or it should be possible to use the sample frequency of the output DAC as well (then the filter also acts as sample rate converter).

Then the ratio of fc/fsamp gets smaller (but still far away from the Nyquist limit) and the filter will match better to reality.

I had an Octave prog checked in for the VIC core (in docs), but I actually rework it to fit to the actual rc_bypass structure and put it somewhere in a doc directory near the VHDL code.

/WoS

Re: Pac-Man Hardware (multiple games)

If you move the rc_bypass module I will update the scripts and check in.
I've just renamed the double scan module and will check everything in shortly.
The simulation in /tb (run comp.bat to compile everything) should work as is.

ok, it's easy to change to using a clock enable here. This would give a frequency of 6.144 MHz.

It should look like this at the top of the core then.

   -- ~24 MHZ
  clk_audio <= i_clk_sys; -- soft assign (could be sys clock)
  rst_audio <= i_rst_sys;
  ena_audio <= i_ena_sys;

  o_clk_aud <= clk_audio;
  o_ena_aud <=ena_audio;
  o_rst_aud <= rst_audio;

I'll make the changes.

40 (edited by WoS 2015-02-15 14:16:50)

Re: Pac-Man Hardware (multiple games)

Ah great. I can do a comparison of the two frequencies to check the difference between these two sample rates.

Edit: I'll also add an additonal model in the Octave setup with a much larger bitwidth, later on I can set up an additional accuracy generic in the model enabling the FPGA multiplier.

/WoS

Re: Pac-Man Hardware (multiple games)

I've just made a (hopefully) final change to the library wrapper to add the other IO pins to the core (for the JAMMA inputs).
Also added generics to remove the DRAM/FILEIO module if required for the minimal loader design.
Just testing a build now, then I'll check everything in.
/M

42

Re: Pac-Man Hardware (multiple games)

I just saw (while checking with Octave) that the rc_bypass code I use with Phoenix is totally outdated and partially the parameter calculation isn't correct - it is still a low-pass, though wink . I'll update this one as well with some significant updates, together with a stand-alone testbench for it. The interface will stay the same, so it will be a 1:1 replacement.

/WoS

Re: Pac-Man Hardware (multiple games)

Should all be checked in. I'm going to do some more tidying up with the template design, loader and scripting etc.

I'm coming round to the idea of all lower case filenames as well.... This is your preference as well?
I won't change the libs yet, but may change pacman and loader ....

44

Re: Pac-Man Hardware (multiple games)

Up to now I didn't care and win is not case sensitive. But might be a good idea to avoid problems with other case-sensitive OS.

But you may run in troubles with SVN together with the Windows frontend when changing filenames just to lowercase (I can remember this was not so easy to do). Even if done on the repository directly, on existing (checked out) local repositories SVN will update the files but the problem might be that Windows won't change the name to lowercase locally as it can not differentiate it.

You can try to change on some files and send me a note, then I can try an update here and check if it did work out.

/WoS

Re: Pac-Man Hardware (multiple games)

I've temporarily added rc_bypass in the pacman directory, will remove when it's in lib.
Running

replay_lib/tb/comp.bat
pacman/tb/comp.bat
simulate top Pacman_Tb.vhd

works fine (assuming unisim is already set up)
Note, I checked in replay_tib/tb/comp_lib.bat to compile unisim from scratch.
/MikeJ

46 (edited by WoS 2015-02-15 16:21:04)

Re: Pac-Man Hardware (multiple games)

Having done some checks. 6MHz sample rate provides a slightly better result than 24MHz.
Improvement for a 18bit multiplier is quite small compared to 4 shift/add structures. A single shift/add is still usable, but a little off the optimal result (independent of 6MHz/24MHz sample rate).

24.5MHz:

octave:152> rc_bypass(5,10,1/24576000)
fc =  3183.1

Transfer function 'Hs' from input 'u1' to output ...

           1
 y1:  ------------
      5e-005 s + 1

Continuous-time model.
---------------------------------------------
wc_dig = 8.1380e-004
alpha = 8.1314e-004
bitwidth =  11
fp_coefficient = 0.000000000011010101
alpha_dig = 8.1253e-004
alpha_error_percent =  0.074997

Transfer function 'Hz' from input 'u1' to output ...

            1
 y1:  -------------
      1231 z - 1230

Sampling time: 4.06901e-008 s
Discrete-time model.
---------------------------------------------
fp_coefficient = 0.00000000001101
alpha_dig = 7.9346e-004
alpha_error_percent =  2.4207

Transfer function 'Hz' from input 'u1' to output ...

            1
 y1:  -------------
      1260 z - 1259

Sampling time: 4.06901e-008 s
Discrete-time model.
---------------------------------------------
fp_coefficient = 0.00000000001
alpha_dig = 4.8828e-004
alpha_error_percent =  39.951

Transfer function 'Hz' from input 'u1' to output ...

            1
 y1:  -------------
      2048 z - 2047

Sampling time: 4.06901e-008 s
Discrete-time model.

24.5/4MHz:

octave:153> rc_bypass(5,10,4/24576000)
fc =  3183.1

Transfer function 'Hs' from input 'u1' to output ...

           1
 y1:  ------------
      5e-005 s + 1

Continuous-time model.
---------------------------------------------
wc_dig =  0.0032552
alpha =  0.0032446
bitwidth =  9
fp_coefficient = 0.000000001101010011
alpha_dig =  0.0032463
alpha_error_percent = -0.051193

Transfer function 'Hz' from input 'u1' to output ...

           1
 y1:  -----------
      308 z - 307

Sampling time: 1.6276e-007 s
Discrete-time model.
---------------------------------------------
fp_coefficient = 0.000000001101
alpha_dig =  0.0031738
alpha_error_percent =  2.1826

Transfer function 'Hz' from input 'u1' to output ...

             1
 y1:  ---------------
      315.1 z - 314.1

Sampling time: 1.6276e-007 s
Discrete-time model.
---------------------------------------------
fp_coefficient = 0.000000001
alpha_dig =  0.0019531
alpha_error_percent =  39.805

Transfer function 'Hz' from input 'u1' to output ...

           1
 y1:  -----------
      512 z - 511

Sampling time: 1.6276e-007 s
Discrete-time model.

Now will update the VHDL code and check everything in...

Edit: here also the bode plot (attenuation in dB over frequency in Hz; 6MHz sample rate, 24MHz looks quite the same). All lines are very close to the analogue implementation (thick green), except the single-adder setup shown in red ("low accuracy" setting in the rc_bypass block). So there is really no need for a full multiplier design...

Post's attachments

bode.png
bode.png 25.37 kb, file has never been downloaded. 

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

Re: Pac-Man Hardware (multiple games)

Super. It sounds a lot nicer actually with the 6MHz rate and resistor change.
Edit - was probably the resistor change then.

Shall we go for lower case filenames b.t.w ?

48

Re: Pac-Man Hardware (multiple games)

Yes, as proposed maybe you try with a few files first and I try to update and see if it works under Windows (or if I can't "see" the change after an update....)

/WoS

Re: Pac-Man Hardware (multiple games)

Seems to work for me in a quick test. I'll do pacman and loader a little later.
/Mike

50 (edited by WoS 2015-02-15 20:00:33)

Re: Pac-Man Hardware (multiple games)

Checked in an updated rc_bypass model plus a Octave script to compare analogue versus digital (magnitude/phase) and to compare it also with a VHDL simulation (via step response):

Edit: moved to --> hw\replay\cores\lib\generic\filters\rc_butter_1O
as it may be used for sound and video parts...

Simulation VHDL vs. Octave looks fine with your parameters, but have not tried a synthesis run yet with the new code...

/WoS