With Edwin’s help, I’ve just finished adding Atom Lite 1.x support to both SimCoupe and SamDisk.
The new interface is a simplified version of the original Atom HDD interface, and is now primarily for Compact Flash use. The Atom Lite uses an ATA feature for 8-bit data accesses, rather than normal 16-bit IDE mode, avoiding the need for half the data to be latched inside the interface. The change simplifies the design and allows faster data transfers - the next data byte is now fetched with a single IN, rather than having to select the high or (latched) low address first. Streamed media playback anyone?
The new interface requires updated B-DOS and HD-BOOT ROM versions to select 8-bit mode, but once set it’s software compatible with the original interface. Data can be read from both &F6 and &F7 ports as before, despite no latching being involved this time. However, the change does means the byte order of the Atom Lite media is reversed (or perhaps un-reversed!) compared to the Atom, which returned the high byte first. Fear not, existing Atom media can be converted to use Atom Lite byte-order using SamDisk!
The changes to SimCoupe were mainly to the ATA emulation, with enhancements to support 8-bit data mode and 28-bit LBA sector addressing. The latter allows support for devices beyond the 8GB CHS limit (16383 cylinders, 16 heads, 63 sectors), extending the maximum size to a whopping 137GB. Even an 8GB card would contain almost 10,000 B-DOS records, which could easily contain every SAM software title ever written! The Atom Lite implementation is just a cut-down version of the existing Atom C++ class, which has been further simplified as part of the same changes.
The SamDisk changes were also fairly trivial, especially as there’s no ATA emulation to worry about. The byte order of the media is determined by examining the BDOS signature at offset 0xe8 in the first record (which follows the boot sector and record list). With the original Atom (seen as “DBSO”) data accesses must be byte-swapped after reads and before writes. This allows all record-level commands to work transparently on both media. A new command-line option (/bs) forces byte-swapping of entire images, used for the Atom <-> Atom Lite conversion mentioned above. Simply read the device to an HDF image using the byte-swap option, then write the converted image back to the original device.
The Atom Lite 2.x boards are expected to include a Dallas clock chip, with registers access through the same floppy 2 ports. SimCoupe support will be added once the details have been confirmed…
Would Sim Coupe support the new Atom Lite+ using the Dallas clock? What do you have in mind? Could the uses also store bytes in the Dallas clocks RAM , if so could you save and load Dallas RAM as a file to and from your hard drive?
I normally use my Sam in mode 3, it would be nice to be able to store the screen mode, say in the Dallas clock on a real Sam so when it boots up you could read the last used screen mode and have it set to that. - just a thought!
Yes - AL+ DALLAS clock support was added last week, and confirmed over the weekend with Edwin’s updated BDOS.
I implemented DALLAS RAM saving to the .cfg file for the normal clock, but that wasn’t very convenient to view/edit. I’ll move that to an external file instead, with the AL clock saved to a different file.
SimCoupe currently emulates the DS1687, which has only 256 bytes of RAM. Once I get my AL+ I’ll implement the DS17887, which has a spacious 8K of RAM. That should give much more room to play with for state saving!
Is there any chance of a version of
Samdisk for Linux?
It wouldn’t be much work to do it, though it’ll never be as fully functional as the Windows version. The FDRAWCMD interface support in the Linux kernel lacks the flexibility to terminate write commands early, since it’s not something people would normally need to do. That prevents writing CRC errors, short sectors, mixed density tracks, and a few other quirks required by copy protected disks.
That said, if you only want to read/write regular SAM and CP/M formats then you’ll be fine with the standard support:
To read from SAM disk to raw image:
dd if=/dev/fd0u800 of=image.mgt
To write the image back to a formatted disk:
dd if=image.mgt of=/dev/fd0u800
To format a new SAM disk:
fdformat /dev/fd0u800
If the /dev/fd0u800 device doesn’t exist, try /dev/.static/dev/fd0u800 instead. Or for CP/M disks change the last part of the name to fd0u720.
You’ll only be able to use .mgt (old-style 819200 byte .dsk images) with that method, but it might be better than nothing for now!