fix(): Review blockout followups

[asturur]

Followups to clean up the blockout core

• adjusted the _cs signals with the mame informations
• left pixel clock as is, but need to investigate the signal numbers
• made HEADER 4 and used the standard header syntax
• added the skipped rom region
• reordered some yaml file

[jotego]

It must be a multiple of 4 or it will break the Analogue Pocket firmware.

[asturur]

This is NOT ready for review, i m doing it slowly because i have to do it without AI, for reasons.

[asturur]

I hate to call this EVIDENCE but the only thing outside mame i found is this:

a 24mhz xtal and a 20mhz one.

The 20Mhz is the 10Mhz motorola
The 24Mhz needs to be the one that generates the video clock, at 320px visible area i would say 8Mhz is correct

@jotego does it sound reasonable?

This was one of the things you asked to double check or put conformant with mame.

[jotego]

1. SDRAM chip selects are asserted before a valid 68000 data strobe. rom_cs, fb_cs, and work3_cs are decoded from !ASn only (jtblkout_main.v:106-117), while the core-review rule for fx68k SDRAM access requires !ASn && {UDSn,LDSn} != 2'b11. Gate the SDRAM selections at the decoder, including reads, and revalidate read-modify-write cycles and DTACK behavior. This one is critical.

2. Add JTFRAME_RATE=57.45, and verify with jtsim -video 3/jtrefresh. If the board has a 24MHz clock the 8MHz clock frequency sounds reasonable.

3. Agress is emitted without its required startup ROM patch. MAME patches word 0x82/2 to 0x2700 so Agress does not enter the trace exception (cores/blkout/doc/blockout.cpp:560-584). mame2mra.toml has no equivalent patch, while the misspelled skip.setnames=["aggress"] does not exclude the real agress/agressb sets. Add and validate the MRA patch for both sets, or explicitly skip them until supported. Update the README to match the actual choice.

4. The main CPU register decoder aliases unmapped addresses. frontcol_cs covers the whole 0x280000-0x2801ff range rather than only 0x280002-0x280003, and pal_cs also accepts 0x280600-0x2807ff although MAME maps only 0x280200-0x2805ff (jtblkout_main.v:115-117; MAME map at blockout.cpp:263-265). Decode the exact ranges. Preserve byte-write semantics for the front-color register as MAME does with COMBINE_DATA. Partial decoding, is normally fine but missing the byte-write semantics may cause a bug more frequently.

5. the per-set header/button configuration does not work. Generated blockoutj MRA data still contains a zero header and the World labels A,B,C,Drop, not the requested Japanese Drop,B,C. The selector uses machine="blockoutj", but that set is a clone of machine blockout; additionally, no HDL consumes the header. Use an exact setname="blockoutj" selector where appropriate and remove the unused header, or implement a named generated header only if RTL actually needs a variant flag. Verify every generated MRA, including Agress alternatives.

6. vblank interrupt handling does not follow the core CPU rules. jtblkout_main.v:162-172 manually detects LVBL edges instead of using jtframe_edge, and dip_pause halts the CPU without gating new vblank interrupt triggers. Convert the trigger/clear handling to the framework helper and prevent vblank IRQ assertion while paused.

7. required video debug structure is missing. debug_view is tied to zero, gfx_en stops at the game level, and jtblkout_video performs overlay priority, palette lookup, blanking, and RGB output itself (jtblkout_game.v:27-28; jtblkout_video.v:146-162). Add jtblkout_colmix, route gfx_en to it, and gate the framebuffer and overlay independently. Move the front-color memory-mapped register into cfg/mmr.yaml so scene state can restore it.

8. there is no functional regression evidence. cores/blkout/ver contains no saved scenes, boot simulation, or coin cabinet test. Add representative framebuffer/overlay scenes, a boot run that produces readable title/credit text, and a nonblank-frame coin test whose following 30 frames contain nonconstant audio. Include at least Block Out, Block Out Japan, and Agress if Agress remains supported.

9. jtframe mra blkout: completed, but warned that proms is unlisted for all six sets. Skip the proms. Even better, try to use them in the core.

[asturur]

3. Agress is emitted without its required startup ROM patch. MAME patches word 0x82/2 to 0x2700 so Agress does not enter the trace exception (cores/blkout/doc/blockout.cpp:560-584). mame2mra.toml has no equivalent patch, while the misspelled skip.setnames=["aggress"] does not exclude the real agress/agressb sets. Add and validate the MRA patch for both sets, or explicitly skip them until supported. Update the README to match the actual choice.

I thought this was addressed by removing the mispelled names, i have skip for agress and agressb and i defer agress till the point blockout is done and in good shape.

this is what i got from compilation. Agress is disappeared.

2. Add JTFRAME_RATE=57.45, and verify with jtsim -video 3/jtrefresh. If the board has a 24MHz clock the 8MHz clock frequency sounds reasonable.

i added JTFRAME_RATE=58.04 and i see that verified in the pipeline, because with the current signal shape, 58.04 is what comes out. Should i rethink how the vtimer is configured?

5. the per-set header/button configuration does not work. Generated blockoutj MRA data still contains a zero header and the World labels A,B,C,Drop, not the requested Japanese Drop,B,C. The selector uses machine="blockoutj", but that set is a clone of machine blockout; additionally, no HDL consumes the header. Use an exact setname="blockoutj" selector where appropriate and remove the unused header, or implement a named generated header only if RTL actually needs a variant flag. Verify every generated MRA, including Agress alternatives.

i tested this from the compilation, and it was working correctly.

What i see from the MRAs:
is that blockout has first byte set to 1 and blockoutj has second byte set to 2, while i was expecting 0 and 1.

registers=[
    { name="blockout",    pos="0[0]",   desc="Blockout",   values=[{ setnames=["blockout","blockout2","blockout3"], value=1 }] },
    { name="blockoutj",    pos="0[1]",   desc="Blockoutj",  values=[{ setname="blockoutj", value=1 }] },
]

where is the issue in those 3 lines?

9. jtframe mra blkout: completed, but warned that proms is unlisted for all six sets. Skip the proms. Even better, try to use them in the core.

I added this:

{ name="proms", skip=true },

and i thought that fixed it. ( i can look into supporting it but seems an harder task for me now without verification sources).

The other items i need to look at with calm, i read your requests and those sound strange to me because i thought i exactly did what you asked.

Current MRAs for inspection
mra.zip