Jump to content

X8 Release Date q:


EMwhite
 Share

Recommended Posts

I really have no idea what the 'rules' are around here; feels like so much has changed across the last month or two so moderator/webmeister, feel free to delete this thread; I won't complain or mind.  I'm here to respectfully ask for an update, if there is one...

About a month ago, 8 Bit Guy said "The X8 could be available immediately and be well under $50.  I'm not sure how far under $50.  I'd say as low as $25 and as high as $50. "

With over 300 'votes' and voting tapered off, "immediately" well behind us, and no mention of Commander X[anything] on the VCF East agenda, I was just wondering if there was an update or maybe a date on when the folks running this show think an update might be provided.  Thank you.

 

  • Like 1
Link to comment
Share on other sites

On 9/26/2021 at 4:33 PM, EMwhite said:

I really have no idea what the 'rules' are around here; feels like so much has changed across the last month or two so moderator/webmeister, feel free to delete this thread; I won't complain or mind.  I'm here to respectfully ask for an update, if there is one...

About a month ago, 8 Bit Guy said "The X8 could be available immediately and be well under $50.  I'm not sure how far under $50.  I'd say as low as $25 and as high as $50. "

With over 300 'votes' and voting tapered off, "immediately" well behind us, and no mention of Commander X[anything] on the VCF East agenda, I was just wondering if there was an update or maybe a date on when the folks running this show think an update might be provided.  Thank you.

 

"About a month ago" is about four weeks. That's not that long to make the fundamental decisions they have to make, given that this is a volunteer team contributing their sometime not very abundant spare time to the project, and then when those decisions are made, there will be some more time required to hammer things out into a firm enough shape for public announcement of the new development path and anticipated timeline.

As far as rules ... the team announces when they have something to announce, so the answer to "when is the next update coming" is always "when it's ready", so there is indeed a general rule against threads that are basically asking when the next update is coming. Its point three in the welcome message to the forums:

Quote

3. Please don't ask for updates/videos/pricing: Announcements will be made when available

 

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

I can understand their silence perfectly. Absolutely perfectly. They can spend their time and effort developing the actual hardware, or just talking about the hardware instead. And not building it. There is no opportunity to allow the internet community to help with the project, it has to be done by just a few offline people, nothing else can work, it is exactly the reason why virtually every automotive mechanic have signs that tell customers to stay out of the workshop. I always manage to be welcomed into the workshop after one or two visits, however I know the problems they face because I educate myself about those problems. Hissyfit hysterical customers at the auto mechanic drive the price astronomical for everyone. No I am not talking about you or anyone, just generally explaining why updates are scarce.

 

It brings to mind a Keanu movie called chain reaction, someone is criticizing his character Eddie Kasalivich asking them something like why haven't they documented the device on the computer yet or some version of that, and he's been up all night in the machine shop and says "because I was building it". So yes, there are plenty out there who do nothing at all except slow the entire process to a halt, oblivious of the effects. Again, not you or anyone, just talking generally as to why PR is counterproductive to production in a far less than ideal world.

Link to comment
Share on other sites

On 9/26/2021 at 9:33 PM, EMwhite said:

I was just wondering if there was an update or maybe a date on when the folks running this show think an update might be provided.  Thank you.

 

Perfectly reasonable, but so is the silence. Dave tapped the community, got a response, has probably read some of the discussions, most of which were fairly predictable, and he'll make a call with input from other senior project members. It's a difficult call and wouldn't be helped by any more speculation on his part.

We can talk about it all we like of course 🙂 That can be helpful ; I would hope if they are going down the X8 route they've taken note of the things Bruce (mostly) has written about an SPI port.

 

  • Like 1
Link to comment
Share on other sites

On 9/27/2021 at 9:49 AM, paulscottrobson said:

I would hope if they are going down the X8 route they've taken note of the things Bruce (mostly) has written about an SPI port.

 

And hopefully able to keep the vram access mechanism the same as the X16 spec.

Link to comment
Share on other sites

On 9/27/2021 at 5:32 AM, Wonderdog said:

And hopefully able to keep the vram access mechanism the same as the X16 spec.

Address compatible would not work ... but function compatible would make a reassembly or patch for compatibility of low RAM applications straightforward, that would be great!

Mind, I'm skeptical that it's possible ... I suspect the logic resources freed up by not having the incrementing address port may be part of what is used for the 6502 core (which needs an adder for indexing and an adder for the arithmetic operations) ... but if it is possible, it would be great.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

On 9/27/2021 at 10:32 AM, Wonderdog said:

And hopefully able to keep the vram access mechanism the same as the X16 spec.

No, I much prefer the window. Compatibility isn't difficult - 98% of the time it is just loading stuff in to VRAM, which is part of the Kernel anyway (or should be !), and you may of course want different resolutions and/or sprite colour depths. And you can do stuff with the Window you can't do with the pipe.

Programmers should be seperating their view anyway, so you can do what Dave has done with his Petscii Robots game, port it fairly easily. And well all keep our Models and Views seperate ..... of course 😉

  • Like 1
Link to comment
Share on other sites

On 9/27/2021 at 3:13 PM, paulscottrobson said:

98% of the time it is just loading stuff in to VRAM

Funny, I'd say 98% of the time I'm not using it to 'load stuff into VRAM'.

Maybe you do, which is fine, but don't assume that is what everyone else is doing.

On 9/27/2021 at 3:13 PM, paulscottrobson said:

Programmers should be seperating their view anyway, so you can do what Dave has done with his Petscii Robots game, port it fairly easily

Personally I find the idea of writing code that runs on all 6502 based machines boring. If I were writing a database or a spreadsheet then I guess so, but that's not where some people's interest is.

  • Like 1
Link to comment
Share on other sites

On 9/27/2021 at 2:32 AM, Wonderdog said:

And hopefully able to keep the vram access mechanism the same as the X16 spec.

That's Highly unlikely, due the lack of banked RAM.

On the X16, I/O sits between main and banked RAM. On the CX8, there is no banked RAM, and the ROM is apparently just a bootloader. So it's likely that the  CX8's memory map will be very different in upper memory... there will still need to be some I/O space, but if the ROM is only 8 or 16K, that will definitely put the I/O map in a different location than the Commander X16. 

At that point, you already have to refactor code, and David already said that changing the VRAM code for PETSCII Robots was like a 10 minute job. So if the X8 does come out, I'd rather see it be its own thing with as many optimizations as possible, to take advantage of the single integrated FPGA. 

 

Link to comment
Share on other sites

On 9/27/2021 at 5:46 PM, TomXP411 said:

That's Highly unlikely, due the lack of banked RAM.

On the X16, I/O sits between main and banked RAM. On the CX8, there is no banked RAM, and the ROM is apparently just a bootloader. So it's likely that the  CX8's memory map will be very different in upper memory... there will still need to be some I/O space, but if the ROM is only 8 or 16K, that will definitely put the I/O map in a different location than the Commander X16. 

At that point, you already have to refactor code, and David already said that changing the VRAM code for PETSCII Robots was like a 10 minute job. So if the X8 does come out, I'd rather see it be its own thing with as many optimizations as possible, to take advantage of the single integrated FPGA.

The "mechanism" being the same may be possible. That depends on how much of the logic resources the X8 uses. IIRC, Frank said that Vera used about 85% of the FPGA logic resource ... and the X8 adds a 65C02 soft core and some I/O ... so it might not be feasible. That is an open question.

The mechanism being located at the same address would indeed be too late.

The bootrom code when selected in is apparently 512bytes ... the top two pages of the 64K system memory space when the bootrom is selected, $FE00-$FFFF. So the Kernel would seem to be part of the binary blob it loads from the serial flashROM on powerup.

But if in addition to the existing window system, there was also the X16 Vera data port system in some 32bytes in the I/O control page ... I think that it in the page starting at $0600 ... then for code that fits in normal CX16 Low RAM, you wouldn't have to refactor anything ... you'd just have to change the assignment of the base of the Vera register slot, and reassemble.

Link to comment
Share on other sites

While I also suggested having 100% compatibility between x16 & x8 Vera access would be nice, it is definitely not essential. A "hardware abstraction layer" isn't difficult to create in the worst of times, and the similarities between the platforms will make it even easier.

  • Like 1
Link to comment
Share on other sites

On 9/27/2021 at 10:13 PM, Yazwho said:

Funny, I'd say 98% of the time I'm not using it to 'load stuff into VRAM'.

Maybe you do, which is fine, but don't assume that is what everyone else is doing.

Personally I find the idea of writing code that runs on all 6502 based machines boring. If I were writing a database or a spreadsheet then I guess so, but that's not where some people's interest is.

Interesting. What are you doing ?

Most of the game code I've seen is doing what you would expect ; either characters or tiles (in practice the same thing) sometimes overlaid with sprites which you manipulate by writing to the sprite registers, scroll registers (though I don't recall a scroller, it shouldn't be difficult). Sometimes there's no real background (e.g. SHMUPS)

I did look at other ideas, mainly thinking about how you would implement such ideas. Vera is a bit NESish in that it's very good at what it's good at, but much less good at other things. I've often wondered, how would you do Asteroids, how would you do Frogger ? Michael and I have independently written line drawers which obviously access VRAM directly, and they're about the same speed, and I don't see how you speed it up much without the Window which gives you access to the full 6502 indirection thing almost.

Frogger you'd probably have to do with line interrupts and scrolling, but it's a bit messy and won't work if you want varied vertical scrolling obviously.

I think the code is going to be similarish because the hardware is very similar. Whether you write to the Tile/Sprite Control registers directly via the window or indirectly via $9F2x really doesn't make a huge amount of difference. PETSCII robots allows it because the base level, the PET, you can do on just about any 6502 machine that has the physical space and *some* form of graphics.

Link to comment
Share on other sites

On 9/28/2021 at 12:47 AM, BruceMcF said:

The "mechanism" being the same may be possible. That depends on how much of the logic resources the X8 uses. IIRC, Frank said that Vera used about 85% of the FPGA logic resource ... and the X8 adds a 65C02 soft core and some I/O ... so it might not be feasible. That is an open question.

Maybe lose some of the sprites. There's 128 of them, I think, and Sprites are notoriously heavy on FPGA resources. 64 might do, thinking of all hell breaking loose games like say Robotron. Even then I suppose you could have an Amiga type construct where you had slow bitmap sprites and fast hardware sprites.

Link to comment
Share on other sites

On 9/28/2021 at 12:47 AM, BruceMcF said:

But if in addition to the existing window system, there was also the X16 Vera data port system in some 32bytes in the I/O control page ... I think that it in the page starting at $0600 ... then for code that fits in normal CX16 Low RAM, you wouldn't have to refactor anything ... you'd just have to change the assignment of the base of the Vera register slot, and reassemble.

That's going to be near mandatory or close to it anyway. Even if the data port is squeezable in (I'd rather the SPI !) then you have the insoluble (without different hardware) 64k VRAM limitations. Some things (e.g. 320x240x256) are just impossible. I would think an X8 version of an X16 game would probably have to use 16 colour rather than 256 colour sprites, and no PCM sound or just tiny snippets, or one shot loads, or  you could double the scaling, or just the horizontal scaling. BBC Micro games generally ran in 160 x 256 resolution and it did look a little chunky at times, but usually was fine.

Link to comment
Share on other sites

On 9/28/2021 at 10:29 AM, paulscottrobson said:

Michael and I have independently written line drawers which obviously access VRAM directly, and they're about the same speed, and I don't see how you speed it up much without the Window which gives you access to the full 6502 indirection thing almost.

Indeed, this is not a machine thats good at rendering things on the fly, but is that a bad thing? Were there any 8 bit era machines that were?

On 9/28/2021 at 10:29 AM, paulscottrobson said:

Interesting. What are you doing ?

When you think of VRAM as a stream of data it becomes very interesting, especially when your data structures are variable in size and/or larger than 256 bytes. Throw in the ability to set the step amount, and you've got the hidden power of the system.

  • Like 1
Link to comment
Share on other sites

On 9/28/2021 at 5:38 AM, paulscottrobson said:

That's going to be near mandatory or close to it anyway. Even if the data port is squeezable in (I'd rather the SPI !) then you have the insoluble (without different hardware) 64k VRAM limitations. Some things (e.g. 320x240x256) are just impossible. I would think an X8 version of an X16 game would probably have to use 16 colour rather than 256 colour sprites, and no PCM sound or just tiny snippets, or one shot loads, or  you could double the scaling, or just the horizontal scaling. BBC Micro games generally ran in 160 x 256 resolution and it did look a little chunky at times, but usually was fine.

The version of an external SPI for the FPGA that is least demanding of logical resources only requires bringing one additional registered pin out and drops the internal decoder circuit in favor of an external 3>8 decoder, giving two external spi selects plus the SD select, all overridden by the serial ROM select. It seems likely it would be fewer FPGA logic resources than the current design, so it doesn't seem like there would be an either/or.

Surely the memory constrain will limit the use of certain features ... this is part of why I am not worried that there will be a general impression that the X8 is the "superior" member of the family if the X16p and X8 are released side by side.

Link to comment
Share on other sites

Different architectures serve different purposes, result in different programs.  That's not necessarily a bad thing, since each has a slightly different ecosystem.

* PRO X16.  I LOVE the banked RAM in the X16, because it gives me an alternative to file access (it's nice to have choices), plus it gives me a huge playing field for Core Wars, which would not work well using swap files.  I also worry (needlessly?) about programs that do a LOT of file access against an SD card, because I tend to think of SD cards as having a (large) read/write limit with no warning of impending doom. 

* PRO X8. I LOVE the idea of a significantly faster processor with a friendlier VERA window.  This lets me focus on more twitch-intensive games, and also lets me toy with things like interpreters, which might run intense-r operations at reasonable speed.

 

Edited by rje
Link to comment
Share on other sites

On 9/28/2021 at 3:17 PM, BruceMcF said:

Surely the memory constrain will limit the use of certain features ... this is part of why I am not worried that there will be a general impression that the X8 is the "superior" member of the family if the X16p and X8 are released side by side.

Maybe. I'm not that sure amateurs are going to write vast amounts of code, and data could be stored on the SD card, and loaded into the banked RAM on the X16, several Spectrum games which switched 48/128 did this.

  • Like 1
Link to comment
Share on other sites

As to why it hasn't launched I imagine the world wide semiconductor shortage is not helping. If you look on Mouser, Digikey, etc. the supply of FPGAs is not what was a year ago with many of the most popular FPGAs on waitlists.

Also, the exact FPGA that Frank has been using (ICE40UP5K-SG48ITR50) as been discontinued... meaning the physical designs would have to be updated to support another version of the ICE40 HX8K FPGA.

Lead time is a serious consideration.

Edited by Lasagna
  • Like 1
Link to comment
Share on other sites

On 9/28/2021 at 4:04 PM, Lasagna said:

As to why it hasn't launched I imagine the world wide semiconductor shortage is not helping. If you look on Mouser, Digikey, etc. the supply of FPGAs is not what was a year ago with many of the most popular FPGAs on waitlists.

Not only that, but shipping shortages ... I have a container partly full of my household effects from China that is stalled waiting for an a spot on a container ship, since it's a 20 foot container and they only want to go with 40 foot high cube containers to maximum the amount of goods they can carry, and freight charges are still five times their normal rates.

Link to comment
Share on other sites

In yet other parts of the world (Bournemouth, UK), fuel is unavailable with some petrol stations closed.

Shortage of truck drivers as many are from Euro countries that left at Brexit or otherwise went home during Covid shutdown/slow downs.

In some parts of the U.S., a shortage of school bus drivers are putting pressure on contracts causing rising costs.  It’s going to be this way for a while longer.

Link to comment
Share on other sites

On 9/27/2021 at 9:13 AM, paulscottrobson said:

No, I much prefer the window. Compatibility isn't difficult - 98% of the time it is just loading stuff in to VRAM, which is part of the Kernel anyway (or should be !)...

I looked for a VRAM loader in the KERNAL, didn't find one, and then created an "issue" on Github for it. 

https://github.com/commanderx16/x16-rom/issues/222

One possibility is to extend the memory-copy routine.  Or add Yet Another KERNAL Routine (YAKR).  I also suggested a call or two for the PSG.  Less of an issue but still.

 

Link to comment
Share on other sites

On 9/28/2021 at 1:04 PM, Lasagna said:

As to why it hasn't launched I imagine the world wide semiconductor shortage is not helping. If you look on Mouser, Digikey, etc. the supply of FPGAs is not what was a year ago with many of the most popular FPGAs on waitlists.

Also, the exact FPGA that Frank has been using (ICE40UP5K-SG48ITR50) as been discontinued... meaning the physical designs would have to be updated to support another version of the ICE40 HX8K FPGA.

Lead time is a serious consideration.

TR50 refers to a specific packaging of the FPGA (50 part tape and reel). That packaging option has been discontinued. The iCE40UP5K-SG48I (which comes in the default 2,000 unit tape and reel) is still being produced and very popular. The reason for discontinuing the TR50 option is probably that they are simply making too many to cater to quantities that small. If you want less than 2,000 units, you go to Mouser or Digi-Key and they will cut a strip of them off the reel for you (for a fee, of course).

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

On 9/28/2021 at 10:48 PM, EMwhite said:

In yet other parts of the world (Bournemouth, UK), fuel is unavailable with some petrol stations closed.

Shortage of truck drivers as many are from Euro countries that left at Brexit or otherwise went home during Covid shutdown/slow downs.

About 14-16% of the shortage is down to EU nationals.

You have to have a special license to drive fuel trucks, unsurprisingly, and such are not in short supply.

Link to comment
Share on other sites

On 9/29/2021 at 12:00 AM, Wavicle said:

TR50 refers to a specific packaging of the FPGA (50 part tape and reel). That packaging option has been discontinued. The iCE40UP5K-SG48I (which comes in the default 2,000 unit tape and reel) is still being produced and very popular. The reason for discontinuing the TR50 option is probably that they are simply making too many to cater to quantities that small. If you want less than 2,000 units, you go to Mouser or Digi-Key and they will cut a strip of them off the reel for you (for a fee, of course).

Yes that is why I said the physical design, they will have to change the board to BGA or whatever option is still in production. This also affects who can assemble them easily, etc.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use