Jump to content

Ides of March Status of X16


Recommended Posts

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.

 

  • Like 3
  • Thanks 5
Link to comment
Share on other sites

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!

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.  

 

 

 

Edited by rje
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

  • Super Administrators
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. 

 

 

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 2
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

  • Super Administrators
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.

  • Like 1
Link to comment
Share on other sites

On 3/17/2022 at 12:18 PM, TomXP411 said:

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.

I meant "ala" to imply "in the manner of / for example".

I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.

Link to comment
Share on other sites

On 3/17/2022 at 2:33 PM, Scott Robison said:

I meant "ala" to imply "in the manner of / for example".

I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.

Yes. Support for one fastloader format already supported by SD2IEC would allow existing devices to be used, while support for the most efficient available alternative for the CX16 would allow units with CX-compatible firmware to communicate as fast as possible. Whether the C128 burst mode is supported in hardware by the available pins on the W65C22 ... I don't know, but it wouldn't be surprising if Burst mode on an SD2IEC device connected to a 4MHz, 6.25MHz or 8MHz CX16 would allow faster throughput than Burst Mode to a C128.

  • Like 2
Link to comment
Share on other sites

  • Super Administrators
On 3/17/2022 at 11:33 AM, Scott Robison said:

I meant "ala" to imply "in the manner of / for example".

I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.

I'm pretty sure burst mode would require ROM changes, though. I don't think a stock 64 supported burst mode on capable drives. Related but different is fast serial mode which definitely requires different ROM routines.

there are actually is a C64 burst ROM KERNAL already out there. And there's obviously the Commodore 128 KERNAL. Since that code already exists, that should be less of an issue than trying to re-create the JiffyDOS protocol from scratch in a manner that doesn't infringe on Mark Fellows's Copyright.
 
Link to comment
Share on other sites

Right, I thought you were saying the kernal could use those features without modification. My understanding was that C64 was the base kernal, and I don't know what the license actually allows from other kernals. It may be a distinction without a difference.

How about FabuDOS instead? 🙂

Link to comment
Share on other sites

The continued discussion after David's comment would be helpful, but no FB here, wish David would give a proper YouTube update where more people would see it.

This gives me a bad feeling about the future.  

Link to comment
Share on other sites

It seems Michael is willing to fix the sd card issues and I would hate to lose that feature.  Maybe this Facebook post will kickstart the project again
 

Quote

About FAT32 and the SD card: First, this is a very complex yet mature piece of the software stack. And it is way better than an external sd2iec, e.g. it's 50x faster, but also way less limited, more generic, and still very much in the style of Commodore hardware (no D64 images, but direct access to up to 2 TB of storage, with subdirs etc). Sure there are bugs, as in any software. I could dedicate some time to fix them, but again, with the project overall making little progress, I'd rather dedicate it once I know there will actually be a project at the end.

 

  • Like 3
Link to comment
Share on other sites

On 3/18/2022 at 5:04 AM, dr.diesel said:

The continued discussion after David's comment would be helpful, but no FB here, wish David would give a proper YouTube update where more people would see it.

This gives me a bad feeling about the future.  

I don't think the lack of a YouTube update at this point is cause for concern, or at least no more concern than before the most recent FB update. David puts a lot of time into production on his videos, trying to create evergreen content. This would not qualify (at least not from my perspective).

Link to comment
Share on other sites

why not creating a SD device that goes on the floppy drive connection and make it work as if it was one? that could move this out of the computer insides and be more easier to update it, no? and you can make so that you can have 4 like the floppy drive and help copy files on each of them?

I can already see the tiny SD reader with a floppy-drive style design near the computer, could be fun.

Link to comment
Share on other sites

On 3/22/2022 at 3:24 PM, DragonGaulois said:

why not creating a SD device that goes on the floppy drive connection and make it work as if it was one?

That's what a SD-2-IEC device does - which already exist. Maybe not super fast, but they will work.

  • Like 1
Link to comment
Share on other sites

  • Super Administrators
On 3/22/2022 at 7:46 AM, AndyMt said:

That's what a SD-2-IEC device does - which already exist. Maybe not super fast, but they will work.

Just for clarity's sake, the device's name is "SD2IEC". No hyphens.

Normally, it's no big deal what you want to call it, but using different names for the same thing makes it hard to search the forums, since searching for "sd2iec" may not turn up references to "sd-2-iec".

Link to comment
Share on other sites

I'm pretty sure AndyMt wrote it like that to emphasize the SD-to-IEC aspect of it, and break it down for clarity to someone who might have thought it was just an 'XL2000'... numbers and letters that sound cool. Or maybe a vanity name for Stephen Douglas's second IEC device.

But yeah, the actual product is just SD2IEC.

  • Like 1
Link to comment
Share on other sites

On 3/22/2022 at 10:46 AM, AndyMt said:

That's what a SD-2-IEC device does - which already exist. Maybe not super fast, but they will work.

And adding the C128/1571/1581 burst mode should certainly be do-able, because it's a three wire interface with data, clock, and a receiver "ACK" line, so it's not based on a fixed clock speed, but goes as fast as the slower of the sender and receiver. It uses the IEC SRQ line as the burst mode clock line, and the IEC clock line as the burst mode ACK line.

If the VIA timers and serial shift register lines from the CX16 are used, the CX16 ought to support a pretty high top speed for burst mode.

And of course, it's just used for bulk data transfers, using the normal IEC for thinks like opening files, etc. ... so starting with an SD2IEC which already has that side covered makes sense.

Edited by BruceMcF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use