NEW OR UPDATED ARCADE CORES

[Darfpga]

Satans hollow and Tron updated for de10_lite at :

https://sourceforge.net/projects/darfpg ... re%20VHDL/

Tron is now ok.
There still may have little problems. No freeze but credits increase with no reasons! Let me know about it.

[Gehstock]

Thank you very Much, updated the MiST Cores

[DrOG]

Thank you!

[vebxenon]

Thank you very Much, updated the MiST Cores

[vebxenon]

All cores from Jotego updated and a new one released: Tiger Road , three days ago: https://github.com/jotego/jtbin/tree/ma ... YWymj9lniM

[Darfpga]

I've just release Discs of Tron VHDL source code for de10_lite at:

https://sourceforge.net/projects/darfpg ... re%20VHDL/

Required large amount of rom room. Missing squawk and talk board.
As usual with these cores it seems to pause for credit!

Very beautiful game. Up to 30+ sprites on a single raster line.

Bring your roms a feel free to port to MiST/MiSTer.

Tapper, timber ... required still more sprite data. External sdram usage will be mandatory.

[Gehstock]

Thank you

[squid4]

Can't wait for Tapper & Timber - two of my favs, but I guess these will never work on 15Khz RGB? I don't use VGA.

[Darfpga]

@Darfpga: thanks for implementing these arcade boards. Would it possible to preserve the original interlaced video, too for these higher resolution arcades (and switch between them via an input signal)? Then TVs and VGAs (without scandoubler) could be used as well.

15kHz interlaced TV mode is well progressing . Coming soon Kick single core with both 240i 15kHz and 480p 31kHz switchable.

[Gehstock]

Thank you

[slingshot]

15kHz interlaced TV mode is well progressing . Coming soon Kick single core with both 240i 15kHz and 480p 31kHz switchable.

Cool! Thanks!

[Darfpga]

New Kick release for de10_lite. Added 15kHz mode. Added merged sprite roms to ease for future biggest sprite data (Tapper...). Remind to rebuild vhdl rom files.

https://sourceforge.net/projects/darfpg ... re%20VHDL/

[retrofun]

Jotego has updated all of his cores - 20191121:
https://github.com/jotego/jtbin/tree/master/mist

• 1942
• 1943
• Commando
• Ghosts & Goblins
• Gunsmoke
• Tiger Road
• Vulgus

[vebxenon]

Jotego has updated all of his cores - 20191121:
https://github.com/jotego/jtbin/tree/master/mist

• 1942
• 1943
• Commando
• Ghosts & Goblins
• Gunsmoke
• Tiger Road
• Vulgus

I've written to Jotego. Except Tiger Road, all the other cores seem to be wrong.

[vebxenon]

I've updated Dig Dug from Gehstock. Now at bottom and left side glitched graphics appear . Can this problem be fixed?

https://github.com/Gehstock/Mist_FPGA/b ... ST/Release

[vebxenon]

Jotego has updated all of his cores - 20191121:
https://github.com/jotego/jtbin/tree/master/mist

• 1942
• 1943
• Commando
• Ghosts & Goblins
• Gunsmoke
• Tiger Road
• Vulgus

I've written to Jotego. Except Tiger Road, all the other cores seem to be wrong.

Well, everything is now correct! https://github.com/jotego/jtbin/tree/master/mist

[Darfpga]

VHDL source code for de10_lite of Kick, Solar Fox, Satans Hollow, Tron and Discs of Tron all updated to 15kHz interlaced mode.

https://sourceforge.net/projects/darfpg ... re%20VHDL/

Also available Timber, playable but with some wrong sprite graphics (required more room to fit full 128Ko sprites roms. Need external [sd]ram to hold all of them).

Feel free to port and bring your own roms.

[Gehstock]

Thank you very much!

[slingshot]

VHDL source code for de10_lite of Kick, Solar Fox, Satans Hollow, Tron and Discs of Tron all updated to 15kHz interlaced mode.

Tried Kick and Tron, works well, nice job!
@Gehstock: PR sent

[slingshot]

Also available Timber, playable but with some wrong sprite graphics (required more room to fit full 128Ko sprites roms. Need external [sd]ram to hold all of them).

As I see, these are really using the ROMs in a 32-bit arrangement, and if the core would use them like that instead of individual 8-bit access, it would better fit to an external SDRAM 2 words burst read cycle.
Upd.: I've added an SDRAM controller which returns 32 bits data (by merging the ROMs and ignore the two MSBs of sp_code_line_mux), however as I see, storing the data into the line buffer expects the data to be available almost immediately. It cannot happen with the SDRAM (nor with the original ROMs), so it would be good to modify the rendering to use all the sprite data 6-8 cycle later.

P.S: secretly hope for a working Spy Hunter core

[Darfpga]

Also available Timber, playable but with some wrong sprite graphics (required more room to fit full 128Ko sprites roms. Need external [sd]ram to hold all of them).

As I see, these are really using the ROMs in a 32-bit arrangement, and if the core would use them like that instead of individual 8-bit access, it would better fit to an external SDRAM 2 words burst read cycle.
Upd.: I've added an SDRAM controller which returns 32 bits data (by merging the ROMs and ignore the two MSBs of sp_code_line_mux), however as I see, storing the data into the line buffer expects the data to be available almost immediately. It cannot happen with the SDRAM (nor with the original ROMs), so it would be good to modify the rendering to use all the sprite data 6-8 cycle later.

P.S: secretly hope for a working Spy Hunter core

At the moment the sprite machine uses 34 cycles for each sprite which requires 16bytes. Does sdram can hold that troughput? If yes it should be possible to use a pipelined machine or even speed up line buffer feed by increasing clock speed.

[slingshot]

At the moment the sprite machine uses 34 cycles for each sprite which requires 16bytes. Does sdram can hold that troughput? If yes it should be possible to use a pipelined machine or even speed up line buffer feed by increasing clock speed.

It can easily fetch 32 bits in 8 cycles in a burst, that will fit then. Just it has to wait 6-8 cycles from the address setup until the data returned. But it's about 150-200ns, and I don't believe the original ROMs were faster.
The emphasis on the 32 bits fetch. It cannot do it with byte-wide access.

[Darfpga]

At the moment the sprite machine uses 34 cycles for each sprite which requires 16bytes. Does sdram can hold that troughput? If yes it should be possible to use a pipelined machine or even speed up line buffer feed by increasing clock speed.

It can easily fetch 32 bits in 8 cycles in a burst, that will fit then. Just it has to wait 6-8 cycles from the address setup until the data returned. But it's about 150-200ns, and I don't believe the original ROMs were faster.
The emphasis on the 32 bits fetch. It cannot do it with byte-wide access.

I'am going to give it a try in a while. Should be easier in 15kHz mode since pixels lasts twice.

[slingshot]

I'am going to give it a try in a while. Should be easier in 15kHz mode since pixels lasts twice.

Thanks! Actually the current rate would be good, if the core would use the data when all the 4 bytes arrived addressed by the mux, not immediately after each byte.

[DanyPPC]

Ghosts'n'Goblins has graphics problems.

Moon Patrol has sound problem. Sound goes away after a while. But this is a bug just reported by me a long time ago