c1541

Just so that I remember.

To create a d64 image from a command line (e.g. Linux terminal) with the c1541 tool, part of the VICE package.

c1541 -format floppyname,0 d64 mydisk.d64 -attach mydisk.d64 -write myfile.prg filename

The floppyname is the disk name in the c64 filesystem. mydisk.d64 is the name of the disk image file on your pc filesystem. The myfile.prg is the file you want to write. The last name, filename how the filename will appear in the c64 filesystem. Use lowercase for both diskname and filename or else.

Format a new disk image:

c1541 -format myfloppy,0 d64 diskette.d64

Format a new disk image and write a file inside it:

c1541 -format myfloppy,0 d64 diskette.d64 -attach diskette.d64 -write idiotprog.prg idiotprog

Write a file into an existing d64 image:

c1541 -attach diskette.d64 -write idiotprog.prg idiotprog

Read a file out from an existing d64 image:

c1541 -attach diskette.d64 -read idiotprog

Commodore Plus/4

Thought I'd say a little about Commodore Plus/4 now that I'm a bit more familiar with it. When I got this computer I expected to feel the kind of enjoyment when exploring Panasonic JR-200. I can't explain why. Neither can I explain why it didn't turn out that way. It's still an interesting computer, though.

Compared to how well-known C64 and VIC-20 are, Plus/4 can be called fairly obscure. At least I never saw a physical Plus/4 in Finland back in the day.

Instead of going upward from C64, Commodore decided to go a bit sideways and somewhat back with this computer. From a manufacture perspective, the C64 was perhaps a bit troubled with having so many of those glorious chips, so creating simpler hardware seemed attractive.  Goodbye VIC and SID, the TED chip takes care of it all.

The Plus/4 has more than 60k available for BASIC programming, accessible graphics modes and built-in software packages. Outwardly there is something of the 'spectrum' in it, what with the black plastic case and polygonal shapings. Even the boot-up screen seems like a concession towards Sinclair sensibilities: a grayish white background.

Left: The BASIC listing. Right: the output. Note the split graphic/text mode.

The BASIC has more features than before, though I'd say in user-friendliness it's not equal to Sinclair BASIC or the MSX implementation of Microsoft basic. Neither is it as versatile as the QL SuperBASIC or Amstrad BASIC.

GRAPHIC 2 gives the bitmap mode and GRAPHIC 0 gives back the text mode. Cleverly, using commands like INPUT in middle of GRAPHIC 2 gives a split-screen bitmap/text mode. Lines, rectangles, circles, flood fills etc., all of course are very slow. For once, there is a command for clearing the screen: SCNCLR.

Fortunately the computer has a typewriter keyboard, even though the uniquely styled cursor keys have been only half-thought out.  Surprisingly, my keyboard does not work as well as thirty-year old C64 keyboards, even if I suspect it has not been used that much.

The built-in text editor.

Commodore floppy drives and SD2IEC work with Plus/4, so it's possible to access the software catalog or do at least something meaningful with the computer. The new type joystick connector is simply silly.

Graphics are nominally better than in the Commodore 64, but the resolutions and text modes are pretty same as in the C64. The usual PETSCII text graphics are in effect, which is a good thing. An 80-column mode might have been welcome but nothing outside of a monitor would have displayed it in a satisfactory manner anyway. 121 colors sounds a lot but the palette is dominated with pastels.

The color palette appears a bit suspect when shown in its totality, but people have made some amazing pictures with it. The trick I suppose is not to try to modulate the colors with the luminosities directly (like below) but find smooth gradients by using different parts around the whole palette.

The built-in software is a waste of potential. One would imagine that a character display-based text editor would be fast and responsive, but here the implementation is slow. The rest of the package is more like extended support features for the text editor rather than proper software.

One good feature is the built-in machine code monitor, accessed by typing MONITOR in Basic. A monitor is very helpful for at least educating the programmer. Perhaps a full-blown assembler instead of the 3-in-1 package might have made the computer even more interesting. Sadly, without the added boost of the C64 chips the processor is left to do everything and compared to the Z80 the 6502 is not quite up to the task.

Cross-developing for the Plus/4 is pretty similar to C64, simply use cl65 and -t plus4 as parameters.

The following activates the hi-res bitmap mode and sets it to start from $4000 onwards.

LDA #$20
STA $83
LDA $FF12
ORA #$10
STA $FF12
RTS

Colormap starts at $1C00 and luminosity from $1800, both $400 long. Border is at $FF19.

With the Plus/4, Commodore introduced a new line of computers that were not meant to be any more compatible with the C64 than the C64 was compatible with the VIC-20. It was maybe hampered by a public perception that whatever Commodore made ought to be a continuation of the C64 thinking. Later days have shown the Plus/4 to be a quite capable and robust little 8-bitter.

Plus/4 World

Plus/4 at Wikipedia

iCade to Atari 9-pin

iCade arcade style stick on the C64, not unpossible!

Like many retro-heads, I was wowed for a while by the Apple iPad. It seemed that most interesting retro game stuff happened on that platform. But in the end I realized that the device has a major flaw: the touchscreen.  So I went and bought the iCade bluetooth arcade stick. This turned out not to be that great an addition, so it mostly gathered dust in some corner. (Well, mostly I was disappointed with the increasingly degenerating iPad)

When I needed an extra joystick for the C64, I opened the iCade to see what could be done to convert it into a good old-fashioned 9-pin Atari/Kempston joystick. I am aware that this must have been done dozens of times by different people, but I just refused to google it.

I used a breadboard to connect all the ground wires, but this is a bit extravagant.

Funnily, I did not need to solder anything. All the buttons and stick directions are very neatly connected to the tiny circuit board with such headers that easily connect to "jumper/dupont" style wires common in breadboarding. Also, all the ground wires from each button and direction switches are clearly marked black. I guess this all might be part of the intended design and greatly increases the value of the iCade in my eyes.

Example of the iCade header (left) almost connected to a jumper/dupont wire (right). 

Admittedly, what made life easier was that I already owned a couple of very useful pieces. The 9-pin doohickey shown below is a cannibalized COM-port header/connector from a tiny Linux computer I bought from a fleamarket (now destroyed). It's very robust as the connector solder points have been drowned in epoxy. Similarly the 9-pin extender cable is something I have had around for who knows how long. The gender changer was needed in between.

The COM-port thingamajig taken from a linux box, plus a gender changer. The jumper cables don't fit too neatly into the COM-header, though.

It took the longest time to figure out the correct pins, because I was tired. I won't include the diagram now as I'm prone to get it wrong. The Atari 9-pin schematics are lying around the net, but it's not always clear whether it's the jack or the port side. Once the ground has been figured out the directions can be checked one at a time. Wrongly connected pins can mess the C64, especially the CIA chip so take care.

Frankly, the iCade is not ideal for home 8-bit games, as the joystick travels a bit too much compared to, say, TAC-2. The fire buttons are delightful though. For Decathlon-type games, one might even consider connecting the buttons to directions. The neat thing about iCade is that there are numerous buttons, so perhaps in the future I could be motivated to do something a bit more ambitious, like one of the buttons as space bar or other keys.

The backside. Batteries not required!

Multipaint for drawing 8-bit images

Multipaint, a drawing program that works on PC/Mac/Linux has finally been released. Multipaint allows you to draw pictures with the colour limitations of some typical 8-bit computer platforms. The display formats supported are C64 high resolution, C64 multicolour, ZX Spectrum, MSX 1, Commodore Plus/4 hires, Commodore Plus/4 multicolor and Amstrad CPC mode 0. The images can be exported as files that run directly on the target platforms or emulators. (.PRG on Commodore models, .TAP on Spectrum and .COM for MSX) Currently the software also supports some 8-bit paint program formats, such as (Advanced) Art Studio on the C64, SCR (SCREEN$) on Spectrum, (Multi) Botticelli on the Plus/4 and SC2 on the MSX.

I started this project in 2013 with the idea that a single program could easily collect together multiple 8-bit drawing formats. It turned out more difficult than I thought, especially after adding the C64 Multicolour mode which follows different rules than the other screen formats. The program idea is greatly indebted to Deluxe Paint, but the tool palette has been adjusted with 8-bit drawing in mind. 

Mocking up a game screen in ZX Spectrum format

Automatic colour adaptation

One feature that took a long time to figure out was how the program could help with managing the foreground/background colours in a more intuitive way. With Multipaint, I wanted to create a paint program rather than an editor. Typically, 8-bit paint programs would have the pixels and colours almost as separate "layers". When editing a complex picture it would be easy to forget which colours are foreground or background in any particular character area. Multipaint treats the more prominent colour as the "background" on each square character, so you can focus more on drawing and less on keeping track of colours. This new system is not totally perfect either, but it is helpful in many situations.

Edit: The new feature, "force colour" (hold down ctrl/cmd) helps in detailed pixel editing. The colour under the pointer inside the character area will be directly altered to the current colour.

Demonstrating the ZX Spectrum border

Some features:

• Immediate color/character attribute update while drawing
• Platform-relevant export (.prg, .tap and .com output)
• Import and export .png images
• Import and export 8-bit paint program formats
• Fast switching between main and spare page, just like in Deluxe Paint
• Multi-step undo buffer, separate for main and spare pages
• Tile paint mode and small sprite animation
• All tools work with custom cut brushes
• Simple raster, color replace and brush recolor modes
• Tooltips with key shortcuts

X/Y mirror tools with a custom brush on C64 multicolour.

Links

The current version is 22.5.2016, which is the third released version.
The website with download links, information and image gallery: http://multipaint.kameli.net/

Multipaint at CSDb: http://csdb.dk/release/?id=145506

Multipaint at Pouet: http://www.pouet.net/prod.php?which=66976

Related project PETSCII, a cross-platform text art editor: http://www.kameli.net/marq/?page_id=2717

Related project Pixel Polizei, a cross-platform multi-format graphic tool: http://www.kameli.net/marq/?page_id=4557

A video introducing some of the tools and features of Multipaint:

Developing for C64

This is an idiot's guide for developing C64 software on Linux. (That idiot is me.) I need these instructions each time I get a new linux computer in which I want to install the development software.

This means that using a compiler within a PC/Linux environment, the code is tested on a C64-emulator and then transferred to a real machine. cc65 is the compiler and I'll go through how it has been set up.

Why not assembler/machine code? Although using C is quite problematic for C64, it is handy for planning and testing ideas. The program can be first written in C which is easier to grasp, then later the code can be changed into in-line assembler (supported by cc65) and further optimized.


Installing the cc65 cross-compiler

It's a bit depressing that the first step in coding for c64 is to compile the cc65 compiler for your system. But it's not a big deal.

It's possible to download the cc65 packages and compile them, but Subversion also works here. (for example sudo apt-get install subversion)

Then copy the SVN-link from https://github.com/cc65/cc65 and svn checkout [link].

Edit: Just get the cc65-master.zip, extract it and continue.

Then make. (If for some reason there's no such command then sudo apt-get install make it is)

After the binaries have been created, the commands only work from the folder they are in. A simplistic solution: go to the directory with the compilers (ar65 ca65 cc65 and so on) and copy the compiler binaries to "bin" folder, for example sudo cp * /bin. (Might be /etc/bin or something different also.) (Edit: usr/local/bin should do.) Check the file permissions too, chmod +x filename.

Now command cc65 ought to bring a response "cc65: No input files" even when not in the folder where the binaries are.

So far, so good...

The additional include files go to the include folder under the cc65-master folder. This is also where the usual stdio.h, string.h etc. are found.

Setting the C64 emulator

You need a C64-emulator for running the code, and Vice emulator is the most comprehensive and also the most universally available.

sudo apt-get install vice.

Note that the Vice will need ROMs and Kernal files and ROMs for the Floppy Drives too (1541). You can download a different Vice package that contains the files and copy them to the respective directories. If you only want to code for C64 you can copy just that one directory contents.

After a successful installation

x64

...ought to bring up the emulator window, and x64 programname.prg should run an emulator file in that format.

From Vice, it is wise to disable the "confirm quiting VICE" parameter, disable saving parameters on exit (and then save these parameters manually.)


Which editor for code?

Some kind of text editor is needed for writing the C code. Both Gedit and Kate handle code and matching bracket highlighting well enough and are pretty user-friendly. Komodo Edit has a handy sidebar for easily adjustable direct terminal command sets, but it's not as readily available for all Linux distributions.

If you decide on Kate, then it's possible you have to fix the kdelibs too and install the oxygen icon theme.

sudo apt-get install kate
sudo apt-get install -y kdelibs-bin kdelibs5-data kdelibs5-plugins

sudo apt-get install oxygen-icon-theme

You need to Settings/Configure Kate and display the build plugin in "plugins". Display the Build Output at the bottom of the editor window and insert "make run" for the default target. From now on the Build Default Target will run the project, and the menu can be assigned a key shortcut such as CTRL+R.

The main thing is that you get whatever editor to do the compilation with a simple keypress, otherwise it becomes a chore. I use Control-R in Kate, because it is also used in Processing. Especially for a beginner it's useful to have a rapid trial-and-error cycle. Some might vouch for better pre-planning, but they are wrong.

Edit: I've learned to use xed and make from a terminal window, it's nearly as fast. Kate just seemed to need more and more effort to work.


Compilation and Makefile

The sources could be compiled with cc65 from the commandline (cc65 test.c and then cl65 test.s) but a Makefile comes in handy. Any text editor can be simply told to employ the "make" command in the project folder.  The Makefile becomes sort of glue between the different programs: whatever compilers and text editors are always invoked in the same way.

The image below shows an example directory tree for locating your c64 sources, in this case two different projects, test and game. Note that the .c files have the same base name as the folders.

Good makefiles can be pretty daunting to do if you're simply interested in doing c64 code. It's also easy to create a makefile that fails to work in someone else's system. I'm hardly an expert so I've tried to keep the makefile simple. I've worked with the one below, ripping off stuff from here and there.

Edit: The indentations need to be real TABs, so copy/pasting from this blog won't work directly :(

CFLAGS = -Oi

LDFLAGS =

# Project basename extracted from the current directory name
PROJ = $(shell basename `pwd`)

# Sources
OBJ = $(PROJ).o

$(PROJ).prg: $(OBJ)
 cl65 $(OBJ) $(LDFLAGS) 
 cp $(PROJ) $(PROJ).prg

%.o: %.c
 cl65 $(CFLAGS) -c $< -o $@ $(LDFLAGS) 

%.o: %.s
 cl65 -c $< -o $@ $(LDFLAGS) 

run:  $(PROJ).prg
 x64 $(PROJ).prg

clean:
 -rm *.o $(PROJ) *.prg

As long as the Makefile is positioned in a correctly-named folder with a correctly-named source all should be ok when running make.  make clean will remove all previous compilation outcomes and make run will compile and run the Vice emulator. (x64) These will need to be "teached" to the text editor. In my example I've not included any libraries or linked files so the LDFLAGS is left empty.

Added assembler sources (not inline) can be added to the source line, e.g. if you have sourcea.s and sourceb.s then add sourcea.o sourceb.o after OBJ = $(PROJ).o and so on. (Apparently it's not very simple to have make generally link all sources present.)

So, if I have the following test.c source inside a folder called test, and my Makefile is also there, I can make run and have the emulator run the resulting program. It only turns the border black (using inline assembler) and the background red (using C).

void main()
{
__asm__("lda #$00");
__asm__("sta $d020");
  *(char*)0xd021=2;
}

Designing the Automated Office 1984

I took some photos out of an old book, Designing the Automated Office (by Pulgram and Stonis). Mostly it's the usual early 1980s normative design guideline book with scientific-looking diagrams and measures, but it also has nostalgic photographs of cute terminals and overtly neat environments. Published in 1984, the material reeks more of late 1970s stuff, not very visionary or with the latest trends. Unix, CP/M and Xenix are the only OS mentioned, it's as if personal computer revolution had not happened at all.

Sorry for the poor quality, these are simply mobile snaps. Maybe improved later...

A company that worked on computers would probably be an early-adopter...

Not a huge expert on offices, but I've worked in some and been involved with it as a topic. Office space trends are obviously always in transition, but what's particular about this era is that the layout of the office still remains fairly traditional, yet is invaded by computer terminals and equipment. Soon after, developments in computer applications among other shifts started to erode the traditional office space layout, too.

Old CAD workstations prove that Apple didn't invent GUI. Design-metaphor ought to have become the generic GUI metaphor, and not the desktop! 

It seems to have been terminals all the way. Most of the stuff has probably been thrown into the bin since, and is not that noteworthy. The outer designs are fascinating, though, as there seems to have been broader ideas about what a computer terminal in an office ought to have looked like, before it all settled into grey rectangular boxes in the 1980s.

Another cute, if repetitive, semi sci-fi environment.

When discussing future offices, a lot of expectations are put on voice recognition (as still is) and "smart walls" with text recognition (we are still waiting). In 1984, it may not have been hard to predict that video projection would become commonplace, but they sort of missed the mark on what would be reasonable complementary technologies. I've yet to see any really sensible smart wall product for office. Possibly this is because although smart walls are feasible now, the settings in which they were envisaged for are not really there anymore.

I'm wondering if that's a microwave oven or some kind of information superhighway.

Prior to computers the office kinda was the "computer", so as computers matured the office as an environment started to become a bit redundant. There's some indication of this in the book, as portable computers and gadgets are discussed. These are a bit naive in hindsight, but what else they could have imagined?

Typing "please come in", the text would handily appear outside the door, where the client was waiting...

A little something about Finnish computer magazine scene

MikroBITTI, the Finnish general computer magazine published from 1984 and discontinued in early 2015, has now fused with another magazine, born again with the original logo and a promise to focus on computer technology. Published monthly, the new mag concentrates on reviews and commentary of computing products, spiced with more speculative futurist articles, tutorials and opinion pieces. This is very much in line with the original magazine which inherited the review-orientation from the long-running Tekniikan Maailma ("The World of Technics").

MikroBITTI and Skrolli head-to-head. WHICH ONE WILL WIN

This is not the only new paper-based computer magazine that uses the 1980s recipe to attract new old customers. Skrolli, published from since 2013, 4 times a year, instead focuses on non-commercial, hacker, DIY, development, programming and demoscene cultures and rarely if ever includes consumer reviews. Skrolli was the first to tap into this new niche of catering for the, let's say, 40-somethings who grew up with Commodore 64, Amiga and early PCs.

It's a bit too early to compare the two magazines, as there's only one issue of the new MikroBITTI. Based on that I have to say the reborn MikroBITTI succeeds in re-orienting the magazine to a better direction, but it remains to be seen if it can be as interesting experiment as Skrolli. The reviews are surely extensive and include many devices that might otherwise be missed, now that there's an abundance of technical computer gadgets for different markets. I'm just wondering if there will be any product category left to review for the next issue! As a quarterly, Skrolli perhaps has to rely less on immediate topicality, striving towards more "deep" content on current themes.

It is arguable the new MikroBITTI has followed the example of Skrolli, but I have to say at the moment the two publications are quite different. The nostalgic logo and the graphic design were attractive enough for me to buy MikroBITTI, and I suppose many people felt the same way. The journalism, although maybe more evenly professional than in Skrolli, is also a bit generic and conventional. Although Skrolli in contrast has a more generic graphic layout, the inclusion of "amateur" images, drawings, photographs and an unapologetic use of crude screenshots helps give a friendly DIY-tone to the magazine.

Example of the stylish graphic design in the insides of the born-again MikroBITTI

Why paper now?

It's interesting that there would now be a market for paper magazines. In the UK, the number of magazines has been constantly dwindling, and only some very niche "retro" oriented publications could enter the market. Even this is already a fairly old phenomenon. Skrolli and the new MikroBITTI are not at least decidedly retro- or games-oriented. It's more like if someone in the UK thought that Your Spectrum (ca. 1984) had a great concept and ought to be seriously (and not only as a nostalgic one-off) re-wired for today's audiences.

Especially one has to wonder how some of the most techno-enthusiastic people would now clamor for an old-fashioned paper publication, even if they may have been one of the first to move away from them. (Consider disk magazines, 1990s BBS scene, internet etc.) One reason may be that there is a whole generation of computer users who grew up with magazines like BITTI and Printti, even if they may have abandoned them later. These people long lamented the lack of good computer journalism, which the 2000s magazines allegedly failed to deliver. Or I'll take that back - the old journalism wasn't that good necessarily - it's just that there was a specific mixture of elements that sort of disappeared from the market as internet began to make it unnecessary.

So there might be a market but what do they want? The cliché "audiences want well-curated content" is somewhat valid, but there's no reason why it would not work on the internet too. Yet I suppose over-abundance of daily-updated information and the effort that goes in searching the web can reduce attractiveness of specialist websites. Tired of constant feeds, audiences might want to return to the occasional bundle of information and entertainment. It is nice to browse magazines that have made choices for the reader and don't appear too often. The paper magazines may also better function as kind of banners under which the readers can show allegiance and support to a culture of computing they wish to foster.

What for?

The home computer technology has long become separated into two directions: On one hand, the earlier "pure computer" hardware, and on the other hand, all the commercial gadgets that achieve specific tasks (facebooking, messaging, camera, calendar etc). The computers in the first case are not "for" anything. Skrolli embraces this fully. Skrolli is more about the "cultures" of technology, digging the areas that commercial computer journalism and academia don't quite cover. I fondly remember the Issue 3/2014 which featured articles on Forth, Emacs, soundtrackers, fixing old pinball machines, Amiga... All simply because this is interesting now and by itself, and not just as a historical overview. An inspiring mess.

MikroBITTI seems to believe in the usefulness of the computing technology in every day life. The reviews in BITTI are a powerful means to collect at-a-glance overviews of latest computer technology that reside in the periphery of your interest, whereas Skrolli at it's best is able to probe into a rich thematic variety that inspires the reader even when the topics are not directly relevant to me. Both are fun to browse.

In any case, the paper magazine trend may turn out to be a fad only related to a particular generation of Finnish computer enthusiasts, feeding on nostalgia of something disappeared. Nerds-turned-busy dads may want their nostalgia/news arrive at their doorstep rather than spend active time to find it. Yet this generation may also prove to be a loyal customer, if the magazines can continue to deliver interesting content.

Edit: The second issue of MikroBITTI just arrived. It has roughly 50% of reviews, spearheaded by a meticulous wifi-router comparison. The appeasing of "retro" fans has ceased, no more posing with an MSX or talk about Amigas. The cover seems to have reverted a bit towards the consumer-style magazine, promising mobile phone reviews and the wifi-router article. The general interest articles are pretty nice, one about the anatomy of silicon chips, and another about the history of Finnish on-line discussion cultures. There's also a little piece about Habitat. I'd say we're still heading a pretty good direction, a bit worried the reviews take so much space.

Pathetic trolling! Everyone knows Atari ST was better.