Commander X16

The Sega Dreamcast had a built in modem ?   Wish I still had that system - had a keyboard too, and a web browser software was available for it eventually.  

I read about the 1982 game COMMBAT, published Scott Adams (I emailed him recently and confirmed it actually existed and works).  It let a TRS-80 and Apple II users play a simple game against each other, over a modem connection (or could be same-type systems also).  So, it had some simple protocol to communicate plays and game-state between these two systems.   Another example is SOPWITH2 around 1984 (it was IBM PC only, but worked across a serial connection).

No ethernet.  I just thought it would be interesting to replicate that "heterogeneous system" connectivity, across a modem.  I still have lots of physical systems and don't use emulators all that much.

 

Also:

These days, you have the projects with "weird size" LED screens - like say 32x4 rows. Sure, someone could do a terminal emulation that supports ANSI on that.   

Then the Datapoint 2200 from 1970 was 80x16, then the TRS-80s/IBM 5100/Wang 2200 with 64x16.   Not that many people are powering up pre-1977 equipment (I do) - not much selection for ANSI terminals on those anyway (since even if a terminal program were written, not many have a working tape or 8" disk to even load up any software).  

Followed by 40x24 on the early Apple's (PET was 40x25), 80x25 for PC.   Then finally modern GUIs let us virtualize up to any size console we want (like 200x160, or... whatever suits you).

 

 

If a modernized "smart BBS" asked for what console size to use during that connection-session, then it could render ANSI stuff accordingly to that resolution.   Maybe like a "RetroTube" or "ASCIITube":  You connect using the WiModem232 via a command like "ATDTsomewhere.com:1234", enter your console resolution, and it pushes content appropriate to that specified console size (similar to how YouTube is forever transcoding videos to be more appropriate to the viewers bandwidth and screen resolution) -- whether that connected client is ancient or modern.    If anything, it could be a "screen saver" to play during vintage computing gatherings ?   No animation per se, but a kind of "ANSI codec" to find the least amount of escape sequences to transition from one image/scene to another could be computed on the fly (by this kind of "smart BBS" server).   

 

 

Revised... Not a network between these systems, but managed connections by a "smart BBS" (that handles interaction/collaboration between the connections, w.r.t. the specified console resolution of both systems involved)



 

 

I was experimenting with the WiModem232 on the CoCo1... Without the RS232 Pak, the built in serial connection could only do 1200 baud.   That was surprising since the PET could manage 2400 baud.

Adding the RS232 Pak on the CoCo (which connects thru the cartridge port), then it could handle 9600 baud.

 

With the 8MHz X16, I'm not sure what the difference will be (between some onboard emulation versus some solution as a cartridge).

 

On 10/22/2022 at 2:35 AM, voidstar said:

I was experimenting with the WiModem232 on the CoCo1... Without the RS232 Pak, the built in serial connection could only do 1200 baud.   That was surprising since the PET could manage 2400 baud.



Adding the RS232 Pak on the CoCo (which connects thru the cartridge port), then it could handle 9600 baud.



 



With the 8MHz X16, I'm not sure what the difference will be (between some onboard emulation versus some solution as a cartridge).

The Commodore 64 User port could handle bit-banged serial at up to 2400 bits per second, and the 6551 used in the Swiftlink cartridge can run at 19.2K (or faster if externally clocked.)

The Commander is 8x faster, so you should be able to manage about 19.2K bit-banged and the full 115.2K with a 65C51N. 

 

Commodore 64, Novaterm 9.6a supports "UP9600" that doesn't need any real hardware.

https://www.pagetable.com/?p=1656 - UP9600: How to Bit-Bang 9600 Baud RS-232 on the C64

"The idea is to use the hardware shift registers of the two CIA 6526 I/O controllers to do the timing-critical part of the transfer."

 

For faster serial speed:

https://gglabs.us/node/2057 - GLINK232T - Turbo232 UART cartridge for Commodore 64/128

"SwiftLink232 and Turbo232 cartridges based on the 6551 ACIA chip."

"The additional baud rates (203400, 115200 and 57600) are obtained by bypassing the 6551 baud rate generator and optionally dividing the oscillator output by 2 or 4."

 

(for unmodulated communication it's bit/s not baud)

Assuming networking; I would expect there to be, maximally, a lynx-like text browser and gopher:// protocol support. All that other crap is, well, crap. The gopher-verse is making a comeback. You might find an exceptional amount of excitement over this through gopher holes like the SDF unix folks.

neutrino wrote: ↑Sun Dec 18, 2022 10:26 pm Commodore 64, Novaterm 9.6a supports "UP9600" that doesn't need any real hardware.

https://www.pagetable.com/?p=1656 - UP9600: How to Bit-Bang 9600 Baud RS-232 on the C64

"The idea is to use the hardware shift registers of the two CIA 6526 I/O controllers to do the timing-critical part of the transfer." ...

However, we don't have two hardware shift registers of VIA's, since VIA#2 is optional in the Gen1, and might not be included at all in the Gen2.

Still, according to the current documents, we do appear to have 3 GPIO (PortB bits 0-2), two handshake outputs (CA2 and CB2), and one handshake input (CA1), so bit banging TTL serial ought to be possible. With an 8x faster clock, there's no guarantee that 19.2kbps is available until it's tried, but at least 9.6kbps should be available. And there are enough I/O lines for hardware flow control (each handshake output line can be separately set to either high or low).

Just my two cents here. For me, what would be period correct and hugely enjoyable is a simple wifi modem that allows for a simple terminal program to connect to internet-based bbses. One of my primary uses for my C64 was to connect to bbses for conversation, games and downloads. To me, having some sort of simple modem would be a huge addition to what is already and awesome platform for explortaion.

geekpower wrote: ↑Sat Apr 20, 2024 10:44 pm Just my two cents here. For me, what would be period correct and hugely enjoyable is a simple wifi modem that allows for a simple terminal program to connect to internet-based bbses. One of my primary uses for my C64 was to connect to bbses for conversation, games and downloads. To me, having some sort of simple modem would be a huge addition to what is already and awesome platform for explortaion.

Kevin (TEXELEC) is developing one(a wifi card). There's already been a demo of a prototype, the 8bg has already written >95% of a terminal program and demoed that as well with TEXELEC's card. Last I knew there's still work being done because the current terminal program only has BASIC ASCII control support. Full ANSI control character support is being worked on.

Kevin (TEXELEC) is developing one(a wifi card). There's already been a demo of a prototype, the 8bg has already written >95% of a terminal program and demoed that as well with TEXELEC's card. Last I knew there's still work being done because the current terminal program only has BASIC ASCII control support. Full ANSI control character support is being worked on.

That's fantastic news! It would be awesome if there was a github for that board so we could contribute or at least test it as it's being developed.