Frank van den Hoef

The FPGA is indeed a Lattice iCE40 UltraPlus 5K. If I remember correctly it is about 85% filled up. The VERA design has been finalized for about a year now. So yes, all the VERA specs are quite final.

The line counter is active at all times. The (9-bit) line counter is increment by 1 in progressive mode, and by 2 in interlaced mode. In progressive mode a line IRQ is produced when the 9-bit line number matches the 9-bit line irq register. In interlaced mode a line IRQ is produced when the upper 8-bits of the 9-bit line number matches the upper 8-bit of the line irq register. The video timing has the active portion at 0-479, then 10 lines of front porch, 2 lines of v-sync and 33 lines of back porch, for a total of 525 lines. Rendering is started one line earlier, so at line 524. Composing the outputs of the renderers (2 layer renderers and 1 sprite renderer) is performed while outputting the pixel data. Eg. the line buffers rendered at line 524 are displayed (and composed) on line 0. Hope this helps.

On the real hardware, there will be a way to reprogram the FPGA image if necessary to fix any bugs that are discovered after release. (This involves putting a jumper on the VERA board to enable access to the flash chip from the CPU.) So yes, if you would like to hack around you can, it is (will be) your hardware. Also the FPGA does have a feature where it can store up to 4 FPGA images in the flash chip, which could be nice for hardware hackers to allow the original image to be present in addition to their own creations. Do note, that this will not be officially supported and normally users are expected to run original firmware. So if you mess up, it is on you.

1. If the horizontal pixel counter equals DC_START the output will be enabled, at DC_STOP it will be disabled. So if DC_START is bigger than DC_STOP, DC_STOP is basically ignored and the image will be displayed up to the end of the line. 2. Sprites are rendered in order of their index, so higher index sprites will be rendered in front of lower index sprites, except when it has a lower Z-value. No garbage will occur. 3. On the real hardware, the noise generation is done using a LFSR. It could be emulated, but I think the rand is doing a quite similar job.

I think in the end someone should create a test suite of programs to test the corner cases on both real hardware and the emulator to test they produce equal results. For the real hardware, in interlaced mode it only renders the lines that are actually displayed for that field. But regarding the line interrupt, if for instance it is set to 10, it will actually trigger for each field once the line number is on or passed the set line number. Also since only displayed lines are rendered, this also implies that collision detection will also only occur on displayed lines.

Eventually probably yes. But don't expect this until the system has been released and on the market for some while.

The hardware really only has one output resolution: 640x480. 320x200 isn't a resolution that is natively supported by VERA. As far as I know the kernal has this 320x200 resolution as part of the GEOS drawing code, which Michael didn't yet update to make use of the full 240 lines height. As Stephon Horn showed, you can use the scaling to make the 200 lines cover (almost) the full 480 output lines, but it will give some scaling artifacts.

Hello all, My name is Frank van den Hoef and I am responsible for the design of the VERA module (the audio, video and storage hardware module), which is part of the Commander X16.