Commander X16

3 hours ago, ellindsey said:

I have to admit that the engineer in me is looking at the design so far and thinking that they should just throw everything possible into a FPGA. You can put a 6502 in a FPGA fairly easily, along with the RAM and much of the glue logic, and it would make redesigning the memory banking system easier. It might even be possible to implement a 65816 core which would give you a larger memory space and eliminate the need for banking, and allow for features like direct access to the VRAM through the memory bus.



Of course, that would get even further away from the actual original goals of the X16 project, and I can understand why they're not doing it. It is something that I might look into implementing myself as a side project at some point in the future.

I think the original goals I think are noteworthy and certainly, much like Ben Eater's 6502 work, it's nice to be able to see how some of this stuff interacts in a way that an FPGA would hide. We already have complicated computers sitting on our desks and floors (mine is all fancy and watercooled even awyiss!). Basically this starts down the path to the previous discussions about this which often ended up effectively defining a modern computer. David draw a nice line in the sand as it were when he based the design off the VIC-20 with as much as possible of it being on real chips. This is, in it of itself, a sort of "limitations breeds creativity" right from the start, even in the design of the computer.

Now that said, though lines can blur here, the C256 is a 65C816 baremetal hobby computer chock full of FPGAs. And it is a beautiful design it its own right for sure! It's very different from the X16 - sort of more Amiga-esque in a way. Could be worth a look though if you're really all in on the FPGAs.

A few thought on OS vs. living from a Basic command interpreter:

If a modern-ish GEOS style can be optionally banked in/enabled for those that really want that [not me], than both camps will be satisfied (one that wants a contiguous memory map without banking business and one that is willing to manage RAM and forfeit some always in ROM code/OS).  

I'm nowhere near well-read/informed when it comes to how MMU type functions will manage the banking of the memory north of the 64K boundary;  Maybe the team here has already worked that out or maybe it's roll your own e.g. plug a number into a single memory location to determine which bank of 8 or 16k overlay a portion of the contiguous 'main' memory.

• 
  But as a recent Apple II convert, I'm struck by the difference of environments, capabilities, product ecosystem, longevity, and market value of Apple products.
  


• 
  Built in monitor that Commodore for some reason dropped after the PET is awesome
  


• 
  Zero disk capabilities without booting into "DOS" is nuts.  Makes you really respect the afterthought of a command channel to IEC serial devices
  


• 
  Applesoft Basic with plenty of extensions for graphics and what not, mixed mode screens, etc. but nothing other than sluggish bit mapped graphics with PET style 'sound' and fake color = madness
  


• 
  But on the other hand, I bought an Apple II+ with a language card, drive, Disk ][ drive, Epson printer interface for less than I can buy a C64 with a broken keyboard.  Since picked up an 80 col card and a SuperSerial adapter.
  

My Commodore 128 (mounted to the wall in my STEM Lab as me and our 11 yr old call it) had sprite editor and a bunch of other tricks that I never even bothered to use.

So in short, do include the xtra niceties of some extended Basic commands and disk utilities, a ML monitor and an image, char set, and tile editor if that could be omnipresent and allow a rom banking (probably too late) for fancIER GEOS.

Would love to see the MVP, EPICs, and jump in on your Sprint planning PBR and demo sessions; because scope creep coming from guys like me must be fun, considering  : )

Everything else is awesome.  Looks like the machine is ticking all the boxes ... but please hurry : )

22 hours ago, kktos said:

Hum... ok, I got what your saying. And yes, I do agree.

I'm merely thinking about Disk Operating System rather that a complete OS.... I'm a apple // fan and as far as I can remember, I always used the computer with a dos. seems to be the minimum

GEOS, on the other hand, is a tad too much :):) That's the C64 trying to mimic the Mac with UI and more..... Wrong target.

If there is a setting for whether to run an autostart program in the persistent memory of the clock chip, then having the autostart program run your disk operating system of preference would seem to be an option.

18 hours ago, ellindsey said:

I have to admit that the engineer in me is looking at the design so far and thinking that they should just throw everything possible into a FPGA.

They are going to do that, aren't they? It's just going to be implementing the features in the kit build able reference design.

As far as "allowing" them to change the memory map, there's no gain in that if they don't WANT a more intricate memory map, and from the discussion at the time the new memory map was decided on, they are implementing what they want, as opposed to being forced to accept what they can get.

Regarding sound.  I know many people want and know how to use the YM synth -- 8BG included -- but even without it, the PSG + PCM fits the "sound of some kind" requirement.

 

Meanwhile, I understand Paul's points:

Quote

The [...] 65C02 [is] too old, too limited and too slow. You can solve the problems either by having a wide address space or speeding it up  [...]

If [VERA] was on the bus directly addressable [...]

The operating system is [...] still Microsoft BASIC with GOTO GOSUB 2 letter variables etc. in something which is supposed to encourage programming. Precompilers lose the immediacy. [...]

[It loses on] Affordability. 

 

I would like Paul to start a new thread with his Dream Computer.  For the moment, though, we have enough information to make some starting assumptions.

His balance favors the programmer, with a flat memory, memory-mapped I/O model. 

1. The W65C816S fits the Apple IIgs world, still solidly in 1986.  $1 more than the 65C02.

2. You get speed (efficiency) and memory addressing space.   Same memory costs.

3. VERA can sit right on the memory bus.  Same VERA costs.

I suppose VERA and the CPU would have to split the clock for memory access.  Assuming VERA can run fast enough, then that's probably not a problem.  (I suppose things would run at about 7Mhz?)

4. An upgraded "immediate mode" programming environment.  The Structured BASIC that's being built for the X16 would probably be the solution.   Development time with QA.

5. Scrapping the current prototypes and starting over would be daunting.

 

I admit that the 16 bit CPU has all sorts of elbow room.  I can see the appeal.  It would solve some of MY programming problems.

 

 

 

 

4 hours ago, rje said:

Regarding sound.  I know many people want and know how to use the YM synth -- 8BG included -- but even without it, the PSG + PCM fits the "sound of some kind" requirement.



 



Meanwhile, I understand Paul's points:



 



I would like Paul to start a new thread with his Dream Computer.  For the moment, though, we have enough information to make some starting assumptions.



His balance favors the programmer, with a flat memory, memory-mapped I/O model. 



1. The W65C816S fits the Apple IIgs world, still solidly in 1986.  $1 more than the 65C02.



2. You get speed (efficiency) and memory addressing space.   Same memory costs.



3. VERA can sit right on the memory bus.  Same VERA costs.



I suppose VERA and the CPU would have to split the clock for memory access.  Assuming VERA can run fast enough, then that's probably not a problem.  (I suppose things would run at about 7Mhz?)



4. An upgraded "immediate mode" programming environment.  The Structured BASIC that's being built for the X16 would probably be the solution.   Development time with QA.



5. Scrapping the current prototypes and starting over would be daunting.



 



I admit that the 16 bit CPU has all sorts of elbow room.  I can see the appeal.  It would solve some of MY programming problems.

What you're describing are some of the things available in the C256, though in other parts it is very different (lots of SMD parts for instance). I find the 65C816 actually more daunting though having seen some of that code. Maybe not by a lot but I like that my first real adventure in to assembly is on a simple 8-bit platform. Yes having flat memory (and allowing for a much phat'er pipe to video) is nice but there's the need to contend with modes and certainly from the hardware side, the dual-nature of the pins is a lot more complicated to explain.

I can show my kiddo the X16 and, for the most part, things aren't much more complicated than Ben Eater's breadboard computer and I don't think the 816 fits that.

The banked memory is perhaps a small complication but I really like it. It actually made it really easy to implement my tracker stuff since i just use the banks (which is wildly wasteful, I'll admit). In my case, the pattern #'s are the bank #'s. It couldn't be easier (though loading and storing those patterns to/from song files is something I still need to do and that may indeed be less trivial). So I think some things could be easier with banks. Game assets could be nicely organized into pages for instance and in this way I find it easier to work with than having to track flat locations in memory.

So to me I think the X16 is still very much an approachable platform and I'm actually rather glad it's 8-bit by design. It does offer up a lot of learning opportunities that might get masked behind 16-bit addressing.

That's not taking away anything from either the X16 or C256. C256 is one crazy powerhouse (and is available today). Though I'm glad I'm not writing a tracker for the C256 - it has so many sound chips I'm not sure how to even begin to organize all that into a nice tracker UI ?

5 hours ago, rje said:

His balance favors the programmer, with a flat memory, memory-mapped I/O model. 



1. The W65C816S fits the Apple IIgs world, still solidly in 1986.  $1 more than the 65C02.



2. You get speed (efficiency) and memory addressing space.   Same memory costs.



3. VERA can sit right on the memory bus.  Same VERA costs.



I suppose VERA and the CPU would have to split the clock for memory access.  Assuming VERA can run fast enough, then that's probably not a problem.  (I suppose things would run at about 7Mhz?)



4. An upgraded "immediate mode" programming environment.  The Structured BASIC that's being built for the X16 would probably be the solution.   Development time with QA.



5. Scrapping the current prototypes and starting over would be daunting.



I admit that the 16 bit CPU has all sorts of elbow room.  I can see the appeal.  It would solve some of MY programming problems.

Well. I'd go for one of two models. Either what you have here, or a 6502 with a much faster 65C02, like Mega65 speed, which is 48Mhz I think. But the 65816 on a bus is simpler. But it's not going to happen.

Rewriting the BASIC is in some ways easier than patching the current one. There was an absolutely horrible bug in there, connected with a bodge to make the DATA statement work (by Microsoft, not Michael Steil) that stopped VPOKE or VPEEK working. The more changes are made the more risks there are of this sort of thing. Doing things that should be done - long variable names, long procedure names, locals, parameters, structures, is almost impossible.

The structured BASIC is, as I understand, a transpiler. I wrote one professionally about 35 years ago that did much the same thing, quite well, it had a miniature FORTH in it and could generate quite complex code. But it's asking quite a lot of an 8Mhz 65C02 to do this (offline it's relatively trivial) and you lose the immediacy of programming.

I did my own a year or two back https://projecteris.blogspot.com which is a bit slow (it had to all work on an ESP32) but is probably in practice maybe 40% quicker than the X16. Though it is not a real CPU, probably closest to the IMP16/CP1600 style.

5 hours ago, rje said:

I admit that the 16 bit CPU has all sorts of elbow room.  I can see the appeal.  It would solve some of MY programming problems.

Although the 16-bit nature of the 65816 does make some things much more convenient, especially for programming using a high level language (hello decent stack size!), I think the 24-bit address space is almost if not more useful.  The CX16 looks like it will be a great platform for retro games, learning programming, and doing low-level hardware stuff. I'm having fun messing around with it in the emulator.

However, a 24 bit address space and floating point capability would actually let me do (in C, perhaps) much of what I'm messing around with in C# on my home computer.  I could have accomplished it with a little pain with a mid-80's PC or Mac, or maybe a IIgs, though with some workarounds.  I'm starting to understand why the concept of a so-called 3M computer was such the rage in the early 80's.

OTOH, C and the original UNIX were developed on a PDP-11, a 16-bit machine with 64 KB.

1 hour ago, m00dawg said:

Maybe not by a lot but I like that my first real adventure in to assembly is on a simple 8-bit platform. Yes having flat memory (and allowing for a much phat'er pipe to video) is nice but there's the need to contend with modes and certainly from the hardware side, the dual-nature of the pins is a lot more complicated to explain.



I can show my kiddo the X16 and, for the most part, things aren't much more complicated than Ben Eater's breadboard computer and I don't think the 816 fits that.



The banked memory is perhaps a small complication but I really like it. It actually made it really easy to implement my tracker stuff since i just use the banks (which is wildly wasteful, I'll admit). In my case, the pattern #'s are the bank #'s. It couldn't be easier (though loading and storing those patterns to/from song files is something I still need to do and that may indeed be less trivial).

The C256 is very heavily engineered. It's a nice design but it's over complicated IMO. This sort of design you want flexibility and comprehensibility.

The trick with the 65816 is to dump most of the complexity. No compatibility mode, no weird programming modes, pretty much permanently in 16 bit mode unless you are doing 8 bit I/O or character level manipulation. Dump the weird things like MVP and MVN that are messy. Pretty much treat it like a 16 bit 6502, with 16 bit registers always with a 24 bit memory space - you add on the 24 bit address modes and .... that's it. It's easier because you don't endlessly write 6 or 7 instructions to do 1 or 2 16 bit operations.  I think they tried to make it all things to all men, hence the stack relative modes.

Banking works if it is fast enough (and you have a system for allocating them, loading into them and so on, designating some for code, some for data, some for graphics).

Though to be honest even an 8Mhz 65816 isn't that quick.

The question is not what should it be, but what do you want to do with it ? Is it for your children to learn for example - a great idea, but why then stick with the truly horrible Microsoft BASIC ?

I'm looking at it as sort of an entryway to understanding computing at more fundamental levels (but with the ability to do something useful with it). In college I had to learn to program assembly using a fake CPU that didn't exist (LC2) and I hated it because I had no reason to write any code to do something more than college assignments. 6502 seems like a great introduction to that level, and it's easy-ish to go down one step lower and really see how things actually work at the electrical level. That's really obfuscated on modern machines.

The kiddo is perhaps too young for assembly, and not sure he'd be all that interested in it when he gets older, but as a tool for folks interested in computing in general, having some idea of the fundamentals, I think, it's incredibly important.



That's for the learning aspect of it, but there's also a lot of other things I like about the X16. And C256 too though I don't think I'm quite ready for that platform yet - and I agree it is quite decadent like biting into super rich chocolate you weren't prepared for haha. Whole different set of problems to solve on that system (like how to manage all those FM channels for composing music in a tracker or some other in-system music program). In some ways C256 sort of sits a bit in the uncanny valley of having so much stuff that it kinda has 'the problem of choice' like modern PCs too (as in I find having too many choices, with respect to creating music, can sometimes be overwhelming and kill my creativity).