Simplest MMC Interface hardware

[Jeff]

The HxC still needs to go on the controller board, so I guess the question is to know if the WD chip would accept values like 100 tracks per disk

It looks like that on Atari and Amiga, their FDC is able to do this, maybe our can do it?

This chip seems to support up to 256 tracks

[Dbug]

Let's say that the idea of having a MMC or SD card connected to the Oric using the parallel port is doable in a very basic and simple way:
- device is connected to the parallel port
- the oric boots normally without detecting the device
- some code is loaded from somewhere (disk drive, tape, typed manually, present in a custom rom, ...) and allows to access this external storage

What would be the minimum amount of components usable to achieve that, how difficult would it be to handle that software wise?

Assuming it's doable, that it is very small, there's actually a number of possible usages for such a device, even if it's not optimal:
- it could be used to easily transfer stuff between the PC and the actual Oric, so the data could be saved to a real floppy (for example)
- by using a 32k EPROM, one could contain the code to access the flash card to transfert data to the main memory, the second being the normal Atmos ROM.

Advantage is that yes that would not collide with any other hardware that uses the expansion port, that would allow some form of reliable loading of massive amount of data. Problems would be that nothing is automated, you don't get the overlay ram either.

Just thinking out loud...

[kenneth]

The SD card drive connected on the printer port could have a second connector plugged on the sk1 socket of the oric used for the tape recorder. And a double connector (male female) for the power using 9V and could work like that:
-Type CLOAD""
-The SD card drive receive the order with rl1 relay (used to remote the tape recorder)
-The SD card drive send the boot program with autorun protocol through the tape recorder line.
-The Oric is now able to communicate with the drive through the printer port for example with ! LOAD and ! SAVE etc

[highwayman]

if you really want to do this,

use the bus-port.
map a new rom over the old one, with the tape routines removed & replaced with the sd ones.
and you can map the sd card over one of the bytes in the rom-space.

a simple gal device can do the address mapping for the sd/rom.
it would cost beer-money.

dont automaticaly jump on fat16 though - it's very limited.
i'd also look at some of the unix format's like Ext2 - we have the Linux kernel source etc to get drivers/info for every format on earth other than EXFat anyway.

also, dont bit-bang a serial pin - it's slow.
a 1€ microcontroller can shift from 8bit bus to a serial protocol and really speed the thing up!

[Xeron]

fat32 is easy enough. I have a basic fat32 routine somewhere.

[Dbug]

if you really want to do this,
use the bus-port.
map a new rom over the old one, with the tape routines removed & replaced with the sd ones.
and you can map the sd card over one of the bytes in the rom-space.
a simple gal device can do the address mapping for the sd/rom.

So, we would get the alternate set of rom to boot, plus the overlay ram management, so basically same thing as Jasmin or Microdiscs are doing.
Knowing that there's no actual real base performance/timings to mimic, and no particular compatibility criteria to observe, what would be the easiest way to make such a device?
What do you mean by "map the sd card over the rom-space". Is it possible to map a card like that directly? Was thinking it was some kind of serial controller on this type of card.

If the device works, and is cheap, then finding volunteers to make an actual "operating system" should not be too difficult.

Cumulus was ideal, but no progress on this side, and last quotes were expensive, so perhaps something not compatible with original disk systems would do, as long as there are way to hack/port existing applications to use the large storage system. If it's "cheap" and easy to build, it means there's a chance to get a number of people buying it.

[highwayman]

when i say map the card into the romspace, i'm not talking about a large area,
i just meant overlaying a couple of bytes - say data & status/command to an address that is normally used by the rom so it wont collide with anything else.
for example, using $c000/c001

that said, maybe - just maybe, with a fast enough microcontroller you could actually have a data buffer - 2k/4k or whatever.
but i dont see the point.
it would take the 6502 almost the same amount of time to copy it down to the 800+ area as just reading bytes sequentially from the same high address.

here is a plan i mentioned before,
go look at SD2IEC
http://www.sd2iec.de/

this is a c64 project to create multiple virtual floppies & drive in a fat32 sd-card.
it uses a serial port to comunicate commands & sequential bytes to the computer.

taking it as a starting point - hardware is minimal btw.
you could start by ditching the serial coms & using an 8bit port tied to an address or 2 in the oric.
that's it - jub done on the hardware side.

then adapt the software to make virtual floppies with the same space etc as an oric floppy or just throw the whole file-system in the trash & consider it a limitless virtual harddrive.

all you need to do on the oric side is implement new cload & csave routines to comunicate with the atmel micro via the 2 oric addresses.

there arer dozens of coders & well over a year - probably several gone into that project - i dont think we could do better than use it as a base.

[Dbug]

As you wrote, this SD2IEC is emulating a 1541 drive. It uses the existing dedicated port and the existing basic commands to access this serial interface. So there's nothing special to do to handle bank switching or flimsy bus timings.

Every single hardware project I've been following on the Oric has stopped with a 90% something working solution: It worked on the developers machine but happened to be not reliable on other machines. Then started the game of adding or replacement components here and there to delay/rectify/amplify the signals, shorten the cables, etc... imo this is *the* big problem to solve.

At this point, I don't really care about the microdisc or jasmin compatibility anymore, all I want is something that
- auto-boots and installs some basic functionalities to access the storage
- allows to use the overlay ram at will
- is simple to program and reliable (ie: not too strict timings)

I was discussing with Torlus yesterday, he was saying that probably for about 20 euros (give or take) it was possible to have a small something based on a SDCard module, some MCU, a 32Kbyte SRAM. That does not seem very far from what you suggested. The sram could be used both to store the "boot rom" transfered from sdcard by the mcu on startup, and then as well as a transfer buffer for the sectors exchanged between the oric and the card.

The big question was:
- is it better/easier to use page 3 addressing to read/write data (microdisc/jasmin style), or to share some bytes in the top 16k?
- how does the command handling, reading and writing of data, notifications of end of read/write happens
- how is the bus shared? (ie: can the 6502 do things on its side while the mcu read or write the sram?

As a programmer, what would be awesome is to not have to use the page 3 at all, and just use some shared memory. I would be perfectly happy using the C000-Cxxxx area to send commands and read the result, specially if this can be done asynchronously (Direct Memory Access).

Now of course the problem is that we need a way to be able to switch the overlay on and off, which probably means we have to use page 3 anyway... so perhaps some mixed approach could work, with the page 3 to send commands, the IRQ signal to be informed when the command has been processed, and for example a 256/512 bytes buffer starting in C000 for the data sent/received.

Let's make a deal:
If anyone manage to build such a device, then I promise to spend time to make the 6502 side of the code to provide at least basic support for accessing the SD card with some basic operating system with commands to list, load, save files. I will also spend the time to convert some floppy demos and games so they work on the new device. All the code would be of course on the SVN depot (full access to the source code)

[highwayman]

well i had not thought of keeping the bootrom on the sd-card - interesting idea.

the way the load/save works is basicaly that you request a file by name & it's returned in serial format.
very similar to tape - probably because it was started on the pet/vic20
the sd2iec uses virtual folders/disks by assigning magic filename prefixes to switch/create them.

to save complexity at the extra expense of a few euro i'd start by using a seperate boot-flash though.

the timing issues where bulshit caused by trying to tie 2 realtime systems together that used different clocks - that shouldnt be any problem here because the sd2iec can wait on the oric.

the only other issue is the oric's stupid negative-regulated power system.
the stuff must all be powered from the oric - and no external links like usb etc,

about page3 - are there any safe bytes in page-0 ?
we can get much faster load/save loops using zero-page obviously.

[highwayman]

missed a few of your questions,

32k sram is history - the microcontroller has more than that.
and an absolute shitload of flash too - 128k in the one i'm looking at.

no buss issues should happen, the iric is 1Mhz, the micro is 20Mhz - it can slave the buss and wait for the clocks.
and as it can run down to about 2.7v weak signals shouldnt be an issue - although that shouldnt happen unless to have a 6inch ribbon cable anyway!

now you asked about if the oric has to wait on sector-reads or if it can go do it's thing - presumably like playing tunez.
forget sectors - that's why the microcontroller has 128k or flash, 64k+ of ram and a 20Mhz clock.
you write bytes, you recieve bytes - the controller worries about sector allocation, erase/write etc.

i dont know yet how best to signal that a byte is ready, either by status-register or interupt.
the cbm machines used an interupt afaik but we dont need to.

now let me be clear,
i have a *very* minimal hardware in mind - leveriging the speed of the microcontroller.
this has never been tried before!

what i want to try is this,
in the past - as you know, you used logic on the bus to decode the addresses of interest.
this then latched a data buffer on the data-bus.
so whatever the hell you tried to do, you had between 3 & 6 ttl chips to do the address decoding first.

i want to try directly putting the microcontroller on the bus - cpu>mcu.
three 8bit ports, one for the data-bus and 2 for the address-bus
then a few bits from a fourth port to watch R/W clock etc.

i'm pretty sure the mcu is fast enough to see the clock, then analyse the 2 address ports and either read, write or ignore the data port.

if not then extra chips will be needed like usual - but if i'm right then you can pretty much read or write *any* address in the oric at will!

i need to find my orig & build a test board - i have the bits to make an sd2iec here.
i can try just intercepting addresses to display status on an led to check if the timing is possible.

if it comes to it the latest version - "arm2iec" will be more than fast enough to do anything you could think up!
but i'd rather use an AVR for cost and simplicity reasons.


this may be worth reading for people who dont know the sd2iec project:
http://www.c64-wiki.com/index.php/SD2IEC
http://www.c64-wiki.com/index.php/sd2iec_(firmware)

[Torlus]

no buss issues should happen, the iric is 1Mhz, the micro is 20Mhz - it can slave the buss and wait for the clocks.
and as it can run down to about 2.7v weak signals shouldnt be an issue - although that shouldnt happen unless to have a 6inch ribbon cable anyway!

I think you're a bit optimistic there.
At 20MHz, assuming 20 mips, you have at best 20 cycles for your routine. I don't have the timings requirements off my head for memory access of the 6502, but I believe you should better go for 15 cycles max.
If we do a basic cycle counting, we end up with something roughly like this (I assume you'll use a 8-bit PIC or AVR) :
- Sample the 1Mhz clock edge : 1 cycle.
- Compare/jump logic, at least 3 cycles (a taken jump is likely to invalidate the instruction pipeline).
- Sample the two 8-bit ports for address bus, and R/W : 3 cycles.
- Compare/jump logic : 3 cycles.
- Setting data bus port direction : 1 cycle.
- Reading from mcu memory/fetching the data bus value : 1 or 2 cycles.
- Jump back to the beginning : assuming 2 or 3 cycles.
And that's for basic ROM emulation... Your routine will probably have some other checks to do, so in my opinion, this is not going to end well...

Anyway, as DBug stated this morning while we were talking about it, there is another issue.
After receiving a command, the MCU will be busy doing something else, so won't be able to handle ROM emulation.
If an interrupt occurs, the 6502 will fetch its interrupt vectors at the location that is supposed to be handled by the MCU, and boom.

However the idea is interesting, and might be doable with a beefed-up MCU.
Or a XMOS chip, that looks very suitable for this task.
I have some ideas myself, but I need to sort everything out before talking about it.

[Igotafro]

the only other issue is the oric's stupid negative-regulated power system.
the stuff must all be powered from the oric - and no external links like usb etc,

Couldn't you just use a opto-coupler?
Or even with IR and make it wireless

[highwayman]

make what wireless, the whole bus?


but seriously,
you cant link the oric to something that has an independant psu without isolating it.
so usb for example is questionable.


btw, with modern mcu's the oric could have usb(1.1) or ethernet real easy.
but i'm not sure how big the software would be - it could probably be done because you can do ethernet on the c64.

Btw.
20Mhz AVR is 20MIPS

i wasnt thinking about flash emulation.
i was thinking:
clock generates an irq,
read upper address and compare.
if it's in range, read lower address and compare.
if that's good, read or write data relating to the SD function or set an output pin for ROMDIS / flash enable.

but your right, it dont leave much for the original intended function.

i'll have to look at seperate address decoding using a gal or something.

[Dbug]

btw, with modern mcu's the oric could have usb(1.1) or ethernet real easy.
but i'm not sure how big the software would be - it could probably be done because you can do ethernet on the c64.

There's already TCP/IP stacks for 6502, so that's not impossible by itself. They have ethernet both on the C64 and 8 bit Ataris.

If you can get a design that gets us large data storage, ethernet, and support for a usb mouse, that works on all the machines and does not cost an arm, I will call you Master

[highwayman]

that's doable,
but if you can show me the software for the ethernet-stack, the usb driver and so on,
that still leaves room for an aplication program i'd be pretty surprised.

the usb already exists on a number of atmel's,
the ethernet is done via a serial port on the same mcu.
see this for an example.
http://tuxgraphics.org/electronics/2006 ... 6061.shtml

you seem concerned about hardware,
as a hardware guy, my concern is getting as much onto the mcu as possible to save wasting ram in the oric.