Printing on a Color StyleWriter

Posted by pulkomandy on Fri Jul 14 21:02:32 2017  •  Comments (0)  • 

Je suis l'heureux propriétaire d'une imprimante Apple Color StyleWriter 2400. Je l'ai récupérée il y a fort longtemps avec un lot de Macintosh qui partaient à la poubelle.

Cette imprimante date de 1994, elle a été vendue par Apple mais le matériel est conçu par Canon. On peut donc utiliser des cartouces de cette marque.

Et donc, après une dizaine d'année à traîner dans un coin de mon bazar, il était temps de remettre cette imprimante en service!

Étape 1: la brancher

Une particularité des imprimantes Apple de cette époque est d'utiliser un port série. En effet, les Macintosh n'avaient pas de port parallèle comme les PC. En plus de ça, pour gagner de la place sur la face arrière de ses machines, Apple a très vite laissé tombé le connecteur DE-9 pour utiliser à la place une mini-DIN. Rien de grave: on trouve le cablage par exemple ici. J'ai coupé un cable série Apple en 2 et j'y ai soudé un connecteur DE-9, et c'est parti!

Étape 2: les pilotes

Normalement, cette imprimante est sensée fonctionner avec un Macintosh de 1994. Évidement il n'y a pas de pilotes pour les systèmes plus récents. Mais, on a de la chance, quelqu'un a fait une grande partie du travail avec lpstyl. C'est pas vraiment un driver, plutôt un exécutable qui sait juste prendre une image dans un format bien précis, et l'imprimer. C'est prévu pour s'intégrer dans une chaîne d'impression UNIX, entre d'autres programmes qui vont convertir le fichier à imprimer en image, et le port série de l'ordinateur.

J'ai donc récupéré les sources et fait quelques ajustements pour que ça marche avec Haiku, mon système d'exploitation préféré. Et surtout, j'ai du ajouter quelques délais, car le code d'origine est trop rapide sur mon PC et n'arrive pas bien à se synchroniser avec l'imprimante. Bref, après quelques ajustements, l'imprimante prend une feuille de papier, le chariot se met en mouvement et… à la fin, j'ai une page blanche.

Étape 3: l'encre

Ben oui forcément, après 10 ans à dormir, la cartouche d'encre est toute sèche. Hereusement sur ce modèle, on peut remplacer le réservoir d'encre mais aussi la tête d'impression (qui est elle aussi pleine d'encre sèche et donc bonne à jeter). Par contre, Canon ne fabrique plus ces têtes d'impression (on trouve facilement les cartouches avec seulement le réservoir d'encre). J'ai fini par trouver un ensemble tête d'impression + cartouches noir et couleur pour pas trop cher chez un vendeur anglais. J'avais un peu peur que l'encre soit sèche après probablement 10 ans passés sur une étagère. Mais non, les cartouches sont vendues dans un emballage scellé sous pression, et avec un petit feuillet plastique de protection.

Du coup, j'ai juste eu besoin d'installer la nouvelle cartouche et j'ai enfin pu imprimer une page de test.

Étape 4: intégration avec Haiku

Bon, c'est bien joli d'imprimer une image de test, mais je peux toujours pas cliquer sur fichier/imprimer dans mes programmes et obtenir une sortie sur papier directement. Il va falloir intégrer ça proprement.

Ce sera l'occasion pour moi d'apprendre à écrire un driver d'imprimante pour Haiku, et probablement de débugger quelques petites choses dans le support de l'impression en général. De ce que j'ai vu, ça marche pas encore super bien.

Conclusion

Cette imprimante est plutôt solide et efficace, et elle fonctionnera sans doute encore de nombreuses années (tant que j'arrive à trouver des cartouches d'encre, en tout cas). Et autre bonne nouvelle, contrairement à la version Canon, il n'y a pas de compteur de pages qui met l'imprimante HS après un certain nombre de pages imprimées (soi-disant parce qu'il y a un réservoir d'encre usée qu'on ne peut pas vider dedans...).

J'ai donc économisé l'achat d'une imprimante neuve et qui aurait probablement duré moins longtemps.

Quick notes on building gcc

Posted by pulkomandy on Sat Apr 1 13:44:05 2017  •  Comments (0)  • 

This may not be up to date anymore. A complete GCC for AVR (and AMR) is now available as HaikuPorts recipes, which provide a more complete process, with a C library and everything. Refer to these recipes if you need to do it (even on other platforms, the recipes aren't all that hard to read and adjust)

As you may have noticed, I like to develop stuff for all kind of weird devices. For this, I usually need a C compiler, and most of the time it's gcc (not always).

gcc is a big piece of software and there are some tricks needed to build it. Also, I run the Haiku operating system, which is quite nonstandard, so additional workaround are needed.

Today I built gcc for avr. Here are notes on how to do it so I don't spent a month figuring it out next time.

#!/bin/sh
# gcc compilation for gcc 4.4.5 (4.5.x needs more stuff. maybe later)
# Made by PulkoMandy in 2010
# Before you start :
# * Download gmp and mpfr from HaikuPorts (http://ports.haiku-files.org/wiki/Downloads) and extract to /boot
# * Download gcc-core-4.4.5.tar.bz2 from gcc mirror and extract to work directory
mkdir obj && cd obj # This is the output folder. So you can keep the source area clean
setgcc gcc4 # We can't compile gcc4 with gcc2.
../gcc-4.4.5/configure --target=avr --enable-languages=c --prefix=/boot/common/ --with-mpfr=/boot/common/
	# Tell the target, then language we want, and where to install the result. Binaries will be called avr-* so don't care about overwriting other ones.
	# For some obscure reason mpfr isn't detected properly, so we force the prefix.
make all-gcc ; make install-gcc # This does compile only gcc, not libgcc; which failed to work for me.

There are other things to watch out : I had to remove a -lm somewhere as Haiku doesn't have a separate libmath.

Next : build a PlayStation development toolchain, including gcc MIPS target.

Projects I'm NOT coding

Posted by pulkomandy on Sat Apr 1 13:41:22 2017  •  Comments (0)  • 

SometimesI have ideas about software that could be interesting to write or useful to use; but I'm already contributing to a lot of projetcts and I'd rather not start all of the new ones.

Following a talk on #haiku irc channel, I decided to put the list online so other people can pick these projects up and start working on them.

Please let me know if you made (part of) one of them. So I can link to you here :)

PulkoMandy's ever growing TODO-list

Older items first.

  • Port the znax flash game to the Atari Lynx console.
  • Create a device that plug on the amiga clockport and can serve as a base for complicated projects. A DSP to decode OGG would be nice.
  • Build a mouse adapter, similar to AmiPS/2, but using the AMXmouse protocol for the CPC.
  • Compile the SDL version of Road Fighter for the GP2X
  • Port Rick Dangerous2, Prince of Persia 1 and 2, The Lost Vikings 1 and 2, and Jazz JackRabbit 2 to SDL or another lib and make them run on the GP2X.
  • Maplegochi : an electronic Maple tree for the Haiku desktop. You feed it with some water and you watch it grow day after day. The tree is built with random fractals so everyone gets an unique tree on its desktop. It changes over the seasons (depending on the system date and the locale). It is a replicant living on the desktop and acts as a living background,without being too disturbing.
  • Make the various usb to serial chips work on haiku with a simple terminal program.
  • Code a ROMDOS D1 filesystem add-on for Haiku to read/write floppies for Amstrad/Schneider CPC computers.
  • Network-shared whiteboard application for Haiku, allowing people to draw diagrams and see each other drawings. Likely use Playground as a base.

MesagEase Keyboard

Posted by pulkomandy on Sat Apr 1 13:28:43 2017  •  Comments (0)  • 

I recently gave up on using my old "phonebooth" dumb-phones and switched to… a 10 year old Galaxy S. What an upgrade!

I of course updated it to CyanogenMod, which runs quite well on this device and allows me to get a reasonably "recent" Android version (4.4, which is old, but still compatible with most apps).

Anyway, the main problem with that phone was the keyboard. I was never very good at typing with the numeric keyboard on old phones, but for some time I have been using a Nokia phone with a physical keyboard, which was quite nice. While the tocuhscreen-keyboard on Android makes place for a much larger display, which is a very good thing, it has awfully small keys and no feedback. It also tries to auto-correct me in a way that is sometimes useful, sometimes not correcting obvious mistakes, but also sometimes trying to correct where it really shouldn't or when I'm already trying to correct myself.

As you may know, the QWERTY layout was designed as a workaround for mechanical limitations of early typewriters. There is no reason at all to continue to use it today on physical keyboards, and even less on smartphone virtual ones. Surely, there had to be something better!

After some research, I found the MessagEase keyboard. It is, as expected, an input replacement for Android. The keyboard has just 9 keys, but each of them has 9 chars depending on the gesture you make. It is easy to learn (even if at first you have to do a bit of hunt and peck), and allows quite fast typing. It also has some interesting features, for example the keyboard can be made partially transparent, so you can still see a little of what's under it (not all applications put something under it, but some do). It is also very configurable (you can move characters around on the keyboard and change many other settings).

After a few days of training, I can type at a reasonable speed, and much less typos than with the normal keyboard. So this is something I would recommend to everyone using their phone display as a keyboard. Forget about QWERTY before it is too much hardwired into your muscle memory there!

Now, I need to compare this with Graffiti, which is now available on Android. I remember using that in the Palm days, but I didn't do a lot of writing with it, so I don't remember how fast it could go. Also, using it without a stylus will probably be quite different. But, I should give it a try and see what happens.

Bitbox laptop

Posted by pulkomandy on Tue Nov 24 22:20:55 2015  •  Comments (0)  • 

This article is about the bitbox. If you don't know about it yet, click the link and read about it.

I got my bitbox last year, and it quickly became quite annoying that each time I wanted to use it, I had to unplug the LCD from my PC, locate my gamepad, an USB cable to power it, remember which of the USB ports the gamepad must be plugged to, etc. I also always feared that while carrying the bitbox in my backpack, I would bend a pin on one of the connectors or something.

Well, I solved these issues. I could have gone with a 3D printed case and whatnot, but I went with the simpler solution: make a laptop-like case using some easily hackable devices!

the bitbox laptop!

You can easily build one yourself. You need the following parts (dx.com links included):

Assembply instructions:

  • Remove the backpanel from the TV so it is thin enough to fit the tablet support in the keyboard.
  • Cut some holes in the keyboard cover to make space for the bog capacitors on the TV PCB (easily done, the keyboard cover is only thick cardboard)
  • Locate the 5V regulator on the TV PCB and solder a wire there to power the bitbox
  • Plug the keyboard and TV to the bitbox (you need the VGA gender changer here), and glue the bitbox next to the display (they both fit)
  • Enjoy!

There is some room for improvement. The setup currently doesn't include a battery (I wanted to use an USB "power bank", but the LCD display needs 12V), and the VGA connector is needlessly bulky, especially with the gender changer. I could solder the wires directly to the bitbox and ignore the connector, but I like to be able to remove the bitbox from this. Maybe I should add an HE10 or some other connector for the display output.

So, what is it useful for? Well, you can run all the bitbox games and apps (as long as they can be used with a keyboard). The ZX works fine, but I would prefer a more friendly on-line development interface (Amstrad CPC emulation was suggested, but I think a better idea is a native BASIC/Lua/Forth/Squirrel/whatever). One can also run the chiptracker there, but that needs audio output, which the LCD I used unfortunately doesn't include.

Maybe someone can suggest a reasonably flat and small loudspeaker to fit into this? And what about the battery? There are some 12V batteries on dx but they will need some charge control. Or should I use my USB thing with a boost converter?

Gravis Interface Protocol

Posted by pulkomandy on Sun Nov 23 21:39:25 2014  •  Comments (0)  • 

This article has been revised to include fixed and up to date information after I actually plugged the gamepad to an oscilloscope. Now it should be error-free.

Ever heard of the Gravis Gamepad Pro ? It's a gamepad using the old-fashioned PC gameport. It looks quite like the original Playstation controller and has a very solid build quality.

Those of you who know about the gameport limitations will quickly notice that there must be something non-standard about it: there are 10 buttons, while the gameport only allows 4. Even better, you can actually use 2 gamepads at the same time on a single port.

There are several modes accessible with a switch under the gamepad. These are 1-player, 2-player, and GrIP. In 1 player mode, you get 2 axis and 4 buttons. In 2 player mode, you get 2 axis and 2 buttons, and you can use 2 gamepads. In GrIP mode, each gamepad can use all 10 buttons, but this is not compatible with the games expecting a standard joystick.

I have some of these gamepads around, but my PC don't have a gameport anymore. Since I'm not very happy with replacement hardware (I tried the Logitech Precision USB gamepad, but it doesn't look as nice and colourful), and the USB version of the Gravis Gamepad is impossible to find (and less beautiful with the black plastic, I'm thinking about building an adapter for these gamepads to plug them on an USB port. Of course, without opening and rewiring them. Not only this would void the long expired warranty, but I may still want to plug these gamepads to the system they were intended for (my 1995 Pentium 166 MMX).

There is some information on the internet about the protocol, but it's not easy to find. Heer is what I could get : a textfile with some info and the Linux driver for these joysticks. Since the textfile does not say everything the driver does, here are some notes that duplicate the text file and add the info from the driver.

I checked this with an oscilloscope, so I believe the information to be correct. But I may have missed something.

First, the gameport pinout. It's a SUB-E 15 connector. The following pins are relevant:

  • 1,8,9,15: 5V power (my gamepad accepted down to 3V, below that it stops generating the clock signal)
  • 4,5,12: GND
  • 2,7,10,14: buttons 0,1,2,3
(the other pins are axis 0, 1, 2, 3, they are not used in GrIP mode).

When you use only one gamepad, buttons 0 and 1 are used as data lines. Button 0 is a 20 to 25kHz clock. On each falling edge of this, you can read the state of button 1. Frames are 24 bits long and is formatted as follows:

011111
0SelectStartR2Blue
0L2GreenYellowRed
0L1R1DownUp
0RightLeft
The frame starts with a start bit, then 5 bits set high. Since the button data is split in 4-bit words with a 0 interleaved, there can't possibly be 5 set bits anywhere else, this makes it possible to detect the start of a frame.

Transmitting a full frame at 20KHz will take about 1.2ms (slightly more than 1.5ms on my test gamepad). This is more than fast enough. It's likely that Gravis drivers on windows only polled the gameport only 20 or 25 times per second (or even less), and waited up to 2ms for a frame start. This was the only way for them, because these gameport buttons are not triggering interrupts.

When there are 2 joysticks connected, the second one uses buttons 2 and 3 exactly the same way. The Gamepad Pro has a pass through connector that swaps buttons 2 and 3 with 0 and 1 for the second device, like any Y-doubler joystick cable does.

I'm planning to use an STM32f3 microcontroller to decode this. The protocol is close to SPI, unfortunately microcontrollers able to handle 24-bit SPI frames are not common. Moreover, the start of frame is hard to detect so synchronization could be a problem. Bit banging the protocol is a better solution, we just have to use the clock line as an external interrupt and read the bits in the interrupt handler.

Développement rapide sur STM32

Posted by pulkomandy on Mon Nov 10 22:53:18 2014  •  Comments (0)  • 

Il y a quelques années de ça (déjà), j'ai fait partie du club robotique de l'ENSSAT. On utilisait pour nos robots des dsPIC30f4011. Afin de travailler rapidement, on utilisait un bootloader permettant de programmer le PIC via un port série, évitant ainsi d'avoir à brancher un PICkit à la moindre modification de code (vu que de toutes façons le lien UART était nécessaire pour tester le code sur le robot). On pouvait même utiliser un adaptateur bluetooth pour faire de l'UART sans fil, pratique pour tester un robot qui se déplace.

Le problème bien connu des bootloaders, c'est que c'est lent. Le lien série a une vitesse limitée et envoyer tout le code pour un PIC peut prendre un certain temps. ça se compte en secondes, mais quand on met au point un bout de code ou qu'on essaie de calibrer un asservissement, ça peut vite devenir très chiant. Notre bootloader était donc capable d'optimiser les transferts en ne reprogrammant que la partie modifiée de la flash. Pour cela le logiciel sur PC est résident, et se souvient du fichier chargé précédement. Ainsi il peut le comparer avec le nouveau et extraire les différences.

Le dit logiciel est d'ailleurs un logiciel libre, il s'agit de RBL. Il inclut également un terminal série pour communiquer avec la carte.

Aujourd'hui, je n'utilise plus de dsPIC30f4011. Par contre, je joue en ce moment avec un STM32f3 et j'utilise toujours un bootloader série. Et le confort de RBL me manque pour plein de petites raisons. J'ai donc essayé de retrouver un confort similaire mais en utilisant une solution plus générique, puisqu'elle repose sur Haiku plutôt que sur Qt ;).

Mon premier problème est de pouvoir partager le lien série entre le bootloader et le terminal. Dans RBL, tout est dans la même application donc il n'y a pas de problème. Le clic sur le bouton "programmer" débranche le terminal, lance le code du bootloader, puis rebranche le terminal.

J'avais commencé à adapter RBL pour l'utiliser avec un NXP LPC1746. Mais avant d'avoir pu finir, j'ai commencé à jouer avec plein d'autres microcontrôleurs, et pour la plupart il existe déjà des outils pour les programmer. Réécrire tous ces outils pour les intégrer à RBL est assez pénible et chronophage.

J'ai donc abordé le problème de façon différente. SerialConnect, le terminal série de Haiku, accepte des commandes de scripting. Cela signifie qu'on peut lui demander, de façon assez simple, de libérer et de reprendre le contrôle du port série (bon j'avoue, j'ai ajouté moi même le support du scripting dans SerialConnect). Concrètement ça donne ceci:

hey SerialConnect delete port
stm32flash ...
hey SerialConnect set port to usb0

Et voilà, on vient de demander à SerialConnect de libérer le port série, ensuite on a lancé stm32flash pour programmer le microcontrôleur, et enfin on prévient SerialConnect que c'est terminé et qu'il peut réouvrir son port.

Il reste un petit problème: stm32flash ne permet pas de redémarrer le CPU pour entrer en mode bootloader. Il faut donc penser à mettre un jumper sur la pin BOOT0 (pour démarrer dans le bootloader et pas la flash), et à appuyer sur le bouton reset. Beaucoup trop fatiguant. La solution est la même qu'on utilise dans RBL, un protocole convenu avec l'application qui permet de la redémarrer et de sauter directement dans le bootloader.

Le protocole est simple: dès que l'application reçoit le caractère 'U', elle se termine. Mon fichier de startup est prévu pour récupérer le contrôle et appeler le bootloader dans ce cas. Il ne reste plus qu'à demander à SerialConnect d'envoyer ce caractère avant de se déconnecter, et le tour est joué. Un simple "make flash" permet de recharger l'application sans avoir à toucher directement à SerialConnect.

Il manque encore l'optimisation de la reprogrammation, qui risque de nécessiter des modifications dans stm32flash. Mais on verra ça dans un autre article, quand mon firmware sera devenu assez gros pour que la différence soit visible.

J'allais oublier, le projet template pour STM32 est sur Github.

Récupérer un Atmel AVR avec FuseBit Doctor

Posted by pulkomandy on Sun Nov 9 23:03:36 2014  •  Comments (0)  • 

Cet été j'ai testé pour la première fois la programmation d'un microcontrôleur AVR8 sous Haiku avec un portage tout frais de la libusb. Malhereusement il restait encore quelques bugs, et je me suis retrouvé avec un AVR avec tous ses fusebits à 0. Impossible de le reprogrammer avec un programmeur ISP classique, soit que le port SPI soit désactivé, soit que l'AVR aie besoin d'une horloge externe que ma carte de développement ne fournit pas.

Fort hereusement une solution existe, il s'agit du Fuse Bit Doctor (attention, page en polonais). Il s'agit d'un montage assez simple à base d'ATMega8 (ou 88 ou 168). Il utilise le mode "high voltage" pour reprogrammer les puces en panne. L'utilisation est très simple: on met l'AVR à réparer dans le socket, on branche l'alimentation 12 volts, et on appuie sur le bouton. En moins d'une seconde la LED verte s'allume et l'AVR8 est restauré dans sa configuration d'usine et fonctionne de nouveau.

Le montage est également assez simple: à part un AVR8 "doctor" contenant le firmware, il comporte 2 boutons, 2 LEDs, 2 transistors, un régulateur, 3 condensateurs et deux douzaines de résistances. Je n'avais pas envie de commander un circuit imprimé ou de tenter d'en graver un, j'ai donc réalisé le montage sur une protoboard 7x9 centimètres. ça rentre juste et il y a la place pour les sockets 28, 40 et 20 pins pour les différents modèles d'AVR qui peuvent être réparés.

C'est donc un montage simple et bien pratique que tout le monde devrait avoir dans un coin en cas de problème. Hereusement que j'ai eu la bonne idée de garder mon dernier ATMega8 encore programmable pour ce montage. Maintenant je peux programmer les fusibles de mes AVR sans avoir peur de tout casser.

Radeon 7000 on Windows 7

Posted by pulkomandy on Mon Aug 18 22:02:04 2014  •  Comments (0)  • 

As you know, Windows XP is EOL now. However, I'm still using that machine I assembled in 2003 as my only Windows computer, and I don't plan to change that. So I went ahead ans upgraded it to Win7.

Everything works fine, except the video card. Windows will complain that it needs a DirectX9 card. I know such a thing can be found even for my old AGP motherboard, but that's more money than I want to spend.

AMD won't provide drivers for such an old card for the new windows (Vista and 7). You can force-install the XP driver, and it will mostly work, but the system will BSOD on shutdown. Not so nice.

The solution is simple, once you have found it. The drivers for Windows Server 2008 will work perfectly. In the case of my Radeon 7000, these can be downloaded from Dell's FTP.

Note that the installer won't work, but using the inf files provided with the driver will go fine. And I now have my PC running as it should again.

I should look into Windows Server drivers for more of my hardware. It looks much less bloatware-enabled than the mainstream versions and gets the job done.

Reviving a Turbo-XT

Posted by pulkomandy on Tue Aug 5 16:33:51 2014  •  Comments (0)  • 

How I got an XT motherboard

This week I got an old PC/XT clone motherboard back in working order.

I had this board on my parts bin for some years. My cousin had found a PC/XT on the sidewalk, probably some company threw it away when the power supply failed. Unfortunately, it came with no keyboard, monitor, or even floppy drive.

Inside the original box (a big desktop-style one) was the huge and heavy power supply, the motherboard, an Hercules compatible card, a floppy controller, an MFM hard disk and its controller card.

I had already tried replacing the power supply with a standard AT one (the connectors are similar enough) and I could hear the PC speaker beep, so I knew the POST test was passing, however, without the monitor and keyboard, I couldn't do much more. The hard drive would not spin up. I only kept the motherboard and the 3 expansion cards, and got rid of the hard drive, case and power supply.

The computer comes with an Hercules compatible video card. This is a monochrome display, but more importantly it uses the same refresh rates as MDA: 50Hz vertical and 18.6kHz horizontal. This does not match the 15.6kHz used by TVs and CGA, nor the 31.5kHz used by VGA. Attempts to use ISA VGA cards on this motherboard weren't very succesful. So I let the boards sleep for a few years in my parts bin.

Seeing it boot

Last month, the "8088 domination" demo was released. This got me thinking about this motherboard again and I decided to see if I could do something useful with it. I installed it in a baby-AT tower case which takes less space than the original and started researching a solution for using the MDA card. I first thought of connecting it to my CTM640, which is normally a 15kHz monitor, but can be adjusted a bit using a potentiometer. I had to build a sync mixer to merge the horizontal and vertical sync signals (I simply XORed them together using 74LSxx chips). I could get some garbage on screen but the sync didn't work, so it was just unreadable text. However I knoew the MDA card was worknig properly, as I could see some generated video and check the sync lines with an oscilloscope.

I started looking for scanrate converters, but it seems so far there is no cheap solution that officially supports MDA. It's possible to find some VGA to composite or VGA to HDMI converters, and I think some of these may be compatible. However, while researching those, I noticed they work pretty much like the input section of most modern LCD displays. This gave me the idea to test my LCD (which is actually a TV with SCART, VGA and HDMI outputs) to see which frequency range it would accept.

I booted Haiku and used the screenmode command to set a custom video mode using a modeline. I couldn't find the exact timings for the MDA/Hercules cards online, however they are fairly easy to compute from the CRTC settings, which I found on John Elliot's page about Hercules cards (you just multiply the character-based settings by the character horizontal or vertical size). It turns out this LCD will handle a 18kHz HSync just fine.

The next step was wiring an MDA to VGA connector adapter. The wiring is straightforward, I connected the "monochrome" output from the video card to the green channel, and the "intensity" to the red one. The VGA port should need a 0.7v signal, but it turns out my LCD accepts the 5V TTL just fine (it's a Linetech LF1912HD01, but that brand or model probably disappeared from stores already). So I could finally see the bootscreen!

User input needed

Ok, without a keyboard, being able to boot DOS isn't so useful. And as you should know, the PC and PC/XT use a different keyboard protocol from later models, so using a standard PS/2 keyboard directly is not possible.

This is a long-solved problem, with the guis at the Vintage Computer Forum having an adapter built around a small PIC12 chip. But I don't like PICs and prefer AVRs. There is an AVR version of the adapter, but the code is big and clumsy, where a small and simple one would do the job just as well.

So I designed my own keyboard adapter. The code is C and should be fairly readable. It uses the same PS/2 library I used earlier for my PCW and Amiga keyboard adapters. The lib had some problems and this was a good occasion to review it, clean it up, and do some more testing. On the XT side, things are rather simple as I just need to send the single byte keycodes with a standard clock signal. This is implemented on the XT side using a 74LS shift register, which is quite flexible on the timings.

So, I now have the adapter (named XTK) working, on two different boards I had lying around. One uses an ATMega8 or ATMega48, the other uses an ATTiny2313. You can find the code at the avrstuff repository. However, for the final version of this I plan to use an ATTiny13 and fit the whole adapter circuit inside the DIN connector. I want to get my prototyping boarsd back, and a small integrated circuit like this will be much less fragile.

While I was at it, I also replaced a burnt LED in my Olivetti keyboard. It has a nice yellow caps lock LED again. But I didn't update the PS/2 library so it controls the keyboard LEDs yet. That will come later.

Mass storage

Ok, I fitted a 5"1/4 floppy drive in the machine so I could boot DOS and test the keyboard at a prompt. This is working quite well, but swapping floppies gets annoying and I'd rather keep my other floppy drives for other projects. This PC originally came with an MFM or RLL hard disk, which was broken when I got my hands on it. Replacements are hard to find, and they are heavy and noisy. Instead, I plan to use a compact flash card. I could buy the amazing XT-CF or XT-IDE boards, but even if they are quite cheap, it's more money than I want to waste on this computer. So let's see if I can continue doing things with just my parts bin.

First, I need a way to connect the "XTIDE universal ROM" so I can access my CF card using the usual DOS interrupts. My motherboard has 6 ROMs slots on it like the original 5150 PC. Only one is used for the BIOS, the next 4 are for the IBM BASIC, and the last one is for an expansion ROM. I used this one for the XTIDE ROM. On this motherboard the ROMs have a standard pinout, so I could easily put the XTIDE universal ROM on a 27C256 chip (copied 4 times to make sure the system can see it). After some hacking on my EPROM programmer, I got it to reliably program this in the ROM. So that's one problem solved.

I also need to connect the compact flash card. It turns out I can use the IDE port on a sound card, and XTIDE can set the CF card to 8-bit mode to avoid the use of the 16-bit bus, which is of course not wired on my machine. This is the same trick I use on my CF adapter for CPC. (you need XTIDE version 2 to use this feature).

However, I need a non-PNP card with an IDE port for this to work. The BIOS doesn't know how to initialize PNP cards, and if I wanted to do it using the manufacturer provided drivers (assuming they can run on a 8088), I'd have to boot DOS first. Time to dig out that Sound Blaster 16 which is the only non-PNP card I have around. Mine comes with an IDE port which I set to address 1F0.

With the sound card and the CF adapter plugged, the XTIDE installation tool detected everything just fine and I could prepare the ROM file suitable for my machine. I saved this back to disc (my UVPROM can't be programmed on the fly on the motherboard like the flash chip on XTIDE would), got that file back to my other DOS PC where I could finally put it on the ROM. I seated that ROM in the XT and could see the XTIDE welcome message. Some FDISK later I could boot DOS from that compact flash, it works quite well and DOS boots in less than a second (but there aren't much drivers to load).

The software!

Well, now that the thing is running... what to do with it? I ran through my 5"1/4 floppies and found that a lot of the software there is meant to use with either CGA, Tandy PCJr, or some later video card. But there are some games for the Hercules card as well. Of course none of those use the Sound Blaster (even in AdLib mode), they all go for the PC speaker. I had more success with the tools such as QBasic and Turbo Pascal, but I'll probably cross compile things I want to run on the machine.

An obvious thing to do on a 8088 based machine is to run "8088 Corruption". I thought this required a CGA card, but MDA support is now available. However, and as pointed out by Trixter, I found that the Sound Blaster 16 wouldn't work on a 8088 based box because it needs some tools in the autoexec to initialize it. However, I found a workaround to this once again on the Vintage Computer forums. A simple DEBUG script can be used to initialize the card.

o 224 80
o 225 02
o 224 81
o 225 02
q

I added this to my autoexec.bat, and it worked! I can now use the card (as a Sound Blaster 2.0, the 16-bit DMA obviously won't work). The mixer volume is quite low, so I may have to extend this debug script or try to run one of the mixer tools if I can find one that runs on the 8088. Or I could get a Nec V20 which would run all this software fine.

Getting it on the network!

I tried using a 3Com Etherlink III as an extra extension ROM slot. That didn't work, but I stopped messing with it when I noticed that the motherboard already had a slot for XTIDE. Maybe I can add some ethernet connectivity to this machine with this card. However, 3COM tools to configure it don't seem to detect it. I may need an alternative driver that supports the 8088, just like for the sound card.

Rome2Rio

Posted by pulkomandy on Wed Jul 30 10:43:02 2014  •  Comments (0)  • 

Today I discovered Rome2Rio, which is a multi-modal travel search engine. I've been looking for such a tool for some time. Instead of searching only flights, it provides train and bus routes, and allows to mix and match all of these (and even ridesharing) to find the best way to go where you want. It also features door-to-door pricing, which means not just the cost of the flight, but also any shuttle you may need to use from the airport to city center.

They have their own dataset and don't do API queries to other operators. There is a risk of out of date data, but on the other hand, this makes the search super-fast. The trip is visualized on a map and you can easily see what's the best solution.

I can finally plan mixed train/bus/plane trips easily!

Rainloop webmail

Posted by pulkomandy on Thu Jan 30 16:14:57 2014  •  Comments (0)  • 

Pendant des années j'ai utilisé Roundcube comme webmail. Mais je n'en ai jamais été vraiement satisfait..

Et aujourd'hui, j'ai installé Rainloop sur mon serveur. C'est propre, c'est beau, c'est facile à installer, ça marche tout seul, et on a même pas besoin d'avoir les mails sur le même serveur car tout passe par de l'IMAP et du SMTP. Adopté!

Website mirroring

Posted by pulkomandy on Mon Nov 25 10:53:36 2013  •  Comments (0)  • 

Personnal message to whoever uses IP 212.37.186.188: your mirroring of the website using WebReaper was using 100% CPU because most pages are dynamically generated. I have more useful things to do with my server, so WebReaper is now banned. If you want a mirror of the website, I can send you an archive.

You probably won't use everything I have online here, anyway, and you are wasting my internt bandwith. I host this server at home and use the internet connection for you know, web surfing and stuff.

Downtime

Posted by pulkomandy on Tue Sep 24 16:08:56 2013  •  Comments (0)  • 

The downtime is over, all services should now be running again. Ping me if something is broken.

Address change

Posted by pulkomandy on Tue May 10 22:42:41 2011  •  Comments (0)  • 

Following some problems with my router and DynDNS settings, the site is now available at http://pulkomandy.lexinfo.fr . Please update your bookmarks.

Hello World

Posted by pulkomandy on Fri Jun 26 17:42:56 2009  •  Comments (4)  • 

This is the new server of the PulkoTeam! Enjoy your stay here.

Everything is still work in progress, so please be patient.

Warning: this site looks simple, but it uses css3 features and some other things that require a modern browser. It was tested with Opera 10, Firefox 3, Internet Explorer 8 and Chrome 3. Anything older may not work. Don't complain, upgrade your browser or disable css.