<![CDATA[FPGA Arcade]]> http://www.fpgaarcade.com/punbb/index.php Mon, 24 Apr 2017 18:19:46 +0000 PunBB <![CDATA[Rs232]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1255&action=new Windows 10, I'm gonna try with your infos and see if it's working thanks
Kamelito

]]>
Mon, 24 Apr 2017 18:19:46 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1255&action=new
<![CDATA[FPGA Recreations]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=200&action=new Bumping this thread to add my opinion as I've been pondering this for the last few evenings whilst looking into doing an Acorn Electron core. This is my current view on how I'd like to approach it, however, as I've yet to implement a core this  is in no way a suggestion of the "right" way. For all I know this approach is doomed to failure.

The way I've gone with the initial implementation is one of externally pin identical, but internally just functionally identical. By functionally identical I mean I see any kind of initial implementation of the innards of the IC as fine as long as it externally appears to work the same as the original IC.

Over time improvements could then be made to iron out corner cases where due to the implementation choice it wasn't actually quite the same as the original IC.

As an example, with the ULA on the Electron that needs to access 4 x 1bit 64k RAM ICs I wanted to keep the ULA ports of the component the same as the original ULA pinout with ram0, ram1, ram2 and ram3 lines along with /cas, /ras, /we etc. As a consequence of that decision, the RAM which I had assumed would be reasonably simple to add has become a little more involved.

I  needed to implement a new quad RAM IC which operates via those signals. Internally though  I went with BRAM which as a consequence meant my RAM implementation also needed an external clock too, a compromise on pin identical smile

I may change my mind on this once I start working on the innards of the ULA as I'll now have to include logic to generate /cas, /ras, /we and so on rather than just reading straight out of a 8bit ram module and taking only 4 bits each clock (the ula does two read cycles to get 8bits from the 4 ram modules).

That said, my reasoning behind this approach is I'd like it to be possible to take someone else's 6502 implementation or 12C021 ULA and swap it in for the version used in the core with as few changes as possible, maybe renaming a signal or adding a clock.

I have gone back and forth on this for a few days though and in the end I think "whatever works" will turn out to be the right solution smile

In the time since this thread was created, has anyone changed their minds on their approach?

]]>
Tue, 24 Dec 2013 21:02:58 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=200&action=new
<![CDATA[Clock choice]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1293&action=new I'm looking into doing an Acorn Electron core and need a 16MHz clock for the ULA. My question is how to best generate that via the replay.ini?

A clk_a at ~256MHz would give an ena_sys of 16MHz, but the datasheet for the PLL says the max output freq is 167MHz. Whilst a clk_a of ~64MHz gives a sys_clk of 16MHz which I could use raw into the ULA rather than gated with ena_sys. But I recall something about clk_a also being used for SPI and needing to be reasonably high? Is 64MHz too low?

The option I'm leaning towards atm is clk_a of ~128MHz to give a sys of 32MHz then the core would ignore sys_ena and instead use a 1 in 2 ula_ena.

Deriving a new 1 in 2 "ula_ena" clock from sys_clk isn't an issue, but are there implications for using that in the core in place of ena_sys? I imagine anything running in the replay lib and exposed to the core (that uses sys_clk) will be based on 1 in 4 sys_ena, so there'd be a timing mismatch to deal with. DDR for example would need to have two ula_ena clocks before the read is ready.

Are there any better ways to handle this?

]]>
Tue, 20 Jun 2017 11:55:39 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1293&action=new
<![CDATA[Simulation of replay loader]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=122&action=new Just had another look at this today as I've a need to use the simulator soon to verify a new ram module.

It looks like the error is due to the nested spi, spi_ena and spi_dis using signals in a call that were not passed into that subprogram.

For example, the main spi_ena is defined as:

procedure spi_ena(signal fpga_ctrl : out word(1 downto 0); sel:integer) is
 ...

Then you have spi_readhex defined as:

procedure spi_readhex( signal fpga_ctrl : out word(1 downto 0); 
                       signal fpga_spi_clk, spi_tb_miso : out bit1;
                       signal fpga_ctrl_direct_l,  fpga_spi_mosi, fpga_spi_miso : in bit1;
                       filename:string) is

Within "spi_readhex" there is then an overload of spi, spi_ena and spi_dis to allow dropping several arguments such as fpga_ctrl, fpga_spi_clk and others passed into the parent "spi_readhex"

For example, the nested spi_ena takes only a sel but then calls the outer spi_ena with two params, fpga_ctrl and sel.

procedure spi_ena(sel:integer) is
begin
  spi_ena(fpga_ctrl, sel);
end procedure;

Thus allowing "spi(1);"  to be used within spi_readhex rather than the longer "spi(fpga_ctrl, sel);".

At least I assume that's what it's supposed to do, but it appears for whatever reason, spi_ena above is no longer allowed to use fpga_ctrl in any further procedure calls unless it is also passed in as a parameter. Obviously doing so would be pointless as you may as well then just call the outer spi_ena directly and delete the nested versions.

That's what I've done for now as a workaround, deleted the nested spi, spi_ena and spi_dis procedures and called the outer versions with the full argument list. This is obviously much more verbose, especially for "spi" which has several arguments.

Was this kind of syntax ever legal? Has a newer version of the compiler added additional checks that now catches something that shouldn't be allowed? If not, it seems weird, as it must have worked for someone at some point.

Once I've verified the above changes really do solve the issue (I've still to write my testbench to check), I can commit this to svn if you'd like. Although it does mean everything now is much more verbose e.g

spi_ena(1);
SPI(x"81"); -- command
SPI(x"00"); -- do write
spi_dis;
wait for SPIBITTIME*4;

has to become

spi_ena(fpga_ctrl, 1);
SPI(fpga_spi_clk, spi_tb_miso, fpga_ctrl_direct_l, fpga_spi_mosi, fpga_spi_miso, spi_read_data,x"81"); -- command
SPI(fpga_spi_clk, spi_tb_miso, fpga_ctrl_direct_l, fpga_spi_mosi, fpga_spi_miso, spi_read_data,x"00"); -- do write
spi_dis(fpga_ctrl);
wait for SPIBITTIME*4;

That's ugly however if the first version is legal code.

Edit: Confirmed. The above changes allow the simulator.sh to now build and run correctly on Linux.

]]>
Wed, 04 Sep 2013 18:14:11 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=122&action=new
<![CDATA[Replay audio visualiser example.]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1292&action=new As my learning continues, I thought I'd take the audio core and add a two channel visualiser to it.

I've uploaded a short video to youtube showing the visualiser running. The code is up on bitbucket in the example_audio_visualiser directory and there's a short overview in this blog post

It's nothing too involved. I ended up creating it as I was learning how the BRAM wrappers worked for uploading from the ARM and reading on the FPGA (after confusing myself looking into the DDR usage) and wanted to check the uploaded data so dumped it to the vid output each line and then got a little carried away big_smile

Hopefully it's of some use to others to see how to read/write data from the FPGA side into the BRAM. Not that the repo isn't short on examples in the various cores, it's just easy to get lost in unrelated details when starting.

]]>
Fri, 16 Jun 2017 18:17:04 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1292&action=new
<![CDATA[Memory Read/Write timing.]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1291&action=new There is still some work to do here - it's the main reason I haven't released Asteroids yet which requires a frame buffer with write back.

All access to the DRAM controller must be on sys_clk, so it's much easier if you need to write back to the memory to run the video of the sys_clk with appropriate enables. Loader, which has different clocks as an example, does burst reads from the DRAM then uses an async FIFO to do the clock change.

Assuming sys clock is around 33 MHz (DRAM is 4x this) then you can do one address access every sys clock from a random address. You can do a burst read and get 4 x 32 bits per sys clock cycle.

Currently I haven't turned on burst write, so you can write only 32 bits per clock.

What I am planning for the Asteroids buffer is 4 x 32 bit fetch followed by 4 x 32 bit write back in 2 x sys clock cycles, which leaves 2 clocks for other stuff.

The alternative as you suggest is doing all the write backs during hblank - but again you would need burst write for this. I'll check it and check it in asap.
/Mike

]]>
Tue, 13 Jun 2017 15:54:59 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1291&action=new
<![CDATA[A guide to playing audio based on the loader core.]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1289&action=new Wow that awsome hicks.

]]>
Thu, 08 Jun 2017 11:07:12 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1289&action=new
<![CDATA[Buying a rear i/o backplate?]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1290&action=new Thanks.
Yeah I ran out. I actually ordered some more, then stopped as I realized I needed new ones for the daughter board anyhow - so I'm doing a combined one with all the holes in.

]]>
Sat, 10 Jun 2017 02:53:26 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1290&action=new
<![CDATA[OSD menu black screen]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1284&action=new Got it thanks. We can iterate by email then post the results here.

]]>
Sat, 27 May 2017 13:41:45 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1284&action=new
<![CDATA[VIC20 core talk]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=165&action=new With a clear head it was easy to see the issue.. the problem was with the replacement for the Xilinx RAM, in Mike's original code there were 8 x RAM16X1D's, but the VHDL for the non Xilinx equivalent was actually an 8x8 array.  Most of the time the RAM is accessed with a 3 bit address, but not always - hence the issue and corruption of RAM contents.  Change the RAM to a 16x8 and all is good !  It was timing dependent as to if RAM address 7 got corrupted, and the corruption was also only for bit 0, hence why 2 (row/col 07) didn't work.  So the MIST VIC20 core is bad, as well as other ports non Xillnx ports of the VIC20!  No issue here for the Replay version because its T65 core is good and the PS2 to VIA interface code is completely different to the MIST.

]]>
Sun, 10 Nov 2013 12:32:17 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=165&action=new
<![CDATA[Numbers instead of letters]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1286&action=new Hm, I'm surprised that the keyboard doesn't react to the

option = " on",            0x00000100,default

change. It should really start 'cycling' through all the LEDs on the keyboard.
Maybe the loader core somehow fails to start up at all (and it's simply not a monitor/video problem alone...)
The quick flash of the LEDs when starting up is 'normal' - that's the keyboard powering up, I think.
My keyboard actually flashes twice when booting up..

And - if the keyboard is sending standard PS/2 numlock scancodes the amiga core should (as long as the OSD is disabled) respond to that (by toggling the numlock led)..

]]>
Wed, 31 May 2017 21:46:45 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1286&action=new
<![CDATA[ERROR: Element not found. ERROR: Access is denied.]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1288&action=new we've made a few fixes,I think there will be a firmware update along shortly.

]]>
Mon, 05 Jun 2017 19:26:19 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1288&action=new
<![CDATA[Generic FileIO]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1287&action=new I think you have the idea.

The main problem here is to get a single clock pulse from one clock domain to another. Generally you sample it on the source clock and stretch it. Pass the level through some meta-flops, pass that back to clear the source and then do a rising_edge detect to get a pulse again smile

]]>
Wed, 31 May 2017 23:45:31 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1287&action=new
<![CDATA[FPGA Arcade and ISE]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1279&action=new you are welcome

]]>
Fri, 19 May 2017 09:33:22 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1279&action=new
<![CDATA[Latest Version]]> http://www.fpgaarcade.com/punbb/viewtopic.php?id=1283&action=new looks to be the case. Did you mail me?
I'll make a new release when we have fixed some issues.

]]>
Sat, 27 May 2017 05:47:23 +0000 http://www.fpgaarcade.com/punbb/viewtopic.php?id=1283&action=new