Would it be possible to have an expansion board with a modified exdos rom (to allow boot without wd1770) and driver in the rom for communicating with the sd card?

I have a pic chip talking to an sd card, so creating an interface to the sd card with a cheap pic chip would be quite easy. You'd then just need the driver for exdos.

As getting a disk interface for the enterprise is tricky these days, and disks are unreliable, this seems like a useful project...

I've been thinking, and you could combine a memory expansion with an SD card "hard drive". Would just need a ROM on the memory expansion with the EXDOS / driver as well as the PIC interface and a micro sd card.

The only thing missing then would be a way to access the SD card from the outside world. Has anyone written a terminal server for the Enterprise? I could then connect to the client using a USB serial cable to control copying of files to and from the Enterprise "hard drive" as well as perhaps some useful development features like loading and executing code. This could also go into the ROM as an extension.

Having a quick way to remotely access the Enterprise would be very useful.

I've been thinking, and you could combine a memory expansion with an SD card "hard drive". Would just need a ROM on the memory expansion with the EXDOS / driver as well as the PIC interface and a micro sd card.

The only thing missing then would be a way to access the SD card from the outside world. Has anyone written a terminal server for the Enterprise? I could then connect to the client using a USB serial cable to control copying of files to and from the Enterprise "hard drive" as well as perhaps some useful development features like loading and executing code. This could also go into the ROM as an extension.

Having a quick way to remotely access the Enterprise would be very useful.

Well, I always have ideas I don't have time (or enough knowledge ... sometimes) for. I was also thinking to interface with an SD card with an Atmel microcontroller (of cource, someone can play with PIC too). SD (and mmc) cards basically works through SPI bus (well, some cards have other modes too, but SPI is simple, and it works with all, no differences, etc). Most MCUs today have hardware SPI support.  And microchip btw has a full featured Ethernet controller in 28 dip package (!) called ENC 28J60 (I even have one!). This little stuff also "speaks" over SPI by the way! And optionally you can find many other things that can communicate through SPI. So maybe the best would be implement (eg with the help of an MCU) a general SPI interface for Enterprise, then you can have ethernet, SD card, and possible other stuffs as well. Similar (but even more "advanced") idea is to implement an USB host for Enterprise (some more advanced MCUs may handle USB in OTG or host mode too ....), so for example every device which implements the USB mass storage protocol (eg: pendrives, USB/IDE converter, most phones/cameras which does not require own program, card reader) can be used as storage for EP. Also you may be able to find USB/ethernet, USB/serial etc converters. The disadvantage: with USB/ethernet there is no standard way so you may need different drivers for different dongles

With SPI/SD card there are tons of examples on the net (mainly with AVR) with firmware/source/schematic. Also I could find tons of examples again for AVR+28J60 and also PIC+28J60. So maybe it's not even too hard to create someting with the help of information can be found on the Net. I will do it some time, just I have no idea _when_ Currently I have non-working EP only, first I should cure it ...

If you have some kind of network on the EP, it's possible to write software to be able to handle it. For example in my Javascript based Enterprise-128 emulator I have some stupid experiment to be able to show web pages with implementing some pseudo hardware to bridge information between EP and Javascript AJAX functionality. Of course similar can be done on a real hardware too, just it's more complicated to implement TCP/IP yourself (I did ARP/UDP/ICMP for 6502 once ... it is quite odd to do, but TCP is even  harder). If UDP is OK, it's quite simple to do, and EP will communicate over Internet then if you want Just you may need special UDP servers, or you need that TCP/IP monster to be defeated Another possibility: Master Zozo post information on some chip here (I can't remember now ...) which implements TCP/IP _itself_ and it's very easy to interface! Maybe that would be fun to try it, but that's a quite odd chip, I have no idea how to buy it. If you have ethernet/networking/whatever once you may not even need SD card, as if you have your home NAS, you may prefer to use it, from your PC and EP too and forget local storage at every level of your life, aka Cloud COmputing. Well, almost ...

But I want an *internal* hard drive for the EP! I don't want to have to make a hole in the case for an sd card slot, just have it there unseen and working.

Plus, having a way to quickly send code to real hardware would be really useful for development and testing. I had a similar system on the Atari ST and also Sony PSP which was really nice...

Yes, that's the reason I talked about ethernet or USB maybe But using an MCU which has some kind of parallel connection with EP bus, has something over SPI still, namely the serial port. You may implement (with some IC like MAX232) a real serial port to interface with a PC (you may need an USB-serial dongle if your PC does not have real serial port as newer ones). The MCU itself works as a "bridge" between SPI - EP bus (SD card for example) or serial - EP bus (PC connection) then.

I also have code running on a PIC chip talking to an mmc card over SPI already. Microchip provide some code to do this for you, which is great!

I suggested AVR for one reason: there are mature projects with AVR and SD card communication, like the sd2iec which is a Commodore floppy "emulator" using SD card for Commodore machines. However the AVR-SD card communication routines can be reused etc and they are widely tested with various SD card in the real life not just from the MCU vendor, that was the reason I suggested that. Of course the PIC vs AVR question is a bit "taste" thing, I prefer AVR, as it has more applications among hobby people, and have more open source tools etc (and I know AVR assembly while PIC assembly looks like horror movie for me), but of course it really does not matter.

The internal memory expansion is really simple, so I'll think about the memory mapped SD card interface too. A generic SPI interface would be possible, but then would require more code on the Enterprise side. I like the idea of keeping the interface simple and having the ability to change the firmware if needed.

With AVR at least (I don't know about PIC) firmware upgrade can be done easily with so called "boot loaders" even on smaller AVRs like on ATmega8A, or ATtiny series (if I remember correctly). Btw it's not a problem to have more code on the Enterprise side, this is my theory. I dislike the idea a bit to have so much "help" from the outside that someone have more powerfull MCU for the EP than its CPU (z80) is for real. It looks/feels odd for me. I would only use the MCU to interface SPI bus, probably with memory mapped mode though to transfer blocks, but even SD card intialization is controlled by EP, that's the real feeling. At least this is my idea, etc, everyone can have its own ideas what is good and what is not For me I may share your idea to keep interface as simple as possible. You can even control SPI bus with "bit banging" without any hw (you can use printer port, whatever). That will be REALLY slow, but it works and it allow to experiment a bit MCU here helps to implement SPI by hardware (by the MCU) but it could be even great to have some specialized IC as SPI driver for 8 bit systems Like an UART etc, just for SPI.

Is there a problem with using the cartridge for the sd card interface, in that the basic rom would not be plugged in? Or would you think of including the basic rom in the cartridge as well as the exdos / driver rom?

I agree, for other "normal" users a cartridge or expansion port device would be best. I am finding it hard to find 33x2p edge connector (the closest I have found is 34x2p), though. So a cartridge would be the easiest as you can just etch the edge.

An expansion port add-on may be the nicest solution, though... ? I will have to try the 34 way edge connector and see how we'll it fits / how much needs cutting down.

I do like the cartridge idea, as it also means you can use the disk drive to actually develop and test the hardware. If it was simply a stand alone expansion, it would be very difficult to develop the drivers for the hardware.

The only problem I can see is that inserting an un-housed PCB as a cartridge is awkward and there is no support for the PCB in the cartridge bay. This could mean unwanted stress could be put on the cartridge connector and possibly damage it or the cartridge PCB.

I think a final product may be safer / stronger as an expansion board?

Interesting!!!!!!!!!!  i want one sd interface:lol:

I think LBA accessing whole card as hard drive are enought. It is exist a VHD image with (near to) all Enterprise programs for the hard disk users. This is also can be written to the SDCard.
In my existing hard disk handler program just need to replace the drive detect and sector read/write routines for the SDCard routines then job finished!
Later possible make modified EXDOS version which can simulate floppy drives from disk images on the SDCard.