>"IO 16 pins for IDE communication."
23 pins. You have to add CS0, CS1, DA0, DA1, DA2, DIOR, DIOW.
>"IO for keyboard and display."
7 pins minimum for the display (standard LCD in 4 bit mode).
1 pin minimum for the keyboard if you use an a/d converter input as shown in one of the circuits posted earlier on this thread. Although I won't recommend this solution as it might do strange things if you press two ore more buttons simultanously.
Doing it the classical way you will need 4 I/O lines for five buttons (in fact you can handle 8 switches that way).
>"IO for in circuit programming."
Depends on the controller. Between 2 and three pins.
Would like to add one for the RC5 decoder.
So we need from 34 to 38 I/O lines.
>"You probably will lose most of the thread followers since programming in Assembly is hard"
The software development is for the hardcore guys anyway. No matter if it is done in C or in assembler. Portability is an aspect, agreed.
>"Even QUAKE is not coded in assembly."
And it doesn't run on a microcontroller. If you have 2 - 16 kilobytes of memory you are forced to use efficient coding.
23 pins. You have to add CS0, CS1, DA0, DA1, DA2, DIOR, DIOW.
>"IO for keyboard and display."
7 pins minimum for the display (standard LCD in 4 bit mode).
1 pin minimum for the keyboard if you use an a/d converter input as shown in one of the circuits posted earlier on this thread. Although I won't recommend this solution as it might do strange things if you press two ore more buttons simultanously.
Doing it the classical way you will need 4 I/O lines for five buttons (in fact you can handle 8 switches that way).
>"IO for in circuit programming."
Depends on the controller. Between 2 and three pins.
Would like to add one for the RC5 decoder.
So we need from 34 to 38 I/O lines.
>"You probably will lose most of the thread followers since programming in Assembly is hard"
The software development is for the hardcore guys anyway. No matter if it is done in C or in assembler. Portability is an aspect, agreed.
>"Even QUAKE is not coded in assembly."
And it doesn't run on a microcontroller. If you have 2 - 16 kilobytes of memory you are forced to use efficient coding.
Elektor has published a nice IDE interface (article + schematic) around march 2001. This interface is using a little 16V8 GAL and 3 74HCT ICs. This could be handy for someone who don't want to mess with "hardcore" programming.
I don't agree at all with that
A lot of people here are using microcontrollers in their projects and they're not necessarly hardcore programmers. Personally, I'll be the first to customize the software once the project completed. Guys on this forum are here to learn anyway. Programming isn't hard at all. Good programming techniques are an art.
I TOTALLY agree with that. I spent 3 years with 5 other guys working on a 64k firmware and 4k of RAM... Spent the last 6 months splittting hair in four.... And by the way, we were using C ! (except the physical layer which had to be precisely synchronized)
Of course ! No one's crazy enough to code an application this big in assembly.
my 2 cents
Well the DS89C420 sure is available on sample. I've received a few over the last year or two, and if the page I referred you to says you can "Request samples" then you can do so.
With regard to Holger's list of required features versus pins required, I believe the DS89C420 has enough processing power (and I/O pins) to handle this job just fine.
Also I believe it would be ideal, because it's based on 8051 architecture, and therefore DIYers who can't get hold of a DS89C420 will still be able to build the project with another controller, but still the same board and software.
Also, I don't like the thought that only the "hardcore" programmers will handle the code. I would like to leave the door open for people who want to do "minor" mods to the software, and therefore I also believe Assembler is not such a good idea.
Thanks for the link Holger. Come to think of it, I think I have the full version of Eagle lying around on a CD. Yes, I do have a lot of stuff "lying around".
I'll be back.
With regard to Holger's list of required features versus pins required, I believe the DS89C420 has enough processing power (and I/O pins) to handle this job just fine.
Also I believe it would be ideal, because it's based on 8051 architecture, and therefore DIYers who can't get hold of a DS89C420 will still be able to build the project with another controller, but still the same board and software.
Also, I don't like the thought that only the "hardcore" programmers will handle the code. I would like to leave the door open for people who want to do "minor" mods to the software, and therefore I also believe Assembler is not such a good idea.
Thanks for the link Holger. Come to think of it, I think I have the full version of Eagle lying around on a CD. Yes, I do have a lot of stuff "lying around".
I'll be back.
Of course you can. Not only ont the 8051 series controllers, but on ervery type. If you'd take a look at my approach you would see I have already done that for the buttons.
But in our case it is not too simple to get the whole thing done with 32 I/Os. As we have a lot of bidirectional lines and special function pins, the multiplexing will be rather complex.
I would like to avoid this.
But in our case it is not too simple to get the whole thing done with 32 I/Os. As we have a lot of bidirectional lines and special function pins, the multiplexing will be rather complex.
I would like to avoid this.
You don't need to count the I/O's needed for In System Programming, because you can use the same I/O's for other functions. Accept if you add a USB interface or something.
You can use the same pins for ISP as for the IDE interface, because you don't need the IDE when flashing the uC.
The DS89C420 is too expensive I think.
The ATMega161 is also suitable with his 35 I/O's, 16kB Flash, 512 Byte EEPROM, 1kB RAM and a lot of futures. This uC costs only €10.15
The ATMega128 is maybe a little overkill with 53 I/O's, 4K RAM, 4K EEPROM, 128kByte Flash!. €16.45
These prices are German consumer prices. Ordering samples is also possible.
You can use the same pins for ISP as for the IDE interface, because you don't need the IDE when flashing the uC.
The DS89C420 is too expensive I think.
The ATMega161 is also suitable with his 35 I/O's, 16kB Flash, 512 Byte EEPROM, 1kB RAM and a lot of futures. This uC costs only €10.15
The ATMega128 is maybe a little overkill with 53 I/O's, 4K RAM, 4K EEPROM, 128kByte Flash!. €16.45
These prices are German consumer prices. Ordering samples is also possible.
I hate it, but I have to complain again
Multiplexing the ISP port gives us 3 pins - still very tight.
Mega 161 is a good choice, but it is discontinued.
Mega 128 would be perfect, but it has a 64 pin TQFP package with 0.8 mm grid. No sockets, hard to solder and nearly impossible to handle on a single layer pcb.
Sample ordering with Atmel in Europe doesn't work - I have tried that several times. I once called their german headquater on the phone and they told me that they never recieve a sample order done via the Atmel website. Someone seems to trash all of them...
Multiplexing the ISP port gives us 3 pins - still very tight.
Mega 161 is a good choice, but it is discontinued.
Mega 128 would be perfect, but it has a 64 pin TQFP package with 0.8 mm grid. No sockets, hard to solder and nearly impossible to handle on a single layer pcb.
Sample ordering with Atmel in Europe doesn't work - I have tried that several times. I once called their german headquater on the phone and they told me that they never recieve a sample order done via the Atmel website. Someone seems to trash all of them...
Yes, you are right.
You can do it. I can do it. And perhaps three other people on this board interested in this project also can. But for everybody else this is a little too hard I think.
BTW: 0,8 mm pitch can of course be soldered by hand, if you are skilled enough and hav the right tool.
But if we want to keep the whole thing as simple as possible this is the wrong way I think.
You can do it. I can do it. And perhaps three other people on this board interested in this project also can. But for everybody else this is a little too hard I think.
BTW: 0,8 mm pitch can of course be soldered by hand, if you are skilled enough and hav the right tool.
But if we want to keep the whole thing as simple as possible this is the wrong way I think.
I still believe this project can be done with the DS89C420 fairly easily. If you really need all the extra pins you can use one of Dallas/Maxim's port expanders.
See:
http://www.maxim-ic.com/MaximProducts/DisplayDrivers/port-expanders.htm
The beauty is you can get these on sample as well.
Douchekop, the DS89C420 may be expensive to buy, but since we can get it on sample, I don't see a problem.
I'm not totally stuck on the idea of using the DS89C420 yet, since I haven't had enough time to check out all the specs versus what we want yet, but I will do this later today. So anyway, I'm still open to using the mega16, although I don't know how on earth I'll get one here without paying an arm and a leg. Atmel RARELY sends samples to us here.
DJ
See:
http://www.maxim-ic.com/MaximProducts/DisplayDrivers/port-expanders.htm
The beauty is you can get these on sample as well.
Douchekop, the DS89C420 may be expensive to buy, but since we can get it on sample, I don't see a problem.
I'm not totally stuck on the idea of using the DS89C420 yet, since I haven't had enough time to check out all the specs versus what we want yet, but I will do this later today. So anyway, I'm still open to using the mega16, although I don't know how on earth I'll get one here without paying an arm and a leg. Atmel RARELY sends samples to us here.
DJ
Hi
Interesting thread.
If the source files are written in something like C, then a number of different uP's can be used. For simplicity sake (and because I have all the dev tools) I would tend towards one of the Microchip 18F devices such as the PIC18F442 or their DSPIC range of DSP processors. If the source files are written in a nice modular format then it would be pretty easy to recompile them for each of the various processors.
Another issue that is quite important to this discussion is the sourcing of a reasonable CDROM drive. For Audio I tend to prefer the older (SLOWER) drives.
This last weekend my 48x gave an almighty clang as it launched one of my older CDs out the rear of the drive unit. Some of the older audio CD's are thicker than the new one's. It appears that newer CDROM's drives do not "clamp" the thicker disks adequately. Needless to say, the CD inherrited some quite radical scratches on its way THROUGH the drive. It left the spindle with enough force to dent the drive casing!
I dont know if anyone has had a similar experience. Fortunately this only seems to be a problem with thicker CD's and new FAST drives.
Cheers, Stuart
Interesting thread.
If the source files are written in something like C, then a number of different uP's can be used. For simplicity sake (and because I have all the dev tools) I would tend towards one of the Microchip 18F devices such as the PIC18F442 or their DSPIC range of DSP processors. If the source files are written in a nice modular format then it would be pretty easy to recompile them for each of the various processors.
Another issue that is quite important to this discussion is the sourcing of a reasonable CDROM drive. For Audio I tend to prefer the older (SLOWER) drives.
This last weekend my 48x gave an almighty clang as it launched one of my older CDs out the rear of the drive unit. Some of the older audio CD's are thicker than the new one's. It appears that newer CDROM's drives do not "clamp" the thicker disks adequately. Needless to say, the CD inherrited some quite radical scratches on its way THROUGH the drive. It left the spindle with enough force to dent the drive casing!
I dont know if anyone has had a similar experience. Fortunately this only seems to be a problem with thicker CD's and new FAST drives.
Cheers, Stuart
Hey Stuart
I totaly agree with your thoughts on the programming. What I've been thinking so far, is that we should put together a "basic" design (schematic, PCB & software) so that anyone can put one together, but that we should also allow room for those people who would want to mod the code, or as you point out, use different hardware.
If you go up the thread, you will find I have also mentioned the "older CDROM better than newer ones for audio" story. I'll also be looking for a really old 2X or something for this project. The speed itself isn't an issue since we can limit it via software, but old age means better quality in this case.
Can anyone please post a list (or link to a list) of all the commands an ATAPI device will accept? I would be very grateful.
Cheers
DJ
I totaly agree with your thoughts on the programming. What I've been thinking so far, is that we should put together a "basic" design (schematic, PCB & software) so that anyone can put one together, but that we should also allow room for those people who would want to mod the code, or as you point out, use different hardware.
If you go up the thread, you will find I have also mentioned the "older CDROM better than newer ones for audio" story. I'll also be looking for a really old 2X or something for this project. The speed itself isn't an issue since we can limit it via software, but old age means better quality in this case.
Can anyone please post a list (or link to a list) of all the commands an ATAPI device will accept? I would be very grateful.
Cheers
DJ
Universal programming
Hi All,
I agree with the C -programming part. If you program neatly the source code should be easy porable towards other microcontrollers.
Also some thoughts regarding the PCB. If we create a pcb with the size of the CD-ROM drive. We could mount it under the CD-ROM drive. Put the power and IDE connector on the back (nice short leads to the drive) and put the switches and the infrared receiver on the front. That way the package would be small.
Regarding the newer or older CD-ROM drives. I think the newer CD-ROM drives might be better if run on a slow speed. I don't think the clamping of the newer drives is worse but the speed of the newer drives is too high. I've seen a drive wasted because the disk inside it broke due to the high speed of the drive. You could find peaces everywhere. I think the tolerances of the new drives in order to work at these high speeds need to be very small. Also the laser needs to be very strong to read the data at such high speeds. If you manage to run the drive at normal speed the newer drive is probably better than the old one. Haven't tested it though. Might be an interesting test to do when this project is in a working stadium.
MGB
Hi All,
I agree with the C -programming part. If you program neatly the source code should be easy porable towards other microcontrollers.
Also some thoughts regarding the PCB. If we create a pcb with the size of the CD-ROM drive. We could mount it under the CD-ROM drive. Put the power and IDE connector on the back (nice short leads to the drive) and put the switches and the infrared receiver on the front. That way the package would be small.
Regarding the newer or older CD-ROM drives. I think the newer CD-ROM drives might be better if run on a slow speed. I don't think the clamping of the newer drives is worse but the speed of the newer drives is too high. I've seen a drive wasted because the disk inside it broke due to the high speed of the drive. You could find peaces everywhere. I think the tolerances of the new drives in order to work at these high speeds need to be very small. Also the laser needs to be very strong to read the data at such high speeds. If you manage to run the drive at normal speed the newer drive is probably better than the old one. Haven't tested it though. Might be an interesting test to do when this project is in a working stadium.
MGB
I think we all agree on using C (and neat programming style) now. Or am I wrong?
I also agree it would be nice if the PCB can be smaller or equal in size to the CDROM.
I think we could also benefit from, using a well regulated powersupply for the CDROM itself (at least) to ensure the most accurate reading and least jitter possible. By well regulated I mean very possibly a discrete regulator (not an IC such as LM78xx) and preferrably not a switching supply since these can cause noise.
I would be glad to design such a PSU later on, but perhaps someone else (elsewhere in the forum) can start doing so already(?).
I won't go into the physics now, but I don't believe the newer CDROMs' lasers are any "stronger" than the old ones', MGB. Perhaps they are slightly more accurate, but I doubt it would be worth it when weighing up the negative factors of newer drives (build quality etc). Anyway, the nice thing is everyone can choose for themselves what drives they want to use, so it's up to you.
Cheers for now.
DJ
I also agree it would be nice if the PCB can be smaller or equal in size to the CDROM.
I think we could also benefit from, using a well regulated powersupply for the CDROM itself (at least) to ensure the most accurate reading and least jitter possible. By well regulated I mean very possibly a discrete regulator (not an IC such as LM78xx) and preferrably not a switching supply since these can cause noise.
I would be glad to design such a PSU later on, but perhaps someone else (elsewhere in the forum) can start doing so already(?).
I won't go into the physics now, but I don't believe the newer CDROMs' lasers are any "stronger" than the old ones', MGB. Perhaps they are slightly more accurate, but I doubt it would be worth it when weighing up the negative factors of newer drives (build quality etc). Anyway, the nice thing is everyone can choose for themselves what drives they want to use, so it's up to you.
Cheers for now.
DJ