🧛 Vampire V4 and V4+: The Survival Guide

A black screen, an unreadable CF card or a failed core update can have very different causes. Start with the symptom, make one change at a time, and check the result before moving on.

This guide covers the Vampire V4 and V4+ Standalone only. It distinguishes the standard machine from systems fitted with an Ultimate Expansion Board, and separates ApolloOS instructions from AmigaOS 3.x instructions. Use the hardware, firmware and OS instructions for your exact Standalone configuration.

🛡️ Before you start: Keep the original CF unchanged and use a spare for experiments. Writing a disk image replaces the destination's contents. Formatting, partition changes and firmware flashing are separate operations, each with different consequences.

🧭 Find your symptom

🧩 Keep these five components separate

SAGA is the graphics/chipset implementation. Native screens are the Amiga display modes used by many games and boot screens. RTG provides graphics-card-style desktop modes; the AmigaOS setup uses P96/Picasso96 and the SAGA RTG driver. ApolloOS does not use that same AmigaOS driver installation.

⌨️ Open the right command window

Run commands one at a time unless a numbered step specifically supplies a complete block. Replace example paths and device names before running them. Quotes around a path keep spaces within that path. A command's error is a reason to stop that procedure and resolve the error.

On the V4, SYS: is the current boot volume; S: holds startup scripts, C: commands and DEVS: drivers/configuration. RAM: is temporary and disappears when power is removed. A backup in RAM: is not a recovery copy.

📝 Record the configuration before changing it

1. Photograph the enclosure label. Record the model, installed RAM and expansion board from the purchase details or board markings. Remove power before opening an enclosure to read markings.
2. On AmigaOS 3.x, open Workbench → About and record the Kickstart and Workbench versions. On ApolloOS, record the exact image/release name you installed and the desktop's About information. A generic AROS version is not the ApolloOS image's release identifier.
3. Open a Shell and run these read-only checks on either OS:

Version
Avail
Info
Assign

1. Photograph or save the results. Avail reports the OS memory pools, Info reports mounted volumes, and Assign shows name mappings. They do not identify every physical hardware detail.
2. Query an installed utility by its actual filename. For example:

Version C:VControl FULL
Version C:ApolloFlash FULL

1. On an AmigaOS SAGA installation, inspect relevant files individually where they exist:

Version DEVS:Monitors/vampiregfx FILE FULL
Version DEVS:Networks/v4net.device FILE FULL

1. Distinguish a file's version from the currently loaded component. For a device already in use, Version v4net.device FULL can query the loaded device; the full-path command with FILE inspects the file on disk. A “no version information” or “not found” result is something to record, not a reason to install a replacement blindly.
2. If VControl is installed, C:VControl CORE and C:VControl CPU provide useful status. Keep the original JIC filename and flashing log too: core strings can remain stale after JTAG programming. Do not run these names as if they were ApolloControl syntax.

To save a command's output, redirect it to a new text filename, for example Info >RAM:V4-volumes.txt, then copy that file to a mounted transfer card before powering off. Redirection replaces an existing file of the same name.

📝 Back up, edit and restore a startup file

Do this on the spare CF whenever possible. These file commands work in AmigaOS and ApolloOS; the editor's interface depends on the installed program.

1. Open a Shell. Inspect the file before changing it:

Type S:Startup-Sequence

1. Create a uniquely named backup on the boot volume, then check that it exists. Choose another suffix if this backup already exists:

Copy S:Startup-Sequence TO S:Startup-Sequence.before-test CLONE
List S:Startup-Sequence.before-test

1. Keep a separate copy of that backup on transfer media as well. For S:User-Startup, substitute that filename in both places; if it does not exist, record that instead of treating it as a failed backup.
2. On AmigaOS 3.x, open the file with Ed S:Startup-Sequence. Move to the suspect command and put a semicolon (;) at the start of that line only. To save and exit ED, press Esc, type X, then Return. To abandon the edit, use Esc, Q, Return and confirm quitting without saving.
3. On ApolloOS, open its supplied text editor and use Open to select S:Startup-Sequence. Make the one-line change and save as plain text to the same path. If its Ed is the compatible editor, the command above is also usable; do not assume another editor has ED's keyboard shortcuts.
4. Reopen or Type the file to check the saved line. Leave IF/ENDIF structure and unrelated ROM/bootloader commands intact.
5. Finish writes, restart and repeat the original failing action. If the change did not help, restore the backup:

Copy S:Startup-Sequence.before-test TO S:Startup-Sequence CLONE

1. If the edited system no longer starts, enter Early Startup and choose Boot With No Startup-Sequence, then run the restore command there. If booting from another disk, S: points to that disk: identify the affected volume with Info and use its explicit path, such as AffectedSystem:S/Startup-Sequence, for both source and destination. Replace AffectedSystem: with its actual volume name.

Use the same backup/edit/restore method for an existing launcher or WHDLoad script, substituting its real path. Do not edit Amiga startup files in a word processor that adds formatting.

🏷️ Change one icon tooltype and undo it

1. Locate the application's icon. For the AmigaOS RTG driver, open SYS:Devs → Monitors and locate vampiregfx. For WHDLoad, use the game's launch icon.
2. Back up its .info file to a new filename outside the Monitors drawer before editing. Run MakeDir SYS:V4-backups only if that drawer does not already exist, then copy the file. Choose a different backup suffix if this copy already exists:

Copy DEVS:Monitors/vampiregfx.info TO SYS:V4-backups/vampiregfx.info.before-test CLONE

1. Select the original icon once. On Workbench choose Icons → Information; on an ApolloOS desktop use the corresponding icon Information action. Open its tooltype list.
2. Record the current entry. Add or edit only the named tooltype, without adding a duplicate. In the standard tooltype convention, an entry enclosed in parentheses is disabled: (NoAutoVec) is not the same as NoAutoVec.
3. Save, close and relaunch the application. Reboot for a monitor-driver tooltype. Run the same test that previously failed.
4. If it does not help, restore the prior entry or copy the backed-up .info over the original, then relaunch/reboot as appropriate. For the example above: Copy SYS:V4-backups/vampiregfx.info.before-test TO DEVS:Monitors/vampiregfx.info CLONE.

Only use a tooltype documented by that particular program. An icon-information window does not make AmigaOS driver options valid for ApolloOS.

🛡️ Preserve a recovery point

1. Record the configuration: board model, memory, core filename, OS release, drivers and any expansion board.
2. Make a whole-device backup image of the original CF, including the partition map and areas outside ordinary files. Use the backup procedure below.
3. Store the backup on another drive. Keep a separate copy of irreplaceable personal files where they can still be read.
4. Keep the previous core and its matching driver and utility packages.
5. Record whether the working setup uses the core's bundled ROM, a ROM mapped from disk, or a separately flashed ROM. For a separately flashed ROM, preserve the exact licensed source ROM file and the compatible flasher outside the V4, along with a spare CF that can boot the core's bundled ROM. A CF backup alone does not preserve a separately flashed ROM.
6. Photograph the first error or failed boot screen before changing anything.

⚠️ If the card produces read errors: stop ordinary write tests and repairs. Keep the card, recovery image and error log. An image made with unreadable sectors is a partial recovery, not a verified backup.

💾 CF cards and disk images

🛑 The host asks to initialise, format or repair the CF

Cancel the prompt. Windows normally cannot mount Amiga filesystems such as FFS, SFS or PFS3, and it may not recognise an Amiga RDB partition layout.

1. Windows: cancel Format/Initialise. macOS: choose Ignore in the unreadable-disk dialogue. Linux: close the unsupported-filesystem dialogue; do not accept a format/repair offer.
2. Follow the physical-device and capacity check for your host. A detected physical card and a mountable volume are different things.
3. If you have just written an image, open the writer's result/log and require both write and verification success.
4. To inspect the actual Amiga layout, back up the CF and use the read-only RDB procedure on an image copy.

⛔ Do not do any of the following to make the warning disappear:

• Do not initialise the CF in Windows.
• Do not run diskpart clean or clean all.
• Do not create an MBR or GPT partition table on it.
• Do not format a partition containing your Amiga installation.
• Do not accept an automatic repair without knowing what it will change.

diskpart clean removes partition information; it is not a repair for an Amiga disk. A raw-image restore does not require you to create a Windows partition first.

A writer may warn that an Amiga image has no recognised partition table. That warning needs checking against the image's intended format. An I/O error, interrupted write or failed verification is not the same thing.

🔎 The original CF had a Windows drive letter; the replacement does not

First find out whether Windows sees an existing, readable data volume with no letter. Assigning a letter can expose that volume in Explorer; it cannot make a native Amiga partition readable.

🪟 Assign a letter with Computer Management

1. Connect the replacement through the CF reader. Cancel any format or initialisation prompt. If it is a freshly written clone, complete the writer's verification before changing or browsing its contents.
2. Right-click Start → Computer Management, approve administrator access if requested, then open Storage → Disk Management.
3. Locate the CF by its disk number and capacity, using the physical-device check if needed. In that disk's row, inspect its individual volumes. Continue only for the expected exchange/data volume shown with a recognised filesystem such as FAT/FAT32, exFAT or NTFS and a healthy status. Do not select a Windows system, recovery or EFI partition.
4. If that volume has no letter, right-click the volume rectangle, choose Change Drive Letter and Paths → Add, select Assign the following drive letter, choose an unused letter and click OK. If it already has a usable letter, use that letter; it need not match the old card.
5. Open File Explorer → This PC, open the new drive and check for the expected files. Cancel a format prompt if one appears; assigning a letter has not established that the contents are sound.
6. To undo only this assignment, close Explorer windows and programs using the volume. Return to Change Drive Letter and Paths, select the letter you just added and choose Remove. This removes the Windows access path, not the partition.

🪟 DiskPart alternative — use this instead of the GUI steps

1. Open Terminal/PowerShell as administrator, then enter:

diskpart
list disk
select disk N
detail disk
list volume

1. Replace N with the CF's disk number. list volume lists volumes across the computer, so do not select by size alone. Identify the expected Windows-readable data volume associated with the CF, then enter:

select volume V
detail volume

1. Replace V with that volume's number. Check that detail volume identifies the correct physical disk and that the filesystem, label, size and missing letter match the intended exchange volume. If it is RAW, unknown or cannot be identified, enter exit and stop this branch.
2. Choose a letter that is not already assigned in the list volume output. The example below uses R; substitute another unused letter if necessary:

assign letter=R
list volume
exit

1. Require DiskPart's success message and the new letter in its listing, then check This PC as above. To undo the assignment, use the GUI removal step. Do not add clean, create, format or a partition-type change to this procedure.

If there is no eligible volume, or Add/Change Drive Letter is unavailable:

1. Leave unknown partitions, RAW volumes and apparently unallocated space unchanged. Windows may not understand an Amiga disk's layout; do not initialise it or create a volume in that space.
2. Identify what you wrote: your original card's whole-device backup or a newly downloaded OS image. A new image may contain only Amiga partitions and need not reproduce the old card's PC-readable exchange volume. Check the image's supplied partition description; use read-only RDB inspection for its Amiga layout.
3. For a clone whose full-image verification was skipped, write and verify the spare again from the preserved image. Do this before booting it or changing its contents.
4. Safely eject the card, install it with the V4 unpowered and test booting. If the verified image boots but has no Windows-readable volume, use the microSD transfer workflow for ordinary files.

If Windows does not detect the physical device at all: test the reader, USB connection and another card. Amiga partitioning explains an unreadable volume; it does not explain a reader that cannot detect media.

💾 Back up the original CF

Choose the subsection for your host: Windows, macOS or Linux. All three create an uncompressed whole-device image.

🪟 Back up a whole CF on Windows

Use USB Image Tool 1.91 for Windows, obtained from its author's project, with the CF connected through a USB card reader. Its Device Mode reads the whole device, including an Amiga partition layout that Windows cannot mount. A drive letter is not required.

1. Finish disk activity on the V4, switch it off fully and disconnect all power before removing an internal CF or adapter.
2. Extract the complete USB Image Tool package into a PC folder, keeping its accompanying files together. Open USB Image Tool.exe with administrator rights.
3. Connect only the CF reader needed for the backup. Cancel Windows format or initialisation prompts.
4. Choose Device Mode, not Volume Mode. Select the CF by the reader's identity and exact capacity, checking these against the Windows disk listing.
5. If Windows detects the physical card but it is absent from the tool, enable Show non-removable devices in Options and rescan. Recheck the selected device carefully; this can expose other USB disks. If it remains absent, test another reader. Do not initialise the CF.
6. In Options, enable Verify after Backup/Restore. Leave Truncate oversize images, Fix GPT after Restore and Initialize remaining space after restore disabled. These are not part of an Amiga raw-image backup or restore.
7. Click Backup. Save a new, uncompressed .img file on another drive. Select the ordinary image-file format, not .imz or .img.gz. The destination must have enough free space for the whole card and support a file that large.
8. Wait for both the backup and its automatic verification to finish. The verification compares the image with the source device; it is separate from calculating a checksum of the image file.
9. Check the Log for successful completion of both operations. Preserve any error instead of treating a full progress bar as success.
10. Use the image-size and SHA-256 checks to record the image's exact length and hash. An uncompressed full-device image should match the card's reported byte capacity.
11. Safely disconnect the original and put it aside. Restore the image to a spare CF and test that spare in the V4.

⚠️ Do not use Reset or Check device for size on the original card. Those functions write to the device. If the backup produces read errors, stop repeated attempts and preserve the error log and any recoverable image.

If Win32 Disk Imager already selects your card correctly, it remains an alternative: leave Read Only Allocated Partitions unticked and use Read to create the backup. The USB Image Tool procedure above supplies a complete backup-and-verification route when drive-letter selection fails.

🍎 Back up a whole CF on macOS

These commands read the CF into an ordinary image file on the Mac or another backup drive. Keep the card out of the V4 during the operation.

1. Follow the macOS identification steps. Record the whole disk identifier and byte capacity. In this example /dev/diskN means your identified CF, not a literal name to paste unchanged.
2. In Finder, choose a backup location on an APFS, Mac OS Extended or exFAT volume with enough free space for the entire CF. Select that destination volume and press Command-I to check its format and available space. Use a new image filename.
3. Close applications using the card, then unmount its volumes without ejecting the hardware:

diskutil unmountDisk /dev/diskN

1. Continue only after successful unmounting. Replace the destination path below with your backup location. /dev/rdiskN is the raw interface to the same numbered disk. The parentheses keep the overwrite protection local to this command:

(set -C; sudo dd if=/dev/rdiskN bs=4m > "/Volumes/Backup/V4-original.img")

1. Enter your Mac administrator password if asked; Terminal does not display password characters. Wait for dd to finish. Control-T can show progress without cancelling it. Immediately run echo $?; require 0 and no read/write error. An error leaves an incomplete image.
2. Check the image length with stat -f '%z' "/Volumes/Backup/V4-original.img". It must equal the recorded physical card capacity.
3. Keep the card unmounted and hash both the image and the whole source device:

shasum -a 256 "/Volumes/Backup/V4-original.img"
sudo shasum -a 256 /dev/rdiskN

1. Require both commands to finish without errors and their 64-character hashes to match. This comparison is valid because this backup covers the entire source card. Save the results.
2. Run diskutil eject /dev/diskN, disconnect the original and put it aside. Write the verified image to a spare and test that spare in the V4.

If Terminal reports a permissions error, check System Settings → Privacy & Security → Full Disk Access for Terminal, then reopen Terminal and identify the disk again. Do not replace the command with an erase or partitioning operation. Do not add conv=noerror to turn unreadable sectors into an apparently successful backup.

🐧 Back up a whole CF on Linux

1. Follow the Linux identification steps, recording the physical device and byte capacity.
2. Choose an existing backup directory on a filesystem supporting files as large as the CF, such as ext4 or exFAT. Check its filesystem and available space:

df -T -B1 "/home/yourname/Backups"

1. Close applications using the card. In the lsblk output, inspect every child partition with a mount point. Unmount each of those partitions individually, substituting its actual path:

udisksctl unmount -b /dev/sdX1

1. If udisksctl is unavailable, use sudo umount /dev/sdX1. Repeat only for other mounted partitions on this CF. Re-run lsblk and require their mount-point fields to be empty. If none are mounted, there is nothing to unmount.
2. Create the whole-device image using a new filename. Replace both paths:

sudo dd if=/dev/sdX of="/home/yourname/Backups/V4-original.img" bs=4M conv=excl status=progress

1. conv=excl refuses to replace an existing file. Wait for completion, then immediately run echo $?; require 0 and no I/O error. Do not add options to skip read errors.
2. Check the image length and compare it with the card capacity:

stat -c '%s' -- "/home/yourname/Backups/V4-original.img"

1. With the source still unmounted, compare the entire image and source card:

sudo cmp -- "/home/yourname/Backups/V4-original.img" /dev/sdX
echo $?

1. No comparison output and status 0 means identical contents. Status 1 means a difference; 2 means an error. Require the image length to match the card capacity as well. Record the image's SHA-256.
2. Use udisksctl power-off -b /dev/sdX or the desktop's Safely Remove action, then disconnect the original. If the reader does not support power-off, finish the read operations and ensure all its volumes are unmounted before unplugging. Restore to a spare and boot-test it.

On AmigaOS/ApolloOS: copying drawers is useful for personal-file backups but is not a whole-CF image. For a recoverable system snapshot, power down and use one of these host workflows.

📦 Extract the image and diagnose extraction errors

Extract system images on the host computer, onto a drive that can hold the complete result. FAT32 cannot hold a file larger than 4,294,967,295 bytes. Space on the Amiga CF is irrelevant to this step.

Windows

1. In Explorer, open This PC, right-click the destination drive and choose Properties. Check File system and Free space. For a large image use an existing NTFS or exFAT destination; do not reformat a populated drive just to extract a download.
2. Put the archive and every numbered part in one folder. Install 7-Zip from its author's project if needed.
3. Open 7-Zip File Manager, browse to the archive and select it. For a split 7z archive, select .7z.001; for a split RAR, select .part1.rar or the initial .rar, according to its naming scheme.
4. Choose Test. Missing-part, CRC or data errors must be resolved before continuing.
5. Choose Extract, select a new destination folder on the suitable drive, and wait for completion without errors.

macOS

1. In Finder, select the destination volume and press Command-I. Check Format and Available space. APFS, Mac OS Extended and exFAT can hold large images; FAT32 cannot.
2. For an ordinary ZIP, double-click it to use Archive Utility. For 7z/RAR or split archives, install Keka and place every part together.
3. Right-click the archive's first part and choose Open With → Keka. For .7z.001 sets, open .001; do not extract every numbered part separately.
4. Use a destination on the suitable volume. If the extractor writes beside the archive by default, move the complete archive set there first.
5. Wait for successful completion. If it reports a missing part or damaged archive, retain the message and replace the missing/bad download before retrying.

Linux — GNOME Archive Manager

1. Open Terminal and check the existing extraction directory, replacing the path:

df -T -B1 "/home/yourname/Downloads"

1. Check its filesystem and Available bytes. An ext4 or exFAT destination is suitable for large images; vfat/FAT32 has the single-file limit above.
2. Open the archive or first split part in Archive Manager. Choose Extract, select a new destination folder and extract all contents.
3. If that format is unsupported, install the archive backend offered by your distribution's software manager or use its packaged 7-Zip. Do not concatenate compressed parts or rename them to .img as a workaround.
4. Check for extraction errors. If using the 7-Zip command-line package, run 7zz t "archive.7z.001" to test it and 7zz x "archive.7z.001" -o"extracted-image" to extract to a new folder. Use 7z instead only if that is the executable your package installs.

Finish on any host

1. Locate the actual extracted image. A ZIP containing another archive still needs that inner archive extracted.
2. Check its exact byte length against the download description, then check any supplied SHA-256.
3. If there is no published checksum, retain the calculated hash as a baseline and require the later card-write verification to pass.

Do not format the Amiga CF to solve an extraction error. For Amiga application archives, preserve the archive and use the native extraction procedure instead of unpacking the program on the host.

📏 An image will not fit another card with the same advertised capacity

Compare the extracted image file's length with the whole destination device's capacity, both in bytes. A partition's free space and the size printed on the card are not the measurements you need.

Windows — PowerShell

1. Disconnect other removable disks. Open Start, type Windows PowerShell, right-click it and select Run as administrator.
2. Before connecting the CF reader, run the following command. Connect the reader with the destination card, cancel formatting prompts, then run it again:

Get-Disk | Select-Object Number, FriendlyName, SerialNumber, BusType,
    Size, LogicalSectorSize, IsBoot, IsSystem | Format-List

1. Identify the newly appearing physical disk. Match its reader, approximate capacity and serial number where available. Record its Number and Size. Stop if its identity is uncertain or it is marked IsBoot : True or IsSystem : True.
2. Run this block and enter the full path to the extracted .img or whole-disk .hdf, without surrounding quotes:

$imagePath = Read-Host 'Full path to the extracted image, without quotes'
$imageFile = Get-Item -LiteralPath $imagePath -ErrorAction Stop
if ($imageFile.PSIsContainer) { throw 'Choose a file, not a folder.' }
$imageFile | Select-Object FullName, Length | Format-List

1. Compare Length with the disk's Size. Both numbers are bytes. The destination must be at least as large as the image.
2. Re-run Get-Disk after any reconnection; the disk number can change. A drive letter is not required.

macOS — Terminal

1. Open Applications → Utilities → Terminal. Run diskutil list external physical before and after connecting the CF reader. If macOS reports an unreadable disk, choose Ignore.
2. Identify the new whole disk, such as /dev/disk4. Do not select a partition such as /dev/disk4s1. In these examples, replace N with the number you actually found:

diskutil info /dev/diskN

1. Check the device/media name, external connection and Whole: Yes. Record the exact byte count in Disk Size; do not use only the rounded GB figure.
2. Type stat -f '%z' , including the trailing space, then drag the extracted image from Finder into Terminal and press Return. Alternatively, replace the example path below:

stat -f '%z' "/Users/yourname/Downloads/ApolloOS.img"

1. The number printed is the image length in bytes. Compare it with Disk Size. If it is greater, use a larger card.
2. When finished inspecting, eject the device with diskutil eject /dev/diskN before unplugging it.

Linux — Terminal

1. Open Terminal and run the following command before and after connecting the CF reader:

lsblk -b -o NAME,PATH,SIZE,TYPE,TRAN,MODEL,SERIAL,MOUNTPOINTS

1. Identify the new row with TYPE disk and the expected reader and capacity. A USB reader commonly appears as /dev/sdb; /dev/sdb1 is a partition. Replace /dev/sdX below with the whole device you identified.
2. Ask the block device for its capacity in bytes:

sudo blockdev --getsize64 /dev/sdX

1. Obtain the extracted image's byte length, replacing the path:

stat -c '%s' -- "/home/yourname/Downloads/ApolloOS.img"

1. Compare the two integers. The first must be equal to or greater than the second. If MOUNTPOINTS is unsupported on an older system, use MOUNTPOINT in the listing command.
2. Use the file manager's Safely Remove/Eject action when finished. Device names can change after reconnecting.

AmigaOS / ApolloOS

1. Open a Shell and run Info to see the mounted volumes and their used/free space.
2. Use that output to answer “is this volume full?” It does not give a dependable measurement of the entire physical CF, including unpartitioned space.
3. For an image-fit decision, finish writes, power off, remove the CF safely and use one of the host procedures above. Do not attempt a raw restore over the mounted system from which the V4 is running.

Interpret the result: if the image is even one byte larger than the destination, it does not fit. If it fits but the writer still refuses, confirm that you selected the whole device and the fully extracted image, then record the writer's exact error.

Two cards sold as “128 GB” can expose different capacities. 128,000,000,000 bytes is about 119.21 GiB; the change of units is normal. Do not truncate a whole-card image: seemingly unused bytes can lie inside a partition or contain filesystem structures.

🔐 Calculate and compare a file's SHA-256

Use this for an archive, extracted image or ordinary test file. Check the same file named by the published checksum; an archive and its extracted image have different hashes.

1. Open PowerShell on Windows or Terminal on macOS/Linux.
2. Run the command for your host, replacing the path with the actual file:

Windows:

Get-FileHash -LiteralPath 'C:\Images\ApolloOS.img' -Algorithm SHA256

macOS:

shasum -a 256 "/Users/yourname/Downloads/ApolloOS.img"

Linux:

sha256sum -- "/home/yourname/Downloads/ApolloOS.img"

1. Wait for the command to finish without a read error. Compare all 64 hexadecimal characters with the trusted checksum or with your earlier saved result. Letter case does not matter.
2. Save the filename, byte length and hash together in a text file. A mismatch means the contents differ; repeat the download or investigate the copy before using it.

A hash without a trusted comparison value records the current contents. It does not authenticate a download or verify a card write. For files copied through the V4, use the round-trip transfer test; it does not depend on a particular Amiga checksum utility being installed.

🖥️ The HDF boots in an emulator but not from CF

1. Copy the HDF on the host, then run the read-only RDB inspection on the copy. A readable RDB with partitions supports the whole-disk interpretation; “No RDB Disk” requires checking the supplied image description.
2. In the emulator's hard-drive settings, select that HDF entry and record its controller, any RDB/whole-disk mode setting and any supplied filesystem/geometry. Also record the selected Kickstart ROM. An emulator can provide a disk wrapper or handler absent from the V4.
3. Inspect an image copy with an Amiga-aware tool. Renaming .hdf to .img does not change its contents.
4. For a direct CF restore, obtain the whole-device image intended for that installation. Alternatively, follow the distribution's installation procedure to build a physical disk correctly.

uaehf.device belongs to a UAE emulator setup. A successful boot through it does not prove that the V4's real disk driver and boot ROM can reach the same data.

✍️ Write a replacement CF

⚠️ This operation overwrites the selected destination card. Disconnect the original CF and other removable drives before proceeding.

🪟 Write and verify on Windows

These steps use USB Image Tool 1.91 and an uncompressed whole-device image.

1. Prepare the image. Use the extraction procedure and confirm that the image is intended for your Standalone and OS arrangement.
2. Check capacity. Follow the Windows exact-byte comparison.
3. Open USB Image Tool with administrator rights. Choose Device Mode, enable Verify after Backup/Restore, and leave the truncation, GPT-fixing and remaining-space initialisation options disabled, as in the backup procedure.
4. Select the spare CF as the destination. Match its reader and capacity. Recheck the selection after reconnecting any device.
5. Start the restore. Click Restore, select the prepared image file and confirm the operation when prompted. This writes the image's contents to the selected card. Do not copy the image file into a folder on the card or create a new PC partition table first.
6. Wait for writing and verification. Leave the reader connected and let both operations finish.
7. Check the Log. Require successful completion of the restore and verification. A full progress bar is not enough; preserve any error and investigate it before booting.
8. Safely eject. Cancel any Windows formatting prompt. Use the taskbar's Safely Remove Hardware and Eject Media action for the reader and wait for permission to disconnect it. Do not remove it while the writer is active.
9. Install with the V4 unpowered. Boot the replacement and run the practical checks before changing partitions or installing updates.

If the writer cannot select the device or refuses the image, stop and identify why. Do not initialise the CF as a workaround.

🍎🐧 Write and verify on macOS or Linux

This route uses balenaEtcher with the already extracted, uncompressed whole-device image. Install the build for your host from the balenaEtcher project. The same sequence is also available on supported Windows systems.

1. Disconnect the original CF and other removable drives. Insert only the spare into the reader.
2. Complete the exact-size comparison for your host. Confirm that the file is a whole-device image intended for this V4/V4+ installation.
3. Open Etcher and choose Flash from file. Select the extracted image, not a partition-only HDF.
4. Choose Select target. Match the spare's reader, device identity and capacity with your disk listing. Leave every other device unselected.
5. If Etcher warns about an unrecognised partition table, recheck the distribution's image description. Proceed only when it is the intended Amiga whole-disk image; do not dismiss an unexplained warning.
6. Select Flash! and authorise the host's administrator prompt. The selected spare is overwritten.
7. Wait through both flashing and validation. Do not skip validation. Require the final success result; an error at either stage means the card is not ready.
8. On macOS, choose Ignore if the written Amiga disk is described as unreadable. On Linux, close any unsupported-filesystem prompt. Do not initialise or repair it.
9. If Etcher has not already ejected it, use Disk Utility/Finder's Eject on macOS or Safely Remove on Linux. Wait for completion before unplugging.
10. With the V4 completely unpowered, install the spare. Boot and carry out the practical checks.

On AmigaOS/ApolloOS: install and test the completed spare with power removed. Do not write a whole-device image onto the CF containing the currently running system.

🔍 Understand verification before interpreting a mismatch

For an image of N bytes, verification must cover the first N bytes of the card. Use Verify after Backup/Restore in USB Image Tool 1.91 or the validation phase in the Etcher procedure; the writer handles the image range. A whole-card hash from a larger destination cannot be compared directly with the shorter image's hash.

For an additional Linux read-only comparison:

1. Unmount the card's partitions as in the backup steps. Recheck its physical device name.
2. Set the image length, replacing the file path:

image_bytes=$(stat -c '%s' -- "/home/yourname/Backups/ApolloOS.img")
printf '%s\n' "$image_bytes"

1. Continue only if stat succeeded and printed the expected positive byte count. Use that same image path and replace /dev/sdX with the identified card:

sudo cmp -n "$image_bytes" -- "/home/yourname/Backups/ApolloOS.img" /dev/sdX
echo $?

1. No cmp output plus status 0 means those bytes match; 1 means a difference and 2 means an error. On Windows/macOS, the verified writer workflow above supplies the comparison without a custom raw-device script.

Run the comparison before the V4 boots or you edit the partitions. Also remember that Windows or another host program can modify a Windows-readable partition after writing or reconnecting the card. A later mismatch needs investigation; it is not automatically proof of defective media.

If verification fails:

1. Save the first error and any reported offset or sector.
2. Establish whether the failure occurred while reading the image, writing the CF or reading the CF back.
3. Recalculate the source image's SHA-256 and compare it with the value recorded before writing. Recheck its byte length if extraction was interrupted.
4. Check whether the card was mounted or used between writing and comparison.
5. Repeat on a spare with another known-good reader or connection, changing one item at a time.

Do not trust an unexplained mismatch for a system restore. A correct copy can still contain an unsuitable OS or a pre-existing filesystem error.

🗜️ A small download appears to occupy the whole card

Check four different measurements:

1. Archive size: select the download and open Properties in Windows, Get Info in Finder, or Properties in the Linux file manager.
2. Extracted image length: use the exact-byte command for your host on the extracted file.
3. Allocated partitions: run the RDB inspection on an image copy. Record the partition sizes and ranges.
4. Used/free space inside the V4 volumes: open an AmigaOS/ApolloOS Shell and run Info. Find the volume by its name, then read its Used, Free and Full columns. Do not substitute the size of the physical card for that volume's free space.

An almost-empty disk can compress well while retaining large partition definitions. A larger replacement also keeps the original image's partition sizes. If Info shows free space in the intended volume, it is not full just because the image or partition is large.

🔌 Power and startup

⚡ The V4 freezes or resets unpredictably

1. Use the supplied or explicitly approved PSU and power lead for the complete machine. The standard Mini-USB-powered Standalone uses a 5 V supply; an expansion system can have a different external power arrangement.
2. Check the power lead and connectors. Avoid an unapproved thin cable or inline switch as a substitute for the supplied assembly.
3. Disconnect non-essential peripherals and external adapters.
4. Connect the video output directly to the display, bypassing switches, splitters and capture hardware.
5. Perform a full cold start, then repeat the activity that caused the failure.
6. If stable, reconnect one extra device at a time and repeat that test.
7. If failures began after an update, compare with the previously working core and software together.

Do not raise the supply voltage to compensate for instability. Do not flash firmware from a system that is already freezing or resetting.

🔄 Perform a genuine cold start

1. Finish file transfers and wait for disk activity to stop. Allow time for delayed writes after saving.
2. Switch off and remove the normal power connection.
3. Disconnect other connections that could keep the board energised, including the display connection, Ethernet and any programmer.
4. Leave it fully unpowered for 30 seconds.
5. Reconnect the normal power, display and essential input devices, then start again.

For a warm reset on a compatible PC keyboard, press left Ctrl + Windows + right Ctrl. Wait for disk writes first. A warm reset does not replace the power cycle required after flashing.

🖥️ No picture appears

1. Select the correct input on the display.
2. Use a direct connection and a known-good video cable.
3. Connect a known-compatible mouse to its proper input port.
4. Hold both mouse buttons during power-on to enter Early Startup.
5. If the menu remains invisible, press Tab to try switching its PAL/NTSC timing. Older documented environments also accept another key for this switch.
6. Try a display known to accept the V4's native output. The usual native timings include 720 × 576 at 50 Hz and 720 × 480 at 60 Hz.

If Early Startup is visible but the desktop goes black: follow the screen-mode recovery steps.

If Early Startup never appears: check mouse compatibility, display compatibility and power before deciding that the firmware has failed. A screen that displays the RTG desktop may still reject a native boot or game mode.

🌈 Coloured stripes appear at startup

Brief self-test colours can be normal. Diagnose a persistent failure pattern, not a colour that flashes past.

On cores providing the separate diagnostic BootMenu—documented from core 10500—hold Help at power-on. A compatible PC keyboard maps Page Up/Page Down to Help; the Apollo joypad also provides entry through B, X or Y during power-on. This diagnostic menu is different from the two-mouse-button Early Startup menu.

1. Photograph the persistent pattern.
2. Record the installed core and what changed before the failure.
3. Use the available diagnostic memory tests if the menu works.
4. Stop normal use if a memory test repeatedly fails.

Do not format the CF in response to a memory or ROM self-test failure.

📦 The CF stopped being detected after transport

An insert-boot-drive screen can result from a loose CF or IDE adapter. It does not justify pushing on the card through the case opening.

1. Switch off and disconnect all cables before opening the standard enclosure.
2. Follow the enclosure's disassembly instructions and use proper ESD precautions.
3. For an internal adapter, remove and support the board as required before applying pressure. Do not press the adapter into place while the board is unsupported inside the case.
4. Inspect the CF and adapter seating. Check the connector orientation and that every row and pin is aligned.
5. Reseat only if the alignment is certain. The 44-pin IDE connector carries power; a reversed or offset connection can damage the hardware.
6. Reassemble the machine before powering up and test detection again.

For an externally accessible CF slot on an expansion enclosure, follow that enclosure's instructions instead. If orientation or disassembly is unclear, ask the supplier before proceeding.

🚦 Early Startup works, but normal boot stops

1. Enter Early Startup with both mouse buttons held at power-on.
2. Choose Boot With No Startup-Sequence, where offered.
3. If a Shell opens, photograph the error. Run Type S:Startup-Sequence and, if present, Type S:User-Startup to inspect the scripts.
4. Review the most recent change: a driver, startup command, ROM mapper or preference file.
5. Follow the backup/edit/restore procedure to put a semicolon before one suspect command on the spare CF.
6. Restart and repeat the same test. Restore the line if it made no difference.

A Shell narrows the search to later startup activity, but does not prove that the whole card is healthy. On a multiboot system, do not remove ROM-selection or bootloader commands without understanding their role.

If the problem started immediately after flashing, also check the ROM arrangement.

🗄️ Storage faults and larger cards

🧩 A partition exists but will not mount

A partition entry describes where the volume is. The boot environment must also have a suitable filesystem handler and a disk driver that can reach it.

1. Preserve a full image before changing the partition map or filesystem configuration.
2. Follow the read-only RDB inspection on an image copy, recording each partition's name, range and filesystem identifier.
3. Check which filesystem handlers are stored in the RDB and which are supplied by the boot environment.
4. Compare those with the requirements of the installed ROM, OS and disk driver.
5. If an emulator mounts the partition but the V4 does not, compare the controller, ROM and handler versions used by each.

The RDB can hold filesystem code needed during boot. Copying a handler into a directory on an unreadable volume does not necessarily make that volume bootable.

Do not format a populated partition because it appears uninitialised. Do not change its filesystem identifier to “convert” it. SFS, PFS3 and FFS store their data differently; relabelling is not conversion.

🔎 A partition disappears under another ROM or OS

1. Use the configuration-recording commands. Read the filesystem entries and partition ranges with the RDB inspector; distinguish embedded handlers from files in L:.
2. Calculate the partition's end position using the geometry and end-cylinder explanation in the RDB procedure, not just its displayed size.
3. Confirm that the complete storage path supports addresses that far into the disk.
4. For a boot partition, confirm that this support exists before Startup-Sequence runs.
5. Compare with a known-working boot environment using a copy of the same disk image.

Legacy 32-bit byte-addressed disk access has a 4 GiB boundary. A small partition located beyond that boundary can still be inaccessible. Large-disk support requires a suitable driver and access method as well as a suitable filesystem.

PFS3aio tests available access methods and can refuse to mount an unreachable partition. Installing a newer handler alone does not guarantee that the underlying driver can access it.

🚨 Files copy without an error, but the copies are damaged

1. Stop writing to the affected data and preserve the current card.
2. Choose a known-good test file and keep its original checksum.
3. Write a spare CF through the PC reader and verify it there.
4. Run the V4 file round-trip test and compare the returned file's size and SHA-256 with the host original.
5. Change one component at a time: card, reader, cable or adapter. Power off before changing internal connections.
6. Repeat the operation that originally failed, including a large transfer if that was the trigger.

Correcting the cause does not reconstruct damaged files. Restore those from a verified source afterwards.

🔁 Verify a file copied through the V4

This checks a complete host → transfer card → V4 volume → transfer card → host round trip. It works with either AmigaOS or ApolloOS and uses the host's SHA-256 tool. Use only expendable data on a spare system card when investigating corruption.

1. On Windows, macOS or Linux, select a known-good ordinary file, preferably a few tens of megabytes. Keep it below 4 GiB for a FAT32 transfer card. Name a copy V4-test.bin and record its byte length and SHA-256.
2. Copy V4-test.bin to the transfer card using Explorer/Finder/the Linux file manager. Safely eject it, then mount it on the V4 using the microSD procedure.
3. Run Info on the V4. Identify the transfer volume and an expendable destination on the spare CF. In the following example, replace Transfer: and TestData: with the names actually shown. Do not assume the volume label is SD0:.
4. Make a new test drawer, then copy the file from the transfer card into it:

MakeDir TestData:V4-copy-test
Copy Transfer:V4-test.bin TO TestData:V4-copy-test/V4-test.bin
List TestData:V4-copy-test/V4-test.bin

1. Check for errors and confirm that the reported file size is plausible. Finish writes and perform a cold start, so the following read is not simply the first copy's immediate cache contents.
2. Mount the transfer card again if needed. Copy the CF file back under a different name:

Copy TestData:V4-copy-test/V4-test.bin TO Transfer:V4-return.bin

1. Finish writes and use the release's documented unmount action. If that action is unavailable, power the V4 off completely before removing the card.
2. On the host, copy V4-return.bin to a new folder and calculate its SHA-256 using the command for your host. Compare it with the original V4-test.bin hash and byte length.
3. Matching sizes and hashes mean this round trip preserved those bytes. A mismatch identifies a problem somewhere along that path; it does not identify the faulty component by itself. Repeat with one changed component, retaining both files and the error record.

Once this small test passes, repeat with a larger expendable file if the original fault involved large transfers. This is a practical transfer check, not a complete test of every sector or filesystem structure.

⚙️ Check IDE timing and partition transfer settings separately

IDE timing controls the storage interface. MaxTransfer limits the amount requested in one filesystem transfer. Mask describes the memory addresses allowed for transfers. These settings are not interchangeable.

For an IDE-speed change:

1. Run Type S:Startup-Sequence and Type S:User-Startup where present. Locate the VControl or ApolloControl line and follow the startup-file backup procedure.
2. If corruption began after that command was added or changed, undo that specific change.
3. Cold-start and repeat the file round-trip test.
4. For an installed VControl, run C:VControl HELP and record its available IDE options. For ApolloControl, open the guide supplied with that exact version. Do not substitute command names between the utilities.

The microSD clock is a separate setting. Do not change it to fix an internal IDE problem.

For partition settings:

1. Restore a verified backup to a spare. Run the read-only RDB inspection to record each partition's mask and max_transfer, filesystem type and embedded handler. Also record the OS image/release and controller configuration. These are diagnostic observations, not replacement values.
2. Confirm any replacement values against the instructions for that V4/V4+ image, controller and filesystem. A screenshot from a different installation is not enough to establish the correct values.
3. If the fault affects only a newly added partition, compare its settings with a working partition using the same controller and filesystem. Treat differences as clues; do not automatically copy settings from a different filesystem or boot environment.
4. If the correct values cannot be established, leave them unchanged and supply the recorded configuration when requesting help.
5. Make only the confirmed change on the spare, using the procedure for its partition tool. Reboot, reopen the tool to check that the intended values were saved, and repeat the same transfer test.

There is no single Mask/MaxTransfer pair prescribed here for every V4 installation. A change to these fields does not repair files that are already damaged.

🚨 PFS3 reports “Wrong Index Block ID”

1. Stop writes to the affected partition.
2. Preserve a whole-card image and work on a copy.
3. Use the RDB inspection to identify its filesystem type and embedded handler version. If the installation also has L:pfs3_aio-handler, run Version L:pfs3_aio-handler FILE FULL on the V4. Record both results; a file on disk is not proof that the same handler is active.
4. Check storage reliability and the handler's release notes before choosing a repair or upgrade.
5. Recover files to a separate destination before considering a rebuild.

The error is not a unique diagnosis. PFS3aio has fixed multiple corruption bugs, including defects triggered by rapidly creating many small files on larger partitions.

A specific historical case: PFS3aio 3.0, when using the affected AmigaOS 3.1.4 SCSIDIRECT mode, could corrupt the partition. PFS3aio 3.1 fixes that defect, but the affected filesystem requires reformatting and restoration after its files have been recovered. Merely replacing the handler does not repair existing damage.

That version-specific requirement does not mean every index-block error should be treated by formatting. Use PFS3 repair tools only on a copy and only when they support the affected filesystem format.

⚠️ PFS3 warns about an experimental partition size

Some PFS3aio releases describe >104G partition support as experimental and unsupported.

1. Cancel the operation until you have checked the limits of the exact handler version.
2. Locate that partition in the RDB inspection output and record its size. Do not substitute the card's advertised capacity.
3. For a new installation, choose partition sizes supported by the complete storage setup.
4. Keep existing data backed up before altering any layout.

A 128 GB card does not need one partition spanning almost the entire device. Do not accept an experimental-format warning merely because the hardware has enough space.

📐 A larger CF still has the old image's partition sizes

Restoring an image reproduces its partition layout. It does not automatically expand the filesystems to fill a larger destination.

1. Verify the restored image and test that it boots before making changes.
2. Back up the replacement and record the existing partition boundaries.
3. Measure the physical card in bytes, then inspect the RDB image copy. Compare its BlockDevice, PhysicalDisk, LogicalDisk and partition ranges.
4. Establish whether the extra capacity lies beyond the disk definition, between existing partitions, or inside a partition whose filesystem has its own size limit. These require different solutions.
5. Before changing the layout, obtain the expansion procedure for the exact V4/V4+ OS image and filesystem. If that procedure is unavailable, keep using the verified existing layout; unused capacity does not prevent it from working.

Changing a populated partition's boundaries is not a safe way to enlarge its filesystem. Treat resizing or moving it as destructive unless a specifically supported migration procedure establishes otherwise.

📐 Check unused space before changing partitions

Use this checklist to assess a proposed V4/V4+ storage procedure:

1. Confirm that a complete backup can be restored to a spare.
2. Use the physical-size check, RDB inspection and configuration record. Save the outputs before considering the proposed layout.
3. Confirm that the proposed data area is outside every existing partition and inside the usable disk range.
4. Check that the boot environment, driver and filesystem can address the proposed partition's end position.
5. Preserve populated partitions. Any formatting step must identify only the new, empty partition by its device name and size.
6. After following the release-specific procedure on a spare, run the file round-trip test before storing important data.

This is a preparation checklist. The partition creation commands and settings must come from the procedure for the actual V4/V4+ installation. If an existing volume appears uninitialised after a change, stop and compare its map with the backup; do not format it.

🧭 Personal: seems to refer to the wrong place

1. Open a Shell and run Assign. Look under its assignment, volume and device headings for Personal.
2. Run Info to see which mounted volume/device names correspond to the available filesystems.
3. Run List Personal: to see the directory contents reached by that name. This lists files; it does not alter the assignment.
4. Inspect S:Startup-Sequence and S:User-Startup with Type, looking for the line creating the assignment. Check any launcher it invokes as well.
5. If the mapping changed with an edit, use the startup-file procedure to restore the previous line on a spare, then reboot and repeat Assign and List Personal:.

DH0: is a device name; Personal: can be a volume label or an assign. Neither alone identifies the physical disk a partitioning tool will modify. On multiboot installations, do not remap a shared data name until the other installations' use of it is understood.

📦 Programs are broken although the raw image verified

Use this to check an application archive, not to unpack a many-gigabyte system image into the V4's RAM disk.

1. Keep the original archive unchanged on the host. Copy the archive itself to a compatible microSD transfer card and mount it on the V4.
2. In a Shell, run Info and identify an Amiga filesystem on the spare CF with enough free space. Make a new extraction drawer. Replace the volume name with yours:

MakeDir TestData:Extract-test

1. For an LhA archive with the Amiga LhA command installed, test it first, then extract with paths preserved. Substitute the real transfer volume and archive name:

LhA t Transfer:Program.lha
LhA x Transfer:Program.lha TestData:Extract-test/

1. For a ZIP archive, use the Amiga/AROS UnZip utility if installed:

UnZip -t Transfer:Program.zip
UnZip Transfer:Program.zip -d TestData:Extract-test

1. If the command is missing, use the distribution's archive application's Open → Extract controls and choose the new drawer. Do not substitute an unverified archive utility or extract over the live installation.
2. Require the test/extraction to complete without CRC, data or write errors. Open the extracted ReadMe or Installer and follow the package's OS requirements.
3. To inspect one program's attributes, use List "TestData:Extract-test/Program". On a file known to be the actual executable, an absent execute permission can be restored with:

Protect "TestData:Extract-test/Program" +e

1. Use that correction only after checking the archive and program identity. Do not mark data files or whole directories executable. Launch the cleanly extracted copy and compare it with the failed installation.

Host extraction can lose Amiga metadata or mishandle filenames. A raw-image restore preserves the image's bytes; it cannot correct an image assembled from a damaged or incorrectly extracted application tree.

🔗 Peripherals and connections

⌨️ A USB keyboard or mouse does not work

The V4's native USB input ports implement supported input protocols in hardware. Installing an Amiga USB stack does not make these ports support arbitrary USB devices.

1. Check the labels and port diagram for your board or expansion enclosure. Port numbers and positions differ.
2. Connect the keyboard and mouse directly to their assigned ports.
3. Remove hubs, KVM switches and adapters for the test.
4. Try a simple device confirmed compatible with the V4. Keyboard and mouse support depends on the required USB boot protocol.
5. Test recognition from a cold start, particularly if you need the mouse for Early Startup.
6. If the problem began with a core change, compare against the previous matching setup before replacing peripherals.

If reconnecting a mouse after boot makes it work, record that result as an initialisation/compatibility clue. It does not prove that the mouse will work at power-on.

Ordinary USB storage sticks are not supported through these native input ports. Use CF, supported microSD storage or networking for files.

🎮 Characters or controller buttons are wrong

1. For a working keyboard that types the wrong characters, open SYS:Prefs/Input on AmigaOS, or Prefs → Input on an ApolloOS release containing that editor. Select the keyboard layout matching the physical keyboard, choose Use to try it, then type letters, punctuation and symbols into an unsaved editor document. Return and Save only if correct. On AmigaOS, a missing PC layout may need the keymaps from the matching SAGA package installed in DEVS:Keymaps.
2. Check the Amiga-key equivalents: Windows keys provide Amiga-key functions; right Ctrl can act as right Amiga; Page Up/Page Down provide Help on the supported mapping.
3. For the Apollo joypad, set the rear mode switch to D.
4. For another USB controller, check its exact model and core compatibility. A D/X switch alone is not proof of support.
5. Check the game's own button support and per-game configuration.

For DB-9 input, use devices approved for the actual board and core. The connector's shape does not guarantee electrical or functional compatibility, and historical V4 documentation differs on some legacy input capabilities.

🕰️ The clock resets after power-off

1. Check whether a battery-backed RTC is actually fitted. Without one, the machine cannot maintain time while completely unpowered.
2. If a compatible DS3231 module is fitted, run Version C:I2Clock FULL to check the utility and note the result. On AmigaOS, use the matching SAGA installer's I2C support. On ApolloOS, use the driver and utility supplied for that release; this is not an instruction to install the AmigaOS package over it.
3. Open SYS:Prefs/Time (or the release's Time preferences), set the current date/time and apply it. In a Shell run Date and check the displayed result before writing it to the RTC. Do not save a clearly incorrect system date to the battery clock.
4. Save the current time to the RTC from the Shell:

I2Clock CHIP=DS3231 SAVE

1. Use the startup-file backup/editor procedure for S:User-Startup. Inspect the existing file first; if there is no equivalent RTC load command, add this line after the required driver is available:

I2Clock CHIP=DS3231 LOAD

1. Finish disk activity, switch off, remove power and start again. Check that the saved time has advanced correctly.
2. If it has not, run I2Clock CHIP=DS3231 LOAD manually, record any error, then run Date again. If manual loading works but boot-time loading fails, inspect the saved startup line and driver-loading order. If manual loading also fails, remove power before checking the module connection or battery.

Fit or remove an RTC only with all power disconnected. Match the module's pinout and electrical requirements to the board; “DS3231” on a module is not sufficient confirmation of the connector layout.

🔊 There is no sound

1. Connect the V4 directly to an audio-capable display through its digital A/V output.
2. Check the display's selected audio input, volume and mute settings.
3. Test a known-working game or audio file.
4. If game audio works but one application is silent, open that application's audio settings and record its output backend and AHI unit, if used. Open SYS:Prefs/AHI where installed, select the same unit, record the current mode and volume, then try an installed mode intended for the V4. Use its test/play control if provided. Apply with Use, retest the application and save only a working setting; restore the original mode if it does not help. If no V4 mode is listed, check the matching OS driver package before changing other units.
5. If you use external speakers, confirm the actual audio path: display audio output, a supported expansion-board output or a suitable digital-video audio extractor.
6. Remove the extractor temporarily if it causes new video problems.

The standard Standalone sends digital audio with its video output. A separate analogue jack depends on expansion hardware. A video connection through DVI does not provide the same assured audio path.

🌐 Ethernet is connected but networking fails

Start with a direct connection to a working router/switch port and a known-good cable. Identify the installed TCP/IP stack before changing its configuration. On AmigaOS with the SAGA driver package, the onboard interface uses DEVS:Networks/v4net.device; ApolloOS supplies its own driver/stack arrangement.

AmigaOS with Roadshow already installed

1. Open a Shell and run these read-only commands:

Version DEVS:Networks/v4net.device FILE FULL
List DEVS:NetInterfaces
ShowNetStatus INTERFACES ROUTES DNS

1. Note the interface name, address, default route and DNS servers. Use Type DEVS:NetInterfaces/YourInterface to inspect the relevant configuration file, replacing YourInterface with its actual name. Check its device and unit; do not run several interface definitions for the same hardware.
2. If that configured interface is not running, start that existing definition:

AddNetInterface DEVS:NetInterfaces/YourInterface

1. Preserve any error. Re-run ShowNetStatus INTERFACES ROUTES DNS and check whether an address and default route now appear. If this is a DHCP network but the file forces an old fixed address, use the correction below.
2. Close network applications before a controlled stack restart. NetShutdown stops Roadshow; wait for completion and dismiss any demo requester before AddNetInterface starts the intended interface again.

Repair an old static Roadshow setup for a DHCP router — AmigaOS 3.x

This procedure is for one wired interface on a router that supplies DHCP. Keep a deliberately managed static or multi-interface configuration intact until its network requirements are known. Replace YourInterface with the existing filename identified above.

1. Close network applications. Run NetShutdown and wait for completion, dismissing any demo requester.
2. Create a new backup drawer outside DEVS:NetInterfaces. Run MakeDir SYS:V4-backups only if that parent drawer does not exist, then run MakeDir SYS:V4-backups/Roadshow-before-test. If the latter already exists, choose a new suffix throughout these steps.
3. Use List to check the three source paths below, then copy each existing file. Note any file that was absent. Keep a separate copy of this backup drawer on transfer media too:

Copy DEVS:NetInterfaces/YourInterface TO SYS:V4-backups/Roadshow-before-test/YourInterface CLONE
Copy DEVS:Internet/routes TO SYS:V4-backups/Roadshow-before-test/routes CLONE
Copy DEVS:Internet/name_resolution TO SYS:V4-backups/Roadshow-before-test/name_resolution CLONE

1. Open Ed DEVS:NetInterfaces/YourInterface. Preserve device and unit. Put # before active fixed address= and netmask= lines and before other configure= lines. Leave exactly one active line:

configure=dhcp

1. Save with Esc, X, Return. Roadshow configuration files use # for comments; this is different from a Shell script's semicolon. configure=auto is not another spelling of DHCP. Do not keep backup interface definitions alongside live files in DEVS:NetInterfaces, where startup may load them too.
2. If DEVS:Internet/routes exists, open it with Ed. In this single-interface DHCP setup, put # before an obsolete forced default ... route. If DEVS:Internet/name_resolution exists, open it and put # before obsolete forced nameserver ... entries. Preserve unrelated lookup/domain settings. Save each edited file; absent files need not be created for this DHCP test.
3. Inspect the saved files with Type using their full paths. Then start the intended interface and inspect the result:

AddNetInterface DEVS:NetInterfaces/YourInterface
ShowNetStatus INTERFACES ROUTES DNS

1. Check for a DHCP address on the expected LAN, a default route and usable DNS servers. An automatically chosen 169.254.x.x address is not a successful router DHCP lease. Run the numeric-address and hostname tests below, then reboot and repeat them to confirm the saved setup starts correctly.
2. If DHCP gives an address but omits a required gateway or DNS server, obtain the actual values from the router or a working computer on the same LAN, using the host checks below. Close network applications and run NetShutdown. Open Ed DEVS:Internet/routes and add or correct one default GATEWAY_ADDRESS line. Open Ed DEVS:Internet/name_resolution and add or correct nameserver DNS_ADDRESS. Replace those uppercase placeholders with the confirmed numeric addresses; use a space, not =. A gateway is not automatically a DNS server. Save, restart with AddNetInterface and repeat the tests.
3. To undo the changes, close network applications, run NetShutdown, and copy each backed-up file to its original path. For example:

Copy SYS:V4-backups/Roadshow-before-test/YourInterface TO DEVS:NetInterfaces/YourInterface CLONE
Copy SYS:V4-backups/Roadshow-before-test/routes TO DEVS:Internet/routes CLONE
Copy SYS:V4-backups/Roadshow-before-test/name_resolution TO DEVS:Internet/name_resolution CLONE

Run only the restore commands for files you actually backed up. If you created a previously absent routes or name_resolution file in step 9, remove that newly created file only with Delete DEVS:Internet/routes or Delete DEVS:Internet/name_resolution, as applicable. Restart the original interface and repeat the status checks.

ApolloOS installations with SYS:Prefs/Network

1. Open the system disk's Prefs → Network application. If this release has a different network launcher, use the one supplied with that image; the following controls describe the AROS Network Preferences interface.
2. Photograph the current settings. Select the existing wired interface and choose Edit. Record Device, Unit and whether it is Active. Keep the driver supplied for this ApolloOS installation; do not install the AmigaOS SAGA network driver over it.
3. On a network using DHCP, choose Automatic under IP Mode for that interface, then accept the edit. Do not add a duplicate interface.
4. Apply/Use the configuration as offered by that version. If asked to restart the stack or reboot, finish file transfers first and follow the request. Save for future boots only after a successful test.
5. Check the router's connected-device/DHCP-client list for the V4's assigned address. The address field in an automatic-configuration editor is not always a live lease display. Record the address and the router's gateway/DNS settings.

Test connectivity in stages

1. On the V4, use the installed stack's Ping tool. For Roadshow, the following sends four requests; replace the example address with your actual router address:

Ping COUNT 4 192.168.1.1

1. For an ApolloOS release with the usual AmiTCP-style ping installed, the corresponding syntax is ping -c 4 192.168.1.1. If the command is absent, use the release's network test utility; do not substitute Roadshow commands into ApolloOS.
2. Test another known reachable numeric IP address on your LAN. Replies establish reachability for those requests. A timeout can also mean the destination blocks ping.
3. Test a hostname, for example Ping COUNT 4 example.com on Roadshow or ping -c 4 example.com with the AmiTCP-style tool. A displayed numeric address shows name resolution worked, even if echo replies are blocked. An explicit name-resolution failure is a DNS clue.
4. If IP and name tests work but a website does not, check the browser's exact error and the V4 clock with Date. Test another site before changing the network configuration.

Check from a second computer on the same LAN

Use the gateway and IPv4 DNS servers for the same network as the V4; a VPN or guest Wi-Fi can change routing or prevent local-device access. Do not copy a host's loopback resolver address such as 127.0.0.53 to Roadshow. If Linux does not use systemd-resolved, obtain the LAN DNS addresses from the router's DHCP settings instead.

If networking fails only after leaving a game, test the WHDLoad shutdown/cleanup sequence.

💾 Prepare or mount a microSD transfer card

Keep the microSD transfer card separate from the CF system disk. An SDHC card in the 4–32 GB range with FAT32 is a conservative transfer choice for the documented setup.

If ApolloOS can already read and write the card, leave its format alone.

To mount an existing compatible card:

1. Insert it correctly into the slot.
2. In the applicable ApolloOS desktop, choose Start Menu → SD Card → Mount.
3. Run Info to identify its mounted volume name, then follow the file round-trip test.
4. Finish transfers and use the installation's flush/unmount operation before removal. If uncertain, finish writes and power down first.

To prepare an otherwise unsuitable spare transfer card in Windows:

1. Back up everything on that microSD card. The following format erases it.
2. Disconnect the Amiga CF and other removable disks.
3. Open Rufus and select the correct microSD device.
4. Choose Non bootable, an MBR partition layout where selectable, and FAT32.
5. Set the label to SD0 to follow the documented ApolloOS transfer setup. The label alone does not provide compatibility.
6. Select Quick format and disable Create extended label and icon files, where offered.
7. Check the selected device again, start formatting, wait for completion and safely eject.
8. Mount it in ApolloOS and test both reading and writing.

Prepare a spare transfer card on macOS

1. Back up its contents and disconnect the Amiga CF and other removable disks. Use an SDHC card in the stated 4–32 GB range for this procedure.
2. Open Applications → Utilities → Disk Utility and choose View → Show All Devices.
3. Select the physical microSD device, matching the reader and capacity. Select its top-level device, not the Mac's internal drive or an individual volume.
4. Click Erase. Enter SD0 as the name, choose MS-DOS (FAT) as the format and Master Boot Record as the scheme.
5. If the scheme selector is missing, cancel and reselect the whole device. Recheck the target, then confirm Erase. This erases that microSD.
6. Wait for completion, click Done, eject the device and test mounting and a file round trip on the V4.

Prepare a spare transfer card on Linux — GNOME Disks

1. Back up the microSD and disconnect the CF and other removable disks. Identify the SDHC card with the Linux disk listing.
2. Open Disks. Select the matching physical device in the left column and check its capacity and device path.
3. From the disk's menu choose Format Disk. Select the partitioning option described as Compatible with all systems and devices (MBR/DOS). Recheck the device before confirming; this replaces its partition table.
4. Select the resulting free space and press + to create a partition spanning the card. Enter SD0 as its volume name and choose FAT, described as compatible with all systems/devices.
5. Complete the creation. For a 4–32 GB SDHC card this should produce the FAT32 transfer volume. Check the filesystem description in Disks before continuing.
6. Use Disks' Power Off/Safely Remove action, then mount the card on the V4 and run the round-trip test. If the AmigaOS SAGA/GiggleDisk arrangement fails to recognise this Linux-created FAT32 volume, use the compatibility branch below.

These formatting instructions apply only to an expendable transfer microSD, never to a populated Amiga CF. A label such as SD0 does not install a driver or make an unsupported card compatible.

🐧 Linux-created FAT32 mounts on the PC but is not recognised by GiggleDisk

Some GiggleDisk versions identify FAT volumes using the boot sector's eight-character OEM field. Linux FAT tools write mkfs.fat; the affected detection code expects MSWIN?.? or MSDOS?.?. This concerns the named AmigaOS SAGA/GiggleDisk mounting route, not every ApolloOS SD driver.

Use this only on the freshly prepared, backed-up spare transfer microSD, after confirming it is FAT32. An alternative is to prepare that spare with the Windows procedure above, then return it to the Linux/V4 transfer workflow.

1. Return the microSD to Linux. Disconnect the CF and other removable disks. Run the following and identify the card's FAT32 partition, checking its parent disk, capacity, label and mount point:

lsblk -b -o NAME,PATH,TYPE,SIZE,FSTYPE,FSVER,LABEL,MOUNTPOINTS,MODEL

1. Substitute that partition path for /dev/sdX1 in every command below; a built-in reader may use /dev/mmcblk0p1. Do not use the whole-disk path. Unmount it if mounted:

sudo umount /dev/sdX1

1. Read the OEM field without changing it:

sudo dd if=/dev/sdX1 bs=1 skip=3 count=8 status=none

1. Continue only if the read succeeds and returns exactly mkfs.fat. If it already shows MSWIN4.1, or an MSWIN/MSDOS identifier, this particular mismatch is not the explanation. Do not patch an unfamiliar result.
2. Recheck the selected partition in Disks. With it still unmounted, change only those eight bytes of its primary boot sector:

printf 'MSWIN4.1' | sudo dd of=/dev/sdX1 bs=1 seek=3 count=8 conv=notrunc,fsync status=none

1. Require a successful command with no I/O error. Repeat the read command in step 3 and confirm MSWIN4.1. This changes an identification field; it does not repair a filesystem or make an unsupported driver compatible.
2. Safely remove the device in Disks. On the V4, run the AmigaOS mounting steps below so GiggleDisk generates a fresh MountList, then complete the round-trip test before putting useful files on the card.
3. If this does not help, retain the mounting error. To return this still-expendable spare to its original Linux format, repeat the Linux preparation procedure; that erases it. Do not keep modifying boot-sector fields in search of a fix.

AmigaOS 3.x with the SAGA SD tools installed

1. Insert the already prepared transfer card and open a Shell. Run SDDiag.
2. Require a sensible Block Size, Blocks and Capacity report. Preserve any detection error rather than formatting the card to hide it.
3. If your installed package includes SYS:System/SDMountOnOff and C:GiggleDisk, run:

Execute SYS:System/SDMountOnOff
Info

1. Confirm that the expected transfer volume appears. The script generates card-specific MountLists under T:SDMount and attempts to mount them. If mounting fails, run List T:SDMount and Type T:SDMount/SD0 where that entry exists; record its device, geometry and filesystem path.
2. Do not copy another card's geometry into that entry. If a previously populated FAT32 card appears uninitialised, stop and check the generated entry and installed FAT handler; do not format it.
3. Once mounted, run the round-trip test. These steps concern this named SAGA tool arrangement, not ApolloOS's native SD menu. Re-running a mount/unmount script on a card already in use can unmount it, so finish transfers first.

SD boot support was added in the 11K core generation, so “the microSD slot can never boot” is outdated. Booting still requires a supported core and a correctly prepared boot installation; a FAT32 exchange card with copied files is not automatically one.

On a spring-latched slot, press the card inward to release it. Do not pull it out against the latch.

🎮 Graphics, games and applications

🖥️ The desktop went black after saving a resolution

For AmigaOS with the SAGA/P96 RTG driver:

1. Restart while holding Shift to bypass the driver's RTG modes and fall back to a native screen.
2. If that native screen is also invisible, use the display checks in Power and startup.
3. Once visible, open the boot disk's Prefs → ScreenMode, or enter SYS:Prefs/ScreenMode in a Shell.
4. Select a mode supported by the display and use Test before saving it.
5. Save the working mode and reboot normally.
6. After confirming the working desktop survives a reboot, leave other display timings unchanged. If the bad mode must be removed from the available list, back up the P96 configuration and use the supplied Picasso96Mode documentation for that driver version; removing modes is a separate configuration task.

For ApolloOS — recover a visible desktop:

1. If available, connect the display on which this installation last worked. If the desktop becomes visible, open ScreenMode from the system's Prefs drawer, test a mode accepted by the intended display, then save it. Retest on that display.
2. If you still cannot see the desktop, power down and preserve the affected CF. Make a whole-device backup if the card reads reliably; a backup made now preserves the current fault as well as your files.
3. Choose the image to use:

• With a working backup: use a whole-CF image from before the screen-mode change that worked with the currently installed core. It restores the complete earlier installation, including its saved display settings.
• Without a working backup: use the official ApolloOS whole-device image specified for your Standalone/core. It provides a clean installation for testing.

1. Write the chosen image to a spare CF and verify it. Keep the affected card disconnected while writing. Retain that original card and its backup for later file recovery; newer files will not appear in an older backup, and a clean image will not contain your personal files.
2. With the V4 fully unpowered, fit the verified spare and boot it on the previously working display. Keep the core unchanged during this test.
3. If the desktop is visible and a different mode is needed, open Prefs → ScreenMode, test the required mode and save only a working result.
4. If the spare is also invisible, return to the native-video, display and power checks. Record the exact ApolloOS image and core before seeking a release-specific recovery procedure.

The spare-card route requires only one CF in the V4 at a time. Do not swap cards while powered, or expect a CF reader to work in the V4's native USB input ports.

A repair limited to the saved preference file needs the correct filename, boot route and target volume for that ApolloOS release. Do not delete guessed preference files. The AmigaOS SAGA/P96 Shift shortcut is not a universal ApolloOS recovery method, and its driver package must not be installed over ApolloOS.

🔎 High-resolution modes disappeared after an update

1. Use the configuration-recording commands and compare the results with the saved baseline.
2. Check the release's required software components.
3. Use the rollback procedure to test the previous matching combination on a spare, or the driver-update procedure if the current core requires a newer package.
4. On AmigaOS with the SAGA/P96 driver supporting VideoMemSize, back up DEVS:Monitors/vampiregfx.info and open its tooltype list. Record the existing VideoMemSize entry, including whether it is disabled in parentheses. Insufficient reserved framebuffer memory can hide modes.
5. Estimate one framebuffer as width × height × bytes per pixel: use 1 byte for 8-bit colour, 2 for 15/16-bit, 3 for 24-bit and 4 for 32-bit. For example, 1280 × 720 × 4 is 3,686,400 bytes. This is a basic framebuffer calculation, not a guarantee that every multi-screen arrangement fits that exact allocation.
6. If an unusually small reservation caused the problem, test the documented VideoMemSize=8M setting. The driver accepts a byte count or a K/M suffix; VideoMemSize=4M is another valid example, not a universal recommendation. Edit the existing entry rather than adding a duplicate. These are icon tooltypes, not Shell commands, and do not apply to ApolloOS's native graphics driver.
7. Save the icon and reboot. Open Prefs → ScreenMode, check whether the missing mode has returned, use Test, then save only a working mode. Test a native Amiga screen too.
8. If this does not help, restore the backed-up icon and reboot. A larger framebuffer reservation cannot correct incompatible timings or a mismatched driver.

Do not import arbitrary monitor timings as the first response to a missing mode.

🖱️ The pointer disappears, doubles or does not match clicks

1. Test the pointer on the normal desktop and in more than one application.
2. If it fails only inside ShapeShifter or one program, check that application's screen and pointer configuration first.
3. If the problem began after an update or downgrade, compare the core with the graphics package installed on the CF.
4. Follow the rollback procedure or matched driver update, then repeat the same pointer test.
5. Retest movement, clicks, menus and screen edges.

These symptoms can involve the graphics or application configuration; they do not identify one specific fault by themselves. Avoid replacing a single driver binary from an unrelated release or treating an old beta recommendation as a permanent fix.

🖼️ Games are stretched or the image is cropped

1. Test a native Amiga game separately from the RTG desktop.
2. For a stretched native image, try the display's 4:3 / Aspect / Original setting. Classic Amiga screens generally target a 4:3 presentation.
3. For missing edges, disable the display's zoom or overscan. Options such as PC mode, Just Scan or 1:1 may help.
4. Open the game's launch icon using Information and inspect its existing settings. If it runs a script, read it with Type "actual/path/to/launcher". Record any zoom/position command and temporarily undo only a change you introduced, using the file-edit procedure.
5. Confirm that circles look round and that the full intended picture is visible.

A widescreen RTG desktop and a native game can need different scaling settings. Pixel-for-pixel display is not always the same as the intended picture aspect.

🐢 Scanlines appeared or the machine suddenly became slow

1. On a core supporting the shortcuts, press F11 to toggle scanlines or F12 to toggle turtle mode.
2. Test whether the change affects the desktop and other programs.
3. If it returns only when launching one game, inspect that game's compatibility settings.
4. If it returns after every boot, run Type S:Startup-Sequence and Type S:User-Startup where present. Look for the control-utility invocation and any script it calls. Use the backup/edit/restore procedure to test removal of a recently added slowdown/scanline command.
5. Keep any required slowdown local to the affected title where possible.

If scanlines return on the AmigaOS SAGA/P96 RTG desktop:

1. Back up the monitor icon and open DEVS:Monitors/vampiregfx → Information, using the tooltype procedure.
2. For the SAGA driver supporting this option, change its existing entry to Scanlines=No, or add that one entry if absent. Scanlines=Yes enables the effect. Remove a duplicate conflicting entry; leave unrelated tooltypes alone.
3. Save the icon, reboot and check the RTG desktop. This setting concerns RTG screens; a game's native-screen setting may differ.
4. If the change has no useful effect, restore the backed-up icon and reboot. Do not put this AmigaOS monitor tooltype into ApolloOS preferences.

Turtle mode is a deliberate compatibility slowdown. Newer cores offer additional speed settings: run C:VControl HELP on a VControl installation, or open the installed ApolloControl utility's supplied help for its version. Keep a game's required slowdown in its own launcher and retain the prior launcher for undoing that test.

🧊 WHDLoad freezes or reports an interrupt error

For an AmigaOS installation with a network stack or an added software USB stack:

1. Close applications using the network or added USB hardware.
2. For Roadshow, run NetShutdown in a Shell and wait for completion. For another network stack or an added software USB stack, use its own Offline/Shutdown action. Do not apply Roadshow commands to ApolloOS or assume they stop an unrelated USB stack.
3. If a Roadshow demo displays a shutdown requester, dismiss it before launching the game.
4. Run the same WHDLoad title again with its previous settings.
5. If this resolves the fault, first restart the same Roadshow interface with AddNetInterface DEVS:NetInterfaces/YourInterface, substituting its actual filename from the network checks. Verify that the network works again. Complete the automatic setup below only after both manual commands work.

Automate a confirmed Roadshow fix — AmigaOS 3.x

1. Inspect S:WHDLoad.prefs with Type. If it exists, back it up with the file backup/editor method. Look for active ExecuteStartup and ExecuteCleanup entries: if they already call scripts, back up and edit those actual scripts, preserving their other actions. Do not create a second hook arrangement.
2. If there are no existing hooks, use the filenames below. Back up either script if it already exists. If a file is absent, the following ED command creates a new text file; enter the indicated command, then Esc, X, Return to save and exit.
3. Open Ed S:WHDLoad-Startup. Add this command once, preserving any existing script content:

NetShutdown

1. Open Ed S:WHDLoad-Cleanup. Add the following, replacing YourInterface with the one already tested:

AddNetInterface DEVS:NetInterfaces/YourInterface

1. Test the saved scripts manually, one at a time: run Execute S:WHDLoad-Startup, wait for shutdown and dismiss any demo requester; then run Execute S:WHDLoad-Cleanup. Check ShowNetStatus INTERFACES ROUTES DNS and repeat a successful network test. Fix any error before enabling the hooks. For an existing hook arrangement, test its actual script paths instead.
2. Open Ed S:WHDLoad.prefs, creating it if absent. For the new script arrangement, add or enable exactly these two entries. Remove a leading semicolon to enable a commented entry; do not leave duplicate active entries. If using existing scripts, retain their real paths instead:

ExecuteStartup=Execute S:WHDLoad-Startup
ExecuteCleanup=Execute S:WHDLoad-Cleanup

1. Save with Esc, X, Return. Use Type S:WHDLoad.prefs to check the saved hook lines. Close network applications, launch the same game, quit it normally and verify that the desktop and network both return. Dismiss a Roadshow demo shutdown requester if one appears.
2. If automation causes trouble, restore the saved prefs and scripts. If you created the hook entries from scratch, comment out both lines with ; to disable them. Run the already tested AddNetInterface command manually if networking remains stopped.

This simple cleanup starts the named interface on exit, even if it was offline before the game. Use it for a setup that normally keeps that interface online. Added USB stacks require their own shutdown/startup commands; these Roadshow scripts do not control them.

For interrupt options:

To test either option, use the icon Information procedure on one game's launch icon, add ChkInts or NoAutoVec as a separate entry, save and launch that same game. Record the result and remove the test entry afterwards. Use ChkInts to investigate an interrupt problem, then remove the diagnostic option when finished. Consider a global NoAutoVec setting only after establishing why several games need it. Do not add both automatically.

The V4's built-in keyboard/mouse input is not the same as an added software USB stack. Likewise, do not apply these AmigaOS stack instructions indiscriminately to ApolloOS/AROS.

🕹️ One game fails while the rest work

1. Photograph the WHDLoad splash/error information and record the title and slave version/date. In a Shell, run Version C:WHDLoad FILE FULL if WHDLoad is installed there. Keep the game's own ReadMe and release details with the report.
2. Read that install's requirements and supported tooltypes.
3. Test an applicable updated slave or documented per-game setting, changing one item at a time.
4. Keep the same game files when comparing cores, and the same core when comparing game patches.
5. Restore working defaults for other titles.

A title-specific failure does not establish that the CF or core is damaged. Avoid a system-wide downgrade solely because an unrelated game once worked better on a particular beta.

🍎 ShapeShifter will not start or has pointer problems

1. Confirm that the Amiga desktop itself works correctly.
2. Back up ShapeShifter's launch script using the file-copy procedure, and photograph its current memory/display settings. If launched by an icon, back up that .info file too.
3. Check its required Macintosh ROM, memory and display configuration.
4. On the Vampire setup that already reserves the low Chip-RAM area for Macintosh emulation, remove a duplicate PrepareEmul step from the test launch configuration.
5. Check that the VBR is moved to Fast RAM, as required by that setup. On an installation using VControl with its documented CPU and VBRMOVE commands, open a Shell and inspect the current state:

C:VControl CPU

1. Read the VBR line. If it already reports Fast RAM, leave it alone. If it reports Chip RAM, first check that no other VBR-management utility is active. For the VControl-managed setup, run:

C:VControl VBRMOVE 1
C:VControl CPU

1. Confirm that the second status report places the vector base in Fast RAM, then launch ShapeShifter and retest both desktops. Do not continue if the relocation fails or the status is unclear.
2. This VControl setting resets on reboot. If it resolves the problem, back up the launch script and add the command before ShapeShifter starts, following that installation's existing memory setup. Avoid duplicate VBR movers.

These commands assume VControl is installed in C:. Check C:VControl HELP if the installed version differs. An installation managed by ApolloControl needs that utility's own documented syntax; do not rename the command or add a second utility blindly.

Avoid assuming that every duplicate pointer comes from the core. A problem confined to the emulated screen needs its own graphics/configuration checks.

⌨️ Space or another typing key makes IBrowse disappear

Treat this as a possible shortcut conflict, rather than a known V4 hardware fault.

1. Look for IBrowse's icon on Workbench. If present, double-click it to restore the window. Note whether the session and tabs are still there; that distinguishes iconification from a fresh application launch.
2. In IBrowse, choose Project → About MUI… and record the version, then choose Preferences → MUI…. This opens IBrowse's own MUI settings. Keep the change application-specific; do not start with the global SYS:Prefs/MUI editor.
3. In the MUI 3.8 settings layout, select System in the left-hand page list, then find the Hotkey / Iconify-Hotkey field. This is the key combination that hides and shows the application. It is separate from the window's iconify-button checkbox. Use the same route in a later MUI build only if it presents this control; Zune or a different preferences layout needs its own matching help.
4. Photograph the current field. If it contains space or another typing key that reproduces the fault, click in the field, remove that shortcut text and press Return. Leave unrelated keyboard-navigation settings unchanged.
5. Click Test if offered, then return to IBrowse and type the previously failing key in an editable field. Confirm the window stays open. Also test normal iconification through IBrowse's Project → Iconify, then double-click its Workbench icon to return.
6. If the change resolves the conflict, return to the same MUI settings and click Save. Close and relaunch IBrowse, then repeat the typing test. If it did not help, choose Cancel before saving; if already saved, restore the photographed shortcut in the same field and save again.
7. If the field was already empty, the application actually quits, or several programs receive incorrect input, do not call this a confirmed MUI shortcut fault. Record the IBrowse/MUI versions and return to keyboard/keymap diagnosis.

🛠️ Update a working V4

🎯 Check the hardware and prerequisites first

1. Complete the configuration record, including the exact Standalone model, board revision, fitted RAM and expansion hardware.
2. Select an Amiga ApolloStandalone core approved for that configuration. These files commonly use a name such as STANDALONE_<build>.jic.
3. Check any stated clock/build variant and release status. A higher build number does not mean it is the right release for your board.
4. Read the release's required ApolloFlash, ApolloMap, control utility and graphics/OS updates. Complete prerequisite updates in the stated order.
5. Keep the previous core, matching software and full CF backup available.
6. Confirm that the machine is stable before starting.

Use only the Amiga core explicitly approved for your exact V4/V4+ Standalone. Firmware for accelerator boards or other Apollo systems is outside this procedure. A separate Atari core for V4-SA hardware is also not an Amiga firmware update.

The AmigaOS SAGA package and an ApolloOS distribution have different installation procedures. Use the route below for the OS you actually run. Do not move jumpers based on a generic release announcement without the instruction for your particular board.

📦 Install the matching software on a spare

AmigaOS 3.x — P96 and SAGA packages

1. Back up the working CF, write a verified spare, then boot that spare before changing its software.
2. Obtain the AmigaOS package version required by the selected core. Save the archive and release notes on the host alongside the core; an old download index is not evidence that its first entry suits a newer core.
3. Transfer the complete archive to the V4 and extract it natively into a new drawer. Read the included ReadMe before launching its supplied installer.
4. If installing RTG support from scratch, install the compatible P96 system first, then the SAGA driver package, using their supplied installers. For an existing installation, use the package's update path; do not replace a newer working P96 with an older bundled copy just to repeat a first-install sequence.
5. Double-click the package's installer icon. Check the selected system/destination and component choices against its ReadMe before confirming. Keep any installation log or first error. Do not reboot midway through an installer unless it requests it.
6. After successful completion, reboot as directed. Run the version checks, test ScreenMode and native video, then the practical checks.

ApolloOS

1. Preserve the original and identify the exact V4/V4+ image release and its core requirements.
2. If that release provides its own updater, use its included instructions and packages on the spare. The AmigaOS P96/SAGA installer is not the ApolloOS update mechanism.
3. For a clean, reproducible test, use the whole-device image-writing procedure with the specified ApolloOS image. Complete validation before installing the spare.
4. Boot and test before copying personal files across. Preserve the earlier card for recovery; do not copy its entire system directories over the new installation.

⚡ Flash with ApolloFlash

⚠️ Use this route only while the V4 boots and runs reliably. Keep power uninterrupted for the entire operation.

1. Extract the approved core package. Copy the .jic to a mounted transfer card, eject it on the host and mount it on the V4. In a Shell run Info to identify the transfer volume, then List Transfer:#?.jic, replacing Transfer: with that volume's actual name.
2. Close other applications and finish disk writes.
3. Check Version C:ApolloFlash FULL. If that is the approved installed flasher, run ApolloFlash followed by the exact core path using the command pattern below. Do not flash if the utility is missing or unsuitable.
4. Check the file and target reported by the utility.
5. If correct, confirm with uppercase YES when requested.
6. Leave the machine untouched until flashing reports success.
7. Wait at least another ten seconds after completion.
8. Switch off, disconnect any other power paths and leave the machine fully unpowered for 30 seconds.
9. Reconnect and boot. Check the core information where available, then test input, display, storage, sound and networking.

Copy the selected file into RAM: and confirm its exact name before starting the flasher. Replace the transfer volume and filename in all three commands:

Copy Transfer:STANDALONE_XXXXX.jic TO RAM:STANDALONE_XXXXX.jic
List RAM:STANDALONE_XXXXX.jic
C:ApolloFlash RAM:STANDALONE_XXXXX.jic

Stop if Copy fails or List does not show the intended file. This assumes the approved flasher is in C: and enough free RAM is available; run Avail first. Quote paths containing spaces. RAM: loses its contents at power-off.

A .jic is firmware data. Do not double-click it as an executable. If ApolloFlash fails to run, use List C:ApolloFlash to inspect the file, then check its native extraction and executable permission. Do not set the execute bit on the .jic.

🚫 ApolloFlash refuses the file

1. Save the complete error.
2. Check the filename, path and extraction result.
3. Recheck the hardware target and build variant.
4. Check that the ApolloFlash version meets the core's requirements.
5. Obtain board-specific advice if the rejection remains unexplained.

Do not use Quartus merely to bypass a target or compatibility rejection. External programming does not supply the same board-specific protection. Do not mix old flashrom/VampireFlash commands into a newer procedure unless that release actually requires them.

🧩 The flash succeeded but the old OS no longer boots

A core update can replace a separately flashed Kickstart with the core's default ROM while leaving the CF contents intact.

1. Hold both mouse buttons at power-on. If Early Startup appears, choose Boot With No Startup-Sequence where available and run Version. Photograph the result and compare it with the baseline record.
2. On the affected installation, inspect S:Startup-Sequence and S:User-Startup with Type. Look for an existing ApolloMap/ROM-loader command or a launcher it calls. Record the exact command and ROM path; do not create a second loader.
3. If the previous arrangement mapped a ROM from disk, check the referenced file with List "actual/ROM/path". Compare the loader and startup files with the preserved working installation. Restore that full backup to a spare to test the earlier disk-side setup with the release's compatible core/utilities.
4. If the installation depended on a separately flashed ROM, restoring the CF does not restore it. Use the separate-ROM restoration procedure after the final core flash. For rollback, restore the previous compatible core first; do not replace an unknown ROM with a similarly named download.
5. If the boot partition disappears only under the changed ROM, use the RDB inspection and record its position and handler. Do not format the card; the previous ROM may have supplied disk access or filesystem support that the new one lacks.

ApolloMap loads a ROM temporarily; it does not permanently flash it. A mapped ROM can survive a warm reset but is lost when power is removed. Do not alternate flashing and mapping without establishing which arrangement the installation needs.

For AmigaOS 3.5/3.9 configurations affected by the Vampire ROM-update conflict:

1. Follow the startup-file backup and editor steps on the spare CF.
2. In S:Startup-Sequence, locate the existing SetPatch command; do not add a second one.
3. Adapt that command to suppress the conflicting ROM update; the documented form is:

SetPatch NOROMUPDATE QUIET

1. Preserve other required startup logic, restart and test.

Do not add a second SetPatch invocation or apply this replacement to every AmigaOS or ApolloOS version.

🛟 Recover with USB-Blaster and Quartus

Use this advanced procedure when a firmware failure prevents normal flashing. First rule out power and display problems. A programmer cannot fix a loose CF, a missing filesystem or physical damage.

🧰 Prepare the recovery equipment

Host choice: Quartus Programmer is a Windows/Linux route. For macOS, use a suitable Windows or Linux computer for this recovery; there is no native macOS Quartus Programmer procedure here. ApolloFlash on a booting V4 remains a separate option, not a replacement for JTAG recovery on an unbootable machine.

1. Obtain the approved .jic for the exact board and preserve its filename.
2. Install an Apollo-supported Quartus Programmer version with support for the V4's Cyclone V device and the selected JIC format. The Standalone manual documents Quartus Programmer 13.1; newer software must also support the required device and cable.
3. On Windows, run the Programmer installer, connect the USB-Blaster to the PC, open Start → Device Manager, then use Update driver → Browse my computer for drivers on that programmer if its driver is missing. Select the matching installed Quartus driver folder and allow subfolders. On Linux, extract/install the supported Linux Programmer package, then open its quartus_pgmw application; USB permissions may need the Linux checks below.
4. Identify your connection method before powering anything:

The standard Standalone's Mini-USB power input is not a programming port. Do not confuse it with an expansion board's separate programmer socket.

🔌 Connect an external programmer

1. Disconnect the V4's PSU and all other connections that could energise it.
2. Open the enclosure using its documented procedure and use ESD precautions.
3. Identify pin 1 on the board header and programmer using their markings and diagrams.
4. Connect the JTAG ribbon with the marked edge correctly aligned at both ends. Check that it is neither reversed nor offset.
5. Connect the programmer to the PC as directed by its instructions.
6. Restore the V4's normal approved power supply for programming.

⚠️ Never connect, remove or reverse the internal JTAG ribbon while the board is powered. If pin 1 cannot be positively identified, stop and obtain board-specific assistance.

Recognition of the USB-Blaster on the PC confirms only that connection. The target must also be correctly connected and powered.

🔌 Connect the Ultimate's built-in programmer

These steps apply to the Ultimate Expansion Board assembly with the dedicated Mini-USB programmer socket. Identify it from the assembly's labelled rear-panel diagram before connecting a cable; the ordinary V4 Mini-USB power socket does not have this function.

1. Shut down, disconnect the assembly's PSU and remove other connections that could supply power. Leave the internal programmer wiring in place; do not attach a second USB-Blaster or follow the external-ribbon steps.
2. Connect a USB data cable from the dedicated programmer socket to the Windows or Linux computer running Quartus. A charging-only cable will not provide the programming connection.
3. Reconnect the Ultimate assembly's normal external PSU and switch it on with its power button. The programmer cable does not replace the machine's normal power supply.
4. Continue with Detect the board and load the JIC below. If USB-Blaster is absent, use the host-driver checks. If the cable is present but the target is not detected, stop before programming and check the target's power.
5. After successful programming and the wait specified below, switch off, disconnect the PSU and unplug the programming USB cable from the PC. Keep all power paths disconnected for the stated cold-start interval before normal booting. There is no external JTAG ribbon to remove in this arrangement.

🔎 Detect the board and load the JIC

1. Open Quartus Programmer and select JTAG mode.
2. Open Hardware Setup and select the recognised USB-Blaster.
3. With an empty programming list, use Auto Detect as a connection check. Do not start programming.
4. Photograph or copy the detected Device name and JTAG ID from the list/message pane. If detection fails, reports an unknown device or asks you to choose between devices sharing an ID, do not guess. Confirm the part using the exact board revision's documentation or an already recorded chip marking. Remove power before inspecting a board; do not remove a heatsink just to read a part number.
5. Select the temporary detection rows and click Delete to clear the PC's programming list. This does not erase the board. Choose Add File and load the approved .jic once.
6. Compare the FPGA/SFL Device name supplied by the JIC with the FPGA name recorded in step 4. Compare FPGA with FPGA, not with the configuration-flash row. They must identify the same supported FPGA device; if the names differ or require an interpretation you cannot confirm from the board documentation, stop and retain both screenshots for support. Do not edit the target name to make it agree.
7. Recheck the release's board/revision and memory variant too. Matching an FPGA part alone does not establish that a core has the right pin assignments and memory configuration for this V4.
8. Enable Program/Configure and Verify for the configuration-flash/JIC entry. Keep the associated FPGA loader configuration selected as required by the JIC workflow.

The FPGA entry may be labelled Factory default SFL image or similar. SFL is a temporary Serial Flash Loader used to access configuration flash; it is not an old Apollo core to delete.

Leave a separate Erase operation unticked. Normal programming handles the erasure required for its write. A separate erase is not an extra verification step. Do not add guessed flash devices or force a different FPGA identity.

🔄 Program, verify and restart

1. Recheck the target, filename and selected operations.
2. Click Start and leave the PC, programmer and V4 undisturbed.
3. Wait for 100% (Successful) with the requested verification completed. The V4 may stop responding while the programmer takes control; do not interrupt the operation because the desktop freezes.
4. Copy the Programmer message pane into a text file or capture a screenshot showing the filename, operations and final result. Wait at least another ten seconds.
5. Remove the V4's normal power and other power paths. Disconnect the programmer from the PC as required so the board is fully unpowered before detaching an internal ribbon.
6. Leave the machine unpowered for 30 seconds, reassemble it and reconnect normally.
7. Boot and check the ROM/CF arrangement if the OS does not start.

Some older version-reporting methods depend on a string updated by the Amiga-side flasher, so that string can remain stale after JTAG programming. Keep the exact JIC and successful programming log rather than repeatedly flashing solely to change an old VControl CORE display.

🔍 USB-Blaster is absent from Hardware Setup

1. Check the PC USB cable and port.
2. On Windows, right-click Start → Device Manager. Open the programmer's Properties → General and record its status/error code. Under Details → Hardware Ids, record the USB vendor/product IDs.
3. Install the driver matching the programmer family, Windows version and architecture.
4. Typical Quartus driver directories are drivers\usb-blaster and drivers\usb-blaster-ii; choose the correct one for your cable.
5. Reconnect or restart as required by the driver installation, then reopen Hardware Setup in Quartus.

Linux

1. Run lsusb before and after connecting the programmer. Record the newly appearing cable and its vendor/product IDs. If there is no new device, check the cable/port before changing permissions.
2. Run jtagconfig from the selected Quartus installation's executable directory. If it is not on PATH, use its actual full path, for example "/path/to/quartus/bin/jtagconfig". This detects cables/targets; it does not flash the core.
3. If USB sees the cable but Quartus cannot access it, install the udev rules supplied or documented for that cable and Quartus package. Match the IDs from lsusb; USB-Blaster, USB-Blaster II and third-party programmers need not share the same IDs.
4. If the package instructs you to create a rule file, use sudoedit /etc/udev/rules.d/51-usbblaster.rules, add its specified cable rules, save, then run sudo udevadm control --reload-rules.
5. Disconnect and reconnect the programmer's PC USB connection, then repeat jtagconfig and Quartus Hardware Setup. Do not disturb the powered target's internal ribbon.
6. Keep the full detection error if the cable is present but the FPGA is absent. Move to the JTAG-chain checks below; changing host permissions cannot fix a reversed ribbon or an unpowered target.

Use the cable maker's matching rule instead of globally granting access to every USB device. Do not use Linux command paths or driver installation steps on macOS.

Do not disable driver-signature enforcement as a generic workaround for an unidentified problem. A host driver must actually support the host and programmer you are using.

🔗 Quartus reports “Can't access JTAG chain”

Error (209040): Can't access JTAG chain means communication with the target chain failed. A later Error (209012): Operation failed does not replace that first useful error.

1. Copy the Programmer message pane from the first error onwards into a text file. Include the JIC filename, detected target and selected cable; a screenshot is acceptable if the log cannot be copied.
2. Confirm that the programmer is recognised and selectable on the PC.
3. Confirm that the V4 has its normal power during detection.
4. Remove all power before checking ribbon seating, pin-1 alignment and header condition.
5. Reconnect correctly, restore target power and retry Auto Detect in an empty list.
6. If needed, test a known-good compatible cable or programmer, changing one component at a time and removing power before each internal connection change.
7. If reliable detection cannot be established, stop and seek hardware/programmer support.

A selectable USB-Blaster does not prove that the target is reachable. A chain error does not, by itself, prove that the FPGA is permanently damaged. Formatting the CF is unrelated to this fault.

⚠️ Programming ends with a verification failure

1. Treat the result as unverified, even if the progress bar reached a high percentage.
2. Save the first error, log, JIC filename and target details.
3. Recheck image suitability, stable target power, reliable detection and programmer compatibility.
4. Retry only after correcting an identified problem or receiving specific support instructions.

Do not remove the loader helper, add an erase or force another device identity merely to obtain a successful-looking progress bar.

🧪 Test an update and roll back cleanly

🧪 Before trying a beta or faster build

1. Keep the working CF unchanged and prepare a spare copy.
2. Save the previous core and matching driver/utility packages.
3. Confirm that the candidate explicitly supports the board revision, fitted memory and selected clock variant.
4. Have a suitable recovery method available before testing a build that could stop normal boot or input.
5. Record the baseline behaviour with the current core so the comparison has a clear starting point.

✅ Check more than the desktop

After the update, perform these checks and note pass/fail:

1. Cold starts: perform three full power cycles. Confirm a usable desktop each time.
2. Memory: run Avail and compare with the baseline and fitted RAM, allowing for OS/display reservations. Do not infer physical RAM solely from the free-memory value.
3. Input: type letters, symbols and cursor keys in an unsaved editor document; test mouse movement, both buttons and menus.
4. Video: test the RTG desktop and one previously working native-screen game. Check the image edges and return to the desktop.
5. Storage: run the round-trip file test using the spare CF and transfer microSD.
6. Sound: play the same known-working game/audio file used before the update, checking both channels where appropriate.
7. Network: repeat the address, local-IP and DNS tests.
8. Applications: run the games and programs you normally use, then confirm that desktop, sound and network operation recover after closing them.

If software suddenly reports more physical memory than the board contains, stop write-heavy work and investigate the build and reporting tool. Do not deliberately fill the suspect address range.

If a faster variant is unstable but the supported lower-clock build works, retain the stable build. Increasing supply voltage is not a substitute for a suitable core.

⏪ Restore the complete working combination

1. If the current card reads reliably, preserve its newer files with a whole-device backup and copy important personal files to a separate recovery destination. A byte-verified backup preserves the current contents, including any existing corruption; check that important documents actually open. Keep the current card unchanged during rollback.
2. If the V4 is stable enough to flash, use ApolloFlash with the previously working JIC. If it cannot boot reliably, use the USB-Blaster recovery route. Check the rollback core's prerequisites before either operation.
3. Restore the preserved working CF image to a spare, verify it, then install it with the V4 fully unpowered. That restores the matching drivers, utilities, startup files and saved preferences from the backup.
4. Restore the recorded ROM arrangement. A disk-mapped ROM and its loader should be present in the restored CF image. If the working installation used a separately flashed ROM, complete the procedure below after restoring the JIC. The rollback is incomplete until that ROM is restored too.
5. Keep the current card and the preserved working backup separate. Restore personal files to the spare only after its basic tests pass; do not overwrite its newly restored startup files with an unreviewed copy of the broken setup.
6. Cold-start, compare Version and the configuration record with the working baseline, then repeat the same workload with the same peripherals.

Changing only the .jic does not undo changes on the CF. A successful rollback establishes that the previous combination works; it does not identify every individual change responsible for the failure.

🧩 Restore a separately flashed ROM after the core

Use this only when the baseline explicitly used a single, separately flashed ROM, and you have its exact previously working licensed image. A ROM mapped by a startup command is a different arrangement. Flashing the core again afterwards can replace this ROM, so restore the core first and the separate ROM last.

Utility scope: the positional-file command below applies to ApolloFlash 2.30, distributed as a standalone utility for ApolloOS and AmigaOS by Apollo Team, and the same normal image argument is used by 2.22 in SAGA Driver 3.4. Use a version approved for the target Standalone core. These steps do not add extended-ROM arguments, force options or an AmigaOS driver installation to ApolloOS.

1. Preserve the working ROM file, utility and old JIC on the host. If necessary, restore the previous compatible JIC using the core update or JTAG recovery procedure, then complete its cold restart.
2. Boot a CF that works reliably with that core's bundled ROM. If the restored working CF cannot boot until its separate ROM is reinstated, power down fully and use a spare rescue CF prepared for this core and bundled ROM. Keep the restored working CF aside. An arbitrary ApolloOS image is not a guaranteed rescue image for every core.
3. Transfer the preserved ROM and the matching standalone ApolloFlash executable through a working microSD transfer card. If obtaining the utility from Apollo Team's ApolloSoftware distribution, select Tools → ApolloFlash → 2.30 → C → ApolloFlash; copy that executable, not an entire driver package. Preserve the original ROM filename on the host. In the example below, replace Transfer: and KnownWorking.rom with the actual mounted volume and filename:

Copy Transfer:ApolloFlash TO RAM:ApolloFlash CLONE
Copy Transfer:KnownWorking.rom TO RAM:KnownWorking.rom CLONE
Protect RAM:ApolloFlash +E
Version RAM:ApolloFlash FULL
List RAM:KnownWorking.rom

1. Check the utility version and ROM byte length against the preserved files. The ROM must be the same single image previously used with the target core; a ROM for another machine, an encrypted distribution file or an archive is not interchangeable. Do not set an executable permission on the ROM.
2. Close other applications, maintain stable power and run:

RAM:ApolloFlash RAM:KnownWorking.rom

1. Read the reported board and image information before confirming. Proceed only if it identifies the intended Standalone and accepts the intended ROM operation. When asked to confirm, type YES in capitals and press Return. If the utility rejects the file, cannot locate the ROM area or reports an unexpected target, stop; do not add FORCE or guess an extended-ROM argument.
2. Wait for the utility to report successful completion, preserve the result and wait at least another ten seconds. Do not interrupt an active write. An error is not a completed restoration.
3. Switch off, remove all power paths and leave the machine unpowered for 30 seconds. If you used a rescue CF, fit the restored working CF while the machine is unpowered. Reconnect normally and boot.
4. Run Version and compare it with the recorded working ROM/OS versions. Then run the post-update checks. Keep the source files and rescue CF for future recovery; the copies in RAM: have disappeared.

If the ROM change prevents booting, the JTAG procedure can restore the compatible JIC and its bundled ROM; use the matching rescue CF again. If you do not have the exact old ROM or a compatible bootable rescue installation, stop before the ROM flash and obtain those missing components. Do not describe JIC-plus-CF restoration alone as a complete rollback of this setup.

🔍 Read-only checks

The commands below inspect devices or image files; they do not initialise, format or repartition them. They are not a hardware write blocker, and they do not prevent Windows or another application from writing independently.

For the routine measurements, use these complete procedures:

• Exact image length and physical-card capacity: Windows, macOS and Linux.
• SHA-256: Windows, macOS and Linux.
• Mounted-volume and version checks: AmigaOS and ApolloOS.

The following checks examine partition metadata without editing it.

🗂️ Inspect Windows-visible partition entries

On Windows, first use the Get-Disk identification procedure. In the same administrator PowerShell, run this block and enter the card's current disk number:

$answer = Read-Host 'CF disk number from Get-Disk'
$diskNumber = [uint32]0

if (-not [uint32]::TryParse($answer, [ref]$diskNumber)) {
    throw 'Enter a valid non-negative disk number.'
}

$disk = Get-Disk -Number $diskNumber -ErrorAction Stop
$disk | Select-Object Number, FriendlyName, SerialNumber, Size,
    PartitionStyle, IsBoot, IsSystem | Format-List

try {
    $parts = @(Get-Partition -DiskNumber $diskNumber -ErrorAction Stop)
    if ($parts.Count -eq 0) {
        Write-Output 'No Windows-visible partitions. This does not prove the card is empty.'
    } else {
        $parts | Select-Object PartitionNumber, DriveLetter, Offset, Size, Type |
            Format-List
    }
} catch {
    Write-Warning ('Windows partition query failed: ' + $_.Exception.Message)
}

An RDB disk can produce no recognised entries or a query error. Use an Amiga-aware image inspector for its actual layout. A Windows “RAW” or “unallocated” description is not permission to initialise the disk.

🗺️ Inspect the Amiga RDB in a copy of an image

The amitools package supplies rdbtool. This procedure installs it in a separate Python environment and reads an ordinary image copy, not a physical card. It works on Windows, macOS and Linux.

Prepare the tools once

1. Install Python 3 from the Python project on Windows/macOS, or through your Linux distribution. Open the appropriate command window.
2. In a working folder you own, create the environment and install amitools. Use only your host's block. These commands create v4-rdb-tools in the current directory:

Windows PowerShell:

py -3 -m venv v4-rdb-tools
.\v4-rdb-tools\Scripts\python.exe -m pip install amitools
.\v4-rdb-tools\Scripts\rdbtool.exe --help

macOS / Linux Terminal:

python3 -m venv v4-rdb-tools
./v4-rdb-tools/bin/python -m pip install amitools
./v4-rdb-tools/bin/rdbtool --help

1. Stop if installation fails. If py is absent on Windows but python --version identifies your installed Python 3, substitute python for py -3 in the first command. On Debian/Ubuntu, a missing venv component can be installed with sudo apt install python3-venv; then repeat environment creation. Other distributions have their own package names.
2. In the help output, confirm --read-only. No activation command or PowerShell execution-policy change is needed.

Inspect both images

1. Copy the original backup and replacement image into a working folder, keeping the preserved backups elsewhere. Do not open those same copies for writing in an emulator.
2. Stay in the folder containing v4-rdb-tools, then run the matching host command, replacing the image path:

Windows:

.\v4-rdb-tools\Scripts\rdbtool.exe --read-only 'C:\Images\replacement-copy.img' info
.\v4-rdb-tools\Scripts\rdbtool.exe --read-only 'C:\Images\original-copy.img' info

macOS / Linux:

./v4-rdb-tools/bin/rdbtool --read-only "/path/to/replacement-copy.img" info
./v4-rdb-tools/bin/rdbtool --read-only "/path/to/original-copy.img" info

1. Read the rows as follows:

1. For unused cylinder ranges, repeat the same command with free instead of info. This lists ranges; it does not create a partition. These ranges are within the recorded disk definition, which may not cover a larger destination's full capacity.
2. Save the output by adding > "replacement-rdb.txt" to the command, choosing a new text filename. Keep it with the image length/hash and the card's separately measured byte capacity.
3. If there is No RDB Disk, a geometry error or an unexpected range, stop and check the image format. A partition-only HDF or unsupported layout can produce that result. Do not use init, resize, adjust or other editing commands to suppress it.

Checking a partition's end position: the low/high cylinder values are inclusive. In the usual matching disk/partition geometry, use (high cylinder + 1) × surf × blk/trk × (blk_longs × 4) to obtain the byte offset just after that partition. The extra info lines provide surf, blk/trk and blk_longs; the latter is measured in four-byte units. Do not substitute the larger filesystem block size when it groups several sectors. If the geometry fields disagree with the disk definition or the units are unclear, retain the output for diagnosis rather than guessing a boundary.

This reveals the map and embedded handlers. It does not validate every file or prove that the V4's active storage driver supports that address range.

🖥️ HDToolBox cannot see an image in an emulator

1. Check which emulated controller exposes the image.
2. For a UAE controller using uaehf.device, start HDToolBox against that device. For example, if the tool is on the install disk in DF0::

DF0:Tools/HDToolBox uaehf.device

1. Use the actual HDToolBox path if it differs.
2. Inspect an image copy and exit without saving changes when diagnosing.

An emulated IDE controller can instead use the ROM's IDE driver. Match the tool to the configured controller; do not change the physical V4's driver entries to uaehf.device. Avoid simultaneous writers to the same image or physical card.

🛑 Stop when the next step would be a guess

Stop writes or hardware changes when:

• The CF develops repeated read errors.
• A populated partition suddenly appears uninitialised.
• A memory test fails repeatedly.
• A connector's orientation is uncertain.
• The JTAG target cannot be detected reliably.