Change of product direction, good and bad news!

[TomXP411]

1 hour ago, paulscottrobson said:

If the X8 can be produced at the sort of cost mentioned, which I can certainly think it might be, given the cost of similar devices, then it's almost beer money (well, a good night anyway ...). I think most people who wanted an X16 may well buy an X8 as well. I'm not sure it works the other way round.



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.



But then the X8 could be the game machine version and the X16 the experimenters machine version, you could make the Kernel calls compatible and even provide alternate kernal versions to load VRAM, position Sprites and so on. (Though if you add SPI then you can pretty much connect anything you like anyway)



I think cost is important, always have. Some of the designs out there ; the Mega65 and the various Foenixes (?)  -ii (?) look excellent machines but it's an awful lot of money for a machine without a software base.  Even if X# never gets a significant software base (and I think both would get a reasonable one, though it's never going to match C64 levels obviously ...) it's not a big loss. WCS scenario for me for an X8 is that I can repurpose it as something else ?

Actually, I don't think the window design is that much of a difference, performance wise. I did the math a while back and demonstrated that a pipe approach is actually faster for most approaches than direct writes.

Yes, even for vector graphics.

That's because you still have to store the address being written to somewhere, and that somewhere can be the VERA address register just as easily as it can be a memory cell. Also, as the window approach only works for 256 bytes at a time, it's actually still going to require relocating the window for writes to different lines, which isn't really any faster than writing a new address to the VERA address register. 

And yes, cost is important... the $100-ish option will absolutely outsell a $400-500 option - especially if the more expensive system requires extensive soldering.

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

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

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

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