Bit-Bang Serial (RS232) Output via Joystick Pin (PORTA-Bit 0)

[+mytek]

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

 

[+David_P]

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.

[Rybags]

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

[+mytek]

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

[+David_P]

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 RIGHT

DATIN EQU $20
DATOUT EQU $80
COMAND EQU $40

;EQUATES

PORTA EQU $D300
PACTL EQU $D302
NMIEN EQU $D40E
SDMCTL EQU $22F
DMACTL EQU $D400

;PROGRAM ORIGIN

ORG $4000

;TURN OFF SCREEN TO GET ACCURATE TIMING

START
LDA #0
STA NMIEN
STA SDMCTL
STA DMACTL

;DISABLE OUTPUT

DISOUT
LDA #$38
STA PACTL ;DIRECTION
LDA #$00
STA PORTA ;DISABLE OUTPUT TO DATA IN LINE
LDA #$3C
STA PACTL

;RECEIVE COMMAND FRAME

COMFRM
BIT PORTA
BVC COMFRM ;WAIT FOR COMMAND TO GO HIGH
COM1
BIT PORTA
BVS COM1 ;WAIT FOR COMMAND TO GO LOW

LDY #4
JSR RXF192 ;RECEIVE COMMAND FRAME
BCS COMFRM ;IF ERROR

LDY #4
JSR CHKSUM
BNE COMFRM ;IF BAD CHECKSUM
LDA FRAME+4
CMP #$80
BNE COMFRM ;IF NOT THIS DEVICE

;ENABLE OUTPUT

LDA #$20
STA PORTA ;PRECONDITION OUTPUT
LDA #$38
STA PACTL ;DIRECTION
LDA #$20
STA PORTA ;ENABLE OUTPUT TO DATA IN LINE
LDA #$3C
STA PACTL
LDA #$20
STA PORTA

;CHECK COMMAND

COM2
BIT PORTA
BVC COM2 ;WAIT FOR COMMAND TO GO HIGH
LDA FRAME+3
CMP #$52
BEQ GET ;IF GET COMMAND
CMP #$50
BEQ PUT ;IF PUT COMMAND

;UNRECOGNIZED COMMAND, SEND NAK

NAK
LDA #'N'
STA FRAME
LDY #0
JSR TXF192
JMP DISOUT

;PROCESS GET COMMAND (WE SEND)

GET
LDA #'H'
STA FRAME
LDY #0
JSR TXF192 ;HIGH SPEED ACK
BCS GET1 ;IF ERROR

JSR D1000 ;DELAY 1000 US

LDA #'C'
STA FRAME
LDY #0
JSR TXF384 ;SEND COMPLETE
BCS GET1 ;IF ERROR

LDY #128
JSR CHKSUM ;CALCULATE CHECKSUM
LDY #128
JSR TXF384 ;SEND THE FRAME
GET1
JMP DISOUT

;PROCESS PUT COMMAND (WE RECEIVE)

PUT
LDA #'H'
STA FRAME
LDY #0
JSR TXF192 ;SEND HIGH SPEED ACK
BCS PUT1 ;IF ERROR

LDY #128
JSR RXF384 ;RECEIVE THE FRAME
BCS PUT1 ;IF ERROR, DO NOTHING

JSR D1000 ;DELAY 1000 US

LDY #128
JSR CHKSUM
BNE PUT2 ;IF CHECKSUM ERROR

LDA #'A'
STA FRAME
LDY #0
JSR TXF384 ;SEND ACK
BCS PUT1 ;IF ERROR

JSR D1000 ;DELAY 1000 US

LDA #'C'
PUT3
STA FRAME
LDY #0
JSR TXF384 ;SEND COMPLETE
PUT1
JMP DISOUT ;DONE

PUT2
LDA #'N'
JMP PUT3 ;SEND NAK, RETURN
SUBTTL 'TRANSMIT/RECEIVE SUBROUTINES'

ORG $6000

;RECEIVE A COMMAND FRAME AT 19200 BAUD
;ON ENTRY, FRAME SIZE-1 IN Y (<=128)
;RETURNS CS IF ERROR
RXF192
BIT PORTA
BPL RXSB1 ;IF START BIT DETECTED
BVC RXF192 ;IF COMMAND LOW
RXSB2
SEC ;ERROR
RTS
RXSB1
LDA #$80 ;INITIAL BYTE
LDX #9
RXSB4
DEX
BNE RXSB4 ;DELAY 46 CYCLES
RXSB5
LDX #13
RXSB3
DEX
BNE RXSB3
NOP ;DELAY 68 CYCLES
PHA
LDA PORTA
ASL A ;MOVE BIT INTO CARRY
PLA
ROR A ;MOVE BIT INTO BYTE
BCC RXSB5 ;IF NOT DONE WITH 8 BITS
STA FRAME,Y
LDX #12
RXSB6
DEX
BNE RXSB6
NOP
NOP
NOP
NOP ;DELAY 69 CYCLES
LDX PORTA ;GET THE STOP BIT
BPL RXSB2 ;IF IT'S INCORRECT
DEY
BPL RXF192 ;IF NOT DONE WITH FRAME
CLC ;SUCCESS
RTS


;RECEIVE A DATA FRAME AT 38400 BAUD
;ON ENTRY, FRAME SIZE-1 IN Y (<=128)
;RETURNS CS IF ERROR
RXF384
BIT PORTA
BPL RXFB1 ;IF START BIT DETECTED
BVS RXF384 ;IF COMMAND HIGH
RXFB2
SEC ;ERROR
RTS
RXFB1
LDA #$80 ;INITIAL BYTE
LDX #3
RXFB4
DEX
BNE RXFB4
NOP
NOP
NOP
NOP ;DELAY 24 CYCLES
RXFB5
LDX #4
RXFB3
DEX
BNE RXFB3
NOP
NOP ;DELAY 25 CYCLES
PHA
LDA PORTA
ASL A ;MOVE BIT INTO CARRY
PLA
ROR A ;MOVE BIT INTO BYTE
BCC RXFB5 ;IF NOT DONE WITH 8 BITS
STA FRAME,Y
LDX #5
RXFB6
DEX
BNE RXFB6 ;DELAY 26 CYCLES
LDX PORTA ;GET THE STOP BIT
BPL RXFB2 ;IF IT'S INCORRECT
DEY
BPL RXF384 ;IF NOT DONE WITH FRAME
CLC ;SUCCESS
RTS

ASSERT *<$6101
ORG $6100

;TRANSMIT A FRAME AT 19200 BAUD
;ON ENTRY, FRAME SIZE-1 IN Y
;RETURNS CS IF ERROR
TXF192
BIT PORTA
BVC TXSB4 ;IF COMMAND LOW
LDX #0
STX PORTA ;WRITE START BIT
SEC
LDA FRAME,Y
NOP ;DELAY 2 CYCLES
TXSB1
LDX #11
TXSB2
DEX
BNE TXSB2
NOP
NOP
NOP ;DELAY 62 CYCLES
ROR A
PHA
ROR A
ROR A
ROR A
STA PORTA ;WRITE BIT
PLA
CLC
BNE TXSB1 ;IF NOT DONE
LDX #11
TXSB3
DEX
BNE TXSB3
NOP
NOP
NOP ;DELAY 62 CYCLES
DEY
BPL TXF192 ;IF NOT DONE WITH FRAME
CLC
RTS
TXSB4
SEC
RTS


;TRANSMIT A FRAME AT 38400 BAUD
;ON ENTRY, FRAME SIZE-1 IN Y
;RETURNS CS IF ERROR
TXF384
BIT PORTA
BVC TXFB4 ;IF COMMAND LOW
LDX #0
STX PORTA ;WRITE START BIT
SEC
LDA FRAME,Y
NOP ;DELAY 2 CYCLES
TXFB1
LDX #2
TXFB2
DEX
BNE TXFB2
NOP
NOP
NOP
NOP ;DELAY 19 CYCLES
ROR A
PHA
ROR A
ROR A
ROR A
STA PORTA ;WRITE BIT
PLA
CLC
BNE TXFB1 ;IF NOT DONE
LDX #2
TXFB3
DEX
BNE TXFB3
NOP
NOP
NOP
NOP ;DELAY 19 CYCLES
DEY
BPL TXF384 ;IF NOT DONE WITH FRAME
CLC
RTS
TXFB4
SEC
RTS

ASSERT *<$6201 ;BYTE I/O ROUTINES MUST BE WITHIN PAGE
ORG $6200

FRAME DS 256
SUBTTL 'SUBROUTINES'

;CALCULATE CHECKSUM
;ON ENTRY, FRAME SIZE-1 IN Y
;ON EXIT, CHECKSUM IN FRAME, ZS IF CHECKSUM WAS CORRECT
CHKSUM
LDA #0
CHKS1
CLC
ADC FRAME,Y
ADC #0
DEY
BNE CHKS1
LDX FRAME
STA FRAME
CPX FRAME
RTS


;DELAY 1000 US
D1000
LDX #236
D1001
NOP
DEX
BNE D1001
RTS


END START

[Rybags]

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.

[+mytek]

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

[ricortes]

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.

[+mytek]

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

[Brentarian]

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.

[+mytek]

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

[Rybags]

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.

[Joey Z]

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

[+mytek]

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

[Wrathchild]

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.

[gz0000]

Please check

 

http://www.atarimania.com/documents/Hackerbook-for-your-Atari-Computer.pdf

[+mytek]

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

[+mytek]

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

[thorfdbg]

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.

[+mytek]

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

[Rybags]

You'd need to disable VBlank NMIs too or at least do a SEI or set CRITIC nonzero.

Edited April 30, 2016 by Rybags

[+mytek]

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

[+mytek]

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

[thorfdbg]

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.

[+mytek]

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