Pushing the limits of the C64 and 128!
Вставка
- Опубліковано 29 тра 2024
- High speed downloads on the Commodore 64 and 128 using period-correct hardware and software. Turbo232, REU RamDisk, bottlenecks, and benchmarks.
Channel Membership: ua-cam.com/users/retrobitstvjoin
Patreon: / retrobits
Amazon: www.amazon.com/shop/retrobits
Twitter: / retrobitstv
Thanks to our awesome Patrons for their support!!!
Kevin Gonzalez
Jon Ingersoll
John DiLiberto
John Trammell
Paraffine
Eric Stacey
Pinay Collectibles - / @pinaycollectibles3074
Josh K
Mitch Hoffman
Alex Smith
Peter (Melair)
William Sullivan
Matthew Warren
Ryan Brooks
FULLSET
Allister Fiend
Joshua C. Forest
Pierre Kressmann
RobF228
James Taylor
00:00 Introduction
00:23 Modems, the C= Userport, and RS232 speed
02:26 Turbo232 and the MOS 6551 UART
03:36 Test Setup
04:54 Bottleneck
06:12 REU and Xpander3
07:20 Configuring StrikeTerm
08:23 C64 REU Benchmarks
10:38 Configuring DesTerm128
12:04 C128 REU Benchmarks
13:51 Final Results and Conclusion
*Retro Bits earns money from Amazon and eBay Partner Links - Наука та технологія
I love that your Commodore content is this type of curiosity experiment instead of the usual repairs and game history. Very unique and fresh!
Agree with you 1000% - this was a great question that no one was asking and boy was the answer pretty darn fascinating. :)
Absolutely, still dream about my old BBS
Agreed. I'm still trying to find the best way to use the c64 with different external components.
Its amusing to consider what we accepted BITD. When I had graduated from my Westridge 6420 (300bps) my next stop was Supra2400 and an Amiga. So 2400 seemed great, until I realized files were enough bigger for the Amiga that most of the 'connection time' improvement disappeared.
At work our 9600bps modem (connected to a VAX for leased access) was the size of a PC!
Haha, exactly! Even today we haven't escaped that cycle of increasing our home bandwidth only to find the patch we need to download in order to play our game is 90GB!
Back in rhe day I connected my c64 via the user port to the parallel port on the amiga. I wrote a small machine code program on each. I could get roughly 90KiB/s this was just one way amiga -> c64. I didn't bother with error checking as the machines were sitting next to each other and every thing I sent down was error free, Used it as a Dev setup.
I was using parallel cable and PData/by deadbeat/sharks. I've used it to transfer & convert graphics from Amiga. It was quite fast.
Back in the day, if I remember correctly, I was able to get 2400bps by writing everything in assembly language, but I was never able to get higher than that. I wrote a terminal program that supported ymodem, zmodem, punter and xmodem called 'Echo Term' (wish I still has the source code.) I also use the same code to re-write the rom so that if you set a bit, it would echo all text to the serial port and screen, this made writing a BBS program using both basic and assembly so much easier (Yes I also wrote a BBS, called Echo BBS, but also long gone).. Ahh.. I miss the 6502 programming days.
I wrote a multitasking multi user BBS for the Amiga 😀 Great days!
The name of the terminal/BBS sounds awfully familiar but I really can't remember if I ever used them.
Back in the 90s, mainly for shits and giggles, my brother and I developed a rudimentary cross-development system. Writing 6502 code on an AMIGA A1200 and piping it to a C64 via the joystick ports, parallel style! As I recall it was lighting fast, we just kept cranking up the data rate until it became flaky. It was a simple point to point cable too, no capacitors or fancy shielding. So it possibly could’ve been even faster.
That's awesome. I have no idea how fast the joystick port cab be polled or what the data rate one could achieve would be but I love to hear about hacks like this from back in the day. Thanks for sharing!
The fact that C64s are still working today is a tribute to their build quality and engineering.
Most hardware from back then seems to still work fine. I think everything was made better. Also less demand on the components.
This proves that my entry into long-distance data transmission at 300 bps was really slow. The floppy was not the bottleneck. Of course, I didn't have an REU. Thanks for the great video. You answered all the questions I had in 1984.
I had totally forgotten about disk couriers on the old C=64 scene.
@8:14 AHHHH! I was losing my mind trying to figure out how to use the RAM disk.
I spent a bunch of time figuring that out a few years ago but had totally forgotten by the time I got around to making this video :)
I like this channel because it tackles the questions that I lay awake pondering at night
Nice job, Matt. I had no idea it was possible to use some C64/128 cartridges simultaneously!
Thanks! It wasn't commonly done, but there are some combinations that just make sense. Other hardware add-ons featured a pass-through that let you daisy chain additional carts as well, so those were doing the same thing in effect.
I think the last modem I had been using on my C-128 to connect to my university before moving to PC was an external modem at maybe 2400.
An excellent, EXCELLENT scientific test well presented. Instant subscription, can't wait to see what else you have!
Thanks! Glad you enjoyed it and welcome aboard!
Very nice video. It is interesting how much moving to an REU speeds up the downloading process. If one was transferring a lot of files back in the day a 128 would have been a serious benefit.
Heh, it was a Taiho 300 baud modem for me on my C64, I was too skint for a 1200 baud modem, though I was often impatient as I could read text faster then 300 baud could transmit and display for me. As for X/Ymodem data transfer, a single disc would take overnight to transfer. In the Amiga days, I moved up to a whopping 2400bps modem, swag city!
My first modem was an external 2400 I got for my birthday and used on the family Apple //c. When I later bought a C64 of my own, it wouldn't work on that since it had no RS232 interface :( I had to borrow an old 1200 to get online which was so slow after using the 2400 for a year or so!
@@retrobitstv Haha! Good times, eh? It's so fascinating when you look at the two main rivals in Apple and Commodore at that time (Sorry Atari 8-bit fans! I loved them too but..) and the way they were designed in terms of data transfer. Commodore really dropped the ball there with both a crappy UART and lack of in-built RS232 compatibility at, even though it was 5 years newer then the baseline Apple 2! And then there is the insanely slow transfer rate from the 1541 FDD that had to be addressed by 3rd parties in the form of cartridges like the Epyx FastLoad or even in games utilizing custom fast-loading software. (Electronic Arts were the kings of this, under the Trip Hawkins years.) It's not surprising that the C64 was almost ignored as a business computer compared to the Apple 2 line.
I did a comparison between Link232, U1541+, and Wimodem a while back on lemon64.
38400 Baud
Null Modem (Link232-Wifi-With Serial Converter instead of Zimodem Module)
(SD2IEC with Jiffydos)
Ymodem Batch 170.8 KB, 2:54 min = 1004 bytes/sec
Xmodem 170.8 KB, 3:09 min = 925 bytes/sec
(REU) (Super 1750 Clone)
Ymodem Batch 170.8 KB, 1:42 min = 1.7 KB/sec
Xmodem 170.8 KB, 1:54 min = 1.5 KB/sec
Link232-Wifi
(SD2IEC with Jiffydos)
Ymodem Batch 170.8 KB, 3:41 min = 791 bytes/sec
Xmodem 170.8 KB, 2:30 min = 1.1 KB/sec
(REU) (Super 1750 Clone)
Ymodem Batch 170.8 KB, 2:23 min = 1.2 KB/sec
Xmodem 170.8 KB, 2:06 min = 1.4 KB/sec
Ultimate II+
(SD2IEC with Jiffydos)
Ymodem Batch 170.8 KB, 2:56 min = 993 bytes/sec
Xmodem 170.8 KB, 3:11 min = 915 bytes/sec
REU (Ultimate II+)
Ymodem Batch 170.8 KB, 1:44 min = 1.6 KB/sec
Xmodem 170.8 KB, 2:03 min = 1.4 KB/sec
Wimodem at 9600 Baud.
(REU) (Super 1750 Clone)
Ymodem Batch Wouldn't Complete Transfer. (Download Aborted after transfer)
But Shows completed file on the REU
Xmodem 170.8 KB, 4:42 min = 620 bytes/sec
C128 2Mhz, Desterm 3.02
Null Modem 38.4 (REU) (Super 1750 Clone)
Xmodem (170.8 KB, 1:12 min = 2.4 KB/sec)
Xmodem1K (170.8 KB, 0:55 min = 3.1 KB/sec)
Ymodem (170.8 KB, 0:54 min = 3.2 KB/sec)
Zmodem (170.8 KB, 0:52 min = 3.3 KB/sec)
Link232-Wifi 38.4 (REU) (Super 1750 Clone)
Xmodem (170.8 KB, 1:19 min = 2.2 KB/sec)
Xmodem1K (170.8 KB, 1:19 min = 2.2 KB/sec)
Ymodem (170.8 KB, 1:20 min = 2.1 KB/sec)
Zmodem (170.8 KB, 0:53 min = 3.2 KB/sec)
Link232-Wifi 38.4 SD2IEC Jiffydos
Zmodem (170.8 KB, 1:43 min = 1.7 KB/sec)
I wonder what's different about the Link232 that allows you to get much higher speeds than the Turbo232 I'm using given that we're both using DesTerm and an REU. You were getting faster transfers at 38.4k than I was at 57.6k!
6:55 These shots make everything look wobbly due to software image stabilization, because it can't change parallaxe/perspective. I'd recommend keeping the camera static with close-ups. You're just exchanging shaky for wobbly.
Yeah I've been messing around with stablization in post and it's definitely got some drawbacks. Certainly no substitute for a proper camera stabilizer/steadicam. Something to look into getting.
@@retrobitstv It's perfectly fine if you keep these shots from a tripod, and just zoom in.
The other options are cameras/lenses with optical image stabilization, generally using a heavier camera (I actually suspect that you are using a phone to record your footage), or using a slider.
But I don't think that making your shots more "cinematic" adds much. I enjoy your content for the content, and not for the special effects.
Cool, thanks for making this, it was interesting!
Paused at 0:19
Running an unlisted Color64 BBS for a few... A C64/Self-Powered Cart Port expander/Hacked REU with piggybacked memory/Swiftlink RS-232 Cart(UART)RS-232 interface with up to 38.400 bps/BOCA Modem 9600 v.42bis
So.... 9600baud if I remember correctly
Wow! DesTERM! Loved that!
And here I thought the best I could get was 9600. Learned something new.
+1
I ran C-Net 128 on a 20MB Lt. Kernal back in the day. A few different BBSes on a 64 before that (All American BBS, DBBS, maybe I forgot one other...) Good times :)
Love it, fantastic vid. Thanks Matt.
Glad you enjoyed it!
never try this machine before but i believe this machine is standing beside me in the past in my uncle father in law house in year 2000
Not period standard but the WiC64 can download from the Internet at blazing speeds (via the UserPort) eg. 39k in 4.7 seconds!
It's not Hayes compatible though.
Very interisting good work :)
I think that is 1200 baud not 1200 bps. 1200 baud IS ~9600 bps. If I remember correctly, Commodore modems were always rated in baud which is characters/symbols (one character/symbol = 8 bits in this case) per second. The first VICMODEM was 300 baud (2400 bps), I had one of those. With 4 bit symbols or characters like sending hexadecimal code the baud would be different. A modem that transmit 4-bit symbols as fast as the VICMODEM would be 600 baud. Anyway, that is just my 2 cents. If I am wrong, I would appreciate any comments/explanations. I was always under the impression that the VICMODEM was transmitting 8 bits per baud. Older modems were transmitting at 4 bits per baud and really, really, really old modems were the ones that transmit at 1 bit per baud. Guess I am wrong.
Looks like the VICMODEM WAS one of those really really old modems.
Hi, Very well done and presented.
There is some maths on transfer speeds and what type of protocol to use, it is based on probability.
Eg the more stable the connection the larger the block size before crc checking and a resent packet if there is a error
However lets say you send 1024 bytes ad there is a error, you need to resend the entire lit again
If you done it in say 256 byte streams, mathematically the 1 byte error will allow 3 blocks to go through and only 1 block to be resent - then take into account crc check and compare, then request to send another block in cpu cycles
I cant recall if X or Y modem protocol can change the block size on the fly depending on error count and block size
I could not find the buffer size on the mos 6551 - as most pc owners in the day were aware the original ibm uart used was a single bit 8250 and this was maxed at 9600 as far as reliability before missed characters / errors.
The replacement 16550 had a 16 byte buffer that ensured no dropped or corrupt character translation
I am not sure it was not really the uart hardware that solved the problem but the combination of the increase uart buffer size and that fact helped the pc in not losing control of the data stream when the pc muti task and moved to something else in the IRQ Control eg screen or keyboard entry
Thanks! Appreciate the insight as well.
There was an Xmodem-1K protocol and Zmodem could apparently use an 8K block size and also an arbitrary subpacket length, according to the 'sz' man page at least:
"Use ZMODEM sub-packets of length N. A larger N (32
I notice that the terminal software you use on the c64 redraws the screen for each block sent however DesTerm on the c128 has no screen output. That’s steals valuable clock cycles and will affect the transfer speed.
Well yes and no. It's updating the "total bytes received" (which has some cost), and it's using some screen space as the receive buffer (which is basically no cost). The bigger impact on the CPU is probably the fact that the VIC is operating at all, that, as you say, does steal cycles from the CPU. (Matt did note that the C64 could go faster by blaning the screen...)
That's one of the big differences compared to running the C-128 in 80-column mode at 1MHz (test #6): The VIC chip isn't stealing CPU cycles any more. The 80 column display on the C128 has its own memory and operates independently of the CPU, except when you're actually changing screen content, which is slow. Like Striketerm (the C64 program), DesTerm does update the screen with some basic statistics (total bytes received, time elapsed etc.) but it doesn't use display memory as a data buffer because accessing VDC display memory is more complicated than just writing to a memory address... So between tests 5 and 6 the real difference we're seeing is just the fact that the VIC isn't stealing CPU cycles.
Answering questions nobody is asking! Ha! That was such a fantastic line, you gave me a Laugh Out Loud moment!
You did bring up an interesting question that nobody else has asked. Is it possible to make a kind of "Super" C64 that has 512Bb+ of RAM, network connectivity, JiffyDOS or something similar and have a near modern usability experience? I wonder...
The Ultimate II cartridge comes pretty close to that. It only provides 128MB of RAM (and I think it maybe only can expose 16MB to the C64 as a REU) but it has a net port and a drive emulator and can act as a drive accelerator cartridge, too.
Yeah, I was just about to ask about those early hard disks.
I recently played around with retroterm, which does 57.6kbps over the **user port** (blanking the screen) and a custom protocol. It does transfers to c64 ram only, but still counts. :)
I agree, it counts and it's really impressive! In addition to RetroTerm, there's also V1541 (commodoreserver.com) that does 38400 over the userport with screen blanking. I was able to get that working with my WiModem successfully, to some degree at least.
WOW another GREAT video! Do you know if when I now use my UII+ does it have the U.A.R.T. function you spoke of when I use it to go onto BBSs? You spoke of my plus/4 have a 6551. Is that the reason I can use my 1551 drive on the 264 line at the much fast data transfer rate? (I wonder if the 1551 is so named because of the 6551?) I never used DesTerm128 in the 80's when I had my 1st C128DCR but it is the only one I use now on my C128DCR that I got in September 2021. WOW 48 seconds vs 30 minutes!
Thanks! The UII+ emulates a 6551-based SwiftLink, which is the predecessor to the Turbo232 I used in this test. However, the emulated SwiftLink is tied to the network connection and allows for "dialing" out to telnet BBSes and the like and doesn't provide an actual RS232 serial interface.
The Plus/4 contains a 6551, but I have yet to figure out how to take advantage of the increased port speeds on it with the peripherals I have on hand. Something for a future episode perhaps?
To the best of my knowledge, the 1551 cartridge implements a parallel interface and wouldn't use the 6551 which is meant for serial communications. I do not have a 1551 for, as you know, they are hard to come by and expensive!
Excellent video again Matt!
I'm not familiar with DesTerm 128. Can it be used with the video output from the C128's VDC? That would be the equivalent to turning the screen off on a C64 so the VIC II chip doesn't steal cpu cycles for dram access... In theory that would make it possible to achieve higher transfer speeds...
He showed it running in 80 column mode, so yes.
Yep, DesTerm only works in 80 column mode as far as I am aware.
That's state of the UART technology!
Haha, groan :P
How come you used blue and purple in crossed color order on your bar graph?
I can't say for sure how fast it was actually going, but I was using a Hayes 14.4kbps modem on my 128D back in the early 90's.
Nice. I only had a 2400 on my 128, connected to the userport with an RS232 interface that was hand-made by a friend in Jr high school Tetsujin (@scopeeyevideo). To this day I'm still not sure how he made it.
@@retrobitstv Interesting... I don't remember building that. I did own some user port connectors and did some simple interface circuits but I don't remember anything as complex or useful as an RS232 level shifter. (Though of course RS232 level shifters can be pretty simple if you don't need them to be exactly in spec...) I'm really curious now.
On my C128 stack toward the end I think I was running a 2400 baud RS232 modem as well. I don't remember the brand or model but it was in a laughably cheap-feeling enclosure with the serial connector dangling out on a ribbon cable. I don't remember what I used for a user port-to-RS232 adaptor. I think I bought my adaptor.
If you really had a handmade adaptor, maybe my dad made it. It's not impossible I would have built a thing but I think he would have had plenty of interest and knowledge to make something like that.
@@tetsujin_144 I am sure it came from you (or your dad). It was built on a standard brown/orange development board with everything exposed including a number of pretty large (finger-width) capacitors. I don't recall how the edge connector slot was attached but it was very home made looking. Worked great for my generic 2400 RS232 modem that I had previously been using on the Apple //c though!
u rock dude.
I love Applied Science!
If you had error correction you could have tried Y-Modem G
Now try an Atari 130XE using a 56k US Robotics Modem through an 850 interface using Zmodem terminal and either a ram disk or a 1050 drive with a US Doubler upgrade. These were all available back in the day and worked beautifully. High speed I/O from end to end.
The thing is, it's far faster to just use the EtherNet cartridge or the 1581 3.5" floppy drive to transfer files to and from.
I had a vic 20 in jr high... lol
Does using the Xpander nullify this test, or was there a version available back in the 80s?
Great question. The xpander3 is a modern product but many such devices were available back in the machine's heyday. Here are a few examples ar.c64.org/wiki/Category:Port_Expanders
7:59 - "That's six times more space than a 1541"
170K * 6 = 1020K
Also, Matt, you want a New Year's card? I'm sending out New Year's cards. They're not late! Who told you that?
I was always bad at math :)
Haha, I think it's still technically the new year until Feb 1. Shoot me an email if you're still sending them out!
@@retrobitstv I don't know your email...
@@tetsujin_144 Ah, somehow I overlooked that fact. It's [my first name, short]@[my last name].net
I'd like to see this tested with a 128+1571 and/or JiffyDos, and then with an ethernet interface cartridge to compare.
I didn't test a 1571 or 1581, but I did measure an SD2IEC with JiffyDOS several years ago under different test conditions. I found that it could achieve transfer rates up to 12kbit/sec on a C128 over the IEC interface. The REU was still faster at 21kbit/sec at the same serial port speed (57600 bps), but this does illustrate how much of the IEC bottleneck can be removed.
So why are you using Striketerm, which isn't period-correct (this version that you have, at least), if you have Novaterm?
It has some nice quality of life enhancements but it still uses the loadable modules directly from NovaTerm (in fact they are interchangeable) so I felt like it wasn't really cheating.
What is the fastest a C64 can transfer data from internal RAM to the RAM of the 1541 and 1581?
I imagine it's "not much faster" than data can be written a disk since the 1541 was designed to (and can, with upgrades) read/write 5x faster than it does out-of-the-box but the IEC bus is the limiting factor. The 1541 only has 2KB of RAM, but that can be upgraded.
With some TTL Logic and Buffer Chips a direct parallel-connection between two C64/128 should be at least at 250kBit/s. But you'd need to write your own software for it.
Why is that device-7 trick undocced?
Why were 14.4k, 28.8k and 33.6k speeds omitted from this test? 14.4k, 28.8k and 33.6k modems were all very popular, but I think I've maybe seen one 19.2k modem and don't think I've ever seen a 38.4k modem.
I find it interesting that you we able to get a reliable transfer at 29,127bps. The MOS 6551 is only rated for transfer speeds up to 19,200. Underrating performance by over 1/3 seems excessively cautious. Maybe the performance varied widely from chip to chip, so they played it safe. It would be interesting to see if a different MOS 6551 would have yielded very different results.
14.4k, 28.8k, and 33.6k are omitted because he's looking for the maximum achievable serial I/O performance. If he can do better than 14.4k using a 57.6k serial link, then there's no need to test 14.4k because it won't be faster.
As for the serial port speed... I'm not sure what the practical limits were on 1980s versions of the 6551, but the chip did have a 115200bps setting (setting bits 0-3 on the control register to 0 disables the clock divider, producing a serial port bitrate of 1/16 of the input clock speed) Whether that mode was reliable on the 6551 back then, I don't really know.
The serial card Matt is using is based on an enhanced version of a serial card that came out in 1990. The 1990 version (Swiftlink 232) had a 6551 with double the normal clock speed (3.68MHz instead of the usual 1.84MHz), so it could produce speeds ranging from 100-38400bps (instead of the usual 50-19200bps), with a "no-divider" speed of 230400bps. The enhanced version (Turbo232) came out in 1997, it added its own clock divider to allow the 6551 (at 3.68MHz) to achieve 57600bps and 115200bps.
So I'm not sure if any hardware was on the market in the 1980s that would have allowed a Commodore to achieve these kinds of serial port speeds... By 1990 there was the Swiftlink that could do 38400 (or 230k with the divider off) - it was a commercial product (at a time when the Commodore was still pretty commercially viable as a home computing platform), that's no guarantee it was reliable (being "2x overclocked"), of course...
Ahh, I failed to make note that the Turbo232 came out so late and it was only the SwiftLink that was available earlier. There's a good read about the development of the latter (really the former, chronologically!) here: www.commodoreserver.com/BlogEntryView.asp?EID=FA5AE758474345A9A0A7208C7F408538 The MOS 6551 itself was released some time in the 70's since it was used in the PET but a cursory Google search didn't indicate what year.
The max speed of the C64 has always been "too slow" :-) still, I do much more often wait longer for something to finish on a PC
Would the to see if you used a 1571 in this test
You can link the 2 computers together to make a multiplayer game.
There are a few. I remember playing Modem Wars with my friends on my 64 back in the day.
How come you could go to 57.6K on this rather than topping out at 56K like we would on a more modern computer with dial-up (yes, I know this isn't dial-up, but still wondering where this number came from)?
56K modem speed is the product of a signaling standard (V.90) meant to provide data transmission over a phone line. Its speed was constrained by the bandwidth that could be reliably achieved over the phone network.
But the speed of a computer's serial port is determined by the serial port's clock, and a clock divider built into the serial I/O chip: Typically this would be a 1.8432 MHz clock, and so if you divide it by 4 you get 57600 Hz. This was the lowest commonly-achievable serial port speed that was faster than a 56K modem. All the typical serial port speeds are the result of different divisions of the serial port's clock.
@@tetsujin_144: Huhh, interesting. OK, thanks! Now I've also always kind of wondered what those V numbers mean. I'm pretty sure that "Google is my friend" in this case, but hey, as long as we're already in this conversation and it seems to be a good one, why don't I go ahead and just ask you what those numbers mean?
@@HelloKittyFanMan That is cool as far as I'm concerned. Modem standards are determined by a group called the ITU-T, they've made a lot of different standards and use different prefix letters for different groups of standards (like H.264 video encoding). V is the prefix they use for standards related to data over telephone networks, so all the different modem standards (as well as other stuff like Fax machines, the RS-232 standard, etc.) all have V. standards. More recently (since the telephone network as it existed in the 1980s/1990s is becoming increasingly obsolete and irrelevant) some V. standards actually go the other way, standards for voice or teleconferencing over data networks.
Can you do something like this with an Atari 800XL/130XE? Sorry, Atari person here. Never had a Commodore.
I have an 800XL with a 1050 drive but no 850 interface or RAM disk. I'll keep an eye out on eBay though!
@@retrobitstv Thanks, I'm looking for a 130XE but prices are outrageous and a lot are PAL versions. I do have a 520 ST though with 1 Mb upgrade. I just need to fix the floppy drives power supply. The fuse blew and it's soldered in.
9600 Baud
"the average transfer rate over a 1200 baud connection was 672 bps" Yeah, that's definitely not right. The optimal practical transfer rate over an error-free line under those conditions should be around *960 bps.* This may be because you're using Ymodem, which is pretty crappy over high-latency links, and the serial->modem->phone->modem->serial link probably has some decent latency to it. You'd probably get much better results with something like Zmodem instead.
And if Zmodem was less reliable than Ymodem, there is something wrong with your Zmodem setup. Zmodem is pretty much better in every way than Ymodem, including the same or better error handling and correction, and NAK-based streaming which can result in much higher throughput on higher-latency connections. Also, since the latency effects also become a larger percentage of the total the higher the bitrate is, you might also have gotten better performance out of the very high port speeds if you had been using (a correctly functioning) Zmodem instead of Ymodem as well.
I know for sure a few years ago I had no problem with Zmodem transfers with this setup. More recently, it just won't work no matter what terminal software I try in either 64 or 128 mode. In the past I've connected via wifi modem to my local linux server and used 'sz' without an issue. Even the laptop with TeraTerm connected directly failed when using Zmodem. I spent many hours trying to figure out why it would no longer work and finally resorted to Ymodem which worked completely fine. The only thing I could come up with was a cable problem preventing flow control from working properly, but I tried multiple cables as well!
OK, but your cartridge port splitter isn't period-correct!
Mine is a modern port expander that you can still purchase today but many such devices existed during the c64's heyday. ar.c64.org/wiki/Category:Port_Expanders
So why not learn how to set up a program that you could get to blank the screen?
There are a few already, Virtual 1541 (commodoreserver.com) and RetroTerm come to mind. However they use their own proprietary method for data transfer, not standard protocols like X/Y/Zmodem that can be measured for an apples-to-apples comparison.
'promo sm'
"Answering vintage computing questions nobody was asking" is essentially the raison d'etre of my @theoldskoolpc channel :-)
Hey, if we don't ask these important questions, who will?