Interrupts returning to wrong address

[floobydust]

Try using ExtraPutty as a terminal program.... I use that for Windows... I think it might be available for Linux as well.... on OSX I user Serial.

Sending a Break to Micromon will reset the ACIA, clear the buffer pointers and display the CPU registers.

EDIT: Try this: https://numato.com/blog/how-to-install-putty-on-linux/

[sci4me]

floobydust wrote:

Interrupts are enabled for the 6551 Receive, which is working on the W65C51. The transmit interrupt is not enabled by default, you can look at the init code and see how the ACIA is setup. The transmit interrupt is enabled by CHROUT... it takes the character in the A reg, checks for space in the 128-byte FIFO buffer, puts it into the buffer, updates the buffer pointers, then turns on the transmit interrupt and returns.

The BIOS interrupt service routine, gets the interrupt, checks for receive or transmit flags and branches to a routine to handle it. In any case, the XMTCHR routine is the handler for the transmit interrupt... it checks for an available character in the FIFO buffer, sends it to the 6551, updates the pointers and returns. Note that if the buffer count is empty, it turns off the transmit interrupt and returns.

So... if Micromon is working and you can execute the various commands, then your hardware appears to be functioning... as all of the routines use the stack through JSR/RTS and the Interrupt handler is being called everytime you send a character from your terminal program to the 6551... which is the receive interrupt handler.

Well I can tell that Micromon is working to some extent, but, see EDIT3 in my last post; might have posted that as you were typing this

I also just tried disabling and re-enabling interrupts at the beginning and end of CHROUT to no avail. Here is what I changed CHROUT to:

Code: Select all

CHROUT          SEI
                STA SIODAT
                PHX
                LDX #$68
OWLP            DEX
                BNE OWLP
                PLX
                CLI
                RTS

That is nearly identical to the routine I've been using, other than the SEI and CLI. Also, in this routine I am writing to the ACIA first and then doing the delay; in the routine I've been using, I've (questionably) been doing the delay before writing to the ACIA.
So, I'll try writing to the ACIA after the delay instead, but I don't see why that would fix the problem I'm having.

This particular issue is frustrating because I can't really tell if it's the hardware/software or if it's that the serial port on my PC is messed up (which I'm 99% sure it is...)

EDIT:

floobydust wrote:

Try using ExtraPutty as a terminal program.... I use that for Windows... I think it might be available for Linux as well.... on OSX I user Serial.

Sending a Break to Micromon will reset the ACIA, clear the buffer pointers and display the CPU registers.

EDIT: Try this: https://numato.com/blog/how-to-install-putty-on-linux/

Alright, I'll go give that a shot.

[floobydust]

Okay, first... there's no need to disable/re-enable interrupts for the CHROUT routine... you also send the character to the ACIA, then execute the delay loop. This ensures that you won't attempt to send another character (by calling CHROUT) until the existing one has completed sending.

If you're still having a problem, you need to look at the handshake lines on your serial port setup. There are 7 signal lines from the 6551... they all need to be connected to something... Try this:
1- Connect RTS to CTS on the 6551
2- Connect DCD, DTR and DSR on the 6551 together (all 3 together)
3- Do the same on the serial port for your computer if those lines are exposed
4- RxD to Txd and Txd to Rxd between devices plus ground.

[sci4me]

floobydust wrote:

Okay, first... there's no need to disable/re-enable interrupts for the CHROUT routine... you also send the character to the ACIA, then execute the delay loop. This ensures that you won't attempt to send another character (by calling CHROUT) until the existing one has completed sending.

If you're still having a problem, you need to look at the handshake lines on your serial port setup. There are 7 signal lines from the 6551... they all need to be connected to something... Try this:
1- Connect RTS to CTS on the 6551
2- Connect DCD, DTR and DSR on the 6551 together (all 3 together)
3- Do the same on the serial port for your computer if those lines are exposed
4- RxD to Txd and Txd to Rxd between devices plus ground.

Well, I do have it working at this point; it appears that the (perceived, by myself) crappiness of serial ports on Linux is the problem. So far I have only been able to get into the monitor by using a program called dterm I just happened to find during research regarding serial ports on Linux. However, I'm not 100% sure it's _fully_ working yet.

I'm experiencing "weirdness" (for want of better phrasing..) with the monitor interface. It almost looks like it only ever responds to a single keystroke...

I can't tell if the weirdness I'm experiencing is because of the serial port thing (i.e. software issues on my PC), the program I'm using (dterm), the software on the SBC, or the hardware itself. I highly doubt it's the software on the SBC though; clearly it's not Microcom's issue. And, I suspect it's not related to the few minor changes I had to make to get it working on my machine. I really think I'm still just having issues with software on my PC. Either that or it's the CTS/RTS thing.

So, with that, if I can't get it working more properly by just messing around with things, I'll take the ACIA out of its socket and try out your suggestion.

EDIT: Also, regarding #3 of your suggestion, I am using a USB to UART cable that only provides GND, +5V, RX, and TX.

EDIT2: Okay, it's working 100%! At least, as far as I can tell. I am able to interact with it, without the "weirdness", and do things like print out what's in memory. Not sure how many things I can really do with it without having other software on the computer (suggestions are welcome!) but, hey! This is good.
And here's the kicker: I didn't even remove a single chip.

EDIT3: By the way, guilty confession: this is the first time I think I've ever actually used a monitor program of any kind. Gotta say, as minimal as it is, it's pretty neat! Makes me think writing my own should definitely be on my agenda.

[floobydust]

Glad to hear it's working! Congrats are in order.

If you want to try something more functional, grab the software for my SBC-1... very rich function for a Monitor, BIOS also supports a 6522 VIA for timers and ports.... maintains a RTC and accurate time delays as well... plus a full disassembler for the W65C02 plus plus...

Also, here's the FTDI device I prefer: https://www.mouser.com/datasheet/2/163/ ... -15654.pdf

And... the C02 Pocket SBC has a more updated monitor... but a separate BIOS, which only supports the NXP SCC2691. You can get some ideas on the Monitor functions and operations by looking at the source... I usually comment my code pretty well.

Have fun!

[sci4me]

floobydust wrote:

Glad to hear it's working! Congrats are in order.

If you want to try something more functional, grab the software for my SBC-1... very rich function for a Monitor, BIOS also supports a 6522 VIA for timers and ports.... maintains a RTC and accurate time delays as well... plus a full disassembler for the W65C02 plus plus...

Also, here's the FTDI device I prefer: https://www.mouser.com/datasheet/2/163/ ... -15654.pdf

And... the C02 Pocket SBC has a more updated monitor... but a separate BIOS, which only supports the NXP SCC2691. You can get some ideas on the Monitor functions and operations by looking at the source... I usually comment my code pretty well.

Have fun!

Thanks! Although I'm not quite ready to jump for joy; it's disconcerting to me that this "interrupt issue" appears to have "magically disappeared". Granted, such a thing isn't impossible; could be as simple as moving the hardware causing some bad connection to behave better, or something. Which is why, like I said, it's disconcerting.
Beyond that though, I am quite happy!

I'll absolutely try out your SBC-1 software! Should be fun!

If this thread goes on long enough while the issue has seemingly disappeared, we can always call it and I can make a new thread should the issue reappear. But, like it said, it just rubs me the wrong way...

EDIT: Almost totally forgot to ask... uh, in Micromon, when I use the R command to print out the registers, they're all 0? If I set, for example, X to a value, it shows up correctly; I'm just worried about the PC being `0000`...

EDIT2: Just noticed that if I hit Ctrl+Pause(Break?) on my keyboard, in putty, it 1. prints a blank line (well, blank excluding the monitors prompt) and 2. the registers have values when I print them with R, including PC. Hmh. Break is supposed to display the registers? Perhaps Ctrl+Pause isn't sending a break like I thought?

EDIT3: The C02Monitor program from your SBC-1 project is working too! And the behavior of the R command is the same as it was with Micromon.

[Dr Jefyll]

sci4me wrote:

this "interrupt issue" appears to have "magically disappeared". Granted, such a thing isn't impossible; could be as simple as moving the hardware causing some bad connection to behave better

Yes, I think that's exactly what's happening. I suggest you proceed by inspecting all the solder joints in case there are any that're marginal... or that perhaps never got soldered at all! Also check that all IC pins do in fact engage their sockets, rather than having gotten curled underneath or otherwise gone astray.

[floobydust]

So, for both Micromon and the C02Monitor, the R (register) command works by referencing locations in Page Zero. You can see this looking at the code. Initially, they are zero'd out during startup. If you force a break from the terminal, that will cause a break condition and the monitor will capture all register and program counter information and accurately display it. Also should your code hit a BRK instruction, the information will be captured and displayed. The same happens if you use the G command (go run code at a specific location)... on return, the details are captured and can be displayed. in short, if there's nothing going on to warrant capturing the register and PC data, there's nothing to display.

NOTE: in the C02Monitor, the BRK condition will also use the disassembler routine to display the code at the BRK location so you can see the instruction that was being executed.... being a BRK of course and the BRK signature byte. Forcing a control break from the terminal will also cause a capture of the current CPU status (registers and PC) which can then be displayed via the R command. Go ahead and try it... punch in some code, the use the G command to execute it, when it it returns to the monitor, issue the R command and you get the details. You can also load specific registers and then use the G command to call a routine which uses register contents to perform a specific function.

Hope this helps explain the workings of the Monitor a bit more.

[BigEd]

Great to hear that things are now working.

I would ask, if the discussion is going to move away from "interrupts returning to wrong address", it would be good to see those new discussions in new threads.