*** M E M O R U M ***

stephen_usher wrote: ↑04 Sep 2022 23:39 The only thing which probably needs addressing is the storage. Being limited to the original SD card specification is a headache as hardly any small SD cards exist. Also having it as raw storage limits things. Maybe a future upgrade could be to encapsulate the drive image into a file on a FAT filesystem and support the ubiquitous SDHC cards?

Despite the reservations expressed by Dave on his site, supporting SDHC cards should not be too difficult. They require a couple of extra steps in initialisation, and are then accessed by logical sector address rather than byte address. Irrespective of how they may be organised internally, they present standard 512 byte sectors to the outside world so blocking / deblocking is the same as for the CFX. I have successfully supported SDHC cards from both my Z180 project and MEMU on Pico.

Accessing an arbitrary FAT file as a drive image is unlikely to ever happen. However there is one special case where it should be possible, that is if the entire image file occupies consecutive clusters on the SD card. That is likely to be the case if you write the image file to an otherwise empty SD card. I can imagine a FATMOUNT program that reads the directory to find the start of the file, then walks the FAT table to check that the file is contiguous. If it is, it then updates the CP/M drive parameter block with the start of the image file, and mounts it as a CP/M drive.

Another approach is to partition the SD card in the DOS / Windows sense. The first partition could be (for example) a 32MB partition of either type 52h (CP/M) or 7Fh (Experimental). This could then contain four 8MB CP/M drive images. Again, I have done that for my Z180 system. On booting, you read the first sector and check for it being an MBR. If so read the partition table to find the start of the partition containing the CP/M images. That gives an offset which needs to be added when accessing the drive images.

If you have done this, you can then have a second partition on the SD card which is FAT formatted and can easily be read / written from Windows. You then need a CP/M program which can copy files between the CP/M images in the first partition and the FAT partition. I have not done that for an SD card, but in the past I wrote a program that would copy files between a CP/M RAM drive and a 720KB FAT floppy in a 3.5inch SDX drive.

Any or all of the above would only require ROM upgrades to the MFX. It was thinking about this that prompted me to upgrade my Z80 assembler to support Martin's latest code. But then, as is often the way with me, I got distracted by other things.

The "must be a contiguous file" is a restriction many of these devices have and is fine. It's not as if you'll be changing the size once it's there.

It may be useful to have the ability to read a config file pointing to the image in question so that you could have multiple images and point to different ones, but that's just extra work.

stephen_usher wrote: ↑04 Sep 2022 23:39 Indeed. The only thing which probably needs addressing is the storage. Being limited to the original SD card specification is a headache as hardly any small SD cards exist. Also having it as raw storage limits things. Maybe a future upgrade could be to encapsulate the drive image into a file on a FAT filesystem and support the ubiquitous SDHC cards?

Moved this to a new thread - it's an enhancement request

An update . . . .

Thanks to ongoing work by Bill and Martin, it is likely that support for SDHC cards will soon be added to MFX.

In the first instance, SDHC cards will be supported in the same way that SD cards currently are, i.e., storing data in RAW format, without any support for higher level formatting such as FAT32. The immediate advantage is that SDHC cards are more readily available and cheaper than legacy SD cards, making it easier for users to source additional SD cards for backups etc.

Support for SDHC cards will require an update to the MFX ROM but no changes to the FPGA firmware are required. (The updated ROM will be backwards compatible with SD cards). In due course, I will make the updated ROM available for download to allow users who have a ROM programmer to update their own board. Users without a ROM programmer will be able to send their ROM back to me for upgrade at no cost, other than return postage. Alternatively, I will supply a replacement ROM for a nominal charge to cover the cost of the chip and postage.

Note: Andy's Hextrain program uses customized code to access the hidden HT data area and will be incompatible with the new ROM. Bill is working on modifying the HT program to correctly handle the SDHC card format. An updated HT program will be available for download in due course.

25/09/22: The updated firmware is now available for download from

http://primrosebank.net/computers/mtx/p ... mfx_fw.htm

regards
Dave

Ooh, that would be useful. As pointed out, SD cards of 2GB or less are getting harder to find these days.

I'll have to check my EEPROM programmer (which I have yet to use) will flash this chip.

Sounds like excellent progress. The MFX seems to be the ideal basis for an increasingly capable system.

Just closing the loop on this . . . .

This request is COMPLETE.

Thanks to Bill and Martin, MFX now supports SDHC cards, with support added for Andy’s HEXTRAIN.

The updated ROM Firmware binary (build 167) and an updated version of the HEXTRAIN executable (221001) can be downloaded from

http://www.primrosebank.net/computers/ ... mfx_fw.htm

(There is an error on the web page that I will correct next week, the HTSD description is “211001”, but the download is correct)

Nice enhancement.

I notice GAL and CPLD updates too. Are they critical for early boards?

The other updates are not critical.

I am away for the weekend and need to check when I get home, but I think that all of the shipped systems have the GAL update already loaded.

A couple of early boards, probably including yours, do have the earlier version of the FPGA code, but the impact is minimal. It is related to the shadow page port, I.e., the ability to read the page port (memory configuration) status. The original MTX did not have this, it is only useful to anyone writing software that wants to check the configured memory status.

Anyone who does want the revised FPGA code loaded is welcome to return the FPGA module for an update for the cost of return postage

Regards
Dave

There was a typo issue** with mapping the 512k ram in the first draft of the memory decode GAL. That was cured before the MFX went to "manufacturing". The issue resulted in duplication or some of the paged memory and would be apparent as corruption in a ram disc with more than 128k or so of files, if I remember the details correctly.





** What I'd typed in the CUPL equations didn't match what I'd written in the accompanying comments. The comments were correct the code wasn't!