Change of product direction, good and bad news!

[AndyMt]

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.

[BruceMcF]

13 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.

This isn't as crazy as it might sound - as I'd assume a similiar intentional nerfing would need to occur with the eventual FPGA based x16e (which would also be capable of using the window as everything is in the FPGA), as otherwise it would require/offer software capabilities equally different to the kit/surface mounted x16's.

Thing is, it might not be possible. The logic resources to do the the two independent autoincrements on the two data ports are freed up by the X8 approach ... it's just an internal latch generating the effective high eight bits of the "video" RAM address ... and those logic resources might be used by the ADC/SBC/CMP operations and the ,X and ,Y address modes.

For the X16e, it wouldn't be nerfing: the design would be to simulate the X16p, and if you need a bigger FPGA to do so, you just switch to a bigger FPGA than Vera uses, in the same family. You have to switch to a bigger FPGA anyway to get the 14+1 or 22 address bus lines and 8 external data bus lines ("+1" if it multiplexes the high address bus lines and the data bus, using a toggle line rather than chasing the Phi Clock like the 65816).

But since the X16e isn't supposed to have slots, it has plenty of room to put a toggle bit to switch to X8 addressing the first 64KB of video RAM and more of the Vera internal registers in the X16 Golden Ram, so the X16e could well be designed to be compatible with both, which would kind of justify being twice the price of the X8. Indeed, that'd be the design that could be considered for a third campaign, if the sales of the X16p/X16c and X8 indicate there might be an appetite for such a beast.

_____________

1 hour ago, paulscottrobson said:

I think code is fairly portable between the two designs, especially if you design it with that in mind. The problem is the window design is capable of doing things that the pipe design isn't, if you wanted to do a vector game the frame rate would go up significantly.

Sure, if you want to do a vector game in what was originally a sprite and tile video system, and don't require a lot of game resources ... the extension RAM can also allow preloading a lot more things from the SD card as a level is playing, so it can do things faster than putting up a load screen and loading from the SD card when you need the assets.

I expect vector gaming on the X# family is going to be like when David Lettermen's Stupid Pet Tricks had a cat that would actually do a trick come on ... people were not impressed by the trick itself as much as by the fact someone was able to get a cat to do a trick. Sprite and tile games are going to be more of the bread and butter.

Edited September 6 by BruceMcF

[Wonderdog]

53 minutes ago, BruceMcF said:

But since the X16e isn't supposed to have slots, it has plenty of room to put a toggle bit to switch to X8 addressing the first 64KB of video RAM and more of the Vera internal registers in the X16 Golden Ram, so the X16e could well be designed to be compatible with both, which would kind of justify being twice the price of the X8. Indeed, that'd be the design that could be considered for a third campaign, if the sales of the X16p/X16c and X8 indicate there might be an appetite for such a beast.

I'll take your word on the potential logic capabilities - the detail is way beyond my puddle deep level of technical understanding  

It would be odd from an ecosystem perspective for the X16p/c not to have straightforward backward compat with X8 native code though - as the X8 feels like be a great way to help people get their hands on something tangible to start work on X16 (specifically 65C02+VERA) compatible software - of course it would have to fit inside the constrained RAM window etc. but it seems like that headstart and the confidence of having some hardware out in the wild would be very helpful to the overall X16 project as a whole (both in terms of audience confidence in the long term prospects, and as a way to bring in some money). Emulators are great, but prone to change and still leave the eventual device feeling ephemeral - a lot of people are put off developing or writing tutorials for a device that may never appear! 

I get the impression that the main bones of contention with the X8 are the risk of developer ecosystem fragmentation, and the risk of "poaching" sales from the X16. If the X8 code is directly backward compatible, then ecosystem fragmentation is a lot less of an issue, and the selling points I'm hearing from those opposed to the X8 are that they really want the X16 increased capabilities (RAM, Sound chips, expansion etc) and physical formfactor (chips on a board) for their own ends, rather than any need for everyone to have access to those features - as I can't see anyone paying the mortgage selling X16 software anytime soon - so I just dont see what releasing a code compatible, cut down device in the form of the X8 is taking away from those hardcore X16 users.

Edited September 6 by Wonderdog
typo

[paulscottrobson]

1 hour ago, BruceMcF said:

I expect vector gaming on the X# family is going to be like when David Lettermen's Stupid Pet Tricks had a cat that would actually do a trick come on ... people were not impressed by the trick itself as much as by the fact someone was able to get a cat to do a trick. Sprite and tile games are going to be more of the bread and butter.

Michael Steil and I have both independently written general line drawing routines for 320x240x256 mode and they're pretty much the same speed, and it's not great, a couple of lines a frame.  If I was doing Asteroids I'd do it with pre rotated sprites with 4 way mirroring.

[paulscottrobson]

42 minutes ago, Wonderdog said:

I get the impression that the main bones of contention with the X8 are the risk of developer ecosystem fragmentation, and the risk of "poaching" sales from the X16. If the X8 code is directly backward compatible, then ecosystem fragmentation is a lot less of an issue, and the selling points I'm hearing from those opposed to the X8 are that they really want the X16 increased capabilities (RAM, Sound chips, expansion etc) and physical formfactor (chips on a board) for their own ends, rather than any need for everyone to have access to those features - as I can't see anyone paying the mortgage selling X16 software anytime soon - so I just dont see what releasing a code compatible, cut down device in the form of the X8 is taking away from those hardcore X16 users.

I think it's exaggerated. I don't see it as difficult having X8/X16 compatible code as long as you don't make too heavy use of the window. It wouldn't be hugely difficult to have an X8 and X16 version with different graphics (say the X8 might have 4 bit colour and the X16 16 bit)

From what I understand from what BruceMcF especially has said if you could have a serial interface on the X8 along the lines of SPI then you could add a fast serial RAM or you could load it off the SD Card, and the SPI could connect devices in the way an old fashioned parallel expansion bus does.

The sound chip, the YM2151 (?) doesn't really matter a great deal. There's several channels and PCM audio on Vera. There's only so much sound you want, and if someone wants something really fancy they can just build a board with an SPI interface. You could do MIDI this way as well, just use a MCU chip as a bridge.

In some ways this parallel things is better. If you wanted (say) a classic "User I/O port" you could wire things to you could just get an Arduino or ESP32/8266, use their SPI libraries and control the pins by sending instructions. This would have advantages - if  you cocked up the electronics you'd probably just blow up the Arduino, not the computer.

As for poaching sales, I think many would buy an X8 if it was $50 which is dirt cheap really. I think the idea of charging a bit more for it to help fund the X16 is worth considering. Especially if the X16 is a kit, many won't purchase it, I'm not a bad soldered, I've a working Gigatron in my desk, the X16 would be pushing it.

[John Chow Seymour]

11 hours ago, paulscottrobson said:

The problem is the window design is capable of doing things that the pipe design isn't, [...]

I'm wondering if someone could, very briefly, explain/summarize the difference between these two graphics approaches.  (Not necessarily @paulscottrobson, your post was just a handy one to quote that mentioned both.)

I'm not a graphics guy at all (all my work in assembly has been SIO/text, or sound), and for either the X8 or the X16 I would have to learn how the graphics system works.  For anyone else on the forum here who might fall into that same boat, the briefest of comparisons might aid the discussion.

Not a tutorial on how to use the two, just maybe a 1-2 paragraph overview, would be greatly appreciated. (Apparently the 'window' approach requires more pins on the FPGA - why? Does one or the other demand more of the CPU's cycles? etc.)

If such an explanation already exists (possibly in another thread) then I apologize and would appreciate a link.  Thank you!

[Ender]

2 hours ago, John Chow Seymour said:

I'm wondering if someone could, very briefly, explain/summarize the difference between these two graphics approaches.  (Not necessarily @paulscottrobson, your post was just a handy one to quote that mentioned both.)

I'm not a graphics guy at all (all my work in assembly has been SIO/text, or sound), and for either the X8 or the X16 I would have to learn how the graphics system works.  For anyone else on the forum here who might fall into that same boat, the briefest of comparisons might aid the discussion.

Not a tutorial on how to use the two, just maybe a 1-2 paragraph overview, would be greatly appreciated. (Apparently the 'window' approach requires more pins on the FPGA - why? Does one or the other demand more of the CPU's cycles? etc.)

If such an explanation already exists (possibly in another thread) then I apologize and would appreciate a link.  Thank you!

Not really sure what you already know, and what you're asking for, but I can summarize it from a software standpoint (no idea about the hardware side/feasibility of setting up the X8 to act like the X16).

On the X16, the way you write to the VERA is to write to specific addresses ($9f23/4).  When you write to these addresses, the data is automatically transferred to the VERA.  You can set the address on the VERA it's written to by writing to the addresses $9f20-2.  The VERA also has a feature where you can set it to auto-increment the address for you so you don't have to worry about that.

On the X8, there is a 256-byte window that you can write to that is mirrored to the VERA, rather than writing to the two addresses.  You control where on the VERA this 256-byte window maps to.  This is convenient for loading right from disk into the window, for example.  Besides that though, (and I haven't thought about this a whole a lot so take this next part with a grain of salt), but from a VERA user's point of view, implementing a game or something, it doesn't seem that much different to me, besides that you're incrementing the address you're writing to yourself as you write into the window, rather than letting the VERA handle that for you. You also have to worry about changing the window address every 256 bytes.  So honestly, it seems more complicated to implement for than the X16 to me.

Edited September 6 by Ender

[BruceMcF]

3 hours ago, Ender said:

On the X8, there is a 256-byte window that you can write to that is mirrored to the VERA, rather than writing to the two addresses.  You control where on the VERA this 256-byte window maps to.  This is convenient for loading right from disk into the window, for example.  Besides that though, (and I haven't thought about this a whole a lot so take this next part with a grain of salt), but from a VERA user's point of view, implementing a game or something, it doesn't seem that much different to me, besides that you're incrementing the address you're writing to yourself as you write into the window, rather than letting the VERA handle that for you. You also have to worry about changing the window address every 256 bytes.  So honestly, it seems more complicated to implement for than the X16 to me.

The thing about the the page window is in the 6502, if you are writing to an arbitrary RAM location, STA (W),Y is replaced by STA $0400,Y ... and when you adjust the high address of the address by adjusting the high address of the zero page location in a normal RAM access, with a page window, you do the same adjustment to the page window register ...

... instead of INC W+1 you do INC VRPAGE ...

... so you can implement line drawing routines as fast in the X8 system as in a direct RAM based video display.

Implementing the X16 access STYLE in the X8 may or may not be possible, but it wouldn't be at $9Fxx ... to be plug and play compatible, it would be a shift of the X16 IO page to $0400 and shuffling the X8 IO pages around so the unique IO register at presently $0600 and up are where expansion slot locations are in the X16 IO page.

Also, it might not be possible in the Vera FPGA ... the logic resources used to implement the auto incrementing data port registers might be used for something else by the X8 ... the X8 has an entire extra 65c02 core implemented that Vera doesn't have.

To be compatible with reassembly or patching to a different IO location, the Vera 32 address slots could be implemented in the X8 somewhere in the general IO registers presently at $0600 and up. But it might require stepping up to the next larger FPGA in the family.

Implementing X8 style access for the X16 requires the same moving the IO page down to $04xx, with VRAM window in $0500 and Vera register page at $0600 ... but also 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. And a complete shuffle of the chip select circuits.

[paulscottrobson]

13 hours ago, John Chow Seymour said:

 

You have the RAM the 6502 can access, and you have VRAM which it normally can't.

On the X16, you write to VRAM by writing to an address and the byte is copied into VRAM.

So to write a byte :

• Set the address register to the VRAM address you want to write to
• Write the byte to the data register

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 to write a byte :

• Set the window so it makes visible the bit of VRAM you want to write to
• Write the byte to that memory slot.

The main advantage is the second one is more flexible. You can set the address register on the first to autoincrement, so you can just send a series of bytes, but on the second you can just use 6502 code to write arbitrarily to anything in the window.

[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.

Edited September 8 by BruceMcF

[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.

[Cyber]

17 hours ago, BruceMcF said:

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.

I very much agree with you, Bruce. But we both followed this project and this thread from the beginning and with paying attention to details. I noticed that members, who just read some announcements occasionally, are confused.

After all discussion in this thread I still think it's a good idea to release X8 alongside with X16 or even before X16. David made valid points in the first post of this thread. There is hardly a confusion here. Those who understand - will understand. Those who don't - will encounter things to confuse with and to complain to.

[rje]

Re X8, X16, and VERA.  The X8 is more like Commodore's memory-mapped I/O.

Because college was soooo long ago, I had forgotten about using ports.  But because I first learned programming on Commodore machines, I thought memory mapped I/O was not only natural, but just right.

The X16's interface to VERA is a pair of ports, isn't it?  I can handle it, but I prefer memory mapped.

 

Edited September 9 by rje

[Eric Retro]

I just joined this forum to comment on this crossroad.

I am excited about the Phase 1 DIY board and even more excited about the community surrounding this effort.

My perspective on this project is that it is pragmatically realizing an 8-bit computer that many of us first learned on while incorporating new features that a beginner could still wrap their head around to understand and peek and poke at the whole thing.

Some of those new features are expandability and modularity including the VERA video card/sound card/storage and expansion bus.  These features make the system more relevant going forward in a world where kids look at 8-bit graphics and ask why is it blurred?

The heart of the system is an 8-bit processor and the limitations and idiosyncracies required.

This standard system is a challenge to builders and developers to do their best and when possible show their work on github etc.

I even see this as an important cultural thing where people have been shut out of building/fixing/tinkering with new tech at a hardware level because it is unapproachable.  This system will be approachable for centuries.  Education and curiosity will both benefit.

So based on the above I am ready to put some cash down on ten Phase 1 X16 DIY kits.  I will hire a couple guys in the Philippines to solder together 8 of them and resell those completed with a reasonable markup to cover labor.

I see having a finished Phase 1 board in your own personalized case and accessories as a badge of honor and pride.

I am also currently developing a Populous style game in Assembly for the emulator in order to learn more.

I want the audience for the software developed for the system to be as large as possible so I would support a much cheaper FPGA hardware emulation as long as it didn't segment the market with different specifications.  I also agree with a cheaper surface mount system with expansion if demand supports it which makes for a great Kickstarter test.

I would not support segmentation with a lower common denominator X8 / X16 bifurcation issue.  Why not use an X16 emulator in the meantime?  Perhaps there is a way to make the X8 and X16 even more similar?  The video ram window is a nice feature and I wish both could support it.

I also think the VERA video card/sound card/storage cartridge for other systems would be an excellent feature to increase the audience for porting new X16 software to these other systems.

I can imagine where the video card/sound card/storage for the X16 could be upgraded as a replacement daughter board or expansion card.

Thanks for reading this and reflecting on my perspective.

This whole project has made me very excited including this conversation.

[BruceMcF]

13 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 ).

Yes. From the FPGA people have worked from pictures of Vera, there is a 128KB RAM module built into that FPGA. It is single ported ram, so only one FPGA circuit can write it or read it at a time. The fact that it is built in is how Vera can have an internal VGA dot clock of 50MHz.

The X16 uses all of that as "VRAM". The X8 reallocates 64KB for the 65C02 " soft core" to use.

From unofficial information about the X8, the page in the X8 CPU system address at $0400 is always the page of VRAM set by the VRAM bank register. The page at $0500 always maps to a fixed set of Vera registers. The I/O that takes part of page $0700 always accesses the control and data registers for that I/O. The VRAM window "moves around" in VRAM, but its location in the CPU memory map is fixed.

Edited September 9 by BruceMcF

[BruceMcF]

5 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?

It's almost certainly economies of scale. When you subtract the kits bought by people who don't want cases, the number of large cases can easily be less than 1000. Indeed, if you don't have cases, but have "support" tiers that include keyboards and some different goodies (name on a supporters page, printed docs, etc), it's a lot easier to put together a crowdfund campaign that can be structured to break even on keyboards than to structure one that can break even on cases. You might even want to set the "go" volume on kits at 200 and cap the first campaign under 500 X16p kits, to make sure you avoid "fulfillment hell" and the bad reputation it brings.

If the crowdfund is a runaway success, then there should be financial flexibility to just produce more kits and sell them on pre order in batches. And if it funds but doesn't max out, you know where to set expectations on the market.

If there is also an X8 with keyboard tier in addition to keyboard support tiers and a range of 200-500 kits in the first campaign, hitting break even on keyboards would be pretty straightforward, while hitting break even with the Micro-ATX cases could easily be infeasible.

Edited September 9 by BruceMcF

[Snickers11001001]

48 minutes ago, BruceMcF said:

Yes. From the FPGA people have worked from pictures of Vera, there is a 128KB RAM module built into that FPGA. It is single ported ram, so only one FPGA circuit can write it or read it at a time. The fact that it is built in is how Vera can have an internal VGA dot clock of 50MHz.

The X16 uses all of that as "VRAM". The X8 reallocates 64KB for the 65C02 " soft core" to use.

From unofficial information about the X8, the page in the X8 CPU system address at $0400 is always the page of VRAM set by the VRAM bank register. The page at $0500 always maps to a fixed set of Vera registers. The I/O that takes part of page $0700 always accesses the control and data registers for that I/O. The VRAM window "moves around" in VRAM, but its location in the CPU memory map is fixed.

Do you have any links to the source of those addresses/pages on the X8? 

Is the memory at page $0600 affected?     What 'part' of page $0700 is also spoken for?