Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


izb last won the day on October 28 2020

izb had the most liked content!

Recent Profile Visitors

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

izb's Achievements


Newbie (1/14)

Week One Done One Month Later One Year In

Recent Badges



  1. This is frustrating news, and must be more so for the team that has invested so much in getting it to this point. I’ve been developing a game for this system since the emulator was first available. With this news, I think I will be pausing development until a real system becomes available. I don’t want to develop for a moving target or a fragmented system, and to me that’s what the X8 seems to represent. I have always been excited by the prospect of a singular new system, packaged up and ready to explore. I am not excited by the prospect of spending some hundreds of dollars on an electronics kit that I need to solder together with a high possibility of failure. It reads to me like the possibility of the original plan at a reasonable price is unlikely. I’m unsure why there has always been an apparent resistance to running a Kickstarter campaign. I know they take a significant cut, but isn’t the scenario you describe exactly what Kickstarter is for? If you offer the option of paying a premium for a preassembled kit, then to be honest that just sounds like a ticket for a place on a lengthy waiting list. A launch that manifests as a slow trickle of new machines would surely be death for any new platform. I won’t invest in a system that has no user base, or prospect of gaining one. I hope this hasn’t come across as overly negative. I really hope to buy an X16 one day - the work so far has been amazing - but I will now be sitting watching, waiting to find out what that actually means.
  2. You have per height routines, but could you also have a per texture+height routine? You could take advantage of textures created with vertical runs of identical pixels to reduce “reads” from the texture. I’d imagine the answer is that that would use a ton of memory, but I’m wondering how much memory the routines are using up now? Sent from my iPhone using Tapatalk
  3. Will the new kernal routines allow you to detect when a key is held and released? Sent from my iPhone using Tapatalk
  4. Small world! Sent from my iPhone using Tapatalk
  5. Random, disjointed thoughts... I like the simplicity of the X16 as a platform for learning and exploring assembly programming. All those boot menu options etc on the mega65 just put me off. Also the case is ugly - ew. I don't care about backwards compatibility either - it never works on the one thing you want it for, and if you want to play an old C64 game there are better ways to do it than on a mega65. And anyway, frankly those old games aren't going to be as interesting to play as any new ones that make proper use of the hardware. Breaking C64 compatibility is a big plus and properly focuses the project. Nostalgia is nice, but keep the dial down low. The X16 feels way more accessible, and I can see it being much more successful at introducing younglings to the craft of writing programs. I know you said 'chips aside', but... I don't have a problem with FPGAs as such, but I like that the lack of one makes for a more stable platform. I don't want to have a game that will only run after hunting down some 'enhanced' core that someone made on some forum somewhere. Perhaps an unfounded fear, but there it is (Please nobody make a Vera+). Also, as a developer, I appreciate the sense of being closer to the metal that seeing the real chips gives you. There's something less satisfying about coding for a virtual or emulated platform, and I'd put FPGAs in that category purely for the feeling of abstraction and instability. I think 8MHz is also a great balance between capability and constraints. You could make some really great games for this system, well within those constraints, and treat is as a 'lowest common denominator'. Porting X16 games to the mega65 or zx next would be obviously possible and an interesting project. All that said, I am a zx next KS2 backer, and my nostalgia for the speccy has won out over my fear of forking FPGA cores, and I will absolutely be playing old speccy games on that when it arrives. I'm sure there will be some C64 superfans with the same feelings about the mega65 who will wonder what the point of the X16 is. I won't pay what I was prepared to spend on a zx next on a mega65. I will pay for a cheaper, new, interesting and capable platform like the X16. I will also watch mega65 videos on youtube and have thoughts like "wow, 40MHz", and "holy crap 1000 multiplexed sprites, that's so cool", and "Oh, if only the X16 had an HDMI port too..." For me though, I'm really enjoying learning to code for the 65c02, and the vera chip is awesome.
  6. Bumping this with a related query... Does the keyboard scanning work in the same way as the C64? If I wanted to write my own keyboard scanning routine, would it have the same rollover issues as the C64?.. or does the X16 ROM do things its own special way?
  7. izb

    CPU meter

    The code is a horrible, unpresentable mishmash of magic numbers and macros, but I'll do my best... This is the main wait loop which just thrashes and waits for the vbl interrupt to set a flag This just waits for vsync_trigger to be set (by the interrupt) and counts up a cycle_counter value while it does so. From the emulator's own cycle counter, I can see that this loop is worth 14 cycles, so each tick of cycle_counter here is actually 14 cycles. So from there we know that the most amount of time we can spend in this loop is 9533 loops. If we divide our cycle counter by 37 (You'll need to find your own divide routine somewhere) then we end up with a value between 0 and 255 in the low byte of the division result. Next up, we need to remap that byte to a 0..100 percentage value, which is: There's probably cleaner or quicker ways to do this without the two divisions, but it seems to work well enough for my purposes. I should probably calculate the number of cycles burned by calculating the CPU usage and subtract that from the result
  8. izb

    CPU meter

    Been tinkering away at my game, and thought I'd spend some time adding better debug tools, so I added a CPU meter. I was getting concerned that I had no idea if my plans were going to fit into my frame budget. The screenshot shows I'm using 32% of the CPU resources available. Well worth adding because it started out at 53% and it helped to reveal that I was doing some very slow and unnecessary things in my code that had to be improved or removed. Basically it's just counting the cycles that it spends waiting for the vertical blank, and remapping that to a value from 0..100% based on the max number of cycles available at 60fps. Figured out the max cycles by looking at the changes in the emulator's in-built cycle counter when the interrupt comes in. As it turns out, the frame budget is 133,462 cycles, which sounds a lot. But then it also turns out that it's easy to write code that burns through those cycles really quickly if you're not careful
    Really well done, and fun to play
  9. izb

    Rogue Forest

  10. Twitter: https://twitter.com/izb Twitch: (For Commander X16 game dev streaming) https://www.twitch.tv/budpico
  11. Yeah I updated the script to use the correct colours some time ago. Not sure why the version you had still discarded the lower nybble. Sent from my iPhone using Tapatalk
  12. I put an aesprite script in downloads that modifies the current palette to a 12-bit x16 one. I have it bound to a hot key so I can just nudge the colours into line every time I edit them. Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use