Thanks @retrobits for taking the time to install and test the BBS. You've given a good overview of what RetroBBS and Retroterm can do. Retroterm was initially developed using an RS232 interface on the user port (no UART, just using a MAX232 voltage adapter) and a serial-USB adapter (PL2303) on a PC, always at a speed of 57600 bps. As for whether it would have been possible to have something like this in the 80s/90s, it would have been difficult, but not because of the server but because of the available telephone modems. Early versions of RetroBBS required specially generated binaries with images, 4-bit PCM audio, or programs. Before choosing to write the server in Python, I thought about doing it under MSDOS, because it was still a presentation system without a network connection. Therefore, we could have had a server with hardware similar to what a classic BBS would use.
Wow so amazing. As an old guy who was super involved in the BBS scene from 85 to 96, this brought back so many memories. So pleased to see that modern solutions are available for BBSing on our old machines. I still remember downloading a cracked copy of ghostbusters on my 2400 baud modem using new punter and losing all of my progress when my sister picked up the phone.
... I was a FIDO Administrator in the 80's and I'm still dreaming about the interesting times and experiences with BBS nodes before the internet overtook us. Thanks for the great video
@@RickTheGeek That's right, FIDO still exists, but here in Germany, it's almost non-existent. I started in Helsinki Finland in 1987 and then moved back to Germany. I was still active there until 2000, but it was already declining by then. Here are my last 4 node numbers: 2:245/2 Werner Cappel From Homburg 1996.05.24 - 1998.04.24 2:245/6803 Werner Cappel From Homburg Saar 1998.06.12 - 1999.08.20 2:245/5500 Werner Cappel From Homburg 1998.07.03 - 1999.08.20 2:245/7000 Werner Cappel From Homburg 2000.05.12 - 2001.04.06
TH-cam really needs to mind its own business. They keep up with their stupid copyright strikes for music that is being used for demonstration purposes.
"the future" of computing people could only dream of even at the machine's peak-- amazing how passionate devs squeezed stuff like youtube framecapture, game and audio streaming into that 64k of ram and 1mhz cpu ❤
PS: That "loading" of IK+ through the BBS went up 10x faster than how we used to do it turbo-less from floppy or tape 🤣thanks for the nostalgic surprise (Also, serial-to-usb-dongles are known for compatibility issues with incorrect pinouts and signal problems all over the place-- make sure you get a good one!)
It's entirely possible! The RTS/CTS lines need to be connected properly for Retroterm to function. I was able to get a rock solid 57.6k connection using tcpser and that dongle using Striketerm to a regular telnet BBS but I guess that doesn't mean anything because of how Turbo56k relies on the flow control for everything.
@@retrobitstv Pure personal experience; used to work for a company with a PLC division (basically vending machines to factory & defense automation) and had to order bunches of models of serial converters at some point (sorry I can't remember any) since so many didn't comply to standards and basically failed to connect to devices :( major headaches for engineers once serial ports were phased out of newer model notebooks. Guess I'm trying to say either something with onboard serial or a known quality adapter might be worth a try! 😅
Works great using the C64Net WiFi modem, and yea, the speed is unreal. When I set it to 57600 bps, ran retroterm, and typed commands, I was shocked that anything came back. Amazing stuff.
I have a Wifi modem as well, with Zimmer update, but I can't get retroterm to work... it loads up, plays the cool Wargames sounds, but I am not able to connect to any bbs. How are you setting the bps of your wifi? Through programming or at commands?
I'm in a similar situation. I get errors from some BBSs where it does not see me hitting the "Return" key to continue to connect. If I hit other keys, I get a Turbo56k error
Awesome that the BBS software can support plugins. I've been working on a way to access Twitter from the C64, and though I can get all the text data with no problem (thanks to the Python library called Twython) it was getting the image data that was holding me back. At 1200 or 2400 bps the speeds were just too slow to download and render an image, and I still had to come up with a custom terminal program to display the resulting image right on screen, rather than downloading it to disk and viewing it later. This software might make it possible to do what I want, although logging into a Twitter account might be a problem thanks to the OAuth method of using a browser to sign in, getting permissions, and getting a token that gets passed along to your application. Brilliant work none the less!
Wow what a trip, thank you for sharing! As mindblowing as this is to witness decades after owning the thing I'd still love to see how far they could push this concept for SuperCPU and REU-expansions :)
This is fascinating stuff. Imagine having this back in the day - it would have been incredible. The game downloading feature is like an early days Xbox Game Pass !
Awesome, Matt! Thanks for showing this off. A bit of related trivia: the "Oral History of Brent Townshend" was recently posted by the Computer History Museum (TH-cam channel). Brent Townshend is the person who made the breakthrough to 56kbps modems in the mid '90s. He realized that the existing assumed theoretical "speed limit" of ~35Kbps for modems on a POTS-based "last mile" could be exceeded by thinking about the problem differently. The next real limit, still constrained by Shannon Entropy but with different parameters, was ~64Kbps: the capacity of each telephone line in the digital core of the telephone network. 5:48 Interestingly, he came to invent it by thinking about how to stream digital music at higher quality. I found this a fascinating interview (~3 hours in total). The fastest modems possible was not his only invention nor area of expertise; he shares a number of interesting life stories.
Interesting tie-in there! I must admit to not being very well-versed in how the later high speed modem protocols work and what the limitations they were up against. The last modem I ever owned was a 28.8k before heading off to college and gaining 10mbit access to an OC-3. The following summer ('96), my home town was a cablemodem test market and I never looked back.
@@retrobitstv To be even more specific, his goal was to stream high quality music over phone lines! (I stopped at 33.6Kbpbs Supra modems, for similar reasons.) IIRC, I had 19.2k serial in my dorm room directly to an AT&T ISN port to the campus phone system ( That I admin'ed.)
Thanks for sharing. So far with Vice, lu8fjh bbs is telling me I need a compatible terminal software, but I’m getting close. I’m gonna fire up with my c-128 and wifi modem and see if real hardware fixes it up. Thank you!! Nevermind; you got me. I was trying to bridge thru tcpser as the GitHub said, but you got me online. Thank you!!
Wow if this was around back in the day it would have been mind blowing. Thank you so much for showing us this and I am glad you finally worked out the edit.
To be fair, the weightlifting (decoding and converting JPEG/audio file or stream) is done on the server side by retrobbs. Nevertheless, it's amazing stuff. Does someone know if this can run on a MiSTer with its C64 core's modem replication? That SID streaming feature would be very neat, if it could continuously stream files based on song lengths (I guess you can modify retrobbs to do that). I could imagine using the MiSTer as a SID jukebox. It probably boils down to supporting Turbo232 on the C64 core (I don't see it unfortunately), otherwise the terminal server could run on the HPS/Linux side to serve files from the SD card.
Great question, that would be a super cool use of the core! I just took a peek as well and yea, it looks like the RS232 options are limited to UP9600 as the "high speed" option. The core seems to be getting new features from time to time so hopefully in the future? I've been meaning to try out the hardware IEC connectivity but I need to build the interface first. Maybe a future episode.
There's support for HVSC style songlength files, there's also the SLIDESHOW function that sequentially streams all supported files on a given directory, unfortunatelly I forgot to add .sid in the list of supported files 😓. But that's easy to fix. One important detail is that only single speed (1x) .sid files are supported. And some of those that use hardrestart might sound funny or completely wrong.
2 ปีที่แล้ว +1
@@retrocomputacion haven't checked the code yet, but does the SID file gets actually "streamed" (the Python side executes the SID code and sends SID register changes over the serial connection and the C64 side just blindly writes that to the SID chip) as its being played (so essentially the same way as the PCM part works but with lot less data), or you transfer the file to the memory first and the run the player routine on the C64 itself? Mod: never mind, it's in the readme "SID music streaming: SID files are converted to a stream of SID register writes.", that's cool, so the server is basically in full control when the song change, even remote control would be possible.
@ Yeah, it uses SIDdump to get the register data. We've been thinking about some sort of frontend for the BBS that controls the C64 remotely, mostly for us to streamline development time by directly triggering new features instead of having to navigate the different BBS menus from the C64. Edit: Oops posted from wrong account :P
that 1980s Canadian NABU 8-bit computer could perhaps achieved some of the feats shown here but done so back in the day, as it was intended to be used as always connected to one's cable service. So servers could have streamed things pretty quickly over cable to said 8-bit computer. If this had caught on and been entirely succesful, we would have had Internet like experience about a full decade sooner
If the 64 can do all this, imagine what a similar setup for the Amiga could do. Well, I say "THE Amiga", but unfortunately Amiga doesn't have nearly the same sort of homebrew scene that the 64 does, specifically because it wasn't a single, discrete piece of hardware but an evolving platform like x86 PCs and Macs. So there's not as much incentive to see how far you can push an A1000/A500 in particular when newer, more capable ones already exist.
Hi. My C64G configuration is: U2 (normal) and 0.13a mm firmware. The list menu modem configuration is identical. But retro term 0.14sl or 0.20 not work. Stopped after initial title and no characters if I try any commands.
115k2 or 128kbit/s are no problem at all on a 6502... as long as you use a proper uart chip... dat bit where the 6551 can't only use it's internal baud rate generator (devider) but also simply can run the provided rs232 clock / 16. whatever that external clockrate is. (as long as it's not higher than let's say, the megahertz the 65c51 in question is rated for ;) and the computer can handle the interrupts fast enough to 'pump it away to some place and do stuff with it' (should be no problem even at the c64's lousy 1mhz or so - and yes that already was lousy for 6502 standards when it was brand new. other manufacturers were happily chunking out the 6502 at 2 or 4 or higher ratings even back then ;) any other issues such as wire length etc are simply solved by not running rs232 over copper but let's say, using fiberoptic tranceivers. even the simple ones from 30 years ago go well over 5mhz. (or you simply don't use it at all and insert an 8 bit ethernet controller ;)
you know for something calling itself 'commodore business machines' tramiel completely missed the point that computers must have networking interfaces. absolute fail :P bitbanging some glorified shift register. lolol. like what the hell. they made perfectly fine 6551's themselves which they did put in the b series pets and some c16 derivatives. ;) and yet the c64 had to make do with some crappy software workaround and at ttl level of all things.
It's a shame that they are limiting themselves to 57600bps. If they used the User port in parallel mode, like the WIC64 does, then they could achieve speeds way beyond 57600bps. Unfortunately most hobbyists seemed to forget the user port had this capability and they just stuck to terrible bit banging KERNAL routines or other hacks like UP9600 to achieve more speed.
This project is already almost 3 years old, and the code to send and receive data at 57600 bps is even older, since it was written in 2016. We are working on a parallel modem, but it will not use the user port, instead it will be a cartridge.
I disagree with you about video streaming being beyond the capability of the c64's 1mhz CPU. Remember Nuvie movies? they are essentially just being bit-banged out of the REU memory space and in to the VIC-II. th-cam.com/video/xd2pe8TIU4U/w-d-xo.html
The difference being the REU has a DMA controller and can ship video data to memory at a theoretical 1MB/sec. While it would be entirely possible to extend this type of capability to Internet streaming with add-on hardware, it's not feasible with just the CPU and a serial interface alone. I'd be happy to see someone prove me wrong though.
Thanks @retrobits for taking the time to install and test the BBS. You've given a good overview of what RetroBBS and Retroterm can do.
Retroterm was initially developed using an RS232 interface on the user port (no UART, just using a MAX232 voltage adapter) and a serial-USB adapter (PL2303) on a PC, always at a speed of 57600 bps.
As for whether it would have been possible to have something like this in the 80s/90s, it would have been difficult, but not because of the server but because of the available telephone modems. Early versions of RetroBBS required specially generated binaries with images, 4-bit PCM audio, or programs. Before choosing to write the server in Python, I thought about doing it under MSDOS, because it was still a presentation system without a network connection. Therefore, we could have had a server with hardware similar to what a classic BBS would use.
Always happy to try out awesome new stuff for the C64! Thanks for your hard work!
Wow so amazing. As an old guy who was super involved in the BBS scene from 85 to 96, this brought back so many memories. So pleased to see that modern solutions are available for BBSing on our old machines. I still remember downloading a cracked copy of ghostbusters on my 2400 baud modem using new punter and losing all of my progress when my sister picked up the phone.
... I was a FIDO Administrator in the 80's and I'm still dreaming about the interesting times and experiences with BBS nodes before the internet overtook us. Thanks for the great video
FIDONet is still around!
@@RickTheGeek That's right, FIDO still exists, but here in Germany, it's almost non-existent. I started in Helsinki Finland in 1987 and then moved back to Germany. I was still active there until 2000, but it was already declining by then.
Here are my last 4 node numbers:
2:245/2 Werner Cappel From Homburg 1996.05.24 - 1998.04.24
2:245/6803 Werner Cappel From Homburg Saar 1998.06.12 - 1999.08.20
2:245/5500 Werner Cappel From Homburg 1998.07.03 - 1999.08.20
2:245/7000 Werner Cappel From Homburg 2000.05.12 - 2001.04.06
TH-cam really needs to mind its own business. They keep up with their stupid copyright strikes for music that is being used for demonstration purposes.
This video was awesome! A really great in-depth overview of this whole system!
"the future" of computing people could only dream of even at the machine's peak-- amazing how passionate devs squeezed stuff like youtube framecapture, game and audio streaming into that 64k of ram and 1mhz cpu ❤
PS: That "loading" of IK+ through the BBS went up 10x faster than how we used to do it turbo-less from floppy or tape 🤣thanks for the nostalgic surprise
(Also, serial-to-usb-dongles are known for compatibility issues with incorrect pinouts and signal problems all over the place-- make sure you get a good one!)
It's entirely possible! The RTS/CTS lines need to be connected properly for Retroterm to function. I was able to get a rock solid 57.6k connection using tcpser and that dongle using Striketerm to a regular telnet BBS but I guess that doesn't mean anything because of how Turbo56k relies on the flow control for everything.
@@retrobitstv Pure personal experience; used to work for a company with a PLC division (basically vending machines to factory & defense automation) and had to order bunches of models of serial converters at some point (sorry I can't remember any) since so many didn't comply to standards and basically failed to connect to devices :( major headaches for engineers once serial ports were phased out of newer model notebooks.
Guess I'm trying to say either something with onboard serial or a known quality adapter might be worth a try! 😅
Works great using the C64Net WiFi modem, and yea, the speed is unreal. When I set it to 57600 bps, ran retroterm, and typed commands, I was shocked that anything came back. Amazing stuff.
I have a Wifi modem as well, with Zimmer update, but I can't get retroterm to work... it loads up, plays the cool Wargames sounds, but I am not able to connect to any bbs. How are you setting the bps of your wifi? Through programming or at commands?
I'm in a similar situation. I get errors from some BBSs where it does not see me hitting the "Return" key to continue to connect. If I hit other keys, I get a Turbo56k error
Awesome that the BBS software can support plugins. I've been working on a way to access Twitter from the C64, and though I can get all the text data with no problem (thanks to the Python library called Twython) it was getting the image data that was holding me back. At 1200 or 2400 bps the speeds were just too slow to download and render an image, and I still had to come up with a custom terminal program to display the resulting image right on screen, rather than downloading it to disk and viewing it later. This software might make it possible to do what I want, although logging into a Twitter account might be a problem thanks to the OAuth method of using a browser to sign in, getting permissions, and getting a token that gets passed along to your application. Brilliant work none the less!
Wow what a trip, thank you for sharing! As mindblowing as this is to witness decades after owning the thing I'd still love to see how far they could push this concept for SuperCPU and REU-expansions :)
Fascinating developments! Thanks, Matt!
Glad you enjoyed it!
This is fascinating stuff. Imagine having this back in the day - it would have been incredible. The game downloading feature is like an early days Xbox Game Pass !
Awesome, Matt! Thanks for showing this off.
A bit of related trivia: the "Oral History of Brent Townshend" was recently posted by the Computer History Museum (TH-cam channel).
Brent Townshend is the person who made the breakthrough to 56kbps modems in the mid '90s. He realized that the existing assumed theoretical "speed limit" of ~35Kbps for modems on a POTS-based "last mile" could be exceeded by thinking about the problem differently. The next real limit, still constrained by Shannon Entropy but with different parameters, was ~64Kbps: the capacity of each telephone line in the digital core of the telephone network.
5:48 Interestingly, he came to invent it by thinking about how to stream digital music at higher quality.
I found this a fascinating interview (~3 hours in total). The fastest modems possible was not his only invention nor area of expertise; he shares a number of interesting life stories.
Interesting tie-in there! I must admit to not being very well-versed in how the later high speed modem protocols work and what the limitations they were up against. The last modem I ever owned was a 28.8k before heading off to college and gaining 10mbit access to an OC-3. The following summer ('96), my home town was a cablemodem test market and I never looked back.
@@retrobitstv To be even more specific, his goal was to stream high quality music over phone lines!
(I stopped at 33.6Kbpbs Supra modems, for similar reasons.)
IIRC, I had 19.2k serial in my dorm room directly to an AT&T ISN port to the campus phone system ( That I admin'ed.)
Thanks for sharing. So far with Vice, lu8fjh bbs is telling me I need a compatible terminal software, but I’m getting close. I’m gonna fire up with my c-128 and wifi modem and see if real hardware fixes it up. Thank you!!
Nevermind; you got me. I was trying to bridge thru tcpser as the GitHub said, but you got me online. Thank you!!
Nice, glad you got it working!
amazing! now if we can just get fair use on youtube, nah that's way too difficult. but streaming audio on a C64 over the internet. easy.
Wow if this was around back in the day it would have been mind blowing. Thank you so much for showing us this and I am glad you finally worked out the edit.
Thanks for the help!
To be fair, the weightlifting (decoding and converting JPEG/audio file or stream) is done on the server side by retrobbs. Nevertheless, it's amazing stuff.
Does someone know if this can run on a MiSTer with its C64 core's modem replication? That SID streaming feature would be very neat, if it could continuously stream files based on song lengths (I guess you can modify retrobbs to do that). I could imagine using the MiSTer as a SID jukebox. It probably boils down to supporting Turbo232 on the C64 core (I don't see it unfortunately), otherwise the terminal server could run on the HPS/Linux side to serve files from the SD card.
Great question, that would be a super cool use of the core! I just took a peek as well and yea, it looks like the RS232 options are limited to UP9600 as the "high speed" option. The core seems to be getting new features from time to time so hopefully in the future? I've been meaning to try out the hardware IEC connectivity but I need to build the interface first. Maybe a future episode.
There's support for HVSC style songlength files, there's also the SLIDESHOW function that sequentially streams all supported files on a given directory, unfortunatelly I forgot to add .sid in the list of supported files 😓. But that's easy to fix.
One important detail is that only single speed (1x) .sid files are supported. And some of those that use hardrestart might sound funny or completely wrong.
@@retrocomputacion haven't checked the code yet, but does the SID file gets actually "streamed" (the Python side executes the SID code and sends SID register changes over the serial connection and the C64 side just blindly writes that to the SID chip) as its being played (so essentially the same way as the PCM part works but with lot less data), or you transfer the file to the memory first and the run the player routine on the C64 itself? Mod: never mind, it's in the readme "SID music streaming: SID files are converted to a stream of SID register writes.", that's cool, so the server is basically in full control when the song change, even remote control would be possible.
@ Yeah, it uses SIDdump to get the register data. We've been thinking about some sort of frontend for the BBS that controls the C64 remotely, mostly for us to streamline development time by directly triggering new features instead of having to navigate the different BBS menus from the C64. Edit: Oops posted from wrong account :P
that 1980s Canadian NABU 8-bit computer could perhaps achieved some of the feats shown here but done so back in the day, as it was intended to be used as always connected to one's cable service.
So servers could have streamed things pretty quickly over cable to said 8-bit computer.
If this had caught on and been entirely succesful, we would have had Internet like experience about a full decade sooner
Grande Jorge Castillo
the future is 8-bit :-)
If the 64 can do all this, imagine what a similar setup for the Amiga could do.
Well, I say "THE Amiga", but unfortunately Amiga doesn't have nearly the same sort of homebrew scene that the 64 does, specifically because it wasn't a single, discrete piece of hardware but an evolving platform like x86 PCs and Macs. So there's not as much incentive to see how far you can push an A1000/A500 in particular when newer, more capable ones already exist.
That's a really interesting point I hadn't considered before!
Holy bananas this is cool!
Thanks!. Is there a way to use the WIC64 with RetroTerms?... i use both UII+ and WIC64 on the same C64 machine.
My maxi64 is collecting dust and wants to access this.
Amazing stuff!
Duuuuuude! Duuuuuuude! This is just... Duuuude!
10:21 just lookup in duckduckgo's graphics 'umbra world dennis l mammanatwan'
There are ROM specific for the 128 to host the retro term on start
Hi. My C64G configuration is: U2 (normal) and 0.13a mm firmware. The list menu modem configuration is identical. But retro term 0.14sl or 0.20 not work. Stopped after initial title and no characters if I try any commands.
115k2 or 128kbit/s are no problem at all on a 6502... as long as you use a proper uart chip... dat bit where the 6551 can't only use it's internal baud rate generator (devider) but also simply can run the provided rs232 clock / 16. whatever that external clockrate is. (as long as it's not higher than let's say, the megahertz the 65c51 in question is rated for ;) and the computer can handle the interrupts fast enough to 'pump it away to some place and do stuff with it' (should be no problem even at the c64's lousy 1mhz or so - and yes that already was lousy for 6502 standards when it was brand new. other manufacturers were happily chunking out the 6502 at 2 or 4 or higher ratings even back then ;) any other issues such as wire length etc are simply solved by not running rs232 over copper but let's say, using fiberoptic tranceivers. even the simple ones from 30 years ago go well over 5mhz. (or you simply don't use it at all and insert an 8 bit ethernet controller ;)
you know for something calling itself 'commodore business machines' tramiel completely missed the point that computers must have networking interfaces. absolute fail :P bitbanging some glorified shift register. lolol. like what the hell. they made perfectly fine 6551's themselves which they did put in the b series pets and some c16 derivatives. ;) and yet the c64 had to make do with some crappy software workaround and at ttl level of all things.
It's a shame that they are limiting themselves to 57600bps. If they used the User port in parallel mode, like the WIC64 does, then they could achieve speeds way beyond 57600bps. Unfortunately most hobbyists seemed to forget the user port had this capability and they just stuck to terrible bit banging KERNAL routines or other hacks like UP9600 to achieve more speed.
This project is already almost 3 years old, and the code to send and receive data at 57600 bps is even older, since it was written in 2016. We are working on a parallel modem, but it will not use the user port, instead it will be a cartridge.
@@retrocomputacion what you're doing is still super impressive. Didn't mean to imply that it's not amazing. Sorry
How can I get this?
so why nabu had 6000kbits/s network link
wannabe remote desktop
video streaming
law is not fair use
sincerely not yours
of course you can buffer video even over low bitrate connection, even ham radio network, for which c64 is very suited, for data transmission
But can it run Crysis?
It can outrun Crysis!
I'm sure it could livestream Crysis... This is freaking awesome!
Give 'em a couple more years
I disagree with you about video streaming being beyond the capability of the c64's 1mhz CPU. Remember Nuvie movies? they are essentially just being bit-banged out of the REU memory space and in to the VIC-II. th-cam.com/video/xd2pe8TIU4U/w-d-xo.html
The difference being the REU has a DMA controller and can ship video data to memory at a theoretical 1MB/sec. While it would be entirely possible to extend this type of capability to Internet streaming with add-on hardware, it's not feasible with just the CPU and a serial interface alone. I'd be happy to see someone prove me wrong though.