Level42 Posted October 19, 2018 Share Posted October 19, 2018 Sneak a few more minutes in tonight.. I didn't mean to be a tease.. The diode is basically there to allow a 'wire-or' method of sharing the wire, only allowing the device to pull the line low and using the pull up resistor in the Atari to keep it high. The ATMega32 chip can configure the pin used as serial transmit to be different functions, so all I did was change it so that normally it's an input not driving the pin high or low, but when it needs to send data it turns the pin to serial transmitter until it's done and then back to an input... I'll clean up the code, and post a git diff tomorrow and figure out how to send it back.. I'm more of a mercurial guy than git..... Great ! (got one bag of useless diodes here now.....ahhh whatever...they cost close to nothing anyway.... 2 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 19, 2018 Share Posted October 19, 2018 Basically yes, this doesn't affect any timing of anything whatsoever. It enabled the USART tx pin as soon as the first byte needs to transmit, and then off again as soon as it's done processing a command. This evening when I'm home I will have time to post the changes, and I will upload the .hex files it created. Then lots of people can try running it. You can even leave the diode in place to test this as it won't affect anything. But, going forward, no one will need to add the diode / have any issues with the proper value. Not having the diode at all means no worrying about voltage drop, etc. 4 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 19, 2018 Share Posted October 19, 2018 (edited) Here is the diff: diff --git a/SDrive.c b/SDrive.c index 0590906..7b28795 100644 --- a/SDrive.c +++ b/SDrive.c @@ -374,6 +374,9 @@ int main(void) CMD_PORTREG |= 1 << CMD_PIN; // with pullup CMD_DDR &= ~(1 << CMD_PIN); // to input + // enable port D pin pull-ups + PORTD = 0xFF; + //interrupts PCICR = (1<<PCIE1); PCMSK1 = (1<<PCINT13); // for CMD_PIN @@ -746,6 +749,7 @@ ISR(PCINT1_vect) cmd_buf.cmd = 0; //clear cmd to allow read from atari process_command(); + UCSR0B = (1<<RXEN0); // turn off transmitter LED_GREEN_OFF(virtual_drive_number); // LED OFF vp = FileInfo.vDisk; //save actual vDisk pointer diff --git a/usart.c b/usart.c index 7d2927d..d33895c 100644 --- a/usart.c +++ b/usart.c @@ -65,7 +65,7 @@ void USART_Init ( u16 value ) { //UCSRA = (1<<UDRE); /* Enable Receiver and Transmitter */ - UCSRB = (1<<RXEN)|(1<<TXEN); + UCSRB = (1<<RXEN); //|(1<<TXEN); /* Set frame format: 8data, 1stop bit */ UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); { @@ -75,6 +75,8 @@ void USART_Init ( u16 value ) { } void USART_Transmit_Byte( unsigned char data ) { + /* enable transmitter now */ + UCSRB = (1<<RXEN)|(1<<TXEN); /* Wait for empty transmit buffer */ while ( !( UCSRA & (1<<UDRE)) ) ; And the .hex files to program: Edit: The .hex files are based on the v10 branch, but the patch works on any version... sdrive-nodiode.zip Edited October 19, 2018 by MrMartian 5 Quote Link to comment Share on other sites More sharing options...
SS Posted October 20, 2018 Author Share Posted October 20, 2018 SS, did you get your device updated? YES! SUCCESS! Thank you very much! So now when new firmware is released, do I only have to replace the SDrive.hex file in the folder with the new one and repeat the entire process? 1 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted October 20, 2018 Share Posted October 20, 2018 YES! SUCCESS! Thank you very much! So now when new firmware is released, do I only have to replace the SDrive.hex file in the folder with the new one and repeat the entire process? Close. You'll need both eeprom_writer.hex and SDrive.hex files. Flash them to the device in that order. But I'm glad the flashing process worked and went well for you! 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted October 20, 2018 Share Posted October 20, 2018 I still can't have the SDrive Max on the SIO chain when the BBS is running. It interferes with 850 RS-232 comms. It still boots protected Archon just fine. 2 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 20, 2018 Share Posted October 20, 2018 I still can't have the SDrive Max on the SIO chain when the BBS is running. It interferes with 850 RS-232 comms. It still boots protected Archon just fine. I can understand that... Not to take anything away from the work that's been done to get it this far, but the code could use a real good cleanup... Also, I'm curious about the choice of pin for the command signal.. Moving it to another pin would make some programming easier. 1 Quote Link to comment Share on other sites More sharing options...
SS Posted October 20, 2018 Author Share Posted October 20, 2018 So far with both the 1.0b and "nodiode" updates everything is working pretty good. I still cannot get my SIO devices to function together with the SDRIVE-MAX though. Even the brief success that I had using the 1050 and SDRIVE in serial with my stock 800XL seems to have disappeared. Not really a huge deal because I will probably be using the SDRIVE-MAX primarily as the only SIO device attached to my 600XL rather than with the hub attached to the U1MB 800XL machine. It would just be cool to see everything being able to work in tandem with each other functioning independently as D1, D2, and D3. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 21, 2018 Share Posted October 21, 2018 what is command line doing? is it holding the wrong state while idle. Quote Link to comment Share on other sites More sharing options...
SS Posted October 21, 2018 Author Share Posted October 21, 2018 what is command line doing? is it holding the wrong state while idle. I don't think that I have been paying enough attention to it. I will see if I can get a look a little later today. Do you think that it makes much difference which XL that I use for the testing? Stock or U1MB? Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 21, 2018 Share Posted October 21, 2018 (edited) command line not in proper state is what could mess with all connected devices... drives or 850's it's tells everything hey wake up and listen! Edited October 21, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 21, 2018 Share Posted October 21, 2018 My comment regarding the command line, is that they put it on a normal digital pin, and enable the pin change interrupt on it. This causes an interrupt when it goes low and when it goes high.. If instead they had routed it to one of the defined INTx pins, it could be configured to only interrupt when going low. It would just save some code determining the state of the command signal in the interrupt handler.. Also, the INT0 pin is beside the TxD pin, so the wires would have gone to three adjacent pins, instead of the one spread across the board. <shrug> Also, as much as I'm very familiar with the ATMega itself, this project has made me look at the Arduino platform.. And, I see something I don't like for this use. The serial port on the ATMega32 is also connected to the onboard ATMega16U2 which is used for programming the board over USB. But, this means there is *another* device connected to those two pins (RxD, TxD) that can cause problems. Perhaps this is why some UNO boards are working fine, and others not, depending on how those lines are being handled when no programming. For reference, I use the "Elegoo UNO R3 Board ATmega328P ATMEGA16U2 with USB Cable for Arduino" board from Amazon and have no problems. I'm investigating how the boot loaders work on these boards, as this could also cause all the problems! 1 Quote Link to comment Share on other sites More sharing options...
SS Posted October 21, 2018 Author Share Posted October 21, 2018 (edited) Here is what I am seeing. In both instances, I have the 1050 turned on and a DOS 2.5 floppy loaded in it. Edited October 21, 2018 by SS Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted October 21, 2018 Share Posted October 21, 2018 And the .hex files to program: Edit: The .hex files are based on the v10 branch, but the patch works on any version... Thanks for looking into this. Behavior on my equipment with this version is the same as with the current v10 branch - 1050 boots fine with empty SDrive-MAX D1 and reading/writing from SDrive-MAX D2, and the Indus refuses to boot with the SDrive-MAX attached. A suggestion if I might - if there is going to be compiled firmware with your changes out in the wild, I'd suggest changing the displayed version number slightly as well as to avoid the eventual confusion that will occur. Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 21, 2018 Share Posted October 21, 2018 Thanks for looking into this. Behavior on my equipment with this version is the same as with the current v10 branch - 1050 boots fine with empty SDrive-MAX D1 and reading/writing from SDrive-MAX D2, and the Indus refuses to boot with the SDrive-MAX attached. A suggestion if I might - if there is going to be compiled firmware with your changes out in the wild, I'd suggest changing the displayed version number slightly as well as to avoid the eventual confusion that will occur. I've sent my changes upstream, so hopefully they're incorporated, and there is no 'version with my changes'... Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 21, 2018 Share Posted October 21, 2018 Here is what I am seeing. In both instances, I have the 1050 turned on and a DOS 2.5 floppy loaded in it. Odd... You have things set right. If you put a disk in the SDrive D1: and have your 1050 set to D2:, does it screw up as well? Quote Link to comment Share on other sites More sharing options...
SS Posted October 21, 2018 Author Share Posted October 21, 2018 Odd... You have things set right. If you put a disk in the SDrive D1: and have your 1050 set to D2:, does it screw up as well? Yes. The Atari just cannot seem to see the 1050 when the SDRIVE is connected and turned on, whether the 1050 is set to D1 or D2. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 21, 2018 Share Posted October 21, 2018 (edited) did you jump your diodes and try maybe the combination is up to no good? it shouldn't be however anything is possible. in any event some progress is made and hopefully giving moving cmd a whirl might help... wonders what for or why that choice was made Edited October 21, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 22, 2018 Share Posted October 22, 2018 Yes. The Atari just cannot seem to see the 1050 when the SDRIVE is connected and turned on, whether the 1050 is set to D1 or D2. Looking back through the posts, and the picture of your board piques my interest, as it isn't using another ATMega for the programming interface. Do you know if the manufacturer of your board posted schematics? I would expect that we'll see that the serial programming ports are interfering... Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 22, 2018 Share Posted October 22, 2018 Looking back through the posts, and the picture of your board piques my interest, as it isn't using another ATMega for the programming interface. Do you know if the manufacturer of your board posted schematics? I would expect that we'll see that the serial programming ports are interfering... I looked at the high res pictures, and then googled some more and found that your board seems to use a CH340 usb to serial adapter. Many people seem to dislike these clones as they have problems with them overall.. I will go with this being the root of the problem. Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted October 22, 2018 Share Posted October 22, 2018 I looked at the high res pictures, and then googled some more and found that your board seems to use a CH340 usb to serial adapter. Many people seem to dislike these clones as they have problems with them overall.. I will go with this being the root of the problem. All the units I've made (including mine) use a board that has a CH340 chipset. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted October 22, 2018 Share Posted October 22, 2018 All the units I've made (including mine) use a board that has a CH340 chipset. Ditto mine. Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted October 22, 2018 Share Posted October 22, 2018 (edited) Mine is also a CH340. The Indus (D1:) will NOT boot with SDrive attached as D2: Edit: I have NO diode yet, but I AM using the 'diodeless' firmware. Edited October 22, 2018 by Kyle22 Quote Link to comment Share on other sites More sharing options...
SS Posted October 22, 2018 Author Share Posted October 22, 2018 I looked at the high res pictures, and then googled some more and found that your board seems to use a CH340 usb to serial adapter. Many people seem to dislike these clones as they have problems with them overall.. I will go with this being the root of the problem. So what you're saying is that there's likely no good fix based on the equipment that I currently have? In that case, I am going to stop worrying about it and just use the SDRIVE as a stand-alone device. Thanks for the info. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 22, 2018 Share Posted October 22, 2018 (edited) aren't all uno's ch340 and ch341 compat..... but the trailing letter differs... that trailing letter seems to show the need to make the chip invert some signals etc.. and select either pull up or pull down on some pins... look through the data sheets... take a gander at where the paragraphs start below the standard table run down... t r g h all have something slightly different. chances are most of us have g's If we can determine who has what and the two chips involved a solution will follow... this still has a chance for fixing... Edited October 22, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.