Robert Morrison

I experimented a bit more with creating an image to deliberately exploit the effect that a 50Hz alternating image has on my TV (and other upscaler chipsets).

Since the TV seems to display all the even lines of one frame, and all the odd lines of the other I thought I’d create a double-height image of 256x384. The source image is scaled down horizontally (so that it looks stretched) but that will be corrected when displayed at 256x192 because the de-interlacing effect scales down the image by half vertically (each row of the display is half a pixel high).

I exported the image as an (8-bit) 16-colour PNG, then ran it through my 8-bit to 4-bit conversion script that I’ve been using to convert sprites. I modified the script to export all the even lines to one file, and the odd lines to another file. (Each 128 bytes in the file represents one screen line, and the lines are ordered top to bottom).

I thought about just using one contiguous file and doing some processing on SAM but then I’d have to deal with a 48kb image file. The resulting files are basically a normal Mode 4 screen$ file, (just missing the palette data) so that keeps things straightforward.

To help further with moving the image around SAM’s memory I compressed the data using zx0. In this case it took the 24kb file down to 7113 bytes. The Z80 implementation of the decompressor is really fast and I use it to dump the two images directly into the respective frame buffers when the program starts up.

I don’t yet have a way of automatically mapping the palette from the PNG index to SAM’s format, so I just opened up the 16-colour PNG in SCADM’s handy image importer and copied the palette entries from there. (The order was wrong; I’m not sure how my image editor assigns the colour indexes so I just reordered them by hand).

I’ve started using Simon Owen’s pyz80 extension for VS Code which provides a wrapper around Andrew Collier’s pyz80 assembler as well as Simon’s samdisk tool for manipulating disk images. So now with a keyboard shortcut the code is assembled with pyz80, and samdisk creates an auto-booting disk image as well as broadcasting the assembled binary to my SAM listening on the local network. The TrinLoad softaware running on SAM recieves the code and launches it. Here’s how the resulting image looks on the TV:

It definitely works to smooth out certain things—like the curvature of the earth, the top of the space helmet or Sonic’s quills (compare that to the stair-stepping inside Sonic’s ear for example):

I noticed I had to load the even lines in to the first buffer; the other way around incorrectly interlaces the images and results in visible comb artefacts:

But otherwise I think it’s a neat effect. What do you think?

Here’s a disk image if you’d like to try it out: image-fun.mgt

Tonight I’m mostly using @shieladixon’s wonderful MIDI interface for RC2014 to take a closer look at how serial Networking is implemented on the SAM Coupé. (TL;DR it’s MIDI).

SAM uses DIN-7 connectors but the sockets are compatible with DIN-5 (MIDI).

The RC2014 MIDI Interface Z80 Framework gives straightforward access to the raw bytes. I’ve noticed that my USB-MIDI adapter (also pictured but not in use here) automatically translates the bytes into “standard” two- or three-byte MIDI messages (usually by injecting extra control bytes in an attempt to try to make musical sense out of non-musical data).

The data structure is similar to how ZX Spectrum BASIC programs are stored. Header bytes give file type and file name etc, the BASIC keywords are tokenised and variable names and values are tacked on at the end.

Meanwhile, in the laboratory: floppy head alignment issues, some Olympic-level desoldering, a disk controller transplant, and a hasty Shugart-to-Citizen bodge-it, but eventually… Pang! ✌️🎈

💾 #SAMCoupé