+mytek Posted April 28, 2016 Share Posted April 28, 2016 I did a search and didn't turn up anything of much use, so maybe someone knows of something that was written to do this. Basically what I am looking for is preferably a machine language routine that could be put into Page 6 and then called from BASIC. I only need transmit, and will convert the TTL output to RS232 with a MAX232 (or similar chip). The information I wish to send would be ASCII coded characters, including carriage Return and possibly Line Feed. Could be something as simple as by poking a memory location with a single ASCII character, would then automatically invoke send, after which a null character would take its place waiting for another character to be poked. Baud rate doesn't need to be fast, with even 300 baud being quite usable (if faster speed were possible, 1200 would be preferred although not necessary). So anyone seen such a thing? - Michael Quote Link to comment Share on other sites More sharing options...
+David_P Posted April 28, 2016 Share Posted April 28, 2016 There's the old drivers for the MPP modems that might do this; there's also (somewhere on Atari Age) source code to run an SIO connection through a joystick port as well. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 28, 2016 Share Posted April 28, 2016 Homebrew printer interfaces using joystick ports were common though I think some were parallel. You could use the SIO port, but the disadvantage there is that it generates start and stop bits whether you want them or not. Alternatively you can bit-bang through the SIO port. The advantages there is no start/stop bits if you don't want them and the fact there's already plenty of RS232 conversion devices around, ie practically every non-USB SIO2PC type interface uses a RS232 port at the PC end. A sticking point can be getting the bitrate constant. The best method would be to use Pokey Timers or a VCount wait method, in both cases you'd want to disable all interrupt types except the ones you need (Timer and Break key). Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 28, 2016 Author Share Posted April 28, 2016 There's the old drivers for the MPP modems that might do this; there's also (somewhere on Atari Age) source code to run an SIO connection through a joystick port as well. Did a search based on A.A. for "SIO connection through a joystick port" and didn't find anything (perhaps I'll do a Google search as well and also look into the MPP drivers). Thanks for the tip . Homebrew printer interfaces using joystick ports were common though I think some were parallel. You could use the SIO port, but the disadvantage there is that it generates start and stop bits whether you want them or not. Alternatively you can bit-bang through the SIO port. The advantages there is no start/stop bits if you don't want them and the fact there's already plenty of RS232 conversion devices around, ie practically every non-USB SIO2PC type interface uses a RS232 port at the PC end. A sticking point can be getting the bitrate constant. The best method would be to use Pokey Timers or a VCount wait method, in both cases you'd want to disable all interrupt types except the ones you need (Timer and Break key). I'd kinda like to avoid the SIO port since it uses a non-standard connector and would also require daisy-chaining with other peripherals on that bus. - Michael Quote Link to comment Share on other sites More sharing options...
+David_P Posted April 28, 2016 Share Posted April 28, 2016 Found my file copy of the SIO to Joystick information on my NAS, that I believe Curt Vendel posted several years ago. Here goes: Wanna have some fun, check out this file I found from some materials out of Atari's on computer engineering department in 1984:It details making a disk drive simulator through the joystick port from one Atari to another:TITLE 'DISK SIMULATOR'SUBTTL 'MAINLINE';FILE DISKSIM.ASM;7/17/84;This program simulates a disk drive which understands the SIO;fast mode protocol. Joystick port #2 of the computer running this;program is connected to the SIO port of another computer equipped;with Rev 4 (or later) OS, as follows:;; SIO CONNECTOR JOYSTICK PLUG;; GND 4 --------------------- 8 GND; DATA IN 3 --------------------- 2 BACK; COMMAND 7 --------------------- 3 LEFT; DATA OUT 5 --------------------- 4 RIGHTDATIN EQU $20DATOUT EQU $80COMAND EQU $40;EQUATESPORTA EQU $D300PACTL EQU $D302NMIEN EQU $D40ESDMCTL EQU $22FDMACTL EQU $D400;PROGRAM ORIGINORG $4000;TURN OFF SCREEN TO GET ACCURATE TIMINGSTARTLDA #0STA NMIENSTA SDMCTLSTA DMACTL;DISABLE OUTPUTDISOUTLDA #$38STA PACTL ;DIRECTIONLDA #$00STA PORTA ;DISABLE OUTPUT TO DATA IN LINELDA #$3CSTA PACTL;RECEIVE COMMAND FRAMECOMFRMBIT PORTABVC COMFRM ;WAIT FOR COMMAND TO GO HIGHCOM1BIT PORTABVS COM1 ;WAIT FOR COMMAND TO GO LOWLDY #4JSR RXF192 ;RECEIVE COMMAND FRAMEBCS COMFRM ;IF ERRORLDY #4JSR CHKSUMBNE COMFRM ;IF BAD CHECKSUMLDA FRAME+4CMP #$80BNE COMFRM ;IF NOT THIS DEVICE;ENABLE OUTPUTLDA #$20STA PORTA ;PRECONDITION OUTPUTLDA #$38STA PACTL ;DIRECTIONLDA #$20STA PORTA ;ENABLE OUTPUT TO DATA IN LINELDA #$3CSTA PACTLLDA #$20STA PORTA;CHECK COMMANDCOM2BIT PORTABVC COM2 ;WAIT FOR COMMAND TO GO HIGHLDA FRAME+3CMP #$52BEQ GET ;IF GET COMMANDCMP #$50BEQ PUT ;IF PUT COMMAND;UNRECOGNIZED COMMAND, SEND NAKNAKLDA #'N'STA FRAMELDY #0JSR TXF192JMP DISOUT;PROCESS GET COMMAND (WE SEND)GETLDA #'H'STA FRAMELDY #0JSR TXF192 ;HIGH SPEED ACKBCS GET1 ;IF ERRORJSR D1000 ;DELAY 1000 USLDA #'C'STA FRAMELDY #0JSR TXF384 ;SEND COMPLETEBCS GET1 ;IF ERRORLDY #128JSR CHKSUM ;CALCULATE CHECKSUMLDY #128JSR TXF384 ;SEND THE FRAMEGET1JMP DISOUT;PROCESS PUT COMMAND (WE RECEIVE)PUTLDA #'H'STA FRAMELDY #0JSR TXF192 ;SEND HIGH SPEED ACKBCS PUT1 ;IF ERRORLDY #128JSR RXF384 ;RECEIVE THE FRAMEBCS PUT1 ;IF ERROR, DO NOTHINGJSR D1000 ;DELAY 1000 USLDY #128JSR CHKSUMBNE PUT2 ;IF CHECKSUM ERRORLDA #'A'STA FRAMELDY #0JSR TXF384 ;SEND ACKBCS PUT1 ;IF ERRORJSR D1000 ;DELAY 1000 USLDA #'C'PUT3STA FRAMELDY #0JSR TXF384 ;SEND COMPLETEPUT1JMP DISOUT ;DONEPUT2LDA #'N'JMP PUT3 ;SEND NAK, RETURNSUBTTL 'TRANSMIT/RECEIVE SUBROUTINES'ORG $6000;RECEIVE A COMMAND FRAME AT 19200 BAUD;ON ENTRY, FRAME SIZE-1 IN Y (<=128);RETURNS CS IF ERRORRXF192BIT PORTABPL RXSB1 ;IF START BIT DETECTEDBVC RXF192 ;IF COMMAND LOWRXSB2SEC ;ERRORRTSRXSB1LDA #$80 ;INITIAL BYTELDX #9RXSB4DEXBNE RXSB4 ;DELAY 46 CYCLESRXSB5LDX #13RXSB3DEXBNE RXSB3NOP ;DELAY 68 CYCLESPHALDA PORTAASL A ;MOVE BIT INTO CARRYPLAROR A ;MOVE BIT INTO BYTEBCC RXSB5 ;IF NOT DONE WITH 8 BITSSTA FRAME,YLDX #12RXSB6DEXBNE RXSB6NOPNOPNOPNOP ;DELAY 69 CYCLESLDX PORTA ;GET THE STOP BITBPL RXSB2 ;IF IT'S INCORRECTDEYBPL RXF192 ;IF NOT DONE WITH FRAMECLC ;SUCCESSRTS;RECEIVE A DATA FRAME AT 38400 BAUD;ON ENTRY, FRAME SIZE-1 IN Y (<=128);RETURNS CS IF ERRORRXF384BIT PORTABPL RXFB1 ;IF START BIT DETECTEDBVS RXF384 ;IF COMMAND HIGHRXFB2SEC ;ERRORRTSRXFB1LDA #$80 ;INITIAL BYTELDX #3RXFB4DEXBNE RXFB4NOPNOPNOPNOP ;DELAY 24 CYCLESRXFB5LDX #4RXFB3DEXBNE RXFB3NOPNOP ;DELAY 25 CYCLESPHALDA PORTAASL A ;MOVE BIT INTO CARRYPLAROR A ;MOVE BIT INTO BYTEBCC RXFB5 ;IF NOT DONE WITH 8 BITSSTA FRAME,YLDX #5RXFB6DEXBNE RXFB6 ;DELAY 26 CYCLESLDX PORTA ;GET THE STOP BITBPL RXFB2 ;IF IT'S INCORRECTDEYBPL RXF384 ;IF NOT DONE WITH FRAMECLC ;SUCCESSRTSASSERT *<$6101ORG $6100;TRANSMIT A FRAME AT 19200 BAUD;ON ENTRY, FRAME SIZE-1 IN Y;RETURNS CS IF ERRORTXF192BIT PORTABVC TXSB4 ;IF COMMAND LOWLDX #0STX PORTA ;WRITE START BITSECLDA FRAME,YNOP ;DELAY 2 CYCLESTXSB1LDX #11TXSB2DEXBNE TXSB2NOPNOPNOP ;DELAY 62 CYCLESROR APHAROR AROR AROR ASTA PORTA ;WRITE BITPLACLCBNE TXSB1 ;IF NOT DONELDX #11TXSB3DEXBNE TXSB3NOPNOPNOP ;DELAY 62 CYCLESDEYBPL TXF192 ;IF NOT DONE WITH FRAMECLCRTSTXSB4SECRTS;TRANSMIT A FRAME AT 38400 BAUD;ON ENTRY, FRAME SIZE-1 IN Y;RETURNS CS IF ERRORTXF384BIT PORTABVC TXFB4 ;IF COMMAND LOWLDX #0STX PORTA ;WRITE START BITSECLDA FRAME,YNOP ;DELAY 2 CYCLESTXFB1LDX #2TXFB2DEXBNE TXFB2NOPNOPNOPNOP ;DELAY 19 CYCLESROR APHAROR AROR AROR ASTA PORTA ;WRITE BITPLACLCBNE TXFB1 ;IF NOT DONELDX #2TXFB3DEXBNE TXFB3NOPNOPNOPNOP ;DELAY 19 CYCLESDEYBPL TXF384 ;IF NOT DONE WITH FRAMECLCRTSTXFB4SECRTSASSERT *<$6201 ;BYTE I/O ROUTINES MUST BE WITHIN PAGEORG $6200FRAME DS 256SUBTTL 'SUBROUTINES';CALCULATE CHECKSUM;ON ENTRY, FRAME SIZE-1 IN Y;ON EXIT, CHECKSUM IN FRAME, ZS IF CHECKSUM WAS CORRECTCHKSUMLDA #0CHKS1CLCADC FRAME,YADC #0DEYBNE CHKS1LDX FRAMESTA FRAMECPX FRAMERTS;DELAY 1000 USD1000LDX #236D1001NOPDEXBNE D1001RTSEND START Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 28, 2016 Share Posted April 28, 2016 Joystick I/O never gets referred to as SIO even if it is serial transmission. There's not really a huge need to research it. Just decide whether you want clocking as well or will just rely on timing alone, with or without start/stop bits. Note that 0 to 1 transitions are usually laggy and 1 to 0 is almost instant. As such if you use clocking as well it's worthwhile delaying the clock by a few cycles. Just the delay in doing the required instructions would likely be enough. Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 28, 2016 Author Share Posted April 28, 2016 David_P that's cool that you found that! And quite interesting what that was written to do. I guess you could even call that an SIO2ATARI interface. However that is a bit much for what I am after, and in my situation it would be nice to leave the screen display enabled if possible, hence the reason I would be satisfied with even a 300 baud transmission rate. Maybe I'll just pop in my Assembler Editor cartridge tomorrow and try to piece something together. Using a very slow baud rate should help, since the timing wouldn't be as critical. Rybags this would be a asynchronous protocol, 1 start bit, 8 data bits, 1 stop bit, no parity, obviously no hardware handshake (single I/O pin), and no XON/XOFF either. - Michael Quote Link to comment Share on other sites More sharing options...
ricortes Posted April 28, 2016 Share Posted April 28, 2016 One of the Atari books had a serial printer routine/hardware for the J/S port. Could have been http://www.atarimania.com/documents/How-to-Program-you-Atari-in-6502-Language.pdf I loved the MPP driver back in the day, but I am not sure it fits your requirements I think it may have plugged into the second J/S. Other then that, it was pretty nice. IIRC interrupt driven sampling and rock solid transmit/receive at 300 BAUD. Volksmodem who latched onto MPP's cart had a cable that was just a zener and resistor to hold voltages in range. You could plug it into a Supra or Hayes modem and they worked fine albeit at 300 BAUD. The MPP also uses RS232 signal levels or inverted logic if I am saying that right. You may end up having to roll your own if you are using ttl level logic. Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 28, 2016 Author Share Posted April 28, 2016 One of the Atari books had a serial printer routine/hardware for the J/S port. Could have been http://www.atarimania.com/documents/How-to-Program-you-Atari-in-6502-Language.pdf I loved the MPP driver back in the day, but I am not sure it fits your requirements I think it may have plugged into the second J/S. Other then that, it was pretty nice. IIRC interrupt driven sampling and rock solid transmit/receive at 300 BAUD. Volksmodem who latched onto MPP's cart had a cable that was just a zener and resistor to hold voltages in range. You could plug it into a Supra or Hayes modem and they worked fine albeit at 300 BAUD. The MPP also uses RS232 signal levels or inverted logic if I am saying that right. You may end up having to roll your own if you are using ttl level logic. I checked out that book, but didn't find anything. But this sparked my memory of a long time ago. I think around 1983-84 my brother and I wrote an alternative "P:" handler routine that talked with a serial RS232 printer (teletype) via a joystick pin, and utilized an optoisolator to interface from TTL to the printer electronics. I think it was at a 300 baudrate, and it worked perfectly, looking just like a normal printer to the Atari. This would also be the answer to my problem, assuming I still had that code (which fit entirely into Page 6). Sadly I no longer have it . - Michael Quote Link to comment Share on other sites More sharing options...
Brentarian Posted April 28, 2016 Share Posted April 28, 2016 The MPP modems would go up to 450 baud pending the modem on the other end supported the same rate. I remember calling BBSes in the DC area and connecting at 450 baud. Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 28, 2016 Author Share Posted April 28, 2016 (edited) The MPP modems would go up to 450 baud pending the modem on the other end supported the same rate. I remember calling BBSes in the DC area and connecting at 450 baud. 450 what an unusual baudrate But why not, if both ends agree on the timing any baudrate is possible. So I'm thinking that maybe to ease my 6502 assembly programming task (which I am very rusty at), I can utilize a program I found here: Build a Low Cost Printer Interface as a basis for what I need. Essentially it is also an alternative "P:" handler working via the joystick ports, but in that particular implementation done as a parallel interface. I'll just need to go into the code and add a parallel to serial aspect, and perhaps also put in a changeable parameter to select which joystick port is utilized (or more specifically which pin). - Michael Edited April 28, 2016 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 28, 2016 Share Posted April 28, 2016 Baud rate for old type modems would be limited by what frequencies are used for the symbols, generally some multiple 2 or more of the longest wavelength used would dictate it. Though I doubt the problem would arise on anything 2,400 baud or lower. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted April 28, 2016 Share Posted April 28, 2016 (edited) Baud rate for old type modems would be limited by what frequencies are used for the symbols, generally some multiple 2 or more of the longest wavelength used would dictate it. Though I doubt the problem would arise on anything 2,400 baud or lower. yeah, ends up being something like baud/2, baud, baud times 2, etc. shouldn't be equal to the difference between any two frequencies used by the modulation scheme. (although this is somewhat oversimplified, because if you end up with 'negative frequency' this ends up still being a signal present at the corresponding positive frequency, but 180 degrees out of phase) Basically, if you've got a signal at X baud, then you end up with +/-X/2 hz peaks in the spectrum, centered around the frequencies that the modems use. So if you've got a 300 baud transition, causing a 150hz modulation, then you maybe end up with peaks due to modulation at, say, 1120hz and 1420hz centered around 1270hz (mark on a Bell 103 modulation scheme). This becomes an issue as these frequencies end up just happening to coincide with other frequencies used by the modulation scheme. Also, at 300 baud, 150hz isn't the only modulation frequency, it could also happen to be half that, or 1/3, or 1/4, or even 1/5 (but not any lower, unless you're using something longer than 8N1). EDIT: I should note here, that mathematically speaking, these extra peaks are not some unfortunate product of switching between mark and space. They are, mathematically, the reason we are able to change between mark and space. If you were to totally filter out these sideband frequencies, you would actually not be able to change the amplitude. So at a baud rate of 400 baud, for example, you can get +/-200hz peaks, which would give you spectral peaks at 1070 and 1470 centered around 1270 (mark) which becomes an issue because 1070 is space. If you are careful to choose the baud rate so that this does not happen, we can get away with higher rates. 450 baud, for example, results in +/-225hz peaks, which would give you 1045hz and 1495hz peaks centered around 1270, which now don't interfere with the space tone as much. You may initially think that as long as you stay away from 400 baud we can get away with higher speeds. If we go up to 800 baud, however, you get +/- 400hz, but also +/-200hz, which gives us the same issue as 400 did. So what bell did was a good idea, for their specified speed of 300 baud: they put the mark and space tones apart by 200hz, which should give a nearly 400 baud usable bandwidth, if there were perfect mark and space filters. But since there aren't, the extra 100 baud of excess gives a nice margin for keeping away from the mark and space tones. But if one is careful, you can choose the baud rate in such a way that it should avoid interference, as long as you also stay within the ~3500hz high frequency cutoff of the typical phoneline. Edited April 28, 2016 by Joey Z 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 28, 2016 Author Share Posted April 28, 2016 (edited) Argg!!! Well it appears that I have forgotten a lot when it comes to doing 6502 assembly. I spent the whole day with not much to show for my efforts. So I guess I've gotten soft in my old age (the brain that is), and also spoiled by working in higher level languages for the last 15-20 years. Anyway before I have a real melt down, I'm going to hang this up for today and do some more searching to see if I can find an existing joystick to serial print handler routine. I also highly regret having not kept any of my programs from way back when, since all of this was already solved at one time. So just to recap what I was attempting today... I downloaded the joystick parallel printer routine, and then tried to replace the parallel aspect with a bit-banging serial version. I really didn't get very far, since I was just trying to get reacquainted with the assembly tools and the 6502 instruction set. I did write some new code, but it's pretty bad. Then I got an error #5 (Assembler Editor Cart) when assembling at a spot where I hadn't even changed anything with the new handler vectors. Since I don't really understand too much yet about how the handlers really work under the hood, I'm pretty much at a loss for the time being. - Michael EDIT: There is something I don't like about the code I grabbed, and that is it requires a reset to install the handler. I don't believe that was required on the version that my brother and I created back in the 80's, but I could be mistaken. Edited April 28, 2016 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted April 29, 2016 Share Posted April 29, 2016 When using the MadMac assembler on the Atari ST, this used a parallel cable to the joystick ports on the A8 so transferred a byte at a time. On the A8 you'd bootstrap from a disk which loaded the 'receiving' code and then on the ST their was a small app that pumped a file across the printer port. Around that time I also hacked up a single cable that permitted me to transfer data from the C64's joystick port to the A8. This worked on a nibble basis but what hit or miss as to whether it aligned the initial one properly due to a lack of handshaking and that the code was very small as I had to hand enter the hex into the Action Replay cartridge on the C64! I'm not sure if I have that code laying around any more though. Quote Link to comment Share on other sites More sharing options...
gz0000 Posted April 29, 2016 Share Posted April 29, 2016 Please check http://www.atarimania.com/documents/Hackerbook-for-your-Atari-Computer.pdf 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 29, 2016 Author Share Posted April 29, 2016 Please check http://www.atarimania.com/documents/Hackerbook-for-your-Atari-Computer.pdf That's it on page 72 -- RS232 SERIAL INTERFACE Thank you ever so much After I get this up and working I'll be sure to post an ATR in this topic. - Michael Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 30, 2016 Author Share Posted April 30, 2016 (edited) I put in a pretty good amount of time first cutting and pasting the code out of the book, and then struggled with getting it to actually work without errors within the assembler environment (also had to fix some syntax errors in the original code). But at this point I have had some success with transferring characters from my Atari to a PC with a USB RS232 serial dongle. The only problem is the characters were garbled, but consistent. I think this is just a problem with inversion passing through the TTL-to-RS232 level converter, which I can easily rectify tomorrow. I'll probably add a couple of easily changable parameters to the source to accommodate this and also to select which joystick port you wish to use. As I said earlier, I'll post the final source file and executable when this is all cleaned up. At least now I am a happy camper . Thanks gz0000 for finding that for me - Michael Edited April 30, 2016 by mytekcontrols 3 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted April 30, 2016 Share Posted April 30, 2016 But at this point I have had some success with transferring characters from my Atari to a PC with a USB RS232 serial dongle. The only problem is the characters were garbled, but consistent. I think this is just a problem with inversion passing through the TTL-to-RS232 level converter, which I can easily rectify tomorrow. Native RS232 levels are "inverted", i.e. not just TTL levels scaled to +12V. However, there is a second problem here, and that is inconsistent timing. If you time your serial transfer by delay loops, then the Antic DMA will always steal cycles from the CPU, and depending on where you are on the screen, less or more cycles. It's probably getting more reliable if you're using WSYNC or VPOS for timing your loops. Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 30, 2016 Author Share Posted April 30, 2016 (edited) Native RS232 levels are "inverted", i.e. not just TTL levels scaled to +12V. However, there is a second problem here, and that is inconsistent timing. If you time your serial transfer by delay loops, then the Antic DMA will always steal cycles from the CPU, and depending on where you are on the screen, less or more cycles. It's probably getting more reliable if you're using WSYNC or VPOS for timing your loops. Yes I'm using a simple RS232 level shift inversion circuit utilizing a PNP transistor and voltage divider which derives its negative swing by stealing power from the idle TXD pin. So I'm probably seeing +5 to -9 transistions on the RXD pin. Since the original software routine was aimed at interfacing to a serial printer, it was meant to be done via direct TTL connection. And since I am seeing consistent, although incorrect characters showing up on my terminal, I'm assuming that I'll need to invert what is being sent. Or in other words if you refer to the code in that book which a link was previously provided to, there is an EOR with $FF (EOR #%11111111) being performed just prior to serially sending the byte -- this needs to be undone. As for timing, the code momentarily disables DMA while transmitting, so this allows the delay loops to remain consistent (at the expense of blanking the screen). For my application this is acceptable, since data will be sent only when a change has occurred, which is not often, and the data packet is small (4 characters). This however would not be very suitable for the Atari when used as a terminal. = Michael Edited April 30, 2016 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 30, 2016 Share Posted April 30, 2016 (edited) You'd need to disable VBlank NMIs too or at least do a SEI or set CRITIC nonzero. Edited April 30, 2016 by Rybags Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 30, 2016 Author Share Posted April 30, 2016 You'd need to disable VBlank NMIs too or at least do a SEI or set CRITIC nonzero. Yes it appears that the code I am working with does all of that. 0910 ; DISABLE INTERRUPTS 0920 ; 0930 SEI 0940 LDA #0 0950 STA NMIEN 0960 STA DMACT - Michael Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 30, 2016 Author Share Posted April 30, 2016 (edited) Actually the character data inversion is necessary within the software routine, and after passing through the RS232 hardware, should be correct. However it isn't for some strange reason. So for example if I send an 'A' (ASCII 65) I'll get an '_' (ASCII 95) at the terminal. If I send an 'B' (ASCII 66) I get an '/' (ASCII 47) at the terminal. I can not see the pattern. But whatever is happening the communication is consistent, because I can send 10 or more characters in a row and although it doesn't match what I send, it does keep reproducing the same exact wrong character on the terminal. Here's the code for the RS232 character send... 0690 PUTBYTE 0700 PHA 0710 CMP #EOL 0720 BNE NOEOL 0730 ; 0740 ; IF EOL GIVE CRLF TO DEVICE 0750 ; 0760 LDA #CR 0770 JSR SEROUT 0780 LDA #LF 0790 NOEOL 0800 JSR SEROUT 0810 PLA 0820 LDY #1 0830 RTS 0840 ; 0850 ; SERIALOUT - FIRST INVERT DATA 0860 ; 0870 SEROUT 0880 EOR #$FF 0890 STA BUFFER 0900 ; 0910 ; DISABLE INTERRUPTS 0920 ; 0930 SEI 0940 LDA #0 0950 STA NMIEN 0960 STA DMACTL 0970 ; 0980 ; SEND STARTBIT 0990 ; 1000 LDA #1 1010 STA PORTA 1020 JSR BITWAIT 1030 ; 1040 ; SEND CHARACTER DATA 1050 ; 1060 LDY #8 1070 STY COUNT 1080 ; 1090 SENDBYTE 1100 LDA BUFFER 1110 STA PORTA 1130 ROR BUFFER 1140 JSR BITWAIT 1150 DEC COUNT 1160 BNE SENDBYTE 1170 ; 1180 ; SEND STOPBIT 1190 ; 1200 LDA #0 1210 STA PORTA 1220 JSR BITWAIT 1240 ; 1250 ; ENABLE INTERRUPTS 1260 ; 1270 LDA #$22 1280 STA DMACTL 1290 LDA #$FF 1300 STA NMIEN 1310 CLI 1320 RTS ;DONE 1330 ; 1340 ; THE BIT TIMING ROUTINE 1350 ; FOR AN EXACT BAUDRATE 1360 ; 1370 BITWAIT 1380 LDX #K 1390 LOOPK 1400 LDY #L 1410 LOOPL 1420 DEY 1430 BNE LOOPL 1440 DEX 1450 BNE LOOPK 1460 RTS Anyone see the problem? - Michael Here is the entire R: Handler Routine: JOY2RS.ASM Edited April 30, 2016 by mytekcontrols Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted April 30, 2016 Share Posted April 30, 2016 All your transmitted characters end with 1111 in binary. This means that the baud rate at the receiver does not match the baud rate of the sender. The sender is transmitting bits too fast so the receiver sees the stop bits (idle line) as the sequence of one-bits. Please check whether you calibrated your delay loop correctly. Quote Link to comment Share on other sites More sharing options...
+mytek Posted April 30, 2016 Author Share Posted April 30, 2016 All your transmitted characters end with 1111 in binary. This means that the baud rate at the receiver does not match the baud rate of the sender. The sender is transmitting bits too fast so the receiver sees the stop bits (idle line) as the sequence of one-bits. Please check whether you calibrated your delay loop correctly. Good observation The loops are what they were in the original code (not to say they were correct, since I found a few other faults already). I'll play around with it and see what happens. Thanks - Michael 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.