Search Results for ‘Processing’

Lisää vaan Processingia

Kun kerran into on löytynyt, ainakin pariksi päiväksi:

  • Karuhko interaktiivinen Mandelbrot-generaattori: mandelzoom
  • Reaaliaikainen Julia-generaattori: juliaset
  • Dragon-fraktaali: dragonfractal. Tarkoituksella hidas, että iteraatiot näkee.
  • Saa sen 3D:n kiihdytettyäkin: kolmereegl, mutta ainakin Linuxilla vaati Javan turvallisuusasetusten höllentämistä (System – Preferences – Sun Java 6 Plugin Control Panel – Advanced – Security – Mixed code – Disable verification), kun en halunnut nyt ruveta tutustumaan tuohon onnettomaan koodin allekirjoitukseen.
  • Rekursiivinen puu ja jonkun sortin motion blur: recursion

Mandelzoom toimi Processing.js:lläkin, mutta oli todella hidas. Dragonin luulisi olevan ok ja Julian sitten taas hidas.

Add comment October 19th, 2010

Jälleen Processingin äärellä

Opetettuani viikon Processingia koululla se jäi vähän päälle, ja tuli taas näpyteltyä jokunen sormiharjoitus:

  • Piechart. Piirakkadiagrammi-komponentti. Tätä voisi suorastaan käyttääkin johonkin tarvittaessa. Värit hieman sinne päin ja tekstien paikkaakin pitäisi miettiä, mutta kaikkiaan simppelin toimiva.
  • Kolmeree. Hieman hitaanpuoleinen 3D-demotus. Hidastelu tulee jostain muualta kuin kuutioiden määrästä — sadalla menee melkein yhtä lujaa.
  • Objtest. Valmista Objloader-palikkaa käyttävä .obj-mallin pyöritys. Helpostihan tuohon saa jotain ruudulle.

2D-graffassa Processingin pikselipohjainen koordinaatisto on ihan jees, mutta 3D:n tapauksessa parannettavaa olisi. frustum() ei toimi kuten glFrustum, vaan säätää ainoastaan projektiomatriisin muodon. Ratkaisuni oli translatoida ja skaalata grafiikka widthin ja heightin suhteen, jolloin ikkunan koolla ei ole merkitystä ja origon saa ruudun keskelle. Lievänä ärsytyksenä koordinaatisto on vielä vasenkätinen

Add comment October 11th, 2010

Processingin rumat fontit

Kokeilin ekan kerran Processingia Linuxilla ja tuntuu toimivan ok. Jostain historiallisista tai käytännöllisistä syistä sitä ei saa paketinhallinnasta, vaan se pitää ladata sivuilta erikseen. Ubuntussa piti asentaa Sunin Java-paketit (sun-java6-jdk, -jre ym.), sillä heti alkuunsa tuli valitus, ettei Icedtean kanssa luvata yhteensopivuutta. Icedtea kannattanee käytössä muutenkin unohtaa — eipä nimittäin toiminut sen selainlaajennuskaan (sun-java6-plugin koneeseen ja johan soi). Muuten näytti jo hyvältä, mutta editorin fontti oli kohtuuttoman ruma ja palikkainen ilman antialiasointia. Kerrottakoon nyt kaikille muillekin varmuuden vuoksi: kotihakemistossa sijaitsee .processing/preferences.txt ja siellä oleva editor.antialias=false pitää muuttaa muotoon true. Mäkillä fontit ovat tuntuneet olevan vakiona ok, joten sen kanssa ei ole tarvinnut tähän säätöön kajota.

Add comment September 25th, 2010

Pixel Polizei

ppolizei-msx ppolizei-plus4 ppolizei

“Systeemin vartija se poliisin on työ / Poliisi hippejä pampulla lyö”


  • 8.7.2017: What, updates? Yes! Fixed BG colors should work now with Plus/4 multicolor. Thanks to Ptoing for the bug report. In addition, the latest source-only features are now part of the binary distribution.
  • 6.5.2016: Source-only: You can set your own error color with ERRORCOLOR in prefs.txt
  • 31.5.2016: Source-only: Loading transparent images doesn’t create a mess anymore. Fix kindly submitted by Dr. TerroZ.
  • 25.5.2016: Another quick binary release with:
    • HRS loader and writer for Le Oric
    • ColecoVision screen 2 support
    • Name table supported on the MSX when loading SC2 images
    • Improved MZ-800 palette and viewers
  • 23.5.2016: A brand new binary release with the following additions:
    • Sharp MZ-800 mode 1/2 (16/32k)
    • Sharp MZ-700
    • Panasonic JR-200
    • MSX screen 3
    • Smarter multicolor for the C-64 and Plus/4
  • 17.5.2016: Aaand the first release is out!


Pixel Polizei is a tool for the retro/scene/retroscene artist. It lets you automatically check whether an image conforms to the color limits of a particular oldschool platform and save the result in certain native formats. The underlying idea is that you can use whatever paint program you happen to prefer for creating the images and observe – almost real-time – if you’ve made a mistake somewhere. One more fundamental bit is that the tool is multiplatform unlike many others.

Pixel Polizei is not a paint program or a generic image format converter, even though the aim is to implement at least the most typical file types for the supported platforms. Neither is it meant to be used as a converter for random family photos. You can use it for that purpose too, but the end results won’t be as good as with dedicated tools. For converting various old formats to modern images check out the Recoil project.


There’s not much to it: load an image, check whether it’s ok and save it in another format. In the case of errors you can either fix them in your favorite paint program and retry or force the colors to comply. When a piccy is loaded it is automatically converted to the native colorset without dithering, so do that kind of magic elsewhere if needed. Furthermore, remove any borders that you might have or the image will be scaled incorrectly.

If the loaded png or gif is not of the native resolution, it will be down- or upscaled as necessary, which might or might not produce the desired result. Therefore it’s generally better to do the scaling elsewhere. C-64 multicolor and CPC mode 0 have very flat pixels, so drawing a 320×200 image will probably be easier; every second column will just be discarded.

Checking and forcing can be done automatically. In that case Polizei works according to its name and constantly polls whether you’ve saved the file anew. If there is an updated version, it’s loaded and checked automatically. This way you can quickly find and fix color clashes – keep the Polizei window always visible on another screen or in some corner.

The zoom toggle lets you look at the image closer, and a grid is available for you as well to better see the character block locations. If the platform has a selectable border color, just click on the color selector.

Check out the “palettes” directory to find the exact colors used on each platform. Drawing with those colors ensures that there’s no complications when importing the image.

Keyboard shortcuts

  • c – check
  • f – force
  • g – grid on/off
  • r – revert
  • z – zoom on/off

In some modes you need to press shift when clicking the color selector to set the background color.


Some settings can be controlled through prefs.txt which should reside in the same directory as the program itself. The following options can be used:

  • ZOOM=x where x is 1 or more. Note that with ZOOM=1 pixels are never stretched to mimick a real aspect ratio. The larger the value the slower it gets. This is all about UI zooming, not the zoom function of Polizei.
  • GRID=x, set to 1 to show the grid when starting the program.
  • PATH=x where x is the absolute path of the directory where your images can be found. Leave blank to go with the default. Do not use quotation marks.
  • ASPECT=x, which can be one of PAL, NTSC or SQUARE. Used for stretching the pixels like the real machine would. Not relevant on all platforms.

Supported Platforms

Next follows a list of the supported machines, graphics modes and file formats, coupled with platform-specific quirks (if any). New file formats and machines will most likely be added later.

Amstrad CPC

The CPC is an exceptional 8-bit as you don’t need to care about color clashes: any pixel can be of any color (16 colors in mode 0 and 4 in mode 1). It also has a palette of 27 jolly happy colors to choose from. I found myself wondering what the heck they were thinking when designing the bitmap layout like that.

  • Supported modes: Mode 0 and 1, with or without overscan (160×200/192×272 and 320×200/384×272).
  • Supported formats: bin and asm. When copying the files to a dsk image the needed start/load address is $6000 for ordinary images and $100 for overscan pics.

To display the image on an emulator or a real machine, you need to get the file to a floppy – most likely a DSK image. There’s ManageDSK for Windows and iDSK for the rest of us. iDSK probably won’t compile out of the box, but just keep adding #include <stdio.h> to the offending source files until it does. After that you should be able to do this:

iDSK mydisk.dsk -n
iDSK mydisk.dsk -i piccy.bin -t 1 -e 6000 -c 6000

And run the binary from BASIC with:



This console is so close to MSX (same CPU and VDP) that it was easy to add trivial support for it.

  • Supported modes: screen 2.
  • Supported formats: col and asm. MSX sc2 files can be loaded or saved, too, since it’s the exact same mode.

COL is essentially a module dump that you can feed to any emulator or flash cart. I’m not sure if there’s much use for this particular converter, but at least you can show pics on your old hardware – a nostalgic birthday gift for a Coleco fan maybe?

Commodore 64

This old workhorse has been explored over and over again throughout the years. From a graphician’s perspective there are dozens of curious hacks that let you display more colors and pixels than what the standard modes allow. Use the well-known Pepto palette to ensure a faithful conversion.

  • Supported modes: hires and multicolor. At least basic FLI support will probably follow at some point, but as there’s a plethora of hacked modes, don’t expect all of them to make an appearance.
  • Supported formats: (Advanced) Art Studio, Doodle, Koala, prg and asm.

There is automated logic which tries to choose the multicolor common “background” color wisely, but as it doesn’t always work out, you can also select the color yourself (shift-click or rmb) and turn fixed bg on.

The resulting PRG files can be run directly by using VICE, 1541 Ultimate or SD2IEC. For some situations you may want to create a floppy image, which can be done with for example c1541 that comes with VICE:

c1541 -format mypic,0 d64 mypic.d64 -attach mypic.d64 -write piccy.prg piccy

Commodore Plus/4

It wasn’t a biggie to add support for the Plus/4 after getting the C-64 side working. A lot of colors available for you (121 shades) and practically square pixels in hires. Not that different otherwise to the C-64, except in multicolor you have 2 global colors and only 2 free colors per block.

  • Supported modes: hires and multicolor.
  • Supported formats: Multi Botticelli, prg and asm. Name Multi Botticelli files m.something.prg so that the original program finds them too.

There is automated logic which tries to choose the common “background” colors for multicolor pics, but you can also select the color yourself (shift-click and rmb) and turn fixed bg on.

Running the resulting PRG files is pretty much the same as on the C-64. See above.


A plain MSX1 can do 256×192 pixels with 15 – not 16 – washed-out colors. PAL machines produce a really flat “widescreen” image, whereas the NTSC ones are more or less 4:3. MSX2 computers could display a lot more colors at better resolutions, but at least as of now they’re not supported, as they’re not that special from a conversion point of view.

  • Supported modes: screen 2 and 3. S2 has otherwise free color placement except that a block of 8×1 pixels can only have two colors. S3 is blocky and has free pixel placement.
  • Supported formats: sc2, sc3, com and asm. Name table supported with sc2, but sprites not.

The com files are normal MSX-DOS programs that you can copy to a floppy or an image for running them on a real machine or an emulator. The good old wrdsk will do the trick:

wrdsk myfloppy.dsk msxdos.sys

SC2 files are essentially screen memory dumps that can be directly loaded from BASIC like this:



Le Oric’s graphiques are completely different to almost any other machine. It’s a bit like teletext in some sense: you can either show pixels or change the paper/ink color. To make it even more complicated, any 6×1 block can also be shown in inverted colors and the bottom of the screen (3 character rows) is hardwired to text mode. Read this.

  • Supported modes: hires. 240×200 pixels with 8 colors. Setting the border color will only affect the last three text lines.
  • Supported formats: tap, hrs/hir and asm. Apparently there exists something called hrs/hir, but nobody has taken the time to document the format.

The tap files can be run from basic with a CLOAD”” or CLOAD”PICCY” depending on the emulator. Use the tap2wav utility to turn the emulator file into audio that can be played back to the cassette port on a real machine. I’ll look into disk files later, but no promises yet.

HRS (HIR) files are simple screen memory dumps saved from BASIC. They can be displayed by switching to HIRES and then simply cloading the file as above. To save one on a real machine, try this:


Panasonic JR-200

Not many have ever even seen this failed Panasonic venture. See here for some technical discussion. From an artist’s standpoint it’s not unlike the Spectrum, except there’s no brightness bit and you can only have 320 different 8×8 character blocks. In addition, there’s blocky 64×48 pseudographics without attribute limits – both “modes” can be mixed freely.

  • Supported modes: 256x192x8 hires.
  • Supported formats: cjr and asm.

Panasonic emulators are scarce, but Virtual Panasonic JR-200 will get you started at least. CJR files can be loaded to the emulator or converted to wavs for playing back to the cassette port. See here again. If your goal is to convert Spectrum images to the JR-200, check you-know-where for an interactive tool aimed specifically for that. The images can be displayed as follows:


Sharp MZ-700

The MZ-700 is a slightly revamped consumer version of Sharp’s old microcomputer series. 64k memory, color graphics and… wait, there’s only 80×50 pseudographics with a 40×25 color grid.

  • Supported modes: 40×25 character approximation and 80×50 pseudographics.
  • Supported formats: mzf and asm.

When approximating pixel graphics with characters you may gain a slight advantage by including the absurd 2nd character set in the conversion. Beware, however, that the output won’t work correctly on Japanese machines that used the 2nd set for something useful instead of various 2×2 character faces and Pacmen.

Pretty much any emulator supports MZF files, which you can load from the monitor by typing L. For a real machine take a look at mzf2wav.

Sharp MZ-800

A lot more capable than its predecessor, the MZ-800 can display 320×200 pixels with four colors or 640×200 with two. Rather exceptionally the graphics are planar and thus pixel placement is free. Add another 16k of VRAM and you get 320x200x16 and 640x200x4.

  • Supported modes: mode 1/2. 320x200x4 on a stock machine, 16 colors with 32k VRAM.
  • Supported formats: mzf and asm.

Like with the MZ-700, emulators support MZF loading. In addition to the monitor method you can also choose option ‘C’ from the main menu. mzf2wav is again your friend when dealing with real machines.

ZX Spectrum

The British miracle can display 256×192 pixels with 15 different colors, but in a block of 8×8 you can only have two different colors, which makes the machine a true giant when it comes to color clashes. Furthermore, you can’t have bright and dark colors in the same block.

  • Supported modes: eh… there is just one.
  • Supported formats: scr, tap and asm.

An scr file (also known as SCREEN$) is a simple memory dump of the Spectrum screen and supported by various tools and emulators. A tap file can be loaded by emulators or from a card reader such as divIDE. You can also convert .taps to audio using tap2wav and then play them back to a real Spectrum through the cassette port. LOAD”” is all you have to type.


The latest stable binary is available here: If you’re after the latest features and bugs, check out svn:// Because the program is written in Processing you – unfortunately – need to install Java 7 or newer to run it. Mac users should visit System PreferencesSecurity & Privacy if you see something like “blah blah is damaged and can’t be opened”. Allow “any” software to run to correct the problem.

If all else fails, download Processing 2.x (3.x won’t work at least as of yet) and run from source: copy the “ppolizei” folder from “src” to your sketchbook and open ppolizei (.pde if you’re using the file selector). Press the play button and enjoy.

It shouldn’t be too tricky to add new file formats or even totally new machines. Contributions are welcome, but let’s stick to a 4-char tab to keep the source uniform. The code is released under the liberal WTFPL license.


  • Most code and design: Marq/Fit^L!T^Dkd (see also: PETSCII)
  • Several templates and other help: Dr. TerrorZ/L!T (see also: Multipaint)
  • C-64 palette: Philip “Pepto” Timmermann
  • MZ-800 palette: Chaky

May 16th, 2016

PETSCII editors – design thoughts

After more than two years of improving and honing my own project, and checking the competition I got the urge to share some of my thoughts on what makes or breaks a PETSCII editor. A lot of this stuff is actually pretty self-evident in the end, but it has taken hours and hours to figure it out. Bear with me 🙂

Not pixels

When comparing a PETSCII editor to a generic paint program there are plenty of similarities, but also notable differences. Instead of tens of thousands of individual pixels we’re dealing with a relatively low-resolution grid consisting of predefined symbols. On the one hand it is easier to deal with text, since tools such as lines, ellipses and curves are rather useless, but on the other hand there is a constant need to effectively choose and alternate between the available symbols, which requires different kind of thinking altogether. In other words, adopting tried and tested methods from paint programs alone will not lead to optimal outcome.

Among the most powerful features of PETSCII (the editor) are smart rotation and flipping of a selected area which take into account the form of the character. I take no credit for these, as it was Tero who came up with the idea in the first place and wrote the remapping tables. Not every character can be rotated or flipped, but even so you’ll save a lot of time when working with symmetric forms. See the following image for an example of how “smart” flipping works as opposed to simply moving the characters:


Typing vs. drawing

In essence there are two main methods to get characters on the screen. The traditional way, typing, was initially the only possible option and is still heavily present in modern-day editors (for example AAE). A mouse is something of a rarity on C-64s and graphical symbols can be conveniently found on the keys, so on a real machine typing makes all sense – but a lot less so on your PC or Mac which has a different keyboard to begin with.

I’ve included a half-assed typing mode in PETSCII, mostly for the sake of actually writing text, even though all the symbols can be typed too if it’s really necessary. In any case, drawing with a mouse was the preferred metaphor right from the beginning. There are pros and cons to both, but using a mouse definitely makes it quicker to sketch forms in the spirit of direct manipulation. A little but important detail is to show the character before it is actually placed: otherwise you end up constantly undoing the operation.

Character selection

When drawing, a great deal of time is spent on selecting the next character. The first thing to do was to reorganize the otherwise messy character set to group related symbols together (thanks go to Tero again). Jambonbill went even further and repeated the same characters multiple times to create visually continuous groups.


A well-organized character selector is a good start, but much more can be done to facilitate an efficient workflow. For example in PETSCII the aforementioned rotate and flip operations work with individual characters as well: press a single key and get the next corner for a window or a box. In the same lines I came up with “smart sets”, predefined sets that you can walk through with a keypress. Another little bit that arose from a real need was to let the user quickly shift stick characters (used for various lines) right/left/up/down.

As a piece of PETSCII art is drawn, you typically start accumulating useful characters and their combinations in the image itself. Instead of always going for the selector – which in Playscii even occludes part of the canvas – it makes sense to quickly pick a character from the surroundings.


You can get away without a grid if the images are comparably small, but all in all a well-working grid can be of great benefit when selecting regions and aligning symbols with each other. After at least three complete rewrites of the drawing code I’ve eventually come up with the following findings:

  • Don’t make the grid intrusive (thick, contrasty etc.)
  • No single color works for the grid alone. Instead, darken light colors and lighten dark colors to keep it harmonious.
  • It’s useful to have a quick on/off toggle

Below a few real-life examples of how the grid looks like in different editors.


File formats

The file formats supported by an editor tend to reveal its intended use. Some editors are clearly geared toward actual machines, stick to their limitations and facilitate easy exporting to formats like .prg, which can be run on real hardware. At the other end of the spectrum you might get only PNG files or GIF animations out for easy distribution on the web.

I’ve been balancing between the two extremes myself: initially the idea was to support software development and participate in demoscene competitions. However, it soon became evident that many people needed and wanted to distribute their works online for easy viewing, so I had to give in and add a PNG exporter. Supporting multiple exporters for multiple machines obviously means plenty of error-prone extra work.

Automatically converting existing images to PETSCII is a different discussion altogether. Having said that, many users would welcome such a feature for, say, converting their self-portrait into retro character art. In addition, an artist can benefit from a reference image, as some of them prefer sketching on paper first before firing up the actual editor.

Animation and other fancy features

Creating proper support for animation is probably as big a task as all the others combined. As of now there are animation features in multiple editors, but none of them really go beyond simple copy/paste and playback of the frames. Think of a proper video or animation editor to realize how many possible features there could be.

Undo and redo aren’t exactly “fancy” features from a user perspective, but it takes some effort to include them in your editor. It’s definitely a good idea to implement them early on, as adding them as an afterthought might prove painful – speaking from experience 🙂 There are more and less sophisticated ways to go about undo, but as we’re dealing with quite little data it’s not all that bad to just save the buffers between operations for undoing or repeating the steps. Another welcome safety network comes in the form of automated backups.

There are a couple of editors that support layers, approximately in the lines of your familiar photo editing software. I can definitely see some uses for them, for example for separating the background from foreground figures. Then again, to fully support layers requires considerable effort, and they aren’t quite as useful as in photo editing, as you can’t really have things like translucency or color manipulation.


While some users are after a genuine user experience – tapping away on a real C-64 – most seem to welcome the ease of cross-development. Supporting the three main desktop platforms (plus their different flavors) is tedious at best, and thus some of the editors run on Windows only. Being a Mac/Linux user myself this was, of course, out of the question, but luckily Processing lets you export multiplatform applications with little extra effort. On the downside, Java is required on the target machine, which will turn off some possible users (and rightfully so).

As I see it, the best bet these days would be to develop for the web. In spite of the possible troubles with browser compatibility, web applications tend to be multiplatform by nature. In addition, you don’t need to go through the trouble of installing anything on the local computer. If I were to start from scratch, I’d probably take this route. As of now there are two online editors already, even if neither of them is quite complete yet (see my previous post).

Another angle to accessibility follows from the fact that people use laptops and tablets with a crammed keyboard. Therefore, relying on numpad or function keys beyond F10 is obviously out. Likewise, touch pads (esp. Apple ones) might not have more than one or two mouse buttons available, which requires some thought. Even more so for touch screens, which again introduce a new set of challenges.


I can wholeheartedly relate to programmers that want to spend their free time on interesting coding problems instead of writing documentation. Even if it’s not exactly fun, there is a need for at least some product support: be it a manual, online help or a website. A few nice example works done with the editor definitely don’t hurt, as they show what’s possible and spark user interest.


Cross-development tools for PETSCII are a surprisingly new phenomenon. As far as I know, they’ve been around for not much more than five years, after which things have really started picking up speed. The threshold of starting to do character art has probably never been lower, and new authors are popping up every now and then.

All in all, the challenge of programming a PETSCII editor is twofold: there’s the tech and then there are the users. It’s not hard to put together basic minimum functionality, but going beyond that has turned out so laborious that most projects have been abandoned shortly after their initial release. PETSCII too would require quite an overhaul by now to accommodate any new major features – feature requests are, of course, neverending.

Implementing new modes, tools and so on is one thing, but thinking about the workflow and making the features useful is another. If you’re not much of an artist yourself, it’s at least good to have one in the loop: user feedback or even going so far as to observe someone’s work over their shoulder provide valuable insight and motivation. Ok ok, that was the design teacher in me speaking 🙂

2 comments April 6th, 2016

PETSCII editors: an overview

I’ve been rather actively involved with PETSCII art for the last couple of years, coding, drawing and even conducting a bit of research. As PETSCII is kinda fashionable now, and many people would like to experiment with it, here’s a little overview of the available editors and their pros and cons. The list aims to be complete, so if there’s anything missing, let me know. Let’s start with native tools and then move on to cross-development.

It’s a fine line, but I’ve decidedly excluded various text editors that could be used for character graphics as well.

Digital Paint 4.0 (C-64, link)

Probably ok for its time – can’t quite pinpoint when exactly it was released. In addition to the original version coded by Aaron Hightower there are various hacks by sceners who added missing features. In addition to typing, you can paint filled boxes and edit colors.


TBoard-Painter 1.1 Pro (C-64, link)

Another oldie, this time by Tao/Triad. The most notable extra feature is the 1/4 char pseudographics drawing mode. The image can be larger than the screen size, which together with the name suggests it was meant for BBS graphics. As a nice little touch the x/y location display uses hex numbers 🙂


Tyronpaint 2.1 (C-64, link)

Not much new to say about this: you can type text, change the color or draw blocky 1/4 dots. The images can be higher than 25 lines. Created by Lynchbit/Alpha Flight in 1996, this improved version is from 2006.


Kaleidoscope 4.0 (C-64, link)

Very simple, but at the same time easily comprehensible editor by BroBryce64 all the way from 1989. Not many features there, but you can type chars and change colors. A curious extra is the “rainbow mode” which cycles the colors after each character.


PETSCII Paint 0.5 (C-64, link)

A rudimentary tool by 0xDB from 2011. The basics do work: you can select characters, change colors and save the outcome, but even simple things tend to be on the tedious side.


Petscii Editor 4.6 (C-64, link)

FieserWolf’s editor is undoubtedly the most popular one when it comes to programs running on real hardware. As the version number suggests, there have been plenty of iterations and the workflow has been improved a lot since the initial releases. Once you get used to the UI, there’s useful functionality such as copy/paste, recoloring and multiple pages available. Several notable works have been produced with this editor.


Online PETSCII Editor (online, link)

A web-based solution by Krissz from 2013. I like the idea that you can draw on a normal browser without installing any software or digging the old warhorse from the closet, but this particular project seems to have been abandoned. You can both draw and type, and the character selector is well though out. On the other hand, there is little functionality to support advanced editing.


PET Shop Pro (online, link)

As of now there’s very little documentation on this editor by Jambonbill, as it is still work in progress and not officially released. Nevertheless, quite a promising online tool which lets you even do animations. Originally based on Krissz’s editor (see above), but was mostly rewritten after that. The character selector is well designed, you can edit images of various sizes plus export them to different formats, and even script the editor. There are still some bugs around, which will hopefully be ironed out at some point.


CBM .prg Studio (Windows, link)

Arthur Jordison’s CBM .prg Studio is a complete development environment that lets you create software for the Commodore 8-bits. One of its parts is the screen editor, which is actually quite usable for artistic endeavours too. Largely served as the source of inspiration for the editor below.


APE (Windows, link)

APE (Another Petscii Editor) by MrXaliasH from 2013 is Windows-only, but does run fine under Wine as well. The basic functionality (drawing, color selection, copy/paste and even undo) is there, but it seems the project was quickly dropped after its initial release.


C64 AAE (Windows, link)

C64 ASCII Art Editor by RADSoft hails from Poland. Windows-only, but runs somewhat ok under Wine except the color editor. Apparently the development ceased in 2012, but in spite of that there are some unique features – most notably layers, which were a firstie in the scene. The animation features are also among the most advanced. Drawing happens by writing, but unfortunately the key mapping doesn’t suit all keyboards. Furthermore, keyboard shortcuts require quite heavy juggling with various ctrl/shift/alt combinations.


EDSCII and Playscii (multiplatform, link)

EDSCII by JP “Vectorpoem” LeBreton was one of the first editors I tried in 2013. Later on its development halted and Vectorpoem created a new tool called Playscii. Both versions focus on PETSCII-like retro graphics instead of sticking to the exact capabilities of the C-64. Still under development, Playscii already features plenty of functionality such as different character sets, layers, animation frames and smooth zoom, plus of course the standard editing tools. There is also something called “game mode”, which I didn’t quite understand at first sight, though.


PETSCII (multiplatform, link)

Do not expect me to be very objective with this 🙂 The project, initially coined by me and Dr. TerrorZ, started in 2013 and has received occasional updates ever since. In addition to the standard stuff there’s rudimentary support for animation and other machines than just the C-64 (VIC-20, PET and Plus/4). One recognized problem is that because of Processing, the program runs on Java, which spells trouble these days. The GUI is undeniably “no-nonsense” with most functions hidden behind single-key shortcuts.


In conclusion, there’s already quite a variety of tools available these days, and some are surely still missing from the list – not everyone has made their software public in the first place. At one end of the spectrum there are hardcore editors running on genuine hardware, and at the other retro art oriented tools aimed at recreating the old look with less regard for authenticity (at times called fakescii). Pick your poison!

edit: More additions, thanks to Goto80 for the tips!

edit2: More details on Pet Shop Pro received from Jambonbill himself.

4 comments March 22nd, 2016

Raspberry Pi 2: hyvät ja huonot uutiset

Lägään tällä hetkellä näiden Raspien kanssa hieman perässä, sillä rupesin vasta testailemaan synttärilahjaksi saamaani 2B-mallia. Jälleen kerran hieman nopeampi kolmonenhan tuli juuri uunista ulos.

Juhlapuheista huolimatta etenkään alkupään Raspeista ei todellakaan ollut työpöytäkäyttöön: muistia oli liian vähän, X:n ja SDL:n kiihdytykset riittämättömiä, ja jo muutenkin hitaan koneen hyydytti viimeistään käyttiksen ajaminen SD-kortilta. Muutaman vuoden aikana ytimiä on tullut kolme lisää, ja kenties vielä tärkeämpänä parannuksena muistin määrä on noussut gigatavuun. Mutta ollaanko vieläkään työpöytäkäyttöön riittävällä tasolla?

Kyllä, ei ja ehkä. Raspi 1:een verrattuna työpöytä pyörii mainiosti, mutta toisaalta hitainkin nykypäivän Intel-pohjainen miniläppäri on edelleen nopeampi. Hitaus ja nopeus ovat pitkälti ohjelmista kiinni: mukana seuraava Web-selain ja LibreOffice ovat aivan käyttökelpoisia, kun taas Java-pohjainen Processing hyytyi varsin ikävästi. Pikaisesti kokeilemani kevyet emulaattorit toimivat sinänsä ok X:n päällä, mutta kiinteän resoluution ja puuttuvan video-overlayn vuoksi niitä ei saanut koko näytölle (resoa voisi toki pudottaa, mutta se on ongelman kiertämistä eikä ratkaisua).

Pahin pullonkaula tuntuu edelleen olevan massamuisti. Siinä missä SSD:istä on tullut päivittäistavaraa isojen koneiden puolella, pikkulaudoissa ollaan edelleen jumissa USB2:n ja muistikorttien maailmassa. Odroideissa nähty eMMC on jonkin verran parempi, mutta jää sittenkin SSD:lle mennen tullen.

Parhaimmillaan Raspit ovat niille erityisesti räätälöityjen softien kanssa: mediatoistimista, emulaattoreista ynnä muista on optimoituja versioita, jotka käyttävät videoskaalaajaa tai OpenGL ES:ää tavanomaisten kirjastojen sijaan. Yllätyin itsekin, kuinka paljon 3D-rauta jaksoi puskea, kun sitä ohjelmoi järkevästi. Ylimääräiset kerrokset, kuten Java ja JavaScript, ovat puolestaan myrkkyä suorituskyvylle.

Monia päivittäisiä asioita voi tehdä jo nykyiselläänkin riittävän sujuvasti, kunhan hyväksyy tietyn ajoittaisen tahmailun. Ainoaksi peeseen korvaajaksi en Raspia edelleenkään laittaisi, enkä usko kolmosenkaan tilannetta merkittävästi muuttavan, varsinkin kun massamuistiväylät eivät ole sen nopeammat. Toisaalta tarkkaan rajatussa yksittäisessä käytössä etenkin tämä uusi Rapsutin voi olla aivan riittävän tehokas ja hinnaltaan kymmenesosa “oikeasta” tietokoneesta. Palataan asiaan taas parin sukupolven päästä.


1 comment February 29th, 2016


Kiitos nimettömän lahjoittajan, sain käsiini kolme käytöstä poistettua, muutaman vuoden ikäistä Dellin bisnesläppäriä, joista kaksi siirtyi jo eteenpäinkin. Kaksi niistä oli mallia E4310 ja viimeisenä trokattu E6410. Kaikissa oli edelleen ihan ajanmukainen i5-prosessori – oikeastaan vain pienet kiintarit, kuolleet akut ja nykymittapuulla vaatimattomat näytöt kertoivat koneiden iästä. Yhteen meni lopulta Windows 7 ja kahteen tietysti tuttu Mint/Mate.

Takavuosina Linux+kannettava oli huono yhdistelmä monestakin syystä: eksoottisille näytönohjaimille ja wlan-piireille ei ollut tukea, virransäästöominaisuudet olivat puutteellisia ja sleeppi toimi, jos toimi. Noista ajoista on kuitenkin tultu ilmeisen kauas, sillä Mint meni heittämällä ineen kaikkiin koneisiin niin 32- kuin 64-bittisenäkin versiona. E6410 kaatuili uhkaavasti asennuksessa, mutta syypääksi paljastuivat hankkimani uudet 1,5 V muistit (blääh!). Olisi pitänyt olla 1,35 V kampoja, mutta onneksi väärät kelpasivat edes Chromebookiin, joka puolestaan luovutti kaksi gigaa takaisinpäin.

En uskaltanut odottaa ihan liikoja, mutta hyvinhän se meni. Kaikki toimii suorilta: näyttis, wlan, hiiripädi, optinen asema, äänet, sleep, erikoisnäppäimet, usb, kamera, mikrofoni ja kortinlukija. Akun varaustaso ja lataustilanne näkyvät automaattisesti alapalkissa, tuuletin pyörii sopivasti ja kernel skaalaa prosessorin kellotaajuutta tarpeen mukaan. VGA:n tai DisplayPortin (vain E6410:ssä) kautta kytketty näyttö tunnistui automaattisesti jne. Yhteen masiinaan laitettu SSD, Kingston HyperX, ei temppuillut sen enempää, vaikkakin pelkän SATA2-ohjaimen takia nopeus saattoi jäädä maksimista. Toimivuutta kohentavat epäilemättä koneiden ikä ja yleisyys. Kokeilematta jäivät toistaiseksi Bluetooth sekä telakkakäyttö – jälkimmäinen ei mene välttämättä aivan näin kivuttomasti.

Vertailun vuoksi toiseen E4310:een asentamani Windows 7 Pro vaati melkoisen määrän taistelua. Geneerinen asennuslevy ei tukenut suoraan juuri mitään laitetta, vaan Dellin sivulta piti latailla parisenkymmentä pakettia hieman summamutikassa. Samanlaisia riemunkiljahduksia aiheuttivat n. 300 käyttöjärjestelmäpäivitystä, joiden äärellä vierähti tuntikausia: etenkin iän kaiken asentuvat .NET-päivitykset jäivät hyvin mieleen. Tässä kohtaa teki mieli kysyä, että kumman näistä käyttiksistä pitikään oleman se “helppo” asennettava. Savotan jäljiltä W7 toimii lopulta ilmeisen ok, vaikka kiintolevyn jatkuva hinkaaminen hieman ihmetyttääkin (onneksi ei ole enää minun ongelmani).

Softapuolesta ei ole juuri erityistä sanottavaa; Mint on Mint. Muutaman vuoden ikäinen i5 jaksaa hyvin toistaa full hd:tä VLC:llä, myös ulkoisella näytöllä. Selaimet, Gimp, LibreOffice, HandBrake, Processing, Audacity, X-Chat, VICE, DOSBox ym. perusohjelmat pyörivät asianmukaisesti, eikä neljän gigan muistikaan tunnu liian vähältä tällaisessa käytössä. Näyttöjen melko vaatimaton tarkkuus (1366×768 ja 1280×800) ja pieni kontrasti asettavat käytölle toki omat puitteensa.

Lopputulema tästä säätöprojektista oli siis varsin positiivinen. Amazonilta löytyi vielä uusia akkujakin, vaikka sadan euron hinta nostaakin projektin kokonaishintaa jo tuntuvasti, samoin kuin SSD. Itselleni jäi lopulta E6410, vaikka E4310:t ovat monessa suhteessa näppärämpiä – etenkin, jos konetta on tarkoitus oikeasti kanniskella mukana. Myös näppäimistön asettelu on hieman parempi E4310:ssä, mutta isompi malli voittaa ainakin liitäntöjen määrässä.

E6410 ja 64-bittinen Mint/Mate

E6410 ja 64-bittinen Mint/Mate

Edit: No eihän ainakaan tässä E6410:ssä edes ole Bluetoothia, joten toimivuutta on sikäli vaikea arvioida.

Edit2: Telakkaa pikaisesti testattu. Voi lykästä koneeseen ihan lennossa ilman mitään komplikaatioita. USB-portit toimivat hyvin ja näyttökin tunnistui display portista oitis. Näytöt ja alapalkit eivät aina sijoitu ihan loogisesti, mutta kyllä ne toimimaan saa pienellä näpläämisellä. Maten alapalkkia voi raahata näytöltä toiselle alt pohjassa.

Add comment August 29th, 2015

Skrolli 1/2015

Skrollin tämän vuoden ensimmäinen numero ilmestyi juuri, ja mukana on taas omaakin tekstiäni: Maisemia Perlin-kohinalla. Kuten nimikin vihjaa, artikkelissa tehdään Processingilla pieni reaaliaikainen 3D-maasto käyttäen Perlin-kohinaa muodon laskentaan. Teron piirtämä takakannen PETSCII-kuva on sekin tutulla edikalla tehty.

grabbi spock

Add comment March 18th, 2015

Arduino, Atari ja joikkari

Virittelin jo aiemmin kasaan Joyduino-projektin, jolla sai emuloitua Atari-joystickiä PC:n näppäimistöltä. Projektissa oli kuitenkin kaksi ongelmaa: kolvaamista vaativa tarpeettoman mutkikas piirikortti ja hieman epämääräinen sarjaportin käsittely omalla ohjelmalla. Kuulin vasta myöhemmin, että Arduinon pinnit saa suljettua laittamalla ne input-moodiin, mikä teki kytkinpiirit tarpeettomiksi. Eli kun virtuaalisen joikkarin kytkintä ei paineta, pinni on sisääntulona ja kun painetaan, niin pinni vaihdetaan ulostuloksi ja laitetaan nollaan. Tältä pohjalta riitti tehdä triviaali johto D9-naarasliittimestä piikkirimaan, joka menee Arduinon headerin pinneihin 8..GND (ylös, nappi, alas, vasen, nappi 2, oikea, maa). Tulitusnappi 2 tässä MSX:n mukainen – muissa laitteissa saattaa olla eri piikissä. Oman C-ohjelman sijasta tein isäntäohjelman tällä kertaa Processingilla, niin se toimii saman tien useilla alustoilla. Arduinoon pitää ensin ladata Firmata, jotta Processing toimii sen kanssa. Firmata ei ole järin nopea, sillä aikaa haaskaantuu yksittäisten pinnien erikseen kääntelyyn ja protokollaan, mutta tässä tapauksessa nopeus oli ihan hyväksyttävä. Omaa, luultavasti pahempaa lägiään tulee Processingin päivitystaajuudesta, mutta sekään ei ollut vielä liikaa. Esimerkki täällä:

Firmatan lisäksi tarvii asentaa Arduino-tuki Processingille, joten mikään avaimet käteen -ratkaisu tästäkään ei tullut. MSX:n kakkosnapin vahingossa sohimisesta voi seurata ongelmia joillakin koneilla – pinniä saatetaan käyttää muihin tarkoituksiin, joten joikkaportin pinniin 7 ei yleensä kannata kytkeä mitään. Toinen detsku on, että pelikone kannattaa käynnistää tai johto kytkeä vasta ohjelman herättyä, sillä muuten porttiin tulee ei-toivottuja painalluksia. Näppikseltä pelaaminen on jo kohtuullisen hyödyllistä, jos ehjää Atari-joystickiä ei satu olemaan, mutta vielä hyödyllisempi tämä viritelmä olisi vaikkapa joypadin kanssa. Katsotaan, iskeekö inspiraatio sellaisenkin tukemiseen jossain vaiheessa.

edit: Nappi 2 ja vasen menevät tosiaan ristiin piuhassa, koska huomasin vasta jälkikäteen, että MSX:ssä kakkosnappi onkin eri pinnissä. Helppo muuttaa koodista (ja muutenkin järjestys on aika satunnainen).

edit2: Äh, menköön. Tässä se joypad-tuki. Nappien ja kontrollerin nimeä joutunee vaihtamaan, mutta muuten toiminee suorilta:

Add comment December 9th, 2013

Previous Posts

Kommenttien virta