Latest update video and what this means

May 22, 2019
662
313
63
Here's the video on Facebook. (I have requested that he repost it on YT so we can link it here.)


To summarize....

The prototype hardware is nearly complete, and David is optimistic about the hardware's progress.

The software has had a major setback. David has been seeking a license from Cloanto to use the Commodore KERNAL in the CX16, and he was finally told that Retro Games has an exclusive license to use the Commodore 64 KERNAL in the TheC64 products. They have been unable to reach a license deal with Cloanto, who is simply refusing to communicate at this point.

As a result, the Commander's Github sites have all been taken down, and they have stopped distributing any software related to the project until they can remove the Commodore KERNAL code. Their plan is to rebuild the kernel using open source code.

The BASIC code is a different situation. David believes that Microsoft granted BASIC to the public back in the 90s, but he does not yet have definitive proof. (While he hasn't said as much, it's possible that he may not be able to use Microsoft BASIC either. Legally, he certainly can't without an explicit license grant.)

This leaves the team in a place where they have hardware, but no software.

More information as it comes.

**Update**
Peri Fractic of Retro Recipes has apparently contacted Cloanto and negotiated an initial agreement. No more information is forthcoming at this time.

Announcement! Thank you to Peri Fractic, who managed to get us a preliminary agreement with Cloanto at the last minute. As such, we will resume development with the existing Kernal, which was always my first choice in this project. Sorry for all of the drama, as apparently we are back on the original course. We'll get the emulator and GitHub opened back up.
 
Last edited:
May 22, 2019
662
313
63
Update:

As expected, David got a ton of replies in his video thread (over 400, so far.)

At this point, he is expecting to create a new kernel from scratch. Also, the creators of the Mega 65 have offered to let him use their open kernel code, seen here:


While the open kernel is not complete, and it's not fully compatible with the Commodore 64 - that's not a problem, here. It would have to be customized for the CX16, in any event, and no one is really expecting full C64 compatibility - just that it generally supports the standard KERNAL APIs.
 

picosecond

New Member
Sep 27, 2019
15
7
3
Northeast U.S.
This is a long overdue course correction and I am glad to see it. The most surprising thing is that anyone on the dev team would advocate for staying on the previous path. I never understood the case for licensing and did not find David Murray's explanations for it at all persuasive. The MEGA65 folks proposed cooperation on the kernel months ago. The CX16 team should have taken them up on it. Licensing ancient code for a new design that is intentionally not C64 compatible never made a bit of sense.

The hardware needs a course correction too. The very first principle laid out in the first "Dream Computer" video was to use only modern, off-the-shelf parts. No new old stock or sourcing parts from vintage computers. Further down the list is the preference to avoid FPGAs or microcontrollers. The FPGA non-preference is clearly negotiable; see the graphics implementation.

Given these sensible constraints how did the dev team decide to go with gray market sound chips? This adds effort and expense to screen out broken or mislabeled parts. No amount of testing is likely to fully reveal damage these parts may have suffered from mishandling. A stated reason for building CX16 was to have a new machine that would not suffer the reliability problems that plague vintage computers. Why would anyone design old, maybe-unreliable silicon into such a machine? It is the exact opposite of the fundamental design objectives.

The best answer for the sound has always been the same as the best answer for graphics. FPGA. FPGA is cheaper, smaller, easier to manufacture and would have been easier to design. Phase 3 needs it anyway. Finally, a new sound design would be so much more interesting. Graphics and sound design choices are what gave most of the vintage systems their unique personalities. There are some nice things about the feature set for sound but the implementation is not good.
 

ubik

New Member
Jan 2, 2020
4
6
3
Oh well, having worked for small and big software companies (and having been forced to work around all kinds of licensing b******t numerous times), I was almost sure something like this would happen. :(

Never use proprietary software when you can use open source instead... especially not for projects close to your heart (btw, exactly the same applies for using Facebook vs. using free and open blogging software for creating a community...)

I for one would very much welcome corporation between the Mega65 Kernel and cx16 folks. And if that means, we get a cx16 and a Mega65 target for the cc65, all the better!
 
Last edited:

Jestin

New Member
Jan 25, 2020
16
13
3
Other than the amount of work that now has to go into building a new kernal, I'm really looking forward to this change. I've been interested in this project not for any sort of nostalgia or compatibility reasons, but for educational reasons. I'm excited that I'll get a chance to watch the kernal development from day one, rather than a port of an existing kernal. I'm just hoping that I'll be able to learn fast enough that I might be able to contribute!
 

BruceMcF

Active Member
May 19, 2019
208
63
28
The hardware needs a course correction too. The very first principle laid out in the first "Dream Computer" video was to use only modern, off-the-shelf parts. No new old stock or sourcing parts from vintage computers. Further down the list is the preference to avoid FPGAs or microcontrollers. The FPGA non-preference is clearly negotiable; see the graphics implementation.

Given these sensible constraints how did the dev team decide to go with gray market sound chips?
Quite clearly by having different preferences than you have. You can say "further down the list" as if the list was carefully laid out in order of priority, but choices reveal actual preferences, and given an inability to meet both, they had to decide where their preferences lay. There wasn't a choice for the video chip ... not only was there no in-production chip that did what they wanted, there was also no chip available in quantity in the grey market chip that did what they wanted. So the "negotiability" of the no-FPGA preference for the system reference design seems to be exactly if there was absolutely no alternative.

If you hold out for a "stage 3" design, and assuming the project plows all the way through to that implementation of the functioning of the system reference design, you'll get what you want regarding sound chips in FPGA.

As far as getting what you want as far as gambling on how a novel design of sound chip(s) are going to sound, it would seem that is not on the table. It would seem that designing a novel video chip is quite enough of a high wire act without a net for their liking, and for the sound they prefer to go with the safety net of having established designs where they can hear how the designs sound.
 
Last edited:

rje

Member
Nov 6, 2019
40
13
8
While I have my preferences, I feel that the team has done a great job with follow-through. Dave set his expectations, and members of the team offer paths as they come up, but Dave's vision is the standard. This is how a team gets things done -- and no plan ever survives first contact with impediments and blockers.

Rather than gloom over a "one month" prediction, I see opportunity:

(1) The MEGA65 project has already got an open source Kernal; consider that time invested in the CX16; even if it's not eventually used, it's a path to try.

(2) Assume the CX16 project uses the MEGA65 open roms; this means CX16 can also advance MEGA65's timeline, and thus contribute indirectly to a related project. There is a potential synergy here.

(3) Apparently the Kernal is not that big of an effort anyhow, beyond the effort of making sure it is a creative product rather than a copy (again, MEGA65 has a good treatise on how to make sure of this).

As Tom has mentioned to me, it would be more difficult to create a MS-BASIC-like interpreter (uh, in 9K of assembly, that is... more on this later).

Video and sound chips notwithstanding, CX16 is doing remarkably well as an open source project to date, and has proved resilent and able to cope with change. In fact that makes the overall story INTERESTING.
 

BruceMcF

Active Member
May 19, 2019
208
63
28
While I have my preferences, I feel that the team has done a great job with follow-through. Dave set his expectations, and members of the team offer paths as they come up, but Dave's vision is the standard. This is how a team gets things done -- and no plan ever survives first contact with impediments and blockers.

Rather than gloom over a "one month" prediction, I see opportunity:

(1) The MEGA65 project has already got an open source Kernal; consider that time invested in the CX16; even if it's not eventually used, it's a path to try.

(2) Assume the CX16 project uses the MEGA65 open roms; this means CX16 can also advance MEGA65's timeline, and thus contribute indirectly to a related project. There is a potential synergy here.

(3) Apparently the Kernal is not that big of an effort anyhow, beyond the effort of making sure it is a creative product rather than a copy (again, MEGA65 has a good treatise on how to make sure of this).

As Tom has mentioned to me, it would be more difficult to create a MS-BASIC-like interpreter (uh, in 9K of assembly, that is... more on this later).

Video and sound chips notwithstanding, CX16 is doing remarkably well as an open source project to date, and has proved resilent and able to cope with change. In fact that makes the overall story INTERESTING.
I don't know how many KB this one is. https://github.com/paulscottrobson/basic-65 (I think on FB I may have got it confused with the other, integer Basic: https://github.com/paulscottrobson/Basic65 ... even if how "Basic65" and "basic-65" could be confused be anyone escapes me ... put it down to a slightly premature Senior moment).
 

rje

Member
Nov 6, 2019
40
13
8
I don't know how many KB this one is. https://github.com/paulscottrobson/basic-65 (I think on FB I may have got it confused with the other, integer Basic: https://github.com/paulscottrobson/Basic65 ... even if how "Basic65" and "basic-65" could be confused be anyone escapes me ... put it down to a slightly premature Senior moment).
His mega-basic (https://github.com/paulscottrobson/mega-basic) fits into 16K, and is augmented. Since his basic-65 is "close to MS" in compatibility, I'd say it's closer to the 9K of CBM's MSBASIC.

Sounds like he's an interpreters-in-assembly fool, with code for RPL, Forth, and his own Lean, as well as those BASICs he's got lying around. Sounds like an interesting guy to talk with.
 
Last edited:

picosecond

New Member
Sep 27, 2019
15
7
3
Northeast U.S.
Quite clearly by having different preferences than you have.
Clearly. I prefer to design reliable hardware.

Let's talk about the CPU. The team want a discrete CPU. It doesn't interest me at all. I got that out of my system three decades ago. But you will never see me complain about this choice because it is not bad engineering. There is nothing whatsoever wrong with building CX16 from new WDC 65C02 chips. It's just not my cup of tea.

Using sketchy sound chips is bad engineering. Maybe they will get lucky and things will work out fine. The world is full of bad designs that went to production and worked out OK. Maybe they won't get lucky and CX16 production turns into a disaster. Happily it's not my money and reputation on the line.

Speaking of bad engineering, I saw in today's FB comments that they just hooked the expansion bus directly to the CPU, no buffering. Oh man...
 

BruceMcF

Active Member
May 19, 2019
208
63
28
Using sketchy sound chips is bad engineering. Maybe they will get lucky and things will work out fine.
If they are socketed in the "Stage 1" system reference design, it seems turning the use of recycled chips into a big issue is making a mountain out of a molehill.

In the Stage 2 board, they will have to decide, since that is not going to be a kit-buildable board. If the chips are not available in modern surface mount packaging, they might have to go with an FPGA for that just for the board footprint ... IOW, swap out the CPLD to replace all of that glue logic with an FPGA that does that and implements the sound chip cores as well.

But If both sound chips have working cores available, that doesn't seem like it's a big issue either. I'd rather have the real sound chips, but I'm not going to turn up my nose at buying the Stage 2 board if it has the chips as cores on an FPGA instead.

Speaking of bad engineering, I saw in today's FB comments that they just hooked the expansion bus directly to the CPU, no buffering. Oh man...
I don't even see a reveal of the new boards on FB ... in the latest video update, they were described as being available "soon".

If you are talking about the first version of the board, that would just be inventing things to complain about. Leaving the prototype board with the option to experiment with different expansion port bus buffering set-ups before you've settled on your expansion port design is the opposite of bad engineering ... it's smart engineering.
 
Last edited:

FeralChild

New Member
Feb 7, 2020
1
3
3
github.com
(1) The MEGA65 project has already got an open source Kernal; consider that time invested in the CX16; even if it's not eventually used, it's a path to try.
If anyone wants to try this path, follow these steps:

1. Clone the Open ROMs from here - official repository does not have some important changes yet
2. Replace the stubs with X16 hardware drivers, use the aliases
3. Adapt the makefile - I don't know what is the rom.bin file layout, so the rule to compose $(TARGET_X16_x) is rather dummy
4. Do make test_cx16 to compile the ROM and launch it in the emulator
 

picosecond

New Member
Sep 27, 2019
15
7
3
Northeast U.S.
they ought to buffer the data bus and address lines a0-a4
It's best practice to buffer everything consumed by an expansion card. Each added card will change the timing at least a little. You don't want to find out that a full load of expansion cards breaks your SRAM accesses. Whether any of this matters or not depends on how much timing margin you have.

A well-designed expansion card will always limit the load it puts on the bus. Even if you are buffered from the CPU you still share wires with other expansions. Be a good neighbor.

If they intend to support bus mastering expansion cards I can see an argument for having a single unbuffered slot for bus masters. it doesn't look like they have any bus arbitration so more than one bus master won't work well anyway.
 

PowerfulBadBoy

New Member
Jul 17, 2019
27
13
3
Honestly, I didn't want to be a bell-end in the other thread but holy moly am I pleased that this legal nightmare has finally been cleared up.
I fully understand that plenty of people poured blood sweat and tears into the original unlicensed kernal but having a proper open source one just makes everything soooo much easier to muck about with in the future when licencing deals inevitably expire. Plus you can edit it all yourself and that's COOL!
 
  • Like
Reactions: picosecond

BruceMcF

Active Member
May 19, 2019
208
63
28
It's best practice to buffer everything consumed by an expansion card. Each added card will change the timing at least a little. You don't want to find out that a full load of expansion cards breaks your SRAM accesses. Whether any of this matters or not depends on how much timing margin you have.
The issue Lorin raised is that different hardware may have different buffering requirements, so if you buffer for CMOS +5v, you may well have double buffering with the attendent lag if you have a +3v chip. The argument would be that each expansion card would know best what buffering is appropriate.

You want to argue with Lorin about that, you already have the link, go for it.

A well-designed expansion card will always limit the load it puts on the bus. Even if you are buffered from the CPU you still share wires with other expansions. Be a good neighbor.
Yes, if cards that meet their initial spec turn out to interfere with the operation of the board, they'll definitely have to revise the spec.

If they intend to support bus mastering expansion cards ...
Support or permit? It seems clear that they added the expansion ports in response to popular demand for the ports. If they bring out the RDY and all the address lines, that would permit a bus mastering card. As far as supporting it, it seems like, no, you want to do that, it's DIY. If you want to have two cooperating bus mastering cards, bus arbitration would also be DIY.
 

BruceMcF

Active Member
May 19, 2019
208
63
28
Back to plan A, the FB group says they now have a preliminary agreement with Cloanto, reportedly thanks to Perifractic.

Doesn't sound like they are going to explain what happened exactly, I wouldn't be shocked if Perifractic succeeded in getting in contact with the people doing the C64 and got them on board with supporting the CX16 getting the license, and Cloanto took their phone calls when they were not taking the CX16 groups's phone calls, because that's an existing income stream talking.

But still a good idea to keep on working on an open source kernel, given that the flash rom is supposed to be flashable if you set a jumper the right way.
 
  • Like
Reactions: vii