Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by AndyMt

  1. It's also Shift+2 on a Swiss-German standard keyboard ...
  2. I know where you are coming from: I intentionally used the 320x240 pixel mode in my games - in order to get the chunky look. Brixx for example would have been easy to do in 640x480, but I didn't want to... If you want it even chunkier: design your sprites by using 2 pixels at a time... Yes, this will waste VRAM, but as you would also probably not use 256, but 4 colours instead, that should not be an issue...
  3. The K70 TKL variant was on my shortlist, but unfortunateley at the time it wasn't availabe in a Swiss-German layout. It's media keys have a much better feel as the G915 ones.
  4. My favorite right now is the Logitech G915 TKL (Tactile Switches): I never thought a keyboard could make such a great difference. But it does! I now sometimes look forward to typing on it... But of course the IBM Model M is unmatched...
  5. I tried to get box16 to run, but have failed to compile my own compatible rom.bin (don't get the toolchain to work on Windows, despite the instructions being pretty clear). I then used a rom.bin from an older R39 release I had lying around, but of course this doesn't work, too. Any ideas?
  6. Indeed - you are right, thanks for pointing this out. It would also mean we actually have much less memory available as there seems to be no way to access the other 8k (bank 1)? That makes me even less enthusiastic for the X8 now. I'd really prefer it to have the same memory layout and banking mechanism as the X16 and also it's same access mechanism to VERA.
  7. Yes, that might be the issue then. Oh well. All the more important to get actual hardware.
  8. Wait! Im confused - because I don't do this in my games and music works nevertheless. I write as fast as possible to the YM until there is a KEY_ON command - or I have to yield because of a delay. This then is synced with the vsync interrupt. So yes, for sure there is more than 144 CPU cycles between each KEY_ON command, but not between each write.
  9. I fully agree on this! The X8 then would be a X16 light... The effort to support both would be minimal. Actually all X8 software would run on the X16 unchanged - no recompile required. That should be the goal.
  10. That's a valid point. I personally would have been perfectly fine with the X8 specs in the first place. My issue with it is the incompatible memory layout and access to VERA compared to the X16. If the X8 could be made 1:1 compatible in regards to memory layout and VERA access - I would be tempted. That's a very valid point, too... Maybe going for phase 3 directly would be the best option. I mean the emulator already achieved some if this effect, but didn't result in a cash injection.
  11. If you stick to 320x240 in 256 colors - yes that's possible - but challenging. I've done it in Invaderz for the background graphics, which all use around 200 colors (the rest goes to the sprites of player and enemies). Thing is - in the emulator, loading the bitmaps takes almost no time. But it will be slower on real hardware, roughly 2 seconds per screen when loading from SD card. Using compression techniques might not mitigate this, as unpacking will use CPU time... Unpacked, each screen takes around 76kBytes of data.
  12. Yes - it definitely had an impact on my motivation already. Probably I'll regain it when the decision is made, let's see . I don't want to be too negative on the situation. I already learned a lot with the X16 emulator. Maybe developing for the X8 will be another fun journey. As I said earlier: if the VERA interface for the X8 will be made compatible with the X16, then I'll develop for both. Otherwise probably only for one of the two.
  13. I'm thinking about something similar for the mATX board:
  14. If the Phase 2 will be a thing, then I'm thinking about this one: https://myretrocomputer.com/product/my64/ I really want to have the X16 inside a all-in-one wedge keyboard. For Phase 1 I'll probably have to design my own case...
  15. For sure this is possible, but - it takes away time from my budget to actually develop something. I would certainly only develop for one of the 2 platforms and not go into the hassle to do ports. I'd probably also wait until there is a clear indication of which platform "wins". Maybe I'll then not develop for any of the 2 at all because my focus moved somewhere else. I fully agree. Let's assume the X8 gets the same VERA interface as the X16 and is tuned down to 8MHz. I'd probably just develop to the minimum specs. For the 2 games I've released so far I pushed the X16 as far as I could. I've used almost all the VRAM (256 color bitmap graphics, lots of 256 color sprites) and also plenty of banked RAM (for music and sound). My platform jump & run game in the works goes even further: sound track running in parallel, 256 color palette switching to show up to 512 colors at once, partial palette shifting to achieve "water flow" effects etc. I'm not sure what I'll do with it now - probably just wait and see what happens. Here I also agree. If the VERA interface is different, then the software will be incompatible. Or the effort to make it compatible will take away performance, which could be too much.
  16. I thought about the whole situation for a bit more. I still think it's best to release the Phase 1 X16 first. About the next steps I'm not so sure any more... Yes - this! Regarding the X8: If it as the same VERA interface, then I will support it. Ok - I would have to throw away all the bespoke sound tracks for the YM 2151 I have sourced. But because of the limited RAM those would not be usable anyway, so my games then will be without any sound. Also graphics would have to be tuned down, and I personally won't make use of the double VRAM on the X16 in the future. But I won't go into the hassle of supporting 2 different VERA interfaces. If I would, then there were different ways of addressing this, which I don't like: Use wrapper functions: impacts performance. Use conditional compilation (cc65) / macros (assembler): harder to maintain, makes code less readable, no impact on performance Maintain different/mixed code bases: even harder to maintain, but also no impact on performance. Yes all of the 3 options would work and also the additional effort is maybe not that big - but it is there and would take away time from the actual fun development. If it is possible: integrate a YM2151 in fpga. So we would be able to use existing music trackers like Deflemask etc. Otherwise it will be hard to create high quality sound tracks. All the instruments and samples need to be recreated, for the YM everything exists. So: please if you release the X8, then make it's VERA interface identical to the X16. And tune down the CPU speed to 8MHz. It would be so hard to explain why the little brother of the X16 is 50% faster. If possible integrate a YM2151 FPGA implementation.
  17. For me this project alway was about the full retro experience with a modern twist. I want to understand how it works by just looking at the board. I'd order a kit version any time. Also offer it pre-assembled for those who don't want or can assemble it themselves. As for the case: just point to places where we can get them on our own. I will 3d print my own wedge style case anyway. Skip phase 2. I don't think its needed. Then the X8. While it has its appeal, I would not release it. Maybe I would support it, if it had the same interface to VERA. I then could just trim down the programs and games I did for the X16. But different access to Vera would probably drive me away from both. And here is the next problem: few software would use the full potential of the X16. You would end up with mostly X8 only software.
  18. Every tile set can have 2,4,16 or 256 colors - and you can have 2 different tile sets, each of them on it's own layer. So this should be easy to achieve. I did use this for my Brixx game where the bricks etc are a 16 color tile set on layer 0 and the text for highscore etc is the standard character set on layer 1.
  19. When I look at the latest board just posted a few hours ago: We can find a socket labeled "YM2151" at the bottom right. So I'm pretty sure the YM2151 will be in the final design - as is the VERA PSG/PCM. Personally I'm pretty pleased with that .
  20. Because that's version R38. If you want to develop for the upcoming R39, then you need to compile it yourself (or get it from someone else).
  21. I understood that there is no 3d calculations involved. But for Wipeout those might not be needed if we accept some limitations. The course would be pre-calculated (as is the demo) and the perspective would be fixed to a virtual observer following the player in the middle of the course. Tricky would be rendering the player and opponent pods... maybe Spites (ugly)? Or pre-calculated polygons for each object for let's say 10 different distances (more cpu cycles)?
  22. I'm really impressed by this, just wow ! A Wipeout style game could be in reach with the cx16. That's so impressive.
  23. ATARI 520 ST, back in the days around 1987: Piggybacking RAM chips on the existing ones to upgrade vom 512kB to 1024kB RAM. It was quite thrilling soldering all those chips and adding those wires to the MMU ... And it worked !
  24. This sounds familiar . I do something similar in Brixx and Invaderz for the laser sprites and explosions. The main player sprite and some others use fixed slots, though. I'm very much looking forward to the end result.
  • Create New...

Important Information

Please review our Terms of Use