🧛 Vampire V4 and V4+: Fix Boot Problems, CF Cards and Failed Updates

You replace the CompactFlash card, write an operating-system image, and Windows promptly offers to format it. Or you update the core, restart the machine, and discover that the desktop has disappeared. Neither is an invitation to start formatting things at random.

The awkward part of troubleshooting a Vampire V4 is that several different problems can look remarkably similar. A display that rejects an Amiga screen mode can resemble a dead computer. A perfectly copied card can contain the wrong boot environment. A firmware downgrade can leave newer graphics drivers behind and produce a fresh problem instead of fixing the original one.

This guide starts with the checks that leave your data alone, then works through card preparation, boot failures, peripherals, software compatibility and firmware recovery. You do not need to read it from beginning to end. Find the symptom, establish which part has actually failed, and change one thing at a time.

<a id="start-here"></a>

🧭 Start here: what changed before it stopped working?

🧩 Know which layer you are changing

There are five pieces to keep separate. Most of the confusion comes from treating them as interchangeable.

ApolloOS is based on AROS. AmigaOS 3.x uses a different software environment, including its own driver installation. Coffin and multi-boot packages add another layer of configuration. Throughout this guide, an instruction labelled ApolloOS or AmigaOS applies to that environment, not indiscriminately to everything the V4 can run.

The graphics hardware is called SAGA. Native modes are the classic Amiga display modes used by many games and boot screens; RTG modes provide a graphics-card-style desktop. P96, also known as Picasso96, handles RTG graphics in the relevant AmigaOS setup. Keeping those two display paths separate is useful when one works and the other does not.

This is a guide for the V4 / V4+ Standalone, not a FireBird, IceDrake, Manticore, V2 accelerator or the Unicorn board in an A6000. Similar names do not make their core files interchangeable. Board revisions, memory configurations and expansion boards also matter; the V4+ badge alone is not a complete hardware specification.

🛡️ Protect the working parts before touching the broken ones

Make a full-device image of the original CF, not just a copy of the files Windows happens to show. That backup must include the Amiga partition information and any boot or filesystem components stored outside ordinary files. Keep it on another drive, and keep the original card unchanged while testing a replacement.

A backup operation that reports read errors has not produced a verified, complete copy. Preserve its log and whatever data was recovered. When the card holds irreplaceable files, stop experimenting with writes and partition repairs on the original.

Record the working core filename, OS version and driver package before changing them. Keep the previous installation files as well as the new ones. A photograph of the boot screen and a text file containing these details are far more useful than trying to remember what “the old version” meant later.

⚠️ Safety: Firmware flashing, partition changes and internal connections can cause data loss or hardware damage. Use a spare card for experiments. Remove all power before handling internal connectors, and never interrupt an active flash. When a procedure does not match your exact hardware or software, stop rather than improvise.

<a id="cf-images"></a>

💾 CF cards and disk images: fix the copy before fixing the computer

🕵️ The old card appears in Windows, but the replacement does not

💡 This does not, by itself, mean the write failed.

A CF card can contain Amiga partitions that Windows does not understand. Some installations also include a FAT partition for exchanging files with a PC. Others do not. Writing a different system image can therefore produce a perfectly usable Amiga card with no Windows drive letter at all.

The important question is not “Why has Windows stopped showing the same drives?” It is “Did I restore the original card, or install a different image?”

A new operating-system download is not a clone of your previous installation. Its partition layout may differ even when both downloads are intended for the same machine. A raw-image writer copies the layout already present in its input; it does not add a Windows-readable partition as a convenience.

📋 Work through this in order:

1. Identify the exact image you wrote and confirm that it is intended for your Standalone and boot environment.
2. Compare its extracted size, not the size of the compressed download, with the card's capacity.
3. Verify the written image against the card before changing the card's contents.
4. Inspect the image's Amiga partition layout using the read-only checks.
5. If your aim was an exact replacement, restore the verified whole-card backup of the original, rather than an unrelated distribution image.

If the replacement verifies correctly and boots normally in the V4, the absence of a Windows drive letter is not a fault to repair. For routine file transfers, use a separately prepared microSD transfer card or a working network connection instead of redesigning the system disk.

🛑 Windows asks to initialise or format the card

🛑 Cancel the prompt. Windows is offering to make the device usable by Windows; it is not repairing an Amiga installation.

Amiga disks commonly use an RDB, or Rigid Disk Block, rather than the MBR or GPT layout familiar to PC tools. They can also use filesystems such as SFS, PFS3 or FFS that Windows does not normally mount. An unfamiliar layout may therefore appear as RAW, unallocated, missing partitions or a drive that needs formatting.

A writer's “missing partition table” warning can be harmless when it simply does not recognise a valid Amiga layout. An actual input/output error, incomplete image or failed verification is different. Do not wave away every warning just because some Amiga images trigger an expected one.

Check what the supplied image is supposed to contain and verify the copy. Do not initialise the disk, run diskpart clean, create a replacement partition table or accept a repair prompt to make the warning disappear.

🖥️ The image boots in an emulator but not in the V4

An emulator can supply things that a physical card must contain for itself.

There are two common kinds of HDF file: a whole-disk image, which includes partition information, and a partition-only image, which does not. An emulator can wrap a partition-only image in a virtual disk structure. Writing that same file directly to a CF does not create the missing physical-disk layout.

Confirm the image type before writing it. Renaming .hdf to .img changes nothing inside the file, and finding or not finding four particular letters at byte zero is not a complete layout test. Use a proper image inspector and the installation's stated requirements.

The emulated storage controller matters too. uaehf.device is an emulator device, not the real V4's disk driver. A successful boot through it does not prove that the ROM, controller and filesystem used by the physical machine can access the same partitions.

For a replacement system card, use a whole-device image intended for that installation or carry out its actual installation procedure. A partition-only HDF can be useful as a mounted image; it is not automatically a ready-to-write CF image.

📦 The image will not extract, even though the PC has plenty of space

Check the filesystem of the PC drive receiving the extracted file.

FAT32 cannot hold a single file larger than 4 GiB minus one byte: 4,294,967,295 bytes. A drive can have ample free space and still reject a large disk image. Extract the image onto a suitable host filesystem, such as NTFS on Windows or exFAT where appropriate, with enough free space for the complete output.

This is a change to the backup or download destination on the PC. It is not a reason to format the Amiga CF.

Also check that extraction actually finished. A failed extraction may leave an incomplete .img behind. Its existence, plausible filename and large size do not prove that it is complete. For a split archive, make sure all parts are present before extracting the first part with the appropriate archive tool.

📏 A second “128 GB” card is too small

Compare exact byte counts, not the capacity printed on the label.

The target must be at least as large as the complete image file. Two cards sold under the same capacity label need not expose exactly the same number of sectors. A full-card backup from one can therefore be slightly too large for the other.

A separate source of confusion is the unit being displayed: 128,000,000,000 bytes is about 119.21 GiB. That difference does not mean the card has lost space.

Use a target that is genuinely large enough. Do not truncate the image because “there were only a few gigabytes of files on it”. The partition map or filesystem may refer to sectors near the end, even when most of the volume looks empty.

✍️ Write the replacement card properly

Use a spare card and keep the original unplugged from the PC during the write. Disconnect other removable disks that might be selected accidentally.

A raw-image writer copies the image to the device, replacing its contents. Dragging system.img onto a formatted card merely creates an ordinary file. It does not restore the disk represented by that image.

1. Prepare the input. Extract the archive completely. Some writers support particular compressed formats directly, but an extracted image removes that ambiguity and lets you check its exact size first.
2. Identify the destination. Match the reader, card capacity and selected device. Recheck after reconnecting anything; device numbers can change.
3. Select raw-image writing. Use a tool that accepts the supplied image format and writes it without converting its layout. Win32 Disk Imager can also read devices into backup images; Etcher provides an image-writing workflow. A refusal to recognise an Amiga image is a reason to inspect the input, not to let a tool invent a new PC layout.
4. Write and verify. Read the actual completion message. Do not treat a full progress bar as proof that verification passed.
5. Safely eject and reconnect. Cancel any Windows format prompt, then perform a readback verification before the first V4 boot or any partition changes.
6. Test the unchanged copy. Power the V4 off fully before installing the CF. Check booting and basic operation before expanding its partitions or adding software.

If the write fails, keep the first error and establish whether it came from reading the source file, writing the card or reading it back. Switching between writers without knowing which stage failed is mostly a way of collecting more progress bars.

🔍 What a successful verification actually proves

For an image containing N bytes, verification must compare those N bytes with the first N bytes of the card. Checking only the beginning leaves the rest untested.

An 8 GB image written to a larger card should match over the image's length. A hash of the entire larger card will not normally equal the hash of the smaller image, because the inputs have different lengths.

There are three different checks here:

None substitutes for the others. A perfect copy can still be the wrong image for the machine. A card that boots once can still have faults in areas not yet accessed.

Perform the comparison before booting or expanding the card. Once the OS writes preferences, logs or other data, differences may be legitimate. Keep a readback image when the writer cannot provide a suitable independent verification; the comparison must still use equal lengths.

🗜️ A small download seems to occupy the whole card

A compressed archive, a disk image, a partition and a filesystem's used space are four different measurements.

A mostly empty 32 GB disk can compress into a much smaller download. Restoring that image restores its partition allocation as well as its files. Conversely, a 128 GB card can be fully partitioned without being full of data.

Check the physical card size, extracted image length, partition sizes and used space inside each mounted filesystem separately. Windows cannot provide meaningful file-usage figures for an Amiga filesystem it has not mounted.

Do not resize partitions merely to make a percentage or coloured bar look more reassuring. An implausible Amiga-side usage figure can also be a reporting-tool or filesystem-version problem; confirm the actual layout before treating the display as a storage shortage.

<a id="power-startup"></a>

🔌 Power and startup: a black screen is not a diagnosis

🥶 The machine freezes, resets or behaves unpredictably

Start with the power path, especially when several unrelated things fail together.

Use the correct supplied or approved 5 V power supply and its proper power lead. A cable that fits is not necessarily suitable; a thin lead, an inline switch or an unsuitable replacement can cause voltage drop. Choose any replacement supply by the rating required for the complete machine and its expansions, not by an old specification for another Vampire board.

Disconnect unnecessary USB devices, video switches, converters and other additions. Test a direct video connection and a short, known-good power lead. If the machine becomes reliable, reconnect the extras one at a time and repeat the same workload.

Do not increase the supply voltage as a speculative fix. A supply with an adequate current rating is useful; guessing a higher voltage is not. Internal measurements and board-level faults belong with someone equipped to investigate them safely.

If instability began after a core update, the new core or its associated software is a strong suspect, but the timing does not prove the cause. A changed workload or faster build can expose a marginal power or hardware condition. Compare against the previously working core-and-software combination, with the same peripherals and workload.

⚠️ Do not flash from an operating system that is already freezing or resetting. Stabilise it first or arrange the appropriate recovery route.

🔄 Switching off does not seem to clear the problem

Removing the main supply is not always enough. Connected equipment can keep parts of the board powered through other leads, preventing a genuine cold start.

Finish disk activity, remove the main power, and disconnect external connections that could keep the machine energised, including video, Ethernet and a connected programmer. Leave it fully unpowered for 30 seconds, then reconnect and start it normally.

For an ordinary warm reset on a compatible PC keyboard, the combination is left Ctrl + Windows + right Ctrl. Use it only after writes have finished. A warm reset does not replace a full power-off when testing a ROM mapping or completing a core update.

🖥️ There is no picture at all

First remove the avoidable variables: select the correct display input, connect the V4 directly, and try a known-good video cable. Temporarily bypass splitters, switches, capture devices and converters.

Next, hold both mouse buttons while powering on to try the Early Startup menu. This requires a mouse recognised at power-on. Failure to open the menu with an incompatible mouse does not prove that the core is dead.

If the menu is not visible, try its PAL/NTSC switching key. Try Tab; some core environments accept any key for this switch. This can make a difference when a display accepts one timing but not the other.

Native Amiga output commonly uses 720 × 576 at 50 Hz or 720 × 480 at 60 Hz. A monitor handling the high-resolution desktop successfully may still reject a native game or boot mode. Try another suitable monitor or television before escalating to firmware recovery.

💡 What the result tells you: a visible Early Startup menu establishes that the machine can produce that boot display. If the picture disappears only when the desktop loads, investigate the saved screen mode and graphics drivers first. See Graphics, games and applications.

🌈 Coloured stripes appear during startup

Brief changing colours are not the same as a persistent error pattern. The normal self-test can pass through rainbow, blue, green and grey screens. Do not interrupt a boot merely because you saw green for an instant.

On supported cores, a separate diagnostic BootMenu provides tests such as memory checking. It can be entered at power-on with Help, commonly Page Up or Page Down on a PC keyboard; supported Apollo joypads can also provide an entry shortcut. This is not the same menu as the two-mouse-button Early Startup screen.

A persistent memory-test error is not an invitation to increase voltage, heat the board or start soldering. Red stripes after an interrupted flash are not a reason to format the CF.

📦 The CF stopped being detected after moving the machine

A card or adapter can become loose in transit. A logo or boot screen with no progress makes storage detection worth checking, although a logo alone is not a complete diagnosis on every core and custom boot setup.

Remove all power, including connections that could backfeed the board, before inspecting internal storage. The 44-pin IDE connection carries power as well as data. Reversing it or offsetting the connector by a row or column can damage the board or storage device.

⚠️ Do not push the CF or its adapter into place through the case opening. Support the assembly properly. Reseating may require removing the board from its enclosure; use the procedure for that enclosure and take antistatic precautions. Keep the board clear of conductive surfaces, avoid flexing it, and check alignment before applying any pressure.

If the machine is under warranty, or the connector orientation is uncertain, ask the supplier before opening it. Do not copy a photograph from an accelerator-card installation and assume that it shows your Standalone's arrangement.

Once the card is detected, a failure to boot becomes a separate storage or software question. Repeatedly reseating a detected card will not fix a missing filesystem handler.

🚦 Early Startup works, but normal boot stops

Try booting without the Startup-Sequence from Early Startup. That bypasses the main startup script instead of changing anything on disk.

A usable shell is an important clue: the fault may be in a startup command, a driver loaded later, a ROM-mapping step or the desktop configuration. It is not proof that every sector of the card is healthy.

Back up S:Startup-Sequence and S:User-Startup before editing. Check the last change first. Temporarily disable one suspected command, restart, and restore it if the result is unchanged. Do not delete the startup files wholesale, particularly on a multi-boot installation where they may select the correct ROM or system partition.

If the operating system no longer boots immediately after a core update, also check what a core update changes. The new core may have replaced a separately flashed Kickstart while leaving all the CF files intact.

<a id="storage-faults"></a>

🗄️ Storage faults and larger cards

🧩 Partitions exist, but the system cannot mount them

A partition entry tells the system where a volume is and which filesystem it uses. It does not guarantee that the running environment can read it.

The Amiga RDB can store filesystem-handler code as well as partition definitions. That matters during boot: a handler sitting as an ordinary file on an inaccessible partition cannot necessarily help the system mount that same partition.

Inspect an image copy, checking the partition types, ranges and stored filesystem handlers. Compare them with the ROM, disk driver and OS that will actually boot the card. Do not replace the handler with a random newer binary merely because it has a familiar name.

Changing a partition's filesystem identifier is not a conversion. Relabelling SFS data as PFS3 does not turn it into PFS3. Similarly, a populated partition appearing as uninitialised does not make it safe to format.

Restore the correct handler or boot arrangement only after preserving the data and identifying the intended layout. If an image copy mounts in an emulator but the hardware does not mount it, compare the two storage environments rather than immediately rebuilding the filesystem.

🔍 A partition appears in one installation but not another

Large-disk support depends on the complete chain: ROM, disk driver, access method and filesystem.

Older disk-access interfaces have a 4 GB addressing boundary. A newer filesystem alone does not remove a limitation in the driver beneath it. Even a small partition can be affected if it starts far enough into a large card.

On a legacy AmigaOS installation, check whether the boot ROM's scsi.device can reach the boot partition. A disk driver loaded later from the startup script cannot help the machine reach files it cannot read in the first place. Updated ROM environments can change that limitation, but use the ROM and driver combination intended for the installation.

PFS3aio checks which disk-access methods are available. If it cannot address a partition beyond the old boundary, it may leave that partition unmounted without presenting the error message you expected.

The useful test is therefore not just “Is this partition under 4 GB?” It is “Can this boot environment address all of this partition, including its end?” Inspect its start and end positions before moving or resizing anything.

🩹 Files copy successfully, but the copies are corrupt

Stop writing to important data and keep a known-good source file for comparison.

Establish where corruption first appears. Does the source file read correctly on the PC? Does writing and reading back the spare CF through the PC produce an exact match? Does corruption appear only when the V4 writes to the card? Those are different faults and need different tests.

On the V4, a poor connection, excessive IDE timing or inappropriate partition transfer settings can cause trouble. On the PC, the reader, its cable or the card itself may be responsible. A V4 timing adjustment cannot repair a PC-only read failure.

Use expendable data on a spare card and change one component or setting at a time. A small successful copy does not validate the whole card. Repeat the operation that failed and compare the resulting bytes, rather than opening one file and declaring success.

⏱️ Check accelerated IDE settings before adding more tweaks

VControl and its newer counterpart, ApolloControl, can expose storage-timing controls. A setting that works with one card and a short connection may fail with another adapter or longer cable.

If the problem began after an IDE-speed command was added to startup, preserve the script and remove that recent change for a controlled test. Perform a cold start and check the installed utility's help for the active setting. Do not copy speed values from an old utility version without checking that the syntax and defaults still match.

The microSD clock is a separate setting from the internal IDE speed. Changing one is not a general repair for the other.

⚙️ Use the right Mask and MaxTransfer for the actual setup

MaxTransfer limits the amount of data a filesystem requests in one operation. Mask constrains the memory addresses allowed for transfers. Neither setting creates partitions, changes the IDE clock or makes an Amiga volume appear in Windows.

For the ApolloOS HDToolBox workflow using ata.device, the specified values for a newly created partition are:

In that HDToolBox interface, open the partition's DosEnvec settings, enter the values, press Return to commit each field, return with Parent, select the drive and Save Changes. Reboot, reopen the settings to check them, then test with expendable files.

Use this pair only for the matching workflow. A classic A1200 example, an emulator, a different controller or a customised multi-boot image may use a different arrangement. Record existing values before editing any established partition, and do not turn a familiar hexadecimal number into a universal cure.

If a setting was causing corruption, correcting it prevents the same mistake from happening again; it does not reconstruct files already damaged. Recopy those from a verified original.

🚨 PFS3 reports “Wrong Index Block ID”

Treat a filesystem-corruption error as a reason to preserve data, not to try every repair switch you can find.

First confirm that the affected partition actually uses PFS3, and identify the active handler version. SFS and FFS need their own procedures. Then check the exact conditions: OS version, partition size, disk driver and whether a special access mode is enabled.

More than one defect can produce Wrong Index Block ID, including filesystem bugs exposed by creating many small files. PFS3aio has received fixes for such defects, but the error text alone does not identify which cause applies.

There is also a particularly important version-specific case: PFS3aio 3.0 with the affected AmigaOS 3.1.4 SCSIDIRECT support can corrupt a partition. Version 3.1 corrects that defect, but an affected filesystem still needs rebuilding after its data has been recovered. Merely replacing the handler does not undo existing damage.

That is not an instruction to format every partition reporting an index error. Preserve an image first, recover or back up the files, establish whether that exact defect applies, and rebuild only when the diagnosis requires it. Run repair experiments on copies rather than on the sole surviving card.

⚠️ PFS3 warns about an experimental partition size

Some PFS3aio releases label >104G partition support as unsupported and experimental. Take that warning seriously for the version being used; it is not simply asking whether the card has enough free space.

This concerns the individual partition, not simply the capacity printed on the CF. A 128 GB card does not have to contain one partition approaching the full size of the device.

For a new layout, stay within the supported limits of the filesystem and driver you are actually using. Do not dismiss a formatting warning because the card is large enough, and do not redesign a populated card without a full backup.

📐 A larger CF still shows the old image's capacity

Restoring a small image to a larger card does not automatically enlarge its partitions. There may also be a disk definition in the image that still describes the smaller original device.

In the matching ApolloOS environment, ApolloMax updates the disk definition so the additional space becomes available. HDToolBox is then used to create partitions in that space.

That is not the same as safely stretching an existing filesystem. In this ApolloOS workflow, resizing an existing partition loses its data.

Before running ApolloMax, verify the restored image and save a full backup. Confirm that the tool is targeting the correct driver and unit, then inspect the result before adding anything. On a custom installation, do not assume that a launcher inherited from another image points at the right disk.

The safe goal is a new partition in genuinely unused space, without moving, overlapping or resizing the existing ones.

🧭 ApolloMax appears to do nothing, or Personal: is not where expected

Names such as Personal: can represent a volume or an assign to a directory. In a multi-boot setup they may also refer to shared content used by several operating systems.

An Amiga device name such as DH12:, a volume label such as Personal:, and an assign are not interchangeable descriptions of the same thing. Check the partition map and active assigns before changing paths or deciding what to enlarge.

Likewise, ata.device, scsi.device and uaehf.device are not alternative spellings. They belong to different storage arrangements. Inspect the tool's launcher or script and match its device and unit to the working installation.

Do not replace every occurrence of scsi.device with ata.device, or boot another distribution and resize the card from there, just because someone else's screenshot looks similar. A multi-boot image needs a layout-aware procedure that preserves all of its boot environments.

➕ Add a new ApolloOS partition without disturbing the existing ones

⚠️ This procedure is for a deliberately created empty partition in the matching ApolloOS / ata.device setup. It is not a recovery procedure for a volume containing files.

1. Back up the complete card and open HDToolBox on the correct device and unit.
2. Inspect the existing partition ranges and select genuinely unallocated space. Do not resize a populated partition to make room.
3. Create the new entry, give it a unique device name and enable Automount. Check the chosen filesystem and its size limit.
4. Set the appropriate Mask and MaxTransfer values described above. Press Return after editing each field.
5. Check that the new partition ends within the physical card and does not overlap another partition.
6. Return with Parent, select the drive, Save Changes, and reboot so the system rereads the partition information.
7. Confirm the identity of the newly created, empty volume before using Quick Format on it. Then copy and verify expendable files.

An asterisk in HDToolBox can indicate a modified entry with unsaved changes. It is not, on its own, proof that a name is duplicated. Check the names explicitly and make sure changes are saved at the drive level.

A known edge case in this ApolloOS partitioning workflow can allocate one cylinder too many when using the remaining space. Before rebooting, check the proposed high-cylinder value. Where that specific error applies, reducing the new empty partition's high-cylinder count by one corrects the boundary. Do not apply that shortcut to a populated partition or to an unrelated disk utility.

If an old, populated partition appears uninitialised after these changes, do not format it. Stop and compare the new map with the backup.

📦 Programs are broken even though the raw image verified

Verification confirms that the image was copied. It cannot correct mistakes already present inside that image.

Amiga software archives can contain filenames, protection bits and other metadata that a host extraction tool does not preserve correctly. Unpacking an LHA or LZX archive into a Windows directory and copying the resulting files back is therefore not always equivalent to extracting it on the Amiga.

Keep the original archive, transfer it intact, and extract it inside an appropriate Amiga environment onto test storage. Compare that result before replacing the installed copy. Do not make blanket permission changes across the whole system to compensate for an unidentified extraction problem.

This concerns individual files prepared before imaging. A raw sector copy does not translate filenames or silently redesign the filesystem.

<a id="peripherals"></a>

🔗 Peripherals and connections

⌨️ A USB keyboard or mouse does not work

The built-in USB input support is not a general-purpose PC-style USB stack. Compatibility with an ordinary computer is not enough to establish compatibility with the V4.

USB keyboards and mice need the supported boot-protocol behaviour. Complex composite devices, built-in hubs and some keyboard/mouse switches can prevent that from working. For diagnosis, connect a simple, known-compatible device directly to the port assigned to that function on your unit.

Do not assume every V4 revision has the same number or arrangement of USB sockets. Use the markings and hardware layout for your actual board and expansion setup. The native input ports are not a route for copying files from an ordinary USB storage stick, and adding an Amiga USB software stack does not transform them into general-purpose USB controllers.

If a mouse works only after unplugging and reconnecting it once the machine has started, startup timing is a plausible compatibility issue. Try that as a mouse-input test, then replace it with a known-compatible device if reliable cold-start input is needed. Remember that you need a mouse recognised at power-on to use the two-button Early Startup shortcut.

A keyboard that stops working immediately after a core change deserves a board/core compatibility check before a shopping trip. Use a core explicitly suitable for the board revision. Replacing working hardware is a poor first response to a software change.

🎮 Keyboard layout, gamepad buttons or DB-9 input are wrong

For incorrect characters, select the right OS keymap; AmigaOS installations may need the keymaps supplied with their SAGA package. A keymap fixes character mapping, not a device that fails to initialise.

Windows keys commonly provide Amiga-key functions, and Page Up or Page Down can provide Help. Keep that mapping in mind when following an Amiga keyboard shortcut.

For a supported USB gamepad with a D/X mode switch, use the required D mode. Do not assume every USB gamepad offers the right protocol simply because it has a similar switch. Supported pads can be presented to software as CD32-style controllers, but individual games must support the extra buttons too.

DB-9 support depends on the input device and core implementation. Use an appropriate Amiga-compatible device and the instructions for the installed core. Do not assume that any controller with a nine-pin plug is electrically suitable.

🕰️ The clock is wrong after every power-off

A base system without a fitted battery-backed real-time clock cannot retain time by itself when unpowered. That behaviour is not evidence of a corrupt OS installation.

For a correctly installed DS3231 RTC module, first set the system date and time. On the matching installation, save it to the module with:

I2Clock CHIP=DS3231 SAVE

To load it at startup, add this to S:User-Startup only if an equivalent clock-loading command is not already present:

I2Clock CHIP=DS3231 LOAD

AmigaOS needs the appropriate I2C driver and utility installed. Test by shutting down, removing power and starting again. If time is still lost, check module detection and its battery rather than repeatedly rewriting the startup file.

Fit only a suitable module using the correct pinout and voltage requirements. A board labelled DS3231 is not automatically the right physical module to push onto the header, and a direction-only instruction is not a substitute for checking the pins.

🔊 There is no sound, or it comes only from the display

The standard Standalone carries digital audio through its HDMI-style Digital Video output. A separate analogue jack depends on the fitted expansion hardware.

Start with the simplest path: direct connection to a display that supports audio, the correct audio input selected, and its volume and mute settings checked. An HDMI-to-DVI path may provide a picture without a usable audio route.

If classic-game audio works but an application is silent, inspect the application's output settings and, on AmigaOS, the AHI configuration and installed audio driver. If nothing produces sound, concentrate on the common output path first.

External speakers can be fed through a compatible display audio output or a suitable HDMI audio extractor. Any extractor must also pass the video modes used by the V4; adding one is not a guaranteed cure, and it should be removed again when diagnosing a new blank-screen problem.

🌐 Ethernet is connected, but networking does not work

On AmigaOS, the Standalone's onboard Ethernet driver is v4net.device, normally installed under DEVS:Networks/. The OS also needs a configured TCP/IP stack. Installing a driver does not itself supply an IP address, route or DNS settings.

Check the connection in layers:

A successful reachability test is useful evidence; a failed ping is not definitive when the destination blocks it. Compare with another device on the same network where possible.

Use DHCP first unless the network is intentionally configured otherwise. A temporary static address is a diagnostic alternative only when you know the correct subnet, gateway, DNS and an unused address. Do not copy arbitrary IP values from a tutorial or choose an address that another device may already be using.

If networking fails only after leaving a WHDLoad game, check that its cleanup script restores the stack. See WHDLoad freezes or exits with an interrupt error.

💾 A microSD transfer card is not the same as the system CF

For a straightforward file-transfer setup, a supported SDHC card, normally 4–32 GB, using FAT32 is the conservative starting point. If the V4 already reads the card, leave its format alone.

In ApolloOS, use the SD Card → Mount option in the Start Menu when required. If a known-supported transfer card is invisible and genuinely needs preparing, back up its contents first and format that card only with an MBR/FAT32 transfer layout. In Rufus, the corresponding basic choices are Non bootable, FAT32, label SD0, and Quick format; disable extra label/icon creation where offered.

Do not apply that recipe to a CF holding an Amiga system image. Larger SDXC cards and other formats require explicit support from the installed driver and setup; being readable on a PC is not the test.

AmigaOS 3.x uses the separate sagasd.device arrangement. Depending on the installed package, it may require a generated or card-specific MountList. Do not reuse a hand-written MountList from a different card, and do not copy low-level formatting or FAT-header patches into an unrelated installation. Where installed, SDDiag can help check detection; further diagnostics must use the correct SD device.

SD boot support is core-dependent: it was added in the 11K core generation, so an older blanket statement that the slot can never boot is no longer reliable. A bootable SD installation still needs the appropriate layout and boot environment; a FAT32 transfer card does not become a system disk merely by inserting it.

Finish transfers and unmount safely before removal. The spring-loaded slot releases by pressing the card until it unlatches, not by pulling it out against the mechanism.

<a id="graphics-games"></a>

🎮 Graphics, games and applications

🖥️ Saving a new desktop resolution produced a black screen

AmigaOS with the SAGA/P96 RTG setup: hold Shift during boot to bypass loading the RTG screen modes and fall back to a basic native display.

Once you have a picture, open ScreenMode preferences, select a mode the display supports, and test it before saving. In a P96 installation, modes that do not work can also be disabled in SYS:Prefs/Picasso96Mode.

This is not a universal ApolloOS/AROS recovery shortcut. Use the screen-preference recovery method belonging to that environment rather than assuming that an AmigaOS driver feature applies there too.

If a desired RTG mode is missing rather than black, check the driver's available video-memory allocation. The SAGA/P96 setup uses the VideoMemSize tooltype in DEVS:Monitors/vampiregfx.info; modes that exceed the reserved buffer can be hidden. A tooltype is a setting stored in an icon's information, not a command to run in the Shell. Record the existing value and use settings suitable for the installed driver and board.

Do not begin by inventing monitor timings. First establish whether the problem is an unsupported saved mode, a driver mismatch or a mode excluded by the current configuration.

🖱️ The pointer disappears, doubles, or clicks in the wrong place

These symptoms deserve a core-and-graphics-driver compatibility check, particularly when they begin immediately after an update or downgrade.

A core can change how hardware cursors work. A driver intended for that implementation may not behave correctly with an older core. Restoring the old .jic while leaving newer graphics files on the CF therefore does not necessarily restore the old working system.

Use the complete driver package appropriate to the OS and selected core. Preserve the old package first, and use the installer or distribution update procedure rather than borrowing a single vampiregfx.card from a different release.

Test pointer movement, clicks, menus and screen edges. If the issue appears only inside ShapeShifter, test both the Amiga desktop and the emulated Macintosh desktop. A problem confined to one application may require an application-specific fix rather than a global driver replacement.

Do not treat historical beta-driver numbers as a permanent compatibility table. The safe target is a known-matching combination, not whichever binary has the largest version number.

🔎 ApolloOS loses its high-resolution modes after an update

Check the core's required ApolloOS and graphics components before reinstalling AmigaOS driver files over it. ApolloOS and AmigaOS do not use identical installation procedures.

If the modes were present immediately before the update, keep that original card or image intact. Restore the previous matching setup for comparison, or apply a corrected release explicitly suitable for the board. Test both the high-resolution desktop and a native screen afterwards.

A newer beta working on another machine does not establish that it supports your board revision, RAM configuration or peripherals. See Testing and rolling back.

🖼️ The picture is stretched or cropped

Fix the display's scaling before changing the computer's firmware.

Classic Amiga output is normally intended for a 4:3 presentation. A widescreen display set to stretch every input across the panel can turn that into a very unconvincing widescreen game. Try the monitor's Aspect, Original, Auto or equivalent setting and check the result rather than assuming every manufacturer's “Auto” behaves identically.

For cropped borders or missing edges, disable zoom or overscan; a display's PC mode, Just Scan or 1:1 setting may help, depending on how it handles that input.

Test a native game separately from the RTG desktop. Pixel-for-pixel scaling and the intended picture aspect are related but not identical, especially with old video timings. Keep the setting that produces the correct shape and visible image, rather than blindly forcing one scaling option for every mode.

🐢 Scanlines appeared, or everything suddenly became slow

On supported cores, F11 toggles scanlines and F12 toggles turtle mode, a deliberate slowdown for software that struggles with a fast CPU. Check those before treating a changed picture or speed as a new fault.

A game launcher or startup command may also set a compatibility speed. If the slowdown returns only when launching a particular title, inspect that launch configuration rather than repeatedly toggling the machine back afterwards.

Control options vary across core and utility generations; newer cores can expose additional speed modes. Check the installed ApolloControl or VControl help before adding persistent settings. For the AmigaOS SAGA/P96 driver, scanlines can also be controlled through the driver's icon tooltypes.

A cold restart is a useful baseline test, but a startup script can reapply the same setting. Check both the current state and what is setting it.

<a id="whdload"></a>

🧊 WHDLoad freezes or exits with an interrupt error

WHDLoad takes over the machine to run installed classic games. On AmigaOS, background networking or an added software USB stack can interfere with that takeover.

First close network applications and stop the relevant stack using its normal shutdown procedure. If using a Roadshow demo, dismiss its shutdown message before starting the game. Do not confuse an added software USB stack with the V4's hardware-provided keyboard and mouse support.

Retest the same title with the same settings. If it now works, automate the known-working shutdown and restart commands through WHDLoad's startup and cleanup scripts. Back up the existing configuration first; distributions may already have useful scripts that should be adapted rather than overwritten.

The usual integration points in S:WHDLoad.prefs are:

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

An existing configuration may call these scripts directly without Execute; do not change a working invocation just to match this example. Those lines call scripts; they do not supply the correct network commands by themselves. Configure the scripts for the stack actually installed, then check that networking is restored after leaving the game. Do not paste an empty replacement over an existing working script.

For the specific NMI Autovector condition, NoAutoVec can prevent WHDLoad from exiting on an unexpected autovector interrupt. It is a workaround, not a repair of whatever generated the interrupt. Test it on the affected installation before making it a global default, and remove it if it does not address the symptom.

ChkInts is different: it enables extra interrupt checks and can stop the program with diagnostic information. It is useful for investigating an interrupt problem, not a general “stop crashing” option. Do not add both settings everywhere simply because their names appear in a troubleshooting list.

These AmigaOS stack-conflict instructions should not be assumed to describe the same behaviour under ApolloOS/AROS. Apply the workaround to the environment and failure you have actually identified.

🕹️ One game fails, while everything else works

A single title showing colour bars, corrupt graphics, broken sound or a lock-up can be a game-specific compatibility problem. It does not establish that the core is corrupt or that the CF needs rebuilding.

Check the game's requirements, patch or WHDLoad slave version and any stated core restriction. Try its supported compatibility settings one at a time. Keep the working defaults for other games.

When comparing cores, keep the same game files and launch settings. When comparing game patches, keep the core unchanged. Otherwise, a successful run will not tell you which change mattered.

A fix confirmed for one historical title on one beta is not a reason to recommend that beta to everyone. Use a supported core that suits the complete system, and report a reproducible title-specific problem with the exact versions involved.

🍎 ShapeShifter has a startup or pointer problem

Separate the symptoms. A duplicate pointer points towards the graphics path described above; failure to start the emulated Macintosh can involve its memory setup instead.

Do not combine ShapeShifter's PrepareEmul memory preparation with a Vampire setup that already performs the relevant low-memory reservation. Preserve the launch script and check for duplicated or conflicting preparation steps. Other ShapeShifter requirements, including its ROM and configuration, still need to be correct.

Test the Amiga host desktop first. A healthy host with a broken emulated desktop narrows the investigation considerably more than replacing several host libraries at once.

⌨️ Pressing Space iconifies IBrowse

If this happens consistently while typing, inspect the MUI iconify hotkey before replacing the keyboard or keymap.

In the applicable IBrowse/MUI interface, open:

IBrowse → Preferences → MUI… → System → Hotkey

Check for a shortcut using Space or another key you need for normal input. Record the existing setting, choose a non-conflicting shortcut, and test both typing and the intended iconify action. Labels may differ with MUI versions; the setting to find is the window/system iconify hotkey.

Only a matching shortcut conflict calls for this change. Random input errors in several applications belong back in the peripheral and power checks.

<a id="firmware-update"></a>

🛠️ Updating a working V4 without creating a recovery job

🎯 Choose the core by hardware, not by the largest number

A normal update starts with an exact match: Standalone model, board revision where specified, fitted RAM, release type and any clock/build variant.

The Amiga Standalone core is normally named STANDALONE_<build>.jic. In the downloads list, select the Amiga ApolloStandalone entry. A category mentioning “V4-SA” is not enough by itself, because the same hardware can also have a separate Atari core. The Atari core is a different intended machine, not an Amiga update.

Never use a core for a V2 accelerator or another V4-family board. A wrong hardware image can cause serious damage, and renaming the file does not change its target.

Use a supported public release unless you are deliberately testing. A higher build number can be a development build, and a faster variant can be unsuitable for an otherwise functional board. Keep the previous working core and a full CF backup before continuing.

🧰 Update the required utilities as well

Check the target release's required ApolloFlash, ApolloMap and graphics/driver components before flashing. Older tools can be unsuitable for a newer core format or feature set.

On AmigaOS 3.x, these components are distributed through the appropriate SAGA package. ApolloOS and prepared distributions can bundle their own versions and update procedures. Do not apply one environment's installer to another merely because a utility has the same name.

Do this preparation while the machine still boots normally. Downloading the right recovery files is much less convenient after the keyboard or desktop has disappeared.

⚡ Flash from the Shell

⚠️ Use this route only on a stable, reliably booting system. ApolloFlash is a command-line tool; a .jic file is data, not an application to double-click.

1. Extract the approved core package and complete any prerequisite utility updates. Close other applications and finish disk writes.
2. Copy the .jic to an accessible location. Open a Shell and run ApolloFlash with its full path.
3. Read the confirmation carefully. Check the target and filename, then enter uppercase YES only when both are correct.
4. Leave the machine alone until the operation reports success. Do not use the OS, reset, unplug anything or interrupt power while it is flashing.
5. After reported completion, wait at least another ten seconds. Then switch off, disconnect connections that could backfeed the board, and leave it fully unpowered for 30 seconds.
6. Reconnect and start normally. Check the reported core where available, then test input, display, storage and your normal applications before making further changes.

The command has this form:

C:ApolloFlash RAM:STANDALONE_XXXXX.jic

📌 XXXXX is a placeholder, not a release recommendation. Replace the filename with the exact downloaded file already copied to RAM:. RAM: is the Amiga RAM disk; its contents disappear when power is removed. The example assumes the utility is installed in C:. Use the actual utility location if your installation differs, and quote a path containing spaces.

If icon-based launching produces “not executable”, run it from the Shell as shown above rather than modifying the core file. If the tool still will not run, check its version, extraction and executable permissions; do not assume every launch error has the same cause. A distribution that includes ApolloFlashMap may offer a graphical front end, but the target checks and uninterrupted-write precautions still apply.

🚫 ApolloFlash rejects the image

Stop and check the hardware target, extracted file, path and utility version. Read the complete error before making another change.

🛑 Do not switch to Quartus simply to bypass a target rejection. The Amiga-side tool can perform hardware checks that the external programmer does not provide. A refusal may be preventing you from writing an unsuitable image.

Do not combine commands from old flashrom or VampireFlash tutorials with a newer package unless that package actually requires them. Resolve the mismatch using the release's intended tools, not a collection of historical command names.

🧩 The flash succeeded, but the old OS no longer boots

A core update does not reinstall the CF, but it can replace a Kickstart that was previously flashed separately with the core's default ROM.

The default ApolloROM environment is intended for ApolloOS. An AmigaOS installation needs its appropriate Amiga Kickstart arrangement. Some setups flash a ROM permanently; others map it from a file during startup or use a bootloader to select it.

💡 ApolloMap is not permanent flashing. A mapped ROM can survive a warm reset but not a complete power-off. Restore the arrangement required by the installation rather than randomly alternating between mapping and flashing.

For an applicable AmigaOS 3.5/3.9 installation, check the SetPatch invocation in S:Startup-Sequence. The Vampire-compatible form disables the conflicting ROM-update component:

SetPatch NOROMUPDATE QUIET

Review and adapt the existing command; do not add a second SetPatch line or overwrite other required startup options. This is not a blanket replacement for every AmigaOS version or ApolloOS startup.

Also recheck the ROM's ability to reach the boot partition, particularly on large cards. Successful programming proves that the firmware operation completed; it does not prove that the current ROM, disk layout and drivers form a bootable combination.

<a id="jtag-recovery"></a>

🛟 USB-Blaster and Quartus recovery

This is the advanced route for a failed or unsuitable core that prevents normal startup. It writes the configuration through the board's JTAG header, independently of the installed operating system.

A USB-Blaster is not a cure for physical damage, a failing power supply or a missing filesystem. Before opening the case, rule out the display and basic power checks. Get board-specific assistance when the header, orientation or required image is uncertain.

🧰 Prepare the recovery equipment before connecting it

You need a compatible USB-Blaster, its correct JTAG ribbon, a PC with an appropriate Quartus Programmer and Tools installation, and the approved .jic for the board. You do not need the entire FPGA development environment simply to program a supplied image.

The V4 uses a Cyclone V FPGA. Instructions and screenshots for older Vampire boards can show different devices. Use a programmer/software combination that supports the actual V4 target; do not select an unrelated chip because its name appears in a generic tutorial.

Install the programmer's host driver and confirm that Quartus can select it before attempting a write. That confirms only the PC-to-programmer connection, not communication with the V4.

The standard Standalone's Mini-USB power socket is not a built-in programming port. Some expansion assemblies expose a programmer connection separately. Identify the actual socket instead of assuming that every Mini-USB connector has the same purpose.

🔌 Connect the JTAG cable safely

Remove the V4's normal power and disconnect other connections that could energise it. Follow the board-specific connection procedure and use appropriate antistatic handling.

Identify pin 1 at both ends of the ribbon. The marked ribbon edge must align with the correct pin-1 position on the board and programmer. Inspect the alignment and seating before restoring power. A connector reversed or shifted by one position is not something to discover by trial and error.

⚠️ Never connect or remove the JTAG ribbon while the target board is powered. Do not turn the connector around “to see whether that works”.

The connection path is:

PC USB → USB-Blaster → JTAG ribbon → V4 JTAG header

The target still uses its normal, suitable power supply during programming. A programmer recognised by the PC does not establish that the V4 is powered correctly.

🔎 Check detection, then load the image in a clean list

In Quartus, open Hardware Setup and select the USB-Blaster. Use JTAG mode for this workflow.

For a detection check, begin with an empty programming list and run Auto Detect without starting programming. Record the detected target or the complete error. An inaccessible or unexpected chain must be resolved before a write; do not force a device identity to continue.

After a successful check, clear the temporary detection list and use Add File to load the approved .jic once. Do not append another Auto Detect result to the loaded configuration and leave duplicate entries behind.

The normal JIC programming arrangement includes an FPGA helper entry and the configuration flash:

Keep the factory-default SFL entry. SFL means Serial Flash Loader: a temporary helper loaded into the FPGA so the programmer can access the configuration flash. It is not an old Apollo core, a factory-reset image or an extra operating system.

🛑 Do not select a separate Erase operation. Erasing the configuration flash removes the stored configuration; it is not an additional verification step. Use the intended programming and verification operations supplied by the correct JIC workflow.

🔄 Program, verify and perform a genuine cold restart

Check the file, target and selected operations once more, then start. The Standalone can stop responding while the FPGA is being programmed; do not treat that expected behaviour as a reason to interrupt it.

Wait for 100% (Successful) with the requested verification completed. A high percentage followed by an error is a failed operation, not an almost-successful one.

After successful completion, wait at least ten seconds. Remove the target's power and any other power paths before detaching the programmer as instructed for the hardware. Leave the V4 fully unpowered for 30 seconds, reconnect normally and test the boot.

Keep the programming log. Older core-version reporting mechanisms store a string that the Amiga-side flash utility updates but Quartus does not, so a JTAG-programmed system can report stale version information through such a command. Retain the exact file and successful log; do not keep reflashing solely because an old VControl CORE display has not changed.

If programming verifies but the OS still does not load, return to the ROM and CF compatibility checks. The programmer has not repaired or reinstalled the operating system.

🕵️ USB-Blaster is missing from Hardware Setup

Check the host connection and driver first. On Windows, open Device Manager and inspect the programmer entry for an error.

Install the driver appropriate to the cable from the supported Quartus package. Typical package directories distinguish:

<Quartus installation>\drivers\usb-blaster
<Quartus installation>\drivers\usb-blaster-ii

These are different cable families, not interchangeable troubleshooting choices. Use the directory matching the programmer and package, reconnect it as required, and reopen Hardware Setup.

Do not disable Windows driver-signature enforcement or other security protections as a generic fix for an unidentified driver problem. A driver must also be suitable for the host's Windows version and architecture; recognition of an old package on one PC is not a compatibility guarantee for another.

🔗 “Error (209040): Can't access JTAG chain”

This means Quartus could not communicate with the target chain. It can be followed by:

Error (209012): Operation failed

The second message is not the useful diagnosis. Save the log beginning with the first error.

1. Confirm that the PC recognises the programmer and that Quartus can select it.
2. Confirm that the V4 receives its normal power when detection is attempted.
3. Remove all power before checking the ribbon, header, pin-1 alignment and seating at both ends.
4. Reconnect correctly, restore normal target power, and retry Auto Detect in an empty list, without programming.
5. If detection still fails, substitute a known-good compatible cable or programmer, changing one item at a time and removing power before every target-connection change.

If the log indicates a host-side tool or driver failure, resolve that first. Repeatedly inspecting the ribbon will not repair a broken host installation.

A selectable USB-Blaster [USB-0] is not proof that the board is reachable. Conversely, a chain error alone is not proof that the FPGA is permanently damaged. Stop when reliable detection cannot be established; do not force chip IDs, choose unrelated core files or format the CF in response.

⚠️ Programming finishes, but verification fails

Treat the flash as unverified. Preserve the complete log, filename, selected target and first error before doing anything else.

Recheck the correct image, stable target power, programmer compatibility and reliable chain detection. Repeat the approved operation only after there is a reason to believe the failing condition has been corrected.

Do not add an Erase operation, remove the SFL helper or force a different chip identity to make the progress bar finish. None turns a failed verification into evidence of a correct write.

<a id="rollback"></a>

🧪 Testing a beta and going back safely

A beta is an experiment. Keep the experiment away from the only copy of your working system.

Prepare the previous core, its matching driver and utility packages, and a verified full-card backup before starting. Check the candidate's exact board revision, memory and clock requirements. Where there are separate hardware builds, choose explicitly rather than inferring compatibility from a similar filename.

Have the supported recovery equipment ready when testing a release that could prevent normal input or booting. “The new core should work” is not a recovery plan.

🔬 Test the whole machine, not just the desktop

After updating, perform several genuine cold starts. Check the reported memory against the actual fitted RAM, keyboard and mouse recognition at power-on, native and RTG video, storage reads and writes, networking, sound and the applications you normally use.

Use expendable data for write tests. If a machine fitted with 512 MB suddenly reports 1 GB, do not celebrate the free upgrade or deliberately fill the extra memory. Stop normal work, confirm the intended build, and use the appropriate diagnostics or restore the known-good setup.

If a faster build fails but the previously supported variant works, keep the stable variant. Do not compensate for a clock/build mismatch by increasing voltage. Hardware qualification is not determined by a suffix sounding more impressive.

⏪ Roll back the combination, not just the core

A core downgrade leaves the CF's drivers, ROM-mapping utilities, startup scripts and preferences as they were. Those changes can explain why the old firmware no longer behaves like the old system.

Restore the saved core and its matching software environment, using the preserved card or image where appropriate. Keep any newer personal files separately before restoring an older full-card backup, because that restore replaces the destination's contents.

Retest the same workload with the same peripherals. A repeatable improvement narrows the fault; it does not establish that every newer core is defective or every board has the same problem.

Avoid treating isolated beta build numbers as universal fixes. A release that corrects one display problem can still be unsuitable for another board revision or driver set.

<a id="read-only-checks"></a>

🔍 Read-only checks: collect useful evidence without repartitioning

These checks inspect disks or ordinary image files. They do not request formatting, initialisation or partition changes. They are not a hardware write blocker and do not prevent Windows or another application from writing to a mounted volume.

Use a copy whenever possible, insert one CF at a time, and cancel Windows prompts to initialise or format it.

🗂️ List the physical disks in Windows

Open Windows PowerShell as Administrator and run:

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

Identify the CF by its capacity, reader/device information and any available serial number. A reader may report its own identity rather than a useful card serial. Recheck after every card or reader change; disk numbers are not permanent identifiers.

The Size field is the reported physical capacity in bytes. Do not confuse it with the size of a Windows volume.

🧩 Inspect the selected disk's Windows-visible partitions

The following block checks the entered number and prints the selected disk before attempting to inspect its partitions:

$answer = Read-Host 'CF disk number identified above'
$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

$partitions = @()
try {
    $partitions = @(Get-Partition -DiskNumber $diskNumber -ErrorAction Stop)
} catch {
    Write-Warning ('Partition query failed: ' + $_.Exception.Message)
}

if ($partitions.Count -eq 0) {
    Write-Output 'No Windows-visible partitions were returned. This does not prove the card is empty.'
} else {
    $partitions |
        Select-Object PartitionNumber, DriveLetter, Offset, Size,
            Type, MbrType, GptType |
        Format-List

    foreach ($partition in $partitions) {
        try {
            Get-Volume -Partition $partition -ErrorAction Stop |
                Select-Object DriveLetter, FileSystemLabel, FileSystem,
                    Size, SizeRemaining, HealthStatus |
                Format-List
        } catch {
            Write-Warning ('Volume query for partition {0} failed: {1}' -f
                $partition.PartitionNumber, $_.Exception.Message)
        }
    }
}

An Amiga RDB layout may produce no Windows partition objects, or a query error, without the card being blank. Keep the exact message. Windows-visible partition information is not a complete Amiga partition inspection, and a reported healthy Windows volume does not validate the rest of the card.

Save separate results for the original and replacement cards. That comparison helps distinguish a capacity difference from a different image layout.

📏 Check an image file's exact size and SHA-256 hash

Run this against the extracted image file on the PC, not a raw-device path. Enter the path without surrounding quotation marks at the prompt:

$path = Read-Host 'Full path to the extracted image file, without quotes'
$file = Get-Item -LiteralPath $path -ErrorAction Stop

if ($file.PSIsContainer) {
    throw 'Select an image file, not a folder.'
}

$file | Select-Object Name, FullName, Length, LastWriteTime | Format-List
Get-FileHash -LiteralPath $file.FullName -Algorithm SHA256 -ErrorAction Stop

Length is the image's exact byte count. Compare it with the target disk's Size before writing.

A SHA-256 hash identifies the file's contents. It verifies neither the CF nor the file's authenticity by itself. For download verification, compare it with a trusted checksum for that exact image. For card verification, compare the card's corresponding bytes with the image, as explained in CF cards and disk images.

🗺️ Inspect the Amiga partition layout in an image copy

The optional amitools package includes rdbtool, which can inspect RDB-format disk images. On a PC with a suitable Python installation, the package can be installed with:

python -m pip install amitools

Then check the installed command's options:

rdbtool --help

Confirm that it supports --read-only before proceeding. Use ordinary image-file copies, not physical-drive paths:

rdbtool --read-only "replacement.img" info
rdbtool --read-only "original-backup.img" info

Replace the example filenames with your actual image paths. Compare the partition names, ranges, filesystem types and any stored filesystem-handler information. Keep the output alongside the image size and hash.

Do not substitute create, initialise, import or resize commands for info. The read-only option is there deliberately.

Errors such as “No RDB Disk?” or “Can't detect geometry of disk” do not automatically prove corruption. The file may be partition-only, use a layout the tool does not understand, or need a different kind of inspection. Do not force guessed geometry onto the original to make the message go away.

🖥️ HDToolBox cannot see a disk inside an emulator

Match HDToolBox to the emulated controller. For a UAE hard disk exposed through uaehf.device, an example using the tool on an inserted install floppy is:

DF0:Tools/HDToolBox uaehf.device

Use the actual HDToolBox location if different. Inspect the detected device and leave without saving when the purpose is diagnosis. Do not initialise a populated image merely to make it appear.

This command is for that emulator setup. It is not a reason to replace the V4's real storage-driver entries with uaehf.device. Prefer an image copy to direct access to the original CF, and do not let multiple systems write the same image simultaneously.

<a id="when-to-stop"></a>

🛑 When to stop experimenting

Stop and preserve the current state when a card develops repeated read errors, a populated partition suddenly appears uninitialised, a memory test fails persistently, connector orientation is uncertain, or JTAG detection cannot be made reliable.

At that point, the useful information is the last known-good state and first actual failure, not a list of everything tried afterwards.

Keep one compact fault record containing the board/revision and RAM, core filename, OS and driver versions, exact error or photograph, and what changed immediately before the symptom began. For storage, add the image name, exact image/card sizes, partition layout and verification result. For recovery, keep the full Quartus log and programmer details.

The goal is not to apply every fix in this article. It is to find the first test that separates a working part from a failing one, make the smallest justified change, and verify that the original problem is actually gone.

---

📋 Disclaimer: This is an independent troubleshooting guide, not an official manual or a guarantee of repair. Hardware revisions, core releases, operating systems and disk layouts differ. Follow the instructions for your exact hardware and release when they differ from this guide. Back up before changes and do not perform an operation you do not understand. Firmware flashing, hardware handling and disk changes can cause data loss, damage or an unusable system. To the extent permitted by applicable law, the author and publisher accept no responsibility for loss or damage arising from use of this guide. The procedures have been researched and reviewed; they are not a claim of hands-on testing of your particular system.