Commander X16

To be honest, for me the main advantage of the Commander X16 over the Mega 65 is the simplicity. It is a standard 6502 (well 65C02) with a simple memory model.

However, I think that I will actually just get a new Commodore 64 over any of these machines as it does everything I want. I would just go and buy an Ultimate-64 if I could get a new keyboard for it, but I can't. Thus, I wait and see if the Mega 65 comes out and if the price is not over the top, then I will probably get one and basically see it as a variant of the Ultimate-64.

The limitations of the C64 is actually a benefit as if I want to do something myself, as I have to work inside the constraints. It is probably just as fun and also avoids feature creep, making it more likely that I actually have time to finish something.

If I wanted something more, then I think I would just do like I did 1987 when I sold my C128D and replaced it with an Amiga. The Vampire Standalone is not that over the top in price and offers a lot more. I prefer that over the Mega 65 when it comes to the extra abilities.

 

4 minutes ago, hth313 said:

To be honest, for me the main advantage of the Commander X16 over the Mega 65 is the simplicity. It is a standard 6502 (well 65C02) with a simple memory model.



However, I think that I will actually just get a new Commodore 64 over any of these machines as it does everything I want. I would just go and buy an Ultimate-64 if I could get a new keyboard for it, but I can't. Thus, I wait and see if the Mega 65 comes out and if the price is not over the top, then I will probably get one and basically see it as a variant of the Ultimate-64.



The limitations of the C64 is actually a benefit as if I want to do something myself, as I have to work inside the constraints. It is probably just as fun and also avoids feature creep, making it more likely that I actually have time to finish something.



If I wanted something more, then I think I would just do like I did 1987 when I sold my C128D and replaced it with an Amiga. The Vampire Standalone is not that over the top in price and offers a lot more. I prefer that over the Mega 65 when it comes to the extra abilities.

 

Yeah, this is interesting to think about. It's a "what is this for". I agree with you here, I've still got years left of C64 discovery left in me and I already own several of them so I'm not sure what I'd do with this.

I WANT to think of something, don't get me wrong. I think there's room for a project like this if the community can find a "why".

37 minutes ago, mrdoornbos said:

Yeah, this is interesting to think about. It's a "what is this for". I agree with you here, I've still got years left of C64 discovery left in me and I already own several of them so I'm not sure what I'd do with this.



I WANT to think of something, don't get me wrong. I think there's room for a project like this if the community can find a "why".

I donated my 64 to a friend several years ago, and I haven't picked up The64 or similar, though I do use VICE.  So I guess I'm not as attached to it as I used to be.  The C64 has several things about it that I never liked, and some things I didn't know I didn't like until I saw the X16.

1. Only 8 sprites, unless I do the multiplexing thing which feels painful, and I never fully got the hang of.

2. The 1980s TV-friendly 40 column display.  I didn't know it at the time, but I always wanted at least 64, and preferably 80 columns.

3. Easy RAM banking.  Maybe this is easy on the C64, and maybe not -- but it sounds painful.

4. 1MHz.  I know I know, speed is addictive and never satisfies.  But still.



Rather than feeding feature creep, these preferences are more about Ease Of Use. 

 

That said, I think some of the VERA bitfields required to use its sprite engine make those lovely sprites Harder To Use, which bothers me.  I haven't played with the sound generator in VERA yet, so I don't know how it compares with the SID.  I didn't really have complaints about the SID -- especially when Compute! magazine's SuperBASIC came along and packaged many sprite and sound commands into convenience statements in a BASIC wedge.

I should add that I appreciate having the computer in a separate box. I never liked the computer in a keyboard design (having owned C64 breadbin and Amiga 500).

The thing with less memory and slower computer is that you have to work with what you have. That can give a lot of satisfaction getting it to work within constraints.

But, yes, you have good points. The 40 column display is annoying and the VERA may be interesting to have. I see myself as mostly using it for remote debugging. If I ever sit down to do things it would be using Forth and in such case I would surely appreciate having 64 or 80 columns.

I wish there was a 6551 serial port included, or least a socket for one, but I suppose it would not handle 8MHz anyway. It would be very useful for remote debugging.

I will definitely follow the Commander X16 and the alternatives to see how it goes, no decisions on my side yet. Well, I already have an Amiga that gathers dust most of the time, so I do not think I will get the Vampire in the near future at least.

 

I'm pretty late to this post, but it's very interesting to me.



To me it's all about how easy it is to get started.

 

I would not be on this website as much as I am right now, for two things.

• 
  The 8 Bit guys' cool introduction video to this project.
  


• 
  The try it now button / integrated with the uploaded software section on this website.
  


• 
  The community of people, with the forums right here.
  

 

For me getting the X16, which I definitely will do, is really cool.

But what is cooler, for now, is this website, the online emulator, and the awesome community. 

I could not stay interested long, otherwise.  Especially, if the release date is not fixed, to me the community and the emulator are more or less the X16, until the real thing comes out.

 

For the Mega65, all information, chats, download site, emulator, is more scattered, and you need to put more effort into "getting something to work".

 

And with only so much time to spend, (job, family and so on, it's not anymore when I was a student and could spend weeks and weeks on a single project),  it is simpler to go deep quicker with the X16.  For me the Mega involvement will be there, but is just lagging behind, because of the reasons above.



To me the only drawback on the X16 so far is really sound.  Mega65 has SID, X16 does not. X16 is a bit unclear on what sound we will have in the end product.

But then again, it's not a deal breaker for me.  I like the X16 as it is ?

In fact I also like the Mega65, I think both are amazing projects, by dedicated individuals.

 

I've never heard of it, but took some time to check it out.

I'd have to go back to the specifications for my personal desires:

• 
  I want a computer I can regularly use. That's the fun of it.
  


• 
  I'm fine with a 8-bit CPU. The Mega65 is using a modern FPGA to build the circuit logic of the 6502. Conceivably, it will run faster because everything is programmed into the FPGA.
  


• 
  Digital outputs. I'm not a collector of old TVs and monitors. That means HDMI, USB, and SD card slots.
  


• 
  SD card slots with programmatic support for file access.
  


• 
  Easy to program - memory and optimization can come last after building a product.
  

The Dire Problem of Nostalgia:

I've been thinking a bit about this - and I would hate to admit this, but it's in my mind when I compare the machines: The compatibility issue with the original C64 or VIC-20 is the ultimate overcommitment, because the truth is that these machines were infants in terms of design, usability, and capability. What both projects have right now is a crisis of identity versus the needs in capability of its users. We simply expect more of our computers. I think that one would either design to make an old machine OR a new machine with the old machine's parts.

In this, I'd favor the X16. I want to see the 6502. I want to see chips (Feel free to use modern RAM). I don't mind programming in some form of BASIC: The problem for me is that I know over 40 years of improvement have gone into computing, computers, and our use of computers. We've already had them in our lives, and so we expect more of them.

I'm fairly sure the Mega65 is facing the same problem, and the proof of that is its extensive documentation, modes, switching, and memory management. A glance at Mega65 BASIC and the underlaying Assembly (I am bad at assembly) would make me probably prefer Mega65 programming at the moment. I keep making comparisons to SmileBASIC in terms of ease of use. (Honestly, if everything on SmileBASIC servers weren't implicitly copyleft, I'd be making BASIC games on the Switch right now.)

The Mega65 looks like a complete computer. Ethernet port, HDMI port, SD card slots. It's only missing USB. Why does it not have a USB port? It's 2021. Everything is USB.

Disk Drives? No. I am not going out to buy floppies in the year two thousand and twenty one. Just no. If I want a retrocomputer that works worse than my phone, I'll become an antique collector.

In all, the Mega65 looks like junk, is probably extremely capable once literally everything is automatically managed or wrapped up, and will probably be a very capable computer....if it adds USB. The X16 currently is trying to reconcile backwards compatibility with modern programming convenience. I have no straight answer to this, but I just want it to succeed and be able to straightforwardly program without arcane trickery. As long as I can keep doing include and execute, the sky's the limit.

1 hour ago, Starsickle said:

In this, I'd favor the X16. I want to see the 6502. I want to see chips (Feel free to use modern RAM). I don't mind programming in some form of BASIC: The problem for me is that I know over 40 years of improvement have gone into computing, computers, and our use of computers. We've already had them in our lives, and so we expect more of them.

But it will be interesting to see how much of the ease of use is from solutions we had not arrived at before and how much is just burning cycles we didn't have available to burn before.

2 hours ago, BruceMcF said:

But it will be interesting to see how much of the ease of use is from solutions we had not arrived at before and how much is just burning cycles we didn't have available to burn before.

I’m a believer in the idea that modern coding wastes cycles, memory etc. I started professionally coding on Windows 3.0 and Word 2.0 (?). Odd thing is it didn’t seem to be much slower if at all, and Word did pretty much the same stuff. I think they’d just added the wiggly line spellchecker.

Here's my attempt to make side-by-side comparisons of the Commander X16, C256 Foenix, and Mega65:

	Commander X16	C256 Foenix	Mega65
CPU	WDC 65C02@8.192Mhz	WDC 65816 @14.28 Mhz, Choice of extra CPU Options (256 GEN-X and Above, not relevant to this comparison)	Custom FPGA Core based on the MOS Technology 4510@40 Mhz
System RAM	560K Standard (48K Low RAM, 512K High RAM), Maximum of 2 MB available by populating all RAM sockets.  Memory Map presumably can address up to 2,112K Total	Up to 64MB Standard (System can address no more than 8 MB on 65816 power alone), 2 to 4 MB on Foenix U/U+.	Current standard and maximum physical RAM To Be Decided.  CPU possesses 28-bit address bus, capable of addressing up to 256MB, Full memory map recently preliminarily published
GPU	VERA, Separately Addressed Video RAM, 128K (Memory resources shared with PSG and PCM audio subsystems)  (*)	VICKY II/III, Separately Addressed Video RAM (4MB VICKY II, 8 MB VICKY III)	VIC IV, Video RAM Space within larger System RAM can be remapped up to 16 MB, but is mapped to 384K by default in Mega65 Mode Pixel Clock at double CPU clock speed.
Resolution	320x240 (256 Colors Tile, 1024 Colors Bitmap), 320x480, 640x240 (64 Colors Tile, 256 Colors, Bitmap), 640x480 (16 Colors)	320x240, 256 Colors (65536, VICKY III) 400x300, 256 Colors (65536 VICKY III) 512x384, 256 Colors (65536, VICKY III) 640x480, 256 Colors 800x600, 256 Colors 1024x768, 236 Colors (VICKY III Only)	All resolutions from VIC-20 and Commodore 64, Plus   360x288 (1024 Colors 256 Color Sprite CLUTs) 400x300 640x400 720x576 800x600 (@)
Sprites	Maximum of 128 4-bit pixel (16 color) or 64 8-bit pixel (256 color) sprites, or mix and match in a 2-1 ratio.  Sprite size programmable up to 64x64 pixels.  Maximum of 32 sprites per scanline (16 8-bit pixel)	Maximum of 64 32x32 pixel sprites.  No Scanline Limits, bit width per pixel unknown	Maximum of 2048 4 bit-per pixel sprites at stock memory configuration in Mega65 Mode.  Sprite size programmable up to 64x32, 32x64 or 8x256 pixels, but defaults to the stock Commodore 64 12x23.  Maximum of 65,536 sprites when all memory slots are full
Fields	Maximum of Two Tile Fields, or one tile and one bitmap.  Bitmap field lacks scrolling registers and must be scrolled through CPU  power alone, but is split into quadrants each with a separate CLUT	Maximum of 4 Tile Fields and 2 Bitmap Fields	Choice of one Tile or Bitmap Field through conventional means, but judicious use of the Raster Rewrite Buffer can permit an arbitrary number of apparent scrolling fields.
Other Features		VideoDMA with Blitter Functions, Enhanced functionality and bandwidth in VICKY III	DMAgic Video DMA+ Raster Rewrite Buffer effectively produce two different extra blitter methods at the same time

 

Master Palette	4096, four bits each of RGB	16,777,216, eight bits each of RGB	8,338,608, color generation scheme unknown
Sound Chips	Yamaha YM2151+YM3012 DAC, 8 Channels FM Synthesis, 4 operators, 4 possible waveforms, 16 Channels Geometry Synthesis, 4 possible waveforms, 8 sets of two adjacent channels can be combined for more complex sounds. 1 channel 16-bit PCM synthesis, 48 KH maximum sample rate, 4K audio buffer	Yamaha YM2151+YM3012 DAC Yamaha YM2612, 6 Channels 4 operator FM Synthesis Yamaha YMF262 (Several different modes of FM Synthesis + available 5-piece percussion set), Texas Instruments SN76489 (3 Channels general Geometry synthesis, 1 channel sawtooth and white noise) X2 Gideon SID Core (6 channels total geometry synthesis, multiple filter options)+ socket space on the motherboard for two physical SID replacement chips, Red Box (CD Quality) CODEC	X4 SID Softcores (12 Sound Channels total), two based on the original Commodore 64 version, and two based on the Commodore 128/Later 64 version, four available sockets on the motherboard for physical SID replacement chips. Yamaha YMF278 (FM Sound Channels from YMF262+24 PCM Channels with 16-bit sampling@44KHz, based on the Yamaha YMW258-F/Sega Multi-PCM, Successor to the SegaPCM chip used in several Sega arcade games, used in the Yamaha SoundEdge PC Sound Card and the MSX Moonsound expansion cartridge) DMagic DMA Controller can also be used to play four channel raw digital samples.
I/O	VGA Output, A/V Multi-out, PS/2 Keyboard and Mouse, X2 7-pin Super NES controller jacks with headers for 2 more on the motherboard for an expansion backplane, Commodore-styled User Port (electrical profile based “mainly” on the Commodore 64/128 version), SD Card Slot, X4 expansion card slots, based on the Apple II Standard	Varies by form factor.  Mid-Tower and Full Tower Backplanes have: VGA Output, A/V Multi-out, Single-Link DVI Output, PS/2 Keyboard and Mouse, X4 Each Atari CX-9, 7 Pin NES, and 7 Pin Super NES controller jacks, SD Card Slot, X4-6 expansion card slots, physical, electrical, and protocol set profile currently unknown	VGA Output, A/V Multi-out, SCART out, X2 Atari CX-9 joystick Jacks with two extra headers on the motherboard for an expansion backplane. X2 USB 1.2 Ports,  Commodore User Port (Electrical Profile based on Commodore 64/128), Commodore 64 Cartridge Slot, Commodore Floppy and Datasette ports, X1 3.5” Floppy Disc (&)
Form Factor	Horizontal Upright, Separate keyboard optional.  Smaller form factor models projected in the future	Choice of Bare Motherboard, Small Form Factor(roughly Intel NUC/Mac Mini sized), Keyboard Console, Mid Tower, and Full Tower	Keyboard Console
OS	Kernal + Commodore DOS, GEOS GUI	Unknown OS for 65816.  Motorola 680X0 processor upgrades offered with choice of EmuTOS+FreeMINT or Microware OS/9. x86 processor upgrades offered with DOSBox+ReactOS, ARM upgrades offered with choice of some sort of Linux distribution or OpenRISC (%)	Kernal + Commodore DOS, GEOS GUI
Built-in Language	Microsoft BASIC 2.0+additional reserved words and syntax revisions to take advantage of the hardware	Unknown BASIC interpreter Based on Commodore BASIC 2.0	Commodore BASIC 10.0, Mega65 BASIC 11 for Mega65 Mode.

 

Also not that I did not list prices, because all price quotes are currently preliminary.

Notes: 

*: VERA's 128K of Video RAM is the FPGA's fabric cache.  Video Memory cannot be increased.

@: the VIC III 1280x200 and 1280x400 resolution modes of the Commodore 65 are not supported due to a lack of availability of Commodore 65-spec CRT monitors, and the rarity and expense of 2560x1600 5:8 aspect fixed pixel monitors.

&: Two Atari CX-9 Commodore 64 Mouse protocol/USB dongles allegedly packed in

% Full Compatibility with classic MS-DOS software stack and classic Ad-Lib and SoundBlaster support not guaranteed with x86 processor options.  Full compatibility with Atari TOS/MINT software stack with 680X0 CPU option not guaranteed.  Full Compatibility with classic Acorn Archimedes/RISC PC software stack not guaranteed with ARM CPU option.

 

I think "ease of use" is, almost literally, how much performance you can sacrifice to make things easier on the coder.

- me, just now

 

Quote

I’m a believer in the idea that modern coding wastes cycles, memory etc.

It's true.  But conversely, archaic coding wastes developers' time.  There is a fuzzy middle where the two lines cross; it's fuzzy because people represent different points near that intersection.

I will always be a "beginner" when it comes to hardware and assembly language.  My brain was never there.  I can grok it, but I could never be patient enough to live there.

 

 

*** I think those lines crossed about the time the 16 bit processor came out.  That's why the X16 has "16 bit" performance on graphics and sound.

Theoretically the 16 bit processor *could* enable better Ease of Use, because of what Paul wrote:

Quote

The [Mega65] is fast enough to [...] write proper retro style games without having to write in Assembler, and you can run a fast enough P-Code system. [...] the CX16 doesn't quite have it (by a factor of 2-3) without big chunks of assembler [...] [this] handicaps the beginners. The more the merrier though, why not Robotron in BASIC.

Given (assumption) that the Mega65 makes sprites easy and sound easy, then speed IS an Ease of Use improvement.

But I fear scope creep because it is real.

 

If moving back to the W65C816S is "all it takes", then I think about the redesign requirements and the cost estimates and see if Dave's decision is worth revisiting.

I'll start a new thread on THAT.