Change of product direction, good and bad news!

[AndyMt]

I thought about the whole situation for a bit more. I still think it's best to release the Phase 1 X16 first. About the next steps I'm not so sure any more...

1 hour ago, Cyber said:

Since it is all inside FPGA, is it possible to implement in X8 one more way to accces VRAM - the way it is in X16. Developer would be free to choose either use 256 byte window or 4 registers. I mean, if you already implemented 256 byte window, implementing 4 byte window along side should not be a problem. Thus way X16 programs would run on X8 without modifications.

Yes - this!

Regarding the X8: If it as the same VERA interface, then I will support it. Ok - I would have to throw away all the bespoke sound tracks for the YM 2151 I have sourced. But because of the limited RAM those would not be usable anyway, so my games then will be without any sound. Also graphics would have to be tuned down, and I personally won't make use of the double VRAM on the X16 in the future.

But I won't go into the hassle of supporting 2 different VERA interfaces. If I would, then there were different ways of addressing this, which I don't like:

• 
  Use wrapper functions: impacts performance.
  


• 
  Use conditional compilation (cc65) / macros (assembler): harder to maintain,  makes code less readable, no impact on performance
  


• 
  Maintain different/mixed code bases: even harder to maintain, but also no impact on performance.
  

Yes all of the 3 options would work and also the additional effort is maybe not that big - but it is there and would take away time from the actual fun development.

If it is possible: integrate a YM2151 in fpga. So we would be able to use existing music trackers like Deflemask etc. Otherwise it will be hard to create high quality sound tracks. All the instruments and samples need to be recreated, for the YM everything exists. 

So: please if you release the X8, then make it's VERA interface identical to the X16. And tune down the CPU speed to 8MHz. It would be so hard to explain why the little brother of the X16 is 50% faster. If possible integrate a YM2151 FPGA implementation.

[Cyber]

16 minutes ago, AndyMt said:

And tune down the CPU speed to 8MHz. It would be so hard to explain why the little brother of the X16 is 50% faster.

I think explanation is pretty simple: just because it can, so it is shame to waste this ability.

I can think about compromise: X8 runs at 8 MHz out of the box, but 12 MHz mode can be activated by user with a special command (or jumper or switch or whatever).

[James Anders Banks]

On 8/20/2021 at 8:33 AM, Kevin Kelley said:

I would look at the Commander X8 and the Commander X16 like the Vic 20 and the Commodore 64. I like the idea of both. I am not opposed to kit versions and would more likely consider one as I understand the time and cost associated with populating the board.

I agree with that ... however, if the Vic 20 and the C64 had been released at the same time, would anyone have developed for the Vic 20?

[BruceMcF]

20 minutes ago, Cyber said:

I think explanation is pretty simple: just because it can, so it is shame to waste this ability.



I can think about compromise: X8 runs at 8 MHz out of the box, but 12 MHz mode can be activated by user with a special command (or jumper or switch or whatever).

Even simpler would be because the FPGA external reference clock is 25MHz, doubled internally to the 50MHz VGA dot clock, and 12.5 is exactly 1/4th of the internal FPGA clock. If the 6502 core uses four internal cycles to simulate one 6502 clock cycle (which actually makes a lot of sense given the 6502 timing diagram), then 12.5MHz would be the exact top speed. One an internal bit set, stretch the low and high PHI2 phase by one more internal clock cycle, you get 8.33MHz, which is "pretty close" to 8MHz. Or else, one internal bit set, and the C64 circuits use an external 16MHz clock module, doubled internally to 32MHz to run one simulated cycle in exactly 8MHz. So one way or the other, the two options seem pretty plausible.

Confused consumer, "Why can the X8 go faster?" ... Second or third line of the X8 spiel, "For the X8, the RAM is inside the FPGA, so it's can run 50% faster. The external SRAM available for the CX16p kit does not allow going any faster than 8MHz".

______________

43 minutes ago, AndyMt said:

Regarding the X8: If it as the same VERA interface, then I will support it. Ok - I would have to throw away all the bespoke sound tracks for the YM 2151 I have sourced. But because of the limited RAM those would not be usable anyway, so my games then will be without any sound. Also graphics would have to be tuned down, and I personally won't make use of the double VRAM on the X16 in the future.

One of the main points of Forth is to make wrapper functions relatively cheap, so I'd just land the Vera access page at $9Exx if possible, lose one of the two terminal buffers (if there is no slot, there's a lot fewer use cases for two terminal buffers), and plow ahead. However, the High RAM library modules would be CX16-only, so any fancy video things implemented in those would be CX16-only.

 

[picosecond]

5 hours ago, BruceMcF said:

this would also give time to contact Stefanie to see if she can help @Frank van den Hoef integrate a soft YM2151 core

Why on earth would you assume Frank would need help for this?  That's borderline insulting.

Besides, I seriously doubt there is sufficient unused space in the X8 FPGA for a YM2151 core.  That makes no sense at all.

[rje]

4 hours ago, BruceMcF said:

Though it hasn't been said there is no banking, it's just been said there's only 64K system RAM (because that FPGA has only 128K RAM internally). If they wanted to do the CX16 memory map in discrete parts but skip the 512K SRAM's, they could set the banking to 3 8K banks in the 64K Low RAM. That would be even easier to do in an FPGA, just allocating the lowest two bits at the $0000 address.



If the Kernel and Basic use Bank 0, that would leave two 8K banks in the "High RAM" window for program use.

This at first sounds neat, but then I realized it would change how I code for the X16.  I would code for only two banks.

[Cullen]

If you added RAM expandability and no other external circuitry, and changed the video interface to the same one as the x16, would x16 programs not be compatible out of the box?

[Davish47]

8-bit Dave, when you are ready for those of us who wish to simply donate (no obligation), can you send a notice with link?

I want to see this dream come true!

[BruceMcF]

1 hour ago, picosecond said:

Why on earth would you assume Frank would need help for this?  That's borderline insulting.

It is so far from insulting to assume that someone who has done a process already may have useful experience to share that I don't actually think you can see the borderline of insult land from there.

 

1 hour ago, picosecond said:

Besides, I seriously doubt there is sufficient unused space in the X8 FPGA for a YM2151 core.  That makes no sense at all.

You deleted where I explicitly said "on an FPGA that can handle both". Given that she integrated four FPGA's in her original design into two, and has gone through a switch of FPGA families for better availability under current conditions, she likely also has useful experience on appropriate FPGAs families and models for precisely that kind of integration.

[BruceMcF]

53 minutes ago, rje said:

This at first sounds neat, but then I realized it would change how I code for the X16.  I would code for only two banks.

Like I said, it would kill one entire ring of my hoped for three ring HighRAM circus ... high RAM segments for the Forth dictionary, to substantially increase the effective capacity of the base Forth compiler / interpreter / application in Low RAM, Block files broken up into pieces and loaded into High RAM segments, and integrated module application and data objects in High RAM segments, with the last one not an option. As far as the first two, going from block files in 32K chunks to block files in 8K chunks is a process that can be automated, so its not a big issue. And as far as the dictionary ... when the 8K is full and it goes to grab another segment to continue, it hits the minimum block bank lower limit right away and the dictionary is full.

I wouldn't target the X8 explicitly, but then if using Block files as mass storage, a lot of what I could do in Forth could be ported, it would just be substantially faster on the CX16 than on the X8 (12MHz notwithstanding).