Ides of March Status of X16

[Scott Robison]

The following is a copy of information posted by David to the Facebook group, copied here for your convenience.

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.

 

[Jestin]

I for one appreciate the open communication and honesty in this update.  It's disappointing to hear the about the problems, but I'm very thankful that there are backup plans being worked on.  I wish I had the expertise to lend a hand, but I can clearly see that all the easily solvable problems have already been addressed, and all that remains are the parts beyond my own capabilities.  This update was literally published while I was in the middle of developing my own X16 game, so I obviously want to see the project become a success.  Great work so far!

[AndyMt]

Thanks a lot for the update, this is much appreciated. It would be a pity if this project would just stall forever, so I'm hopeful it will continue.

As for the workarounds presented:

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.

I think that's absolutely fine. It takes lot of load off the CPU while kind of fit for the time period. Will this handle the mouse as well?

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.

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?

Will the SD card interface stay on the VERA board or will it be dropped entirely? Because I might take a look at the FAT implementation. I've implemented FAT like file access on embedded systems about 20 years ago. Although I assume the issues here are more bus timing related, rather than managing the FAT etc.? If the SD-2-IEC solution is not a lot slower then it's probably not worth pursuing the VERA SD interface at all.

[rje]

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?

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.  

Unless I am mistaken of course.

Here's one place to start talking about that.  

 

 

 

[SolidState]

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?

Frank posted a demo on Facebook a couple of years ago. It was streaming 320x240 video from the SD card at 4 bits per pixel. He estimated about 300kB/s reading full sectors, with normal accesses around 200kB/s read, 64kB/s write. I'm not too familiar with the IEC Bus, but Wikipedia quotes a speed of 400 B/s for the Commodore 64 with a theoretical top speed of 6.25 kB/s. So best case scenario is about an order or magnitude slower.

[TomXP411]

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.  

So just to expand on this a little:

The basic IEC protocol requires something like 4 discrete steps per bit to transfer data. It's actually very much like SPI, in fact. The process goes something like this:

• 
  Set data line
  


• 
  Set the clock line
  


• 
  Read the data line 
  


• 
  Clear the clock line
  


• 
  Shift the bit into the byte being read
  

We've done the math on this in other threads, and even our back-of-the-envelope code is 2x faster than Commodore's, but that's because we're likely missing something  and not accounting for mass market tolerance stacking. 

Anyway, we have two benefits today:

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.
   

Most of these fast loaders work by optimizing the bit shifting process and by "bursting" the data: sending multiple bits without waiting for clock lines. That alone can speed up transfers 4x or more.

So if we start with JiffyDOS, which can manage 9Kbytes/sec, then accelerate that by 8x, we could theoretically hit 72KB/s. This is more than fast enough to fill main memory in less than one second, and we could fill banked memory in 8 seconds. 

 

 

[Fabio]

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

[Scott Robison]

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

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.

 

[BlahDehBlah]

Feature creep is a shame

I still hope that it doesn't obscure the goal of a simple architecture, the allure of knowing how the computer works inside and out was what caught my interest in the first place. The concept of a "dumb" device (as opposed to the smartphones or smart TVs or smart fridges) has a lot of appeal. Something that, on its own, does as little as possible. If you want it to do something cool, you've got to make it do something cool.

[TomXP411]

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.



 

David mentioned Burst mode on Facebook. It doesn't require new ROMs in CBM drives, and since we're talking about a custom SD2IEC anyway (I'm partial to using a Pi Pico, right now), then it's probably easier to add a burst mode setting to SD2IEC than to re-create JiffyDOS. Not only does this prevent any JD Copyright issues, but burst mode could be back-ported to the official SD2IEC source and benefit Commodore 128 users down the road.