-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
2.5" SCSI SSD Project
- Thread starter techknight
- Start date
i ran into an issue and put it away, maybe look at it at another date. I dont know if its a clock jitter issue, or simple firmware issue. I dont know. The firmware is open source C and my knowledge of C is next to nil and thats where i got stuck in a standstil.
I have 2 boards but only have 1 set of transceivers. I was going to build another one and send it to someone to debug that knew C better than I. But i havent had the time.
I have 2 boards but only have 1 set of transceivers. I was going to build another one and send it to someone to debug that knew C better than I. But i havent had the time.
Its this here:
http://micha.freeshell.org/pcmcia_drive/index.php
its a direct copy of the source code. No code mods, Only difference is i had to recompile for the ATmega128 instead of the ATmega64.
the other AVR is also different, He is using an ATmega169 and i used an ATmega165A which wont directly run 169 code, but that is in ASM so that was a simple directives change in AVR Studio.
I just designed a smaller board thats direct to CF instead of that large monster he has. Really thats the only 2 differences. his is full PCMCIA, mine is not. And he is using 2 different CPUs than I. I basically followed his schematic, and just eliminated anything I didnt need for my setup, as i was doing CF directly instead of PCMCIA.
Also the CF card wasnt being detected properly either, but i havent even begun to troubleshoot anything until i get the SCSI part nailed down.
If i remember where i left off, the PC AHA-2940 card would see the drive and its custom instance ID if i disabled parity. otherwise parity check would fail, And the drive would hang after the ID inquiry.
also, the mac would just reject it totally and say the BUS isnt terminated. LOL, i dont have a terminator on the board, but i used one of those old MAC II dongle terminators. Then i tried using a terminated drive in the chain and that didnt make a difference on how the mac acted.
It could just be poor layout of the board, it could also be the way my PC compiled the code. the latest AVR-GCC wont compile that code. I had to find an old copy of WinAVR that compiles it without inline errors.
the problem has always been the communication between the two AVRs. it seems to get confused/lost and the response never comes or races too fast. I dont know. I thought about pulling both crystals and syncing the CPUs off the same clock to avoid jitter issues. But the firmware was written to handle just this issue.
Also the drive wont work at all if i disable debug output mode. I have to use debug which slows the thing down otherwise it just never inits.
http://micha.freeshell.org/pcmcia_drive/index.php
its a direct copy of the source code. No code mods, Only difference is i had to recompile for the ATmega128 instead of the ATmega64.
the other AVR is also different, He is using an ATmega169 and i used an ATmega165A which wont directly run 169 code, but that is in ASM so that was a simple directives change in AVR Studio.
I just designed a smaller board thats direct to CF instead of that large monster he has. Really thats the only 2 differences. his is full PCMCIA, mine is not. And he is using 2 different CPUs than I. I basically followed his schematic, and just eliminated anything I didnt need for my setup, as i was doing CF directly instead of PCMCIA.
Also the CF card wasnt being detected properly either, but i havent even begun to troubleshoot anything until i get the SCSI part nailed down.
If i remember where i left off, the PC AHA-2940 card would see the drive and its custom instance ID if i disabled parity. otherwise parity check would fail, And the drive would hang after the ID inquiry.
also, the mac would just reject it totally and say the BUS isnt terminated. LOL, i dont have a terminator on the board, but i used one of those old MAC II dongle terminators. Then i tried using a terminated drive in the chain and that didnt make a difference on how the mac acted.
It could just be poor layout of the board, it could also be the way my PC compiled the code. the latest AVR-GCC wont compile that code. I had to find an old copy of WinAVR that compiles it without inline errors.
the problem has always been the communication between the two AVRs. it seems to get confused/lost and the response never comes or races too fast. I dont know. I thought about pulling both crystals and syncing the CPUs off the same clock to avoid jitter issues. But the firmware was written to handle just this issue.
Also the drive wont work at all if i disable debug output mode. I have to use debug which slows the thing down otherwise it just never inits.
Has anyone looked into doing this with an FPGA? People are recreating entire vintage computers in those these days, it seems like SCSI to whatever would be doable in one of the smaller FPGAs. It's a bit outside of my current skillset but it's something I'd be interested in seeing someone try.
