Jump to content
rje

Networking and the X16

Recommended Posts

I've seen posts about networking, including the defunct UART emulation in X16emu r36.

So from the FAQ I see these expansion areas:

  • Four expansion slots with access to CPU databus, each with 32 bytes of mapped RAM.
  • 8 GPIO lines (user port)

Is this the likely way to connect to the Interwebs, via a network card that connects to a slot or the user port?

 

  • Like 1

Share this post


Link to post
Share on other sites

I'd love to see a network card using the expansion slot, actually. Although I'd guess you could always do some simili-UART with the GPIO lines.

Share this post


Link to post
Share on other sites

Most likely, people will use the RS-232 port to connect to a "WiFi modem," which can be had for around $60-80 for professionally made ones, or less than $20 for a home made unit. The last I'd heard, there will be a UART on the system, and we won't need to bit-bang GPIO pins. 

 

 

Share this post


Link to post
Share on other sites
Posted (edited)

I was just thinking about the GPIO bit-banging, and yet again I started thinking about using a Raspberry Pi (e.g. Zero W) as an infowebs gateway to talk to... Theoretically, a $5 solution (well, plus SD card), and it gives me an excuse to write Perl (because I love it) and Python (because I need the practice).

 

 

 

Edited by rje

Share this post


Link to post
Share on other sites

The expansion slot is going to be the recommended method. Reality is there will be KERNAL routines and by default those routines will use some of the user port pins to allow RS232 compatible serial. But by loading in a “driver” during the boot sequence you can reroute those routines to support a real UART for much better speed. So long as software is using KERNAL routines and not direct hardware access the changeover should be mostly seamless.


Sent from my iPhone using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites
Most likely, people will use the RS-232 port to connect to a "WiFi modem," which can be had for around $60-80 for professionally made ones, or less than $20 for a home made unit. The last I'd heard, there will be a UART on the system, and we won't need to bit-bang GPIO pins. 
 
 

There will not be a UART on board.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
15 hours ago, Lorin Millsap said:


There will not be a UART on board.


Sent from my iPhone using Tapatalk

Well, that's disappointing. We had talked so much about different RS-232 options on the FB group that it seems like a shame to just abandon RS-232 entirely. 

Edited by TomXP411

Share this post


Link to post
Share on other sites
Well, that's disappointing. We had talked so much about different RS-232 options on the FB group that it seems like a shame to just abandon RS-232 entirely. 

It’s not abandoned, there just isn’t a UART. The user port can be used. You can however (not developed yet) get a card with a UART.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites

I've just noticed that the Ulitmate1541 has a builtin modem now. I've been surfing BBSs the last hours, it's working great. It should be possible to hook the address- and databus to the cartridge. The Expansion ports expose the whole Address and Databus. Of course the cartridges software will not work, but it can be controlled via telnet, so that shouldn't be necessary.

Share this post


Link to post
Share on other sites
5 hours ago, Sandmage said:

I've just noticed that the Ulitmate1541 has a builtin modem now. I've been surfing BBSs the last hours, it's working great. It should be possible to hook the address- and databus to the cartridge. The Expansion ports expose the whole Address and Databus. Of course the cartridges software will not work, but it can be controlled via telnet, so that shouldn't be necessary.

That won't work. The memory map on the Commander is completely different, and the 8MHz clock would also necessitate an intermediary. By the time you're done, you'd have spend more time and effort building an interface adapter than just building a new I/O unit. The Ultimate should be able to work as an IEC disk drive, but you won't have access to the RAM expansion, SIDs, or Swiftlink modem.

I think the way to go for serial is to simply build a 6551-based Swiftlink clone. There are several people making them for the Commodore 64 and 128, so adapting that to the Commander should not be too difficult. The current implementations are interrupt-driven and can deliver 38.4K on a 1MHz 6510. So we should be just fine using that for up to 115K on an 8MHz 65C02. 

At one point, I was also going to write a serial library for the User port. It looks like I'll be re-visiting that plan, as well. I don't really want to write a 2-wire RS-232 driver, since that's slow and requires exact timing. Instead, I'll build a parallel version that uses all of the GPIO pins on the User port. Since it's supposed to be Centronics compatible, we'll have at least 12 bits plus a clock line, and that's enough for what I have planned. (3 control lines and an 8 bit data bus.)

Share this post


Link to post
Share on other sites

Actually using a 6551 is not a good idea. The modern in production 6551s have a serious hardware bug. You are better off using a more modern UART. There are lots to choose from.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, Lorin Millsap said:

Actually using a 6551 is not a good idea. The modern in production 6551s have a serious hardware bug. You are better off using a more modern UART. There are lots to choose from.


Sent from my iPhone using Tapatalk

We've had that conversation, too: the send data status register bit is defective on WDC units, and that is not a problem with other manufacturers' units. Just buy a different brand, and it's all good. 

Since this is the chip used in the Swiftlink cartridge and the clones, it's the easiest one to adapt for the CX16 - there's already tons of software out there that uses it, and we wouldn't need to re-write the serial I/O routines. We can just adapt an existing circuit and existing code to make it work.

Here's an example of a Swiftlink clone with an ESP32 to show what I mean... it's a super simple board:

x5537Dr.jpg

https://www.lemon64.com/forum/viewtopic.php?t=75130

 

 

 

Edited by TomXP411

Share this post


Link to post
Share on other sites
We've had that conversation, too: the send data status register bit is defective on WDC units, and that is not a problem with other manufacturers' units. Just buy a different brand, and it's all good. 
Since this is the chip used in the Swiftlink cartridge and the clones, it's the easiest one to adapt for the CX16 - there's already tons of software out there that uses it, and we wouldn't need to re-write the serial I/O routines. We can just adapt an existing circuit and existing code to make it work.
Here's an example of a Swiftlink clone with an ESP32 to show what I mean... it's a super simple board:

x5537Dr.jpg
https://www.lemon64.com/forum/viewtopic.php?t=75130

 
 
 

The problem is that other brands are not really an option as they are not in active production and the vintage ones don’t have the speed rating.

The other modern UARTs are better in pretty much every way. They have larger buffers, they can handle greater speeds, they don’t have hardware bugs, and they are way less expensive. There are a couple reasons we don’t have it. Personally I wanted a UART but the reasons for not including it were legitimate and it can be added via expansion card. The system will still have onboard capability, just not as fast.


Sent from my iPhone using Tapatalk
  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

I'm perfectly happy with networking with one of those offboard widgets that emulates a modem, which kind of narrows the CX16 side to serial support. I don't know how fast the User Port can do bit-banging serial, but if it uses the serial shift register to receive that might make for fewer dropouts.

As far as a cheap serial interface card, the Max3107 has a built in oscillator, 128 byte buffers, and IIRTDC (if I read the datasheet correctly) hardware flow control support. It's a tiny surface mount part, but that's not an issue for a built board. (No, I don't know if it's active or obsolete and selling the stock out, last I saw it in a parts list, it was awfully cheap, $2-$3 Qty1, so that could have been the last run on their way out the door. The Maxim3140 was a lot more expensive, nearly $10 Qty1.)

Why it wouldn't be an option for the CX16 main board is in addition to being surface mount, it's a SPI/I2C part (at that scale pins cost more money than the silicon to include slave serial buses), so with Vera having no pins to use for multiple selects to share with the SD card bus, it just doesn't fit for the reference design.

As far as being an SPI/I2C part, Andre Fachet did a 6502 bus SPI 4-device bus master on FPGA about a decade ago, so until I hear of a fatal flaw with that design, I'm going to keep my eye open for inexpensive SPI chips to bundle into a single expansion port build.

Edited by BruceMcF
  • Like 1

Share this post


Link to post
Share on other sites
I'm perfectly happy with networking with one of those offboard widgets that emulates a modem, which kind of narrows the CX16 side to serial support. I don't know how fast the User Port can do bit-banging serial, but if it uses the serial shift register to receive that might make for fewer dropouts.

As far as a cheap serial interface card, the Max3107 has a built in oscillator, 128 byte buffers, and IIRTDC (if I read the datasheet correctly) hardware flow control support. It's a tiny surface mount part, but that's not an issue for a built board. (No, I don't know if it's active or obsolete and selling the stock out, last I saw it in a parts list, it was awfully cheap, $2-$3 Qty1, so that could have been the last run on their way out the door. The Maxim3140 was a lot more expensive, nearly $10 Qty1.)
Why it wouldn't be an option for the CX16 main board is in addition to being surface mount, it's a SPI/I2C part (at that scale pins cost more money than the silicon to include slave serial buses), so with Vera having no pins to use for multiple selects to share with the SD card bus, it just doesn't fit for the reference design.
As far as being an SPI/I2C part, Andre Fachet did a 6502 bus SPI 4-device bus master on FPGA about a decade ago, so until I hear of a fatal flaw with that design, I'm going to keep my eye open for inexpensive SPI chips to bundle into a single expansion port build.

Yes I’m aware if the SPI master. However it’s based on an off language for an obsolete chip.

There is no reason to try to use an I2C or SPI here. It makes sense on microcontrollers that don’t have exposed buses and IO is precious. But here it doesn’t make much sense. And yes, existing RS232 dongles should work fine. The onboard should work fine. We don’t know what speeds it can do yet, but 56kbps doesn’t seem unreasonable. That’s almost 8k per second.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
4 hours ago, Lorin Millsap said:

 The onboard should work fine. We don’t know what speeds it can do yet, but 56kbps doesn’t seem unreasonable. That’s almost 8k per second.

That seems awfully optimistic ... the best the C64 could do with bit banging its CIA GPIO was 2400bps, and 56K is 23 times faster. If true it's even better, since using the serial shift registers of to 6522's will be two to four times faster than bit banging their gpio lines.

As far as the rest, you'll pardon me if I not not prepared to take on faith that the VHDL source for an older Xilinx CPLD cannot be ported to a newer generation CPLD.

  • Like 1

Share this post


Link to post
Share on other sites
That seems awfully optimistic ... the best the C64 could do with bit banging its CIA GPIO was 2400bps, and 56K is 23 times faster. If true it's even better, since using the serial shift registers of to 6522's will be two to four times faster than bit banging their gpio lines.

As far as the rest, you'll pardon me if I not not prepared to take on faith that the VHDL source for an older Xilinx CPLD cannot be ported to a newer generation CPLD.

It was possible to achieve 9600 baud on the c64. Im pretty sure that is using shift registers.

 

On the legacy CPLD SPI interface, the problem isn’t that it can’t be done. The problem is a lack of pros. A parallel bus interfaced UART is going to way outperform an SPI one. It will cost less too and require fewer supporting components.

 

Reality is that the UART was removed from the design because we simply don’t have the resources for it and we need to move the project forward. We can easily implement a functional equivalent using the hardware we already have.

Share this post


Link to post
Share on other sites
On 7/9/2020 at 8:28 AM, Lorin Millsap said:

It was possible to achieve 9600 baud on the c64. Im pretty sure that is using shift registers.

On the legacy CPLD SPI interface, the problem isn’t that it can’t be done. The problem is a lack of pros. A parallel bus interfaced UART is going to way outperform an SPI one. It will cost less too and require fewer supporting components.

(1) How fast you could achieve using the CIA shift registers is pretty much immaterial if you don't have a pair of VIA shift registers to use. The best that bit banging the CIA GPIO on the User Port could do was 2400bps, so assuming that you can bit bang at 8 times higher clock speed and get over 20 times better performance is what I was referring to as quite optimistic ... if there aren't any hidden gotchas, 8 times the system clock would map to 19.2Kbps.

It seems likely one of the cheapest ways to replicate the third party C64 9600bps serial interface at 4-8 times the speed would be a single VIA and a ribbon cable tapping into the free shift register from the User Port. For a TTL header, it would be a single chip board with a 38.4Kbps-76.8Kbps throughput, plus a second EPP parallel port interface as a bonus.

(2) A parallel bus interfaced UART isn't going to "way outperform" an SPI when a post-indexed copy loop only needs a single NOP to be properly paced for a PHI2/2 synchronous serial bus. A parallel bus interfaced UART is going to be within 100%-120% of the performance on the system side, with performance in many circumstances on the port side more determined by FIFO size.

Either an SPI or a 8 bit Intel bus UART needs one supporting component on the CX16 bus side and identical supporting components on the RS232C / TTL header side, but the supporting component for SPI costs more, and supports four devices. On the other hand, other than VLIO bus UARTS, the 8bit parallel UARTs are getting a bit long in the tooth.

Clipped the inside baseball.

Share this post


Link to post
Share on other sites

We do have shift registers available. The 65c22 shift registers do in fact work properly.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
On 7/11/2020 at 5:15 PM, Lorin Millsap said:

We do have shift registers available. The 65c22 shift registers do in fact work properly.

The description of the preliminary User Port only listed one shift register as available.

Share this post


Link to post
Share on other sites
The description of the preliminary User Port only listed one shift register as available.

Sorry. You are correct. The other shift register is in the other VIA and it is not available.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
Posted (edited)

in the same thought process as @TomXP411 swiftlink nomination, adding https://lallafa.de/blog/amiga-projects/plipbox/ which is effectively a parallel port to arduino with a RJ45 shield allowing an Amiga to get online. Would need the driver and TCP/IP stack writing if not already present, additionally converting from the current parallel port to expansion bus.

 

 

Edited by peapod

Share this post


Link to post
Share on other sites
15 hours ago, peapod said:

in the same thought process as @TomXP411 swiftlink nomination, adding https://lallafa.de/blog/amiga-projects/plipbox/ which is effectively a parallel port to arduino with a RJ45 shield allowing an Amiga to get online. Would need the driver and TCP/IP stack writing if not already present, additionally converting from the current parallel port to expansion bus.

 

 

I was actually thinking about Plipbox, as well. The only problem with Plipbox is that it requires network drivers on the computer. If you drop the network drivers into the microcontroller, then you can just treat it like a modem, and things are much simpler.

 

Share this post


Link to post
Share on other sites

There are TCP/IP drivers available for the 6502. GeckOS has one (assembler), and uIP (in C) is working even better.

  • Like 1

Share this post


Link to post
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.


×
×
  • Create New...

Important Information

Please review our Terms of Use