Commander X16

Quote

 



Many people have been wondering about the X16 and what it’s status is.  So, I wanted to give an update on what problems we have left, and how we’ve decided to solve them.  Here are the problems in a nutshell, and then I’ll elaborate on each one.



1) Chip shortage

2) Keyboard not working

3) filesystem not working

4) Michael and Frank have gone MIA.



As far as the chip shortage goes, it’s a short term problem (I hope) but it does mean no mass production until at least 4th quarter 2022.



As for the keyboard.  Originally we were bit-banging the PS/2 keyboard from one of the 6522 chips.  This presented problems and Michael Steil was not able to get it working reliably, so we tried moving that function over to the little micro-controller that was in charge of the power/reset systems.  We figured we’d talk to the micro-controller via I2C.  Frank was going to get this working for us, but he was having trouble with it, and there hasn’t been any word from him in months.



So, we had a meeting today between me, Kevin, and Adrian Black and brainstormed ideas.  We decided to replace the micro-controller with a larger one that has enough legs to integrate onto the main memory bus.  This way it can appear as 1 or 2 memory address registers.  It can read the PS/2 key up/down signals and place them in a buffer to be read in as bytes from that address.  This should make integration into the kernel much simpler. In reality, this is how the original IBM PC worked, so there’s nothing inappropriate about doing this.



Kevin and I talked about possibly building a small cartridge for the C64 that has the microcontroller and a PS-2 port.  This way kevin could test the microcontroller code and I could write some preliminary 6502 code to prove it all works. Then hopefully somebody could integrate that into the X16 kernel. It’s really hard to test stuff on the X16 when you have to burn a ROM chip every time you want to make a change. That will be solved once we have a working keyboard and file system.



The file system is currently a FAT filesystem being run by the 6502. The Vera is in charge of reading/writing to the SD card.  It’s unstable and only partially works.  I’m not qualified to work on this code and fix it.  So I think we’re going to go back to the original idea Kevin and I had years ago, which is just get the IEC port working so we can use an SD-2-IEC or any standard Commodore drive.  At some point we can integrate the SD-2-IEC onto the mainboard as drive 8. Maybe some day we can resurrect the current system if somebody wants to troubleshoot it.  But in order to do that, they need a working board and there just aren’t enough to go around right now.  As long as all software uses kernel-calls to read/write to the disk drive, no software compatibility should be affected.



About Michael and Frank.  I’m not trying to badmouth them.  So please don’t take it that way.  They designed the heart of this system.  But they also allowed a certain amount of feature creep in.  And I was okay with that since they were handling it. But, unfortunately, updating the kernel or the FPGA is beyond my capability. And since both of them have taken a hiatus from this project, it leaves us in limbo. The computer is like 95% finished, but we can’t ship it in this state.  It needs to be working reliably.  Thus, these simplifications of the filesystem and keyboard implementation are necessary to get this project back on track.



I’m open to other ideas.  And we’re open to anyone else that wants to help with the project. Mainly we need somebody to help write some IEC code for the kernal.  We really don’t want to let this project die considering how far along it is in development.

On 3/16/2022 at 5:48 AM, Scott Robison said:

We decided to replace the micro-controller with a larger one that has enough legs to integrate onto the main memory bus.  This way it can appear as 1 or 2 memory address registers.  It can read the PS/2 key up/down signals and place them in a buffer to be read in as bytes from that address.  This should make integration into the kernel much simpler. In reality, this is how the original IBM PC worked, so there’s nothing inappropriate about doing this.

On 3/16/2022 at 5:48 AM, Scott Robison said:

So I think we’re going to go back to the original idea Kevin and I had years ago, which is just get the IEC port working so we can use an SD-2-IEC or any standard Commodore drive.

On 3/16/2022 at 4:10 AM, AndyMt said:

That's kind of a bummer, but I understand it. It means we need another device to connect to the board - and it will be a lot slower I assume?

On 3/16/2022 at 5:10 AM, AndyMt said:

That's kind of a bummer, but I understand it. It means we need another device to connect to the board - and it will be a lot slower I assume?

On 3/16/2022 at 7:23 AM, rje said:

Note that since the X16 is not a C64, it doesn't have many of the performance bottlenecks of the C64.  



It has to be able to talk to an IEC device, yes, but it can send a fastloader to said device.  Binaries are not C64 binaries and so a fastloader won't have the software compatibility problems that C64 fastloaders had.  

• 
  Set data line
  


• 
  Set the clock line
  


• 
  Read the data line 
  


• 
  Clear the clock line
  


• 
  Shift the bit into the byte being read
  

1. 
   Our CPU is 8x faster
   


2. 
   We can theoretically take advantage of hardware bit shifting (since we have fully working VIAs)
   


3. 
   We have lots of prior work we can sample from, including JiffyDOS, Epyx Fast Load, and others.
   

On 3/16/2022 at 3:47 PM, Fabio said:

the commander X16 is not affected by "bad" scanlines of memory.  so we can use the 20 microsecond timing

On 3/16/2022 at 3:07 PM, Scott Robison said:

And really, it could use faster timing if the device was compatible. By which I mean that 20 us is the standard, but other devices could negotiate/ agree to play faster ala JiffyDOS.