Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by AndyMt

  1. On 12/7/2021 at 3:32 PM, Tatwi said:

    While that isn't entirely accurate, I agree with the sentiment, because I think there is a certain visual balance between "this is a computer" and "this is a keyboard"... yeah, something like that.

    I would say that if you're going to do another version, maybe make it a bit wider.

    I agree with this. It's probably not visible in it's current state, but the case is 2.5cm wider on each side than the keyboard and 2cm in the front. That's more than the Atari ST or the Commodore Amiga had. As for ofsetting... no, I'm too much of a fan of symmetry... The cursor key layout already adds enough visual asymmetry for my taste.

    On 12/7/2021 at 3:32 PM, Tatwi said:

    I too have designed a few wedge machines in Blender over the years, but I never built any of them. Good on ya for actually building yours!

    Thanks 🙂. I tried with Balsa-wood and Polyester resin last year, but gave up, it was too much of a mess... Having the printer makes things so much easier. And stuff really fits together as planned.

  2. On 12/6/2021 at 11:31 PM, Edmond D said:

    Are you considering it a one-off, making plans available, or even going for a commercial run?

    Never say never... but I have no experience with non-software commercial projects at all. Production, stock, logistics... let me put it this way: unless I find a partner taking care of this, this will be a one-off from my side.

    I for sure will put the design on Thingiverse - at least for non-commercial use.

    On 12/6/2021 at 11:51 PM, TomXP411 said:

    I have a friend who's willing to print a case on his large bed printer... this would be perfect for that use. 

    The parts are split so they fit on a 230x230mm print bed and with that the side pods have to be printed 45° diagonally. Without splits the largest piece would be 380x225mm (base plate). The overall size of the case is 395x240x65mm. You need to find a suitable ten-keyless keyboard to integrate. The stands I've modelled fit the Xtrify K4 keyboard which is available in a retro colour scheme.

    As this is my first big structure I've modeled and 3d printed probably there are better ways to split parts etc. I already know some awkward corners I want to fix first before publishing it.

    • Like 1
  3. Hi everyone

    while waiting for the X16 to get real, I started to design my own computer case. I want it to resemble the keyboard or wedge-shape cases of the 80ies era. I owned a TI-994A and a Atari ST back then and I wanted to have something similar where I can put the X16 board in. As I just started with 3D printing I fired up Blender and started designing. After many, many hours of sketching, klicking, dragging and swearing I started printing the whole thing. Then I integrated a xtrify ten-keyless keyboard (which I want to lower a bit) and integrated a MISTER, Raspberry Pi (and a KVM Switch). This now gives me the full retro vibe - until the X16 will arrive...

    So this is how it looks now, what do you think?


    The frame around the keyboard is still missing, but I'll do that as soon as I have lowered the keyboard.

    • Like 8
  4. I've now purchased a Xtrfy K4 TKL with retro colour scheme:


    I'll dismantle it and integrate it into a wedge shaped case (in the same grey colour, the filament I have is identical) which then will house my MISTER as well as a Raspberry (switchable).

    This should give me the full retro vibes until I'll get the X16p - which I plan to integrate into a very similar case. I'm modelling the case in Blender right now, I'll upload a preview as soon as it's presentable. I have to split it into at least 4 pieces, not sure how well that will look.

    • Like 4
  5. For me the nice package with the M.2 solution was the reason to go with it. There's also an integrated fan, just in case passive cooling isn't enough.

    The solution with the UASP USB adapter also allows to connect the M.2 SSD to your PC/Mac in case you want to perform a backup etc. just by flipping it over:


    This is very convenient.

    • Like 1
  6. On 10/18/2021 at 11:59 PM, ZeroByte said:

    EDIT: Yeah, that makes it run. Still no sound though, even if I un-click the mute icon. Strange.

    The web based emulator has a white list for file extensions. The music files have to use the .BIN file extension, too.

    I think allowed is only .PRG and .BIN, maybe .SEQ, don't remember.

    • Like 1
    • Thanks 1
  7. On 10/18/2021 at 1:49 PM, Guybrush said:

    You do realize that each tile instance (in tile mode, not character mode) and each sprite has a 4-bit palette offset field which allows you to use practically the entire 256-color palette?

    That's what I actually do in Brixx, where I use tile mode. In Invaderz I use bitmap mode. But you are right - there I could also use the palette offsets (bitmap and sprites) which would mitigate the issue. So the background images could be in 16 colours, which would probably be fine - and the sprites in 16 colours, too 🙂.

  8. On 10/18/2021 at 10:51 AM, Tatwi said:

    Perhaps when using an X8 that is limited to 512K of banked "high ram" as it's ONLY functional difference from a full sized X16, the programmer could use a routine that loads data from disk as it's needed rather than all at once in the beginning.

    This won't work for music, the single sound tracks are too big, which would not leave enough room for the actual game and loading them in chunks would be very challenging without interrupting audio.

  9. On 10/16/2021 at 7:55 PM, Sisko said:

    but out of all curiosity around what people think will happen with the x8 gets released (that all program development will focus on the lowest capable device), but is that not a concern with each phase of the base x16, Or is there such a leap in specs that I don't understand?

    For the games I've released so far (Brixx and Invaderz) for the X16 I would see the following impacts if I had limited them to the X8 specs:

    • No music soundtracks. I use Deflemask to compose and to export VGM and then convert this to a similar condensed format. Without the YM2151 I would have to use a different tracker - which doesn't exist - at least not one usable on a PC. Also my friend who is the composer of the soundtracks won't use anything different than the Deflemask.
    • Graphics need to be nerfed down to 16 colors instead of 256 for the title screens and background graphics (Invaderz). Which maybe would be ok for Brixx, but:
    • for Invaderz that would mean that the background needs to share it's 16 colors with the sprites as well. That might leave around 4 colors for background, 4 colors for player sprite, 4 colors for enemies and 3 colors for explosions/phasers etc. (1 color is the black background color). It won't look nice. Actually I'd rather remove the scenic background images then.
    • Probably less levels in both Brixx and Invaderz. At least there won't be more - which I had planned. The same for my jump & run platformer I had in development (halted atm).

    Bottom line for me is like this: Had the X16 specs been the X8 spec right from the beginning, the platform would have been less interesting for me and I would not develop for it now.

    Comparing the different X16 variants the X16e (FPGA) would only offer 512K of RAM and cannot be expanded (the others can). That's a limitation, yes - but it would be plenty of RAM for what is meaningful to do in most cases. Everything else is identical, software will run on all variants.

    Making the X8 mostly compatible with the X16 (VERA adressing, memor map, I/O adresses, ROM etc.) would leave it as a X16e with less RAM and VRAM... I'd suggest to just go for the X16e (FPGA) directly, to get some cash in. I'd buy one - and the kit version as well.

    • Like 2
  10. 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...

    • Like 1
    • Thanks 1
  11. On 9/9/2021 at 5:21 PM, ZeroByte said:

    I worked with @StephenHorn on the box16 emulator project while he was refactoring that emulator to use the new BSD-licensed YMFM core library. I've learned quite a bit about how this chip works.

    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?

  12. 40 minutes ago, Snickers11001001 said:

    Sheesh.   So on the X8, we would lose the ability to put ML code BASIC helpers/wedges at $0400 to $04FF, $0500 to $05ff, and part of page at $700. 

    Additionally, since there's no longer banked ram, the 8K at $A000 to $BFFF that on the X16 is 'page 0' of the banked ram and reserved 'for KERNAL/CBDOS variables and buffers" is the only RAM in that range.  

    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.

    • Like 1
  13. 4 hours ago, Yazwho said:

    The YM audio is a bit of a pain to use, given the clock speed difference you have to wait 144 CPU cycles between each write.

    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. 

  14. 8 minutes ago, Wonderdog said:

    In fact, I'd go so far as to suggest deliberately crippling the X8 and forcing it to use the same 4 byte register loading process of the x16 design rather than using the 256bit  window to maintain documentation and code consistency between the two. After that, the capability differences are largely related to how much RAM and VRAM is available, and how many channels of sound - so backward compat with X8 software could be much more easily maintained on the x16.

    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.

    • Like 3
  15. 1 hour ago, Wonderdog said:

    wonder if the spec of the X8 (before all the scope creep, supply chain realities and development challenges of the X16) was pitched in 2019, whether people would be complaining about the percieved spec compromises vs the x16

    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.

    1 hour ago, Wonderdog said:

    Also - I often wonder if Dave would have been better off all along reversing the original development and rollout plan, i.e. by starting with the launch of a cheap, easy to produce FPGA based core product with enough capability to encourage community buzz

    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.

    • Like 1
  16. 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.

  17. 6 minutes ago, David Snopek said:

    While application development for the X16 doesn't have to halt, I worry that shipping the X8 could affect the motivation level of the hobbyists who are making software for the X16. Even the suggestion that it could exist is already having an impact, unfortunately.

    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.

    • Like 2
  18. 7 hours ago, Carl Gundel said:

    Some of 8BG's games also do this, so why can't developers be encouraged to write games that work on both machines?  After all we do have access to an X16 emulator, so even if the X16 isn't available when the X8 is, there's no reason why software can't theoretically be developed for both, and published for both?

    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.

    7 hours ago, StephenHorn said:

    But there will be one X16, and maybe the X8. And the install base will be in the hundreds, maybe (maybe!) the thousands. This is much less incentive for wide support, especially if folks write software to be released for free, as opposed to software they intend to sell. Or, to the extend that wide support is encouraged, it will be by developing to the minimum spec shared between the two machines.

    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.

    1 hour ago, Stefan said:

    I do not believe in hiding the differences between X16 and X8 behind API layers. 8 bit computers running at 8 or 12 MHz need all computational power they have if we are to make great programs. Even if there were such an API many assembly programmers would avoid it to gain performance.

    If the X16 and X8 are incompatible, the programs written for them will be so too. If both the X8 and the X16 are released, developer time will be divided between the two platforms. 

    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.

  • Create New...

Important Information

Please review our Terms of Use