Yes it is also problem with the IDE interface.
160 bytes needed for each logical drive, for the EXDOS and device driver administration area. (Bigest part of these the storage space for the actual PATH of the drive.)
If you want all possible drives from F to Z then 21*160=3360 bytes plus some for the expansion ROM variables.
This is not a problem for the EXOS or BASIC, but some programs don't allocate memory from the EXOS, just directly overwrite it. These are calculating with the normal EXDOS memory usage (only A-E drives), with the IDE (and will the SD) more system segment used are are overwritten
Possible allocate memory in a separate segment, but two other problems:
- this function have a bug in EXOS 2.0/2.1 and can not be used Only work with my bugfixed/updated EXOS version. Then needed to upgrade the onboard ROM
- many-many improper programs which are not allocate memory from the EXOS, directly overwrite F8-FF segments, then the separate segment for the IDE/SD ROM only safe bellow F8, then memory expansion needed.

Currently the IDE ROM allocate own segment if EXOS version are higher than 2.1 and memory expansion exist.

If the SD interface have a hidden RAM area in the ROM segment then all problem will be solved!

The hardcore users have (or can install) a upgraded EXOS and memory expansions, but many users want a easy way for using unmodified machine with modern fast storage, just want a play games as "plug and play"

(I would always prefer to use less drives, or even zero, as UNIX does not need this notion - drive letters are from CP/M originally even in DOS/Windows ...).

I like the letters, because the EXDOS have a drive letters

drives before F: can be used as well for SD card, right?

If you delete the floppy drives then the RAMDISK go down to A: then will be problem because the programs search the RAMDISK at E:

And also the "try to modify EXDOS to use FAT16" would be a great idea

Adding FAT16 probably not a to hard work (but need a time...), but only solve the to big clusters problem. Maximum disk size still 65535 sectors.
The BIGDOS FAT16 can solve the partiton size problem, but this is will be very hard work, because the original sector operations use 16 bit registers for sector number, need to free up more registers and add new function calls for handle more than 65535 sectors.

I am not sure how frequent some "average" user wants and SD card interface for the EP using also a "real" EXDOS and using tons of drive letters at the same time.

Average users use a disk browser sw for select game I will be modify (or write) one for display Volume Labels with the drive letters, then the drives looks as directory, for example DEMOS, GAMES_A-B, UTIL, etc

I can't get small SRAM easily --

Somewhere I have a lot of (least 40-50) W24257/W24512 (or compatible) SRAMs which are saved from 486 boards at about 15 years ago
I used one for replace onboard memory
[ Guests cannot view attachments ]

I`ve seen this:

http://www.toshiba-components.com/FlashAir/

It can be an easy(yet sligthy expensive) way to have a semi-host conection by WIFI with a PC.

http://www.amazon.com/Toshiba-PFW008U-1ABW-FlashAir-Wireless-Class/dp/B00BXAXH74/ref=sr_1_11?ie=UTF8&qid=1391997190&sr=8-11&keywords=flashair

Yes, I am still planning to do this. Funnily enough, I've just been thinking about prototyping it. I've got some edge connectors and vero board ready, and will be ordering some PLCC sockets and MAX3000A chips as well as some FLASH and SRAM so I can wire-wrap a test board.

I'm going to use the expansion port first, just because I can create a prototype without getting a PCB made for the edge connector, then when this is working I will think about the possibility of a cartridge version as well.

I've got it all drawn out on a piece of paper, using a GAL (I have quite a few spare now! ) for the address decoding for FLASH, SRAM and the MAX3000A SPI chip (being memory mapped). This means I can move the design over more easily to the cartridge port if needed.

I was also thinking I may add 512KB RAM and 512KB FLASH to the board and possibly other things like a real time clock. The RAM and ROM would make this a nice external expansion for people who have an unexpanded EP64.

Or maybe, I'm wrong at EXDOS, and your storage device will not be an EXDOS "extension" ?
I think the current IDE card work somehow like an EXDOS "extension", and this will be good for any storage device,
but in the emulator, there is a FILE device, what is not such like the IDE, but a different device for EXOS ... or what ...

Zozo, can It be good in practice, when a storage hw is not EXDOS "compatible" like the IDE card ?

To be honest I was thinking more bare-bones style! Like these Speccy interfaces.

ROM and RAM would be positioned in memory such that they were not conflicting with the existing 512KB or 1MB internal expansion. I think it would need just EXDOS and Zozo's SD card driver (like the IDE CF driver).

One page of the RAM (well, 4KB of it) would be shared with one page of the ROM to enable the driver to only require a single page to operate. I believe this was the request, Zozo?

I believe there is a fast memory test we can include in this expansion as well? So people with unmodified EP's dont have to wait forever for the memory to test...

To be honest I was thinking more bare-bones style! Like these Speccy interfaces.

Okay, I read again in the hungarian topic, and I see that the IDE controller is an EXDOS extension.

So how I see, there is the EXDOS, which is the already done, de facto EP disk standard, and it has an EXOS device interface towards the EXOS ( DISK: ), and has a FAT12 implementation, and an other extendable device interface inside itself, handling different hardware devices.

This DISK: device can be the default device to EXOS, and file access will be done through EXDOS in this situation. (Without explicit device specification, like "TAPE:dummy.com"

So when a storage device is such an EXDOS extension, then it will capable of everything what EXDOS can do. It is good, because we have FAT12 filesystem, and every function what is implemented in EXDOS on the new device, immediately. It has drawbacks too, like FAT12 has many limitations, such the little partition size, and so on.


The second choice would be a different EXOS device, like TAPE: or DISK:, in this case we are not bound anymore to EXDOS, FAT12 or anything, but we have nothing from the already implemented features, too. So your SD device would be named SAINT:, and you will have to write every function from scratch, which handle files or filesystems on it, and offers the files to EXOS on a file access. In this case the default device could be SAINT:, and file access would go through the SAINT: device.


So it is, what I think I know. I do not understand what more bare-bones style that speccy interface works, and how could that style work with EP and/or EXOS.