Jump to content

izb

Members
  • Content Count

    28
  • Joined

  • Last visited

  • Days Won

    2

izb last won the day on October 28

izb had the most liked content!

Community Reputation

45 Excellent

Recent Profile Visitors

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

  1. 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.
  2. 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?
  3. 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
  4. 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
  5. Twitter: https://twitter.com/izb Twitch: (For Commander X16 game dev streaming) https://www.twitch.tv/budpico
  6. 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
  7. 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
  8. Will there be appendices listing tables of things like the Vera registers, or special memory locations as a quick reference? Sent from my iPhone using Tapatalk
  9. If I was given a penny for every time a bug was caused by a missing # then I’d have angrily thrown about £3.50 out of the window by now. Sent from my iPhone using Tapatalk
  10. Drat. It’s a shame the cycle counter is read only. It’d be a nice convenience to be able to zero it and easily measure how many cycles my game loop is using. Is there some emulator specific reason that it shouldn’t be modifiable from code? Sent from my iPhone using Tapatalk
  11. Not a game I’ve actually played. Gonna have to seek it out now though
×
×
  • Create New...

Important Information

Please review our Terms of Use