Conversation
| hsize <= scan_dout[5:4]; | ||
| code[11:8] <= { scan_dout[2], scan_dout[3], scan_dout[1:0] }; | ||
| code[11:8] <= CODE_SWAP ? | ||
| { scan_dout[2], scan_dout[3], scan_dout[1:0] } : scan_dout[3:0]; |
There was a problem hiding this comment.
This code swap can probably be avoided in the MRA files by reading the ROM files with a different sequence. That is a cleaner way because we should always aim for very simple verilog.
|
|
||
| // VSCORE=0 -> no cut. The generate keeps the comparison out of the netlist, | ||
| // as v<0 would be a constant-false unsigned compare. | ||
| generate |
There was a problem hiding this comment.
Tell the tool not to generate functions for things that are only used once, and can be summarize as a line. This is a perfect example of that
| module jtvigil_obj( | ||
| module jtvigil_obj #( | ||
| parameter [8:0] XBASE = 9'h180, // sprite X origin | ||
| parameter [8:0] VSCORE = 9'd48, // rows above this get no sprites (0=none) |
There was a problem hiding this comment.
Careful with this, it might mean that vertical blanking in this core is above this line?
Or maybe it is an area covered by another layer
So it might be ok as it is, or this VSCORE may not be needed and it should be handled by the colmix to give priority to the other layer.
There was a problem hiding this comment.
it must be noted this was a vigilante value. we just use a different value for the other core.
|
|
||
| module jtvigil_obj( | ||
| module jtvigil_obj #( | ||
| parameter [8:0] XBASE = 9'h180, // sprite X origin |
There was a problem hiding this comment.
If the new game uses a different resolution, I guess this makes sense. If not, take it with a grain of salt, it could make more sense to solve this at the vtimer counter generation. I don't know.
2 participants
This is the only game that runs on IREM M77 hardware and i derived it from the Vigilante core
Close #1459