Saturday, 30 April 2022

Battledudes

Now that surviv.io from browser doesn't work well (can rarely get in a game) I went to play Battledudes.io instead, another browser-based 2D top-down shooting game.

The 'dudes seems to owe a lot to surviv.io. The major difference is that the players respawn to the same game, whereas if you die in surviv you will have to enter a new game. Secondly, nearly all game modes are 2-team modes and there are strictly speaking no squad modes.

Another difference is that there is no diminishing play area in Battledudes. Altogether the game is modeled more on old-fashioned deathmatches rather than the PUBG/Fortnite mold. There are modes such as Team Deathmatch, Capture the Flag, Control Points, Hardpoint and so on.

The respawning system also means there's no real inventory. Kill someone and their stuff won't be visible on the ground. Instead there's a loadout which always includes handgun, main weapon, secondary weapon, item and two different perks. You get more options through leveling up.

If you get wounded, soon after the health will replenish. Timing your reloads and healing pauses is integral to mastering the game. There are also perks that affect these elements.

The nice thing here is that nobody can find a super-weapon or super-armor. In Surviv this means that good players tended to be doubly good: both in skills and knowing how to get better weapons. Here if your loadout is crap you can continue adjusting it. That's not to say there aren't some combinations that may be better than others.

My current go-to perks are kevlar armor and +12% damage. This usually ensures that if two lamers with comparable weapons try to brute force it out, I'll win unless they have the same perks. I've also tried additional speed and visibility range, the latter can be useful for open areas. Some of the pro players seem to favor dodge and added speed, and this can indeed change the 1 vs. 1 situations.

Interestingly, everything on the battlefield can be destroyed. This doesn't reveal items but adds character to the battles and also important route-creation at some situations.

A major addition compared to surviv.io are the vehicles, such as jeeps, ATVs and tanks. These make for more nuanced situations, as players can move other players quickly over the map. I'm somewhat annoyed that the vehicles run over water just as simply as over any other terrain.

The bazooka is the handy secondary weapon for destroying vehicles. Grenades may be more useful in game modes that don't have the vehicles. They are effective in games where teams guard small areas, and in Payload it's crucial.

Despite vehicles and some added variety I could still say 'dudes is simpler game than surviv.io. The surviv.io 50 vs. 50 battles can be glorious, if there are enough players that is. The map items, bunkers and other special occasions add flavor to the game. The no-respawn rule gives more tension to the game.

When I started, Battledudes was not yet riddled with too-good players or cheaters. Now it looks unlikely I could win any solo gamemodes. As most of the gameplay forms are teams this aspect gets evened out. But team victories and losses can mean less and can often be attributed to luck.

Sometimes good players can be identified by the skin they are wearing, but not always. (Skins are bought with the in-game currencies) As soon as I donned the ninja costume the games seemed to become more difficult! It may be beneficial to look like more of a noob than you actually are.

What I've liked here is that suppressive fire works rather well; shooting at a doorway or at a corner often has a clear preventive effect. In Surviv.io, I've felt there are less opportunities for this even in 50v50, as well-equipped and bold opponents can usually work around the bullet hail.

I often use the mini-map to direct fire at off-screen targets. In other cases supporting crossfire or from flank towards the guessed enemy direction can be helpful. In collective battles this can contribute, even if you can't see the enemy! Whether mini-maps are good for gameplay is another matter.

The idea of suppression and other nuances are often lost to the inexperienced players who just want to be that individualistic "pro", swirling around enemies and going for the maximum kills and a good kill/death ratio. Having a real "pro" in your team is of course desirable.

Those who play as coordinated teams may overcome numbers of poor opponents by working tightly together and using varied weapons. Against such a force, there's usually nothing to be done and the battle will be lost.

It can then feel that winning and losing is matter of who is on-line, but on some rare occasions it can give a satisfying feeling that my actions were important in settling the outcome. In Capture the Flag this can be quite crucial.

Lot of players insist on voting for the rather boring solo modes Gun Game and Free for All. The somewhat flawed Payload is probably the most interesting mode, but it rarely gets voted. 

In Payload, one team has to push a cart on rails that zig-zags across the map to a deployment location. Get it there within the time limit and it's victory, otherwise not.

If there's one friendly team member near the cart and no enemies inside this zone, the cart will move forward. At times I've felt it is impossible to prevent the deployment from happening, but it has been done. A play style has evolved where teams lob grenades to the cart area and others try to kill the cart pushers from distance.

The dynamic is that being too close to the cart is harmful, but staying too far away the teams can't move towards their goal. Sadly, putting obstacles in front of the cart is a waste of time, the cart doesn't really care.

All in all I've felt Battledudes to be quite a robust online game. The developers appear to have not ruined it with superfluous stuff or season frivolities. Bug fixes have addressed relevant bugs. For instance, there were means to exploit the vehicles for "infinite" speed but this was soon repaired.

It remains to be seen how long Battledudes will be my go-to game for a few minutes of mindless instant gratification, but as long as surviv.io doesn't work properly and there are no better alternatives so be it.

Addendum: 14th of May.

The 7th season brought in the game mode Upload, where the team who gets to carry the flag longest, wins. This does move the dynamic of the battle around, however exploiting edges and corners of the map isn't that interesting.

There's a new device called the Trophy System, which creates a grenade-repelling field around the device. In theory this could adjust the balance in game modes where grenade-lobbing has become the go-to strategy, but it yet remains to be seen how useful it is.

I've also noted it's not always possible to drive a car, is it so that the flag-bearer can no longer use the vehicles?

I also saw a few glitches introduced, the payload destination graphic has been messed up.

Oh, and the game mode voting system has been changed so you don't see who votes what until near the end. But I'm thinking this just means I have to suffer the crap solo modes more often.

Sunday, 27 March 2022

Zeeclo will tear us apart

(...or the other way round really, but anyway)

The weather is favorable for some scooting again, even if doesn't look like that from the photo.

But I modded the electric kickbike a little, it's missing a piece in the above image.

I already previously wrote about my intention to remove the wooden deck and replace the grip tape.

This is partly because I felt there's 0.8cm of extra height to an already high deck, and secondly I didn't like it aesthetically.

So here are some notes of this project. After ordering suitable grip tapes (2 just in case!) I could start working.

Removing parts

The old grip tape came off quite easily from the corners. Then I removed the bolts with 4M Allen/hex key.

But because the deck wouldn't come off I removed the entire grip tape in case there might be more bolts. This was also very easy to do, so replacing just the tape would have been quite simple.

As a side note it can be seen the surface can get rather dirty easily.

Because I couldn't find any more bolts I deduced the wooden deck has been glued in after all.

I begun pulling out the deck, prying it up from the corners using a strong knife. Sadly I could not be patient enough and the deck was split in half from the middle. Well, it came off easily enough after that! 

It would have been better to pull it up from the ends rather than from the corners.

Yet I'm not too disturbed as it has been my intention never to re-attach the wooden deck anyway.

Well, what was then revealed is the real surface of the chassis, metal painted black. The remaining glue needed to be removed, which was the bigger chore here. The excess glue here has a filmic and paper-like quality, and wouldn't budge easily.

I began removing it carefully with a sharp blade, and although this was doable, it turned out to be far too slow. Kicking the glue around with the edge of a wooden block proved to be more useful.

The small amounts of remaining glue could then be removed using acetone, wiping the melting gunk out with a piece of cloth. I really had to lather the surface constantly with acetone to make this work.

Removing the glue altogether took more than an hour.

Now that I'm looking at the results, I think the wooden deck wasn't there for nothing.

Firstly it is meant to cover all the bolts from moisture and rain, not just the ones used for the deck but the protruding ones at the front and back. It obviously protects the metal surface too.

Secondly the piece also extends the length of the usable deck with a few centimeters, because the bolts are no longer in the way.

Thirdly I guess it gives a nice and even surface for the grip tape.

Interestingly, there are more bolts here at the front than in the comparable T4 (Maxwheel etc.) and the Zeeclo U322 itself, which doesn't have the wooden deck to begin with.

The not-to-scale image above shows some of the parts involved here. The structures holding the front and the real wheel are welded into this inner chassis structure. Here the "inner chassis" has been imagined as somewhat pulled out from the outer case.

I became curious about the metal cover. It appears that the "wings" are also part of the cover and not removable plastic additions such as the lights at each corner.

I had a notion that the cover and the wings could be removed, but now I realised the metal case is a kind of outer "pipe" to which the inner structure is apparently slid into.

It might be interesting to try to dismantle the whole thing, if it's even possible. As it appears it is not all welded shut, it ought to be doable.

However, as I understand it, removing the outer case would result in something that doesn't stay in shape, so I'm not too keen to do that now.


Attaching the tape

The surface isn't exactly even, as there are two inclinations, possibly for the grip tape strips that are seen in other scooters. For the grip alone this might be enough here, but I had to take into account protecting the metal surface in the middle. Sand particles under my boots would easily scrape the surface.

I measured the free area and cut a precise 490x129mm piece of the tape.

With a skateboard, you'd position the tape over the deck, process and cut the remainder. Here the piece was smaller, and positioning it exactly was the hardest part. After that there isn't anything to it, just patted it some.

For now I took the lazy option and did not fill the additional bolt holes (the ones holding the wooden deck in place) but simply covered them with the grip tape. I can see myself doing this better at some later time.

For example this piece does not prevent the rest of the surface from getting damaged, like the wooden deck would have done. Later, the piece might be roughly shaped like a plus sign. But the main point here is to test the grip quality.

All in all, although I understand the protective idea of the wooden deck, this looks better to me and does not seem to compromise grip quality. And it is 8mm lower!

I drove about 10km and didn't feel there was anything wrong with it, my feet fit on the deck just as well as before really. The unprotected parts did become somewhat dirty though, the paint surface will probably be scratched through eventually.

Sunday, 13 March 2022

Chromecast


I don't usually get the latest TV/hi-fi tech. On a whim I bought the Jaffa-cake sized Chromecast dongle, stuck it into the ~2008 Philips TV set HDMI port and had a look. After running the Google Home app on my phone I could teach it the home network and then start "casting".

Even now I was mostly interested in seeing if this could cast the Linux desktop, and if it wouldn't, then I'd still have my Android phone for casting videos. Then it became the current TV watching solution.

Desktop 

But about that desktop casting. On Linux Mint 19.3, with Chromium browser I found no problem. I could also mirror the desktop or the browser window. This is very laggy (at least half a second) so it could work for showing slides or photos.

So I quickly learned the casting is really only supposed to be done with the "cast" icon and the desktop/browser casting is just a tiny added extra. Youtube obviously works. Yle Areena, the national streaming service, could cast a film and it looked rather fine. I didn't see any problem arising from the Linux environment here.

Outside the browser, VLC does cast too, but there's a problem with the subtitles and there are apparently no really good solutions to it. The only 100% working approach is "burn the titles prior to watching".


TV streaming

Ever since the TV transmissions turned digital (analog ended in 2007) I've been somewhat disappointed with upgrades and hopping between services, not that I bothered to do that really. The crappy bundle tied with the ISP had kept me somewhat happy, thinking this was the only way to meaningfully watch something on that old TV set.

But now the old me finally saw that channels such as Netflix, HBO, Disney+, Amazon Prime, Ruutu, Yle Areena etc. are also apps in the appstore, tied to a monthly subscription. Probably something like Apple TV+ isn't on a Google service, but otherwise the coverage on the Samsung phone looked quite good.

So I could subscribe to one and pick another when something interesting pops up. But it might also be I'm too lazy to unsubscribe the channels (which is what the companies hope for I guess).


Watching shows is easier than having to fiddle with the digi-receiver which even tended to crash-mid show if it hadn't been rebooted lately. And although I still need the TV remote control, the phone now becomes the remote, too.

It can be slightly annoying that different services use slightly different conventions.

Netflix appears to work flawlessly, and casting just the interface itself provides some useful information besides just the logo. Ok, so it might just be an ad for another show, but anyway. HBO Max exactly only shows the service logo on TV screen. With HBO Max I had to find where to adjust the subtitles, and when I got them to work the 'titles were of the somewhat ugly white-on-black box variety.

With HBO Max there might have been a tiny hiccup in the streaming too, something I never saw with the Netflix app. Could be the Max has more bits in the stream by default than the lowly Netflix subscription, however I turned off the phone energy saving and never saw the hiccup again. Occasionally, after viewing a show, the HBO app says it is "offline". Fortunately this did not affect watching the stream in any way.

Sunday, 13 February 2022

Ice and sleet


There was a short window of time with dry roads, before new snow. So I took the opportunity and rode the Fenix outside.

Wind and wetness worried me more than the temperature (+2°C) and the occasional crunchy patch of icy snow.


With the lobster-like skiing(?) gloves I didn't feel any cold in my fingers. I've driven in a -6 weather with these, and the cold does eventually get through after 15-20 minutes. 

I felt the ice and packed-snow areas are driveable, but they also have thickness and hitting the snow sheets in a wrong angle could result in a wobble.



Thursday, 3 February 2022

Ball: The System


I read the 2020 book The System. Who owns the internet, and how it owns us from James Ball.

Instead of explaining the technical workings of the internet deeply, or dwelling too much on the invention of computer networks, Ball instead presents a loosely chronological cross-section of the forces that, in different times, molded the internet as we know it.

The focus is in the who owns the internet, and how it owns us part, identifying challenges in various areas regarding loss of privacy, concentration of wealth, aggressive advertising, eradication of journalistic quality, threats to net neutrality...

I'm making shortcuts by not addressing the origins of these varying opinions, and for most part simply go with "Ball says", the author being responsible for the book as the curator and presenter of these viewpoints.

The story so far

Ball figures the early era (about 30 years) was when most of the decisive technologies and protocols were set, but were in no way envisioned for a multi-billion user, global internet. The stage is set for an environment that is used by large masses of people, having implications for ethics and security both in national and global scale.

With the invention of the World Wide Web the commercialization of internet began in earnest, leading towards the original dotcom boom and crash. Venture capitalist funding has served as the driving force of the internet for the past 20 years. Seeking to make ever larger profits through new companies, the bigger companies then foster a new generation of influential startups. The new smaller companies will be hungry to demonstrate their viability for the next round of funding.

Pretty much the only thing that can be monetized is a large user base and increasing it, this is what they will try to gather, at first providing benefits "for free" to the users. This has had also social and political consequences that took the company founders by surprise. Whereas there are good grounds for claiming the internet network itself is a neutral utility, sometimes the providers of the "platform internet", such as Facebook, have argued similarly when their service has helped sway public opinion for the worse.

The internet never was the same as WWW, but arguably it's the surface layer of things that make it a force for people. But even the "WWW era" may eventually be a thing in the past, as smartphone app ecosystems have proven. Regulatory approaches lag behind, and may not even always touch what is happening in the ever-changing app world. Movements are born in channels like Facebook, Youtube, Twitter, Twitch and so on. The mobile phones are loaded with apps and services that utilize the internet connection in different ways. In some countries, the ISPs don't sell so much "internet" but "facebook".

The book sheds light into the complex way ads developed over the internet, from modest contextual banner-ads to the programmatic, then the targeted/auctioned ads of today that have helped generate an ecosystem of fake content and clickbait headlines. Some sites have begun to live an independent life from any "quality" website. Ball accuses publishers having almost willingly given away their position as a provider of lucrative ad space, whereas initiatives like the GPDR only succeed to miss the original point (of curbing the rampant ad-cookie exploitation).

Ball questions the truism that ads are needed for any free content, as internet did nicely before targeted ads. He suspects that middlemen benefit far more than the deserve, but also suggests that things wouldn't need to be as bad as it is. Ads can actually serve a purpose, but something about the system needs to be better tuned to avoid the worse excesses.

The recurring triad of evil here is Silicon Valley-style Big Tech (make things fast and fix them later), Free-market economic theory derived from Reagan/Thatcher era (what makes wealth is also morally validated) glued together with Venture Capitalism. (fund a promise of future profit despite current viability)

A new global war

The story shifts to cyber attacks, security, surveillance and the Snowden revelations on NSA, a story which Ball had a direct involvement with. Just to recap, NSA experimented with a system that would store "everything" in UK communications for three days, and the metadata for 30 days, something that was technically kind of legal there. Furthermore, NSA had actively sought deals with companies and online service providers to build backdoors in them. From some kind of niche occurrence, hacking has turned into a constant cyber war being waged between governments.

All this wasn't achieved by intelligence agencies alone, nor was it devised by governments as some kind of intentional conspiracy. Ball argues that the aforementioned advertisement capitalism led to a situation where massive pools of user data were suddenly available on the internet, given away willingly (or at least without worry) and eventually worth experimenting with.

Platforms such as Facebook are here seen as an extension of US "soft power" abroad, hence the US might not have been that eager to regulate tech companies and their platforms in the first place. The apparently altruistic push to bring internet to less developed countries can be seen as building US beach-heads for favoring their established companies. So, it's not simply a language barrier and a dictatorial regime that makes countries like China and Russia build their own version of the platform-internet.

It's also an issue who will host the new version of the internet's surface layer in the future and what it will be like. The danger of 5G is not some skull-eating radiation, but that with the new standards there's an opportunity to smuggle in ideas about network "slicing" that again may undermine net neutrality, become a new kind of surveillance tool, or another "soft power" extension of some nation, this time perhaps China. When Huawei was stopped, it was largely on suspicions for the kinds of things US had already previously practiced when holding the strings of the internet.

A couple of times the book draws parallels between internet and the original railroad expansion, acknowledging the main difference that railways tended to centralize and internet is inherently dispersed. But what is being centralized is the wealth in the hands of those who were already well-to-do before internet existed, much like what happened with the railroad.

Whereas industry giants could benefit and leverage the railroad network to gain advantages in other fields, the 20th century anti-trust activities largely put this to an end. Mergers are still scrutinized, yet when something similar happens on the internet, it's not an issue, as Ball repeatedly points out. The Facebook acquisition of WhatsApp is especially lambasted here, but companies like Google(Alphabet) and Amazon likewise made strings of acquisitions without being questioned.


Uh, huh

So, all in all a very light read, but not altogether "light" in the themes it presents. The angle is journalistic rather than academic, giving it more dramatic tension throughout, perhaps even an agenda. The quotes from the interviewed people speak a story, and the reader can make their mind about them.

Still, the discussions and opinions are from noted authorities (including academics) so their voice does have weight. There is a value of having a book like this on your lap while things are still happening, rather than having the academic account ten years later.

I'm not sure what to make of all the pessimism. On one hand the book is attempting to shake people out of the kind of "Yeah it's bad but what are you gonna do" mentality, on the other hand it does paint a picture of a very major complex that can barely be touched by individuals.

The suggested remedies in the book are intentionally somewhat anti-climactic. The whole message of the book is that the internet has a number of different problems in it, and therefore there is no one major fix. Advances can and should be made in multiple smaller areas. At best it is possible to encourage a "systemic" view into the complexity that is the internet and to remind it's the people that set it up and formed it in the first place, not some force forever outside our reach.

Sunday, 23 January 2022

C64 wi-fi modem

I received this wi-fi modem for the Commodore 64 already a few years ago. The board has no identification on it, but it looks like a bare-bones version of the same design that has been going around, like WiFi-64 and Strikelink.

Although there are various C64-cartridges that read SD cards, there are not that many direct file transfer solutions between PC<->C64. So I'm mostly looking at the modem from this angle. The modem sticks into the user port so it doesn't take the cartridge space.

The first time round I had some success with contacting a BBS, but the ftp, wget and other internet functions failed to work for me.

This was all because of not knowing one command! Re-reading the manuals, I found out I can upgrade the firmware directly with the terminal, connected to the internet (as it could do that much). After moving from version 2.62 to 3.6.4 I got the wget file transfer working.

From here you can download the disk image with C64NET WiFi apps by Bo Zimmerman. These are BASIC programs for various tasks. The site also has more comprehensive manuals. 

A better terminal, such as the CCGMS, is useful for contacting Bulletin Board Systems, but that's not my focus here. The minimal CBMTERM included in the apps disk is enough for adjusting the modem parameters.

From the same disk, CONFIGURE is for the first-time setup of the modem. It didn't do anything meaningful now that it seems I've run it before. Sadly I didn't make notes then. After the basic configuration has been done, the CBMTERM can be used for changing the network and the network password.


Terminal

CBMTERM is a simple terminal mostly useful for sending those AT commands to the modem.

Here are some of the commands to try:

ATE1 for command echo might be needed if you don't see the characters you are typing.

ATW lists available and compatible wi-fi networks, together with signal strength.

ATW "[SSID],[PASSWORD]" will connect to a wi-fi network.

Note that this will respond with "ok" if it was succesful, and with "error" if the SSID is wrong or the password is wrong. 

The CBMTERM runs in lowercase, but everything you type in lowercase is actually uppercase in the outside world. So if your wi-fi network name is XYZ5235, you'll type xyz5235. Same with the password. 

My network name had a _ character, this shows as a left arrow on C64, and can be typed in as such.

ATI gives information on firmware and the wi-fi network.

AT&U shows if you can download a newer firmware.

AT&U6502 then actually downloads and installs the firmware. Despite instructions I didn't need to physically reset the modem. Of course if the service ceases to exist, the firmware update can't be done.


Moving files

Again from C64NET WiFi apps disk, the WGET can be used for downloading a file from a web address. The output filename and type has to be defined here too. The default suggests a sequential file, but if you download a prg the line has to read something like @0:myprog,p 

I first tested the wget with the default example, downloading index.html from Bo Zimmer's page. Then I moved to downloading a C64 program file available elsewhere on the internet.

Of course, downloading a file from a web server on your local network is ok, using the IP address. So if the server is set up then for me http://192.168.###.###/index.html could be downloaded.

The bytes will mosey down the tubes to your Commodore 64 drive. Even if the interface was improved (and why not, it's in BASIC), the downloading won't be especially fast.

After setting up an ftp server on a Linux over the local network, I could also try the FTP program supplied for moving files between my Linux and the C-64. The program asks for the ftp address (in this case an IP address), the username and the user password. Then it's ftp commands all the way.

The ftp is already more handy for transfering multiple files, but I have to say that handling the switch between passive/binary mode and such, also takes time.

Some observations

A wi-fi modem that runs on 1200 or 9600 baud max, isn't going to be the final solution for immediate transfer between PC and C64. But I can see it could reduce the need for swapping that microSD card.

Now I simply tested the features and downloaded everything on the mounted C64NET apps disk image. Later, I'll have to think about how and what I am going to mount on the SD card reader and when.

As the programs are in BASIC (with shared M/L libraries), some ease of use could be achieved by rewriting the programs to apply to my local situation. For example I could modify the program to default to my local ftp server address, or just making the connection directly.

I mostly used the modem in conjunction with the SD2IEC+Epyx Fastload combo catridge, with the fastload on. This worked fine, although it seemed to me that after I'd broken out of a "modem session" using RUNSTOP/RESTORE, the SD2IEC lost the disk mounting.

Using the Ultimate 1541 II with the Action Replay VI cart, I couldn't get the software to run. Moving over to using the Epyx Fastload cartridge all seemed to work better. 

However, with Ultimate, on occasions the FTP app produced hiccups and a file refused to load completely. This is not a final judgment about these cartridges, it might just be bad luck and the problems could just as well appear with the SD2IEC+Epyx. I could try to test this more.

But certainly I'd recommend testing the modem first with a more "clean" Commodore 64.

Saturday, 15 January 2022

SD2IEC+Epyx Fastload combo cartridge

SD2IEC + Epyx Fastloader cartridge

SD2IEC has long been the sort of standard inexpensive way of accessing C64 files from a modern media. But it only becomes powerful when combined with a fastload cartridge such as Final Cartridge III or Epyx Fastload.

Juggling with the carts and power cables can be a chore, so someone got the clever idea of combining the fastload ROM with the SD2IEC for the Commodore 64. Here's a DIY version, my cart was based on this design. This was acquired from a certain tinkerer from Akaa, which I'm beginning to think is the C64 capital of Finland.

So, one-cart does all, and as a bonus it gets rid of the 5V power cable. As is usual with drive emulation, the serial needs to be connected.

Just as the plain SD2IEC, the cart has buttons for mounting the next/previous disk image and DIP switches for setting the device number. The Epyx combo comes with a reset button, drive reset button and a serial through-port has been included so for example a real drive can still be connected.

Switch the fastload on and turn on the C64, you'll see the minimal "fastload" message.

Epyx fastload cart isn't the most comprehensive or user-friendly cartridge, but it has enough functions, mostly single-character shortcut commands, a DOS wedge, disk operations menu and even a minimal monitor. It's worth reading through the manual.

LEDs shouting. At top, prev/next buttons and the drive reset. At right, C64 reset.

%filename loads machine code files, $ brings up the directory without erasing your BASIC listing. C= together with Run/Stop loads the first file on the drive.

My tiny gripe with Epyx is that $ for viewing directory is quite slow, and the loading commands don't auto-run files. Unlike other carts, the function keys do nothing. But then again the SD2IEC system works fine with the fileselector.

Plain SD2IEC also works with VIC-20, Plus/4, C16, C128, whereas this combo cart only works with the C64, so bear this in mind if you have more hardware.

Ahhhh.... weekend

For example, I copied my old SD2IEC card contents to my computer, then copied only my C64 folder to the new microSD card and the fb64 fileselector. This way, using C= + Run/stop keys I can run the selector almost instantly after turning on the computer.

There's a button on the cartridge that resets the drive. So if you have previously mounted a disk using the fileselector, you can reset the cart, press this button and bang, you are at the root and can run fileselector again.

Most people probably get the SD2IEC to load games and demos, but as a drive emulator it's also versatile for development on the C64, for saving and loading BASIC files for example. In this case it's probably better to work with the root directory, even if it can get cluttered eventually.

It has to be remembered the SD2IEC is not 100.0% compatible with a C64 floppy drive and especially fastloaders give trouble, but it's true enough and if you find a game that doesn't load there's probably a version somewhere that does.

I've also seen a variant with changeable EPROM, which could be nice for that added tinkering value.

Physically the SD2IEC+Epyx cart looks like a heavy deal, and it is quite close to the core functionality of the mighty Ultimate: a drive emulation with built-in fastload. However, the Ultimate also offers much, much more, such as injecting PRGs directly to memory, choice of cartridges and so on.

Still, the Epyx combo is very neat and not too expensive package for the Commodore 64.