http://retromaster.wordpress.com/.
I had the same idea while discussing with Fabrice last month... Well this project is more advanced than what I've done myself on this topic
Microdisc replacement project
-
Torlus
- Officer Cadet
- Posts: 37
- Joined: Sun Feb 05, 2006 11:06 pm
- Location: Toulouse, France
- Contact:
Microdisc replacement project
Is anyone aware of this project ?
http://retromaster.wordpress.com/.
I had the same idea while discussing with Fabrice last month... Well this project is more advanced than what I've done myself on this topic
http://retromaster.wordpress.com/.
I had the same idea while discussing with Fabrice last month... Well this project is more advanced than what I've done myself on this topic
I posted a message the other day on his blog.
retromaster said on New Project Started: Cumulus
November 13, 2010 at 6:01 pm
Hi Dbug. Although I am not really familiar with the Oric scene, I think I’ve seen your name in quite a few places. It’s nice to hear from you.In response to Dbug on November 13, 2010 at 4:34 pm:
Hi, great work so far as I can seeI’m the webmaster of Defence-Force.org, and on our forums we have/had intense discussions about how best to find a replacement to the hard to find Microdisc systems, and of course the possibility of having a SD based system has been discussed quite a lot. Quite [...]
To be honest, I did not really know about the flaky bus timings issue of the Orics. The bus timing behavior exhibited by the Atmos I own is quite consistent. Nevertheless, I do understand that this behaviour may differ drastically from one Oric to another…
In any case, I do not see this as a good enough reason to abandon an interface project such as Cumulus. However, I now realize that it’s important to make the signal timings (actually just the MAP signal, it seems) as adjustable as possible. Furthermore, it would be ideal if I could come up with a practical method that would enable people to make the adjustments themselves.
And I should add that this is not a commercial project from my point of view. It is very likely that I will open all sources related to the project once it gets to a working stage.
-
Torlus
- Officer Cadet
- Posts: 37
- Joined: Sun Feb 05, 2006 11:06 pm
- Location: Toulouse, France
- Contact:
Hi there,
I'm just back from the "RGC 2010" retrogaming event, from where I created this topic, but a few minutes after doing it, I had no luck with with 3G connection, and couldn't get online again.
During this event, I've talked with my friend Jeff (author of the HxC Floppy Drive Emulator) about my Microdisc recreation project initiated some weeks ago after a talk with Fabrice Frances, and he pointed me to this link... I was quite surprised to discover that another person would start a similar project, at the same time!
Anayway, here is what I've done so far :
- I've "ported" my Oric-in-a-FPGA project to the Altera DE1 board.
- I've converted the Microdisc schematics and parts (without the WD1793) into VHDL.
- I've replaced the WD1793 by a custom design splitted in two parts : a CPU interface which is synchronized with the remaining parts of the system, performs some WD1793 register caching, etc. and a second part that is a large "finite state machine" that emulates (think : software emulation) the WD1793, serving disk images from the Flash memory of the DE1 board. Both parts communicate with a 8-wire "letterbox" design.
- I've managed to get all this stuff working in hardware (on the DE1 board), especially by replacing the asynchronous parts of the original Microdisc design.
Now, what needs to be done :
- Make the first part of the design fit in a CPLD (shouldn't be too hard).
- Replace the large finite state machine by software emulation running in a PIC microcontroller for instance, reading the disk images from a SD-Card.
I'm glad to see that this guy and I have more or less taken the same route, it probably means that we're both right (or both wrong). Now there's an issue with the MAP signal and there are mostly two ways of addressing it :
- Using oversampling (I planned to use a 40Mhz master clock, to drive both the CPLD and the PIC) and see if it's enough to meet timing requirements.
- Reproduce what's inisde the Microdisc : basically adjust the MAP clock generation by varying the Resistor value of a RC-circuit delay.
I'll probably contact this guy too, to see if I can be of any help.
I'm just back from the "RGC 2010" retrogaming event, from where I created this topic, but a few minutes after doing it, I had no luck with with 3G connection, and couldn't get online again.
During this event, I've talked with my friend Jeff (author of the HxC Floppy Drive Emulator) about my Microdisc recreation project initiated some weeks ago after a talk with Fabrice Frances, and he pointed me to this link... I was quite surprised to discover that another person would start a similar project, at the same time!
Anayway, here is what I've done so far :
- I've "ported" my Oric-in-a-FPGA project to the Altera DE1 board.
- I've converted the Microdisc schematics and parts (without the WD1793) into VHDL.
- I've replaced the WD1793 by a custom design splitted in two parts : a CPU interface which is synchronized with the remaining parts of the system, performs some WD1793 register caching, etc. and a second part that is a large "finite state machine" that emulates (think : software emulation) the WD1793, serving disk images from the Flash memory of the DE1 board. Both parts communicate with a 8-wire "letterbox" design.
- I've managed to get all this stuff working in hardware (on the DE1 board), especially by replacing the asynchronous parts of the original Microdisc design.
Now, what needs to be done :
- Make the first part of the design fit in a CPLD (shouldn't be too hard).
- Replace the large finite state machine by software emulation running in a PIC microcontroller for instance, reading the disk images from a SD-Card.
I'm glad to see that this guy and I have more or less taken the same route, it probably means that we're both right (or both wrong
). Now there's an issue with the MAP signal and there are mostly two ways of addressing it :- Using oversampling (I planned to use a 40Mhz master clock, to drive both the CPLD and the PIC) and see if it's enough to meet timing requirements.
- Reproduce what's inisde the Microdisc : basically adjust the MAP clock generation by varying the Resistor value of a RC-circuit delay.
I'll probably contact this guy too, to see if I can be of any help.
Retromaster has just booted Oric game with Cumulus...
http://retromaster.wordpress.com/2010/1 ... irst-game/
http://retromaster.wordpress.com/2010/1 ... irst-game/
Retromaster solved another problem and Sedoric 3 discs now works...
http://retromaster.wordpress.com/2010/1 ... sedoric-3/
http://retromaster.wordpress.com/2010/1 ... sedoric-3/
-
retromaster
- Private
- Posts: 7
- Joined: Fri Nov 26, 2010 6:52 am
Hi everyone!
As you may already have seen on my blog, I've had some very good first results with my SD Card Microdisc replacement project (Cumulus).
And just like Torlus, I was quite surprised to find out that we both had the same idea to work on something like this right at the same time.
Anyway, Torlus, the main reason I am posting here is to say that you've already been of some help. You may have seen from my earlier blog posts that I originally used a 74HCT221 to generate the MAP signal (basically, reproducing what's inside the Microdisc) and I've had some problems with it. Instead, last night I tried using oversampling like you suggested here (using an 32Mhz crystal). I am glad to say that I got it to work.
This approach basically trades PCB area/components for CPLD area. In any case, one gets rid of the pesky 221 and the trimmer so it's very good. I'll probably post more technical details in a blog post later.
And finally, at this point, let me say that, Cumulus seems to work quite well and it is very stable, although there's still quite a bit of testing and firmware/PCB work to do.
-RM
As you may already have seen on my blog, I've had some very good first results with my SD Card Microdisc replacement project (Cumulus)
. And just like Torlus, I was quite surprised to find out that we both had the same idea to work on something like this right at the same time.
Anyway, Torlus, the main reason I am posting here is to say that you've already been of some help. You may have seen from my earlier blog posts that I originally used a 74HCT221 to generate the MAP signal (basically, reproducing what's inside the Microdisc) and I've had some problems with it. Instead, last night I tried using oversampling like you suggested here (using an 32Mhz crystal). I am glad to say that I got it to work
.This approach basically trades PCB area/components for CPLD area. In any case, one gets rid of the pesky 221 and the trimmer so it's very good
. I'll probably post more technical details in a blog post later.And finally, at this point, let me say that, Cumulus seems to work quite well and it is very stable, although there's still quite a bit of testing and firmware/PCB work to do.
-RM
Hi Retromaster, and welcome
On the last photos your prototype seems to be very compact in term of number of components - at least compared to a real microdisc controller board -, that looks like good news if we want to get people to be able to build their own later
One thing I was wondering, was of course the cost of the device. There's the board to print and drill of course, then there's the cpld, the sd card reader module of course, and in your version there is the screen to select the floppy you want to use.
Could you give some ballpark estimate on the costs of the various parts? Is the screen expensive relative to the rest of parts?
On the last photos your prototype seems to be very compact in term of number of components - at least compared to a real microdisc controller board -, that looks like good news if we want to get people to be able to build their own later
One thing I was wondering, was of course the cost of the device. There's the board to print and drill of course, then there's the cpld, the sd card reader module of course, and in your version there is the screen to select the floppy you want to use.
Could you give some ballpark estimate on the costs of the various parts? Is the screen expensive relative to the rest of parts?
-
retromaster
- Private
- Posts: 7
- Joined: Fri Nov 26, 2010 6:52 am
OK. Here is a quick cost analysis:
PIC18F46K20: 3.2$ each @Digikey.
XC95144XL: $5.8 each @Digikey.
28C256 EEPROM costs about $8 each (Digikey), but ebay prices seem to go even as low as $3-4. Not sure, but I think 28C64 could also be an alternative here.
LCD (Nokia 6610) costs around $6-7 on ebay.
PCB could be manufactured for around $10-15 each (batch of 10-15) from a manufacturer like GoldPhoenix.
Additional components to consider are: SD Card Socket, Crystal Oscillator, Connectors, Buttons, etc. $10 would be a safe estimate here I think.
So, if I haven't forgotten anything (or made a mistake), $50 cost per board (including all components and PCB) seems to be a very safe estimate. This of course does not include manufacturing and component shipping costs.
Perhaps needless to say, ordering parts in batches of at least 10 would make prices slightly cheaper and make shipping more cost effective.
-RM
PIC18F46K20: 3.2$ each @Digikey.
XC95144XL: $5.8 each @Digikey.
28C256 EEPROM costs about $8 each (Digikey), but ebay prices seem to go even as low as $3-4. Not sure, but I think 28C64 could also be an alternative here.
LCD (Nokia 6610) costs around $6-7 on ebay.
PCB could be manufactured for around $10-15 each (batch of 10-15) from a manufacturer like GoldPhoenix.
Additional components to consider are: SD Card Socket, Crystal Oscillator, Connectors, Buttons, etc. $10 would be a safe estimate here I think.
So, if I haven't forgotten anything (or made a mistake), $50 cost per board (including all components and PCB) seems to be a very safe estimate. This of course does not include manufacturing and component shipping costs.
Perhaps needless to say, ordering parts in batches of at least 10 would make prices slightly cheaper and make shipping more cost effective.
-RM
Not bad, not bad at all !
The screen is a lot cheaper than I expected, so I guess the idea I had some time ago (have the card 'write' in the $BB80-$BFDF area memory to use the Oric video display memory as a cheap way to get stuff shown on screen) is probably not worth considering
I'm pretty sure we could find a way to have the CEO (Club Europe Oric) involved in an operation to create small batches of the device. I'm clearly wanting to have one
I'm kind of happy to see that you managed to get that far, just only a few weeks after I started this "incentive program":
http://oricsd.defence-force.org/index.htm
Basically I was trying to see how to make the "ultimate oric" expansion, assuming that the SD/controller part would be costly, to make it a "must have" by embedding in the design all these small other things that makes the live better for an oric user (like joystick port, hardware vsync, mini-jack to get the audio out, the better scart cable with self powered commutation, etc...)
The screen is a lot cheaper than I expected, so I guess the idea I had some time ago (have the card 'write' in the $BB80-$BFDF area memory to use the Oric video display memory as a cheap way to get stuff shown on screen) is probably not worth considering
I'm pretty sure we could find a way to have the CEO (Club Europe Oric) involved in an operation to create small batches of the device. I'm clearly wanting to have one
I'm kind of happy to see that you managed to get that far, just only a few weeks after I started this "incentive program":
http://oricsd.defence-force.org/index.htm
Basically I was trying to see how to make the "ultimate oric" expansion, assuming that the SD/controller part would be costly, to make it a "must have" by embedding in the design all these small other things that makes the live better for an oric user (like joystick port, hardware vsync, mini-jack to get the audio out, the better scart cable with self powered commutation, etc...)
-
retromaster
- Private
- Posts: 7
- Joined: Fri Nov 26, 2010 6:52 am
Actually, that idea you had (card writing directly into video memory) is quite good. There are complications of course, and it would be of definite interest if one could actually use it together with the keyboard.
Another possibility is to provide an additional specialized interface (let's say a new peripheral at a couple of free addresses at page 03) that lets software (a menu application) on the 6502 side directly communicate with the FD emulator to get SD card directory and select images, etc.
Having an LCD on board is cool of course... You can see what drive/track/sector is being accessed in real-time, which is nice. And ultimately more flexible than a menu application. And having the LCD was quite helpful during debugging, too. Given the low cost, I intend to keep it in place
Another possibility is to provide an additional specialized interface (let's say a new peripheral at a couple of free addresses at page 03) that lets software (a menu application) on the 6502 side directly communicate with the FD emulator to get SD card directory and select images, etc.
Having an LCD on board is cool of course... You can see what drive/track/sector is being accessed in real-time, which is nice. And ultimately more flexible than a menu application. And having the LCD was quite helpful during debugging, too. Given the low cost, I intend to keep it in place