Ides of March Status of X16

[martinot]

On 3/25/2022 at 12:44 AM, TomXP411 said:

That about sums it up. 



We are still the official community site for the Commander X16, but the site's actual ownership is now independent. The owners (there are 5 of us) are maintaining this community going forward. (There could be personnel changes in the future, and so we've structured the group to allow for people to come and go without disrupting the site's operation.)



As a result, we don't have any special influence on the Commander's design or special access to its hardware. We are fans, like you, and we're just doing our part to help the community communicate, share ideas, and help keep the dream alive. 



 

If that is true, why does it say "Copyright © 2022 8-Bit Productions LLC. All rights reserved." on the home page?

This doeas not compute (if it is a fan based site, and not any official site by David and his company 8-Bit Production).

[Scott Robison]

On 3/25/2022 at 4:45 PM, martinot said:

If that is true, why does it say "Copyright © 2022 8-Bit Productions LLC. All rights reserved." on the home page?



This doeas not compute (if it is a fan based site, and not any official site by David and his company 8-Bit Production).

In the beginning this forum was a creation of a team member, and that copyright notice was assigned to the site.

All of that content still exists in the site and thus the effort has not been made to change the copyright notice.

Note that just because there is a copyright notice does not mean that every word of text on the site is under copyright by 8-Bit Productions. The reality is more nuanced: People hold a copyright on what they right, and there is an implicit understanding when posting on a forum that when you post something, you are giving a right to copy it as it is necessary to transmission to other people.

Long story short is that the copyright notice is primarily a product of inertia. With a new website coming per previously posted discussion, perhaps there may be a change to reflect that all items are copyright their authors or some such.

[Main Administrator]

On 3/25/2022 at 3:45 PM, martinot said:

If that is true, why does it say "Copyright © 2022 8-Bit Productions LLC. All rights reserved." on the home page?



This doeas not compute (if it is a fan based site, and not any official site by David and his company 8-Bit Production).

I think the situation has already been explained in the "Change Of Command" thread. Maybe you can move any other questions there, or start a new thread if you have concerns not addressed there. 

Thank you.

 

[BruceMcF]

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

Right. Hence why it is nice that fast serial works for any kernal call as I stated. It would be nice if the real burst routines were just as automatic.

I believe that where it is relevant is the multi-byte calls, LOAD, SAVE and MACPTR.

The IEC port as documented in the current PRG on GitHub is NOT connected for "full speed" burst mode, it is connected for C64 bit banging the IEC port. Since the burstload mode is asynchronous, that will work as fast as the CX16 can bit bang the protocol, but it is going to be a much lower ceiling on the speed than a hardware burst mode connection. For full speed burst mode, data should be connected to a VIA serial port data line, and SRQ to the serial port clock line.

I do not know whether or not this is up to date for the current revision of the board: it MAY BE that the serial data lines from VIA#2 are connected to the IEC and the PRG just does not document the fact.

In Pasi Ojala's Burst Fastloader for C64, he connects to the User Port serial lines. Presently the I2C port uses the system VIA serial shift register, but none of the VIA#2 lines are allocated to system use, so the VIA#2 serial shift register lines are available.

However, ideally. all of the VIA#2 lines will remain available to the User. An alternative, since the PS2 ports are being moved to the microcontroller, and a microcontroller used with enough lines to be put into the I/O page at $9Fxx, would be to shift the I2C bus to the microcontroller, and free up the VIA#1 serial bus for hardware fastloader support.

 

[Ed Minchau]

On 3/26/2022 at 3:19 AM, BruceMcF said:

However, ideally. all of the VIA#2 lines will remain available to the User. An alternative, since the PS2 ports are being moved to the microcontroller, and a microcontroller used with enough lines to be put into the I/O page at $9Fxx, would be to shift the I2C bus to the microcontroller, and free up the VIA#1 serial bus for hardware fastloader support.



 

Or, maybe add another 6522?

[Scott Robison]

On 3/26/2022 at 3:19 AM, BruceMcF said:

I believe that where it is relevant is the multi-byte calls, LOAD, SAVE and MACPTR.



The IEC port as documented in the current PRG on GitHub is NOT connected for "full speed" burst mode, it is connected for C64 bit banging the IEC port. Since the burstload mode is asynchronous, that will work as fast as the CX16 can bit bang the protocol, but it is going to be a much lower ceiling on the speed than a hardware burst mode connection. For full speed burst mode, data should be connected to a VIA serial port data line, and SRQ to the serial port clock line.



I do not know whether or not this is up to date for the current revision of the board: it MAY BE that the serial data lines from VIA#2 are connected to the IEC and the PRG just does not document the fact.



In Pasi Ojala's Burst Fastloader for C64, he connects to the User Port serial lines. Presently the I2C port uses the system VIA serial shift register, but none of the VIA#2 lines are allocated to system use, so the VIA#2 serial shift register lines are available.



However, ideally. all of the VIA#2 lines will remain available to the User. An alternative, since the PS2 ports are being moved to the microcontroller, and a microcontroller used with enough lines to be put into the I/O page at $9Fxx, would be to shift the I2C bus to the microcontroller, and free up the VIA#1 serial bus for hardware fastloader support.



 

All my statements presuppose that the IEC port is wired appropriately to support fast serial and burst mode.

Fast serial "just works". On a 128, when you call the kernal LOAD and SAVE calls, fast serial is used if it is available on the addressed device. Burst mode requires more kernal calls to open a command channel, send the appropriate commands to the device as an encoded stream of bytes, then react the appropriate way.

It's a bit fuzzy to me because I've never tried to use the burst mode command set, but I didn't have to do anything special in 128 Robots to load with fast serial. The exact same calls that were used on the C64 were used to load files in the C128 and the kernal did the right thing.

[BruceMcF]

On 3/26/2022 at 1:31 PM, Scott Robison said:

All my statements presuppose that the IEC port is wired appropriately to support fast serial and burst mode.



Fast serial "just works". On a 128, when you call the kernal LOAD and SAVE calls, fast serial is used if it is available on the addressed device. Burst mode requires more kernal calls to open a command channel, send the appropriate commands to the device as an encoded stream of bytes, then react the appropriate way. ...

Yes, AFAIU, it "just works" because the C128 KERNAL code has been extended to check whether a device is capable of supporting fast serial and, if it is, then each data byte is sent or received using the burst protocol. That is "fast serial". LOAD and SAVE inherit that from the lower level KERNAL routines that they call, so once it works on the byte at a time KERNAL routines, it works for LOAD and SAVE too.

For it to "just work" in the CX16, the IEC routines would have to be similarly extended.

Had Commodore written entirely new LOAD and SAVE routines based on using burst mode for multiple bytes at a time, and use those instead of the original LOAD and SAVE routines based on the underlying byte at a time KERNAL routines, then burst mode would also "just work" for LOAD and SAVE.

Indeed, if the CX16 implemented the original IEC protocol for broad compatibility and burst mode SAVE and LOAD for speed, then burst mode would be the one that "just works" and fast serial is the one that would require additional user-side code.

[BruceMcF]

On 3/26/2022 at 1:29 PM, Ed Minchau said:

Or, maybe add another 6522?

In the abstract, sure. In practice, I don't think it will happen ... I think that people get more than two VIA's if they buy an expansion card with one or two VIA's on the expansion card.

And the burst mode protocol was designed for the 6522, while it's certain that whatever microcontroller they get will have hardware I2C support built in. Using the microcontroller to access the RTC and using the VIA to run the C128/1571 derived upgraded IEC protocol feels to me like improving the fit on both sides.

 

[Fabio]

On 3/18/2022 at 12:49 AM, BruceMcF said:

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.

I'm sorry for the late reply but I'm curious where the 6,25 MHz frequency comes from?.

[BruceMcF]

On 3/28/2022 at 6:23 PM, Fabio said:

I'm sorry for the late reply but I'm curious where the 6,25 MHz frequency comes from?.

It's an arbitrary frequency between 4MHz and 8MHz. It can show up, for example, when you have a 25MHz primary crystal, being used internally in an FPGA to generate a 50MHz internal clock through a phase lock loop and an external divide by 4 circuit to square off the clock. 6.25MHz is a lot more tolerant than 8MHz for flashROMs and SRAM that "ought to be JUST fast enough just work at 8MHz" ... but sometimes in practice don't work as well as hoped.