Turkey Shoot and Inferno
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: Turkey Shoot and Inferno
https://github.com/darfpga/vhdl_inferno
https://github.com/darfpga/vhdl_turkey_shoot
Thank you so much dar!!
https://github.com/darfpga/vhdl_turkey_shoot
Thank you so much dar!!
birdybro~
-
- Posts: 58
- Joined: Sun May 24, 2020 9:28 pm
- Has thanked: 5 times
- Been thanked: 11 times
Re: Turkey Shoot and Inferno
That's awesome news. I'm looking forward to these great games being ported to the MiSTer.
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: Turkey Shoot and Inferno
I've been attempting to port Joust 2 to MiSTer (https://github.com/birdybro/Arcade-Joust2_MiSTer), I have video working, the roms and everything compiles fine, but rom loading is going to be tough because the original used sdram. It looks like this is the first time you used sdram loading (edit: nevermind, found mcr3 as an example)? I'm trying to look for a reference to compare against.
birdybro~
Re: Turkey Shoot and Inferno
In williams2, where it currently links to each rom, you instead need to create a block of ram (internal FPGA ram is perfect for this) and instead load the rom at run time.
e.g. currently says
graph1_rom : entity work.joust2_graph1
port map(
clk => clock_12,
addr => graph_addr,
data => graph1_do
);
you need to pass these signals into the module
.dn_addr(ioctl_addr),
.dn_data(ioctl_dout),
.dn_wr(ioctl_wr && !ioctl_index),
.dn_ld(ioctl_download),
sort out which address to use and the write signal for loading this block
graph_addr_mux <= dn_addr(15 downto 0) when dn_ld='1' else graph_addr;
graph_rom_ld <= '1' when dn_addr(16 downto 14) = "001" and dn_ld='1' else '0';
(you need to set the relevant address detail to just get just this rom from the MRA block)
graph1_rom : entity work.gen_ram
generic map( dWidth => 8, aWidth => 14)
port map(
clk => clock_12,
we => graph_rom_ld,
addr => graph_addr_mux,
d => dn_data,
q => graph1_do
);
so that should turn an included rom into a ram block that loads from the MiSTer core
If your mra has rom1 (16k)
rom2 (16k)
etc.
then if this was loading rom2 then you need to check for dn_addr being between $4000-$7FFF
you also need to keep reset low whilst it is loading roms.
for an example see the code for Crazy Balloon (or any of the other arcade cores) but some of these also use the rom_index to load samples / backgrounds etc. (this is just checking for ioctl_index being equal to 0 - normal for the game roms)
hopefully all correct, feel free to ask questions!
e.g. currently says
graph1_rom : entity work.joust2_graph1
port map(
clk => clock_12,
addr => graph_addr,
data => graph1_do
);
you need to pass these signals into the module
.dn_addr(ioctl_addr),
.dn_data(ioctl_dout),
.dn_wr(ioctl_wr && !ioctl_index),
.dn_ld(ioctl_download),
sort out which address to use and the write signal for loading this block
graph_addr_mux <= dn_addr(15 downto 0) when dn_ld='1' else graph_addr;
graph_rom_ld <= '1' when dn_addr(16 downto 14) = "001" and dn_ld='1' else '0';
(you need to set the relevant address detail to just get just this rom from the MRA block)
graph1_rom : entity work.gen_ram
generic map( dWidth => 8, aWidth => 14)
port map(
clk => clock_12,
we => graph_rom_ld,
addr => graph_addr_mux,
d => dn_data,
q => graph1_do
);
so that should turn an included rom into a ram block that loads from the MiSTer core
If your mra has rom1 (16k)
rom2 (16k)
etc.
then if this was loading rom2 then you need to check for dn_addr being between $4000-$7FFF
you also need to keep reset low whilst it is loading roms.
for an example see the code for Crazy Balloon (or any of the other arcade cores) but some of these also use the rom_index to load samples / backgrounds etc. (this is just checking for ioctl_index being equal to 0 - normal for the game roms)
hopefully all correct, feel free to ask questions!
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: Turkey Shoot and Inferno
Interesting, however alan suggested I get it loading as is before I do the MRA loading. My problem is that compiling the Joust2 core seems to result in rom banks a through d not getting synthesized into the design, because apparently no signals are connected.
When I check the connectivity report this is what I see for all 4 rom banks:
data Output Info Connected to dangling logic. Logic that only feeds a dangling port will be removed.
Here's an example of these four banks:
rom_bank_a_do only does:
This commented out line of code. The same is true for rom_banks b-d. When I look at sdram_loader_de10_lite.vhd, I can see that it's doing a bit more work, so for me to port it I would have to rewrite portions of https://github.com/birdybro/Arcade-Jous ... 0_lite.vhd to work with our different configuration, I think. Which I'll try my best to do.
When I check the connectivity report this is what I see for all 4 rom banks:
data Output Info Connected to dangling logic. Logic that only feeds a dangling port will be removed.
Here's an example of these four banks:
Code: Select all
-- rom17.ic26 + rom15.ic24
bank_a_rom : entity work.joust2_bank_a
port map(
clk => clock_12,
addr => addr_bus(14 downto 0),
data => rom_bank_a_do
);
Code: Select all
-- rom_bank_a_do when rom_bank_cs = '1' and (page = "010" ) else
birdybro~
Re: Turkey Shoot and Inferno
that is because the de10-lite version is trying to access the bank data from ram loaded by the loader routine, and not actually using those 'rom' equivalent components.
You also have linked it directly to the addresses and data used for the MiSTer loader routine, which is transient - that's why you have to write the data to an actual ram bank (al be it read only to the actual running code and only writable by the MiSTer rom loading routine)
however, to force it back to use the original hex rom images, just change the low address routine to ...
--rom_do when rom_bank_cs = '1' else
rom_bank_a_do when rom_bank_cs = '1' and (page = "010" ) else
rom_bank_b_do when rom_bank_cs = '1' and (page = "110" ) else
rom_bank_c_do when rom_bank_cs = '1' and (page = "001" or page = "011") else
rom_bank_d_do when rom_bank_cs = '1' and (page = "100" or page = "101") else
and comment out accessing the single block of ram loaded by the other routine. (and put it back in later when you lose the attached roms, so different MRA's can select the different rom sets for the other games as well) - at the moment that condition would be true so the other bank accessing would never happen.
You also have linked it directly to the addresses and data used for the MiSTer loader routine, which is transient - that's why you have to write the data to an actual ram bank (al be it read only to the actual running code and only writable by the MiSTer rom loading routine)
however, to force it back to use the original hex rom images, just change the low address routine to ...
--rom_do when rom_bank_cs = '1' else
rom_bank_a_do when rom_bank_cs = '1' and (page = "010" ) else
rom_bank_b_do when rom_bank_cs = '1' and (page = "110" ) else
rom_bank_c_do when rom_bank_cs = '1' and (page = "001" or page = "011") else
rom_bank_d_do when rom_bank_cs = '1' and (page = "100" or page = "101") else
and comment out accessing the single block of ram loaded by the other routine. (and put it back in later when you lose the attached roms, so different MRA's can select the different rom sets for the other games as well) - at the moment that condition would be true so the other bank accessing would never happen.
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: Turkey Shoot and Inferno
Oh darn, that was right in front of my face. I had already commented out those 4 lines but didn't think about commenting out the rom_do line. Thank you!
birdybro~
- atrac17
- Core Developer
- Posts: 162
- Joined: Sun May 24, 2020 10:51 pm
- Has thanked: 32 times
- Been thanked: 385 times
Re: Turkey Shoot and Inferno
I'm sorry, I thought you could respond if I DM'ed. Let me figure it out. Were you interested in it?
Edit: I am able to receive DM's now.
-
- Core Developer
- Posts: 40
- Joined: Fri Mar 11, 2022 9:46 am
- Has thanked: 14 times
- Been thanked: 104 times
Re: Turkey Shoot and Inferno
Managed to get these cores on MiSTer. A bit more work to do (MRA supported, HiScores, DIPs, pause) and hopefully we should have them on the main repo very soon.
List of cores:
Turkey Shoot
Joust2
Mystic Marathon
Inferno
List of cores:
Turkey Shoot
Joust2
Mystic Marathon
Inferno
-
- Core Developer
- Posts: 18
- Joined: Sat May 30, 2020 4:21 pm
- Has thanked: 3 times
- Been thanked: 63 times
Re: Turkey Shoot and Inferno
Hi,
Background sound and speech board for Joust2 is now available at github.com\darfpga. It is currently a standalone for DE10_lite but strait forward usable for MiSTer. Raw outputs to be mixed and controlled as desire.
Dar.
Background sound and speech board for Joust2 is now available at github.com\darfpga. It is currently a standalone for DE10_lite but strait forward usable for MiSTer. Raw outputs to be mixed and controlled as desire.
Dar.
-
- Core Developer
- Posts: 18
- Joined: Sat May 30, 2020 4:21 pm
- Has thanked: 3 times
- Been thanked: 63 times
Re: Turkey Shoot and Inferno
Short reply is that my very old PC is far too much slow to make any compilation/debug directly for MiSTer. Dev for MAX10 is way faster than for Cyclone V.
Thank you anyway.
Dar.
- atrac17
- Core Developer
- Posts: 162
- Joined: Sun May 24, 2020 10:51 pm
- Has thanked: 32 times
- Been thanked: 385 times
Re: Turkey Shoot and Inferno
Understood! Thanks for writing the core. Also, thanks birdybro/JasonA for porting to MiSTer.
-
- Core Developer
- Posts: 40
- Joined: Fri Mar 11, 2022 9:46 am
- Has thanked: 14 times
- Been thanked: 104 times
Re: Turkey Shoot and Inferno
Inferno is still being worked on daily for MiSTer. There is a little more work to do for joypads, and hopefully should be ready for beta sometime next week.
Then attention will be to get Turkey Shoot ready.
Then attention will be to get Turkey Shoot ready.
-
- Core Developer
- Posts: 40
- Joined: Fri Mar 11, 2022 9:46 am
- Has thanked: 14 times
- Been thanked: 104 times
Re: Turkey Shoot and Inferno
Inferno has 4-way direction for "run", and 4-way direction for "aim". As Dar also has in the code, is that run/aim are on the same direction pad, but should be split to be authentic.
Wondering if anyone objects to run/aim being on the same direction. Otherwise I will proceed with it.
Wondering if anyone objects to run/aim being on the same direction. Otherwise I will proceed with it.
Buy me a coffee https://Ko-fi.com/jasona
-
- Site Admin
- Posts: 479
- Joined: Wed May 20, 2020 3:36 pm
- Has thanked: 227 times
- Been thanked: 805 times
Re: Turkey Shoot and Inferno
Any possibility of offering via a core option the choice for twin stick use like in the Robotron: 2048 core?
-
- Core Developer
- Posts: 40
- Joined: Fri Mar 11, 2022 9:46 am
- Has thanked: 14 times
- Been thanked: 104 times
Re: Turkey Shoot and Inferno
Sure, can be done via an OSD option.
I'll add that as a future improvement one the combined run/aim is working very soon
I'll add that as a future improvement one the combined run/aim is working very soon
Buy me a coffee https://Ko-fi.com/jasona
-
- Core Developer
- Posts: 40
- Joined: Fri Mar 11, 2022 9:46 am
- Has thanked: 14 times
- Been thanked: 104 times
Re: Turkey Shoot and Inferno
I put out an Inferno test build on Discord. The controls are very difficult in this first beta. Please help to test, and give feedback please so that I can keep improving it.
Post here or on Discord, I will try to reply either way.
Post here or on Discord, I will try to reply either way.
Buy me a coffee https://Ko-fi.com/jasona
Re: Turkey Shoot and Inferno
As not all like to use discord could you please post the test build also so others can test thanks.