Simplest MMC Interface hardware

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Simplest MMC Interface hardware

Post by Twilighte » Tue Feb 23, 2010 1:10 pm

http://members.multimania.co.uk/mmbeeb/

Something like this connected through the printer port with the possible daisy chained power plug from Oric could work as a quick solution to mass storage on the Oric rather than the existing rare Disk solution.

The hardware could be very cheap to produce.

However how much actual work is involved in the Software side?
Ie. Serial/Clock driving s/w, Fat16 Filesystem handling for writing/reading files to the MMC/SD card.

User avatar
Dbug
Site Admin
Posts: 2662
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Tue Feb 23, 2010 6:52 pm

Hum, it does not look like a replacement for floppy disk?

I've been clear a number of time on a number of threads here: If it does not emulate a floppy disk, if it does not allow me to store all my .DSK as a virtual floppy juke box, it's not something I would buy.

User avatar
ibisum
Squad Leader
Posts: 989
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Wed Feb 24, 2010 11:03 am

I absolutely want to get involved in further development of this hardware .. and I agree that it should function as a .DSK jukebox with floppy emulation.

What we need is a microcontroller with enough data i/o pins to communicate to Oric DOS/SEDORIC etc. sufficiently well enough to do a real emulation of the floppy controller.

I got a Cumana-clone PCB for this project to support further hacking but I have not yet found all the parts to build it yet.

So I wonder if I can use an ATMEL AVR or Arduino or something with sufficient data i/o, along with the uDRIVE-uSD-G1 module:

http://www.4dsystems.com.au/prod.php?id=22

+

Arduino Mega:

http://arduino.cc/en/Main/ArduinoBoardMega

== All we need to do a floppy emulation? Any Oric DOS/SEDORIC experts want to get involved in this?

It seems to me it would be relatively trivial to glom together an AVR + this SD micro-Drive to emulate a disk system .. as long as we can find something that has the right i/o.

User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte » Wed Feb 24, 2010 2:27 pm

Over the last 10 years i have not yet seen a single alternate solution to mass storage for the Oric :(

Lots of wonderful ideas, but nothing tangible.

The interface suggested above would get us around the hardware side and if the code could be small enough over the software side.

Yes its not perfect(All serial transfer and clock would need to be software driven) and would require some devilish programming but if costs are kept to an absolute minimum it could be produced very cheaply.
Dbug wrote:Hum, it does not look like a replacement for floppy disk?
Correct, the software side might be able to accomodate dsk formats but it is doubtful. Your ideal is not neccesarily shared by all of us.
I for one am more interested in getting a mass storage device regardless of its dsk image compatability. Just a means of storing vast quantities of Oric files potentially in subfolders.

It may be possible to drive the Serial input onto CA1 and therefore intercept Serial comms through an interrupt thereby allowing some exotic loaders to play music and perform other tasks whilst reading data from the device. However this is completely theoretical atm.

One major advantage is it should be possible to adapt the ADFS routines used to drive the interface since they are from a BBC which shares the same CPU as the Oric :)


At the pure hardware level it may provide the mass storage capability of Cassette with much better access methods and faster transfers but i doubt as fast as Disk due to the software driven serial bottleneck :/

User avatar
ibisum
Squad Leader
Posts: 989
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Wed Feb 24, 2010 6:17 pm

An ArduinoMega seems ideal for this problem, no? I mean, it has plenty of i/o that can be used to simulate the floppy interface, its easily programmed, and can support a wide variety of peripherals for expansion and continued hacking.

If someone who knew enough about the hardware would confirm that this is a feasible option, I'll go ahead and get one and work on the software. I'd love to see an ArduinoMega that can be used as an expansion option for the Atmos, I really don't see why this isn't a *Great* solution for those of us wanting to extend the peripherals we can use with our Orics..

User avatar
Dbug
Site Admin
Posts: 2662
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Wed Feb 24, 2010 7:22 pm

Well there's clearly two separate schools:
- the ones who want something where they can store a lot of stuff, even if it requires totally new software/os to exploit this.
- the ones who want something that works with existing software/os as a replacement for the expensive/fragile disk drives.

It's probably possible to have something that could handle both situations, after all we can perfectly have a virtual DSK format with 256 tracks and 256 sectors per track, each sector being 512 bytes, that's 64 megabytes of storage, and since the Oric controller supports up to four disks at the same time, this would give you 256 megabytes of storage accessible at the same time.

For the software side, it has to be done anyway, and it would probably be relatively not difficult to patch an existing OS to support these new limits (need Sedoric expert here). For the folders, yeah, brand new universe, but I guess it would be motivating enough to have such a device and write some new operating system for it, ditching all the useless basic commands, after all what we want is things to navigate directories, load and save files, etc... not "allow basic programs to store database formated files".

After, it's also probably possible to have the system accept to automatically push bytes on a I/O port automatically after a read command has been issued, without any timing, just acknowledging the read and sending the next byte.

The problem of the incompatible mass storage device, is that it brings absolutely no value to anyone until the whole device + operating system is written. The compatible storage system brings value immediately: Copy all your .DSK, and there you go.

That's all rhetorical of course, many people have been starting projects, and we've not heard anything about after few month ;)

User avatar
ibisum
Squad Leader
Posts: 989
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Thu Feb 25, 2010 9:27 am

I think the more productive approach is one that fulfills the following requirements:

** Provides a nice handy solution to those of us not fortunate enough to have mircrodisc drives.
** Is relatively plug and play - you plug it in and you can use your exist DSK files.
** Requires *NO* modifications to Sedoric/Oric DOS/et al.
** Provides a platform for futher disk-based development in the Oric world.

I don't personally see this printer-port solution with a 'quick fix to code up something that will make it sort of work' to be very useful - at least not to those of us who want to experience the Disk-oriented use of Oric for the first time. Don't forget that there's a pleasure-basis for the effort to get a compatible disk hardware subsystem built: some of us didn't experience the DOS of Oric, and would like to, indeed, participate in that aspect. If we end up with some hacky solution that sorta works if you load a customized DOS, this isn't really going to provide that experience, in my opinion.


That said, I have ordered an Arduino Mega to see if it can be used to easily add Dataport programming capabilities to an Oric development environment, and I am also poring over the Sedoric code, as much as possible, to identify what will be needed to implement a proper disk emulator with this hardware. I'd really like it if some of the experts in this realm could participate, honestly .. I am wary of just plugging in the Mega, and will need some advice from hardware friends on how to rig up the interface. Can we not just try to work together in this direction, so that we end up with a relatively compatible microdisk emulator, somehow, which will work with our existing code?

Remember: Oric is for fun, and fun only. This isn't commercial; it should be as simple and fun as possible. From my perspective as a long-time Oric fan, and as a person who wishes he'd bought a microdrive way back when, instead of getting raped by collectors now, I really would like to just have a virtualized microdisk that Just Plain Works. I think its quite do'able, if we work together to pool our resources ..

User avatar
Chema
Game master
Posts: 2262
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Thu Feb 25, 2010 10:03 am

ibisum wrote: I am also poring over the Sedoric code, as much as possible, to identify what will be needed to implement a proper disk emulator with this hardware.
I think (and I may be wrong) that it would be a nice idea to have a look at oricula... sorry, oricutron sources for disk emulation. If you are able to emulate that functionality it would be more than enough.

As the topic has been issued before, I won't repeat my pov here again. Just, as a side note, if a disk controller is built, there already exists a virtual floppy drive which would provide mass storage for our dsk files with an easy (and outside of the oric) interface.

http://hxc2001.free.fr/floppy_drive_emu ... pyemulator

This one has already been tested with an Oric+Microdisk (see in the page a bit above) and includes schematics and all the necessary things to build it.

User avatar
Dbug
Site Admin
Posts: 2662
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Thu Feb 25, 2010 10:28 am

Technically it does not even have to be emulating timings correctly.
Something that works like emulators work is good enough: That means that software that works on a real Oric and Microdisc will work on the device, but software made on the device and not tested on a real Microdisc may fail.

The most recent and easy to follow software emulation of the Microdisc is in Oricutron, the source code is public, I wonder if somewhat this could be used as a 'fpga code base'.

User avatar
ibisum
Squad Leader
Posts: 989
Joined: Fri Apr 03, 2009 8:56 am

Post by ibisum » Thu Feb 25, 2010 11:21 am

So you're saying we'd just need to 'code the flipside' of what Oricutron has implemented? Thats very interesting .. and quite an attainable 'first step' towards the goal.

Has anyone got any input on what it would take to get the Arduino Mega hooked up to the Oric Dataport, physically, in order to proceed with tests and so on? How would we go about getting this testing with Oricutron - perhaps a 'shim' library that uses one Arduino Mega as the 'Oric side of Dataport' and another Mega as the 'floppy controller side', with additions to Oricutrom (a shim) that makes the "oric arduino" emulate the Dataport?

User avatar
Dbug
Site Admin
Posts: 2662
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Thu Feb 25, 2010 12:13 pm

I'd say that a logical first step would be to implement the handling of the ROMDIS/EPROM hardware.

This would make it possible to see at least if the Oric behaves correctly when the hardware address is accessed, and if we have the ROMs correctly deselected, that one can write in the overlay memory, etc...

If this part does not work, the rest is not even possible to test :)

Actually some people would be interested by having the top 16k of RAM available even if they do not have a Microdisc installed. My "Buggy Boy" demo requires a Microdisc only for that reason, it's one single file, but I needed the full 64k for me (and the fast interrupts as well).

User avatar
Symoon
Archivist
Posts: 1362
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Post by Symoon » Thu Feb 25, 2010 10:08 pm

Dbug wrote:It's probably possible to have something that could handle both situations, after all we can perfectly have a virtual DSK format with 256 tracks and 256 sectors per track, each sector being 512 bytes, that's 64 megabytes of storage, and since the Oric controller supports up to four disks at the same time, this would give you 256 megabytes of storage accessible at the same time.

For the software side, it has to be done anyway, and it would probably be relatively not difficult to patch an existing OS to support these new limits (need Sedoric expert here).
Sedoric is limited by its 2-sectors bitmap size. André C. already pushed its limits to the maximum, unsupported by real floppy disks but fine for emulators use (calling it "Bigdisk"), which is: 2 sides, 101 tracks of 19 sectors. Then the bitmap is fully used.
I forgot many things about Sedoric, but IIRC changing the bitmap management would mean re-writing a LOT of routines - in a kernel that is already full... (this being what discouraged me in finishing the directories management).

User avatar
Dbug
Site Admin
Posts: 2662
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug » Thu Feb 25, 2010 11:35 pm

Thanks for the information Symoon :)

Well, I guess it should not be too difficult to rewrite an operating system, if all it has to support is basic commands to manage files, folders and sectors.

Higher level things like a command interpreter, and similar things can be built on top later. This has to be done anyway even if we were following the original suggestion from Twilighte.

Would actually be an interesting project to work on, and the Sedoric handling always sucked from a programmer point of view, which is why we do not have standard i/o in the C libraries for example.

If somebody can build a decent hardware, I would be definitely interested in making a new OS (compatible real oric of course) that would work fine with large disks and support folders and longer file names.

User avatar
Symoon
Archivist
Posts: 1362
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Post by Symoon » Fri Feb 26, 2010 12:10 am

Thinking about it, would it be possible to do something like a root-floppy disk that doesn't manages files, but other disks. A Sedoric patched for the new hardware, designed to swap disks instead of loading files.
DIR would give you names of the floppies to load, then you load this floppy just like you would access to a folder.

This means having a mass-storage divided in partitions of 900Ko (approx. maximum usable size in a .dsk file).

In other words: boot your Oric with a mini-DOS where you choose which disk to load in drive A, B, C and D, then reboot it all and load the DSK files just like on a real Microdisc. Actually I'm describing what exists when we press F1 in Euphoric and choose the disks on the PC hard drive, then reset.
This way you can:
- use floppy disks as they should originally (Oric DOS, Sedoric, whatever)
- use all mass-storage space by filling it with disks just like you would create subfolders.
The only downside is that you are limited to a simultaneous use of 4 disks (in Sedoric, I mean).

This is a very raw reflexion, but anyway, hope I'm not too off-topic ;-) And I do realize it would mean we have a Microdisc emulation somewhere, which is probably a dream ? (and why not a Jasmin, too...)

User avatar
Chema
Game master
Posts: 2262
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema » Fri Feb 26, 2010 1:35 pm

Very nice idas here... I will try to add my 2 cents again, although remember this is not my area of expertize (if there is any :) )

Back to topic, I now little about the Arduino Mega, but I suppose that a good start would be interfacing the expansion bus to the digital inputs (not sure if some kind of adaptation or buffering here is needed) and check what Dbug said. In a latter desing some decoding could be used to save some I/O pins if necessary for the address bus.

I'd say that surely the chip has some kind of logging capabilities (even by sending data to the host PC) so it would be very interesting to check if addresses are read correctly by monitoring the R/W and maybe phase2 signals. A simple basic program poking the addresses on the Oric could do. Once this is solved (might require accurate timings) we could go for also reading the data on the bus.

For the reading part (with respect to the Oric), the Arduino could write data when an address is PEEK'ed and a simple program peeking the address could be done on the Oric side to check if it works.

Check the posts (including mine, if it is not too wrong) in http://www.defence-force.org/phpBB2/vie ... c&start=45

Only then we could go for activating the overlay ram. That shouldn't be difficult, except that you need a test program in assembler that switches overlay ram in (disabling interrupts) and maybe checking it is present (poking and peeking several values in overlay could do).

I think that would be the more complicated part. If all that is solved, then we could think about adding the EPROM (maybe the arduino could emulate it, having its contents in memory and writting values when necessary). There will be surely timing issues, but as long as it behaves well (no need for accurate emulation as Dbug said) then we may proceed to the next stage.

Not sure if the correct way to go is emulating the controller and its signals and interfacing with a real floppy drive (or the emulated one with SD cards in the link of a previous post) or doing all the emulation here. I think the Arduino might get out of IOs rapidly if LCD and SD interfaces are to be added. If not, then it should be quite easy to map the selected file in the SD. The 128K of the chip won't be enough as to have the whole disk in memory, which could be the easiest way, really.

I really think that trying to do this project with all the ideas posted here and in other forums, would be very big and complex, and might overwhelm anybody trying. And only a "Microdisc compatible" controller to which you could attach a floppy drive would be interesting enough, as there is indeed interest in those controllers, while being simpler... but just theorising here.

Anyway such a design would be an interesting startpoint for new things, such as massive SD storage.

Post Reply