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.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

HANG ON!
why do you want a mouse :?: :?: :?: :?: :?:
:D
Igotafro
Officer Cadet
Posts: 47
Joined: Tue Feb 05, 2008 3:42 pm

Re: Simplest MMC Interface hardware

Post by Igotafro »

Ofcourse we want a mouse, for a nice OS with windows, Oric Photoshop, RTS games :)

Btw, if you're only interested to have a mouse, you could implement a PS/2 mouse (much easier than USB) and the have a passive PS/2 -> USB circuit. Then most USB-mice can be used anyway.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Simplest MMC Interface hardware

Post by Dbug »

highwayman wrote: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.
There are really two approaches:
- The "super duper" expansion, that brings loads of memory (doable with using bank switching and plenty of memory pages), microdisc emulation, network, mouse, ...
- The "minimal feature-set, minimal cost" expansion, which does not do much but solves an actual problem: The lack of availability of large storage hardware.

Now, I guess a part of the work to do to achieve these is similar: Bus/signal/addressing/romdis/map/connector/power are probably identical on both cards. Both cards would have to interface with the host machine, both card would have to use similar ways to be accessed, etc... so perhaps what would make sense is trying to get a very basic system that works as a proof of concept. Actually the larger card could be seen as a super set of the basic card I was discussing with Torlus.

After discussing on IRC, plus this forum here, it seems that we have different people with different needs, but with one common part: Being able to access a large storage of data efficiently.
- Me (Dbug), I'm fine with a basic card that is not microdisc or jasmin compatible, that requires patching of programs, does not bring more memory. The basic mcu+sdcardmodule+sram is enough for that. This card as a bonus allows to emulate an Oric 1 on an Atmos or an Atmos on an Oric 1 by allowing to write in ROM or replace completely the rom just by loading a file from the sd card.
- mmu man would like to see something like contiki to run on the Oric. Ideally having an expansion that adds many pages of banked memory (like on the Telestrat) would be ideal. I guess having a mouse would be practical too considering that the OS has a graphical user interface.
- highwayman: as much as possible :)

So my suggestion would be to try to get all the hardware people around here try to focus on the simplest prototype that allows to reliably interface with an oric, with all the address decoding and signal handling done, it does not have to be a sdcard module on the back, can be anything simple, but at least something that could be useful and practical to test and debug this kind of hardware.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

o.k.
well asuming using hardware address-decoding and an atmel AVR,
the sd-card is there,
if the atmel has a hardware spi port not used then ethernet is pretty much a given - just add software.
if it has a hardware serial port then maybe rs232 or ps/2 serial mouse - again by adding software later.

usb is probably not going to happen because usb-on-the-go pushes up the cost and i think they are only big surface-mount chips.

so forget usb for now,
asume sd-card for now, and if the chip has spare ports then that's "future expansion"

so, how do we talk to it?
i was thinking treating it like a traditional pheripheral chip,
ie:
a byte used to transfer data and a byte used to read status/send commands.
probably employ an irq/nmi to indicate a byte is ready too.

and repeating my last question, are there any spare bytes in zero-page?
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Simplest MMC Interface hardware

Post by Dbug »

highwayman wrote:and repeating my last question, are there any spare bytes in zero-page?
Yes there are, quite many actually, why? Do you just need few bytes, or do you need a whole bunch of consecutive bytes?
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

consecutive bytes.
probably no more than 2 or 4.

i want zero page because if you load a file,
your gonna run a loop reading from the buffer byte and writing to consecutive destination bytes.
just like loading from tape.

and obviously reading from page zero uses less cycles so runs faster.
also, i want to stay away from the $0300 area because other things use it.

just thought btw, the atmel has 4 or 5 8bit ports - so joysticks would cost nothing but the connectors to add.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Re: Simplest MMC Interface hardware

Post by Torlus »

Using page 3 would be much easier, all you have to do is handle "IO" and "IO control" signals to disable the VIA.
Using page 0 would require to properly handle the MAP signal, which is much more difficult as its timing is picky. On Microdisc for instance, you had to adjust a variable resistor to get it right.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

well i'm not so sure,

anyway - address decoding can be done later.
on the mcu stuff, i looked into some detail.
we can/will have ethernet, SD-card(micro-sd) and ps2-mouse.
probably joystick - but not sure how.
i may need to add a multiplexer because i/o is getting tight.

any rom will be seperate from the mcu.
i want to use a 256k device with a 2bit bankswitch to give the following:
0 - standard rom
1 - new-rom(a)
2 - new-rom(b)
3 - ROMDIS(ram acess)

and the reasons for 2 banks is simple, 32k devices are much easier to get than 16k ones.
also, i would opt for using ferromagnetic ram instead of flash because it can be directly written without having to erase whole sectors.

i already have a 32k ferro in the spares box to play with anyway.


i'm going to spend the rest of the week playing with Eaglecad to get a preliminary design or 2.

:D
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Re: Simplest MMC Interface hardware

Post by Torlus »

Well, I'm not sure to understand all what you mean, and it seems to me that's you're ditching away some critical stuff about the Oric expansion bus and signals, but well, I may be wrong, or too pessimistic.
However, if you haven't done it already, please have a look at Retromaster's Cumulus-related blog posts, or Microdisc schematics.

Anyway, here's my take on an Oric SD-card interface :
- The board would contain a 32K SRAM. I'm thinking about this one http://www.digikey.fr/product-detail/fr ... ND/1206029 which is cheap and widely available.
- It would feature a MCU such as a PIC18F or its AVR counterpart, with SD-card connector and such.
- A GAL would be used for address decoding, as well as bus buffers (74LS244/245).

Now the principle of operation :
- There would be no MAP signal handling, as "shadow RAM" won't be used. (*0*)
- ROMDIS will always be asserted (*0*).
- Upon reset (power-up), the Oric would be held in reset (pull-down resistor or large RC circuit, to let time for the MCU to start). (*1*)
- The MCU keeps the Oric in reset state, so has then full control of the SRAM.
- It will load an Oric standard ROM from the SD-card into the lower 16K of the SRAM (*0*).
- It will load a custom ROM from the SD-card into the upper 16K of the SRAM.
- The reset will be released, and the Oric will boot on our custom "ROM".
- The custom ROM will act much like any expansion card's ROM, i.e install some stuff in page 4 and use memory-mapped registers in page 3. (*2*)

Now the tricky part, the handling of page 3 :
- The GAL will do some basic address decoding and handle "IO" and "IO control" signals, as well as a signal for the MCU.
- Upon memory access of the Oric to the range reserved for memory-mapped registers (GAL output signal), the MCU will handle a request. (*3*)
- Requests will be either bankswitching between lower and upper 16K of the RAM, or SD-card related stuff.

Now for some remarks :
(*0*) : Even if it is a waste of the "shadow RAM" and means the loss of your Oric ROM, it has some positive counterparts :
- You can load an Oric-1 ROM into an Atmos and vice-versa effortlessly.
- Both "ROMs" are RAM, so you can do whatever you want of it. For instance erase the Basic ROM, set up correct interrupt vectors on both banks, etc.
(*1*) : Apart from an Oric standard ROM and a custom Oric ROM, the MCU's firmware itself could be loaded from the SD-card, allowing easy updates.
(*2*) : I'll let _Dbug_ correct me if I'm wrong ;)
(*3*) : Timings are to be checked here.

It's far less ambitious, but would be cheaper. And easier to design.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

32k of ram - you mean as 2 banks for o.s.?

i keep getting confused about why anybody wants a ram chip.
and the mcu cant write an o.s. image without sitting on the whole address & data busses - that's gonna eat up all my i/o

i'd rather have the expansion rom just written from the oric side.
the sd2iec code already updates the mcu flash from the card btw.

think of it as 2 almost seperate things.
the replacement rom (or in this case ferr-ram),
and the sd/ethernet/ps2 stuff.

the only thing i want the mcu to do in relation to the replacement rom is control the banking.


i was thinking 4 bytes of memory.
1 write buffer,
1 read buffer,
1 status byte for checking stuff - see my next bit,
1 control byte for writing stuff other than byte-streams.


now i think want the address-decoding to cause an mcu interupt,
the mcu will then act on whatever was written.
i think that's probably better than just polling an i/o pin constantly.

and i want the mcu to generate an interupt on the oric when it has something ready.

here is where the status register comes in, i want a bit to indicate if the irq/nmi was external - ie ours,
or if it was from inside the oric.
also to indicate the ferro-ram/ram/original-rom banking status.
maybe some other stuff too - like if the sd-card is missing or an ethernet signal is present or not.
just a bunch of bits to flag stuff.

the copntrol byte will be for stuff like selecting the ferro-ram/ram/original-rom banking.
it may be a good idea to have a lockout on the write-enable too.


as for address/data buffers (244's, 245) i'm not sure we need them.
i know a cmos gal has lower pin-loading than those buffers, it may also be true for the mcu.
if that's the case then the buffers would actually make it worse.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Re: Simplest MMC Interface hardware

Post by Torlus »

highwayman wrote:32k of ram - you mean as 2 banks for o.s.?

i keep getting confused about why anybody wants a ram chip.
and the mcu cant write an o.s. image without sitting on the whole address & data busses - that's gonna eat up all my i/o

i'd rather have the expansion rom just written from the oric side.
Well, if I understand correctly what you want to do, you'll use some FRAM to store the expansion ROM and have the Oric program it. I guess it would be done by a routine that should be itself loaded from the cassette port ?

There are some ways to reduce pin count needed to write to the RAM from the MCU, for instance multiplexing data/address lines.
And whatever solution is used, with proper bus isolation, you can "recycle" most of these I/Os after boot, as they are not needed anymore.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Re: Simplest MMC Interface hardware

Post by highwayman »

just thought i'd give an update,

i'm generating the mcu-side schematic.
just working out the best way to link 5v & 3.3v stuff at the moment.
that, and trying not to design it with anything that will be hard to source.

it may be a problem using fram, i think ramtron may be discontinuing 5v parts! :(
gonna check this and also a slightly inferior alternative.

also started thinking about ditching the internal ram bank & expanding the fram(or equiv) to 128k for 8 banks!
if that's not enough to keep people happy them use m.e.s.s. / oricutron! :lol:
Igotafro
Officer Cadet
Posts: 47
Joined: Tue Feb 05, 2008 3:42 pm

Re: Simplest MMC Interface hardware

Post by Igotafro »

Good to hear, keep up the good work.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Re: Simplest MMC Interface hardware

Post by Torlus »

highwayman wrote:it may be a problem using fram, i think ramtron may be discontinuing 5v parts! :(
gonna check this and also a slightly inferior alternative.
Please, if you find an alternative to the Ramtron chips, even in 3.3V or less, please let me know ;)
Anyway, if you're looking for a "second eye" to look at your schematics (for error-checking) please count me in, I'd be glad to help.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Simplest MMC Interface hardware

Post by Dbug »

On my side, I have two other questions:
- How expensive/difficult is it to have 8 banks of RAM versus just 2 banks. I guess it's a bigger memory chip with more pins, is that much more problematic to use? If not, why not 16, 32, 64 pages??? (just to push the cork)
- Is it easy/possible to have a RTC (real time clock and date) on the board? If the board is supposed to be used to store many files, it would be nice to be able to save the time and date of when the files were written. Would also be nice to have the time and date for people who want to port Contiki (or other micro linux)

/me still thinks that having joystick and mouse ports could be awesome, would allow us to make other types of games.
Post Reply