Add Space Harrier Core

[niknakniknak]

Space Harrier. it plays perfectly and matches my cabinet pretty accurately

Sega Hang-On hardware: two 68000s, i8751 MCU, Z80, YM2203 and the discrete
SegaPCM, plus the tilemap, sprite and road generators.

Subsystem Source

---

68000 x2, i8255, YM2203, mixer JTFRAME
Tilemap, palette, priority jts16
SegaPCM forked from jtoutrun
i8751 MCU Oregano mc8051, retimed in the wrapper
Road generator transcribed from segaic16_road.cpp
Sprite scan and draw transcribed from sega16sp.cpp
Memory map, I/O, ADC, sound, video new

The road and sprite routines are derived works of MAME source (BSD-3-Clause,
Aaron Giles); attribution is in those module headers. Sega's SH customs have never
been decapped, so MAME's implementation is the best description of what they do that I can find.

Outstanding things maybe.
Space harrier. A certain later sound effect can stick for a while until retriggered
(short) under heavy activity. I think this is original behaviour;
to be checked on my cabinet.

Extra options for QOL

Space harrier: Three MRA dips, all defaulting to arcade behaviour so loading the
MRA unchanged gives the original machine:

Stick Direction Normal / Arcade Arcade: aircraft stick, up goes down. Normal: up goes up.
D-Pad Control Console / Arcade arcade:spring back to centre. console: stay where you are.
V Glyph Fix On / Off corrects a glyph drawn wrong in the ROM (bugged me since 1986)

Notes

• Two sets ship: sharrier (Rev A, clean MCU dump) is preferred; sharrier1's
  MCU is flagged BAD_DUMP in MAME.
• mcu_en is hardwired 1, so Hang-On and Enduro Racer are not enabled yet.

[niknakniknak]

working on enduro and hang-on, @asturur made me aware of duping the whole of mc8051 was not the best idea. Agreed I should have picked that up. I only needed two extra ports - the FSM state, and a separate clock enable so the timer/serial units aren't retimed. I'll tidy it.

[asturur]

unless you know a reason for those cen to be created like this, those just go in mem.yaml under the clocks section with the other that you put there.

[niknakniknak]

Tried it, had to revert. Moving the MCU and Z80 cens broke the audio and bought back a very old regression: a sound effect cuts out if you credit after leaving it in attract for a while.
It isn't the frequency. I reproduced the exact ratios with mul: 39, div: 245 and mul: 25, div: 315 and it still happened. jtframe_gated_cen and jtframe_frac_cen are different implementations gated_cen has its own accumulator (NUM2 = NUM<<1), toggle registers and glitch handling so at the same average rate the enable pulses land differently, and something in my sound path is sensitive to that.
Also worth noting the 68000 pair can't move regardless: it needs cenb so main and sub interleave on shared RAM, and gated_cen only outputs cen, fave, fworst.

Leaving it as-is for now. Happy to revisit if gated_cen can be made pulse-equivalent, or if the yaml could instantiate frac_cen directly.

[asturur]

this could go into bram section in mem.yaml i m not able to tell you the exact equivalent for this. Always if know why this is not in the bram section say it replaying on my comment

[niknakniknak]

might have to do this when back from vac.

[asturur]

every time i made a new game file, always loops and bits of logic were better placed in submodules instantiated here rather than right on the game file. I see 3 always loop here that maybe are out of place, but this core is incredibly complex for me, so i m telling you just the obvious things i already seen on my cores

[niknakniknak]

Yup, will look at that. Cheers A!

[niknakniknak]

Enduro is running, but i'll hang back on the PR until this is done.

[jotego]

Thanks for taking the time for this. This is going to require a ton of changes before merging. And that is even before checking the schematics.

1. No distributable MRA is produced. jtframe mra sharrier reports Total: 0 games and exits with Error: no setnames dumped. The new
   cfg/mame2mra.toml selects segahang.cpp, but the committed reduced doc/mame.xml contains neither sharrier nor sharrier1. The matching MAME 0.282 archive does contain both sets, so update the reduced database using jtframe mra --reduce /nobackup/mame/mame0282.xml, inspect the global XML change, and then validate MRA generation for this core and the existing MRA-capable cores. The PR also needs the copied MAME driver reference under cores/sharrier/doc/.

2. All targets that enable JTFRAME_LF_BUFFER leave its game-top interface undriven. cfg/macros.def:73-76 enables the feature for MiSTer, Pocket and SiDi128, yet jtsharrier_game.v neither assigns game_hdump, game_vrender, or fb_keep, nor connects ln_addr, ln_data, ln_done, and ln_we to the sprite renderer. lint-one.sh sharrier reports each output as undriven. Follow the jtoutrun_game LF-buffer interface pattern, or remove JTFRAME_LF_BUFFER and provide a renderer appropriate to each enabled target. Do not ship an enabled, unconnected interface.

3. The required build gate fails before Quartus starts.
   jtcore sharrier -mrq exits 1 from lint. Resolve the reported errors rather than relying on warnings: the inferred latches in jtsharrier_road.v:204-218, width truncation/extension in the road, char, and game modules, and the unconnected top-level outputs above. Rerun the MiSTer compile after a clean standard and NOMAIN/NOSOUND lint pass.

Required integration and validation work

4. The declared primary MRA contradicts the README and selects the known bad MCU dump. cfg/mame2mra.toml:3-11 says sharrier (Rev A) is the clean, preferred set, while line 19 makes sharrier1 the primary MRA. Set the primary game to sharrier, then generate and inspect both MRAs.

5. Scene-simulation support is absent. The core has no scenes and no NOMAIN/NOSOUND guards. objram is instantiated directly in jtsharrier_game.v:127-138, rather than declared as scene-restorable BRAM; jtsharrier_road.v:142-153 also keeps a private, write-snooped copy of Road RAM which cannot be restored from a scene. Move CPU-visible video RAM to mem.yaml with the appropriate dual ports and ioctl save/restore fields, preserve video MMR state, add the normal CPU-disabled stubs, and provide representative MAME-backed scenes with exact comparison results.

6. New-core release metadata is incomplete. Add sharrier to .beta.yaml for the supported beta platforms and add a measured two-decimalJTFRAME_RATE to cfg/macros.def. Validate it with jtrefresh sharrier.

7. Repository hygiene needs a pass. git diff --check fails, including trailing whitespace in README.md:74 and README.md:104 and numerous new third-party-file whitespace/line-ending diagnostics. Preserve third-party licence text deliberately if needed, but make the submitted diff pass the repository whitespace check (or keep untouched vendor material out of the changed text path).

Other Big Problems

• Duplicated mc8051 implementation. Just REMOVE all the 8051 folder
• Remove all those pesky comments and leave clean code
• Remove jtsharrier_8751mcu.v file. We already have a 8051 implementation. What is this file doing?
• JTFRAME modules like jtframe_char, jtframe_tilemap and jtframe_scroll should be used either directly at the jtsharrier_video level or down in the hierarchy. This means that jtsharrier_char.v, jtsharrier_obj_draw.v, jtsharrier_tilemap.v and probably other files should be removed
• jtsharrier_pcm.v should be removed too and use OutRun's version or try to reuse it with some new parameters to customised it to the board needs
• timing.sdc is probably not needed at all and should be removed
• All the clock enables in jtsharrier_game should not exist there.
• Memory allocation should preferrably go into mem.yaml
• Most likely, the PCM is missing the right filter present on the board. I bet it is not that 1st order RC currently in mem.yaml as other SEGA games use 2nd or 4th order filters

[real-amano]

@niknakniknak , if you run into problems with mc5081, you could have a look at the new "nu5081" module by wickerwaka. It's on his GitHub.

https://github.com/wickerwaka/nu8051

[jotego]

The problem is that Claude is spitting out new 8051 cores everyday. A different one for each game that used that MCU.

We have been using Oregano's one for a long time. It has not created problems and the license let us use it. So we should stick for it.

Creating new ones for each game goes against the modularity principle that guides all engineering.