Monday, 13 July 2020

Fleamarket pedal


5 Euro foot pedals from a flea market. At first I thought it might be a sewing machine pedal, but seeing as it is pretty heavy and has two pedals so I don't know.

I had no fitting DIN connector and the cable smelled so strongly of old house, I got rid of the cable altogether.

Opening the box was not obvious. I had to tear off the soft rubber bottom to reach the screw that holds the pedal axle in place. (The tiny hole in the axle of the loose pedal at the top image).

These machine screws were mightily stuck and I may have contributed to bending them, when trying to "open" the axle from the end.


Inside there was a tiny surprise: There were more parts than I would have expected. What does the cog do?

First I thought there was some complex system for softening the punch for the microswitches. Which it probably kind of does too...


But the pedals are not both on-off switches. The left one has a mechanical flip-flop latch that keeps the switch "pressed". Were there no microswitches with this functionality?



The left pedal then controls whether the right pedal presses go through at all.


Using the pedal

I had some visions about using the pedal as a second fire button on C64, or controlling my own programs through Arduino serial. Or a weird chess clock.

But, first, the pedal could be used in something that actually needs a pedal.

Enter the Alesis Samplepad Pro, another recent cheap acquisition. It's an electric drum kit that can be played with drumsticks.

There's not much pro about it, as it has a widely known crosstalk problem between the pads. But fortunately by adjusting the individual pad sensitivy values the problem can be practically removed.

My approach so far has been to make Kick, Snare and Hi-Hat more sensitive (6) and concentrate on using them. The rest of the pads can have level 2 sensitivity.

Now if the kick drum could be delivered with pedal, I could remove that pad from the equation altogether.


The Samplepad Pro has a pedal option for kick drum and hihat, and I could connect the pedal microswitch easily to this connector. I soldered in some cables, of course missing the right connections at first, but finally it worked.

Here I've used the 'trigger' option. Possibly the 'switch' allows a velocity control through a resistor.

Well, honestly I can't play at all, but already could see it would make more sense to have a pedal together with the pads. It's a bit dificult to generate proper patterns by using drumsticks alone, even though the geniuses in Youtube can do that too. Then again using both feet and hands is another level of motoric articulation and it doesn't come too easily either.

Well, the ergonomics of the situation now weigh much more heavily than when just using drumsticks. It's also blindingly obvious the pedal is not really suitable for a musical instrument. Ok, so I had to remove the rubber footing that would have kept it better in position, but I doubt if it would help that much.

No wonder the add-on pedals easily cost as much as the second-hand Samplepad.

Trigging the kick was not as accurate as I would have expected. If I make a steady rhythm it will pick all microswitch clicks accurately. But if I click it in really rapidly, only the first goes through. I'm wondering if this is a problem (or intentional design) with the Samplepad input detection, or with the microswitch itself.

So, a nice junk find that at least motivated me to do something more material after a long while.

Thursday, 2 July 2020

Some more Linux/Proton games

About a year ago, I had a look at Proton on Steam for running Windows games on Linux.

Here's a small bunch of games I have since then played on Linux using the Proton/wine setup in Steam.

The results show not everything is totally perfect, it seems the larger the game the larger potential there is for some glitchiness.

Mind you some games could be improved by adjusting settings, these are more like out-of-the-box experiences.

A larger problem for the Linux player these days is the increasing amount of different game stores and solutions for running these games. Not everything is available on Steam. For instance, to play Firewatch I had to use Lutris, so I'm not discussing it here.


(I have reduced the screenshot sizes for this blog)


Inside

For some reason I avoided this for a long time. The game's a real little treat, comparable to Limbo (if not better in some ways) and works quite perfectly.

Ok this is exactly the kind of screenshot that helped me avoid the game. It's much more interesting than this.

Arma 3

There's apparently some limitations to on-line features, but I could play the solo missions.

If I recall correctly it did work rather well.

Every vehicle is quite meticulously modelled from outside and inside.
Although I had some positive memories from Arma 2 back in Windows Vista days, I just couldn't really now become enthused about this somewhat militaristic and involved playfield.

There is interesting stuff like drone reconnaissance, but the missions are of the "perform exactly correctly, or fail" variety, rather than a dynamic simulation, which is not that satisfying.

Some of the cutscenes are almost hilarious in their military matter-of-factness

Dirt Rally

I'm not too enthusiastic about car games but rally games have tended to be more bearable.

Dirt Rally works well, the loading times were surprisingly long but this likely has nothing to do with Proton.

The famous Paskuri.
It's about playable with a keyboard but this kind of game might really need a controller.

It does look quite authentic.

Virginia

This is a heavily Twin Peaks-inspired story game. It's bit like the aforementioned Firewatch but with even less to do for the player. Just click on things and walk the character to correct position to find the things to click.

The beginning is promising but then it starts to get wearisome, as the gameplay never really expands. Then it just ends.

The unhappy family.
Almnost needless to say, the technically quite simple game works perfectly in Proton.

Where's the coffee?

NieR: Automata

Not as huge as a Final Fantasy game, but it's still quite intense. Although at heart an RPG, the game fuses elements from shootemups, platform games, brawlers, often shifting the genre multiple times a minute when going gets hectic.

The technical strain is not massive, but the visuals are well thought out
I encountered spurious crashes at first, but apparently these were a result of undervolting I had done earlier to my computer. After removing undervolting it became one of the stablest games.

You can attach different chips for different features, bit like magic accessories in an RPG. What makes it different is that even the basic game functions, such as hp counters, map, damage counters are "chips" and could theoretically be removed in order to make space for something else.

You are wearing the masks wrong

Mirror's Edge

A rather influential game, as most later third person action games (Tomb Raider) employ similar movement logic as this parkour-fest. Played this only a little but it seemed to work ok.

I needed to change the in-game resolution settings as it did not correctly guess the screen resolution.

Here I had not yet changed the resolution...

Just Cause 3

I believe this was something that until recently would not have worked because of Digital Rights Management issues. (Funnily enough the antagonists in the game are called DRM for Di Ravello Militia)

The High Ground makes it all easier
A rather nice open world game in the GTA mould, but with more emphasis on super-heroics and destruction. Maybe a touch of Midwinter here, although without the strategy/recruit elements.

After launching, the window minimizes itself, after which I had to bring it into view again. Using shift+tab I brought the focus to Steam, after which the keyboard becomes responsive.

The rebels favor strangely uniform visuals for styling their cars
During game, there's also a danger of pressing a key combination that minimizes the window again, or brings something else to focus. After this happens the keys rarely work 100% again and I had to relaunch the game.

I encountered some graphic glitches, which might or might not be result of Proton, but nothing that would distract my gameplay.

It also did crash very occasionally, perhaps 2-3 times in 20 hours (edit:30 hours) of playtime.



Thursday, 25 June 2020

Surviv.io

I've become slightly addicted to a browser game that's essentially something that "kids these days" play, the mighty surviv.io. Although I'm probably 1-2 years late to it.

It's a clever 2D take on the popular battle royale online multiplayer genre, but better still it really reminds me of old games like Rambo, Cannon Fodder and Airborne Ranger a bit.

Squad mode.
My first experiences were just die, die, and die some more.

Then I watched a few videos, read a bit about weapon and item qualities, spectated the other players and went back to the game. And died some more. But at least I kind of knew why.


Some notes

Many players rush for the underground bunkers and other major buildings, as these have guaranteed weapon caches. Better players are often there and without experience you'll get killed instantly and it may be a bit difficult to enjoy.

When you are inserted to the map, the clock may show something between 30 seconds to about 1:15. This gives an indication how long some players may already have been on the map. In the worst case others may have had a minute of looting time before you!

If you have a lot of time, you can check the map ('g' key) for the nearest interesting building (clubhouse, bunkers etc) as you might reach there first.

Even knowing this, to get the feel of the game it may be better to lurk around a bit at first, find out what the items (health, pills, weapons, grenades) do, what can be found from the crates and furniture and so on.

A typical 50v50 map. The battle often focuses on the central bridge. A bunch is looting the greenhouse southwest to the center, with two squadmates. The circle marks the approaching red zone.
It's important to understand soon that using pills/cola adds to your adrenaline. If it's more than 50% you get a speed boost. This explains why some enemies run circles around you, they have the aggro and you don't. Adrenaline is also a slow-healer.

It's possible to survive in the red area in the beginning, and if you have some adrenaline the healing effect is stronger than the damage! Later the effect gets more intense and the pills can't compensate for the burn.

So if I find enough adrenaline at the beginning, I can lurk at the red area and collect all the junk that's been abandoned. This is also a way to learn a bit more about the environment without someone pestering you all the time. It's not totally empty, though.

Lurking's fine for learning the ropes, but it seems it's not possible to win without becoming a hardened battle master! There's no reason to shy away from battles and difficult locations. Fights are often about a complex exchange of timing lateral motion and shooting, weapon switches and special items.


Armor and items

You can get some kind of armor and weapons very quickly, but if you only have crap armor, crap helmet, crap weapon, crap visibility then you won't have a place at the end game.

Only much later I learned the helmet has a different logic to the armor, which simply tends to sink damage. There are apparently such things as 'critical hits' and the helmet sort of protects from those.

It's a good idea to learn to quickly identify enemy armor. White-ish border is the t-shirt, grey is level-2 vest and black is the top-notch (nearly) bullet-proof vest. Some cloth colors make these difficult to see.

Visibility 1=beginning, then 2, 4 and 8. 15 does exist. The higher, the more rare obviously. You can manipulate the situation a bit by hanging inside or underground, as the visibility tends to be low there.

8x view, 50v50 mode. The bridge is often the centerpiece of the battle.
Visibility range in itself is again not that useful, if your weapon has no stopping power from distance. You may just end up revealing your position from further away!

A "sniper" weapon coupled with 8-range can be a deadly combination, whereas those guns are rather difficult to handle at close quarters. Some sight problems may arise from the 8-view, maybe someone jumps out of the nearest bush and you can't see the threat!

It's safe to say that skilled players will have top tier everything at the end game, and if you don't, then there's little chance. They do the math and rush you with superior weapons, confident that you can't damage them enough in the altercation. With luck you can get to #2 through having avoided everything, but it won't help you win.

Note that there are also cheaters, hackers, aimbots and whatnot. (As of today something may have been done to this) It's unclear to me if mobile players and mouse-players are mixed in the same game. I guess touch screen versions must involve some kind of aim assist. Don't be too sad if you get killed by someone playing by different rules.


Weapons

One novelty of surviv.io is that although the game is very simplified and even abstract, the weapons are (comparatively) realistic. There's a bunch of weapons with different characteristics for damage, spread, range, magazine size, loading speed, post-firing slowdown etc.

I'm not going into detail about which gun does which damage, there are wikis and websites for that. In the beginning I tried to figure out which was the "best" weapon, but as I've learned a bit more, most of them seem to have their place in some situation. This also adds some nuance to the game.

AK-47 sounds good but isn't really that amazing. I would prefer M416 over it. The shotguns are OK-ish too. I've begun to like a combination of M416 and the M220 shotgun that delivers 2 shots in quick succession. These are also quite often available.

As I already said, the end-game is not very forgiving. There you need better weapons, even if the M220 serves well as a 2nd weapon. What others have left lying around is often a good guide as to what's crap.

A MAC-10 or a double-wielded G81C can be useful at the very start. Although not powerful, these spraying weapons are attractive for the beginner as the aiming is not so difficult. Slow shotguns and sniper rifles are more potent but are also a bit hard to use.

There have been tricks switching weapons to diminish the delays, slowdowns and loading speeds, but I'm not yet that intensely involved. Also sometimes the developers discourage these tricks by altering the rules a bit. In any case it makes sense to be able to switch quickly between weapons in the heat of the battle.

Grenades can be a game-changer, but they are often easy to avoid too. Throw them at the last moment before they explode and you have yourselves a bazooka, but it's difficult to do in a chaotic situation (i.e. every real fight)

One of the underground bunkers.
More often grenades are used to create a suppression zone between you and the enemy so you can escape or get time to heal. In squad games this can be quite important. Smoke grenades have more subtle uses. You might follow up a smoke grenade with an explosive, but it's often a bit too obvious.

Mines were recently added, and initially I felt the game doesn't need another semi-random way to die! But they do appear to add dynamics to situations.

As I said, fists might even deal more damage than some of the weaker guns. The melee fights are a bit random but sometimes a desperate fist assault can be better than fleeing under gunfire. Note that claws, knuckles and knives are simply cosmetic skins, even though the latter show as items.


Other game modes

After I found Squad games more enjoyable than the Solo mode, I rarely play anything else. This is partly because victory doesn't become so important.

50v50 games are sometimes available, and these can be a good learning experience as you don't meet the enemy too soon. It's more easy to get into the logic of looting and finding weapons and items. Also, the chaotic battle situations are amusing in themselves.

The Russian police never sleeps!
There's also the squad variant on a cobalt grey "spiky" landscape, with "character classes". This can also be useful for learning. Here the Cast Ironskin class generates its own ammunition, so you don't have to figure out which ammo fits which gun (something that caused trouble in the very beginning). Otherwise I'm not a big fan of that mode.

Random squads are not often very effective. Bickering members steal whatever items they can see. For some, snatching the item from a crate you looted is a game into itself. Most care little if some squad members still miss weapons, but more experienced players tend to be more helpful.

...and some wander off without much thought about team coherence. There are also those who find enjoyment in playing "solo" in the squad mode, or try to establish teams in the actual Solo game, or somehow disturb the 50v50. Well, whatever.

Chaos at the bridge in 50v50. The red zone is approaching...

Communication

I played a solid amount of games before even looking at how to produce emojis and to communicate with teammates. The emoji wheel is activated by holding and releasing the right mousebutton, whereas the latter comes up by holding key 'c' and doing the same. The set of emojis can be adjusted in the loadout.

At start I thought that a game with no chat or verbal communication would have no insults or much negativity in it. How naive I was! A barrage of 'poop' and 'crying with laughter' emojis after you've been brutally overcome, DOES have a kind of effect.

The little text there is, is in the player names. There are the occasional squadmates with a "hilarious" name in the vein of "nazis are ok" or "jewkiller", which I feel the need to discourage somehow. As squadmates can't damage each other it can only suffice not to help them. These may have been censored lately.

I've felt that shooting at squadmates can be used to indicate disapproval, even if no damage can be done. After shooting at one "nazi" he got confused and began emoting he's French or Russian or whatever. Yes, there are nationality emojis, which are sometimes brought up in 50v50 as a some kind of hopeful appeal to "true allegiance" when death is nearing.

I also felt the "?" emoji would be useful for play situations, but turns out many just interpret it to mean "what is your nationality?"

The nickname "girl killer" and variants, is a grey area, is that someone who kills girls or a girl who does the killing?

Choosing emoji set in the loadout.
I felt surprised that a lot of the crowd were progressive and conscious enough to declare the "rainbow" emoji. Soon it dawned on me that when correctly timed, the rainbow emoji simply equals the on-line gaming classic "you are gay".

Add to this that it can be invoked in an implied and plausibly deniable way. Should this be worrying? Did the devs think this through?

Or, did I, after reading too little into it, read too much into it? Someone gets killed: that's a rainbow moment. You die: one final rainbow towards your assailants. Some are seen to actually collaborate: a rainbow. Some are found in healing activities in the bushes: rainbow again. Oh look, there are some flowers, that's definitely rainbow time.

It's a bit weird if players are assumed to be of particular gender (the visuals aren't particularly gendered) to make this effective as some kind of insult. So there might be a layer of irony here, too.


Ironies of Surviv.io
  • Try a weapon and find yourself at the losing end of every fight. Then take note how anyone else is able to pulverize you easily with the same weapon, no matter how "crap" it seemed.
  • Conversely, see how economically the enemies wipe you out with a "difficult" weapon like the SPAS-12, try it yourself and you never either hit anyone or deal enough damage.
  • The more seemingly amazing weapon or equipment you find in the first 30 seconds, the more likely it's all going to go to hell in the first minute. Find the most sad weapons and equipment and you'll be bound to survive to  the endgame, just to get killed (because of the crappy equipment).
  • Good players always retreat at the right moment, they sneak out of range and view to heal themselves. You try it and get shot in the back.

Sunday, 31 May 2020

recordmydesktop script

I've used recordmydesktop for grabbing the few desktop videos I need.

It's useful to record a specific window. This requires knowing the window ID beforehand, acquired by using xwininfo.

Remembering and executing this phase is sometimes a bit annoying, so I tried to shorten the process a bit by using the following script. I guess a front-end exists somewhere, though.

After running it, xwininfo is indeed launched but the info is directed through grep to a temporary file. I click on the window I want to record, the output is parsed so that the window ID is passed onto recordmydesktop.

It could be bit more elegant but what do I care.


#!/bin/bash
echo Click on Window
echo WILL RECORD INSTANTLY
echo using fps 30
xwininfo -display :0 | grep "id:" > temp.txt
more temp.txt | grep -Eo '0x[0-9]+' > temp2.txt
fname=$(<temp2.txt)
echo $fname
rm temp.txt
rm temp2.txt
recordmydesktop --windowid=$fname --fps 30


I noted that on occasions at least Chromium browser window refuses to work (unrelated to script I think). Recordmydesktop had trouble with the acquired window ID. First I thought it might have to do with detached tabs, but not really. Sooo... maybe just run another instance of it and try again or something.

Saturday, 23 May 2020

Horizontal and vertical dual setup on Linux Mint

I have never really been a two-screens guy, unless you count the inevitable retro computer monitor next to the modern PC.

Partly because there's never ever enough desk space to do that, partly because I've felt that having my eyes wander between two wide screens is too un-ergonomic, and so on and on.

On a whim I noted I could at least save some desk space by having the other screen as vertical. This would also reduce the horizontal eye and head movement.

Reading news sites or Facebook it might be a better layout, as many websites are now designed with a vertical screen in mind.

But it's still more of an excuse to get the second monitor fit.

To me it makes sense to have a vnc window to another computer on this second monitor. No, really, although it does sound a bit silly.

I've occasionally tried running two computers on two monitor side by side, and found that to be more confusing than the vnc. I have more than two computers and so the keyboard/mouse sharing options could get complicated. Plus the other computers might not be stacked physically close to the screen.

So, I could get used to this.

Connecting two screens and changing their orientation is not at all difficult in Linux Mint/Mate. Some challenges arise from trying to do specific things.


The primary monitor is connected with DVI, whereas the other is on a Displayport->VGA adapter. (I don't have a displayport-equipped monitor) The primary monitor is 1920 x 1200 and the secondary as 1680 x 1050 (1050 x 1680)

It may not be obvious that by moving the pink and cyan rectangles changes the way the mouse pointer crosses over to the other screen.

I did encounter some hiccups in the way the icons are arranged on the primary screen. When trying to match the screen positions with the physical reality, some icons went over the top of the desktop and would not "arrange" correctly either.



Drawing with a Wacom tablet on screen 2

Using GIMP window in one screen and tools in another, is not something that works well for me. The mouse pointer transitions between monitors are not ideal and shifting my focus is even less so.

But, drawing on a vertical format on a single screen might make sense in Krita or Mypaint.

Generally I've found my cheap-end Wacom tablet to behave well in Linux.

The first instinct of the tablet device is to map the entirety of the display range to the tablet. Just like if you take a screenshot it will mosaic both screens. This makes sense if you thing the tablet as a substitute for a mouse, but it's not good for drawing.

xrandr can tell the names of the screens (or the ports?) such as DVI-D-0 and DP-2 in my case.

xsetwacom --list devices will tell the names of the tablet devices:

Wacom Intuos S 2 Pen stylus      id: 12 type: STYLUS    
Wacom Intuos S 2 Pad pad        id: 13 type: PAD  

But, instead of using the screen names from xrandr, I found that using HEAD-0 and HEAD-1 work instead. (I've understood this is due to Nvidia drivers. Just in case the above works better I've included the info).

xsetwacom set "Wacom Intuos S 2 Pen stylus" MapToOutput HEAD-1

What still remains is that the scaling is all wrong because the tablet is horizontal and the screen is vertical!

xsetwacom set "Wacom Intuos S 2 Pen stylus" rotate ccw

This rotates the orientation counter-clockwise. "none" and "half" are also possible values. Obviously the physical tablet will have to be rotated too.

After removing the window toolbars it's quite nice to draw on Krita vertically.


After these settings, everything works as I'd expect: the mouse still works across both monitor boundaries, whereas the Wacom tablet is limited to that one screen with Krita.

There is a discrepancy between the color and intensity and gamma of the two monitors, which can be annoying in some situations but I may even need that in some visual tasks, looking at how a graphic might show in different environments.


Launching applications

I recall this has always been a bit off-putting with the Mint Mate dual monitor set up. The thing is, programs don't launch in the correct monitor in a logical way.

Part of the confusion may be that it is all treated as a single display after all.

Some programs, like Krita and GIMP, remember the previous configuration, which is great.

I don't expect to play Steam games etc. in this vertical monitor so that can be forgotten. I already recall this required some fiddling and is partly to blame for my negativism towards two-monitor setups.
Half-Life 2:Lost Coast behaves rather nicely, but the mouse is mapped wrong

But there's really no need to force games, or films, to play on that vertical monitor.

I created a panel to the second monitor with application launchers. This might help with obvious ones such as the terminal window.

Even this information I had to dig up somewhere: The new panel can be only created on a monitor with an existing panel. Drag the new panel to the correct monitor with ALT pressed down.

Using compiz and and changing compizconfig settings does not help, although some of the options sound like they might address this issue.

Looking around, this launching problem seems like a fairly persistent issue with Mint.

I could make this somewhat kludgy script, make a launcher icon run it and technically have my application run on the other monitor:

#!/bin/bash
x64 &
sleep 2; wmctrl -r "VICE: C64 emulator" -e 0,1920,0,1200,1500

But it's not especially ideal either, here the "sleep" period is used so that wmctrl can catch hold of the window.

Should I want to run Vice full screen then it will again switch to the primary monitor. Ok, if I add the -fullscreen argument to x64, the script will miraculously run it full screen on the other monitor, but the pointer will be confined to that screen. Vice seems to do that in any case, so that's the end of that really.

It does not matter to me if Vice runs full screen on a wrong shaped monitor, I'm simply using this as an example of the kind of problems that may arise from this setup if you insist on getting something to run on the 2nd screen.

Going through a lot of software and finding out they don't behave in the best possible way gives a negative feeling, even if I wouldn't really even use those apps on the second screen.

So, the "wrong" monitor launch is not an enormously big deal, more like an annoyance that comes from testing multiple apps. 

Wednesday, 6 May 2020

1541 Ultimate II




Finally I got the Ultimate cartridge for the C64.

Not the II+ mind you, but a second hand version of the II, with the tape emulation add-on and the Ethernet-USB dongle thrown in.

The adapter has the label "NO:usb 2.0 LAN JP208 MADE IN CHINA" and that's all I know of the brand and make of it. It's good to have an already proven solution included.


Firmware upgrade

I didn't really buy the cartridge for the Ethernet functions, but I was curious enough to want it to work. It happened the u1541 firmware was 2.6 and needed upgrading before this would work well. In any case it must be a good idea to update the firmware.

At this moment I realized the Ultimate cartridge, despite being highly rated and professional-looking hardware, has a rather scattered and a bit confusing documentation. Well, it's quite common for any of these hobbyist add-ons. As I got this second hand the docs may have been lacking.

So, an upgrade 2.6 version to 3.07beta needs an update.bin file in the root folder of the SD card (Usb stick is not enough). When booting, the update will run.

Afterwards, I could upgrade using u2u files. (I guess u2p files are for the plus) When I had my 3.4c version going, I could finally see the IP address on screen.


Remote control and file transfers

Now it's possible to telnet to that IP from another computer, using port 23.

PuTTy is fine, but correct settings are needed for display and cursor keys and backspace.

Initially arrow keys or function keys did not work without pressing Control at the same time. Changing PuTTy keyboard settings to VT100+ helped. "Initial state of cursor keys" is "normal".

Local echo and local line editing are both "force off". Backspace is set to "Control-H"

Also, the font did not display correctly despite changing it from UTF-8 to ISO-8859-1:


I fiddled with various settings, but apparently I needed to untick the box that says "override with UTF-8 if locale says so".

After this it started working properly:

The telnet connection is quite impressive and it's nice to have the remote for viewing files in quick succession. The software inside the cartridge does not care what state the C64 is in, so the menu can be operated all the time the power is on.

ftp is also possible, but any attempts to integrate it to caja (the Linux mint file browser) were not especially successful. I could see the folder but file transfers failed. The same with filezilla, a file manager, which seemed so convoluted I wouldn't probably use it even if I found the correct settings.

Instead, I got it to work using command line ftp to the IP address. First use 'binary' to set all further file transfers to binary, otherwise files will be sent with incorrect file lengths. (despite the system saying its switching to binary for the files.)

'ls' gives the remote folder contents. 'cd SD' is likely the first move, to get to the root folder of the drive. Then 'put' puts a file on the local current folder to the current remote folder, and 'get' does the reverse. 'bye' exits the ftp command line.



Apparently the telnet and ftp functions don't mesh together, so you can't upload a file using ftp while "in" with telnet.

Edit: Apparently they could work together, but it's just that messing back and forth multiple times with either ftp or telnet tends to lock the cartridge. A script that sends a file on ftp and launches it via telnet, may work one or two times. This could be related to a bug/oversight in the cartridge.


Some fooling around

One of the main functions of u1541 is the utility cartridge collection. For the purposes of using the cart for running files and general compatibility, the Retro Replay cartridge seems to be the standard.


But there are others, such as Final Cartridge III and my old friend Action Replay VI.

For fun, I did a code snippet on the monitor. (Invoked by MON).


Well, the monitor is in the Retro Replay version of the cart too.

AVI was the original environment where I learned the first steps of assembler in the early 1990s.

For a long time these were the last steps too, because I didn't understand how to structure these programs at all.

Now I see that it would be possible to write long programs using the monitor, giving enough room for subroutines and using a meticulous paper documentation/mapping.

There is another interesting cart, the Turbo Action ROM by Soundemon/Dekadence. This contains Turbo Assembler:


So the same code snippet can be written this way. The source can be assembled by pressing arrow left (the "esc" key, not the cursor key) followed by 3.

After assembling the source, the cart can be reset, and after activating the Tasm again the source is still in place. (If it's not overwritten I guess).

Perhaps this would have been helpful back in the day. However I must say that it would be really painful to write long sources with this one and writing code directly in machine code monitor might even have some advantages compared to an assembler. There were of course various techniques for splitting the code, and in the end it might require the kind of forethought and paper mapping as with the monitor.


Overall

The core functions of the cart are supreme and I probably won't look too much back at SD2IEC and IRQHack.

Yet, it seems the cart is trying to be a bit too many things, yet some obvious things are missing (if I'm not wrong). Effort has been put into areas that are not that interesting to me, like printing or some weird audio extensions.

For example, from what I've read and experienced, the cartridge does not seem to allow straight-up transfer+execution of the transferred file. You have to manually launch the ftp-transferred file from the menu. This doesn't sound a lot, but it's an unnecessary step and a more direct result would been better for building and executing code.

This is something the IRQhack could do (although again in a limited way) and I don't see a reason why the Ultimate would not if the software was put into place. Maybe I am wrong and the function is there somewhere.

Wednesday, 29 April 2020

More and more sci-fi


Again, a round-up of science fiction I read in recent times.


Moon is a Harsh Mistress by Robert A. Heinlein (1966)

Heinlein attempts to mix elements from famous revolutions in this story about the Moon colony uprising against Earth governance.

Despite compositing elements from various historical contexts, the views are strongly on favor of a free-market economy, no taxation, individual rights to the point no one is an appointed judge or a lawyer by trade. If you don't anything useful, you die, that's harsh. Well, it might be a true observation about a moon colony.

It is an enjoyable story, but in my opinion suffers from Heinlein's basic mistake of overloading all the discussions with tidbits and ideas on how to govern and rule, what is a good society or not, who is a worthy individual and so on and on.

How can Moon threaten Earth? The catapults are used to deliver cargo, but they also act as deadly weapons.

One of the more interesting parts of the story is the sentient computer Mike, residing on the moon. One day he simply becomes aware and the main character, a troubleshooter called to fix the computer, is the only one who knows this. He gets to benefit from this greatly. In fact the computer is bit of a constantly presiding deus ex machina (literally) without which the revolution would have no chance at succeeding at all.

The role-playing game Paranoia is likely influenced a lot by this scenario. The game setting was a dystopian future with all-pervasive computer who is your friend. The players were "troubleshooters" much as Man is, and all belong to a secret society (e.g. the discussion on optimal "cell" structure of a conspiracy).

2300AD RPG also refers to Tanstaafl, the setting with realistic planetside-interplanetary politics and corporations plays in it too, although it is more diverse and generic sci-fi, with Clarke and Asimov in its genes.


Invincible by Stanislaw Lem (1964)

Invincible lands on a harsh, unremarkable planet with a mission to discover what happened to the lost sister ship, Condor. The ship's not that hard to find but what the hell happened to the crew?

The atmosphere is that of horror without intent on being in the horror genre, and the beginning is already reminiscent of later films like Alien. As the mystery unfolds, the Invincible crew seeks to address the ominous, vague threat, while performing under the somewhat unbalanced command.

The characterizations may seem thin but I also felt the people were quite successfully painted in with minimal strokes. Having the spaceship discipline work much like an old-timey naval operation, works. It also makes this minimalism more relatable.

This book is willing to explain and open up the mystery and the psychological doors a bit more than, say, Solaris, a more complex work. The suspense and dread are distributed in addictive doses.


Hyperion cantos by Dan Simmons (1989-1997)

What I felt was one of the more recent works here... yet it's already 30 years old! I never felt that 1990s was a particularly great time for sci-fi, but looking at this I may have been wrong.

The first book, Hyperion is somewhat muddy, what with the constant bombardment of post-modern references and the lack of an actual story progression. Perhaps somewhat in spite of these intentions, I've found the structure to be more admirable than the surface. Hyperion's and Earth's history, and the galactic political situation becomes peeled through the stories. The later stories bring in explanations to earlier details and give further interpretations to the pilgrims' identities within the earlier stories.

The greatest mystery of course is what are the Time Tombs and what is the Shrike?

I picked the Fall of Hyperion and the Endymion/Rise of Endymion sequels at one go, so I had a rare opportunity to read a series in its entirety. Whereas Fall of Hyperion concludes the story, it also rehashes and repeats a lot of the first novel.

I may have even preferred the Endymion sequels to some extent, as it goes on with a more rollicking road-trip story format. Admittedly Simmons clears away any mystery that was present after concluding the Hyperion.

Concentrating on the single main character instead of the ensemble cast, although refreshing, is not without problems either. Simmons seems to have tried to make a hero that is less scholarly and worldly than the Hyperion pilgrims, but as the story progresses he turns out to be quite the know-it-all.


Canticle for Leibowitz by Walter M. Miller Jr. (1959)

An early post-holocaust novel. After a nuclear war, a community of catholic monks have the only handle on technology and electronics after a wave of anti-intellectual and anti-technical sentiment has bashed everything to non-existence. Not that this handle is much to speak of, as they merely preserve and copy extant documents about technology, with no understanding of how to produce anything new.

A discovery of a fallout shelter with interesting materials seems to point towards a sainthood for Leibowitz, and events start to roll forward to a re-instated future.

I kind of enjoyed the muted humor in this one, despite the over-abundance of monk latin. Amusingly the monks concentrate on making hand-made copies of rather mundane artefacts such as circuit diagram blueprints, the contents of which are no longer understood by anyone.

The book advances in time, and we get to see if the technically civilized people are the wiser the next time round.


Shikasta by Doris Lessing (1979)

(Or let's say, "The Invasion of the Space Eugenists")

Sorry to be a bit wordy about this. This is one of those book I bravely went through in my teenager years. Despite not liking it all much back then it may have made some kind of impression on me. Now, reading it as an adult it was much easier and compelling read, but I'm more able to articulate my reservations about this.

This is hardly science fiction at all (which is not the problem) but a spiritual/inner space fiction novel about cosmic empires taking hold and colonizing planets. There will be no gadgets, tech-wizardry or space battles... okay, there are space battles but they are waved away in a couple of sentences and it's not even clear if they happen in a physical plane at all.

The book initially starts out as a series of reports, written by the agents of the Canopus empire. It's not a huge secret that the planet Shikasta is early on revealed to be Earth (in some sense) and soon, instead of the cosmic journeys in the planet's early past, we are treated to a testimony of Earth's colonialist and racist past through extremely realistic and not to say non-science-fictional vignettes taking place in the present day (of early 1980s).

Lessing's own biography apparently serves as a starting point. The report-format enables the novel to treat long time spans and formative events in a quicker pace, shifting viewpoint as necessary. This is very effective and makes for a sort of prismatic reading. As the pace eventually slows down to support the more mundane events, this enhancement is also stripped off.

Emissaries of the spiritual planes choose to be born into this planet as human beings to manipulate it to their ends. Whereas the evil empire of Shammat brings all the devil into it, seeking to disrupt the connection to the better worlds, Canopus (and to some extent Sirius) bring all the goodness and harmony. Perhaps influenced by the ancient astronaut hypothesis, artefacts such as Stonehenge are remnants of the harmonically built structures of the bygone eons. Early biblical events have their roots in the Canopus-Shammat interferences, and so on.

The problem to me seems to be that although the loosening of Canopus' grip appears to result from breaking the Edenic beginnings, this event is not treated as the breaking of an umbilical but as an absolute malfeasance that needs to be corrected, and corrected it will be. Also, as the breakup results in a horrific catastrophe for the humanity, it appears to me a sign of a bit poor planning from the good fellows of Canopus.

But worry not, the human race will be joined to the Canopian paradise, read: devoid of any interesting culture and perhaps even of free will. Possibly, just possibly, the novel is meant to be read in a critical tone, the reader is meant to ponder about evils of Earth's colonial history and then ask whether Canopus is correct in adding Earth to their blissful Empire.

At some times it feels close to that nauseating idea that the evils of Earth are not a result of human stupidity but an outcome of supernatural meddling. However this is sort of avoided as the "human stupidity" is explored in meticulous detail as the white race is put on trial at the end. Also, the spiritual emissaries are not omnipotent, they are instead straining to keep focused on their intended mission.

But it's still the kind of world-view where youth delinquency and perhaps Punk subculture would work as a sign of corruption if not plain stand-in for evilness. The less eloquent and more crude language the character uses, the more evil they are likely to be. Not that this happens a lot, as the only strong swearword is contained in a Shammatian lackey's message, but it's somehow telling.

I was unaware of the Sufist connection before reading the Wikipedia article on this book, at least the SAWF/Sufi wordplay is lost on the Finnish translation I used. To me the religious undertones made the book seem less timeless. The science-fictional precedents are likely the Olaf Stapledon novels mentioned in the introduction.



Voices of Time by J. Ballard (1962)

Ballard is a big name in new wave sci-fi, but I've not read his works. This collection of short stories is written better than sci-fi on average, but there is also something a bit dull about it.

The stories dwell on desolate environments, with the emphasis more on fantastic or magical realism than science fiction proper. This is bit like Twilight Zone but with less twist endings and more about the tone and poetic sentiments.

Despite having been written before moon landings, there's surprisingly little space optimism in these stories. Astronauts rarely leave earth and if they do, it hardly results in anything good.

Philip K. Dick does come to mind, but although drugs, fractured realities, dysfunctional relationships and insanity weigh heavy in Ballard's text, it is more matter-of-fact and lacks the kind of mental streak that Dick's novels have.



Triplanetary by E.E. 'Doc' Smith (1948, serial from 1930s)

An atomic explosion, sexy agents, nuclear holocaust, a billion-year plot, all in the 20 first pages.

A Lovecraft-induced idea of beings beyond time and space who battle their cosmic war and poor Earth is in the middle of it.

This is an intriguing starting point, but it turns to rather mundane pulp sci-fi. The series, I'm told, is instrumental in introducing the now standard ideas about spacewar with energy weapons and shields, battle formations and such. Star Trek further codified these ideas and gave them a stronger visual form, but it's basically all here already.

If I'm not wrong the early computer game Spacewar! was inspired by Doc's space battles. Also, there's a space battle simulating board game that carries the name Triplanetary. So, the cultural repercussions of Smith's worlds are not to be underestimated.

However the cosmic setting tends to descend into uninteresting spacey fights with damsels saved left and right. Possibly the later sequels redeem this, but with this book I didn't get the appeal of Smith's universe. Perhaps it was more important in inspiring Asimov.

Speaking of Asimov... well, I'll save it for later.


Tuesday, 14 April 2020

Old Machinery Phone

Features:
  • RS-232 for all connectivity needs!
  • RCA composite, should you need external display!
  • Ear, Mic, Rem for external tape storage or headphones/microphone!
  • Atari 9-pin joystick/mouse/paddle port!
  • PS/2 keyboard connector!
  • 9V PSU connector!
  • 320 x 200 display + borders!
  • Menu operation / game buttons!
Feel free to build one yourself.

Thursday, 5 March 2020

Icing on the Cake


That's a very rare Commodore 64 model... one could even say, unique!

Yes, I've been working on this desktop C64 case idea for a while. It is loosely modeled after the C128D cover. The front panel was a bit unsatisfying so I finally went and made something that is more in the spirit of the computer.

I'm making these from chipboards that are maybe more commonly used in building dolls houses. It's easy to cut and sturdy enough for these computer cases, if some thought is put into the structure.

I'm not too keen to do truly wooden cases, partly because I don't like the look and partly because I don't have the equipment and environment to do them properly.

I'll need to repeat that what I'm doing here might be a fire hazard, and the dust these chipboards produce could be a bit bad for the computer too. So consider these as prototypes.

Some work-in-progress snaps:

It fits!
The new front panel is a separate "hat" that can be detached. I made it from the same materials as the cover. I'm again using the ready-made edges of the sheets to define the front upper edge of the hat so it would be as smooth and clean as possible.

Gluing the three long pieces together was not the easiest task as they are not easy to support.

It can be removed!
But why do the front panel as a separate piece?

I wanted to paint the entire case, which would have looked nice enough without the panel, BUT when the cover is opened it would have left a visible seam/crack. With this "hat" I can model and paint the case in the future with less problems.

Next up was the slice in front, which was a precision job with the saw. I used a ruler to drag two traces with the saw, then they were properly cut. Another route might have been to make them as two pieces in the first place. I felt better with this approach.

Talking of routes I have a hand router somewhere but did not think to use it here.

The SD2IEC is at the left because it is nearer at my desk.
The above image shows how the SD2IEC SD card would show if there was just a 3mm cover. There should be enough of the card visible to bounce it back.

I made a backpanel for the front panel (if that makes sense) so the cart is less visible than in the image above. It still bounces out but not as easily as I'd hope. I'll perhaps adjust the SD2IEC position a bit.

Also, the bolts at the bottom of the case were somewhat in the way of the "hat" so I had to do room for them. In hindsight, these could have been made through-holes, but maybe it would have been a bit too complicated.

This goes to show how earlier choices affect later ones, as I didn't plan on doing the hat at that stage. For purposes of design, it would make sense to rebuild the entire case now.

Making room for the bolts
Talking of hindsight, or perhaps the lack of foresight, I forgot I needed the hole for the Commodore 64 logo, which was more difficult now that the panel was 6mm thick. Urgh.

The Commodore 64 badge/nameplate was ordered via eBay from Poland.

By the way I used some wood putty to smooth the ends parts, because I glued them the smooth side inwards. I hoped the surfaces would stick better. This meant they had to be sanded and even then smoothed out with the putty.

Cutting the hole for the nameplate
Three millimeters for the groove is a bit too deep to look exactly like the groove on C128D would. Still it would be possible to "fake" the whole C128D look quite accurately using these same DIY techniques, but here I'm just giving a nod towards that original design.

For example I left out the floppy drive opening although I considered it for a long while. The SD2IEC is in different position anyway and this is a Commodore 64 after all.

The grey primer spray
Next up was painting. I sprayed the object first with a gray primer and then painted a white overcoat, giving a gentle sanding in-between. The paint seemed to react better to the wood-putty smoothed parts.

The first layer of spray white already reveals problems in my approach. The front side is as I expected but the paint mercilessly reveals all blemishes, seams and inaccuracies in the corners and sides. I was also too eager to paint it in one go, whereas gentle layers would have worked better.

Needs sanding and more paint.
Sanding and using more thin layers improved things. The more paint layers it has, the better it covers, but it also has a danger of becoming uneven and inaccurate even on the flat surface. I chose not to paint the whole box as yet, because I may need to do changes to it.

The groove does not get enough paint really, but as it's not very visible I don't care too much.

The rounded corners are always challenging. If they don't succeed in one go they are a bit difficult to fix. All looked fine after doing the initial 45 degree bevel and smoothing it out, but subsequent sanding broke things a bit. I managed to fix it somewhat for the end result.

Ground paint and three layers of white spray.
After a few layers of paint it is quite satisfactory. It's obvious it's not plastic and not industrial, but good enough for now. If I get to do something similar again I'll already know a bit better. If I think about the earliest "trash board" version of this case idea, I've come a long way!

There's still work to be done, especially on the backside which I've been too embarrassed to show. I now feel the design of the case should begin with solving the backside rather than the front, but it's too tempting to go straight for the more interesting workstages.

Wednesday, 12 February 2020

Fooling around some more with THEC64 Microcomputer


I already made some (premature) notes about THE C64 emulator machine. Here are some of the things I have been doing with it.

Before I go further, just to wrap up:
  • Just a teeny bit laggy, but the framerate seemed smooth
  • But be mindful of the 50hz - 60hz capability of your display (60hz PAL is unreal)
  • Can do VIC-20 mode too
  • The joystick is bit clunky but has those nice extra mappable buttons & the useful menu key
  • Does only HDMI, not even separate audio
  • ... but a HDMI-VGA adapter with audio split can help, but obviously a 50hz display is needed for smooth and correct speed.
By the way I have not opened my THE C64 yet, I've seen the pictures and it's unlikely I will do any mods in the near future so I'll let it be.


CJM file-specific parameter text files

Just saying what the manual says. If you insert a memory stick into THE C64, you can load disk images (.d64) and program files (.prg) directly from the stick.

If you put rambo.d64 disk image on your memory stick, and have a rambo.cjm text file at the same folder, you can create a joystick configuration that maps the weapon change key (space) with the extra joystick buttons.

X:64,pal,accuratedisk,driveicon
J:1*:JU,JD,JL,JR,JF,JF,SP,SP,JF,SP,B,C,JF,4,5
J:2:JU,JD,JL,JR,JF,JF,F1,F2,JF,1,2,3,JF,F3,F4

Games such as Mercenary, Elite and any flight simulators can be obviously enhanced by this feature, even if these games often have far more buttons than the joystick has.

My palette is a bit iffy today, can't care to fix it
But certainly speed controls in Elite, missile target, launch & unarm keys could be configured this way. (It's just that C64 Elite is a bit crap.)

I also found the joystick a bit physically clumsy for these extra buttons, so it wasn't so enjoyable with Rambo. But there's no stopping using a proper 2000s USB gamepad with four-button cluster and shoulder buttons. How authentic is that... well, there were gamepads back in the day too.

For Twin Tornado, I tried this:

X:64,pal
J:1:JU,JD,JL,JR,JF,JF,F1,F2,JF,1,2,3,JF,F3,F4
J:2*:JU,JD,JL,JR,JF,JF,CO,/,JF,H,Y,A,JF,4,5

I put throttle controls to triangle buttons and wing adjust to the two leftmost of the tiny buttons. Third tiny button turns on the combat sights. Note that for "comma" I used CO, as obviously a real comma might mess the syntax.

Twin Tornado has serial head-to-head mode but this can't be done with THEC64
The simulator boasts surprisingly fast wireframe 3D. To fly the Tornado, Increase throttle to max, release wheel brake with SPACE. Pull up when appropriate. Once in air, switch gear and flaps with T and R respectively.

As a variable-sweep wing fighter, the Panavia Tornado can pull its wings back. Switch them to a position of 68 degrees and then you can reach Mach 1.0+ speeds. The wings can't be switched back unless you drop speed.

To get Digital Integration's Tomahawk to respond, I tried this:

X:64,pal
J:1:JU,JD,JL,JR,JF,JF,F1,F2,JF,1,2,3,JF,F3,F4
J:2*:JU,JD,JL,JR,JF,JF,A,Q,JF,S,W,P,JF,4,5

The throttle and collective controls are mapped to the triangle buttons and the two first tiny buttons. The third tiny button swaps between weapon systems, once they have been activated with key C on the keyboard.

To get that Apache up in the air, increase both collective and throttle until the copter starts to rise. Then you can turn the nose down a bit so it begins to move forward. Then re-adjust the throttle/collective to maintain level flight.

It's a bit hard to tell 8-bit flight simulators apart.
I noticed that trying to use the mapped keys and joystick in very complex motions, it may inadvertently activate a key that's not involved at all. Such as Pause in the case of Tomahawk. This might have happened with the real keyboard too, it's just that back in the day the keys did not receive these combinations so easily.

I have also felt the joystick gets a bit stuck once in a while. Perhaps it will loosen up a bit over time.

They really added some weight to it! Should have weighted the shaft, though.



Cartridge & Disk images

I was interested in whether THE C64 can accept cartridges, not just games but things like Action Replay VI or Final Cartridge III.

Long story short, AVI did not seem to work whereas FCIII did. It's one way to access a machine code monitor. I'd prefer the AVI monitor, though.

I encountered some hiccups with more complex disk loaders. I was a bit saddened that the Ultima IV remaster D81 image (a large-capacity disk image) would not run further than the intro screen.

So, the utility cart support in THE C64 is a bit more haphazard and might not behave entirely as one would wish, but it's not all a loss.

On the plus side, "easyflash" carts work and many important multi-disk games have been modded to work on these images, so welcome Project Firestart and Ultima IV remastered after all!

I felt that the savestates are unlikely to work on anything that sounds a bit non-standard, such as these cart image games.

The few demoscene intros I tried appeared fine, though borders were cropped at times. There is another display mode in THE C64 that shows more of the borders, but may result in a smaller mid-screen area for games.

I perhaps wouldn't use THE C64 for running demoscene demos anyway, as there is no support for CRT display and the SID emulation is what it is.


Disk image file handling

You can have C64-compatible .PRG files directly on the memory stick, but many games come in the .D64 disk image format, which can be a container for multiple C64 files.

THE C64 facilitates loading these disk contents directly from the menus (the first file will be loaded), but to have more sophisticated handling of these virtual floppies you need to use BASIC.

As THE C64 by default mounts an empty C64 floppy image in the .D64 format, it's easy to save BASIC code snippets to the disk using

SAVE "MYPROG",8

and load them back with

LOAD "MYPROG",8

It may make sense to backup that disk image once in a while.

You can check the contents of a disk image with

LOAD "$",8

followed with

LIST

Remember that reading the directory with LOAD "$",8 will destroy the current BASIC program in memory!

Removing files is a bit trickier, and you can't simply overwrite a file by saving it with the same filename. Three commands are required (each followed with return):

OPEN 15,8,15
PRINT #15,"S0:MYPROG"
CLOSE 15

S0 stands for SCRATCH0.



BASIC

Transferring code from PC over to THE C64 is not a very exciting prospect, you have to use the USB stick and that kind of slows things down a bit.

Once in a while it is fun to play around with the BASIC, although I rarely have patience to do anything large with it.

The trade-off with the 8-bit interpreted BASIC is that it's very easy to start a program and get things going, but as the program gets larger it becomes slow and difficult to organize.

So it might be good to have some kind of rough paper plan for the program as it grows. Experience with other languages is also a good teacher.

There are also ways to embed forethought into your program. Although you can always clear the screen and set the colors with a PRINT statement...


a subroutine could be called instead.

10 GOSUB 9000
100 REM main loop
200 GOTO 100
9000 REM clear screen subroutine
9010 PRINT "[clrhome][white]"; : REM use the real characters
9020 POKE 53280,0 : REM border black
9030 POKE 53281,0 : REM background black
9100 RETURN

So, every time you want to clear the screen and reset the colors, use GOSUB 9000.

The downside here is that you might not remember what GOSUB 9000 stands for, and the program becomes less readable. Unlike ZX Spectrum, C64 BASIC does not allow the use of variables as label names (which might slow down the calls besides).

So, use discretion!

Remember that editor screen codes can be inserted in the BASIC " quotes.
So, if normally pressing SHIFT+CLR/HOME clears the screen immediately, typing it after a " will enter the character code instead. Again closing the quote with " will again make the key work directly. Cursor keys, home/clr cursor and reverse on/off can be used this way.

So it's one way of positioning the cursor:

PRINT "[clrhome][down][down][down][down][right][right][right]HELLO"

[clrhome] implies pressing the key clr/home and so on. This would position the text down 4 rows and right 3 columns from the top left corner.

Then, later you can consider whether the screen-clearing has some kind of effect in it or not. Only changing the contents of that one subroutine you can change all screen clears in your program. Or replace it with a machine code call, etc.

There might be subroutine for "press any key", so it could always be called the same way and display that message too.

The subroutine call overhead is significant in BASIC, so it might be better avoided inside the main loop of an action game.

For displaying characters more directly, sometimes POKEing the display may be better than PRINTING character codes.

10 X=20
20 Y=12
30 POKE 1024+X+Y*40,1

This should display an 'A' at roughly at the middle of the screen. Bear in mind that generally PRINTing is faster than trying to combine many characters through POKEs.

Reading the joystick from BASIC is not hard. You have to decipher all the directions one at a time in case there are multiple directions and buttons pressed at once.

10 J=PEEK(56320)
20 IF (J AND 1)=0 THEN PRINT"UP"
30 IF (J AND 2)=0 THEN PRINT"DOWN"
40 IF (J AND 4)=0 THEN PRINT"LEFT"
50 IF (J AND 8)=0 THEN PRINT"RIGHT"
60 IF (J AND 16)=0 THEN PRINT"FIRE"
70 GOTO 10

In case you only need two opposite directions and no fire button, direct values can be used:

10 J=PEEK(56320)
20 IF J=119 THEN PRINT "RIGHT"
30 IF J=111 THEN PRINT "LEFT"
40 GOTO 10

This would spare the interpreter from making more calculations than needed.

The additional keys (and keyboard altogether) of THE C64 Joystick can be read like this:

10 GET A$
20 IF A$="Y" THEN PRINT "THEC64 EXTRA BUTTON 1"
30 IF A$="N" THEN PRINT "THEC64 EXTRA BUTTON 2"
40 IF A$<>"" THEN IF ASC(A$)=13 THEN PRINT "THEC64 EXTRA BUTTON 3"
50 GOTO 10

This assumes a THEC64 joystick with the default config of Y, N and RETURN. Of course the keys can be used too. I'm unsure if the RETURN key could be done with some other means, but at least that works.

Unless the joystick has been configured to other keys, the triangular buttons do nothing.