Zerosquare Posted June 16, 2007 Report Share Posted June 16, 2007 Here's a little idea I had to circumvent the Jaguar's UART bug. The ZIP file contains a detailed description and a demo program (the source code is included). Enjoy ! TestUART.zip 1 Link to comment Share on other sites More sharing options...
Zerosquare Posted June 17, 2007 Author Report Share Posted June 17, 2007 Version 1.01 is now available. I updated the file in the original topic. Link to comment Share on other sites More sharing options...
TXG/MNX Posted June 22, 2007 Report Share Posted June 22, 2007 Version 1.01 is now available. I updated the file in the original topic. Can we expect a DOOM patch someday ? Link to comment Share on other sites More sharing options...
ovalbugmann Posted June 22, 2007 Report Share Posted June 22, 2007 Thanks Zerosquare. Link to comment Share on other sites More sharing options...
SebRmv Posted October 27, 2011 Report Share Posted October 27, 2011 Hello, these days, I have powered up my Jaguar and played a bit with the UART controller. On my PC, I used putty to communicate on the serial link with the Jag. (I have a RS232 cable plugged in the Jaglink2 on the Jaguar side) I observed that the parity bit in ASICTRL has the opposite meaning of what is said in Jag_v8. Am I the first one to observe this? (i.e. when bit #0 of ASICTRL is set to 1, and parity control is enabled, even parity is active) I also observed the problem of corrupted characters (left shifted by 1 bit). However, the error bits of the ASISTAT register seems to be set correctly. So by just clearing the errors and dropping the received character, I guess it is easy to recover from this error. (this seems to work in practice) This means that a simple protocol to transmit packets over UART would work. (I mean transmitting packets on an unreliable channel is doable, if not everything is lost of course!) Are there any other bugs I should be aware in the UART? If yes, how can I trigger them? For the moment, I programmed the UART just by polling the ASISTAT register on the 68k side. I intend to experiment a bit with the DSP interrupt and try to see if I can get something working using these few observations. Has somebody already tried these ideas? (I guess yes, but we never know) Link to comment Share on other sites More sharing options...
SebRmv Posted October 27, 2011 Report Share Posted October 27, 2011 I played a bit this night and unfortunately, it is not that easy! The receiver seems to become deaf if we stress it too much and I have not found the way to reset it until now. By the way, it is quite cumbersome to set the UART interrupt handler. Actually, it is the GPU that processes the request coming from Jerry. (IT handler at GPU_RAM+$10) Link to comment Share on other sites More sharing options...
Zerosquare Posted October 27, 2011 Author Report Share Posted October 27, 2011 The receiver seems to become deaf if we stress it too much and I have not found the way to reset it until now.Indeded, that's the problem I had too, and I couldn't find a way to reset it either. So I decided to forgot about the broken UART receiver completely and do it in software PS : glad to see you back on the Jaguar Link to comment Share on other sites More sharing options...
SebRmv Posted October 28, 2011 Report Share Posted October 28, 2011 Indeded, that's the problem I had too, and I couldn't find a way to reset it either. So I decided to forgot about the broken UART receiver completely and do it in software Ok. I finally understood what you did (or maybe I understood before but forgot since that time ). But Software UART, nobody wants to do that in real life, doesn't it? (especially when a hardware chip is supposed to do it!) And did you notice this thing regarding the parity? I can't make sense of the remark in the "known bugs" sections about UART where they describe a possible workaround. In particular, I don't understand the following: "Subsequent bytes should be exactly aligned (i.e. 2, 3 or 4 stop bits exactly, before the next start bit)" Can you make sense of that? I suspect the key is there. How is it possible to transmit several stop bits? Link to comment Share on other sites More sharing options...
Fredifredo Posted October 28, 2011 Report Share Posted October 28, 2011 Yeah ! Sebrmv is back Link to comment Share on other sites More sharing options...
sh3-rg Posted October 28, 2011 Report Share Posted October 28, 2011 Yeah ! Sebrmv is back \o/ Link to comment Share on other sites More sharing options...
Zerosquare Posted October 28, 2011 Author Report Share Posted October 28, 2011 But Software UART, nobody wants to do that in real life, doesn't it? (especially when a hardware chip is supposed to do it!)Why not, if it works fine ? (in embedded electronics, it's not rare to emulate features in software when the hardware is buggy -- or too expensive to afford) And did you notice this thing regarding the parity?Nope, but IIRC I always used the "no parity" setting, so I probably didn't run into it. I can't make sense of the remark in the "known bugs" sections about UART where they describe a possible workaround. In particular, I don't understand the following: "Subsequent bytes should be exactly aligned (i.e. 2, 3 or 4 stop bits exactly, before the next start bit)" Can you make sense of that? I suspect the key is there. How is it possible to transmit several stop bits? The stop bit level and the idle level (when you're not transmitting anything) are the same. Which means (for example) that sending a byte with 1 stop bit, then waitng for the duration of 2 bits before sending the next byte, is the same as sending the first byte with 3 stop bits. What they mean is that the delay between incoming bytes should be an integral multiple of the bit duration. If that's true, that means that if you send a continuous stream of bytes, you should never run into the problem ; that would be interesting to try. If it works, it would be easy to work around the problem : when you don't have anything to transmit, just send "filler" bytes to keep the UART busy. (note that it's problematic for network with more than 2 consoles for collision reasons) Link to comment Share on other sites More sharing options...
SebRmv Posted October 29, 2011 Report Share Posted October 29, 2011 Why not, if it works fine ? (in embedded electronics, it's not rare to emulate features in software when the hardware is buggy -- or too expensive to afford) Yes, I know that, since I work in a company that does embedded platforms. But I feel it is a waste of DSP power until I got the proof it is impossible to do an other way on the Jag. Do you think other people that did a workaround for the UART bug uses a method similar to yours? The stop bit level and the idle level (when you're not transmitting anything) are the same. Which means (for example) that sending a byte with 1 stop bit, then waitng for the duration of 2 bits before sending the next byte, is the same as sending the first byte with 3 stop bits. What they mean is that the delay between incoming bytes should be an integral multiple of the bit duration. If that's true, that means that if you send a continuous stream of bytes, you should never run into the problem ; that would be interesting to try. If it works, it would be easy to work around the problem : when you don't have anything to transmit, just send "filler" bytes to keep the UART busy. (note that it's problematic for network with more than 2 consoles for collision reasons) I have not understood. Link to comment Share on other sites More sharing options...
SebRmv Posted October 29, 2011 Report Share Posted October 29, 2011 I think I found something!!!!!!!!! It does not work yet, but I think I am on the way to get a workaround. So maybe someone here can experiment on his own. While taking my shower, I had the crazy idea to write back the ASICLK value every time I get in the UART receiver interrupt (just before leaving interrupt handler). Here are the details of the experiments. On the PC side, I set my serial port to 57600 bauds, even parity control. On the Jaguar side, same thing. On the PC side, I launch the simple script: while true; do echo -n "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > /dev/ttyS0; done With my patch, the UART receiver is alive during more than 10 seconds (I got more than 1 minute several times, my record is maybe 3 minutes) Without my patch, the UART receiver dies very quickly (a few seconds in the best case) I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds) Link to comment Share on other sites More sharing options...
SebRmv Posted October 29, 2011 Report Share Posted October 29, 2011 I also observed that the duration of the liveness depends on the length of the message transmitted. (for the message "0123456789abcdef", it lasts only a few seconds) No, this actually seems to be the message content! If I send "aa", this works a long time. If I send "01", the receiver dies quickly. Link to comment Share on other sites More sharing options...
Zerosquare Posted October 29, 2011 Author Report Share Posted October 29, 2011 Interesting... But with your script, a delay can occur between two "echo" commands. I think you should try something like "cat big_file > /dev/ttyS0" (big_file being a few megabytes for example), or a small C program like this : #include <stdio.h> int main(void) { char buffer[] = "0123456789"; FILE *f = fopen("/dev/ttyS0", "wb"); for (;;) { fwrite(buffer, 1, strlen(buffer), f); } } Link to comment Share on other sites More sharing options...
ggn Posted October 30, 2011 Report Share Posted October 30, 2011 This is all very interesting Just out of interest, I found the send/receive code on doom, if Seb gets something stable running I could try hacking it into doom (of course someone with 2 Jaguars, 2 Jaglinks and 2 skunkboards should have to do the tests ) Link to comment Share on other sites More sharing options...
SebRmv Posted October 30, 2011 Report Share Posted October 30, 2011 Well, I think I am still quite far from getting a "light" workaround (if such a thing is possible). By the way, what happens in Doom when network crashes? Link to comment Share on other sites More sharing options...
sh3-rg Posted October 30, 2011 Report Share Posted October 30, 2011 This is all very interesting Just out of interest, I found the send/receive code on doom, if Seb gets something stable running I could try hacking it into doom (of course someone with 2 Jaguars, 2 Jaglinks and 2 skunkboards should have to do the tests ) /me holds up his hand, but politely requests the return of 1 jaglink Link to comment Share on other sites More sharing options...
ggn Posted October 30, 2011 Report Share Posted October 30, 2011 That's what we got on one of our tries at Outline 2010: Although I do recall a message saying something like "link lost" Link to comment Share on other sites More sharing options...
SebRmv Posted October 30, 2011 Report Share Posted October 30, 2011 But is Doom crashed? Or is it possible to play again (alone and/or over the nerwork) without resetting the Jag? Link to comment Share on other sites More sharing options...
NooB Posted November 1, 2011 Report Share Posted November 1, 2011 The only way to recover from the 'network crash' is to reset the Jaguars. If I remember rightly, ggn and sh3 were trying to play some of the hacked Doom II levels that I did. Some of them are larger and more complex than the original levels, but I doubt this would have had any ill effect on the already bugged network code.. extra data due to the larger more complex levels. Link to comment Share on other sites More sharing options...
SebRmv Posted November 2, 2011 Report Share Posted November 2, 2011 The only way to recover from the 'network crash' is to reset the Jaguars. If I remember rightly, ggn and sh3 were trying to play some of the hacked Doom II levels that I did. Some of them are larger and more complex than the original levels, but I doubt this would have had any ill effect on the already bugged network code.. extra data due to the larger more complex levels. Thanks for the info Link to comment Share on other sites More sharing options...
TXG/MNX Posted February 4, 2013 Report Share Posted February 4, 2013 The only way to recover from the 'network crash' is to reset the Jaguars. If I remember rightly, ggn and sh3 were trying to play some of the hacked Doom II levels that I did. Some of them are larger and more complex than the original levels, but I doubt this would have had any ill effect on the already bugged network code.. extra data due to the larger more complex levels. Thanks for the info Is this topic dead or has someone done some more testing or maybe did found a good solution ? Secondly did one of you manage to patch doom to be more stable ? Link to comment Share on other sites More sharing options...
Zerosquare Posted February 4, 2013 Author Report Share Posted February 4, 2013 I don't think anybody ever tried to modify the Doom serial code. Link to comment Share on other sites More sharing options...
Matthias Posted February 10, 2013 Report Share Posted February 10, 2013 Hello all! I don't think anybody ever tried to modify the Doom serial code. My excuse is: At the time when the mentioned workaround was discussed i only had one JagLink as i had forwarded the second to another developer, but then i bought a new JagLink package from Nick at Euro-Jagfest 2011, but focussed on getting Impulse X released (and this job is still not finished). Best regards Matthias Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now