Change of product direction, good and bad news!

[John Chow Seymour]

Thank you all who answered.  @paulscottrobson's answer happened to be the one that made it the most clear, and after reading that one, I went back to read the other two and they also made more sense.

Two last clarifying questions, if no one minds (I hope these questions are helpful to the thread in general)...

12 hours ago, BruceMcF said:

Implementing X8 style access for the X16 requires [...] a bigger FPGA to give it the IO pins to have a two select lines (for IO slot select and X8 page select) and 9 address lines.

Why would we need 9 address lines to access a 256 byte window? In my ignorance, that sounds like it's addressable in 8 bits.

4 hours ago, paulscottrobson said:

On the X8, a small area of memory is set apart which is a 'window' onto the whole of VRAM that you can write to directly.

So when the CPU is writing to the area that is acting as the 'window', it's writing to VRAM instead of CPU RAM? Or the write affects both RAMs?

[BruceMcF]

1 hour ago, John Chow Seymour said:

Thank you all who answered.  @paulscottrobson's answer happened to be the one that made it the most clear, and after reading that one, I went back to read the other two and they also made more sense.



Two last clarifying questions, if no one minds (I hope these questions are helpful to the thread in general)...



Why would we need 9 address lines to access a 256 byte window? In my ignorance, that sounds like it's addressable in 8 bits.



So when the CPU is writing to the area that is acting as the 'window', it's writing to VRAM instead of CPU RAM? Or the write affects both RAMs?

Because the X8 does one page to write to the 64K video RAM, one page set to a dedicated page of Vera registers, and some dedicated I/O. If you wanted to be "plug and play" run X8 software, eight bits doesn't cover it.

Since the X8 page "window" is locked at $0400 in the current X8 memory map, and it it always VRAM read in that page, it doesn't matter whether the "system" RAM at $0400 is written, but it likely isn't, since it's the same 1Mbit of singleported RAM organized as 128KB. So a redundant write to the "actual" $0400 would require more FPGA cycles.

[Ender]

3 hours ago, John Chow Seymour said:

So when the CPU is writing to the area that is acting as the 'window', it's writing to VRAM instead of CPU RAM? Or the write affects both RAMs?

As far as I understand, it affects both.  The changes to the window in CPU RAM are mirrored onto VRAM, and where these changes are mapped to in VRAM can be controlled by a register.

[LRFLEW]

I'm a little late to the party, but I figured I might as well yell my thoughts into this void.

I have no problems with you dropping the case, especially if it's going to be a big issue. If things change in the future, I may be interested in buying the case separately if it is something where the finance issues can be resolved post-launch. As it is, however, not having a case isn't going to deter me from buying the product.

If you are going to half to hand-soldered the phase-1 boards, I'll probably buy the kit for myself. I don't really want to force someone else to spend that much time on just my board, and I'm willing to take the time to do it myself. (It's been a while since I tried soldering, but I think I should be able to handle it).

Between phase-2 and phase-3, the only real advantage I ever saw with phase-2 was the one expansion slot, and I just don't foresee the expansion slot being all that big of a feature. I don't see ready-made boards or kits for X16 expansion cards being something that gets made, and the tinkerers who would want to mess with it would probably go for the phase-1 board anyways. With this in mind, I would say skipping phase-2 probably makes the most sense, but I could be wrong about how people feel about the expansion slots.

The X8 seems... interesting. Looking over it's features and limitations, a few things stand out to me. The 256-byte window into VRAM is neat, but poses some real cross-compatibility issues. It also says that it has "all of the same [VERA] registers", so I'd hope this includes the original VERA's data ports for X8/X16 compatibility. The use of USB for keyboards and controllers is actually something I sort of want to see on the X16. As someone that doesn't have any old PS2 keyboards anymore, I'm gonna have to rely on the one supplied with the phase-1 release, and as someone who never owned a SNES, nevertheless a controller for it, I'll have to go out of my way to get one to use with the X16. Using my existing USB keyboard and controller seems like it would be a simpler solution, honestly. Also, the bump from 8MHz to 12MHz seems... odd, and I would at least consider making it togglable back to 8MHz through a memory register for better X16 compatibility. Otherwise, it kind of seems like the X8 is both a better and worse machine than the X16, which just seems odd to me. I don't really care too much about the Yamaha chip being dropped. In fact, I kind of think it's something that should have maybe been dropped when the PSG was moved to the VERA. The VERA already provides more channels that I think I'd know what to do with, and I suspect the Yamaha might be underutilized on the X16, especially if the X8 does get released.

The RAM and VRAM shrinkage does stand out to me as being potentially problematic. The 64K RAM is probably fine. Nothing I've worked on so far required using the banked RAM, but that's also because most of what I've done has been pretty small-scale data and code wise. It's something I could see being limiting for larger projects, such as games or "productive" projects like text editors, music trackers, or assemblers. The 64K of VRAM does seem somewhat problematic for me at least. Of the two projects I've shared here, only one would fit as it works now. Noise X16 would work as-is, as it only requires 37.5K to store the video buffer (320x240@4bpp). If I wanted to use double-buffering for vsync, it wouldn't work on the X8, but I decided when releasing it that it wasn't worth implementing vsync for it. AES X16 wouldn't work as-is because it requires 75K of VRAM for the video buffer (320x240@8bpp). The only real solution for this is to drop the vertical resolution to 200 to reduce the buffer to 62.5K, but the non-integer scaling just doesn't look very nice. I think I get why the memory is shrunk. I assume that the X8's combined RAM and VRAM is only 128K for the same reason that the VERA's VRAM is only 128K. I assume there just isn't any cost-efficient way of getting more memory onto it, so I get the limitation. I just don't know how much it will restrict developers.

I'm not entirely sure about releasing the X8. I do think it will likely end up similarly to the C64/C128 situation, with a lot of software targeting the lower tier, but I worry it could be more complicated than that. I'd worry it might dilute not the image of the X16 so much as dilute the specificity of the X16. To me, as someone who is too young to have really enjoyed retro computers in their prime, the X16 represents a modern-retro computer with an active community that will let me get as close to the experience I missed out on. Releasing a somewhat incompatible version along side the X16 will make the community less centralized, and would make it harder for me to get the experience I want out of buying the computer. It's certainly not a given, and I wouldn't say that you releasing the X8 would scare me away from buying the X16, but it's something I'd be concerned about if it does release.

[BruceMcF]

16 hours ago, Ender said:

As far as I understand, it affects both.  The changes to the window in CPU RAM are mirrored onto VRAM, and where these changes are mapped to in VRAM can be controlled by a register.

(1) Why would it be? Both are different locations of the same RAM module. That's why the VRAM is half as much ... not because it's a smaller RAM module, but because half of it is being used as system RAM.

(2) And if it was, how would you know, since you can only read VRAM at $0400. You cannot read "CPU RAM" there. So if for some reason it was designed to write the byte to the half of RAM treated as VRAM location and THEN in a second step to write the byte to the half of RAM treated as CPU RAM, you couldn't read it back from the CPU RAM location.

2 hours ago, LRFLEW said:

...



I'm not entirely sure about releasing the X8. I do think it will likely end up similarly to the C64/C128 situation, with a lot of software targeting the lower tier, but I worry it could be more complicated than that. I'd worry it might dilute not the image of the X16 so much as dilute the specificity of the X16. To me, as someone who is too young to have really enjoyed retro computers in their prime, the X16 represents a modern-retro computer with an active community that will let me get as close to the experience I missed out on. Releasing a somewhat incompatible version along side the X16 will make the community less centralized, and would make it harder for me to get the experience I want out of buying the computer. It's certainly not a given, and I wouldn't say that you releasing the X8 would scare me away from buying the X16, but it's something I'd be concerned about if it does release.

The thing is, it doesn't mean any FEWER X16 systems released until the "third phase", which was always described as something that needed the first two phases to succeed before being released.

I think the fact that the X16p is the one running almost entirely on new ASIC chips on a big motherboard people solder by hand and the X8 is an all-in-one FPGA device makes for the strongest distinction you could hope to achieve.

Which is why I argue it's probably OK if the X8 and the X16p DIY are released side by side, because they are hard to confuse with each other.

Then if the X16p has been released, the X16c is self explanatory.

It does mean that the X16e doesn't make much sense unless BOTH the X16p/c and X8 are successful, so that you bump up to the FPGA that is large enough to allow the FPGA + 2MB RAM chip approach to work, and has enough additional logic to support an OPM+DAC core, and then you provide a setting in what is otherwise empty I/O slot space, which sets an X8 compatibility mode.

[Ender]

@BruceMcF Are you saying then that the range of CPU RAM directly maps to the VRAM from a hardware perspective?  That makes sense, I didn't know that.  The way I imagined it was just how I interpreted David's wording in the original post, but I don't know a lot about the hardware side, so your way probably makes more sense.  (Technically though, you could use it as CPU RAM if you really wanted to ?).

[Ed Minchau]

5 hours ago, Ender said:

@BruceMcF Are you saying then that the range of CPU RAM directly maps to the VRAM from a hardware perspective?  That makes sense, I didn't know that.  The way I imagined it was just how I interpreted David's wording in the original post, but I don't know a lot about the hardware side, so your way probably makes more sense.  (Technically though, you could use it as CPU RAM if you really wanted to ?).

I do use VRAM for lookup tables already. It's particularly useful if you have a big table that needs to be read sequentially.

For my Asteroid Commander game, there are 88 tiles that make up the asteroid, and for each pixel I need a radius value and an angle value. Those are stored in an 11kb table in VRAM, and are used to generate a second 11kb table in VRAM that matches a spot on the map to that pixel. The second table is read sequentially later when it's actually drawing the asteroid, using the location data and asteroid rotation to select between a daytime color and a nighttime color, pushing the result sequentially to the tiles.

[KC2NIK]

I'm late to the party but I am super interested in Phase 1.  Give me the DIY kit and set me on a new educational path!  I would gladly donate to a kickstarter type of thing to help inject some capital.  Revisiting the 6502 and 8 bit computers have revitalized my education and I love relearning what I forgot in college.  This project hits a sweet spot and brings me back to my to (in my opinion) the "Golden age of computers".    I would like to be able to build boards to add features to the X16.

 

For nostalgia purposes a case would be super cool but it can be done later, even as a separate purchase.

 

PS. I am not really interested in phase 3...

[Colin]

I have read through most of the thread, so I don't think this has been asked or discussed, maybe I missed it.  Why can't the case be included with the kit?  I would purchase a kit version of the X16, but it would be more attractive to me if the case could be included.  Is it that anticipated sales of a kit version would be way below the minimum 1000 units that the case manufacturer requires?

[Ender]

2 hours ago, Colin said:

I have read through most of the thread, so I don't think this has been asked or discussed, maybe I missed it.  Why can't the case be included with the kit?  I would purchase a kit version of the X16, but it would be more attractive to me if the case could be included.  Is it that anticipated sales of a kit version would be way below the minimum 1000 units that the case manufacturer requires?

Well, David describes in his post that it would require renting storage to store all those cases, and a lot of manpower and time to package all of it, and he just doesn't have the time or money to do all of that.  I guess when he initially formed the idea he wasn't thinking they would have to deal with 1,000 units all at once.