Jump to content
SS

using the SDRIVE-MAX in conjunction with other drives

Recommended Posts

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.... :D

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites

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 by MrMartian
  • Like 5

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites

 

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!

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by _The Doctor__
  • Like 1

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

Here is what I am seeing. In both instances, I have the 1050 turned on and a DOS 2.5 floppy loaded in it.

 

 

post-1863-0-39893000-1540143714.jpg

 

post-1863-0-21784600-1540143735.jpg

 

post-1863-0-07407700-1540143753.jpg

Edited by SS

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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'...

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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 by _The Doctor__

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Kyle22

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

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 by _The Doctor__
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...