VNC, ssh, remote, Android, n00b

For the most part I've found ssh enough for connecting over home network, for file transfer purposes. But sometimes it's just helpful to share the screen, keyboard and mouse remotely.

Not every resource is on the same computer, and in the case of physical drives it might not even be desirable. I need to use Processing on the Mac, but it does not properly compile applications over the command line in the way I'd want to, and making Handbrake crunch a video from a drive that only exists on that other computer is a bit handier when you can see what's going on.

Of course on occasions I could just switch the display to show the other computer but then I'd still need to switch between two mice and keyboards.

So, VNC (Virtual Network Computing) screen sharing to the rescue. This needs the viewer software to view the other computer screen, and a server on that other computer that 'feeds' the screen to the viewer.

I used RealVNC's viewer to get the easiest results. With the Mini Mac, the VNC server was built-in and could be activated by ticking one box in the settings.

With Linux computers I found some hurdles, which on one hand might seem surprising, but perhaps really not. Whereas VNC viewer from RealVNC can be recommended, I did not go for the server, as it requires a subscription.

Being a newbie in this, I guess some protocols don't quite fit each other so it's not always obvious which server works with which viewer. Messing with TigerVNC did not produce the results I wanted, although it probably should do the work. Some Linux Mint versions have vino, but it is no longer part of the Mint install since 19, and I'm not sure I ever got that working either.

So, x11vnc as the server. Not sure if all the above solutions actually rely on it in the end somehow, but at least by using this simplest advice I could also connect the Linux Mints together. I rebooted the computer to get the server properly working.

It gets meta as I edit the blog post locally and have an eye on Handbrake converting video on the other computer. VNC viewer interface in the middle keeps track of past connections.

After this the computers can co-operate within the home network without additional hassle.

The Mac may whine a bit about a missing keyboard, but as you input something this will go away.

The keyboard mapping is one thing I've not yet figured out well, as even rather simple characters like _ and @ can be difficult to achieve straightaway, at least when using a Linux to get over to the Mac.

Predictably, video over VNC is not such a bright idea but is kind of doable, at least for the purposes of checking the contents. I encountered a hiccup when using VLC video player, trying to bring up the context menu with right mouse button shut down the screen sharing server. Hmm...

Playing 3D games is even less useful, but I just had to have a go at Tomb Raider from 2013. It was obviously very choppy even in a resized window, but what made it finally unplayable was that the relative mouse motion was not correctly interpreted.

For a while the silly me thought I need to use the IP address for the connections, but the computer hostnames do just as well and better, as the address can change.

Out of curiosity I also checked the situation for the Android Galaxy phone, as the VNC viewer is also available there as an app and works ok. Doing this the other way might be interesting but at first glance at least it seems to be a bit trickier to get the server running on the Galaxy. Arguably the VNC viewer over Android could work as an elaborate remote controller for another computer.


Other Android stuff

Speaking of remotes, the Android app remote Unified Remote (and the download for the corresponding server on Linux) DOES act as a remote way for moving the mouse pointer. I paid a little fee to get rid of the ads and it does seem to work as promised. This might reasonably work as a remote control for that laptop sitting next to the TV.

These softwares don't look very appealing, but you're not supposed to look at them, really.

After somewhat clunkily enabling the server as a browser app (!?) the movement on the Android touchscreen are transported to mouse movements on the target computer. There are also other functionalities such as launching software etc, but I'm not going over that stuff now.

As a hilarious experiment I could use the remote to hover the mouse pointer over to the VNC viewer window, to control the computer where the unified remote server is NOT running.

Somewhat against my expectations, the Unified Remote could not work reliably by having the server directly over the computer where the VNC server is also running. The pointer would fidget somewhat but would not move. Oh, well.

When it comes to having ssh over the Android phone, there is apparently a solution for accessing the Android system directly via cable and the developer mode. But for my purposes I have found it enough to be able to access the phone through wifi and ready-made Android helper apps.

Left: SSHelper server running on Android. Right: Termius, using tiv on another machine to display a png over the command line.

Termius acts as a simple terminal on the Android so you could access your computer with it (after enabling the ssh server obviously), whereas SSHelper is more comprehensive. I suppose it is a minimal linux-within-linux, as it sets up a small server on the Android, complete with a set of useful command line tools such as busybox.

Both have a kind of 'virtual' mapping of the Android filesystem so you can copy photos etc using scp  from the command line, and I had some success with remotely opening the folders through caja too. Nano on SSHelper together with Apple Bluetooth keyboard might be the closest to having a reasonable text editor on the phone.


Just something more

On another remotely related note, the Terminal Image Viewer tiv (from here) is quite good at displaying bitmaps over the command line terminal itself, using unicode blocks and colours to best effect.

A Big Fat ANSI Deal

Sadly it's not able to accommodate for a terminal wider than 80 characters. That might have helped reproduce 8-bit graphics and PETSCII jpgs rather faithfully... again, it's ok for checking a bitmap over the terminal.

Crafting chesspieces

Barleycorn is a common name for a highly ornamented, tall red and white chessmen, elevated on an urn-like pedestal.

One might think the name 'barleycorn' has something to do with the tallness or shape of the pieces, but apparently it refers to the decorative barleycorn leaf motif found on them. So whether a set without the decoration is truly a barleycorn chess set I can't say. But it's a handy keyword for searching a certain type and I'll use the word here loosely to describe mine.

I've longed for something like this, but barleycorns are quite expensive (200 EUR easily for a modest, complete set) so I started thinking whether I somehow could build my own, even if it wouldn't be as decorative.

I don't have a lathe. The main idea was that the pieces could be created by fitting ready-made parts around a central stick, like beads in a string. Visiting a few hobby shops, I looked for ready-made wooden parts that could help in this.

First phase

After I discovered a part that would work as the base for all pieces, I was already more optimistic. I felt a larger set would be more forgiving for inaccuracies, so I chose a 35mm base. As barleycorns tend to be placed much more tightly than any FIDE regulations now say,  a 50mm squared board should be good for these.

I didn't give much consideration to finding larger bases for the King and the Queen although it is clearly a feature of the barleycorns and most chess sets.

Is it a chesspiece or a sci-fi rocket? Here the barrel is cut and filed out of a cube.

I bought a bunch of the ready-made wooden parts I could find from hobby shops, trying to figure out how they might be used together.

After having a pool of parts, it was time to scavenge more definite images of barleycorn-type chessmen from the internet. I did not seek to replicate any one set in particular, instead I picked features from different sets that I liked.

Of course it was important that the details could be recreated with my parts pool. It was a relief to find out not all barleycorns are especially decorative and I could take that as a guideline.

I needed to ensure the 16 pawns would not require much manual work. I'm happy to note this stage was quite successful, as the pawns are the simplest part of a barleycorn set in any case.

Left: a nearly complete queen, Right: demonstrating the stick-system 

Each pawn and piece has a narrow stick as a central axis. This meant drilling parts that didn't yet have holes in them. Especially the pedestal part required some care as it's not easy to drill into a convex end.

All the collars needed drilling too, finding the dead center was a bit tricky. The small brittle pieces break easily when drilling. For the tiniest collars I just had to patiently drill 1-millimeter pilot holes before making the 2,5 mm holes.

Sample of the parts pool. Note the absence of holes in many of the parts.

In the beginning I made many mistakes, often compounding so that some pawns were unacceptable and had to be remade. Poorly supported parts may move as a result of the glue drying process, which I also forgot to check.

I built a drilling jig out of a wooden block which helped in getting the holes more accurate. This became necessary as I noted I really have only so many bases and 32 perfectly drilled bases are needed.

One trouble I had that there really were no parts for inverted curves (e.g. the "scotia" in antique pillars). I emulated these by using a combination of different collar pieces.

With all the easy labor behind me, I begun work on the knight horse-heads. Here wood putty was somewhat useful as the shapes could not be cut very precisely. I was not overtly happy with the knights, but I needed to make progress on this most difficult part before my enthusiasm runs out.

And run out it did. After I finished the four knights and whittled one bishop head, it took a better part of a year before I could find it in me to continue with the set.

Carving the bishop-heads. The white colour is from gesso primer.

Second phase

With renewed zeal, I sat down and whittled the 3 missing bishop heads and started planning the rooks. Here I drew more accurate sketches, because I had lost the sense of the project and the proportions. The rook designs had been previously unsolved, but I had decided they ought to be elevated. (Less common in barleycorn sets but it has been done).

The drawings were useful in finding the proportions for the rook although in the end I improvised some choices.

The tall rooks ought to go without pedestal really.

Instead of forming the rooks out of solid wooden blocks (my first plan) it struck me that with a proper cutting tool I could create the rooks out of 4mm plywood circular plates.

I had seen such a tool a while ago and now I bought it. It's meant for cutting holes into drywalls and the like, so the cut-out is not really the intended product. But it worked well enough with the power drill and the 4mm plywood. The resulting edges were somewhat torn, but filing and sanding them together I got them quite smooth in the end.

I tested each plate size to find out what my options are and then redrew a rook design on a millimeter paper using this knowledge. Only the center part would be cut out of the solid blocks. Cutting dozens of plates was a bit boring, but likeable procedure.

Measuring plates. The leaflet only supplies the hole inside dimensions!

With this tool the central drill was 6mm fixed diameter. This was helpful for gluing the plates together around a 6mm drill bit, but as the 6mm hole was not suitable for the narrow central stick, I also needed "converter" parts. I won't explain this in more detail.

I used the plate-approach for creating the royal pieces too. I was unhappy with my earliest ideas (see the first picture) and chose to do a simple straight barrel that probably looks better.


The outcome

There is something cartoonish about the designs, especially the rooks are very huge, much larger than the base they are standing on. This is not something I've seen in any set, as the rooks usually are not elevated, and when they are they certainly do not exceed the base dimensions.

So I could also make some original choices. Possibly I also felt this cartoon approach gives the set more character than a failed attempt at copying some existing design.

I did not plan the whole set before looking at it all together so it was fortunate the pieces work together as well as they do. But even during the process I could match certain pieces to work together, so it was not all done blindly.

The set is not especially heavy. The king and queen are sufficiently weighty, but the pawns and other pieces are somewhat light and unbalanced. I could help that little with leveling the base bottoms a bit.

Board supplied by Marq, a nice fit.

Small amounts of pieces in plastic bags turned out to be quite expensive in total, so it's very likely I could have instead bought a somewhat battered antique barleycorn set off eBay with the sums! Well, it's more interesting to try to make your own.

There is still some painting to do, and I'll do more close-ups when the finishing has been done.

C=key adapter 3.0a quick look

About a year ago, I had a go at rigging an Arduino to work as a PS/2 adapter. That adapter is working, but the software needed patching. I got it into semi-decent state but it still leaves a lot to be desired. (Shift+cursor keys etc work a bit randomly.)

In the meantime, I also ordered this ready-made solution from Retro Innovations, the C=key 3.0A.

Apart from modest soldering skill you will need some sense in building electronics, as the (not included) instructions need some deciphering. But if you follow them step-to-step precisely it should come out good. I guess you can also order them soldered. I perhaps wanted to avoid having the PS/2 connector positioned, but as it turns out it was a better idea to use that part anyway.

The board has provisions for both female & male 20-pin connector. I could have avoided soldering the other part in, had I given it a bit more thought.

Because there was a capacitor in the way, I could not fit the board directly on the C64. So I went for a long-ish drive cable. I once found a bunch of these from a flea market.

Bonus points for including proper holes in the board for easy attachment in your own projects. I'm not yet sure where I'll use this.

The adapter worked at the first attempt. My impressions were that this is much smoother and bug-free than that DIY board.

But it turns out this C=key adapter is not without problems either.

Although the key mapping felt great at first, I soon found the cursor keys did not work. Then I learned I need to change the keymapping style. I can enter the "menu" by pressing CTRL+ALT+BACKSPACE.

There,

1. C64 Symbolic
2. C64 Positional
3. C128 Symbolic
4. C128 Positional

(CTRL+ALT+BACKSPACE exits the menu.)

Using selection 1. (C64 Positional) the cursor keys started working and all keys are mapped according to the PC keyboard. ...according to an US keyboard, that is. Sigh! So the keys work but everything is in an alien place.

While testing the keyboard I sometimes came up with gibberish. I also managed to get the adapter locked quite easily, which often followed from pressing Return, but other keys too. Using the CTRL+ALT+BACKSPACE combo a few times the adapter recovered.

The site does say "This is still considered a project, not a complete product. I’ll try to help with issues, but it’s still a work in progress."

I did clean the adapter up and wiggled the cables a bit and got a better response out of it. Who knows, it might be my soldering and construction was a bit botched. I'll have to make sure the board and the cable do not move when pressing the keys.

These were of course the very initial responses to this adapter, and further examination should reveal how well it works in the long run. Possibly, a PS/2 to C64 keyboard adapter is a device that simply cannot be made to work 100% reliably and in a satisfying way, but this is already quite good.

MO28UO mouse

This MO28UO is an IBM-branded mouse from early 2000s I suppose. Looking around it may have been sold as Lenovo-branded too. Certainly it would fit the Thinkpad colour theme...

Although I like the slightly old-school weight and speed of the mouse, I noted the wheel is prone to mis-interpret the direction.

I opened the mouse and took some images.

The scroll wheel is not based on an optical coupler, so the wheel doesn't have holes. The axle had accumulated some dirt and hairs, which I removed.

I didn't expect it to matter much in this case.

The wheel part is simply lying on top of the wheel button switch, which might already be a source of some problems.

After cleaning, the wheel might have improved slightly but I suspect the mechanism is simply not that good to begin with, or it has become worn out.

Although a tactile/audible response from the wheel is a good thing, this one's a bit too noisy for my tastes.

So I guess I'll abandon this mouse...

PETSCII processes

Looking at my stash of unfinished and experimental PETSCII character art files, I found some Digiloi work-in-progress materials I had forgotten.

Here's a screen where the main character was fleshed out:

The nice thing about this image is that I've collected the versions in a chronological order, from left to right.

As can be seen, the first attempt is ridiculously stupid and a 1980s BASIC game might have been forgiven for having such a crude shape in it.

I guess the solitary guy is the one where I felt I'd "got it", although as can be seen it's still some way off. Note also the sketching of background graphics.

This is a frame from an animation where I drew the running frames over a scrolling floor. Using Marq's PETSCII editor it's quite easy to do animation.

Not sure if I ever planned to do a scrolling game, it may simply be the animation loop was easier to test this way.

I also can't remember if the one in the middle is an alternative design based on the one on the left, or the other way round.

That laser shape was on for quite a while before I saw it would not work over a background.

I think the huge gun finishes the character, it's part of the character really. Parts of the previous designs went into the bad guy graphics.

Here are the original "sprites" for the main character, which I thought were finished. In the end I never used a "stand-still" frame in the game.

However, testing the player character over a background, it did not quite work. I changed the colour to green which stands out better against a dark-ish background. Then the tiny details and rounding had to go too, because they would generate ugly black outlines.

This snapshot from an early build shows the problem. Even the finished game has some black outlines.

I also found some extra background tiles, most of which did not find their place in the game:

Another background-related image shows the "running in a dark forest" idea that sort of defines the first moments of the game.

As this is an early build, the graphics routines are tested over a static PETSCII drawing. When I moved over to tile-based rooms, I had to compromise with the trees and the style became quite different.

Although this is just a test, I also toyed with the idea of beginning the game with a bunch of these guys running alongside the player, then disappearing "somewhere." I guess it would have been simply confusing.

So there it is, everything I could find!

Zoo 2019

Some recollections from my participation at the Commodore 64-only demoparty, Zoo, held at Akaa during 4th-6th of October. Again, not really a party report, I'm mostly talking about my own works.

Not the general theme of the weekend.

My pre-party mood was a bit pessimistic, after not catching a hotel room. Another thing I worried about a bit was not having any prods for the compos by the time I arrived. But I managed, as usual, do something on the spot.

It turned out the common accommodation at the nearby building was much better than I expected. The airbeds are cozy and the space was not jam-packed. It actually has a few pros compared to the hotel room, mainly it is very silent (the party noise won't reach there) but it's also cheap. If only I hadn't forgotten to pack the roll-up bed...

The unsuspecting Viiala neighbourhood, somewhere in Finland.

SID

SID was a general theme of the event. Grue gave an overall 'mythbusting' session about the SID and played concrete examples of playing the same songs on different SIDs. The differences were quite drastic, in some cases the wrong SID can even hide the lead instrument.

The bottom line is there is no overall 'best SID', some songs sound better on the 6581 and some better on 8580 - not even always the one the author intended! Your ears be the judge.

Flex gave a workshop on Goattracker. It's a complex piece of software, and SID is complex, so I doubt anyone could have started up Goattracker there and then and gotten finished results, but as I had at least some previous experience I could pick up one or two new things.

I mused that to be able to do SID music on C64, you have to have an understanding of many things, not just one thing:

• About SID features, behaviour and constraints
• The convention of "a SID" as a tracked format on Commodore 64
• How Goattracker (or some other editor) works

And maybe some musical knowledge too. Well, anyway, these SID presentations encouraged me to think that it does not matter so much if I don't achieve the perfect iconic SID sound, so I started tinkering on a crappy tune following some of Flex's tips.


VIC-II

Dr. TerrorZ: Light

I had a Multipaint presentation, but I found I couldn't really 'teach' anything at this point so I simply told what the program is for and showed the main features of the new version. This led me to have chit-chats with various sceners which was maybe the best outcome of the presentation.

The software is now already quite known in the scene but not everyone will adopt it. But I don't think I'm bragging if I say it is a good introductory-level software for making C64 graphics!

First time i saw the zoo from this angle.

My graphics entries were even less successful at the compos than last time.

Normally parties tend to go so that I pick a half-decent half-completed image from the archives and finish it, but this time my folder was rather empty. I also spent a lot of time getting a demo production working (see further below), time taken away from drawing.

The bitmap work was a quick experiment with drawing using wacom tablet with Multipaint.

Dr. TerrorZ: Spacesplash

I preferred the initial quick lines and was even afraid to lose them with too much detailing. So I actually like this image quite a lot (perhaps because I did not have time to grow tired of it) but it didn't go down that well in the compo.

Admittedly, a further session would have helped it a bit. (That's a damn long arm!)


CPU

I was greatly impressed with the amount of quality demos at Zoo. I recall the dry year 2013 when even a crappy PETSCII demo written in c by some idiots could win.

The Finnish Gold 'returning' with a full-size demo should/could have been a bit more grandiose. Although it was presented at the show-stealer last position, it was a bit on the short size and petered out in the end. Artline Designs demo Out of Contex delivered better overall and was the clear deserved winner. The Void Mind was still incomplete at the party but is clearly a memorable demo. PWP's Metadimension was an atmospheric generative-algorithmic work.

In the drunken tired atmosphere there was a tangible mood of having passed a turning point and a feeling of living amidst a new rise of the Finnish C64 demoscene. In a more sober hindsight, it's perhaps not all there yet... X'2020 will mark the spot.

I submitted my modest Nine Rings one-filer, based largely on re-writing Digiloi game routines. Digiloi object drawing system is naive in that it draws characters and colours separately to two buffers, and only combines them at the screen. Now I have the graphics stored in a reverse interleaved order for the drawing, and the buffer is also interleaved. So I could have 9 Digiloi-style 'sprites' on screen.

From Dr. TerrorZ: Nine Rings

The PETSCII mode is forgiving in that I can go with 1/3 framerate and it still looks kind of acceptable. The routine was in place before Friday but I did the scripting, music and some additional graphics at the partyplace.

After hitting the ring theme, my goal was to visualize the One Ring to Rule them all... poem, giving an outline to the demo script. But as time ran out I could not add more graphics and it was left more abstract. It was well enough received.


I/O

Apart from the above presentation, Kasettilamerit made an appearance, and the bid for making demoscene a part of UNESCO World Heritage was also presented here.

At the location I bought an external kernal replacement cartridge, a REX 9628 clone. Equipped with JiffyDOS and JaffyDOS and other jibba-jabba, I'm hoping it will make an interesting companion to SD2IEC or that Raspberry floppy emulator. More about these later.

Also I got a K&A paper magazine English edition with a Digiloi review :)

zooparty.org

Zoo 2019 at CSDb
..at Demozoo
..at pouët

(At the time of writing the listings were incomplete)

Multipaint 2019: ULAplus, QL, pull-down menus and more

Multipaint 2019 has been long in the making, but there are quite a lot of tiny and bit bigger new things.

Get it at http://multipaint.kameli.net/

In this blog post I'll discuss some of the new features and add background detail that wouldn't fit the webpage and the manual.


Application behaviour

The application window is no longer scaled according to the chosen target platform.

The uniform sized application window helped me get rid of the java-based dialogue box when running the application, and you will see an in-application menu for choosing the platforms.

Because of this it's also possible to change the platform (FILE / NEW MODE) on the fly, so you don't have to re-run the application just to try a different platform. Don't expect it to convert your images on the fly as yet.

In the future Multipaint will likely suggest a mode change when loading a file for different platform, it's no longer hard to do but I didn't want to do the testing now.

I have removed the application window zoom size 1 (mini) from the prefs, as supporting it became a bit problematic. Tell me if you really, really need it.

There are now more tricks to access the "prefs.txt", this may help Macintosh users who have had problems with the preferences. If Multipaint is run from terminal, it outputs file-related messages to the console, hopefully helping solve these problems in the future.

Overall the program might not be as fast as before. I changed some convoluted code to something that is easier to handle, but likely a bit slower. I was also reluctant to optimize the all-new window and menu drawing routines.


File safety

Multipaint 2019 imposes some (conventional) rules for increased safety:

• File overwrites and mode changes will have to be confirmed.
• Multipaint reminds you of unsaved work when loading a new file.
• Unsaved pages are pointed out when quitting (However, see note below).
• Using “clear all” will reset the filename.
• You cannot UNDO past a point that would require a filename change.

A page is  “unsaved” if a tool has been used on the page, it's currently no more clever than that.

The UNDO limit may sound like an overkill but it's been the only real source of lost work for me personally. Some have reported lost work due to clicking wrong icons or window close button accidentally.

NOTE: As much as I tried, I could not get Processing/Java to reliably bypass the window close button on the exported application. The work on this continues.

In the meantime, Multipaint tries to save pages automatically on exit, the files are called multipaint_auto_page1.bin and multipaint_auto_page2.bin, saved in the Multipaint application folder.


Drawing tools and magnify mode

There are more magnify levels (5 including the full view), making the mouse wheel magnify much more fluid. It should work a bit more like you would expect in this type of program (e.g. Krita) and to me it has quickly become the standard way of zooming in and out. The old magnify tool icon and magnify keys work like they did before.

I'd go so far as to say a two-button mouse with a wheel (doubling as a middle mousebutton) is the optimal tool for using Multipaint. Well, at least that's what I'm using all the time. However, the new style interface means the program should be more useable with a drawing tablet (wacom).

I cautiously added an auto-scroll for the second phase of two-phased tools such as rectangle and line. So, if you drag these tools outside the entire Multipaint window the mag window ought to scroll a bit. I'll probably improve the panning options in the future.

You can now reset your tool options by pressing SPACE. This means if you have a cluster of switches on (mirror, recolor, dither etc), and you are not quite sure why you can't draw properly, just hit SPACE and you will get back your one-point, one-color brush with all the switches off.


Pull-down menus and interface changes

Multipaint 2019 introduces drop-down menus, much like in Amiga Deluxe Paint. (Or nearly every other application for that matter!)

With the new menus I can add options and dialogues for functions that have been a bit too well hidden. In the future, the dialogues also help in adding features that would not fit well within the icon/keypress logic. It's also a way to divide the immediate drawing tools/switches and the other functions.

Currently the menus don't do that much as I am a bit wary of crowding them with options. Also, a bit more planning may be needed for the new dialogues. As a sort of demo what will happen in the future, the Text export now opens a dialogue for export options (that also have been improved a bit).

The main toolbar can be flipped, it can be on the left or right hand side of the screen, using OTHER/SWAP SIDE. DeluxePaint had the menus at the right but most applications these days seem to favor the left side. To me the left-side felt quite natural. You choose.

As file options no longer have icons, I got more room for the remaining icons. I gave some padding around them and their groupings, which could again be helpful for drawing tablet users. I might consider reducing the amount of icons further, or making even more clear division between drawing tools and the switches.

Some functions are now in a more standard location, for example the Load/Save/Export/Import icons can be found from the top left FILE menu. Keyboard shortcuts work as usual.

Although redundant, Undo/Redo and clear-all can also be found from the menus for added comfort.  Also, select border/background etc. are added to the menus as they were not very visible. Clear background comes in two varieties, using 1st or 2nd color.

Quick flip is accessible from menu, so the image can be viewed as mirrored.

Two Commodore 64 alternate palettes (Pepto and Colodore) can be quick-accessed from the menu. Custom .ACT-format palette files can still be loaded using the Load menu option.

I added the Pipette tool as an icon, as people tended to think it does not exist at all. It does help drawing tablet users I think.


New Target Platforms: Sinclair Spectrum ULAplus and Sinclair QL

The biggest addition is the ZX Spectrum ULAplus colour enhanced mode, based on the ULAplus specification by Andrew Owen. The current ULAplus support is limited for the ZX Spectrum 32 x 24 colour resolution, and not every idea in gestation could be included. In the future, I might support the "timex" 8x1 mode.

An original ULAplus image made with Multipaint

I hesitated to add ULAplus as I've previously avoided any 'special' modes. ULAplus was interesting and compatible enough to do and has some actual support. I'll possibly discuss this in more detail in near future. Let's just say it's not an easy mode to work with!

Sinclair QL mode 8 has been promoted from a semi-supported platform into a "fully" supported platform. The mode has an approximated flat aspect ratio that cannot be turned off. I added this mode mainly because I have grown so fond of the QL.

More importantly, the QL mode represents a small step towards supporting some low resolution 16-bit modes (Atari ST 320 x 200). I've resisted this in the past as Multipaint does not really have the type of tools and interface for handling them in the best way, but the day is getting closer.

Multipaint at http://multipaint.kameli.net/

Atari Falcon serial transfer pt.2: Shells from hell

A continuation of the Atari Falcon/ST file transfer topic.

I've found Atari terminals to be clunky and none would do exactly what I'd want them to. Ansiterm fared the best so far, the terminal is good enough for using the command line remotely, and a Zmodem transfer will be automatically recognized when using sz from Linux end.

However, on the minus side it's one more program to launch, necessitating video mode adjustment to ST-LOW and setting up the xyz.ttp. This also distances you from the Falcon end of things.

Although this was an ok solution for one longer session, I didn't exactly like to access my Linux command line through a terminal.

As long as I can use a command line shell on the Atari end, I should also be able to call up a file via that command line. Previously, this meant launching xyz.ttp at Atari end and then typing the sz at the Linux end.

Now I tried a fun way to improve this a bit.


Mupfel shell

At Falcon end I have used the Mupfel shell, which is bourne-like enough for doing relatively complex scripts and redirecting of input/output.

I could make a small script that sends commands to the Linux by serial port, activating the sz Zmodem transfer and running the xyz.ttp Zmodem receive program at the Atari end.

But it took a while to get the Mupfel shell up and running properly, as I couldn't find that much information about how to use the shell.

Then it struck me that as the shell is a Bourne clone, people must have assumed it's nearly general knowledge anyway. So, after reading some sh guidance...

If the program file mupfel.ttp is at D:\comms\mupfel then the shell expects to find a file called 'profile' from there.

echo Mupfel
echo xyz,zip,lzh,edit,emacs
echo
PS1='%p> '
alias xyz=c:\xyz202b\xyz.ttp
alias zip=c:\stzip\zipjr.ttp
alias lzh=c:\packers\lharc\lharceng.ttp
alias edit=d:\comms\memacs\me311ata.tos
export TERM='VT52'
PATH='c:\;d:\comms\mupfel\bin\;e:\;f:\;.'
HOME='d:\comms\mupfel\'
SUFFIX='prg;app;acc;tos;ttp;mup;sh;'
LINES=30
ROWS=30

The above is an example of my 'profile' which connects various programs with aliases. The line with PS1='%p> ' makes the prompt a bit friendlier, showing the current path.

I use MicroEMACS for editing text files inside Atari, there are not many options for editors that would work well within the Atari shells. If only I'd find the way to bind those arrow-keys...

MicroEMACS requires that the environment parameter TERM is not empty, so I have 'VT52' there. Suffix should tell which files are executable but frankly it doesn't seem to do much. Not sure if LINES/ROWS are meaningful to any programs.

Well, off to the file-transfer-mobile.


The 'get' script at Atari

D:\comms\mupfel\bin\ is a good place to put a script. Mupfel scripts end with .mup extension.

From the command line, doing

echo Hello>>AUX: 

sends characters to the serial.

Saving the following as get.mup

echo get $1 >>AUX:;xyz

is enough to send over a 'command'. The characters 'get ' are sent, followed with the argument passed from the command line, and after that the shell runs xyz.

Here in my case xyz is an alias for xyz=c:\xyz202b\xyz.ttp as defined in the profile above. I guess the 'get' could be an alias too.

I spent some time making a Processing sketch that reads the serial input, sniffed for that 'get' statement and used a system call to send the required file using sz. Clunky but it worked.

However, after a bit of a think I felt this could just as well be done as a Linux bash shell script.


The 'server' script at Linux

At my Linux end, I can use a script somewhat like this:

#!/bin/bash

DEV=/dev/ttyUSB0
stty -F $DEV 57600

echo "Serial is on"
echo "use get at Atari"

while :
do
 echo -n "WAITING>";
 IFS=' ' read COMM ARG < $DEV
 if [ "$COMM" == "get" ]; then
  echo "GET:" $ARG 
  sz $ARG > $DEV < $DEV
 fi
done

The script sets the serial port to 57600 and waits for a line of characters to arrive via the serial.

After such a thing arrives, the string is split using spaces between words. The first part will be the 'command' and the latter part a 'filename' for that command.

If the command is seen to be equal to 'get' then zmodem send (sz) is launched to send the file, with a filename based on the second part of the line received from the serial port.

In the meantime the tiny get.mup script at Atari end ensures that xyz202b.ttp is launched, waiting for the Zmodem transfer.

After the file has been transfered, the Mupfel shell resumes normal operation while the script at Linux end is looping another cycle, waiting for further instructions.

So, typing get /home/user/Downloads/atarifile.zip on the Atari end the file will be received to the current folder.

I added a 'put' command for uploading files from Atari and a 'say' command for simply sending a bunch of characters to be displayed, for testing purposes.

echo put>>AUX:;xyz -u $1

and

echo say $1>>AUX:

and the respective portions to be added to the Linux bash script:

    if [ "$COMM" == "put" ]; then
        echo "PUT:"
        rz > $DEV < $DEV
    fi
    if [ "$COMM" == "say" ]; then
        echo "SAY:" $ARG
    fi



Vice Versa

Now, it might be handy for the Atari to be waiting for the files whereas the typing stuff is done on Linux? How to do the opposite of the above?

Again, in Mupfel:

while :
do
IFS=' ' read COMM ARG <AUX:
if [ $COMM = 'put' ]
then
echo 'RECEIVING'
xyz
fi
if [ $COMM = 'end' ]
then
echo 'QUIT'
exit
fi
done

I had to take a bit different approach (it's not bash) but in the end I got it working on the Mupfel shell.

(I preserved the command/arguments split although I don't do anything with the arguments really.)

Running this, it becomes possible to use the send commands exclusively from the Linux end and the files will arrive at the folder the script is run from.

I had some trouble breaking out of the loop so I added the 'end' command just to be able to stop the shell from outside.

Also, at least in this form the 'read' tended to take in the Zmodem control characters etc. and got into a mixed state having received bunch of codes but no newline. Sending a bunch of lines after the serial send sort of clears the situation, but also produces glitchy-looking messages.

Although a nice exercise, having the 'server' script at linux end might be the better solution after all. Running that script is no problem for that box, whereas the Atari would be tied with running that one loop.


Afterword

By the way, another Bourne-esque shell I dabbled with for a while is called Okami, which was good enough for launching that xyz.ttp, moving and exctracting files around. A bonus is that it's able to launch GEM programs, something Mupfel won't do.

The earlier version of Okami may be recommended, although it is a bit lacking. The later versions appear more comprehensive but they were buggy at least on my Falcon so it was virtually useless.

Atari Falcon SD-IDE

The Falcon August continues!

After establishing the basics of file transfer between Falcon and Linux, I wanted to replace the physical hard disk with a IDE-compatible SD card reader. There was one CF-IDE adapter lying around but my CF cards were exactly those "nameless" brand cards people always warn about so I avoided using that.

I ordered a IDE/SD card reader "SECURE DIGITAL 44 PIN 2.5 MALE IDE TO SD CARD ADAPTER AMIGA 600" off eBay. Seeing that it was advertised as fitting for Amiga sounded good enough.

When the item arrived, I thought it wasn't the correct 2,5 inch as "promised", but smaller. But after opening the Falcon (the first time) it turned out this was exactly right for the IDE cable/connector that was inside the computer.

IDE cable at centre. Note the absence of a cradle for HD.

So, I couldn't even have used my CF-IDE adapter without another adapter.

Possibly, a doohickey 90-degree adapter might exist somewhere that would get rid of the cable entirely.

For the SD card I used a Kingston 8gb HC "20x" card.

For setting up the disk I simply followed instructions, and here I'm largely just repeating what people have said elsewhere, mostly the second option in this Youtube video.


Opening the Falcon and fitting the card adapter

The Falcon cover is held together with a bunch of screws. Underneath, there is a metal panel that needs to be removed. The second metal panel (under the keyboard) can be left attached.

The topmost metal part should come off by creatively bending and wiggling it, even if it at first looks like it might not.

This Falcon did not have the original cradle for the hard disk, so I can't really comment about that.

This also meant I'm somewhat out of options as to where to put the card reader. It's so light it could just dangle at the end of the IDE cable, but the danger here is that it might hit something delicate on the motherboard.

I feel that the creators of SD card readers could make the circuit boards a bit larger just to make them easier and safer to attach inside the computer. I mean if it's supposed to replace a 2,5 or 3,5 inch hard drive, it doesn't need to be the size of a postage stamp...

For a while I kept the card like in the image below, but then I felt it might hinder the air flow. Probably not, but anyway it ought to fit more firmly into place.

In the end I turned the cable and the card "upside down" on itself and fastened a wire around the IDE cable so although the adapter isn't screwed or fastened in, it won't sail away on its own accord.


Partitioning the drive

After physically connecting the card reader using the IDE cable, the card needs to be partitioned using the Atari (not formatted).

I went for the ICD driver route, as people have reported it should work just fine with the CF cards and like. "Somebody" said SD cards might be more reliable so that's why I went there too.

I downloaded the ICDP655A.ZIP on Linux, likewise unpacked it on Linux and copied the resulting folder to a HD floppy disk that I had formatted on the Falcon.

Using ICDBOOT.PRG the relevant driver becomes present (it ought to recognize the card and  display its name even at this point). Then, using the ICDFMT.PRG the card can be partitioned.

Note again that "format" has no relevancy here. Instead, "Clear" the suggested default setting, and then use the "split" command to give a suitable number of portions.

The suggested GEM partition size tends to be overtly small, I suppose there's no sense to keep it smaller than the other partitions. Still I kept it at 20mb just to avoid cramming files there.

The partitioning should be almost instantaneous, but the program will check for bad sectors and this will take some time. After this the system will be rebooted.

You should be able to see the partitions on the desktop after running ICDBOOT.PRG and using Install Devices from the GEM menu.


Making the drive bootable

As the computer can't boot from the drive yet, you'll still have to rely on the floppy.

To make Atari drive C bootable, run the ICDBOOT.PRG again to activate the driver and then use HDUTIL.PRG for enabling the boot.

I bothered to snapshot the desktop on the Atari, a hilariously long-winded process

This part was a bit confusing, and I didn't get it right the first time, possibly because the floppy behaved a bit badly.

You can choose a partition for the boot drive, then the drive should be set for booting and the driver will be installed on that partition. It's possible to fiddle with the boot options, and I did some too.

Not sure about these. I guess I checked the "Falcon" for Boot Res and that's it.

Don't copy the ICDBOOT.PRG to the AUTO folder of the hard disk, it does nothing there.

After the boot works, You can Install Devices from the desktop menu and then Save Desktop. The Falcon should now boot to the system and show the partitions on the desktop.


Reaping the rewards

Strangely enough the disk drive (or the floppy) started working erratically during the process. But I managed to get the XYZ.TTP onboard after which I could leech off everything over the serial on 9600 speed.

After getting DRVIN.PRG, SCC.PRG, XCONTROL.ACC and SERIAL.CPX I could get the faster 57600 speed. The DRVIN.PRG, SCC.PRG and FPATCH2.PRG are to be placecd in the AUTO folder whereas the ACC files belong to the main folder. Make a CPX folder for the SERIAL.CPX, although you probably have to config the XCONTROL.ACC to find the files from there.

I've been toying around with this setup for a few weeks now, adding and adjusting things, and the card appears to work ok. More about Falcon later...

Linux->Falcon serial transfer

After having a look at the Atari Falcon 030 and using the cumbersome floppies for moving files about, I wanted to move files over the serial.

I had lost my null-modem cable and could only find a mirrored 9-pin cable with M-F connectors (what is that for anyway?). The proper null modem cables were still sold at Clas Ohlson in Helsinki. Thanks, Clas Ohlson!

Serial is quite fast for sending a few megabytes or less, which is enough as Falcon files are not that huge.

Obviously, the ports have to be set for the same speed. 115200 proved to be a bit too much, so I went for 57600, which gave a healthy ~5500 bytes per second.

First, I need to set the serial port parameters using the Control Panel. This requires the Control Panel accessory (XCONTROL.ACC) in the boot drive folder and the serial control panel extension (SERIAL.CPX) on the system, at C:\CPX\ for example.

DRVIN.PRG needs to be at the AUTO folder to gain these high speed connections for "Modem 2", otherwise you'll be stuck with the 9600. Edit: It seems the SCC.PRG should be there too. Not sure which of them or both?

If DRVIN is not there, the ACC is likely to bomb if you try to fiddle with the modem 2 parameters.

XYZ on a command line shell at Atari end

To receive files using the ZMODEM protocol, you need XYZ.TTP.

Although the xyz can be run from the desktop, I prefer to use these TTP (TOS-Takes-Parameters) programs from inside a command line shell. It's a bit neater that way and I get to see the program results and recent actions better. Moving files around the system becomes quicker too.

Still testing at 9600, hence the slow speed...

Okami shell is reasonably featured, and you can use some Unix-style parameters, like directing output to a file or a serial port. It's not developed with a Falcon in mind, but using a 2-color video mode it's pretty fast. "mupfel" is another shell, but setting it up seems a bit more involved so I'll look at it later.

I added the following line inside the Okami "profile" file, so the shell will execute it on running. This way I can run the xyz from wherever I happen to be:

xyz=c:/xyz202b/xyz.ttp

Afterwards, using

$xyz

the xyz.ttp will run and wait for a file to be sent. Yes that $ is not exactly as effective as an alias or a proper PATH but it's still far better than working every time from within that folder.

As an aside, editing that profile file is bit of a chore as there are very few choices of a shell-run text editor. I'd hate to jump between a GEM editor and the command line shell now that it's in place. I ended up using something called pro_edit for now, which is rather poor and assumes the display height is 400. ST video modes to the rescue.

But if it's only a matter of adding one line to the profile, then appending that line with echo xyz=c:/xyz202b/xyz.ttp>>profile will work.

Obviously, after the file transfer is in place text files could be transferred from the Linux... But as the point is to toy around with the Falcon, why move over all the tasks to some other computer?


sz at Linux

Unlike Atari, Linux doesn't have an abundance of strange 'terminal emulator' programs, possibly because the terminal is so integral to the system.

There's minicom, but practically minicom (or anything else) uses rz and sz for file transfer protocols, so it's better to use these from the Linux terminal command line directly.

These need to be installed first. If there is a permission problem with the serial port then the user has to be added to the dialout group.

I followed a suggestion of calling sz from a tiny script (named zsend in the example) which ensures the serial port speed is correct:

#!/bin/sh

DEV=/dev/ttyS0

stty -F $DEV 57600
sz $1 > $DEV < $DEV

The ttyS0 is the device for the serial port, in my case it's already a part of the motherboard. An USB->RS232 port is often called ttyUSB0. dmesg | grep tty reveals the device names.

Saving this script as zsend, it can be made into an executable with chmod +x zsend, after which ./zsend filename should start the transfer. If Atari is running the xyz.ttp and waiting, then the file should transfer.

A version for receiving files from the PC end, use rz instead of sz.

At TOS, xyz -u filename will upload a file, defaulting to ZMODEM.

I also tried batch uploading with *.* and although everything went fine for a file, the XYZ.TTP at Atari end complained about too many handles or something after about 16-17 files. So, for moving a lot of files it's better to zip things at that end first, no matter how slow it is.

Strangely, uploading from Atari was a bit slower, some times less than 4000 bps on average. File permissions may need altering on the Linux end and the filenames tend to be uppercase which can be a bit annoying at Linux. -LL option on zip ought to force filenames to lowercase, though.

Backing up AUTO folder and your essential system files with this method is a good idea I think!



At Atari again

Transferring zip files is much more handy than trying to send files with a folder structure, and they are obviously compacted too.

Working with the Okami shell, for added comfort I also added the zip unpacker to the Okami profile:

zip=c:/packers/stzip/zipjr.ttp

...for example. The zipjr.ttp comes out of the stzip.tos self-extracting archive, found here.

$zip -xr file.zip

In Okami, this then becomes the equivalent of running zip from its folder. It appears the zip version I have it likes explicit -xr parameters for extracting and preserving the folder structure.

Lharc (lzh) is another often seen archive format, and jaymsa18 may be used for recovering files out of .msa and .st disk images on the Atari end, if the disks play nice with file structure that is.

After all this, I can finally look at Llamazap, an apparently unfinished game by Jeff Minter that can't even be started without a very specific controller. Oh, well.