Bad polygon(s) on metal layer (#1) for Z80 sim

[logoliv]

There are some bad polygon points for metal layer (layer #1 in the sim) between #42 and ab0 pins (on the left) and one bad point is completely on the top left of the simulation (near the _busrq pin). The layer is fine on the http://www.visual6502.org/JSSim/expert-z80.html page and in Z80 Explorer application.

[floooh]

Thanks for noticing that and writing the issue. It's most likely a bug in the offline-triangulation script https://github.com/floooh/v6502r/blob/master/ext/visual6502/segdefs.py and only affects rendering, but not the actual emulator functionality.

No promises yet when I get around fixing the issue.

PS: thinking about it I wonder if it's a precision problem. The mesh vertex positions are stored as 16-bit integers: (https://raw.githubusercontent.com/floooh/v6502r/master/src/z80/segdefs.c) and for the more 'dense' Z80 some closeby vertex positions might be collapsed into the same 16-bit integer value...

[logoliv]

Thanks for your answer. I know it doesn't affect the simulation but it spoils the pretty look of your work :) I have a doubt about the precision problem : this part of the chip is not very dense. Please when you correct that, could you release an update in your visualz80remix repository ?

[logoliv]

By the way, if I compare your segdefs.c with the original Visual Z80 segdefs.js, it seems all the coordinates have been multiplied by 2

var segdefs = [
[ 48,'-',0,4613,4961,4644,4961,4644,4951,4613,4951],
[ 49,'-',0,55,4959,86,4959,86,4949,55,4949],
[ 50,'-',0,4652,4943,4661,4943,4661,4912,4652,4912],
[ 51,'-',0,38,4942,47,4942,47,4911,38,4911]...

[floooh]

Yeah, I'm passing in a scale factor 2 here only for the Z80:

https://github.com/floooh/v6502r/blob/2c3dd083b2087577a9a49364c2822564cc2dfc52/ext/visual6502/dump_z80.py#L15

Reason might be that the input data for the Z80 has x.5 values, see this comment (which is only about negative 0.5) though:

https://github.com/floooh/v6502r/blob/2c3dd083b2087577a9a49364c2822564cc2dfc52/ext/visual6502/segdefs.py#L63-L65

...it looks more and more like a rounding/clamping issue though (or maybe even a 16-bit overflow issue).

PS: yeah, when you look at the Z80 segdefs.js input file, there's a lot of x.5 values:

https://raw.githubusercontent.com/floooh/v6502r/master/ext/visual6502/z80/segdefs.js

...that explains the multiplication by 2 at least.

[logoliv]

I noticed that all closed shapes with a "hole" inside are scrambled (like in my capture for the A, 8, 4 and 0 characters, but the V is correct), so my advice is that the problem is in indexation of vertexes for these types of polygons.