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.

echo Click on Window
echo using fps 30
xwininfo -display :0 | grep "id:" > temp.txt
more temp.txt | grep -Eo '0x[0-9]+' > 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.

AmigaWave #202: Especial Sinclair QL con Badaman, AFX y Zerover

El domingo 24 de mayo estuvimos invitados al programa de AmigaWave especial sobre QL, algo que veníamos acariciando largo tiempo, y nos dieron dos horas para contaros todo acerca del QL de hoy, Comienza en el minuto 45.

Nosotros sentimos el QL como algo vivo que sigue evolucionando, y aquí hemos querido contar hasta dónde ha llegado. Hablar del QL original para nosotros es como hablar del PC y contar las bondades o inconvenientes del MS-DOS, obviando los Windows y Linux que hoy día podemos tener instalados en ellos. Para los que tienen un QL “pelado”, una única ampliación, la de José Leandro, le cambia la cara a la máquina de forma espectacular, y luego, ya si uno quiere aventuras, pues tiene todo el abanico de ampliaciones posibles y la Q68 (FPGA). El QL no le tiene que gustar a todo el mundo. Es un sistema diferente, con sus cosas buenas y malas, como todos, y que tiene su propia historia.

Espero que lo disfrutéis. Nosotros hemos pasado un rato muy bueno. ¡Feliz día del orgullo friki!

Me he comprado un QL. ¿Y ahora qué? (2)

Algunos enlaces de interés:





Sinclair QL Recursos en Castellano

Dilwin Jones (inglés)



QLForum (inglés)


Sinclair QL Planet (inglés)

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:

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. 

QL-SD driver v1.09

A heap of dung

I’ve been working hard behind the scenes to release a new version of the QL-SD ROM driver. The starting point was that Urs König asked me about a mysterious heap corruption with QL-SD when using his QL/E distribution under Minerva. And mysterious it was, after stripping down QL/E’s monster boot file to a few lines a simple WSTAT command turned out to be the culprit. How can that be?

Long(!) story short, this turned out to be an incompatibility between a compatibility hack contained in SMSQ/E’s DV3 driver (on which the QL-SD driver is based on) and Minerva’s heap manager: when the first empty space in the heap was exactly(!) 384 bytes long the QL-SD driver corrupted the heap chain! This is difficult to debug because once you load a debugger the heap is too different to trigger the bug! Generally the bug is very difficult to trigger which is why it went unnoticed for so long, but fortunately with QL/E it was reproducible.

One network to rule them all

While working on the code I found a few more places where I could save a few more bytes, all in all a whole kilobyte even! So, what to do with so much space? It’s not enough space to include more card management functions (more on that later), but enough to do something I’ve been thinking about for a long time:

In one of my other 1000 QL projects I created new versions of the very famous TK2 basic toolkit and in doing so I also created the QLNET hardware proxy: this means that the highly timing critical low level QL network driver functions can be split off from the rest of TK2 so that they can be burned into a ROM while the much bigger rest of the network code is loaded from another device into potentially slower RAM.

And now with all this free space available the time has come for QL-SD to host the QLNET low level functions. Yaaay! The remainder of TK2 can then be loaded from SD without losing network support. Mind you this is only useful for original black box QLs, GoldCard and SuperGoldCard come with their own TK2, in this case the new functions are simply ignored.

Card business

SMSQ/E for Q68 comes with several CARD_xxx basic functions for working with the FAT32 host file system. As these are somewhat useful I adapted them for QL-SD and released it as an external BASIC extension. There are three new basic functions:

  1. CARD_CREATE card,size_in_mb,filename$
    Create a new empty file on the card with the desired size. The great thing about this command is that unlike files created by the PC the file is guaranteed to be contiguous, which is a necessity for usage with QL-SD.
    “card” is 1 for the first slot and 2 for the 2nd slot.
  2. CARD_RENF card,”old-name”,”new-name”
    Rename a file on the card. Note that the QL-SD driver can not handle long filenames, so the filenames must comply with the old DOS 8.3 filename scheme.
  3. dir$ = CARD_DIR$(card)
    Return the first 16 root directory entries in a string. QL-SD can only “see” the first 16 entries in the root directory, so this is a good way to check what’s actually seen by the driver.

In conclusion

You can head over to the updated QL-SD product page and get the new driver and toolkits. All QL-SDs produced by me shipped with an EEPROM that can be updated within seconds using an appropriate EEPROM programmer. I know not everybody possesses one of those, but unfortunately I cannot provide an update service at this time. I’m hoping that this can be somewhat crowd sourced so people with the hardware can help other people out, maybe even for a fee.

Speaking of fees, I do this all for free. And it’s taken up so much time that I need to scale back eventually. But in the meantime, if you still want to support my work, check out my cookie jar. In any case, thanks for reading and enjoy.

Dumping Intel 8049 ROMs

In addition to the Motorola 68008, the QL has a second processor, named by Sinclair the "Intelligent Peripheral Controller" (IPC).

The second processor is an Intel 8049 microcontroller that runs independently of the main processor and handles the keyboard, sound and serial port inputs.

The 8049 sits on the right side of the QL motherboard, squeezed between the microdrives and the keyboard connectors

Communication between the 60008 and IPC uses a slow serial link and can only happen when the IPC is in-between activities like scanning the keyboard or producing the next segment of a sound.

This can cause a significant slowdown of QL software and the exact timing depends on the code that runs on the IPC.

The code is stored in an internal 2 KB ROM. Sinclair wrote the code, but it got programmed in the chip by the manufacturer, and there is no way to reprogram it.
This also means that if you need to replace an IPC chip, you cannot just buy any available 8049: It needs to come from a QL, or it will contain a different, incompatible ROM.

There are a few copies of the QL IPC code on the internet and they are all the same, apart for a single unused byte toward the end of the ROM.

In order to improve the 'QL Speed' accuracy of Q-emuLator, I plan to better account for the 8049 timings (simulating the interaction between the 68008 andthe ZX8301 ULA will also be necessary, but that's a topic for another day). To compare the speed measured on a real QL to the emulation speed, I need to be sure about what code is running on the IPC, so I decided to dump the contents of the chip and compare them to the version from the internet.

EPROM programmers have the circuitry necessary to read the 8049 ROM, but I don't know of any programmers that support this chip, probably because it cannot be written to.
Reading the ROM can be accomplished by using the "ROM Verification Algorithm" described in the MCS-48 datasheet (MCS-48 is the family of microcontrollers that includes the 8049).

I bought an Arduino UNO board to connect it to the 8049 and read the ROM.

I also got a second QL 8049 to use in my initial experiments and avoid the risk of ruining the chip in my QL.

My two IPC chips look quite different... Will they contain the same or different code?

There is a web page called 8049 Spy that explains how to connect the 8049 for reading the ROM.

I used the same method, with two differences:
  • The 8049 is connected to an Arduino instead of the 6802 Nano Computer.
  • I added a resistor for protection on each of the 8 data lines since these are bidirectional and both the Arduino and 8049 could end up trying to write to them at the same time if the timings are not perfect.

The IPC (on the right) connected to the Arduino board (left)

View from above
Here is the procedure to read the contents of the 8049 ROM:
  1. Apply 12 Volt to pin 7 to set the "ROM Verification" mode. In my circuit, I used a boost converter to convert the +5V used by the 8049 and Arduino to +12V.
  2. Set the 11-bit address of the ROM location to read, using DB0-DB7 for the low 8 bits and P20-P22 for the high 3 bits.
  3. Set the RESET pin to high to signal that the address is valid.
  4. After a few cycles, read the content of the ROM location from DB0-DB7.
  5. Set RESET to low and repeat from step 2 using the next address, until we've read all the 2048 ROM locations.
The Arduino code prints each ROM byte in hexadecimal to the serial link where the PC can read it (through the USB port) and display it (the Arduino IDE has a Serial Monitor window for that purpose).

Here are the connections from each of the 40 pins of the 8049 to the Arduino and other signals:

8049 connections for ROM Verification
The 11 bits for the address/data lines are connected to digital pins D2-D12 of the Arduino, while pin A0 (used as a digital pin) controls the 8049 RESET signal.

In addition to the resistors and boost converter, the only components needed are a 4 MHz crystal and two 22 pF capacitors to generate the clock signal.

Here is the code I wrote on the Arduino to read the ROM:
  #define RESET_PIN A0  

void SetReset(uint8_t b) {
digitalWrite(RESET_PIN, b);

void SetDigitalPinDir(bool bOut) {
if (bOut) {
DDRD = B11111100 | DDRD;
DDRB = B00011111;
} else {
DDRD = B00000011 & DDRD;
DDRB = 0;

void SetAddress(int addr) {
PORTD = ((uint8_t)addr << 2) | (PORTD & 3);
PORTB = (uint8_t)(addr >> 6);

uint8_t ReadDataBus() {
return (PIND >> 2) | (PINB << 6);

void Output(uint8_t b) {
if (b < 16)
Serial.print(b, HEX);

void OutputNewLine() {

int addr;

// Diagnostics
uint8_t diff;

void setup() {
addr = 0;
diff = 0;

while (!Serial); // Wait until serial console is opened

void loop() {

if (addr < 2048) {



SetAddress(255); // Input pullups

uint8_t data = ReadDataBus();



diff |= (data ^ addr);


if ((addr & 31) == 0) {

if (addr == 2048) {

diff ^= 255;
if (diff) {
Serial.print("Some data lines appear disconnected: 0x");

Tweaking the code to make it work took longer than I expected. I found that initially some pins of the 8049 were not making good contact with the breadboard. After straightening the pins and reinserting the 8049, I started getting some data that looked correct, but other bytes or bits were read as zeros. Setting the Arduino digital pins in a input pullup configuration helped, but there were still some remaining zeros. I continued to look for bad contacts, but in the end it turned to be a timing issue and adding or increasing the timeouts in the code finally resulted in a good ROM dump.

I found that both the 8049s I dumped contained identical code. The code also matched the one already available online. This was less exciting than discovering a new version of the IPC ROM, but at least now I'm sure about what is running on my QL (JM version) and know that any small remaining speed differences in the emulator must be caused by something else.

It would be interesting to dump the IPC ROM of an early QL and see whether the code is also the same.

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.


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.

AmigaWave #198: Novedades Sinclair QL

Aprovechando la salida de la nueva versión de SMSQ/E, en el siguiente video de se programa semanal de AmigaWave, David hace un excelente repaso de la trayectoria del mundo del QL, especialmente de las expansiones como la GoldCard las QXL y las Q40 y Q60, y muestra el entorno de ventanas Pointer Envoronment (PE) a color real, y con resoluciones superiores a 512×512.

Lo relativo al QL comienza en el minuto 50 y dura unos 40 mins.

¡No os lo perdáis!

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.

Expandiendo al límite la red local del Sinclair QL. Primera parte.

Hace un tiempo (bueno, … bastante tiempo) escribíamos en QBlog un artículo introductorio sobre las facilidades de red local que incorporaba el Sinclair QL. En ese artículo comprobamos lo sencillo que es montar una pequeña red con dos QLs y la versatilidad el sistema operativo para manejar recursos compartidos entre distintas estaciones. (Si la red local del QL es algo nuevo para ti te recomendamos su lectura).

Ahora, en una serie de dos artículos, vamos a intentar profundizar algo más en las capacidades de red de los sistemas QDOS y SMSQ/e. Intentaremos describir con detalle qué posibilidades actuales tenemos para llevar al límite la red de área local de sistemas QDOS y SMSQ/E.

Esta primera entrega tendrá un carácter mas “exhibicionista” (por decirlo de alguna manera) de hasta donde podemos exprimir la red del Sinclair QL. Sólo expondremos conceptos muy generales y relataremos un ejemplo de cómo podemos llevar al límite la red del Sinclair QL en el contexto actual (año 2020). La segunda parte será algo más árida para quien no esté familiarizado con los sistemas operativos del mundo QL. En esa segunda parte entraremos en las entrañas de los distintos comandos y facilidades que nos aporta el sistema operativo a la hora de planificar y configurar nuestra red. También haremos una descripción más detallada de las distintas partes (hardware y software) que la componen.

Una pequeña introducción.

La incorporación de serie de hardware y software de red en los microordenadores de los años 80 no era una característica muy común. En el año 84, ésta fue una novedad interesante en el Sinclair QL que no fue lo suficientemente valorada ni conocida.

QL NET es el nombre por el que se conoce la red de área local del QL. Esta red permite la conexión de hasta 64 estaciones de trabajo que soporten este protocolo. La red permite compartir impresoras, unidades de almacenamiento y hasta la propia consola de cualquier estación conectada a ella.

Los datos circulan por la red a una velocidad de 100K Baudios y el protocolo asegura que las estaciones estén listas antes de que los datos sean pasados a través de la red. Los datos también pueden ser volcados a modo de “broadcast” a todos los ordenadores que estén a la escucha.

Con el paso de los años, y la entrada en el mundo QDOS/SMSQe de otro tipo de hardware, principalmente el Atari ST, se implementaron nuevos controladores de red dado que estos sistemas no incluían el hardware de red del QL (QL NET). El primero de los controladores en llegar fue MIDINET el cual permitía conectar en red varios AtariST. El puerto MIDI OUT de cada estación se conectaba al puerto MIDI IN de la siguiente estación y así se podía formar una red en anillo. Posteriormente, a partir de MIDINET se desarrolló SERNET que permitía también la conexión en red de varias estaciones SMSQ/E y QDOS a través la interfaz RS232. Este controlador se usaba frecuentemente en hardware distinto al QL original que incorporaba puertos RS232 de alta velocidad (Aurora, Q40/Q60 y emuladores como QPC).

Nuestra red experimental.

La idea básica es montar una red local entre 4 máquinas distintas y heterogéneas empleando QL NET y SERNET. Las características de cada estación que componen nuestra red son las siguientes:

Estación 1. QL clásico ampliado con una Super GoldCard y una QL-SD como unidad de almacenamiento.

Estación 2. Q68 con un “modding” reciente que incorpora QL NET. Además de QL .NET, Q68 incluye de serie un puerto RS232. (Q68 es una FPGA que implementa una máquina SMSQe)

Estación 3. PC con Windows 10 que ejecuta el emulador QPC2. Esta estación tiene un puerto COM1.

Estación 4. Un segundo PC con Windows 10 que comparte a través de la red TCP/IP una carpeta de su sistema de archivos con la estación 3.

El esquema de la red está en la siguiente figura.

(NOTA: No te preocupes por las siglas del la imagen anterior, hablaremos de ello en el la segunda parte de este artículo).

Podríamos decir que la “magia” de esta red heterogénea está en la FPGA Q68 (estación 2) que actúa como una especie de “gateway” entre dos redes distintas QL NET y SERNET. Mediante QL NET conectamos el QL original y la FPGA, mediante SERNET conectamos la FPGA y el PC con el emulador QPC2. Y por último nos aprovechamos de la posibilidad que tiene QPC2 de montar volúmenes de almacenamiento “mapeados” sobre capetas locales o remotas del PC anfitrión.

La infraestructura anterior y las facilidades que nos da el sistema operativo del QL (tanto QDOS como SMSQe) nos permite cosas como montar unidades de almacenamiento lógicas en el QL “mapeadas” a carpetas o directorios nativos del los PC de la red y de la FPGA.

Por poner un ejemplo, podemos redirigir el nombre que asigna QDOS al microdrive 1 (MDV1_) a una carpeta compartida que tiene el PC número 2 de mi red local. Desde este momento, si tecleamos “dir mdv1_” obtendremos el contenido de la carpeta compartida del PC 2 de nuestra red.

A modo ilustrativo, en la figura 1 podemos observar que en el QL (estación N1) se han definido los 4 dispositivos de almacenamiento lógicos (dispositivos DEV) siguientes:

– DEV1_ (apunta a la unidad de almacenamiento WIN1_ de la FPGA).
– DEV2_ (apunta a la unidad de almacenamiento WIN1_ del emulador QPC2 en el PC1)
– DEV3_ (apunta a un directorio del disco C: del primer PC, que ha sido montado a su vez como disposito DOS1_ en QPC2))
– DEV4_ (apunta a un directorio compartido del segundo PC, que ha sido monado como dispositivo DOS2_ en QPC2)

Forzando un poco más, podríamos “mapear” DEV4_ a una subcarpeta dentro de nuestro sistema de almacenamiento en la nube tal como dropbox. Esto significa que desde mi QL pudo escribir o leer directamente archivos que van a ser vistos de forma inmediata por toda las personas del planeta a las que le haya compartido dicha carpeta.

Esta red me permite prescindir de disquetes y tarjetas SD cuando quiero transferir ficheros a mi QL. Ahora todo lo hago todo via QL NET.

Algunas pantallas a modo de ejemplo.

Q68 con los puertos QL-NET (lateral) y su interfaz RS232 (parte trasera)

QL – accediendo a la unidad de almacenamiento de Q68

Q68 – accediendo a la unidad de almacenamiento del QL

QPC2 – con una unidad virtual del sistema anfitrión (DOS)

QL mostrando el contenido de una carpeta del PC con Win10 (ver número sectores)

Todo esto podría parecer confuso para las personas desconocedoras del mundo QL y sus sistemas operativos QDOS y SMSQe, pero en cuanto se dominen un par de conceptos toda esta configuración es muy sencilla.

En la segunda parte de este artículo explicaremos los principales comandos del sistema operativo que nos permite hacer lo indicado anteriormente. Veremos como crear esos dispositivos DEV y otros comando útiles para configurar y montar una red QDOS/SMSQe con máquinas heterogéneas.