MMC-ORIC

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
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

JamesD wrote:If you are the expert, you build it.
Huh, that sentence is a bit hard, isn't it?

I only hope you took no offense, JamesD. I was just participating into the discussion, from my already declared incompetence in the field. Just trying to add my 2 cents, but, of course ANY work done for the Oric is more than welcome from my side. And will receive all my gratitude and admiration.

Maybe I went to offside the actual objective of your desing, and missed the point suggesting things that simply do not apply. Sorry if that is the case. I simply get too much enthusiastic when talking about Oric.
jede
Flying Officer
Posts: 191
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Post by jede »

Hello,

Well We don't really need a FPGA to read sd card.

There is a hundred of usb microcontroller (Like atmel, microchip).

There is also sdcard reader which should require some code on the oric.

http://www.ghielectronics.com/product/1 or http://www.ghielectronics.com/product/102

You have just to send commands to this controller with I2C. Sedoric must be patched anyway (to call I2C routines instead of microdisc routines).

This chip won't work with personnal microdisc routines of course.

It should be easy to do this interface, but i am working on another electronic project :)
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Huh, that sentence is a bit hard, isn't it?

Yup... and I wanted to say it many messages ago.

Look at the commands a disk controller handles. Step in, step out, there's a status, and you can tell it to read and write. Not much more.

Different controllers have the ability to change density and some other settings but they are generally pretty simple and the rest is left up to the software. You don't tell it to read a specific track, you tell it to step a certain number of times and you keep track of the drive track. Basically you step down until it's at 0 and count your way out.
You may even have to tell it to step two times to go from one track to another. The servo can step half tracks but there has to be space between the tracks so you don't overwrite any neighboring data. You also have to delay between steps to give the servo time to step from one track to another. Then there's settle time before you can read data, finding the start of the track, etc...

A controller *may* tell you where the start of a sector is but some don't and you time how long from the index or from the start of the track to start reading a sector.

Now, to emulate a controller you may not need all of that but I would think you still need something emulating how a track/sector is read.

You have just to send commands to this controller with I2C
http://www.esacademy.com/faq/i2c/general/i2cproto.htm

You are suggesting replacing a serial interface with... a serial interface.
:roll:

And what does that do for us? You seem to have skipped the software support part required by USB which treats a plug in SD interface as a mass storage device on top of a USB stack. You have now made it even worse. You need a USB stack, a file system, and the drive controller emulation.
<edit> I checked the links after posting this. There is no need for those chips. There is FAT file system source out there that would run on a microcontroller if you take the drive emulation approach.
You save a little ROM space on the direct interface but the SD controller simplifies the software enough it should allow you to add the FAT code to the ROM. IF it wouldn't fit that might be a good alternative but at a higher cost and more complex design. </edit>

What we were discussing was using an internal serial interface on a MCU to attach to an SD drive but have an interface to emulate a drive controller and an additional interface for directly accessing the file system for access as a mass storage device.

The point of using a small programmable device was to interface between serial and parallel to directly control the SD from the Oric. Small programmable devices in any kind of quantity are probably around $5 or even less and it can also handle part of the addressing logic you HAVE TO HAVE! Such a device would even be desirable to interface an MCU to the Oric since fixes could be made without changing the board.

The small device on one Speccy interface actually has two SD interfaces and can have a joystick interface as well. The entire board plugs into the Z80 socket and is about twice the width as the Z80 with the SD socket on the board.


Some comments for some of the people adding their 2 cents.

1. Stop looking at the C64 SD interface that comes directly off the computer to the SD card. The C64's CPU has a built in serial port! No driver code has been released for that and the build in DOS does not support it.

2. Don't look at the nice little devices for the C64 and Atari that use a nice little drive emulator done in an MCU. Those machines use a serial bus to interface to their drives and an MCU can talk to two separate serial interfaces without added hardware. One for the bus, one for the SD card.
The Oric DOES NOT DO THIS and has no built in DOS! You will need some sort of ROM for the DOS no matter what and the interface will be more difficult! (BTW, if you look at the Atari Serial Bus protocol it looks similar to USB... and yet USB deserved patents?)

3. "You just need an MCU",,, and you can just build a cold fusion plant to solve the world's energy problems. Sounds simple but in practice it's a little more complicated.
Any MCU needs code to talk to the SD card and the Oric.
Have you ever programmed a line of code in your life that talks from one CPU to another let alone processes dozens instructions on the MCU fast enough to give a response to the other CPU within 1 clock cycle of the other CPU? That last one is a must to emulate a drive controller unless you use a larger FPGA to do the interface.

4. Don't think it's easy because the Minimig does it. The minimig is a poor example since the Amiga controller works very different than other controllers. The entire track is read in and decoded once in memory. Totally different than the Oric's controller. Trust me, I worked on a driver to read CoCo disks on the Amiga 5.25" add on drive. It's ugly.

5. If you think this will be cheap, think again. Getting 50 boards printed that are large enough to hold a connector that will attach to the Oric and is large enough for a ROM, PLD, MCU and SD connector will probably cost you $50 US each. If you are lucky, $25 on a special. Then you'll want to print prototypes before you ever go to production, there's parts, assembly cost, lots of hours of development... it adds up. If you want it in a box that will probably be the next most expensive item after the board (not counting labor/development).

The Amiga ROMatic ROM switcher my company produced was just over $2 per board in 1000 quantity... and it sold in the hundreds so we didn't even break even. But that board was barely bigger than two ROMs... I couldn't get it any smaller. If we had produced it in the 100s it would have been more expensive and it would have sold in the dozens. If we had produced 100... we would have had to pay $20 a board somewhere else for prototype quantities and that board didn't have solder mask.
Last edited by JamesD on Sat Jul 04, 2009 7:04 am, edited 1 time in total.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Sorry for being blunt but my patience has already been used up on a personal matter.

I'm not a hardware engineer. I'm a software guy that learned digital logic and some electronics as part of my CS major. I have designed a few circuit boards and small circuits and even owned 1/3 of a 3rd party Amiga hardware company. I also have several years of experience programming embedded systems including hardware drivers, CPU to DSP communications, medical devices, etc...

I'm trying to learn Verilog and VHDL when I have time. I could take an existing part and combine it with some address logic to customize it for an application like this. I could probably even write the code to do a simple interface to an MCU. But I'm mostly in a learn as you go situation and something that is that timing critical requires tools I do not have and I would think far more experience than I have. You would need a person that designs hardware for a living, preferably with FPGAs.
On top of that I could not justify investing the time required for programming the emulation code on the MCU and the revisions required to get the timing right.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

If you want drive emulation I'd start with the controller here:
https://svn.pacedev.net/repos/pace/sw/s ... orm/trs80/
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

JamesD wrote:If you want drive emulation I'd start with the controller here:
https://svn.pacedev.net/repos/pace/sw/s ... orm/trs80/
From the development history, that is a read only interface with an SPI Flash device. Some work was done for writes but I don't think it writes to the Flash device.

If the serial protocol were changed it could communicate with an MCU over a serial interface instead.

A quick look through the code revealed a bunch of constants for the TRS-80 such as 35 track disk drives. I think a lot of that could be handled by the MCU so that it could be a generic disk interface and the MCU code customized for the system specific disk files. The code isn't commented well so it could be difficult to figure everything out. The logic is also designed to attach to the wishbone bus. That's fine if you want the entire system on a chip made out of open source components but would need modification for the Oric bus.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

JamesD wrote:Different controllers have the ability to change density and some other settings but they are generally pretty simple and the rest is left up to the software [...]Then there's settle time before you can read data, finding the start of the track, etc...
That's the point of the discussion, really.

On Atari ST you really have to have a very fined grained emulation, with correct timings, support for invalid tracks with missing gaps, special formatting, error detection, etc... because a gazillion of games have special loaders and protection that require that.

On the Oric, all that is necessary is to recognise the values written in the page 3 as commands for the disk controller, even the timings can be wrong and it would still work ok because none of the software talking to the disc units bother about timings at all (they work perfectly on Euphoric that have a very approximate (ie: nearly nonexistent) timing emulation for the disc commands.

The only thing we are doing on the Oric is to send the seek to track and read sector/write sector commands, and read the bytes comming one by one from the interface. Does not seem to be rocket science.

And since we are working on "virtual floppies", the interface don't even have to support anything about formating commands. (but yeah, should support 256/512 bytes per sector formats)
JamesD wrote:5. If you think this will be cheap, think again. Getting 50 boards printed that are large enough to hold a connector that will attach to the Oric and is large enough for a ROM, PLD, MCU and SD connector will probably cost you $50 US each. If you are lucky, $25 on a special. Then you'll want to print prototypes before you ever go to production, there's parts, assembly cost, lots of hours of development... it adds up. If you want it in a box that will probably be the next most expensive item after the board (not counting labor/development).
The device you were referring to on the Atari is probably the Satan Disk. I happen to have two of them, and I ordered the new UltraSatan model. On the Atari it makes sense for me to have that and not a floppy emulator, because my real Atari comes in standard with a floppy drive, no need to search for one on eBay. Also the SatanDisk makes sense because you can use the default existing disk drivers. If it had required a special software for accessing data, not had been compatible with the default DOS commands, I would certainly not have bought it.

I don't know for others, but I would have no problem buying a (working and usable) $100 device if it was hapilly replacing my dying MicroDisc.

Personally, I have the feeling that you have an idealistic vision of the "simple SD card", and an overcomplicated idea about what we want when we talk of the floppy emulator.

The simple SD card or IDE drive is not yet there because the oric timings are sucky. Two persons started (years ago) their own IDE projects for Oric, and stopped after failing to get consistent readings, they were bytes lost here and there. So whatever type of interface you'd like to do, you will have to deal with this type of problem.

Then yeah, the floppy emulator would require support for a boot rom in order to boot strap the system, but since it has to support overlay ram switching anyway, all it has to do is to do what an normal oric controller do: Boot by disabling the internal ram and rom of the oric to make it show the internal controller ROM. And here you are. Nothing else required: Since the interface supports the native commands, as soon as the rom is visible, everything else is done, and it will work whatever the mounted floppy is using as a system - because they need to support an universal boot sector format for the controller ROM to be able to boot at all.

The bottom line is simple, sure you can produce a low cost and easy to use simple interface that would potentially give access to a lot of storage capacity, but me as a customer I don't see what I would do with it because it could not run the existing software, and I would not create software that would work only on an interface that 10 people have.

On the other hand, as a software developer and demo-maker, paying for an expensive device that would allow me to go in demo parties with every-single oric games and demo stored on a small card, yeah, hell yeah.

Final point: You may or may not agree on the position of the various people here, but we don't have to be dismissive or superior in tone. It's the first time in 3 year that I felt like using the moderator's probe. I can understand that somebody can become frustrated when one has to deal with people who don't see all the sides of something and give ideas that don't work. See that as proof of interest, not as personal attacks. If you dismiss everybody by talking of "2 cents ideas" and "if you are the expert, you build it", you risk fast being happy to be the only one being right in your own thread talking to yourself.

Peace and love ;)
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Post by Torlus »

Eh it looks like I didn't read the forum carefully, and I discover this thread today ;) (I also discovered the two "pokes" sent to me by romuald about Oric hardware developments ;) more on this later...)
Anyway, allow me to add my 2 cents...
JamesD wrote: I'm not a hardware engineer. I'm a software guy that learned digital logic and some electronics as part of my CS major.
That pretty much summarizes my own experience. I'm not a hardware engineer myself, I'm a software guy too. My own experience with digital logic is fully self-taught.
Why am I talking about it ? Well that's because I've been lucky enough to be involved in Jeff del Nero's "HxC Floppy Drive Emulator" project in its early stages (well he already had a fully working floppy drive emulator in TTL devices, but I've followed his progress when he switched to programmable logic).
There are 2 flavors of the floppy drive emulator. One uses a CPLD (programmable logic) and USB to communicate with a PC host, and the other one, developed later, uses a PIC microcontroller, and a SD card. One of this version supports only read operations from a floppy image, and the other one supports read/write to a floppy image for many platforms. From an external point of view, one looks more like the work of a hardware engineer (the CPLD-based one), one more like the work of a embedded software developer (even if both flavors of the emulator are the work of the same, extremely talented person, which has degrees in both hardware and software development).

Guess what ? The more advanced version is the one based on a PIC microcontroller, using a SD card...

I don't want to give false hopes to anyone, but it might not be impossible to have a cheap solution, compatible with Jamsin or Microdisc units.

Last year, I've discussed with Fabrice Francès about a possible Oric SD extension. We both agree that starting "from scratch", with a custom DOS, would be the easier path. Achieving compatibility to existing devices requires a lot of work as it will probably require the sum of many hardware and software guys' talents.

I am personally amazed by the software skills of some people here, and their knowledge of the internals of the Oric. I couldn't write anything close to what they're able to do on this machine, even if I know some stuff about this machine, due to my work on its hardware emulation.

So I don't think dismissing comments by these people on such a thread is the good way to go, JamesD. Hardware and software guys don't share the same ideas, but as a software guy, as I am, I think you should understand their concerns.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Post by Torlus »

I see mostly 2 ways to go :
- Use existing work done on the floppy emulation, i.e for instance HxC Floppy Drive Emulator soft core (USB version), take the schematics of an existing interface (such as Jasmin http://www.teaser.fr/~amajorel/jasmin/j ... 100dpi.png) and write soft cores for each component, and here you go. The only difficult parts to emulate are the WD1170 and the PAL. For the first one, I think there are existing cores on the net, and for the second one, I think it would not be too hard to reverse-engineer its behaviour. Buidling such an interface would require a FPGA, would probably be expensive, especially if you have to design a board and such. However, I think that using an existing board, with some external parts, would minimize the initial investment while keeping the solution in the $100-$150 range.
- Analyze existing software, and see which are the real timing requirements. According to what DBug said :
Dbug wrote:On the Oric, all that is necessary is to recognise the values written in the page 3 as commands for the disk controller, even the timings can be wrong and it would still work ok because none of the software talking to the disc units bother about timings at all (they work perfectly on Euphoric that have a very approximate (ie: nearly nonexistent) timing emulation for the disc commands.
I don't think you need a cycle-exact solution. The fact that the Jasmin uses a floppy drive controller (WD1770) adds up to this, as these controllers are themselves quite tolerant about the floppy drive timings : during the development of the HxC emulator, Atari ST compatibility has been excellent from the start, due to the WD1772 this machine uses. The real pain in the a** came from the Amiga, which has no such controller, and the vast amount of custom trackloaders you could find in many demos and copy-protected software. Building such an interface would probably require a ROM, a simple PAL and a MCU, keeping the final price low.

The first solution is easier, you don't have to care about software, just emulate the components, dump the exisiting Jasmin ROM, and there you go. I might give it a try, but I don't promise anything. ;)
The second solution is more challenging, would probably please more people if the price stays low, but needs to have a good understanding of the Oric+disc unit as a whole, both in terms of hardware and software. I don't feel myself going this way, alone at least...
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Hum, I missed something :)

On this thread here http://www.yaronet.com/posts.php?sl=172&s=90784&p=6 there is a photo of an interface connected to the Oric, showing apparently the Barbitoric demo.

Is it loaded from the Microdisc, or from the interface ?
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Post by Torlus »

Dbug wrote:Hum, I missed something :)

On this thread here http://www.yaronet.com/posts.php?sl=172&s=90784&p=6 there is a photo of an interface connected to the Oric, showing apparently the Barbitoric demo.

Is it loaded from the Microdisc, or from the interface ?
The answer is : from both. :) The interface replaces only the floppy drive of the Microdisc unit.
jede
Flying Officer
Posts: 191
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Post by jede »

Hello,

A sdcard interface is almost finished on amstrad CPC. It works like "HxC Floppy Drive Emulator".

Anyway, on the oric, floppy drive is really a pain. Mainly, because the controller is too hard to find.

Some ideas :

- buy a telestrat :) The floppy controller is built in the telestrat (it's really expensive). I have one telestrat, i will be able to play to Twilighte's next games on disk with joystick support (Private Joke)

- build Thierry's microdisc interface : Annoying because you have to build the PCB (anyway, we can ask to build the pcb to a firm : It cost 50 euros, for this kind of pcb without any chip !)

- Reproduce this controller in a FPGA : It's certainly possible, but i don't know if some one will do it one day.

-Build a new interface (with ualfat chip : See above, the link), it should not be too difficult to do, but i2c is a bit crap with a 1 mhz cpu. It could work with sedoric : It needs to patch all calls to microdisc routines. but, it won't work with all fdc personal routine.

I am interested to this last idea, that is why i asked in this old topic
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Well, I just checked around what it would cost for 50 boards of the size I *think* this would end up. It's close to $20 a board before drill holes, those are extra. I think board makers have lowered prices due to the economy. The catch is that you would have to sell that many or eat the cost of unsold boards so we are talking about a pre-sell. I think ordering a few extra wouldn't be a big deal but you are talking about a $1000+ up front cost not counting an initial run of prototypes or parts.

IF a simple drive emulation can be done (like many people are suggesting) and the board has an MCU I see no need for a proprietary chip like the ualfat. There is source for a FAT file system that will work on an MCU. Besides, one of the ualfat boards with the SD interface is $44.95. The price break at 100 units only lowers the cost a couple dollars and you'd want to order as many of these as you order boards to avoid problems with future design changes to the ualfat board. Don't get me wrong, it's a nice idea if you want to patch an existing DOS and want to squeeze everything into 16K. But I think an MCU that can be purchased under $10 is a little more cost effective with the same end result and it's more flexible. I didn't price just the ualfat chip but I'm sure it's more than an MCU (I think I paid $2-$5 for various PIC MCUs).

As for other costs...

I purchased several hundred 256K x 8 FLASH memories for a price you wouldn't believe last year and if you can buy them as cheap it's almost a non-issue with the price.

The bus connectors would need to be located and priced. I figure under $5 each unless only one manufacturer makes them. I'd be more worried I couldn't find the correct one than it being expensive.

A small FPGA should be under $20 (possibly under $10) even if the design gets a little big.

SD connectors are cheap as well.

So price of parts should be in the $50-$75 range and the final price $100-$150 after assembly.


Now... I did come up with a potential way where floppy emulation might be possible without a large FPGA and without an MCU.
I just don't know if it would work with the Oric so I'll bounce the idea off of you guys. It will probably sound a little odd at first but here is the theory behind it. (and yes, it even sounds a little crazy to me)

Have the FPGA trigger an interrupt when an address for the drive controller is accessed. At the same time it latches the lower bits of the address for decoding along with R/W as a bit, latches the current RAM/ROM setting, and switches to another page in the FLASH memory.

What this does, in theory, is pages in drive emulation code on a separate FLASH page, overrides the NMI vector at FFFA-FFFB (if what is at that address can actually be switched with the ROM/RAM settings), and triggers the 6502 to jump to the drive emulation program in FLASH.
The interrupt handler checks what address+R/W value was latched and calls the appropriate routine in FLASH from a table of pointers.
The 6502 then sets some parameters in internal RAM or register values in the return stack, tells the hardware it's going to return and returns from interrupt. That means that some RAM would need to be paged in with the FLASH so that it's totally transparent to the program that is running.

The biggest problem is returning from the interrupt and restoring the prior ROM/RAM select state. Capturing the state isn't a big deal since it's already handled externally on the Oric and can be done at the same time the interrupt is triggered and FLASH enabled. Returning from interrupt and restoring the state is another matter. You have to write to the hardware to tell it you are returning on the next instruction and the hardware has to delay long enough for the 6502 to execute the RTI before restoring the memory map.
<edit> That should be load the RTI I believe.

Advantages...
Few parts. This also means fewer drill holes and a smaller board which makes it cheaper to produce.
All software is 6502, stored in FLASH for easy upgrades and there are no black boxes that forever hold bugs if the developer disappears.
Should fit in a small FPGA since it's simple state machines, registers, etc...

Disadvantages/Pitfalls...
All software is 6502. It might require page 0 memory so saving and restoring some bytes may be required.
If the interrupt vector can't be overridden it won't work.
Reads and writes would be slower but that is partially offset by faster seeks and possibly finding sectors faster.
If timing is very critical to a program it could malfunction.
Interrupts cannot take place while it is emulating the drive and that could break a program.
If you ever plug a 65816 into the machine and move the stack, the emulation could break since the stack can be paged out of memory. The only way around it is to delay the memory page switch until after the PUSH and I'm not sure if he 65816 even pushes the same number of bytes on an interrupt.
People seem to have their hearts set on using an MCU.
Last edited by JamesD on Mon Jul 06, 2009 6:28 pm, edited 1 time in total.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

BTW, Compact Flash (IDE) would eliminate the need for a separate clock, does not require serial shift registers, and parts to adjust voltage.
It would probably add more drill holes and definitely a larger connector. However it leaves the option of including an IDE connector as well as CF just like the Apple II CFFA like I have.
Torlus
Officer Cadet
Posts: 37
Joined: Sun Feb 05, 2006 11:06 pm
Location: Toulouse, France
Contact:

Post by Torlus »

Very interesting idea, honestly ;)
JamesD wrote: All software is 6502. It might require page 0 memory so saving and restoring some bytes may be required.
That might be a serious issue, software make intensive use of the ZP...
JamesD wrote: If timing is very critical to a program it could malfunction.
Sounds like a non-issue, as DBug stated.
JamesD wrote: Interrupts cannot take place while it is emulating the drive and that could break a program.
Indeed.
JamesD wrote: People seem to have their hearts set on using an MCU.
I don't see why using a MCU seems horrific to you ;)
I won't argue about writing code for MCUs and such compared to the 6502, but if your main concern is firmware updates, then most MCUs have some "bootloading" support and self-flashing capabilities, so you could perform firmware updates using the SD card itself : no need for external programming tools.
Post Reply