Jump to content

Frank van den Hoef

  • Posts

  • Joined

  • Last visited

  • Days Won


Frank van den Hoef last won the day on August 5 2020

Frank van den Hoef had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Frank van den Hoef's Achievements


Newbie (1/14)

Week One Done One Month Later One Year In

Recent Badges




Community Answers

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Eventually probably yes. But don't expect this until the system has been released and on the market for some while.
  7. 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.
  8. 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.
  • Create New...

Important Information

Please review our Terms of Use