To my knowledge no SAM software uses it, so it’s remained near to the bottom of my SimCoupe ToDo list for many years. I made do with a dummy implementation, returning zero over the main screen and 255 during the border. Though a bug in the border test meant even that functionality was broken, so port reads have always returned zero!

Velesoft recently released a SAM-mouse enhanced version of the Spectrum title Galactic Gunners. It uses the ATTR port to synchronise drawing with the top of the main screen, and the broken SimCoupe implementation caused sprites in the upper 2/3 of the screen to flicker. In this case fixing the border test bug cured the flicker, but full ATTR support was needed to ensure other titles behaved correctly.

The SAM Technical Manual contains some details of SAM’s ATTR port behaviour:

This register enables the programmer to read the attributes of the currently displayed character cell in modes 1 and 2, and the third byte in every four displayed in modes 3 and 4.

There’s no mention of what happens in the border, thought a quick test was enough to show it didn’t match the Spectrum’s behaviour. In fact it seemed to only return attribute bytes from the main screen. Time for a test program! My usual approach with these tests is to make whatever I’m probing as visible as possible, so the emulation will only match the real thing once everything is perfect. In this case I used a tight loop reading from the ATTR port and writing the result to CLUT entry 0:


ld hl,loop
ld bc,&00f8
loop:
in a,(255)
out (c),a
jp (hl)
 


This code must be run with interrupts disabled, and started from a fixed position in the frame to ensure it’s the same on each run. Both are most easily achieved by placing the code at the IM 1 handler address of &0038 and using a HALT to guarantee the current instruction is a fixed 4 tstates when the interrupt handler is invoked. The 4-cycle rounding from the HALT opcode fetch ensures the test begins on the same frame cycle each time.

To make the most of the test output I created a test pattern containing a range of colours, and interleaved with columns of palette colour 0 where the test colour would show through. Here’s what I came up with:

And here’s what it looks like on SAM running in screen mode 1:

The time between the port read and the palette write causes the output to be shifted a few screen blocks to the right of the main screen position, reaching into the right border area. The screens above were taken with the SimCoupe border area set to Complete, to show what would be seen if the ASIC generated the display over the full frame. This doesn’t happen on a real machine but is useful to see video changes outside the visible TV area.

The stripes on the main screen and the jagged edges in the lower border are caused by the loop timing not being an exact multiple of the 384 tstates per display line. The actual timing is complicated by the display memory fetches, mode 1 contention delays, and ASIC port I/O delays, but if you look closely you can see three repeating line end positions.

If SAM’s border behaviour matched the Spectrum, the border colour should be bright white (colour 127, since the top bit is not used) everywhere except to the right of the main screen where the colour bleeds from the main screen. To the left of the main screen the colour is actually off-white (colour 120), which matches the right-most attribute on the scanline — bright white paper with black ink is 01111000 binary, 120 decimal.

To test the right-most attribute observation with the lower border I added a bright white paper with white ink (01111000 binary, 127 decimal) block to the bottom right of the screen. As expected this caused the lower and upper border to be coloured bright white. So during the border areas SAM was returning the last attribute value fetched to draw the main screen area.

As a further test I coloured the screen attributes red, set the screen-off bit to disable the display, coloured the screen attributes green, then read from the ATTR port. As expected the port returned the red colour, since that was the last screen byte the ASIC read when drawing the display. Here’s the BASIC code for the test:

10 PAPER 2 : BORDER 2 : MODE 4
20 BORDER 4 : OUT 254,132 : PAPER 4 : CLS
30 PAUSE 5 : PRINT IN 255 : REM should be 34 for red
40 BORDER 0
 


Once the port behaviour was understood the SimCoupe implementation could be enhanced. When the port is read it uses the current raster position to determine the last on-screen location that the ASIC would have read, and the memory address of the screen data (which depends on the current screen mode). The existing mode-change ASIC artefact implementation did a lot of this already so the same code could be re-used.

An additional complication is the value returned when the display is disabled, which may no longer be part of the current display. It requires the ATTR value to be determined when the screen goes from enabled to disabled, giving a value to return for as long as the screen remains disabled.

The test program and source code are available for download (9K). Pressing the NMI button returns you to basic, allowing the screen mode/contents to be changed to see different patterns. Don’t forget that it won’t work in SimCoupe until the next release!

The new interface is a simplified version of the original Atom HDD interface, and is now primarily for Compact Flash use. The Atom Lite uses an ATA feature for 8-bit data accesses, rather than normal 16-bit IDE mode, avoiding the need for half the data to be latched inside the interface. The change simplifies the design and allows faster data transfers – the next data byte is now fetched with a single IN, rather than having to select the high or (latched) low address first. Streamed media playback anyone?

The new interface requires updated B-DOS and HD-BOOT ROM versions to select 8-bit mode, but once set it’s software compatible with the original interface. Data can be read from both &F6 and &F7 ports as before, despite no latching being involved this time. However, the change does means the byte order of the Atom Lite media is reversed (or perhaps un-reversed!) compared to the Atom, which returned the high byte first. Fear not, existing Atom media can be converted to use Atom Lite byte-order using SamDisk!

The changes to SimCoupe were mainly to the ATA emulation, with enhancements to support 8-bit data mode and 28-bit LBA sector addressing. The latter allows support for devices beyond the 8GB CHS limit (16383 cylinders, 16 heads, 63 sectors), extending the maximum size to a whopping 137GB. Even an 8GB card would contain almost 10,000 B-DOS records, which could easily contain every SAM software title ever written! The Atom Lite implementation is just a cut-down version of the existing Atom C++ class, which has been further simplified as part of the same changes.

The SamDisk changes were also fairly trivial, especially as there’s no ATA emulation to worry about. The byte order of the media is determined by examining the BDOS signature at offset 0xe8 in the first record (which follows the boot sector and record list). With the original Atom (seen as “DBSO”) data accesses must be byte-swapped after reads and before writes. This allows all record-level commands to work transparently on both media. A new command-line option (/bs) forces byte-swapping of entire images, used for the Atom <-> Atom Lite conversion mentioned above. Simply read the device to an HDF image using the byte-swap option, then write the converted image back to the original device.

The Atom Lite 2.x boards are expected to include a Dallas clock chip, with registers access through the same floppy 2 ports. SimCoupe support will be added once the details have been confirmed…

Video is recorded in either half size or full size modes, with the latter needed to preserve mode 3 hi-res pixels. Half size mode defaults to storing the odd pixels for the best quality in SAM BASIC, but even pixels can optionally be used instead. Full size mode also respects the scanline option and intensity, so it should look the same as when using the emulator. Only the 5:4 mode is ignored, as AVI doesn’t support aspect ratios, and proper smooth scaling of the image can’t be done due to the limited 8-bit video format.

Audio is stored in the same 44.1KHz 16-bit PCM format as the separate sound recording feature. Unfortunately there aren’t any widely supported lossless codecs I can rely on, so the sound data remains uncompressed. This requires 3528 bytes per frame, adding a steady 172K/s to the recording. Of course, post-processing the audio stream into MP3 format reduced the file size without impacting the video quality.

The recording framerate uses a simple 1:n method to decide which frames to store, giving framerates of 50fps, 25fps, 16.67fps, … down to 1fps. Key frames are stored every 5 seconds to give faster seeking during video playback, and allow catch-up if the decoder is struggling to keep up (possible with full-size 50fps videos on slower systems).

As with GIF, only the differences are stored between most frames. MS RLE includes a “00 02 xx yy” GOTO sequence to skip up to 255 pixels on both horizontal and vertical directions, to position at the next change point. Identical frames are stored as a 2-byte 00 01 sequence, adding 10 bytes to the recording including chunk headers. Not as effecient as GIF but much better than most traditional video codecs.

Here’s a 2.4MB sample video of the first level of Manic Miner. It was recorded in full resolution (576×480) at 25fps, with sound post-processed into 192Kbps MP3 using VirtuaDub:

1. Sound recording

   This was very easy to do as the data is already in PCM format ready to be written to a wave file. I simply write the RIFF/WAV header, append each new frame of PCM data, then seek back and write the final block+data lengths in the header before closing the file.

   Wave files were the obvious choice for export as they’re universally supported and can always be converted/compressed for other uses. It would also be relatively easy to export through a codec under Windows, to write directly in a different format, but that’s something for a future version.

   I currently record only the SAA 1099 sound output, as that’s the only readily available source of sound chip data. SimCoupe use hardware mixing (if available), so I don’t have access to the fully mixed stream (SAA, beeper, DACs and tape). The core is being changed to use software mixing instead, and full recording support will be available once that is done.

   Sound recordings can optionally have silence trimmed from the start and end, as that’s something users will typically want. Another option allows recordings to be split into separate files, if there’s a enough (user-definable) silence between them.

   Here’s a sample recording of the Sophistry music, converted to MP3.

2. Video recording

   The plan is to write AVI files with a hand-coded MRLE encoder, using Microsoft’s Run-Length Encoding format. It’s a simple format, and seems reasonably well supported on different platforms. MRLE supports up to 256 colours (we need only 128), and the run-length encoding is very well suited to the our simple images.

   That is still the plan, but I got side-tracked before I completely finished it! I was inspired by the animated GIF recording in the SPIN Spectrum emulator and decided to implement that in SimCoupe before AVI. GIF is ideal for use on web pages, and the LZW compression is again well suited to our clean images.

   GIF supports sub-image updates, so only the smallest change rectangle needs to be drawn between similar frames. Transparency allows the re-use of colours from the same position in the previous frame, cutting the size down even further. However, care does need to be taken when deciding between transparency and a solid colour, to maximise the run lengths for LZW to compress.

   Before each frame image is a block defining how long the frame should remain visible. As well as controlling the overall animation speed, this allows us to store neighbouring identical frames for free. You simply increase the delay by 20ms for each identical display frame.

   For smooth animation the recordings should ideally use full (50 fps) or half (25 fps) framerate. Firefox plays these perfectly, but Internet Explorer and Opera limit the animation speed to around 15 fps. Faster animations are simply played in slow motion, rather than skipping frames to maintain full speed. For this reason I’ve included an option to set the framerate, so 16.66 fps (1 in 3 frames) can be used when IE support is needed.

   I’ve also included a feature that can help record repeated sections, to be played over and over with the GIF loop feature. Recording starts after the next change of image, and continues until the changed image is seen for a second time. It’s perfect for preserving the flash attribute (see reset screen below), or repeating sections in games or demos (see the SAM Juggler image below).

   The output GIF sizes are very respectable, but a decent GIF optimiser should be able to squeeze them down further. The images I create include a full SAM palette of 128 colours, as I’ve no idea which colours will be used during the recording. The palette in optimised images will typically include only used colours, reducing the LZW token count and the final compressed size. However, forcing the optimiser to use the original palette may give a larger file than my original!

   The following GIF animations were recorded by SimCoupe. The first shows a few lines of BASIC being entered, the second is the first 3 levels of Manic Miner, and the final one is a looped section from SAM Juggler. As they are all recorded at 25 fps, I’d recommend viewing them using Firefox:

   

   The final sample is what you see when holding in the SAM reset button. It’s a mode 1 view of RAM page 0, which is where the system variables are stored. The Spectrum-style flashing attributes alternate every 16 frames (320ms), which is perfect for a simple 2-frame looping animation. And at only 3.125 fps even IE can manage to display it at the correct speed!

   

I first had to build libspectrum for Win32, which isn’t an officially supported target platform. Building with Cygwin did work, but the stand-alone DLL was over 600K! A few code tweaks later I managed to build it as a Visual Studio 6 project, resulting in a much more respectable 49K DLL (UPX-compressed).

The SimCoupe side of the implementation is only a couple of hundred lines of code. The libspectrum library supplies t-state timing information on when the next ear pulse is due, which is scheduled as a SimCoupe CPU event in the same way as interrupts. When the event fires I toggle the ear bit of port #FE, ready to be picked up by the loader edge detection. The timings do need an cycle-accurate machine emulation to work correctly, but we’ve had that for some time. The rest of the implementation is just tape image management, so the user can insert/eject images.

I’ve had a run through the dozen or so tape SAM tape images I’ve had on my HDD for years, and most work fine. The working ones include a couple of titles not yet available on World of Sam, which I’ll upload soon. The non-working ones are simply bad dumps, converted from poor quality VOC samples – I’ll redump these from my own tapes. I’ll also post a sam-users list request for other tape images, or for people to create images from any undumped titles.

The tape support is still pretty basic, with insert/eject/play/stop functions, and auto-play if the tape is inserted at the startup screen (exactly like auto-boot for disks, but pressing F7 instead of F9). I’ll add a tape block browser soon, so you can select where to play the tape from on compilation images. There’s probably not much demand/use for save support, so that will be completed last.

I’ve not looked at accelerated loading yet, but most (if not all) loaders call the edge routines in uncontended ROM, so a single solution should fit almost every SAM title. In the meantime you can use SimCoupe’s turbo feature to zip through the slow loaders (unless you’re like me and enjoy watching them!).

Perhaps a bigger reason to add tape support is the mass of Spectrum software that exists in the format. SimCoupe has no problem using Spectrum tape images, but I’m a little worried at how well they’ll work. If you were a SAM owner in early 1990s you’ll remember the problem of loading Spectrum titles on the SAM. Even if the timing values in the loaders were adjusted for the CPU speed difference, the fully contended RAM would break most custom loaders, with turbo loaders suffering most.

The Spectrum Emulator utility on the original SAM demo tape/disk was able to handle a selection of specific Spectrum loading schemes, and that should work just as well in SimCoupe. I’m also hoping that the exact timings on the tape images will give more reliable loading than using a cheap tape recorder back in 1990, to improve reliability. There’s also some scope for applying a compatibility scaling to the t-state tape timings, to better match SAM CPU speed.

I’m considering adding support for native loading of Spectrum snapshots (z80/sna/szx/etc.), as libspectrum provides support for those too. Unlike the old Spectrum support in SimCoupe, it would be done in a 100% faithful SAM way without pretending to be a Spectrum emulator. This would probably involve loading a Spectrum or skeleton ROM at address 65536, with the 48K snapshot following it, and resuming it using the CALL MODE 1 mechanism.

Just for fun, here are a few screenshots of the loading in action:

Defenders of the Earth is a mammoth 21 minutes and 51 seconds long, which certainly makes you appreciate the disk version!

The Mac version of SimCoupe started with the 48×48 Windows XP icon scaled up to 256×256, which looked very out of place along side the 3D icons used by other applications. I wanted a decent new icon for the SimCoupe 1.0 release but didn’t have the artistic talent to draw my own. Rendering a 3D version seemed the way to go, so I downloaded the free Blender package and got started.

Creating the basic robot shape wasn’t too difficult, with simple hemispheres for the head, body and feet. The eyes and aerial were bezier curves pulled into shape and then filled. I was lucky enough to find a hand model in an animation tutorial, which saved me a lot of work creating my own.

The neck, arms and legs were created using the screw tool. However, the arm segments were straight and needed to hang out from the body and round to the hands. Getting them to curve took weeks of experimentation, but was eventually solved using armatures. Inserting bones into the arms meant I could bend them to the shape I wanted in pose mode, with inverse kinematics (IK) doing all the work. It’s not perfect, with a few kinks visible if you look closely, but it’s good enough!

To ensure the robot was symmetrical I built only the left half, with the right half created by cloning and mirroring it. The images below show the left half as wireframe and filled, and the completed robot in wireframe mode. (click for full size):

The final step was lighting, and I found another tutorial to help with that. I used standard positions to evenly light the scene, knowing they could easily be changed later to fit any user interface guidelines for icon lighting. The render took only a couple of seconds, and was saved out as a PNG image, preserving transparency where needed.

Here’s the final 256×256 image:

At this point I created the Mac icon, importing directly from the PNG render to create the .icns file. For the Vista version I needed to merge the new icon into the existing SimCoupe icon file, so the OS could choose which one to use. XP wouldn’t recognise the new format and fall back to using the original smaller versions, which was perfect.

Rather surprisingly Vista uses the PNG format to store the new icon images in the file, and for a 256×256 32-bit image that meant a huge space saving compared to the old format. This downside was that none of the existing tools would recognise the new icon format, and that included the resource compiler used to build the SimCoupe executable! A 3rd party tool (ReplaceVistaIcon) came to the rescue, allowing the new icon to be injected into the executable after the build.

Here’s how the new icon compares to the original 48×48 XP icon, using Vista’s large-icon view (click for full size):

Vista doesn’t use the new icon for everything though, falling back on the old icon in some situations (including the task list). Hopefully that’s something I can improve as I learn more.

1. Avoiding touching the primary display surface

   SimCoupe uses a video overlay surface for the SAM display by default, which gives the best performance on old video cards. For this I must determine a colour-key value where overlay pixels should show through to the display, like green-screen special effects used on TV. This meant locking the primary surface to peek a pixel value, and that’s something Vista wasn’t happy with me doing.

   In previous versions of Windows the primary display surface was what you saw on your screen, and where most objects were drawn directly. Vista’s Aero interface uses off-screen compositing for its fancy scaling and transparency effects. The visible display is managed by the compositing engine and is off-limits to direct manipulation. Any attempts to do so disables the Desktop Window Manager (DWM), returning the display to a compatibility mode. As part of this it also rather unhelpfully reports: “This program is not compatible with Windows“!

   Video card overlays don’t really fit into the new composite world anyway. They can be scaled, but they can’t be rotated or skewed, and don’t support transparency. The DWM can’t make any use of them, so there’s little point in us trying to use them – problem solved!

   SimCoupe no longer attempts to create a video overlay on Vista, and to avoid any confusion I also grey the setting in the options used to toggle it on and off.

2. Avoid querying the capabilities of the primary display surface

   This is related to the first issue, but shouldn’t have been a problem at all. I found that simply querying the capabilities of the primary surface (using GetSurfaceDesc()) was enough to disable the DWM.

   This was confirmed to be a Windows bug in beta 1, scheduled to be fixed in beta 2. In the meantime I changed my code to work around it, using the required capabilities from the back surface instead.

3. Double-checking the main window is the correct size

   The partial scanlines on the boot screen were showing a banding effect, which happens if the main window is resized to non-multiple of the natural display size. Further investigation showed the main window size (as set using AdjustWindowRect()) was slightly too small.

   This was yet another Windows bug, and not one I found documented anywhere! The size calculations didn’t seem to be including all the extra window decoration and the larger Vista borders were throwing it out. This just required a second size adjustment in SimCoupe if the first one was found to be wrong. This problem affected other programs that required an exact display size, which was mainly other emulators.

These changes were the bare minimum needed to run the program correctly under Vista. True Vista support will require additional changes, almost all related to the tightened security model. More about those in a future update.

1. fdrawcmd.sys is almost unchanged since the 1.0.1.9 release in May, as there’s been nothing much to do. I’ve no outstanding issues to fix, and only a minor enhancement that wasn’t worth a new release.

   I’ve been working on improving the driver installer, which will use the same NSIS setup as SimCoupe instead of my small custom installer. This will give a more traditional install/uninstall process and include both 32-bit and 64-bit drivers in one download. I’ll release a new version once it is complete, even if the embedded drivers don’t get updated from the previous release.

2. SimCoupe is also due a refresh build in the next month, mainly to improve Vista support. I’ve done some minor enhancements and fixes to the main code branch, but only enough to make it version 1.01 rather than 1.1.

   I’ve made a start to bigger changes in a code branch, which largely involves separating the emulation+sound from the UI+video processing. This should hopefully eliminate the occasional sound glitches from moving things over the main window, etc. It should also do more to spread the workload on multi-core CPUs. I also have some fragments of other features, including movie and sound recording.

3. SamDisk has been neglected for a few months, despite having been close to a release for a while! I’m happy with the core functionality, which does an excellent job with copy-protected and custom formatted disks (right to the limit of the PC controller’s ability). I’ve still not decided on the list of disk image formats for the initial version, but it’ll certainly include EDSK, MGT, TRD, D81 and BPB (for normal PC disks).