Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

Geehaf's Achievements


Newbie (1/14)

Week One Done One Month Later One Year In

Recent Badges




Community Answers

  1. Thanks for clarification and further details. Appreciate it.
  2. I wonder if it's worth considering the x16 with a full FPGA implementation like the X8? Not sure what it would mean for the YM chip but perhaps there is already FPGA for that too. It would allow for complete "firmware" upgrades in the future and could simplify the overall design. Not sure if it would help reduce manufacturing costs. Yes, my idea is a little radical I know, especially with all the work and time spent so far on the hybrid FPGA / non FPGA chips approach.
  3. Yes, all documented VERA registers etc. The routine does disable the tile layer between each tile line to stop VERA outputting any tile graphics (this is the space highlighted in yellow below) and dynamically determines the next relative vertical scroll position for the layer in relation to the end position of the previous line. Cheers.
  4. Thanks for the interest! It works by generating a pair of line interrupts for each visible line of tiles, then adjusting the vertical scroll position for the Tile layer accordingly based upon a sine wave pattern, i.e. the 1st line interrupt "switches on" the tile line and the 2nd "switches off" the tile line and is then repeated for all visible moving lines. Tile graphics data is not manipulated as such. Initially I did consider basing the effect on updating the tile base address register but the "grain" of this address is limited to a multiple of 2048 bytes.
  5. I did publish this link on the FB group earlier but just in case you missed it A very small sneak peek at one of the effects I've coded for my upcoming X16 demo: VERA.FX 1 Inspiration came from a C64 Flexible Line Distance (FLD) routine I wrote back in the 1980s! Hopefully the full demo will be released soon...(all fingers crossed ). Not a sprite in sight!
  6. The PSG does lack some of the SID HW features, e.g. ADSR, Filters etc, but it can still pump out some great sounds. Something like ADSR can be achieved in SW using timing and the volume control for the voice. Take a look at the link below. It's a C64 Rob Hubbard routine with its SID values being translated (approx) to PSG values.
  7. One of my fave games from the C64 days is getting a new life on the Switch - Feb 2021:
  8. Thanks Johan - Yes I'm currently using the line interrupts but was curious about the above. Cheers.
  9. I think the answer to my question is NO but does anybody know if there is a way to determine the "current" raster line being rendered by VERA? On the C64 you could simply issue a: LDA $D012 (with the MSB being held in the $D011 register) Thanks, G
  10. A great article I read recently that talks about sprite to tile collisions and other considerations when thinking about implementing a platformer style game: https://games.greggman.com/game/programming_m_c__kids/ The HW context is the NES but the principles still apply. Interestingly, the Collisions section starts with the sentence "Now for the fun part. NOT!" It won't give you the 6502 code but details some of the challenges and provides approaches to solving them. I found it useful for one of my current X16 projects.
  11. Looking good! That's one tidy power cable...
  12. Thanks - this now makes sense. Essentially collisions are detected for up to 4 potential groups and each sprite can be assigned a specific group. Does this mean collisions are only detected/generated within a specific group, e.g. if a player sprite (say) was assigned to group 0 and all enemy sprites to group 1 then collisions would not be generated when a player collides with an enemy sprite? Also thanks for the heads up re. HW vs SW collision detection approach.
  13. Hi All, Has anybody experimented with using the newly implemented sprite collisions with R38? The VERA doco mentions sprite collisions but I was hoping somebody could provide a worked example / explanation. Reading the doco it looks like each of the 128 sprites can be assigned a 4 bit collision mask but I'm not sure how this works together with the 4 bits of "sprite collisions" provided by the ISR register ($9F27). Any help much appreciated. Regards, G
  14. Thanks Stephen - I suspect it's in that space too. For my current project, my idea for a workaround is to use the Horizontal Stop register (DC=1, $9F2A) to mask it out - example below. Cheers, G
  • Create New...

Important Information

Please review our Terms of Use