PulkoMandy's homepage

I have a shelf of old CDs, both audio and games. Some are very common stuff and not so interesting. Others are quite a bit more obscure, for a variety of reasons:

• Audio CDs I bought at shows or from websites, that are not currently re-edited
• Various shareware compilations and tie-in discs
• Even for big well-known games, sometimes the French edition is not well archived even if the English one is

Anyway, it was one small worry in my life that if these discs would be damaged, lost, or stolen, I don't really have a backup plan. Actually, while archiving, I found some cases where the disc is missing (nothing impossible to replace, fortunately).

The other part of this problem is I had no remote backup. I used to do a "backup exchange" system with a few friends, where we would send our homeservers backups to each other. But people move on, servers go offline, and this is not available anymore. Related to that (and less so to the CDs archiving), I'd like to do more with my homeserver, but as long as there is no backup plan, and the server is a machine in my living room, the risk of data loss is just too high. So, I finally registered an account on iDrive so I can upload the stuff there. The server is now backed up, and I'm dumping the software and music there as well.

Due to copyright laws, this is a private archive for my own use. However, I will publicly list what I have. If it turns out some of this is not readily available, contact me and we'll figure out something.

I tried to do things "right", dumping ISO images where appropriate, all sound tracks as flac (both for the games and music CDs), as well as the extra content for Audio CDs. I also scanned the booklets and the disks themselves.

PC GAMES

• 123 Free Solitaire 2003
• 8 jeux de casse-tête (Pointsoft collection of Tetris-like and other braintwister games)
• 3D Ultra Pinball - Le continent perdu
• 3D Maze
• Alien Detector Pro
• Astrobeer
• Blobby Volley
• Blueprint menu editor (for editing The Sims objects)
• Bousille écran
• Boston Bomb Club (edited by Pointsoft)
• CD Force 1 - Octobre 1999
• CD Fun 1 and 2 - Février 2000
• Car Tycoon (French version, I remember this being unplayable due to too many bugs)
• Command And Conquer (with "Opérations Survie" extra disk)
• Crop Circles
• Dune II
• Dungeon Keeper Gold (multilingual)
• EcoQuest
• EcoQuest 2
• Freelog Hors Série 11 - Démos et Merveilles
• Inca II Wiracocha
• Get Medieval (Microïds CD with Shogun, Rage of Mages, and Corsairs
• Grim Fandango
• Gruntz
• GT Racing 97
• Heroes of Might and Magic III (GOG.com edition)
• Hi-Octane
• Hugo
• Indiana Jones and the Fate of Atlantis
• Lego Creator
• Lemmings for Window 95
• Lemmings 2
• Lemmings 3
• Lemmings 3D
• Lemmings Revolution (a different print than the one available at WebArchive)
• Les fourmis - Les Guerres de l'Ouest
• Les Mondes Engloutis 2.0 (scenario for Age of Mythology)
• Little Big Adventure
• Lord of the Rings II
• Lost in Time
• Lost in Time 2
• Ludorace
• Mais où se cache Carmen San Diego edition Junior (Pointsoft and TLC edusoft)
• MaxiMax Septembre 1999
• Micro Machines v3
• Monthy Python Sacré Grall
• New World 3 - Trip to Australia demo
• Oddworld l'Exode d'Abe
• Pandora's Box
• Pandemonium
• Pandemonium 2
• PC Mag hors série 21 (Shareware compilation)
• Plane Crazy (PC Jeux 26 - Nov 99 - CD1)
• Pointsoft Jeux pour Windows (several games edited by Pointsoft: Jungle colors, Snowmanland, Lost In Time, Wizards). The games are clones of well known things (Puzzle Bobble, Dr Mario, ...), but they have decent pixel graphics and great music by then demoscene musician Traven
• Powerslide
• Prince of Persia 2
• RAMA
• Rayman Forever
• Red Baron (PC Fun Hors Série)
• Q*Bert (version from 1999. My CD looks different from the ones already dumped at the web archive, I guess the French version got a different artwork?)
• Rising Lands (Microïds)
• RollerCoaster Tycoon
• RollerCoaster Tyconn: Loopings en Folie scenario disc
• Sim Tower (Maxis)
• Sim City 2000 édition spéciale Media Pocket (a low-cost re-release, including the DOS, WIN16 and WIN32 versions with SCURK and other extras. The CD includes PDF user manuals in french)
• Sim City 3000 OEM edition
• Sim Life
• Sim Town
• Street Wars (Constructor 2) (Acclaim)
• Les Super Maths (PC Junior CD #16) - A MAcromedia made game where You play X-Men characters in 4 minigames involving mathematical operations, graphs, triangles, and so on.
• The Dig
• The Incredible Machine 2
• The Sims Transmogrifier 1.4
• A random asortment of custom objects to add to The Sims
• Theme Hospital
• Theme Park
• Traffic Giant (GOG.com edition)
• Tux Racer 1.1
• Tomb Raider II
• Warcraft II Battle.net edition (in English)
• Warcraft II Beyond The Dark Portal
• Wild Tangent Front 9 minigolf
• Worms 2

Music

• Alternine: both the original EP and the 2.0 from the rebooted band
• André Minvielle et Lionel Suarez - Tandem
• Antoine Reneaut - En Plénitude
• Les aventures de Bibounet et Patacloum (companion CD to a DVD that I don't have)
• Chorale Iroise - Couleurs Celtiques
• Daft Punk - Ton Legacy soundtrack
• Datarock - Datarock Datarock (EU version with extra tracks), also including the videoclips from the CD
• Datarock - RED
• Dr Wong - Heavy Metal Banania Unplugged, Tipiak, and covers of Zelda and Tetris
• Eiffel 65 and Bloom 06 - All albums, nothing very exciting here I think
• Eurovision Song Contest 2009 (CD1 only)
• Fabulous Trobadors - Ma ville est le plus beau park
• Flash (some Atari XL music)
• Flavien Berger - Léviathan and Contre-Temps
• François Hadji-Lazaro - Un recueil frais et disco (including DVD with videoclips)
• Les Frères Brothers - First 2 albums
• Guilhem Desq - Visions
• Harajuku - Just One Look (incomplete)
• La Tordue - All 6 albums
• La Patate - L'alboom (if you know French you may remember their flash animation "La chanson de la patate" but you probably didn't there is a full album)
• Les Escrocs - All 3 albums
• Les Wriggles - Justice avec des saucisses
• Malaussene - 2 albums and bonus tracks. They had these for free on their website
• Mélusine - Chansons à écouter au coin du feu (a tie-in music CD sold with a comic book. Not bad music at all from people whose main job is comic book scenario and drawing!)
• Mickey 3D - All 3 albums from a boxed set
• Paula Powered - Level Up
• Poison - The last legend
• Pomplamoose - Invisible People
• Hurricane on the Bayou (soundtrack from the movie/documentary of the same name
• Tribute to Arno (Putain, putain, une tribu pour Arno)

Playstation games

• SLES-00278-2107629 - Bust A Move - Arcade 2 Edition
• SLES-00838 - Oddworld - L'odyssée d'Abe
• SLES-01502 - Oddworld - L'exode d'Abe
• SLES-01893 - Bomberman
• SLES-04166 - FIFA Football 2005

Software and drivers

• 3D Prophet Kyro II driver CD
• Akai LPD8 CD (Mac and Windows software and user manual)
• Altera Complete Design Suite 7.2 for Windows and UNIX/Linux, with Cyclone II starter kit CD
• ASUS Windows 7 Anytime Upgrade
• BeOS "developer edition" distribution (versions 1.1 and 2.2)
• Borland Delphi pour Windows (Presqu'Offert hors série juillet 1998)
• CD from my high school music teacher with multimedia presentations about the music we had to study for exams
• ClarisWorks 3.0 (Presqu'Offert 9)
• DirectX 9.0 redistributable
• DIV Games Studio
• E-Icons 4.15
• Genius Genitab III driver for Windows 98 and NT4, version 1.2
• Global American Inc drivers - for a VIA embedded PC motherboard, a GPS received and a PCI serial card
• GP2X F100 userguide (English and Korean)
• HP PSC1310 / OfficeJet4200 / OfficeJet 5500 printer drivers (Windows 98-XP, possibly also Mac)
• Iomega Zip driver
• Klik and Play (French, Mac)
• La Bible PC - Programmation système - 5ème édition (sold with the book of the same name, including all examples from the book, and also a Micro Application software and book catalog with weird background music, and a low resolution version of the "Don't copy that floppy" rap clip that takes more space than everything else on the CD)
• Liquid Desktop screensaver
• Matrox Millenium G450 driver CD
• Micrografx picture publisher 6.0 (also including ABC Media Manager, older 16bit versions of Picture Publisher, and demos of other Micrografx software)
• MP3 player driver (don't remember for which cheap MP3, either an S1mp3 compatible one or some later ipod Nano like thing)
• Mustek ScanExpress 1200 SP (includes TextBridge and IPhoto Plus for Windows and Color It! for Macintosh)
• NetBurner support CD (this is a Motorola Coldfire development board with an Ethernet port)
• OfficeOne 7 - An office suite built from existing components (OpenOffice, Paint.net, Avast, ...) also including some games. Sold with an Asus computer back in 2008 or so
• Partition Logic 0.66
• PC100 Video Inside motherboard drivers
• Shino Disquette v3.7
• SNes9x 1.39a FR
• Sound Blaster Live
• ToUCam fun Philips webcam drivers, PCVC 730K version 1.01
• Ultimate Boot CD 5.1.1
• USB to IDE driver CD (I don't remember what piece of hardware it goes with, includes drivers for various chips)
• USB to serial adapter driver (a Prolific based adapter)
• USB 2.0 Digital HDTV Tuner
• Various Palm software
• Visual C++ Express 2005
• Windows XP (first release)
• Windows XP Pro SP3
• Windows 7 Pro 64bit with Service Pack 1, French (ok you probably don't need this one...)

DVD and movies

• Blanche Neige et les sept nains (Zylo / Goodtimes platinum series)
• Heidi (Zylo / Goodtimes platinum series)
• Le Bossu de Notre Dame (Zylo / Goodtimes platinum series)
• Pocahontas

Wanted / Missing

Some things I couldn't archive in time... Some of this is probably easy to find, and just notes to myself to get it. Other things are more complicated.

• The Daft punk soundtrack is supposed to have some bonus on the disk. Unfortunateely, what's actually on the disk is an EXE file that will just send you to a now offline website. The web archive only has a backup of the landing page, because the actual content was behind a login wall. There were apparently 3 trailers for the movie, the videoclip for Derezzed, and a picture gallery. Did anyone doznload the pictures from the gallery or other stuff from that website?
• Complete "Just One Look" album by Harajuku
• My copy of Tomb Raider ("version longue"/extended edition) has only CD2. CD1 has been accidentally replaced by a CD of Tomb Raider II. Anyone has the matching Tomb Raider II case with CD1 of Tomb Raider 1 in it?
• Bénabar - Infréquentable, I have the case but the CD is not in it
• Petite Oreille by Boucherie Prod - A compilation CD released in 1996 with children songs by artists who don't usually do children songs. My CD is lost and this is long out of print, I'll have to locate a copy at acceptable price.
• Megarace 2 - CD2 (French version), mine is too damaged to rip properly
• Command and Conquer Soleil de Tibérium - GDI disc

I have a flat screen TV I bought in 2009. I use it for various retro computer things, mainly when I'm travelling and don't want to carry a CRT around. It is also useful because the VGA port will accept any timing, down to the 18KHz refresh rate of MDA/Hercules at least. It also has a few other cool things my CRTs will not do, like Teletext support.

There is just one problem with it, however: there is no way in the menus to force the SCART connector into RGB mode. This can be done only by sending the proper voltage (1 to 3 volts) to the SCART connector itself. Normally this isn't a problem: proper RGB SCART things will send that voltage, and everything will be fine. But I also want to use this port for other stuff, where I make an adapter myself for some other type of RGB output. Often there isn't a voltage source available on the power connector then. As a result, the TV switches to composite mode and shows a grey screen (since it uses the sync signal as a video signal, and so there is nothing to show).

Previously I did this as an external mod: getting 5V from the USB port of the TV, and feeding back into the SCART. But this requires making SCART connectors with a 5V input, the cable can break when transporting the TV... well, it's annoying. So I decided to make it internally instead.

I get the 5V from the Common Interface slot, this is a PCMCIA slot where you could plug a satellite TV receiver or crypted TV decoder or the like. Since this has a standard pinout, the 5V was easy to locate, and also they made it with very large soldering pads so adding a wire there was very easy.

Since the TV expects 1 to 3V on the RGB switching line, I use a 220 ohm resistor. The TV has a 75 ohm impedance, so this creates a voltage divider in the right range. Any resistor from 50 to 300 ohms would do.

Finally, I mounted the switch by screwing it into the Common Interface slot. The slot is just wide enough to put the switch through, and will provide enough mechanical support once the switch is secured there.

When the switch is ON, this will force the TV to use RGB input on the SCART port. When it's off, the TV will work as normal since the mod is disconnected. A quite simple change in the end, but very useful for me.

Just a little thing today...

Here is a version of Haiku's

screenmode

command line utility modified and recompiled to run on BeOS.

I made this because BeOS screen preferences didn't allow me to set custom resolutions easily. Now I can set up any timings I want, and so I can get my BeOS system running on my 1080p display in native resolution.

Download screenmode for BeOS (17KB, zip)

I made this as part of my work on porting ACE to Haiku. ACE originates from MorphOS, and so it uses "catalog" files for internationalization in the format used there. The format is based on the IFF container typical on Amiga originated software.

Since the Haiku version of ACE uses pretty much exactly the same strings as the MorphOS version, it would be silly to have to re-translate all the strings. So I made this add-on to Haiku locale kit to handle catalogs in the MorphOS format.

At the moment this is not useful to any other software than ACE. However, maybe someone will find it useful. The format is a bit different than what is done in Haiku. In the Haiku locale kit, the original (usually English) string is used as a key for translations. This requires hashing the whole string, which makes everything a bit slower. It isn't very noticeable on modern machines, but it is definitely part of what makes Haiku slower than BeOS. On the other hand, the format used on MorphOS assigns an integer to each string, which can be used to refer to it efficiently. It still provides fallback strings inside the executable, so if there is no catalog, things will still work.

Maybe we could use this format more on Haiku and get better performance. But it would require a lot of changes to the tooling built around the existing format. Maybe a project for later...

You can get the iffcatalog sourcecode:

• IFF catalog 0.5 source archive
• Browse git repository online

If you want to simply use it, the binaries are available in Haiku package manager.

Version history:

• 0.1 - 04/2015 - First public release
• 0.2 - 11/2017 - Skip '\0' in translated strings (used for keyboard shortcuts on MorphOS)
• 0.3 - 06/2020 - Fix catalog search directory
• 0.4 - 02/2022 - Add a python script to generate locale_strings.h from catalog definitions
• 0.5 - 10/2023 - Remove dependency on libtextencoding, which is not safely usable in a Haiku add-on unless the host app links with it as well. Fix a bug in the locale_strings.h generator with handling of escape sequences.

Lately I have taken part in some fediverse discussions about the "small web". As you probably know, many websites these days are bloated. They will load several megabytes of resources. I remember surfing the web as a kid, I would download some games and shareware, and I would be annoyed when one of them would be larger than 1MB, as that would take a while to download. Now, a lot of webpage (just the webpage, not the downloaded software!) are already 10 times larger than that.

Yet, they do not seem to offer much more than they did 25 years ago. A web page mainly shows text with some pictures where relevantm or just to make it look nice. So, what happened? Well, I don't really know. If anything, my website is getting simpler and smaller over the years. Early versions had MIDI music and a Java applet emulating the Start Wars opening scroll on the landing page.

Anyway, so, the "small web". It seems this idea started gaining traction in the last few years. It comes from multiple directions: retrocomputing is trendy, and, well, it always was, but now, there are decidedly retro machines that had their commercial life during the early days of the worldwide web. So there is demand from retrocomputer users who want to browse the web like in 1996 or so. Another nostalgic aspect is the "what if?" exploration of Gopher, an early competitor to the web that largely lost to it. And there is also the concerns caused, I guess, indirectly by climate change, of building a more sustainable tech that's less power hungry. Surely, simpler websites and web browsers could be part of that, as well as being genuinely useful to people who have a limited internet access for various reasons (living in very remote areas, not willing or being able to pay for a super fast connection, or being in a place where the infrastructure just isn't there for many possible reasons).

One thing that is somewhat succesful in that domain is the Gemini protocol. This is inspired by Gopher but made more modern and a little less quirky, for example, it requires SSL where Gopher was mainly plaintext. Unlike HTML, it gives very limited control on the text formatting to people writing webpages. As a result, it is quite easy to write a Gemini browser, even one working in a command-line, and indeed there are quite a few of them. I had only a brief look at it, and decided it doesn't work for me for various reasons (this is my personal reaction to it, not a complaint or so, I'm sure other people are happy with these choices and that's good for them). The SSL requirement makes it unreachable for the 8-bit retrocomputers I care about. The limited formatting is often not enough for what I want to do with the web, and likewise, I find the lack of cookies, URL parameters and the like a bit of an extreme measure. I understand the idea of enforcing privacy, but I am not convinced it is worth the limitations that result.

But, my main problem with it is: it is new technology. There is a new protocol, a new page formatting language, new specifications, and new software to write. I get it, a lot of people will find these new things exciting, it's fun to write software and specs from scratch, without having to care about legacy quirks and past mistakes. This is not how I usually think about things. As I learnt in school, a good software developer is a lazy software developer. So, my approach is often trying to make most use of what's already available. In this case, this means the existing web browsers. That's a good idea because we already have a lot of software, a lot of people who know how to write webpages, and a good understanding of the problems and limitations. And there are also users (people browsing the web) who won't need to be convinced to install yet another piece of software on their computers. Can we achieve that? I don't know, but I find that idea a lot more interesting to explore than the "what if we erased everything we have and started over?" approach of Gemini.

So, I took a look at the existing specifications for the web. My goal here is to see how to make websites that are "light" (a webpage should be a dozen to a hundred kilobytes or so), fast to load, and yet allow websites to have some visual personality. The latter can't really be done in Gemini and I think it's an important part of the web: allowing everyone to have their own space, and really make it reflect who they are. There will be the wall of text just using the default formatting. The cute page with colorful text and animated GIFs. The red-text-on-black-background crazy conspiracy theory website. And so on.

From the technical side, let's try to limit ourselves to the technologies already widely supported by web browsers. Or, to word it differently: I don't think the bloat of the web is a technical problem to be solved by throwing more tech at it. Instead, it's just a matter of making better and more efficient use of what we already have. The core set of technologies is in fact quite reasonable. On the protocol side, we have a choice of at least HTTP 1.0 and 1.1, possibly HTTP 2, possibly some other more experimental protocols. I'm not sure HTTP 2 complexity is really useful for such small websites, 1.1 will probably be good enough.

More interesting is the content format. Here, we can review the different available options. The oldest one is HTML 3, which does not have CSS and mixes up content and presentation. This is not great by today's standards and does not really make things simpler. The newest one is HTML 5, which is in a kind of "rolling release" mode and keeps changing all the time. Personally I find this to be a problem, I would prefer a fixed set of features.

So, that leaves us with HTML 4. Which turns out to be really interesting, because it is from a time where mobile phones were starting to go online, and so, there was a simultaneous demand for richer webpages on desktop machines, and really simple ones for then limited mobile phones and other similar devices. Also, it is from a time where the web attempted to move to XML with XHTML 4. This seems to still be controversial: XHTML is a much stricter syntax, while HTML 4 retains the more flexible way of working of HTML3 and later HTML versions. Basically, whatever you write in a text document, a web browser can parse it as HTML. It is very tolerant on unclosed tags, weird nesting of things (putting a paragraph inside a table inside a list item), and so on. XHTML, on the other hand, is allowed to reject a page as invalid XML. Well, it doesn't really matter anyway, existing browsers already accept both, so we can use both depending on the context. If you are writing a static website generator, you can probably make it generate valid XHTML. If you are manually editing webpages or allowing your users to do so, maybe HTML will provide a less frustrating experience? I'm not sure about that, in my early days of writing HTML and Javascript I think I would have preferred to have clear error messages instead of a browser that always did something, but rarely exactly what I wanted.

Anyway, with both XHTML and HTML4, one interesting aspect that the w3c worked on is modularity. You can pick a profile like XHTML Basic, which gives a set of recommendations for which tags should be used or not. The selected set seems reasonable for my use of the web, it does not seem very constraining to me. Likewise for CSS, you can easily decide to limit yourself to "level 1" or "level 2" features. Or at least, you can make sure your website "degrades" to an acceptable rendering on browsers that support only these, while making use of more advanced features on browsers that can handle it.

Finally, we have to talk about javascript. Javascript is not a great language. We know why that is: it was designed in a very short time with requirements along the line of "Java is trendy, but objecto riented programming is too complicated, can you make us a version of Java without objects? We need it in two weeks". As you expect, the result is not great, and the language did get objects later on anyways. Well, unfortunately, we don't really have a choice. So, my approach to this is to limit Javascript usage to the minimum possible, and make sure my websites work well on browsers that don't parse Javascript. But I still find it useful, for example for client-side pre-validation of forms. It is useful to have immediate feedback on required fields in a form, and not discover problems only after you have submitted it. That kind of thing.

Also, Javascript allows to set up things like "AJAX" (OK, no one calls it this way anymore), basically, you can have dynamic webpages where just one part of the page is reloaded or generated by Javascript code from a loaded network resource. Sure, this makes the browser quite a bit more complex, and the webpage will need some processing. But it doesn't necessarily have to turn into megabytes of bloat. In fact, if used well, this can be very efficient in terms of bandwidth, since the whole webpage does not need to be reloaded. So, I don't like the idea of banning Javascript. Just make its use minimal, and, where it makes sense, have a fallback for browsers without Javascript.

Finally, one thing that is a bit unused in the current web is RSS feeds. Or, more broadly, the idea to expose website data in a format that's easy to parse and process by applications. I thnk this is a path that deserves to be explored more. Not only RSS, but also more generally exposing any type of data in a well structured XML, and maybe using XSLT to process it into other formats. This is well supported in most web browsers, and certainly could get more use. I like the idea of websites exposing data as XML that can also be easily downloaded and processed elsewhere (by some other website, or by a "native" app on the user's computer). This is kind of a tangent to the small web, but maybe there's an opportunity to build something new and exciting here.

So, what will I do, then? Well, not much. This website should be XTML-1.0 basic compatible and uses no Javascript, because it doesn't need any more than that. It does use some modern CSS features, but even with CSS disabled, you can read the text in the articles and use the website in an acceptable way. I hope this inspires other people to do the same. Maybe if more and more websites are built like this, the bloat of the big modern web3 ones will stand out more, and people will notice and complain about it?

So, this week I thought about Thomson EFCIS graphic controllers again. I know that Thomson made at least two families of controllers, the EF934x, which runs the Minitel, and the EF936x, which is designed for pixel graphics, but I did not know as much about this one. It seems a bit more of a "high end" thing, but at the same time, it is loosely similar to the display system used in Thomson TO and MO microcomputers.

I also knew that Thomson EFCIS sold the color palette circuit originally developped for the TO9 as a general color palette chip (the TO9 has it described as a custom chip in its technical manual, but then it became an off the shelf chip).

Anyway, I became curious about the other chips and why and how they were designed. And then I read a lot of datasheets and research papers and patents. Here is what I found.

Note: this is based on some random web searches, I wasn't there at the time (in fact I wasn't born at the time) and I could be misunderstanding or misremembering what I read. Don't trust me too much...

What are we talking about, anyways?

EFCIS is a French semiconductor company. It was created by a public research lab which turned part of its activity into, apparenly, an integrated circuit design and manufacturing company. At the time, France was a bit behind the USA in terms of semiconductors manufacturing. The government helped solve this by injecting money into the sector, but also there would be various merge of companies to join forces, and partnerships with US companies to first resell their chips, and then manufacture them locally.

In the case of EFCIS, it would merge with several other companies to become Thomson Semiconducteurs, which in turn merged with Italian SGS to become SGS-Thomson, later shortened to ST Microelectronics. That company is still around today.

But our story does not start there. Instead, we have to dig into what was happening in the mid-70s in the Laboratoire d'Informatique de l'École Normale Supérieure (LIENS). That's another French reserach lab that, at the time, worked on computer systems and architecture. This is the 70s, so we're talking about probably only one computer, and various terminals to serve it. The terminals would either be text-only, or graphic ones such as the Tektronix 4010 series.

These terminals are somewhat complex and costly hardware. The 4010 is a strange device by today's standard, it does not use RAM to store display data, instead, the cathode ray tube itself keeps the pixels "on". This makes the system cheaper, but has the major downside that you can only erase the whole screen, not just subsets of it, and erasing takes a second or so. As a result, this is not giving a great user experience for interactive graphics.

So, the people at LIENS have an idea: what if we could use a TV and some RAM to make a cheaper terminal? It would allow interactivity, and also maybe color.

Their first try was a text terminal. This was reasonable to do, with 1Kx8bit of RAM and a character ROM, it is possible to display a 64x16 character grid on a TV. This allowed to have a first go at generating the display timings, clock, and pixel shifting.

There was already prior art in doing this, for example, Dan Lancaster's TV Typewriter from 1973 is based on very similar concepts (at only half the resolution, 32x16 characters). That TV typewriter allowed home computers to get some kind of cheap terminal system, and the video output in early home computers like the Apple I and the SOL-20 were based on this design.

Anyway, with the goal of making the cost lower, one solution is to reduce the number of chips by using an LSI (large scale integration) chip. This would result in the SFF96364, with a patent application in early 1977 (FR 77.0524, also known as FR2382049B1, and its equivalent US patent US4328557A, attributed to Jean Gastinel), I think just a little time before similar chips like the MC6845 were announced (but it's hard to find exact dates).

Of course, there would be no point in manufacturing an LSI chip just for use in the research lab, and so, the SESCOSEM, the chip manufacturer, also introduces it for sale to the general public. I have not introduced the SESCOSEM yet, but I don't have much info on it, it seems it merges with EFCIS just a few months after releasing this chip, and the chip is then rebranded as EF9364.

It's also worth mentionning that SESCOSEM was also a second source for Motorola products. Well, or at least that's how they advertised it, it looks like initially, the chips were manufactured by Motorola but rebadged with SESCOSEM part numbers. This means you could get both the 6845 and the 96364 from the same company.

However, the two chips, while similar in the way they drive the CRT, are different on the way they are interfaced on the other side. The 6845 is designed for use with a microprocessor (initially a 6800, but people figured out how to make it work with other CPU families as well). On the other hand, the 96364 is designed instead to interface directly with an UART chip. This means the chip is less flexible and has a fixed resolution of 64x16 characters, whereas the 6845 can be configured into many videomodes, but on the other hand, and unlike the 6845, it will manage memory writes and cursor movement, with some special commands allowing to move the cursor around. This makes it possible to build a serial terminal ("glass teletype") from a TV set, this chip, an UART, a character generator and 1Kx7 of RAM, with a bit of glue logic.

So, we now have this chip that makes it easy and reasonable for DIY computer builders to assemble a text terminal for their computers. This is taken up by several electronics magazines and kit distributors, one of the well-known ones being the Elektor Elekterminal. Suddenly it is possible to build a terminal that will not require hundreds of TTL chips, or include a microcontroller, and cost more than the computer it is attached to.

Into graphics controllers

But for the LIENS, this was just a first test of the concept. Their plan is not to do just text, they are working on designing hardware, and they want to use CAD applications. They want to replace the Tektronix 4010 with a TV set and a relatively cheap adapter board.

As the SFF96394 is finally made available to the general public in mid-78, with terminals and VDU cards starting to appear as kits or prebuilt at the end of that year, the design for the next system is published, as four patents and a paper in SIGGRAPH 78 from Philippe Matherat. Now my research was made quite a bit easier because he links to all of this from his personal website :).

So, this next design retains the basic idea of designing a chip for use in a Terminal. However, at this time, and for a more complex graphics terminal, it becomes acceptable to include a microcontroller, or maybe even a microprocessor and turn the terminal into a kind of simple workstation. This design aims to once again reuse a standard TV receiver as the display, but support Tektronix's PLOT10 API or even Tektronix serial line protocol. This way, the existing applications will run on the new, cheap terminal as a starting point, and then the terminal can be extended with color display, faster refresh times, etc.

At the time, the main constraint is not so much on the memory size. 16K DRAMs are now available at an acceptable price for this application. The main problem is rather the memory speed. It is not possible to output single bits from a single DRAM chip fast enough to match the needed pixel clock (the project aims for a 512x512 interlaced display window). The soluion to this is to put several DRAM chips in parallel (as you do when building a computer to address them in bytes), and then use a shift register to send the bits to the display circuit. Essentially, this removes the character ROM from the previous text based system, instead feeding the RAM output directly into the already existing shift register.

This way, the shift register is the only thing that needs to be really fast, the RAM will only need to fetch one 8-bit word at a time.

The second problem is fast vector drawing. Microprocessors at the time could not be programmed to do this fast enough to keep up with even the Tektronix terminals. Part of the reason for this is that the RAM is completely busy with sending pixels to the display in this design, probably to keep it simpler. Other machines at the time (such as the Apple ][) are figuring out how to intermix accesses to the RAM for the display and CPU, but here a different direction is taken. The CPU will have only limited access (in fact, it's possible to have no access at all) and instead the hardware will provide high level drawing commands, with the goal of drawing one pixel per clock cycle (during borders and blanking, when the memory is not busy with either display or refresh cycles).

The commands start with vector operations. The display controller keeps track of X and Y pointers and implements Bresenham's algorithm in hardware for drawing straight lines. Additionally, it can also draw characters (from the ASCII) table, with optional scaling, rotation, and slanting.

The chip internally manages a 4096x4096 coordinate space, of which a part is not visible on screen. This allows line vectors to go out of screen and the drawing to continue correctly with the next vectors. The part that would be outside the screen are clipped cleanly and the drawing is not distorted.

Access to the memory is done in parallel (all 8 chips) when reading, but writes are done one bit at a time, by enabling the RAS pin for just one of the chips.

The SFF96364 could fit in a 28 pins DIP package, but the new EF9365 needs a 40 pins package, and even that is a bit too limiting, so a few extra chips are needed: a demultiplexer to select the RAM chips, a shift register, and also a PROM to derive some signals from the clock. The EF9366 is a simplified version that can only draw a 256x256 display, but requires a little less support logic. Both versions of the chip do include a lightpen controller as well.

Color graphics are possible by adding parallel banks of memory chips, typically one for each of red, green, and blue. Then, the CPU can program an external register to store a 3 bit color, that is loaded to the RAMs when a pixel needs to be plotted.

In one of his later articles, Philippe Matherat explains why this approach turned out not to be such a great idea: it was done with the goal of replacing the Tektronix displays, and it did a decent job at that. But, a few year laters, bitmap displays would become more common, and faster CPUs such as the 68000 would be available, which would do a faster job at drawing lines and text than this chip could do, and also allowed more advanced operations (scrolling, overlapping windows, etc).

There were attempts to workaround these limitations, for example by adding extra operators on the data path between the video controller and the RAM for write operations. That would allow some operations like XOR with a cursor, intersection with existing drawings, etc. However, adding more complex drawing primitives require a larger redesign of the chip, more on that later.

Initially the chip finds some use, both in DIY videocard projects (again with Elektor offering one) and in scientific hardware where it makes it possible to show realtime and color display of measurements (for example I read about its use to display spectrograms). While the initial design was ready by may of 1978 (as you can see in the patents and papers published then), the chip would be available to customers only in late 1979 or early 1980. At that time, computers and workstations with raster graphics are quickly catching up, which means the chip did not really get a chance to be used.

Meanwhile, in Brittany, ...

Meanwhile, other innovations are going on in France. There are experiments to replace the phonebook with an electronic device, basically a terminal that would be plugged into a phone line and allow to send and receive data. Experiments on this start at about the same time in 1978. Of course, the plan is to replace the phonebook, which means the terminals will have to be produced in a large quantity, and be cheap. This justifies the use of an LSI chip again.

This time, there is no room for complex graphics: in a desire to keep the costs low, there are big constraints on the amount of RAM and ROM in the terminal. And so, it's back to the simple character based system. But maybe not quite so simple as the EF9364. The people working on this first experiment with hardware and protocols based on ANTIOPE, the early Teletext system in France. They also want to make the terminal user friendly, and for this they need various character attributes, maybe colors (eventually it will be 8 greyscale levels), double size characters. Hardware vertical scrolling ("roll") also seems useful to render long pages of text at an acceptable speed.

These requirements will lead to a new design, initially as a set of two chips based on the earlier combination of a text mode controller with a character generator. Eventually, both of the chips become a lot more complex than what they were initially, and, as it seems usual for EFCIS, they are not reserved to the Minitel and added to the general catalog of available ICs. These are the EF9340 and EF9341, also known as VIN and GEN and introduced in 1980. They will also find an use in the Philips Videopac+ consoles where their video incrustation support will be used to mix the video signal with the existing one from the Intel 8244 in the older generation Videopac.

The Minitel hardare will be revised several times over the years, to introduce new features (such as a dialer and local phonebook, and a generic ASCII 80 column terminal mode). This leads to new generations of video controllers, the EF9345 (introduced 1983, also ends up being used in the Matra Alice computers as well as the Philips VG5000) and the TS9347 (introduced 1988, with EFCIS now renamed Thomson Semiconducteurs, this one gets a new manufacturer prefix).

These chip are quite far from the initial "dumb terminal" usage. They can redefine some custom characters in RAM, have a "compression" system where a short byte sequence can expand into a longer string that is stored in memory, etc. They also provide a rather large 8x10 font, fitting 40x25 characters in a 320x256 video output.

Ok, back to the pixel based ones

The EF936x family also gets an upgrade in the form of the EF9367. This chip allows doubling the horizontal resolution (to 1024x512 pixels), but it does so in a not so convenient way. It looks like this was first done as an extension to an EF9365 videocard, and then pushed back into the video chip. It also changes the video timing: the initial timing for the 9365/66 resulted in a square, 256x256 or 512x512 window at the center of the display. But, this results in a lot of wasted space to the left and right of that window. The new chip changes the timing, it now operates on a slower clock but keeps the same horizontal frequency for the display. As a result, in 256x256 or 512x512 interlaced modes, the pixels will be slightly wider than high, matching the 4:3 ratio of the display, and at 512x256 or 1024x512 interlaced modes, they will be slightly higher than wide, with a ratio around 2:3, still much better than the 1:2 you would get in the same conditions with the original chip.

Another new feature is the possibility of a 60Hz mode, reducing the video resolution. The datasheet and appnotes also add a few extra tricks to the circuitry, showing how to implement vertical scrolling (useful on the 60Hz version because it reduces the vertical resolution, and so, parts of the pixels stored in RAM are actually not visible).

Finally, one last iteration is the TS68483. This is a much extended design, made to interface with a 68000 CPU and its 16 bit databus (but 8 bit access is also still possible). It adds more complex drawing primitives for curves, arcs, and so on. It also uses a larger 64 pin DIP package, which allows to have more of the logic integrated in the chip, for example, external shift registers are not needed. It can also produce even higher video resolutions. But, at this point, the design with memory completely isolated from the CPU is not appropriate anymore. Graphics terminals are a thing of the past, and other computer systems have shown that it is possible to get quite fast drawing in software, or, if there is anything to accelerate, it's rather moving blocks of data around, with something like a blitter.

Anyway, the EF936x series remains an ahead of its time graphics accelerator. It would take a few more years to see 2D acceleration implemented in hardware, and 3D acceleration would follow.

But what if 8 colors is not enough?

In the EF936x documentation, it is suggested to use 3 bitplanes for an RGB image. This is similar to what was used in the Thomson TO7, but it felt quite limiting. Later models at Thomson Microcomputers added a 4th bit of color, either darkening or brightening the other colors. This was implemented by feeding the 4 color bits from the video generator into a lookup ROM, and then a resistor network. Of course, this can be added to an EF936x system.

But Thomson computers did not stop there. The next step, introduced first in the Thomson TO9, was to use a dedicated palette chip. This would have 16 color registers that would store a 12 bit color (4 bit each for R, G, and B) and replace the ROM used in the previous models. Then, the color palette becomes fully programmable. Typically, you can switch to 16 grey levels, or mix 8 basic colors and 8 greyscales.

Once again, EFCIS is the company manufacturing that chip, first as a custom chip for the TO9, but later on added to their general catalog as the EF9369.

There is also a later revision, the TS9370, which can handle higher pixel clocks, and removes the need for a separate video buffer/amplifier, further simplifying the design. I don't know if there ever was any graphics hardware combining the color palette chip with the graphics processors (or even the textmode one). These products were manufactured by the same company, but for different projects, and it's unclear if the fact that they would fit together quite well is intentional, or just an happy incident.

Long-winded and irrelevant introduction, like they do on cooking websites before you get to the recipe

I am the happy owner of a Fujitsu U7311 laptop. After several years of using used thinkpads, and not being happy with the new models designed by Lenovo, I had to switch to a new machine after my Thinkpad started developing some unexplained crashes, I suspect some kind of memory corruption.

I found that Fujitsu, not the most popular manufacturer, is actually still doing great machines. In fact, it was acquired by Lenovo a few years ago and it seems they took on the old Thinkpad spirit, or at least the parts that made it work for me.

Unfotunately, there is no equivalent of the thinkwiki for Fujitsu machines. This is pretty much the only downside. The customer support from Fujitsu is better than usual, with complete disassembly guides available from the support page (translated in several languages, and very well made with detailed pictures). There is also a support forum for specific questions (OK, maybe don't get TOO specific or you won't get an useful answer).

On the hardware side, I am happy with having basic IO (VGA (but the next generation U7312 removed that, oh well, I guess I could always use an adapter from HDMI or DVI?) and Ethernet ports) and I also got a docking station while I was at it (a proper one using a full docking connector under the machine, not one of these USB3 ones that I have no idea how they work). The magnesium chassis and case ensures I won't have bits of broken plastic everywhere after a few years. I also have a keyboard with a trackpoint (but you have to make a choice between that and a spill-resistant one, and I had to buy the keyboard separately and install it myself).

It is also interesting how the 13, 14 and 15 inch versions are largely identical, to the point that the BIOS image is the same for all 3. And the model numbering is also easy to follow, with one digit being the display size and the next two being the Intel CPU generation. So you easily know what you get, just from the model numbers.

Anyway, the BIOS update

The machine ships with an Insyde H2O BIOS, that is nothing unusual compared to other systems. I had two problems with the initial version shipped with the machine: boot was very slow (it took 10 seconds or so before even initializing the display), and it was not possible to switch between different displays after booting (the only way to use an external display for the BIOS was to boot with the lid closed, and then you can't use the keyboard).

The BIOS update is available from Fujitsu Support website and comes either as a "desk flash instant" or a "bios admin pack" version, but both of these contain Windows executables that won't run on my Haiku system. But it turns out that's not really a problem. The BIOS admin pack contains a file with a .bup file extension (I guess for "BIOS update package"). This can be extracted to the EFI system partition and it contains the executable that will perform the update.

So, extract the thing, copy it to the EFI partition and reboot to an EFI shell. From there, run the FJNB2E7.CAP file and let it run for a while (it takes a minute or so, be sure your battery is loaded and you are on mains power to avoid any chances of power loss during the update).

The first time I ran the executable, it did not flash anything, possibly because I had tried to run other things from the archive before (there's another executable but I'm not sure what it's for, and running it only resulted in an error message).

Anyway, run the thing, and when it's done, type "reset" to exit the EFI shell. That's it, your BIOS is updated! You can now remove the files from the EFI partition.

By the way, obviously do NOT try to install the BIOS from another machines or use tools from another manufacturer. This procedure worked for me but I take no responsibility if you break your machine, recovering from an erased BIOS is either very hard or impossible (I don't know which and I don't want to try).

Contiki is a small operating system originally developed by Adam Dunkels. Version 1.x became famous on the internets after he ported it to the Commodore 64. The system came with a small GUI and ran reasonably well. It is written in C and uses a few nice tricks to run efficiently on low memory systems.

Contiki became "big and professional", well, mostly profesionnal, and in version 2.x, the GUI was mostly removed and the fun 8 and 16 bit machine ports all abandoned. Now it is useful for actual projects, running on small sensor boards and the like.

The best place to find info about the old Contiki version is the Hitmen demogroup page. I was a bit annoyed about the Amstrad CPC port description there: "runs slowly, does not look nice, and could probably be improved. But still worth a look". Certainly the CPC deserves better. And so I started hacking. That was in 2014.

The CPC port was initially developped by Kevin Thacker, who got it running, and kind of stopped there. It was indeed very slow, but the main cause was the implementation of the "clear rectangle" function as a loop putting space characters all over the display. But I went on and changed quite a few things to get it to look better, be faster, and saved several kilobytes of RAM (partially thanks to improvements in SDCC, and partially through rewriting more of the UI code with small assembler parts, adding missing "const" in various places, etc).

I also simplified the build quite a bit, in particular I had to rework the generation of symbol definition files that are used to link the loadable PRG files to the Contiki kernel. On the CPC port, these files are generated from the SDCC generated mapping files, now using some SED scripts to convert them to the appropriate format. I also made several adjustments to use newer SDCC versions over the years.

Later on, I also ported Contiki to the Bitbox console as well as the VTech V.Smile. The V.Smile port is still unfinished and waiting for the development of a proper toolchain for its unusual CPU, more on that later in another article.

Anyway, this brings us to today where I finally decided to update the port to use the latest version of SDCC. The SDCC compiler changed their calling convention in version 4.2 and finally added a way to pass parameters to functions using CPU registers. Before that, they were pushing parameters to the stack, and making that more complicated by insisting on pusing only 1 byte, when there are no instructions on the z80 to do so (PUSH and POP always work on 16 bit register pairs).

This, of course, requires all functions written in assemby to be updated. But before I got to that, I had to fix a patch to SDCC. One specificity of Contiki is its ability to load programs at arbitrary addresses in RAM to execute them. On a modern machine, this would be handled either by using the MMU to provide a fixed memory layout to the program, or by compiling the code as "position independent". But none of these are available on the Z80 CPU (well, you could, with a lot of custom hardware, but not on an Amstrad CPC at least). So, Contiki has to "relocate" executable, that means, after loading them into RAM, patch every address referenced in the code to adjust it for where the program was loaded. Fortunately there is some support for this in SDCC and Kevin provided a patch to generate a relocation table that lists the places that need to be patched in the final binary of each program.

I have kept this patch up to date with the current version of SDCC over the years, and version 4.2 needed a new change. It internally represents addresses as 24 bit instead of 16, I guess to allow support for banking. This resulted in corruption in the generated .hex files, and a bit of confusion until I managed to convince SDCC buildsystem to generate binaries with debug info for the linker, so I could look at what it was doing. It took a bit more guessing due to Haiku debugger not showing the value for global variables yet, but eventually I figured it out.

The next step was fixing a segmentation fault in the compiler. Fortunately, I could locate an existing bugreport with a fix, and apply the changes to my version of SDCC to avoid the problem.

And finally I could get to the part where I have to adjust all the assembler code to the new convention. Several of the functions could be simplified or even removed completely (when the calling convention matches that of the CPC firmware, it's possible to call directly into the firmware).

Converting the functions was not too hard, despite me making some stupid mistakes (don't pop something into a register if you need the value that's already in that register...) and having to fix another place where a function corrupted the IX register while SDCC didn't expect that (since it's the frame pointer, it assumes all functions preserve it, including ones written manually in assembler).

In the end, Contiki is now running fine with SDCC 4.2! I then tried to turn the optimization level (max-allocs-per-node) way up to 20 million and let things compile for a very long time. But this failed, the compiler generates instructions that the assembler doesn't accept because they are undocumented opcodes (that exist in the z80 implementation, but were not mentionned in the official documentation and removed from later CPUs like the z180).

So for now I have turned that back down, and I will test again in SDCC 4.3 where support for undocumented opcodes will be official and toggleable with a command line switch.

In the end, this new version of SDCC allowed to raise the free space in RAM with Contiki running from 24 to 26K, which is not bad at all! And there would be ways to free even more, by moving the Contiki Kernel to a ROM or using the RAM banks of the CPC to not have the code and the framebuffer share the same 64K space.

... so a few days later I did just this. It took some bug hunting and some not so clean tricks to get the file generated the way I wanted, but Contiki is now a ROM. Which means the free space is now 37K out of a 41K "heap", when the desktop and the "memstat" apps are both running. This is possible because the ROM uses the same memory space as the framebuffer, and so, suddenly there is 16K more of address space to use.

I think I could also implement a proper GUI driver that is not restricted to simulating a GUI from textmode. It could be made to look quite a bit nicer with a smaller font, and not being restricted to 8x8 pixels character blocks with only 2 colors for everything, and also make it use an overscan display instead of just 320x200. That would require moving the apps to memory bank so most of the main memory can be used for the display. But I already planned that when I started working on Contiki 10 years ago, and I have not started it since. And I think it's time to move on to other projects.

I still had two bugs to fix: during startup, there were some things written to the framebuffer that shouln't be there, meaning the linker somehow put non-const data in the ROM. And, the icons on the desktop are not loading. These two were related, it tuns out I had added a "const" to the icons to workaround a problem with the generation of the DSC files (these are files with just the icon data, used to quickly show the icon directory in Contiki). And so they were in the ROM, but adding an icon to the desktop actually writes some things in the icon data structure... So I made my hack a bit more complicated and now it's working fine.

While investigating this, I also found that the borders for some windows did not stop drawing where they should, and continued all the way to the bottom of the screen. I'm not sure if it was a compiler bug or a mistake in the code, but I have rewritten the code in a slightly different way and it's working fine now.

So, it is time for a new release of Contiki after 5 years of doing nothing, and two weekends of hacking!

Download Contiki 1.4 for Amstrad CPC. You will need to flash the ROM to any ROM slot, and put the DSK in your disk drive. Then type |CONTIKI to start the OS. Enjoy!

Get the sourcecode using Git if you'd like to help with this project or have your own fun experiments with it. I don't know when I will look again into it!

I have also submitted the patches for Haiku support to the SDCC team, and we are discussing which of the changes are useful to merge on their side. Kevin's relocation patch has a known bug, that will need to be fixed before they accept it upstream. Unfortunately, fixing it requires some changes to the way the relocation info is encoded. I'll see what I can do about it.

I also found bugs in the ACE CPC emulator (setting the PC register from the Z80 editor window actually sets IX instead?). So that's another bug fixed in ACE and I should look into that as one of my next projects. I want to do a point release of it with a collection of bugfixes, and port and publish all the ACEpansions that are available for the MorphOS version now. Oh well, the TODO list never really goes down!

That's it. I'm off Twitter now.

I used it for 5 years. I now have archives of everything I posted there.

Now you can find me on Mastodon instead. See you there!

This project started by breaking old hardware. A few years ago, I started experimenting with designing hardware expansions for the Amstrad PCW. I had some success previously with the Amstrad CPC, surely this couldn't be so different? And it's a kind of interesting machine, with lots of RAM (for an 8bit system) and a quite nicely designes ASIC which would make programming it relatively nice.

My hardware experiments, however, did not go so well. First I got just a motherboard, and I hacked up a way to connect it to an Amstrad CTM and hooked a floppy drive. It worked, but only for a few minutes. Some time later, I did this again, but I checked the machine service manual more carefully and found the explanation: the video output is straight from the ASIC, and is not designed to handle the load of a typical CRT display. The PCW internal display has a buffer, but it is not on the motherboard, for some reason it is on the CRT/power supply board. So I replicated this buffer in my custom computer, and all was well. But then it broke for some other reason.

I mentionned this on a CPC forum and explained that I didn't really want to get into PCW things anymore because of breaking so many of them. But someone really wanted me to do new hardware and sent me yet another one, this time a complete machine with floppy drives and CRT display. I started working on the hardware again, and the machine self-destructed the moment I tried to probe my hardware with an oscilloscope.

So, here I am with a dead motherboard in that machine. The CRT and power suppy are still working fine and I wanted to reuse them. So the idea became to design a new motherboard to fit in there, and interfacing at least with the display, and maybe with the keyboard and the floppy drives.

I started to look for suitable options. I thought it would be nice to do a board I could hand-solder myself, but I don't want to use obsolete, not in production anymore components (let's keep those for fixing existing computers). And it turns out it is not so easy to find modern hardware that can interface with floppy drives and 15KHz monochrome displays, who would have thought?

So I started looking for system-on-modules instead. The idea being that I could find a cheap one, and then design a baseboard for it that would fit inside the PCW.

My choice eventually landed on the Lichee Zero from Sipeed. It is based on the Allwinner V3s chip, which is in itself interesting because it is a QFP package and integrates DRAM in the chip, so you don't need much internal components. Well, it still has a pin spacing that a bit too low, and a bit too many pins, so I probably won't handsolder one myself, but it would be possible.

The Lichee Zero is a board with the CPU and the needed power supply circuits, and a minimal support: one LED, one micro SD slot, one USB port. Everything else is available on castellated holes all around the board with a 1.27mm pitch. It appears the initial idea was a 2.54mm pitch you could use on a breadboard but they included extra pins in half-steps in between.

Anyway, I ordered two of these and proceeded to let them sit on my desk for a few months. This weekend I finally decided to… start a completely different project with them!

The problem with this board is there is really not much you can do with the bare board. You don't have access to a serial port or video output (well, there's a connector for an LCD but I already gave the one compatible LCD I had to someone else who wanted to interface it with an FPGA). And so you really need a baseboard to get started.

So I started thinking about a simple board exposing most of the IOs in a convenient way. I found the schematics from Sipeed for the Lichee Zero and the baseboard they offer for it, and based my work on these. But I added a VGA port, which the original Lichee Zero desgner offered an adapter for, but there are no schematics for that and no one is selling it. I hope my version will be close enough, it is based on a similar adapter designed for the Raspberry Pi.

During my research I found that the Allwinner V3s chip used on this board is now obsolete, and has been replaced by te V3x. I think when I bought the boards, there was not much known about it. Or maybe I didn't know how to search for it. Now there seem to be a community of chinese hackers at the whycan.com forum working on custom boards using it, and having some success running Linux on it, including apparently a NES emulator with a 6502 CPU core written in hand optimized ARM assembler.

Anyway, in about a day I designed and routed my own baseboard. That would have been simpler if the Lichee Zero had a more standard connector for attaching to a baseboard, but apparently the Lichee Zero Plus, which would be exactly this, is not available. So I had to design my board with a weird shaped cutout in the middle and hope that the Lichee Zero will fit there and align with soldering pads.

I have included the follwing features:

• On board USB to UART
• Ethernet port
• VGA port, with the possibility to connect the DDC lines to the I2C bus on the V3s
• USB host port (for gamepad or keyboard or...)
• Audio jack output
• 4 keys connected to the KEYADC pin (I didn't know what to do with that pin anyways)
• Expansion connector with easy access to all the remaining pins

The SD card remains on the Lichee Zero module.

In the end the whole project is a bit silly: I started looking for a hand solderable chip, I didn't find one, I picked a system on module with a really strange motherboard attachment scheme, and one that still had a mostly-solderable chip on it even if that didn't matter. And I did not end up designing what I initially intended to do.

We'll see where to go from there. For the PCW project, I have now concluded that a system on module makes sense, because it avoids me doing all the tricky power supply part and also means I don't have to make a huge 4 layer board (it seems hard to route all the needed things for the chip, even the V3s or the V3x, on a 2 layer board). The chip is also strangely balanced, with a 1.2GHz core, but only 64MB of RAM. I don't know if Allwinner will continue doing these chips with a not-so-large amount of DRAM built-in. The new generations of "Lichee" boards from Sipeed appear to use the Allwinner D1, a RISC-V chip with an external 512MB DRAM, and also a somewhat more reasonable form factor (it connects to two side-by-side M2 slots, but of course not using them with the standard things you'd find on an M2 pinout. It also apparently has direct HDMI output, which is kind of nice. But then it's maybe not a thing I can design a baseboard for in just a day.

Probably as usual with these things, by the time I finally order PCBs, and fix all issues in the first batch, the Pi Zero will be all out of stock. Maybe I will never get to build more than 2 machines, and then no one will really write any serious software for it.

Oh well, another week-end where things didn't really go as planned. But I made things work in the end.

So, the goal for friday evening was to assemble and test the final version of the Amstrad PCW keyboard to HID adapter I designed. The first version had a stupid mistake (I put the DIN connector backwards) and so I had to order a new batc of PCBs. On the first one I assembled, I was not able to program the microcontroller. So I assembled a second one, and hit the same problem. I did not spot any obvious assembly mistake (chip in the wrong orientation, short cicuits, ...) so I started suspecting a PCB design error. But, triple checking my schematics revealed nothing.

I started probing around with my scope, and quickly found that the quartz that is supposed to clock the circuit wasn't getting any movement. This circuit uses the AT90USB162 microcontroller, which is a bit special because it comes pre-flashed with an USB bootloader. For this to work, it requires an external clock, and the chips should be pre-configured to use a 8MHz quartz (what I have on the board). But, it seems they didn't.

The problem is, the ISP programming usually used to program these chips require the chip to have a working clock. Without one, the chip won't answer. The "proper" way to program these chips would be with a high voltage parallel programmer, but I don't have one that can accept these TAFP chips (especially not after they are already soldered onto a final PCB).

Before and after reaching to this conclusion, I did various experiments, one which involved trying to update the firmware on my USBASP (that I don't use much anymore, since I have an STK500 board) because avrdude complained that it couldn't control the SCK speed. That USBASP is one from Jyetech, and I noticed that it uses an ATMega48p, which is not one of the officially supported chips for the USBASP firmware. I tried flashing it with the ATMega48 version of the firmware and that bricked it.

I also tried ressurecting my older USBASP, one that I built myself with a PCB that was engraved by a local electronics shop near my parents home (yes, surprisingly they live in a relatively small city that somehow has TWO electronics parts shop, one of which would do PCB engraving, ROM programming, and other stuff on-demand, which was hugely convenient to me as a teenager trying to do electronics).

I put an ATMega8 back into that old thing, and got it back to the state it was when I last stopped using it: the USB interfacing works, but it does not detect the target device for some reason I can't find. And, more annoyingly, despite having the latest firmware, avrdude still complained that it couldn't configure the SCK speed.

Anyway, I figured out I should stop messing with these things and stick with the STK500 (and since we are talking about all my AVR programming tools: I got this one when a company I used to work for moved to a new office, and decided to throw away a bunch of unused equipment and parts). I wouldn't pay the full price for it, but it has been extremely useful.

Anyway, so, it looked like the chips were not getting any clock. I could think of two explanations: my quartzs were not working, or the chip were misconfigured. The first idea was easier to test: I put one of the quartz in the STK500 quartz socket, and could quickly confirm that it was generating a perfect 8MHz signal. So the quartz seemed OK. That left only the second option. Thinking about it, the obvious way to have one of these chips not clocked is to configure it to use an external oscillator instead of a quartz. All other settings would result in some sign of life at least.

Looking at my test crystal on the STK500 board, and re-reading the jumper settings and manual for the board, I realized that this quartz circuit on the STK500 is there precisely to help getting out of that situation: the board normally sends a clock signal to the chip being programmed (on one of its onboard sockets), so, even if the chip is set to use an external clock, it will work.

I added a wire to connect the oscillator output to the quartz on my board, and that was enough to get things going. I could finally reconfigure the fuses to the normal setting.

I was not fully out of trouble, however: some confusion resulted from using the online AVR fuse calculator, which somehow has the incorrect default values for the fuse bits for this chip? That was apparently copied into one of my makefiles, and I ended up setting the chip into an invalid state again. This time, my software was running, the clock was running, but still I wasn't able to change the fuses! Finally I managed to get out of this by shorting the HWB and RESET pins to ground, forcing the chip to enter bootloader mode. From there, I could flash a working version of my code. But I still had the wrong bootloader.

See, the idea with these adapters is that they are small. For this reason, I didn't want to include the HWB and RESET buttons as you'd normally do. Instead, the controller detects if a PCW keyboard is present, if not, it goes to firmware upgrade mode. This means the bootloader can be entered without any extra buttons.

Eventually I figured out what was happening (I think?). The chip was running, but the CLKDIV8 fuse was set, meaning it was running quite slow. This is fine for my code, but the ISP programming needs to be adjusted. To do this, one has to use the -B option to avrdude to force a slower clock. Doing that, I was finally able to flash my modified bootloader and get the thing working as I wanted.

Conclusion

I bought these chips back in 2021, during the parts shortage. At the time, they were out of stock on the usual suppliers and so I turned to utsource. This had two consequences: I have no idea where the chips actually come from, and, since I had to pay more for shipping than parts, I ordered a relatively large number (20 or so, more than I needed at the time).

What happened to these chips before I got them? I don't know. From the chips in this batch, a few were fine (the first 5 or so I used didn't give any problems), several but not all had the clock fuse problem, and at least one has a persistent write error in the flash.

My guess would be that these were chips that didn't pass tests at the factory, but with the parts shortage, someone decided to sell them anyway?

It is not the first time I run into problems with parts from UTSource, last time it was some GALs that I was not able to program at all. These came with stickers on top, meaning they were already programmed with something, but I think the offer on UTSource correctly listed them as used and I kind of accepted the risk.

Anyway, a weekend wasted in rescuing these chips, but it mostly worked in the end!

Please do not mirror my whole website using wget mirroring mode, WebReaper, or other similar tools. It results in a lot of requests to my poor old server, too much memory and CPU use, and the server fan spins up and makes a lot of annoying noise. So I will ban your IP or IP range from accessing the website if you try this.

If you want a full copy of some parts of the website, please contact me so we can set up a better way to share the data (I can set up an ftp or sftp or rsync thing, for example)

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

On this website you can find various stuff I work on, around the Haiku project, electronics, 8bit computers, and random things depending on the day mood.