MMC-ORIC
No, the thing is you want something that is going to require a LOT of work and a board that will be expensive to produce for a very small market and it will never compensate the person that does the work for their time.
A simple SD or IDE interface can be hacked together for a minimum effort. There are already file systems out there that could be modified to have existing DOS compatible interfaces. The actual SD/IDE interface would fit in a cheap FPGA, could be built by individuals and the FPGA programmed through a JTAG interface. And given the effort required, someone wouldn't mind giving it away.
A simple SD or IDE interface can be hacked together for a minimum effort. There are already file systems out there that could be modified to have existing DOS compatible interfaces. The actual SD/IDE interface would fit in a cheap FPGA, could be built by individuals and the FPGA programmed through a JTAG interface. And given the effort required, someone wouldn't mind giving it away.
But then we are back to the problem of software.
Sure, I don't mind a low cost/easy to produce device, but if none of the existing software works with it, it kind of limite the usefulness.
If at least the device can't handle the ROMDIS signal, this would make it possible to install some hooks, perhaps a patched ROM, with patched CLOAD/CSAVE, allowing to load .TAP files stored on the card.
If Sedoric can be patched to access the SD card, would work as well for a number of programs using the system.
Remains the problem of the demos and games that don't rely on the DOS because they need to access the overlay memory to store their own data.
The bottom line: What kind of customer is target with this device ?![Smile :)](./images/smilies/icon_smile.gif)
Sure, I don't mind a low cost/easy to produce device, but if none of the existing software works with it, it kind of limite the usefulness.
If at least the device can't handle the ROMDIS signal, this would make it possible to install some hooks, perhaps a patched ROM, with patched CLOAD/CSAVE, allowing to load .TAP files stored on the card.
If Sedoric can be patched to access the SD card, would work as well for a number of programs using the system.
Remains the problem of the demos and games that don't rely on the DOS because they need to access the overlay memory to store their own data.
The bottom line: What kind of customer is target with this device ?
![Smile :)](./images/smilies/icon_smile.gif)
I have bought a SD-card reader for Atari ST that directly plugs to the hard-drive port, they cost 65 euros each, plus a cable about 5 or 10 euros. To me, that was cheap, and I think they sold at least 150 of them (using pre-orders).
Any new hardware, replacing a Microdisc (and others ?), compatible with the existing systems, with a nice design (I mean: in a box), small, directly plugged to the Oric, is worth up to 100 euros to me.
What do you guys call "expensive" ?
Any new hardware, replacing a Microdisc (and others ?), compatible with the existing systems, with a nice design (I mean: in a box), small, directly plugged to the Oric, is worth up to 100 euros to me.
What do you guys call "expensive" ?
They sold 150 of them and it plugs into the "hard-drive port".Symoon wrote:I have bought a SD-card reader for Atari ST that directly plugs to the hard-drive port, they cost 65 euros each, plus a cable about 5 or 10 euros. To me, that was cheap, and I think they sold at least 150 of them (using pre-orders).
Any new hardware, replacing a Microdisc (and others ?), compatible with the existing systems, with a nice design (I mean: in a box), small, directly plugged to the Oric, is worth up to 100 euros to me.
What do you guys call "expensive" ?
And that's for a computer that sold a few million machines.
On top of which I don't think it required any code.
The CFFA interface for my Apple II was $99 US and it's just an IDE port with a CF connector. An IDE port like it can be built with a hand full of TTL chips which probably cost under $10. And remember, the Apple already has a DOS that will work with a hard drive so this FLASH only has interface code between DOS and hardware. It has sold out 6 production runs but there are less that 600 working units total. Keep in mind the Apple II series sold around 9 million units total, Apple users are known to spend more (not exactly budget machines), and many people ordered more than 1.
Now add drive emulation, an expanded DOS (if you ever want to have access to something larger than a floppy), and make it for the Oric which sold what? Less than 400,000 machines?
Out of that number of Orics, how many were defective, died, were just thrown out, or will never be turned on again?
The Oric probably had fewer games in it's entire life than the ST did by it's second year. Most probably could be loaded from a tape image on any interface. How many games/demos actually used the disk drive? I would think they are pretty rare since the drives are so rare.
So, you want a drive emulator for a handful of demos and games, made by someone who is willing to spend their time doing all that development for little or no return on their investment with a total number of sales probably less than 50. Does that about sum it up?
If you really want a virtual floppy drive a clone of an existing interface and this might be your best option.
http://www.thesvd.com/SVD/
- ibisum
- Wing Commander
- Posts: 1646
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
I guess I'm not fully understanding just why its so difficult to build a simple floppy emulator that takes the Oric interface on one side and presents a virtualized disc from a normal SD-filesystem on the other side?
I mean, couldn't we use the Hackaday Bus Pirate project as a starter, for getting an emulator going? That thing costs $30, and probably wouldn't take too much hacking to get at least somewhere, disc-wise.
Whats needed is a good inspection of Sedoric and other DOS for the Oric, to understand what its requirements are on the interfacing side, and then just glom something together out of cheap parts to do a very rudimentary emulation, which would *not* require any software hacking ..
I mean, couldn't we use the Hackaday Bus Pirate project as a starter, for getting an emulator going? That thing costs $30, and probably wouldn't take too much hacking to get at least somewhere, disc-wise.
Whats needed is a good inspection of Sedoric and other DOS for the Oric, to understand what its requirements are on the interfacing side, and then just glom something together out of cheap parts to do a very rudimentary emulation, which would *not* require any software hacking ..
Same here. I declare my lack of knowledge in this field, so...
But, however, I guess that the real problem is not emulating the floppy drive but rather the Microdisc contoller. There are schematics out there (I think) so I don't know where the difficulties are in doing something with the use of FPGAs or someting similar.
After all, you could allways plug an old 3.5'' floppy to that drive, or expand the thing alter on to use an SD or even connect to the PC to provide a Virtual Disk, such as the one shown the above link.
Anyway I completely understand that anything like this cannot be done for money. Just covering the costs will be difficult. It should be more something like the project of an oric-fan, similar to doing software.
BTW, a bit off-topic, but isn't it possible to have something simple like a small cable, maybe with some chips, connected to the expansion port to enable de ROMDIS signal and give access to the overlay ram without the need of a disk drive? That would be invaluable.
Now that I think of it, however, less and less people will be using the real thing with time. So projects as Oric in a FPGA or a new emulator are more needed by the community, but that is just my thought.
Sorry for getting off-topic.
But, however, I guess that the real problem is not emulating the floppy drive but rather the Microdisc contoller. There are schematics out there (I think) so I don't know where the difficulties are in doing something with the use of FPGAs or someting similar.
After all, you could allways plug an old 3.5'' floppy to that drive, or expand the thing alter on to use an SD or even connect to the PC to provide a Virtual Disk, such as the one shown the above link.
Anyway I completely understand that anything like this cannot be done for money. Just covering the costs will be difficult. It should be more something like the project of an oric-fan, similar to doing software.
BTW, a bit off-topic, but isn't it possible to have something simple like a small cable, maybe with some chips, connected to the expansion port to enable de ROMDIS signal and give access to the overlay ram without the need of a disk drive? That would be invaluable.
Now that I think of it, however, less and less people will be using the real thing with time. So projects as Oric in a FPGA or a new emulator are more needed by the community, but that is just my thought.
Sorry for getting off-topic.
oric on a chip
hi there,
Torlus has an oric-on-a-chip design in the pipes (well one of the numerous pipes since he's working on a lot of projects). He told me he had "just" to add VIA and I don't remember what else (but ula is done).
Torlus has an oric-on-a-chip design in the pipes (well one of the numerous pipes since he's working on a lot of projects). He told me he had "just" to add VIA and I don't remember what else (but ula is done).
The SD interface is easy.
Hooking an SD interface to an MCU... easy.
A file system on the MCU to drive the SD... not too bad.
It's the controller emulation and drive interaction that is the problem.
I may be blowing it out of proportion due to the copy protection I've seen on other platforms (Apple, CoCo). If the Oric games that came on disk (did any?) don't have nasty copy protection then it might not be a problem.
But if any did and you want to run them you probably need pretty exact timing for stepping tracks, emulating controller status and transferring data.
One of the nastier tricks some copy protections used was to start reading data and with very exact timing, step to another track at some point in the middle of a track. The data skews across between tracks and without exact timing the load fails. But then I've spent a lot of time on other platforms and know next to nothing of the Oric disk controllers.
I know someone that is trying to do a disk emulator for the CoCo and I described to him a simple circuit that would do the trick but copy protection like I mentioned would probably break on it.
The controller emulation requires very fast response from the MCU so that it can latch which address is being written or read. On a write it has to also grab the data before the end of the clock cycle. On a read it has to calculate the status bits and/or grab the data from the SD file and put it on the buss in time for it to be valid within that clock cycle.
Buffering the interface will help the MCU run a little more asynchronously.
Theory of operation is something like this...
When the CPU accesses the address range of the controller chip the bottom bits of the address are latched by the hardware and the MCU is signaled an access is taking place. That is triggered by the leading edge of the clock cycle but takes place after settle time within the clock cycle so we know the address is valid.
The MCU gets an interrupt, checks the address bits to see what register to emulate on the controller.
If it's a status register... it checks the current emulation state and sends the data back to the main buss in time for the data to be valid. The buffered interface holds the data active through the entire clock cycle.
If it's a seek, the MCU buffers the next track in it's internal cache, updates internal status registers and start an internal timer to mimic track to track timing. The last part is only needed if you have nasty copy protection. Reads and writes are impacted by that timing.
Any track stepping can take place instantaneously with non copy protected software but must be timed exactly with read/write for copy protected software. Depending on the disk/controller used you may even have to support data on half tracks.
Emulators kinda fudge things on their drive emulation and this can too but how much depends on the software.
If the Oric software waits for the spinning disk to hit the start of a track then it does something that is an exact number of clock cycles and then starts reading from the drive part way through a rotation of the disk you have to know exactly where in the track to start sending data.
Same for writing. It's even more critical there since you could corrupt the data.
Basically, any read/write stuff has to be carried out by the MCU within less than 1 clock cycle of the 6502. Not just within but in time for data to be valid on the 6502 buss. So maybe 1/2 clock cycle to allow for settle time on the buss? I don't know the tolerance of the design.
AND you have to emulate a spinning disk.
Now, if all the software played nice and went through the DOS we wouldn't need to emulate the controller at all. That's why many of the interfaces are cheap and small.
If you just have simple ports to read/write from/to the SD it's a very simple interface and the serial nature of the interface is hidden from the cpu. It's just reading and writing bytes from the main cpu. It will fit on a small FPGA about the size of a fingernail... smaller if you don't mind the price.
Hooking an SD interface to an MCU... easy.
A file system on the MCU to drive the SD... not too bad.
It's the controller emulation and drive interaction that is the problem.
I may be blowing it out of proportion due to the copy protection I've seen on other platforms (Apple, CoCo). If the Oric games that came on disk (did any?) don't have nasty copy protection then it might not be a problem.
But if any did and you want to run them you probably need pretty exact timing for stepping tracks, emulating controller status and transferring data.
One of the nastier tricks some copy protections used was to start reading data and with very exact timing, step to another track at some point in the middle of a track. The data skews across between tracks and without exact timing the load fails. But then I've spent a lot of time on other platforms and know next to nothing of the Oric disk controllers.
I know someone that is trying to do a disk emulator for the CoCo and I described to him a simple circuit that would do the trick but copy protection like I mentioned would probably break on it.
The controller emulation requires very fast response from the MCU so that it can latch which address is being written or read. On a write it has to also grab the data before the end of the clock cycle. On a read it has to calculate the status bits and/or grab the data from the SD file and put it on the buss in time for it to be valid within that clock cycle.
Buffering the interface will help the MCU run a little more asynchronously.
Theory of operation is something like this...
When the CPU accesses the address range of the controller chip the bottom bits of the address are latched by the hardware and the MCU is signaled an access is taking place. That is triggered by the leading edge of the clock cycle but takes place after settle time within the clock cycle so we know the address is valid.
The MCU gets an interrupt, checks the address bits to see what register to emulate on the controller.
If it's a status register... it checks the current emulation state and sends the data back to the main buss in time for the data to be valid. The buffered interface holds the data active through the entire clock cycle.
If it's a seek, the MCU buffers the next track in it's internal cache, updates internal status registers and start an internal timer to mimic track to track timing. The last part is only needed if you have nasty copy protection. Reads and writes are impacted by that timing.
Any track stepping can take place instantaneously with non copy protected software but must be timed exactly with read/write for copy protected software. Depending on the disk/controller used you may even have to support data on half tracks.
Emulators kinda fudge things on their drive emulation and this can too but how much depends on the software.
If the Oric software waits for the spinning disk to hit the start of a track then it does something that is an exact number of clock cycles and then starts reading from the drive part way through a rotation of the disk you have to know exactly where in the track to start sending data.
Same for writing. It's even more critical there since you could corrupt the data.
Basically, any read/write stuff has to be carried out by the MCU within less than 1 clock cycle of the 6502. Not just within but in time for data to be valid on the 6502 buss. So maybe 1/2 clock cycle to allow for settle time on the buss? I don't know the tolerance of the design.
AND you have to emulate a spinning disk.
Now, if all the software played nice and went through the DOS we wouldn't need to emulate the controller at all. That's why many of the interfaces are cheap and small.
If you just have simple ports to read/write from/to the SD it's a very simple interface and the serial nature of the interface is hidden from the cpu. It's just reading and writing bytes from the main cpu. It will fit on a small FPGA about the size of a fingernail... smaller if you don't mind the price.
There are not many games on the Oric that used copy protection, in fact only one springs to mind (Willy) and only because it used its own disc handling routine, not exactly copy protected.
I don't think we need to worry about copy protecting/protected software.
The sterling work done by Symoon and others to convert games to .tap files have proved most games are now available.
I guess my only reservation for any MMC/SD card interface would be to ensure that we can still (through software) switch the ROM in and out. This gives us full access to all 64K. Whilst SD access times may be close to memory speed, having the full 64K available is still a must have for direct cpu access.
As for fundamental routines, i actually do not have a problem with simple LOAD, SAVE and DIR commands.
To the machine code programmer the less sd system memory that can be used the more space for games and demos.
To the basic programmer i doubt people want more than these basic commands.
It would be cool if the system even didn't have DIR but included it in the LOAD command like C64, so LOAD"$DIR" loaded the directory into memory as basic lines or optionally LOAD "$DIR",A#A000 etc.
I don't think we need to worry about copy protecting/protected software.
The sterling work done by Symoon and others to convert games to .tap files have proved most games are now available.
I guess my only reservation for any MMC/SD card interface would be to ensure that we can still (through software) switch the ROM in and out. This gives us full access to all 64K. Whilst SD access times may be close to memory speed, having the full 64K available is still a must have for direct cpu access.
![Razz :P](./images/smilies/icon_razz.gif)
As for fundamental routines, i actually do not have a problem with simple LOAD, SAVE and DIR commands.
![Cool 8)](./images/smilies/icon_cool.gif)
To the machine code programmer the less sd system memory that can be used the more space for games and demos.
To the basic programmer i doubt people want more than these basic commands.
![Question :?:](./images/smilies/icon_question.gif)
It would be cool if the system even didn't have DIR but included it in the LOAD command like C64, so LOAD"$DIR" loaded the directory into memory as basic lines or optionally LOAD "$DIR",A#A000 etc.
Without having to worry about copy protection the only thing for disk emulation I'd worry about is rotation. That can be done with a free running counter in the MCU. When the drive motor is turned on the free running counter is started. Then when a read comes in the status or data is updated based on the counter. It's still very timing critical on the interface to the Oric.
If Willy is the only thing that is a problem them I'd say patch Willy instead of spending so much time on the interface.
Switching the ROM in and out isn't difficult. I vaguely remember the Oric expansion connector having a couple connections to determine whether the ROM, RAM or neither are active. An external ROM with the DOS only needs enough RAM for a buffer and some control data. Probably 256 bytes. It should sit in main RAM unless some code is resident in main RAM.
Calls to the ROM routines would just need a pointer to that buffer/control area to be at a location on Page 0 or on the stack. I'd say page 0.
You would need some low level functions for file access. Open, Close, Seek, Read, Write, etc...
Managing an SD's large storage capacity would need some sort of Mkdir, Delete, Copy, etc...
If Willy is the only thing that is a problem them I'd say patch Willy instead of spending so much time on the interface.
Switching the ROM in and out isn't difficult. I vaguely remember the Oric expansion connector having a couple connections to determine whether the ROM, RAM or neither are active. An external ROM with the DOS only needs enough RAM for a buffer and some control data. Probably 256 bytes. It should sit in main RAM unless some code is resident in main RAM.
Calls to the ROM routines would just need a pointer to that buffer/control area to be at a location on Page 0 or on the stack. I'd say page 0.
You would need some low level functions for file access. Open, Close, Seek, Read, Write, etc...
Managing an SD's large storage capacity would need some sort of Mkdir, Delete, Copy, etc...
The main problem, to me, is still that some games (modern mostly) use their own code to load/save data from/to disk appart from using overlay ram: Space:1999 and pinforic do this, and the Elite-clone will, for sure. And some do not use page-4 routines to do it, but use I/O through page 3 to access the controller (microdisc). So no way to simply patch the DOS, I assume.
I don't know why disc rotation and other matters should be taken into consideration. We simply need to have access to the controller registers through page 3, so we can indicate it to seek a given sector, read/write it, etc. and get the FDC status and interrupts.
I am not sure (at all!) how usual Oric DOSes work, but I guess they don't do "nasty" things, so something like this (well, more complex, of course), should do.
If something like this could be done and if it is even worth the effort, but if it is, a way to select a .dsk file inside an SD and let the Oric boot it (for instance) would be invaluable.
I don't know why disc rotation and other matters should be taken into consideration. We simply need to have access to the controller registers through page 3, so we can indicate it to seek a given sector, read/write it, etc. and get the FDC status and interrupts.
I am not sure (at all!) how usual Oric DOSes work, but I guess they don't do "nasty" things, so something like this (well, more complex, of course), should do.
If something like this could be done and if it is even worth the effort, but if it is, a way to select a .dsk file inside an SD and let the Oric boot it (for instance) would be invaluable.