Saturday, 15 September 2018

Pizza Box C64

I became curious about what would be the best way to put the Commodore 64 inside a pizza box shape, to save a bit of table room and to have some fun.

Board orientations

Common sense says the circuit board should be tucked away at the backside of the box, but I wanted to explore other logical possibilities too, and bloat the blog post for what is essentially a very simple case project.

1. Board at front, backside to front

The cartridge port and devices would be very accessible, but the front would look messy. I'd have to take a lot of care to make the openings neat and still it would likely look quite bad.

Joysticks and power would be quite accessible at left side. Different connectors and the cables would  eat up table space which is not very desirable.

2. Board at front, backside inwards

Clean front, but the cartridge port would be hidden and unaccessible. Joysticks and power would be highly accessible at right side, near the computer front. Not that bad really, if I am sure I rarely remove the cart. Perhaps the cart buttons could be wired to the side or front.

In a situation like this the SD2IEC could be pulled to the front panel.

3. Board at back, backside inwards

Seems clean all round, but the wires would have to come out somewhere, most likely the back, which would somewhat defeat the purpose of this position.

Pulling some of the cables & connectors to the front would be neat & easy. The cables could compromise the creative uses for the empty space, though.

Again, the cartridge would be quite unaccessible.

4. Board at back, backside outwards

Like the normal Commodore 64 setup, the joysticks and power are at the right. Unlike the C64 they are quite far away from the computer front.

This is perhaps the most preferable orientation, cables are tucked away at the back like they should be, and the cartridge can be accessed even if a bit far away.


I also considered some sideways orientations, although I did not expect them to be useful they are in fact not all that bad:

5. Right side, backside inwards

Again, less accessible cartridge port, joystick ports would be awkward at the back. The cables could be pulled out from the backside, which is a plus of this position. 

Also, there would be nothing at the front of the computer, perhaps SD2IEC access.

6. Right side, backside out

Would give the joysticks and power to the front, and extra access to the cart. The cables would fall out from the side which would take room on the table. Depending on the position on the table this would not be that bad, but the power cord and joystick obviously are a bit bluntly at the front.

7. Left side, backside out

The same problems as with 6, but almost none of the advantages. Cables would pour out from the side and yet the cartridge and joysticks would be quite far.

8. Left side, backside in

How about no? Well, ok the cables can again be pulled out from the back but the power cord would come out from a fairly ridiculous point, something that was about bearable in 6.

So, the verdict is there's not that much to improve on the initial idea, represented by the orientation 4. But positions 2 and to some extent 6, did give some food for thought so it's not the only viable solution.

Although 4 gives the idea that the port configuration resembles the c64 mostly, actually 2 has the joystick/power positioning closer to the breadbox original in relation to the front side of the computer.

Did not explore: Upside down circuit board. Diagonal circuit board. Circuit board at the centre of the box (and all 4 variants)

I'm also not considering a tower now although I was a bit attracted by the upright position as inspired by Sinclair Pandora/Atari Microbox/Sony PlayStation2.

Going for size

By the way, what are real Pizza Box sizes? Google says 16" is for extra-large which translates to 40.64cm. This would be enough to house the 390 x 136 board.

I figured dimensions 410 x 350 x 50 would be a good starting point, it's the real C64 width, the monitor (1084) base depth, about the height of the C64C at the highest point.

The above image collects some of the initial ideas about how the box would be sized in relation to the monitor and the things inside. Top image is front and the bottom image is a sort of "section" from the side.

Based on this image I already found some reason to position the board a bit further away from the backside, the legs might get in way of the board.

Building the box

At first, I placed the circuit board over the bottom, to have an idea what of the real size. Then I drew the screw positions with a pencil, drilled the holes and put the board into place.

There are a couple of bolts on each screw so the circuit board doesn't touch the chipboard, and a few of the screws are capped with bolts so the board won't fall out if upside down.

The legs had so short screws I could not fasten them, I'm just hoping they stay put in the drill-holes.

Then I'm just adding the junk chip board all around, using wood glue although it won't have the proper effect as the boards are already painted.

The four-player adapter fits rather nicely here although I did not think about it at the beginning. The board is kept slightly inwards, not because of the rubber feet I was talking about previously. (The feet were much tinier than I remembered)

The SD2IEC is taken out of its previous cover. I would have rather ordered a new SD2IEC, but I was impatient so the cover will have to find later use.

There's a lot of room inside the box, which is one benefit of moving the computer to a larger case. I'm toying around with the idea of housing a Raspberry there, with no connection to the C64 whatsoever.

I'm not going to lie, the material looks awful ugly at the moment:

Some prettification is in order, but it'll have to wait until next time. This was already one session's worth of work for me.

The size ended up as 405 x 300 x 55, so all around slightly different than what I envisioned. It turns out the 1084S base is really less than 300, and not 350 at all. I could still use a less thick top get to the 50 height though. The SD2IEC went to the left side instead of right.

Oh, where's the keyboard? I have already an idea or two, but again, some other day. The SD2IEC interface and Final Cartridge menus can be operated with a joystick, so for the time being this is a limited C64 "game console".

Monday, 3 September 2018

Lenovo Thinkpad x220i

Some time ago, I switched over from Dell Latitude 4310 to a used Lenovo Thinkpad x220i.

The Dell charger started to give trouble, so I changed the charger and eventually that one gave trouble too. It turns out there's a signal transmitted from the charger, and if the computer does not find the signal it throttles the processor speed and prevents the battery from charging.

There's a grub fix that prevents the throttling from happening, but it doesn't help with the charging problem. The fix might even prevent the processor from boosting. I also found there is a hack around the one-wire protocol used in the charger, but it seems a bit beyond my time/equipment/skills to be honest.

In addition, one of the USB ports started to show contact problems so I was quite motivated to move on. The Dell was by no means a bad computer for a Linux Mint install, it served me for quite many years.

I had the opportunity to buy a comparable laptop for less than 100€.  Moving over to another, similarly specced laptop, now that some time has passed I felt it would be nice to try to list the tradeoffs:

Lenovo on the plus side:

-I could move the SSD directly to the drive bay of the Lenovo, the Linux Mint boots fine from it. To be honest I might not have bothered installing yet another Mint and building my environment.

-I had 2 x 4GB laptop memory lying around that did not work properly on the Dell, these work on the Lenovo, a very nice bonus!

-The graphics hardware is somewhat better than with the Dell, it can be noticed for example in webGL applications. This doesn't make it a gaming lappy by any means, but at least web banner ads don't slow it down :O

-It's lighter and has smaller dimensions than the Dell. (I count the smaller screen a plus in this case)

-The Lenovo (probably) does not have that silly vendor locked charger thingy

-One more USB, and a USB port that supplies power even when the laptop is off.

-Slightly better/louder audio from the laptop speakers.

-A tiny detail, but like the positioning of the SD card reader better. It's on the right side, almost as if it were a floppy drive.


Lenovo glitches/downgrades:

-The processor (Intel® Core™ i3-2310M CPU @ 2.10GHz) is a tiny bit less capable.

-No webcam. In theory one could be fitted I suppose.

-Although apparently SATA3, the SDD demonstrated only SATA2 speeds so no improvement on that. This might not be the computer's fault, though.

-No CD/DVD drive. Not often used anyway, and an external drive works just as well so I'm not sure how big a "minus" this really is, it's dead weight most of the time.

-The keyboard is maybe not quite as good, it travels a bit more and is more susceptible to small particles. After a few months I've become used to it though.

-Something worries me about the touchpad. The scroll function ceases to work at times, although only at specific Chromium tabs! I've not yet got to the bottom of this, but it only came up after the laptop change so I'm listing it here.


So, all in all a quite good exchange. The pluses are quite noticeable, whereas many of the negatives are not such a big deal or can be worked around. The Lenovo runs the same Linux Mint 18 Sarah 64-bit install as before. Both have VGA, RJ45 ethernet, SD card reader and headphone jack.

Wednesday, 1 August 2018

Multipaint 2018

This year there has been no Multipaint release, so it was about time.

Get the new Multipaint from here.

Still, it's more of an intermediary version, and not nearly all to-do's and good suggestions have been addressed. But here's some:

Finally fixed the silly mac version bug where the icon graphics could not be fully loaded. I simply integrated the icon graphics with the source so nothing needs to be loaded at all here. Entirely different privacy/quarantine/malware scan etc. issues might still pose problems depending on your setup.

Left: old pepto, Right: colodore

Alternative palette support for C64 modes (loads .act format). The one true C64 palette for PCs is a bit flexible concept, so I've finally caved in to requests and allowed alternate palettes. That old pepto might still be most favourable for C64 pics on the PC screen but it might not always be the best prediction for how the image will appear on other hardware. So better prepare with alternate palette checks!

You can for example download different colodore settings as .act files from pepto's colodore site and then load them into Multipaint with the standard load icon. It would be nice to support some text editor readable palette formats (GIMP) but this was the easiest to do for now. The .act file contains 256 R,G,B byte values, but only the first 16 are loaded. A Hex editor can be used for fiddling with the values.

Note that using different palettes might produce complications when loading in png files, so better use as nearly the same palette as in the original png.

A preview window, if you can decipher it from that mess 
I added a sort of preview window (backspace on/off), another often requested feature. It's not a true floating window, and although I could have copied the solution from Marq's PETSCII editor, I am still a bit careful. This "window" can be dragged around the screen but unless in the magnify mode there's not that much room for it anywhere.

To help give more space for the preview window I made it possible to force multipaint window size in the prefs.txt, for example something closer to your native screen resolution. However this should be used with care as what works in one screenmode might not work in another.

More flexible window & icon arrangement is something I'm working towards in the future.

Not too useful yet, but at least the preview doesn't HAVE to overlap the pic
Mousewheel support has been long coming, and I finally bothered to find out how to circumvent that "ambiguous type" error message that had prevented me from using it. Hey, I'm no Java expert... I also added some customizable functions for the wheel in the prefs.txt, but these are very preliminary. The wheel defaults to magnify in and magnify out.

More undo levels, there are now 20. All memory for undo steps is reserved at the start, so I have been wary at adding too many levels, however 10 was a bit silly for pixel work of this type. In the source version, it is easy to add even more.

I added a simple aspect ratio switch for MSX and future modes, as it's clear that although MSX has the same pixel resolution as the ZX Spectrum, it gives a flatter image (depending on NTSC/PAL whatever). The simple aspect ratio is only an approximation, and won't work with the preview window.

Also, Multipaint kind of supports 256 height now. The flat aspect might not be flat enough for QL!
For those who have bothered to read this far, I can say supersiikrit screen modes are now more accessible. These incomplete, untested or otherwise experimental modes were usually only accessible from the source version. But now the application allows these modes too, but only through the prefs.txt:

C64NOLIMIT (320 x 200 with 16 fixed colors, i.e. C64 hires without attribute limits)
QLLOW (Sinclair QL 256 x 256 with 8 fixed colors) *
AMIGA (Amiga OCS 320 x 200 x 32 colors out of 4096)
COCO3 (Tandy Coco 320 x 200 x 16 colors out of 256)
BK0010 (Elektronika BK0010 256 x 256 with 4 fixed colors) *
PICO8 (Pico8 fantasy console 128 x 128 with 16 fixed colors)

*) Uses the flat aspect ratio switch

No export/import functions, so only jpg/png works with these, and I have no guarantee on the accuracy of the modes or the suitability of the Multipaint toolset for these modes, especially when it comes to the "Amiga" mode.

Again, the new Multipaint, from here.

Tuesday, 24 July 2018

More 8-bit pictures

Again, I'll have a look at some of my recent 8-bit pictures.

Queen, a multicolour Commodore 64 picture,for the Vammala Party scene compos. What started as an Alice in Wonderland-esque image, was finished quickly with fantasy chesspieces. Made with Multipaint.

Wolverine, a PETSCII work, also for Vammala Party. Fun to do and using the triangle chars for the costume was no-brainer, but maybe a more active pose would have been impressive. Made with Marq's PETSCII editor.

Remote, a, well, remote entry for Gubbdata 2018 graphics compo. Again, made with Multipaint. This turned out simple/nice and has a multicolour vibe to it even though it is a Commodore 64 hires.

Cartoon outlines are not that easy to do on hires and the approach falters at places, but I feel I managed to make it look like it's intentional.

The image started out from trying to recreate a C64 picture I saw in a dream (roll eyes here if you want to) but the end result became something very different. The robot is reminiscent of the robot in Short Circuit, which I watched recently.

Friday, 6 July 2018

Atari 2600jr

Just think that many Atari 2600 games are now about 40 years old. I believe I encountered Atari 2600 in the summer of 1984. This Jr. version is a later acquisition, I got it alongside a bunch of computers in 2010s.

In the past I had already fixed the select/reset buttons (a common problem in Jr) with crude switches, but avoided doing the composite video mod. Except now.

As Ataris are so popular there are a gazillion mods. I followed the mod from a site that happens to be gone now, but it is pretty much same as here. I simply found my board to be similar and the instructions are very concrete.

1 x R 330
1 x R 1K
2 x R 2K2 (=2,2K)
1 x R 3K3 (=3,3K)
1 x Capacitor 100pF

The mod features a 100pF ("101") capacitor, I figured that the n10-labeled capacitors in my inventory should suffice, although I haven't seen this notation too often.

"n10" = 0,10nF = 100pF

(The 'n' denotes both the scale and the position of the comma so 1n0 would be 1,0nF and so on)

I added a tiny board where I imagined all the wires and resistors would go neatly, placing it over the pins that now make up the select/reset switch connectors. The plan fell through and I soldered the resistors directly to the chip as in the site I found. The added board was somewhat helpful for fitting the video cable that goes out of the box.

Without the audio, two solders away
I cut a couple of grooves to the right side of the case, so the video/audio cables can stick out from there. Having the grooves tight keeps the leads in place. A neater mod would have two proper connectors but I didn't have ones that would have fit. I left the RF connector as it is.

I realized I can't use my previous select/reset switches as they collide with my added board! Not much foresight here I have to admit. Also it reminds me how large the switch boxes can be.

So I removed the crappy switches and added two buttons to the top of the case. I could have removed my additions but I was lazy as usual. The new switches are connected with breadboard jumper cables at least they can be detached easily for removing the case.

I played a bunch of games installed into a Harmony cartridge. But is there something wrong with some of the colors, for example California Games has obviously a wrong palette? But games I know well such as Jungle Hunt and Space Invaders seem to have correct colors so likely it's a software version thing.

So, what to play? My own nostalgia-biased shortlist:

Jungle Hunt

A complete jungle adventure. Few corners have been cut in the conversion, but it does not detract much from the gameplay.

Space Invaders

Ok, so it gets monotonous and does not have all the subtleties of the arcade original, but this was my Space Invaders and the first game I played on the Atari 2600.


Ditto here, I kind of dig the chunky big graphics of 2600 conversions compared to the arcade stick figures. Switch on the Evil Otto for more difficulty.


Even if the backgrounds are quite simple, the play appears to be as complete as in any version. Dynamite the walls, shoot the critters, always pick the route with the obstacle. Gets hard around cave 11 or so.

River Raid

The classic vertical shooting game is nearly fully featured as far as I see. Shoot the bridges, collect the fuel, shoot the fuel. Check the B-switch for proper missile behavior.

Ms. Pac-Man

Although the Pac-Man conversion has a bad reputation, the sequel delivers. A proper maze and you can even see everything.


My best score so far.
This latter-day homebrew conversion by Thomas Jentzsch is amazing and possibly the best game altogether you can get for the Atari 2600. Considering it's one of the better games on the Commodore 64 it's surprising to see it fully functioning here!

Sunday, 17 June 2018

"Data East Hits" 8-bit Gaming My Arcade Pixel Classic mini console

Disclaimer: Your kid might in actual fact eventually become bored
Over the years I've seen a bunch of "50 games" type handhelds at supermarkets or department stores. As the games and physical design are always so bland and generic, I've avoided them.

Now I was lured in by a Data East-branded "308 games in one" cheap device that comes in various attractive shapes, notably the horizontal Lynx/Gameboy Advance form and the more obviously Game Boy shaped hand held console. There's also a mini arcade shape that I did not look at twice.

Options. Oh the buttons can be lit up too. Why?
I went for the Gameboy shape for novelty's sake, although to be honest the horizontal form might be better as a controller and for connecting the leads.

Ergonomics to hell, the case has been shaped with "pixel arty" corners, but this matters very little. Designers take note, perhaps this is an indication we've got past that roundening-era of design styling.

The plastic feels a bit flimsy, but the buttons give an adequate response. There's a 5V micro-USB style power connector, AUX out and AV out. The device works on 4 AAA batteries, but the other options sort of sold this to me, even though no cables or batteries were included with the price. (about 30€)

The game collection

The Data East name is boldly visible on the package, and as their back catalog boasts some really iconic stuff (Burger Time and Bad Dudes vs. Dragonninja) I was prepared to expect at least a good bunch of playable games.

I prefer Mr. Do's Castle (not included)
The word "arcade" might mislead you to think these are arcade version of the games, not to speak of the screenshots in the inlay card.

I can't believe that in this day and age I could still get duped by a "wrong platform screenshot". Thanks for making me feel like a child again, but perhaps not the way I expected...!

Screenshots may vary.
Yet the shots are made in a way that although built from arcade screens they might arguably represent "game covers" rather than actual gameplay, hence the logo overlays. And it DOES say on the cover, "8 Data East + 300 games", but that "plus" is also quite easy to miss. And it DOES say "8-bit" which should clue in that the games can't be arcade quality.

Let's make it clear: About 95% of the games are simplistic, NES bootlegs or otherwise very poor quality.

Real screenshot for comparison
On the first page we get Dragon Ninja, Break Thru, Caveman Ninja, Heavy Barrel, Side Pocket, B-Wings, Karate Champ, Burger Time... These are up to the quality of the NES versions of these games, which is to say they are not all that hot but mostly they play well enough.

But after the first couple of pages it goes downhill. So, enjoy the excitement of iconic 8-bit games the likes of Man in Red, Repair Urgently, Speed Man, Unusual Space, Girl, Tactful Monkey, Devildom Doom and so on!

There's pages and pages of this shift
Many of the games are old bootlegs and hacks of licensed games, like Dada is obviously Popeye, Primitive Woman is supposedly a Tom and Jerry game and Sunken Ship is worked from 2005's Titanic, which in turn is a hack of a Tom and Jerry again. Astro Robo To To is Astro Robo Sasa. Aether Kadass is Macross. Sky Invader is Sky Destroyer. These bootlegs can be semi-playable or interesting as such because the game content is kind of there. But I'm wondering how this particular collection of games got to be curated.

There are many scrolling vertical shooters, the best might be F22, with actual power ups, boss fights and varying levels. I guess it is another rework of something else.

The bootleg of a bootleg
I'm prepared to say some might even be filler crap made specifically for this device, varying a base source code to produce simple shooters and jump'n'runners.

Some games have visuals that go beyond NES, like Cut Fruit and Curly Monkey 2, but design-wise, there's not much thought on the gameplay or level design.

Some games are so simple it's harder to fault for what they are, like Horse Racing where you simply duck and jump with the horse. However there's a bunch of boring sprite-shoots-sprite stuff, guy jumping on platforms, or collects stuff falling from heaven, with slight variations and different skins. There's even a digital paper/rock/scissors game, which must be the pinnacle of sadness.

Dark Castle. Wasn't this Thunder Castle on the Intellivision? Looks crappier.
At least one track'n'field-type game has been blown up into a dozen, with javelin, long jump, hurdles etc., even making Breast Stroke and Butterfly Stroke into separate games. Although I have to admit it may be a better idea than try to endure a full decathlon. A panda takes the place of the sportsman, possibly a clue about the country of origin of these games.

Then there are card games and board games such as mah jong, reversi, checkers, sudoku and so on. These can't be overtly blamed if they are simply bootlegs of once commercial games. Sadly there's no chess, though. Other genres are absent too, there's no Tetris or Columns clone for example, and no proper top-down driving game with rotational controls either.

Dark square at right = Portuguese draughts? Your move.
Then there are doubles, that is the same game with different graphics. This is a bit irksome as usually both graphic variants are just as visually uninspiring.

Overall the games boast very mediocre, bland and unimaginative visuals and sounds, while the game titles convey an idea of non-IP-infringing nothingness. It's almost as if I'm witnessing a relic from an alternative universe Earth culture that had strangely failed to invent any of the central video game brands we have.

You go... eh, girl!
All in all, the Data East games are probably the most playable of the bunch and Burger Time might indeed be the best game on the entire device.

I'll review all the 308 games later.

Final verdict

I took the device to a composite video TV. As I don't have a proper 2,5mm AV cable I used a single tip/sleeve version which produced only a black and white image. Or is the output only B/W? This was enough to show that the device does produce a smooth frame rate for the TV, which is nice. Of course a few of the games give jerky scrolling or flickering sprites due to programming techniques.
A 5V 1A phone recharger cable seems to be sufficient for powering the device (no specs in the manual) so the absence of a cable in the package might be justified. However the 2.5mm TV cables are less often seen.

One annoying thing is the device can't remember the volume setting when returning to the menu. it can remember the menu positions so why it can't keep silent? Wading through the 308 game menu can be tiresome, even if it can be scrolled sideways too.

So, is the My Arcade 8-bit Gaming Pixel Classic any kind of value for money? Despite all the misguidance, I could still be generous and say there are about 30 reasonable quality games in it. Even then 1€ for each might still be a bit too much!

It's a bit sad considering the hardware might be capable of doing justice to the arcade versions of the games, but the conversion job would have been overbearing. I doubt the device is good enough to really emulate the suggested arcade platforms.

Perhaps if the game ROMs can somehow be rewritten, the device might be much more interesting because the physical hardware is OK-ish and the screen and sound quality is not that bad. I am a bit doubtful if anything inside can be easily upgraded, though. Missed potential I'd say.

Addendum 18.6.2018

As I saw the device might be easily opened, I had a peek inside:

For those interested in subduing the sound, this might be achieved by physically blocking the loudspeaker a bit more. (There are like 2 loud sound levels + silent)

The parts are not especially neatly connected so it was a bit of a bitch to put back together. So I'm probably not going to open it again.

The game ROMs are likely buried inside that alien tar shit thing. (Hmm the SPANSION S29GL256P10TF is memory, though). Putting the screen back, it has to be straightened by hand. Luckily it can be done after the board has been screwed back in.

Monday, 11 June 2018

Fixing a Fostex 280

I have had a Fostex 280 (1989) 4-track tape recorder/mixer for about 20 years. I bought it used, around 1998, did some funny stuff with it but then generally forgot about it. At some point I considered it a junk item as the tape recorder had ceased working.

Now I found a 4-track tape with something I'd not heard in 20 years, which gave a motive to look at the device again. Searching the net I was pretty sure the tape recorder belt was faulty, which was also easy to confirm.

Also, I had probably misused the multitracker back in the day, so it might be interesting to record something with a bit better understanding of sound dynamics and a more appropriate cassette type.

The Fostex does 4-track on a C-sized cassette, simply creating four magnetic trails instead of two, using a higher speed than ordinary tapes. The mixer part has 4 main channels with equalization, gain, two AUX buses and various re-routing options. There are also 4 more channels with less options, giving a total of 8.

Channels can be recorded on one track, or stereo-recorded over two tracks at once. Tracks can also be bounced, re-recording for example three tracks onto one, giving more space for new tracks.

The digital control over the 4-tracker is pretty neat, as the tape counter can be set to zero at a convenient point,  and then >>0<< rewinds the tape back to that position. There's also one alternate memorized position that can be used as a loop end position, facilitating loop and auto-record.

Looking at eBay listings, a working Fostex 280, although not super-expensive, is not exactly trash either. Going back the memory lane, I remembered how fun and uncomplicated it was to do a recording without a computer.

Replacing the belt

As I saw the multitracker was not completely lost, becoming motivated again, I then ordered a replacement belt from eBay and received it in two days. Day later, I had it replaced.

When the belt has disintegrated, the tape deck can't really behave at all. As the Fostex is switched on, it will give a horrible creaking sound and an "E" on the display. Furthermore, the tape head may be left awkwardly in a position that makes it difficult to remove or insert the casing cover or even a cassette.

The dreaded "Red E of Death"
These are often indicators of a broken belt and replacing the belt got rid of these problems. Listening to my tape was bit of an anticlimax though, but nice experience in a time travel sort of way.

This video by the Youtuber account "3rd island" shows absolutely everything about the process. Without it I might have wasted time or even broken things. I'll recap the main points below:
  • Remove all faders, unscrew the case cover and then gently pull out the cover.
  • Disconnect cable connectors that might hinder the cover. There's no point in trying to keep the different units connected during repair, if they are in your way. The connectors are quite well color-coded and have logical sizes, but just to be sure you might want to photograph the starting position.
  • Pull out the circuit board with the faders. There's a foil between this and the circuit board below. The foil does not need to be fully removed, just disconnect all the connectors that lead to the tape unit, and make some note of their routes between the capacitors.
The white, red, blue and yellow are for the tape unit.
  • Remove the four screws that keep the tape unit in place. Take note of the ground wire that is also screwed in. Pull out the tape unit.
  • A metal panel needs to be removed before the belt can be inserted. This part is held to the unit with only one mechanical screw. Take care with removing the screw as this holds a couple of other parts in too, mainly the spring. Also, take at least a mental note of how the spring is held in place, before loosening any parts.
  • Now the belt can be positioned around the metal wheel. The other end may be stretched around the small black plastic protrusion next to the plastic wheel, which is the real target for the wheel. Also, make sure the plastic wheel and the metal wheel are clean.
The belt is temporarily stretched over the black plastic stick.
  • Putting the tape unit back together, make sure the spring is in correct position. After the screw is in, the belt can be moved from the temporary position to the actual wheel. As shown in the video, tweezers are good for moving the belt.
  • The ends of the spring need to be re-located, use a combination of a small screwdriver and tweezers to achieve this.
 Left: The hook for the top side of the spring end (not in place). Right: bottom spring end hook (in place)
  • Put it all back together, don't forget the grounded wire under one of the four screws and don't forget any of the connectors.

What makes this fairly simple is that the insides of the Fostex are quite modular and the tape unit is easy to remove.

As I went through the process I soldered back one of the headphone sockets which had come loose. To tell the truth there's a lot of other problems with this multitracker, such as a bit lazy/random rewinding and fast forwarding. Some of the channels have ceased working properly.

I'm wondering if some of these might relate to bad capacitors or similar issues. So, the recording experiments may have to wait for a while. But at least I got my sound out from the 4-track tapes which was enough for now.

Sunday, 27 May 2018


With my Sinclair QL now armed with a disk interface and HxC Floppy Emulator, I wanted a simple way to access a Double Density disk image format and adding/removing files to it.

The qltools.c can be compiled on linux gcc, but I had a feeling I could also work towards understanding the raw image format a bit more deeply, and then write the HxC Floppy Emulator (HFE) files myself.

This is not really a blog post to be read, these are mostly very long "notes to self" about the topics that were needed to achieve what I wanted.

I'll look at:

-The Floppy Emulator 737280 raw byte disk image format and the QL disk ordering
-The Floppy Emulator HFE bit-level disk image format (MFM)
-CRC calculation

Bear in mind I'm not explaining IMGs and HFEs fully, I'm just doing the minimum to manipulate files on a 720k QL DD disk image.

For understanding the QL disk format, the below sites were valuable, but even then I had some head-scratching to do.

About the sector ordering:

Some useful disk terminology from here:

More definite header information from here:

The QLTools source code:

I am looking at a QL Double Density drive raw byte image as a middle-ground for transferring between PC/Linux files and the SD card-friendly HFE image. The image I'm working with is 80 Tracks, 9 disk sectors, two sides, with a sector size of 512 makes 737280 bytes.

A Block is a central unit here. The Block comprises of three sectors, making up 512 * 3 bytes, i.e. 1536 bytes, and there are 480 of these Blocks on this DD disk.

Two Blocks are already taken up by the disk header and File Allocation Table (FAT) itself and the Directory File.

Each QL stored file takes a minimum of 1 Block of space on the disk, even if I saved just one byte. Also, each QL file is preceded by 64 bytes of data, so a file saved on QL Basic...

SBYTES flp1_test, 196608, 1500

...will take two Blocks, as the true length of the file with the information will be 1500 + 64 = 1564, more than 1536 and no longer fits into one block. Additionally, the file takes a 64 bytes slot in the already reserved directory list block.

The raw byte IMG file

I will first look at a stored raw IMG file, converted from a HFE using the HxC floppy emulator utility software.

The raw IMG is exactly 737280 bytes long, so within the IMG there are no additional headers or other data than the floppy image as a byte representation form. Contrast this with the floppy emulator HFE image, which represents the bits on the actual disk and also has a header that describes the disk format.

For purposes of analyzing the image, I found it useful to display the IMG contents as hex/ASCII with 512-wide rows. The below shows the beginning of the DD image:

(Note that the block/sector order does not continue as neatly)
The only really certain thing is that the first 95 bytes are the header.

I guess the look-up table inside this area should describe the order of the sectors, but I use a fixed format/order.

Within this fixed format, the first block will contain both the header and the File Allocation Table, beginning from offset 96. The table is 12-bit, although I'm not sure that it corresponds to any FAT-12 standard.

What I call the "directory file header" in the above image is really one file taking up one slot in the directory list file itself.

The FAT contains 480 three-byte records, corresponding with the 480 Blocks that are on the disk of this size. After the FAT the image will contain by default one directory data Block, at block 1, and after this it's just empty blocks to the end of the image.

IMG File Allocation Table

So, in this disk the first block containing the disk header and the FAT information can be stored to a linear buffer by appending 512 (0x200) bytes from 0x0000, 0x600 and 0xC00 offsets each.

The FAT is made of 480 three-byte allocation records, and a record is made of two 12-bit values:

File Number 0x000 to 0xFFF
Sequential Number 0x000 to 0xFFF

Looking the record as three bytes, it is constructed this way:

Record #n
byte 0: 8 Most significant bits of file# value
byte 1: 4 Least significant bits of file# value, 4 Most significant bits of seq# value
byte 2: 8 Least significant bits of seq# value

An unused (empty, free) record has the values:

0xFD, 0xFF, 0xFF

e.g. File number 1, sequence 0:
0x00, 0x10, 0x00

e.g. File number 1, sequence 1:
0x00, 0x10, 0x01

0xF8 indicates that the block is reserved for the header/FAT. File 0x00 is commonly the directory file. 0xFC and 0xFE indicate files pending deletion and bad blocks respectively, but they don't concern me in this setup.

To simplify, a block can be considered to be in use for a normal, healthy file, if the value is below 0xF8. For my purposes it is enough to check the presence of 0xFD, 0xFF, 0xFF for empty blocks.

The record's location within the FAT indicates the Block number this entry is pointing to. So, the third successive record is "about" the Block #3.

Files larger than 1536 bytes use multiple Blocks, and are indicated by a similar file number and an increasing sequence count. If there are only small files on the disk, the sequence numbers will always be zero. For one giant file, there is only one repeated file number whereas the sequence number increases.

An example portion of the FAT might look like this:

...FDFFFF FDFFFF 001000 00200 00300 00301 00302 FDFFFF FDFFFF...

The above describes three entries between empty records (FDFFFF). The first two, 1 and 2, are one-block files. The third, 3, has three blocks, indicated by the same filename and an increasing sequence count. The directory file would have 3 named entries.

Although normal file writing places the Blocks after each other, nothing says the sequences have to be in any particular order. So, a routine that reads a file from the image has to go through the whole record, picking up all data in order of the sequence indicator.

Just to repeat myself, the FAT looks like this in an empty image:

Block/Entry#, 12-bit file#,  12-bit seq#

0: 0xF8, 0x00, 0x00 (Block #0 contains the FAT)
1: 0x00, 0x00, 0x00 file/seq points to block #1 - Directory
2: 0xFD, 0xFF, 0xFF file/seq points to block #2 - (Earmarked for directory?)
3: 0xFD, 0xFF, 0xFF file/seq points to block #3 - (Earmarked for directory?)
4: 0xFD, 0xFF, 0xFF file/seq points to block #4 - (Earmarked for directory?)
5: 0xFD, 0xFF, 0xFF file/seq points to block #5 - (Earmarked for directory?)
6: 0xFD, 0xFF, 0xFF file/seq points to block #6
7: 0xFD, 0xFF, 0xFF file/seq points to block #7...
479: 0xFD, 0xFF, 0xFF file/seq points to block #479

Interestingly, my real QL seems to save files starting from entry 6 onwards, whereas the QLtools utility seemed to add a file to the first available position whatever, which is 2.

Perhaps it's my fantasy, but records 2-5 might be seen as "earmarked" for directory, although I'm unsure if it would matter that much speed-wise or anything. (It might even slow down the disk, who knows)

Again, a directory reading routine can assume the first directory block to be 1, but theoretically the rest can be anywhere else. It might be better for a reading routine to take its cue from the FAT, looking for file #0 components.

IMG Directory Block

Looking at the first directory block, a row of 0x30 values covers the first directory entry (the entry is the directory itself). After that the directory entries are assigned to files added to the disk.

I'm told the file name and file name length information within the file's own header is useless, and the file names within the directory file are definite. This is the only place to access the true length of the file in bytes.
Note that it's pointless to have a 16-bit value for filename length, but some documents have it this way.

Given the first entry in the directory list is already in use, 23 files can be added before new directory blocks are needed. For example, if five blocks are reserved for directory, this would mean the directory takes 5 * 1536 bytes = 7680 bytes. The directory contains file information and each file takes 64 bytes. This would give 119 files on the DD disk before yet another block would need adding.

IMG Block and track order

My first diagram about the disk image beginning is misleading, as it looks like the blocks and sectors are interleaved in a clear way up until the end of the disk.

Although int(block/6) gives the Track# you can expect to have the Block in, the Blocks are not ordered, and neither are the three sectors (512 bytes) inside a Block in a sequential order.

Ok, so let's look at this thing. Again, the image file is arranged in 480 * 3 = 1440 sectors, including the FAT.

As my first diagram shows, if a row is 512 bytes, the FAT appears on rows 0, 3 and 6. Then the directory contents start at 9th row of the image, padded with sixty-four 0x30 byte-values. The next row containing directory data is at 12th row, and the third is at 15th row.

How to make sense of the arrangement? Here the soulsphere site comes to rescue, but it had to be read in a certain way before it made sense.

Let's find the directory. As the first directory block is the second entry in the FAT, it points Block #1, the ordering which falls within Track #0. (Which has blocks 0-5).

Track #0 contents are in the following order:

Offset: Block, Sector
0: B0S0 (each of these are 512 bytes)
1: B2S0
2: B4S0
3: B0S1
4: B2S1
5: B4S1
6: B0S2
7: B2S2
8: B4S2
9: B1S0 first
10: B3S0
11: B5S0
12: B1S1 second
13: B3S1
14: B5S1
15: B1S2 third
16: B3S2
17: B5S2

We're looking for Block #1, so I've highlighted the three sectors it is made of. Looking at the serial ordering of the table, the Block #1 sectors 0, 1 and 2 are at offsets 9, 12 and 15. Glancing at the 512-wide arranged diagram, it can be seen the directory contents are indeed at locations 9 * 512, 12 * 512 and 15 * 512.

Let's look at the first saved file on the disk. In this example, looking through the FAT, it is at entry #6, thus pointing at Block #6. (In my examples the files fit in one block).

The Block 6 can be deciphered by looking at track #1, where the ordering is different from track #0. The sectors 0, 1 and 2 are at offsets 23, 26 and 20 (counting from track #0 beginning), so they are a bit backwards compared to what was seen on track #0.

Offset: Block, Sector
18: B8S1
19: B10S1
20: B6S2 third
21: B8S2
22: B10S2
23: B6S0 first
24: B8S0
25: B10S0
26:B6S1 second
27: B9S1
28: B11S1
29: B7S2
30: B9S2
31: B11S2
32: B7S0
33: B9S0
34: B11S0
35: B7S1

So, the routine that constructs a multi-block file into a linear buffer has to go through the FAT in file sequence number order, collect and append the sector 0,1,2 data for each block in that order.

Building IMG Disk header and FAT

The 95-byte header is at the beginning of the image.

The directory length (0x22-0x25) is the 16-bit value at 0x22 - 0x23 multiplied by 512, and added with the 16-bit value at 0x24 - 0x25 multiplied by 64. (Each file entry takes 64 bytes in the directory, including the directory file). This can be recalculated by scanning the FAT for unique file numbers, including the directory.

Free sectors at (0x14-0x15) can be recalculated by counting which of the 480 blocks are unused, and multiplying that by 3.

Below has the whole header described. I highlighted with green the locations that need changing in the header, when adding or removing blocks to the FAT. It may be a good idea to increment the update counter and randomize the values at 0x0D and 0x0E, otherwise the QL might think in some situations that the disk has not been altered and refuses to display an updated directory.

Disk ID and filename (0x00-0x0D)

0x00: 0x51 'Q' Header
0x01: 0x4c 'L' Header
0x02: 0x35 '5' Header
0x03: 0x41 'A' Header
0x04: 0x51 'Q' Label
0x05: 0x4c 'L' Label
0x06: 0x5f '_' Label
0x07: 0x44 'D' Label
0x08: 0x44 'D' Label
0x09: 0x20 ' ' Label
0x0A: 0x20 ' ' Label
0x0B: 0x20 ' ' Label
0x0C: 0x20 ' ' Label
0x0D: 0x20 ' ' Label

Disk information

0x0E: 0x92: Random value
0x0F: 0x53: Random value
0x10: 0x00: HI Update counter
0x11: 0x00: .. Update counter
0x12: 0x00: .. Update counter
0x13: 0x02: LO Update counter
0x14: 0x00: HI Free Sectors
0x15: 0x00: LO Free Sectors
0x16: 0x05: HI Good Sectors
0x17: 0xA0: LO Good Sectors = 1440
0x18: 0x05: HI Total Sectors
0x19: 0xA0: LO Total Sectors = 1440
0x1A: 0x00: HI Sectors per track
0x1B: 0x09: LO Sectors per track = 9
0x1C: 0x00: HI Sectors per cylinder
0x1D: 0x12: LO Sectors per cylinder = 18 (Double-sided)
0x1E: 0x00: Number of cylinders
0x1F: 0x50: Number of cylinders = 80
0x20: 0x00: HI Allocation block
0x21: 0x03: LO Allocation block = sectors / block = 3
0x22: 0x00: HI Directory Length: sectors (512)
0x23: 0x01: LO Directory Length: sectors (512)
0x24: 0x01: HI Directory Length: units of 64
0x25: 0x00: LO Directory Length:  units of 64
0x26: 0x00: HI Sector offset / track
0x27: 0x05: LO Sector offset / track

Logical-to-physical sector mapping table (18 bytes)

0x28: 0x00
0x29: 0x03
0x2A: 0x06
0x2B: 0x80
0x2C: 0x83
0x2D: 0x86
0x2E: 0x01
0x2F: 0x04
0x30: 0x07
0x31: 0x81
0x32: 0x84
0x33: 0x87
0x34: 0x02
0x35: 0x05
0x36: 0x08
0x37: 0x82
0x38: 0x85
0x39: 0x88

Physical-to-Logical sector mapping table (18 bytes)

0x3A: 0x00
0x3B: 0x06
0x3C: 0x0C
0x3D: 0x01
0x3E: 0x07
0x3F: 0x0D
0x40: 0x02
0x41: 0x08
0x42: 0x0E
0x43: 0x03
0x44: 0x09
0x45: 0x0F
0x46: 0x04
0x47: 0x0A
0x48: 0x10
0x49: 0x05
0x50: 0x0B
0x51: 0x11

A bunch of 0xFFs

0x52: 0xFF
0x53: 0xFF
0x54: 0xFF
0x55: 0xFF
0x56: 0xFF
0x57: 0xFF
0x58: 0xFF
0x59: 0xFF
0x5A: 0xFF
0x5B: 0xFF
0x5C: 0xFF
0x5D: 0xFF
0x5E: 0xFF
0x5F: 0xFF

The above was the header, and what follows is the FAT. I'll just give the start of the FAT - which is spread across the three sectors of block #0 (480*3 bytes)

0x60: 0xf8 Block #0, Points to FAT itself
0x61: 0x00
0x62: 0x00
0x61: 0x00 Block #1, Directory
0x62: 0x00
0x63: 0x00
0x64: 0xFD Block #2, Free
0x64: 0xFF
0x65: 0xFF
0x66: 0xFD Block #3, Free
0x67: 0xFF
0x68: 0xFF

... the FDFFFF repeated to the end of the first block.

After the first block the img can be filled with zeroes, and there you have it, an empty, formatted disk image in IMG format.

Reading from the IMG

It would be handy to find a file from the IMG based on its name, and then store it in pc memory or disk.

First, decipher the directory, because it's the way to look at file names. In this disk image it is record #1, but can use more records than the 1, so look for any FAT entries that have the file number 0 and then append the block (sector contents in sequential order).

File blocks, including directory blocks, may not always follow each other.

Now that the directory is accessible in a linear way, it can be read:

entrybase = start + 64 * file_no

0-3: Length of file
14-15: Length of file name
16-51: File name
52-55: Modification date (I don't use this)

(Just as in that diagram way up.)

The directory is looped through with file_no * 64. When the filename corresponds with the desired name, the needed file_no has been acquired.

Then the FAT is again looked through for blocks that have that file_no, and all sequential blocks belonging to file are appended in order to create a linear file, just like with the directory. The directory is a file just like any other so one can proceed by loading the file# 0 to a linear file buffer, then use that to load the desired file to another linear buffer.

From that linear file, file_length-64 bytes are then be stored to pc disk, beginning from the 64th byte, in case the 64-byte header is not needed.

When loading any file, directory or otherwise, as the blocks are found, the true sector offset within the image needs to be deciphered.

This row is taken from a table/algorithm that "converts" them into the funny order they are in the disk and provides a simple table from which to fetch the order. Instead of explaining this I'll just show the Processing routine I use to generate the ordered translation tables:

int []g_transblok=new int[1440];
int []g_transtrak=new int[1440];

void track_offset_generator() {
  int tphase[]={0,0,0,1,1,1,2,2,2,0,0,0,1,1,1,2,2,2,0,0,0,1,1,1,2,2,2};
  int bphase[]={0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4};
  int ptr=9;
  int count=0;

  for(int trk=0;trk<80;trk++){
    for(int sec=0;sec<9;sec++){

If I want to know what is the offset row in the disk image of block x and sector y, I'll loop through the table with step of 2, until I have the pair. The result is that table position/2. Multiply by 512 and there's the address from the beginning of the IMG file.

int findoffset(int block,int sector) { 
  for(int i=0;i<1440;i++){
    if(g_transblok[i]==block&&g_transtrak[i]==sector)return i;
  return 0;

If I want to know what is the block and sector at the disk image row n, I just grab the two values from row*2 and row*2+1.

Writing to the IMG

The end game of this Tour de Force, adding a file to the image:


Find the highest file number in the FAT. Your new file has file_no of that +1
Are there enough empty blocks in the FAT for the file? If No, go to ERROR

Is a new directory block needed? If No, go to APPEND

Are there enough empty slots in the FAT for the file + the new directory block? If No, go to ERROR

Extend the directory list file by creating a new FAT entry for file #0 in an empty slot

Give it a sequence number+1 compared to the highest existing block with file #0


Append the file data to a 64 bytes header, giving the complete file data and the length of the file in bytes

Write the file name and file length to the directory slot file_name*64

For every 1536-byte file block:

  • Write the file number and sequence number (starting from 0) to an empty FAT slot, the block# is the number of the first empty slot.
  • Write the three sectors of data to the image, offset row *512, the row is based on the assigned block# and sectors (0-2) values, through a conversion table.
  • Increase sequence number, for subsequent blocks (if any)

Refresh the value for number of free sectors in the header
Refresh the values for the directory list size in the header
Randomize disk Random # value
Increment the disk update counter



Can't add the file! [END]

Into the HFE

Although the IMGs can already be converted to HFE with the HxC floppy emulator tools, as I had gone this far I wanted to get the IMG converted to HFE by my own means. This isn't as comprehensive, as I'm working with an already-formatted and HxC-converted file rather than creating a HFE totally from scratch.

The HFE file image for the QLDD is 2008064 bytes, which already clearly shows it is not a byte representation of the IMG.

Also, it has a 1024 byte file header as byte/word values, but the rest is bit-level information encoded in MFM (Modified Frequency Modulation) format suitable for the HxC to communicate with the disk controllers. MFM, the "Double Density", is a way to compactly encode the data and the clock signal into a waveform without wasting too much space/time.

Luckily the waveform generation stuff is not needed here, it suffices to know that information/data bits are interleaved with an encoding signal. I found it useful to have routines that access the HFE track bits directly.

Still, it is not entirely straightforward to transfer the IMG to an HFE, but it is not that difficult after understanding a few things. It also makes sense to approach the HFE only after doing the analysis on raw byte images discussed above. Also, writing data on an existing HFE ("formatted") is a bit simpler than building one from scratch.

Again, visualizing the HFE tracks in Processing was very helpful:

Before the sector bit data, the HFE file has a byte-readable HxC header. The most important information here are the byte offsets to each of the 80 tracks starting positions inside the HFE file:

base address: 1024 + track * 4
0: track offset LO
1: track offset HI (* 512)
2: track length LO (bytes)
3: track length HI (bytes)

(* 512 = multiply the 16-bit track offset value with 512 to get the offset from the beginning of the HFE file)

From the start of each track offset, reading every second bit after the first one gives the data bits for the track. Every bit in-between relates to the encoding. When reading the data, these are not really needed. Writing the data, these have to be coded to correspond with the data bits.

One header-related structuring still remains: within the sector data, disk side information is interleaved so that the first 256 bytes relate to side 0, the next 256 bytes to side 1 and so on. To make things simpler I make the whole HFE data linear before working on the image, then de-linearize it before saving it.

Now, supposing we've found the start of the disk data (more on that below) that corresponds with the header start in the raw byte image:

Q        L        5        A        Q        L        _        D        D

The bits have been broken into the data bits (above) and the encoding bits below. The data bits are obviously good ol' ASCII here, and the encoding scheme is not too hard to see:

-Start with a zero encoding bit.
-Each time there is a zero in the corresponding data bit, and the previous data bit is zero too, switch the encoding bit to one
-Keep the value 'one' until the data bit is one, at which position change the encoding bit to zero

To read a byte offset from the beginning of the track address, the address is offset*2. Then take 8 bits, hopping over every second bit, and build the byte that way.

Again, reading the encoding bits is in no way needed for reading the HFE image. Writing the encoding is necessary when converting an IMG to the HFE.

Although I'm working on the same image all the time, let's remember the start point of the disk is not in any absolute location inside the track #0 data. It is better to seek the sector identifiers and the data blocks through the ID markers spread across the disk.

The information about disk data is in areas indicated by A1A1A1. The A1A1A1FB appears after A1A1A1FE, which is the track identifier.

SYNC byte, before Index Address Mark or ID Address Mark

SYNC byte, before Data Address Mark

The corresponding sync byte clock signals are not 'normal', and help make detecting the marks less ambiguous. This Atari ST site cleared a lot of things for me.

Inside one track, these can be found:

A1,A1,A1,FE, trk#,00,01,02,CRC,CRC
A1,A1,A1,FE, trk#,01,01,02,CRC,CRC
A1,A1,A1,FE, trk#,00,02,02,CRC,CRC

A1,A1,A1,FE, trk#,01,02,02,CRC,CRC
A1,A1,A1,FE, trk#,00,03,02,CRC,CRC
A1,A1,A1,FE, trk#,01,03,02,CRC,CRC

A1,A1,A1,FE, trk#,00,04,02,CRC,CRC
A1,A1,A1,FE, trk#,01,04,02,CRC,CRC
A1,A1,A1,FE, trk#,00,05,02,CRC,CRC

A1,A1,A1,FE, trk#,01,05,02,CRC,CRC
A1,A1,A1,FE, trk#,00,06,02,CRC,CRC
A1,A1,A1,FE, trk#,01,06,02,CRC,CRC

A1,A1,A1,FE, trk#,00,07,02,CRC,CRC
A1,A1,A1,FE, trk#,01,07,02,CRC,CRC
A1,A1,A1,FE, trk#,00,08,02,CRC,CRC

A1,A1,A1,FE, trk#,01,08,02,CRC,CRC
A1,A1,A1,FE, trk#,00,09,02,CRC,CRC
A1,A1,A1,FE, trk#,01,09,02,CRC,CRC

Look familiar? They are the sector IDs for the six Blocks within a Track.
Each sector ID is soon followed by a Data ID, which is then followed with 512 bytes.

A1,A1,A1,FB,[512 bytes of data],CRC,CRC

But now we also have something that wasn't present in the raw byte disk image at all: CRC values.


So, the HFE format project led me to the world of calculating Cyclical Redundancy Check values, which I found to be a huge topic in itself and won't discuss it too much here.

This site opened up to me the "easy" way to calculate the results and also warned about erroneous calculations. One problem with CRC is that an incomplete implementation may result in correct CRC in some cases, something which led me astray for a while.

This on-line calculator was helpful for comparing my results with different types CRC initial values.

The QL disk track ID I was looking at has the values A1A1A1FE00000102, which is the message for which I need the CRC, as the 16-bit CRC is stored after it. In this case the CRC was CA6F.

I toiled away with another Processing sketch and visualization to get results and a sufficient understanding on the topic. Although CRC is potentially very math-heavy, the process can actually be made simple with just throwing bits around and visualizing the thing until it gets right.

For the QL Floppy CRC I need to use initial value of 0x84CF to get what would be equal to results of "CRC-CCITT 0xFFFF direct":

The message is preceded with the initial value. After the message, as an augmentation, 16 zero-bits are added.

The above image is off but shows the principle.

The bits are churned by XORing the polynomial 0x1021 (in practice 0x11021) with the bits "above", bringing in an extra bit from the message/augmentation as it proceeds from "left" to "right". After the limit is hit at the "right edge", the value we are at is then the CRC.

Writing to an existing formatted HFE disk, the sector ID CRCs need not be overwritten, as their contents do not change. Should this be needed, then CRC the 8-bytes starting from the first A1, and then write the 16-bit result after the data.

With the 512-byte file blocks, the 516 bytes starting from the first A1 are CRC'd, then write the 16-bit value after the data. That's a helluva lot to CRC, and a poorly optimized routine (*cough*) can result in a fair amount of churning.

Whenever data changes, the encoding signals have to be regenerated. This is best done for the data areas, starting after the A1A1A1FB, with the initial bit value as 0. The encoding bits are written with the above-mentioned rules, up until and after the data block and the byte after the CRC value. (If you rewrite sector IDs and for some reason they change, the encoding bits have to be rewritten there too)

When writing the encoding bits, the whole track encoding could be calculated from beginning to an end. But when working on an existing formatted HFE image, I felt it was easier not to encode areas that don't need re-encoding, as then the anomalous sync signals within the ID portions do not need to be addressed.

Maybe I'll publish it, one day.