Interrupts returning to wrong address

[sci4me]

floobydust wrote:

It can be difficult to debug a new system... especially when you have a new hardware design and are writing the software for it. When something doesn't work, you need to be able to determine if the hardware or software is the problem. In some cases, it helps to have some known simple software that can run on a minimal hardware base. Just as long as you have the minimal required hardware and configure the I/O in the software, it "should" work. If not, then you can be pretty certain that you have a hardware problem.

Some years ago, I cobbled a minimal BIOS/Monitor together for basic testing of a 65C02, a (working) 65(c)51 and at least 2KB of ROM and at least 2KB of RAM. ROM must be addressed at the top of memory and RAM at the bottom of memory. Some others on the forum have used this code to verify that the base hardware is functioning. In short, if this code won't work, you have a hardware problem.

I'll suggest that Sci4me grab my Micromon code from my Github page. All that's needed for his system would be to yank out the chips that aren't being used (65C22s, latches, LED drivers, etc.) and ensure the base I/O address for the 6551 is changed to his and ensure the IRQ line from the 6551 is connected to the IRQ line of the CPU.

Second, which is likely to be a problem, is... I think he's using a WDC W65C51 ACIA... which has the Xmit bug, so no proper code will run it for transmit. If this is the case, then I would likely suggest he secure an older Rockwell R6551 (or R65C51) for testing. Short of this, the only other option would be to use a delay routine for sending characters.

I am looking into trying out Micromon currently. Quick (maybe dumb) question: what assembler is it meant to be assembled with? I have been using the cc65 toolchain, but can certainly download something else.

As for the ACIA, yes, I am using a WDC 65C51, and have been using a delay loop for transmission without trouble, thus far. This may be controversial, but I set a requirement for my project that all the parts used must still be in production today (not to mention, available through common distributors such as DigiKey, Mouser, etc.) So therefore, I'm using the WDC variants of the 65Cxx parts.

EDIT: Also, here's a crucial detail I really should've mentioned sooner: I am not using 'U15' (as in the schematic) currently; I simply have a jumper wire between pins 1 and 4. The idea with 'U15' was to be able to use more of the I/O address space, later on. But, when I insert that chip, the computer ceases to function, probably because I made a dumb mistake in the design; I haven't even bothered to figure out why yet, since I don't actually need that chip in this version of the design at all.

Finally, here's a picture of what I have right now:

[floobydust]

Nice looking board BTW... I used WDC Tools to assemble/link and generate a S19 S-Record which I can burn to EEPROM or download to my current SBC (C02Monitor supports Xmodem CRC-16 and automagically processes S-Record format). I don't think it should be very difficult to use CC65, might have to change a few directives perhaps. Then again, WDC Tools is a free download now.

Part selection and choices.... I also like to be able use parts which is still in production. I'm the one that discovered the Xmit bug with the WDC W65C51N when they first came available. It also turns out that you need to add a 1-megohm resistor in parallel with the crystal to get it to oscillate. Some earlier WDC and some other 6551 variants had the resistor internal. Also, check your codes on the W65C51 to make sure it's the same one.... as I don't see the resistor in your circuit.

Interesting read here: viewtopic.php?f=4&t=2543&start=0#p26524

You will have to modify the transmit section in Micromon to get it working with the ACIA... I've since moved to a NXP UART and am much happier.

I noticed U15 in your schematic... it looks like it's wired wrong.... you have an address line going to an input on each decoder, but you're only using one decoder. This is likely the cause, as the select is not being resolved with the two address lines.

[sci4me]

floobydust wrote:

Nice looking board BTW... I used WDC Tools to assemble/link and generate a S19 S-Record which I can burn to EEPROM or download to my current SBC (C02Monitor supports Xmodem CRC-16 and automagically processes S-Record format). I don't think it should be very difficult to use CC65, might have to change a few directives perhaps. Then again, WDC Tools is a free download now.

Part selection and choices.... I also like to be able use parts which is still in production. I'm the one that discovered the Xmit bug with the WDC W65C51N when they first came available. It also turns out that you need to add a 1-megohm resistor in parallel with the crystal to get it to oscillate. Some earlier WDC and some other 6551 variants had the resistor internal. Also, check your codes on the W65C51 to make sure it's the same one.... as I don't see the resistor in your circuit.

Interesting read here: viewtopic.php?f=4&t=2543&start=0#p26524

You will have to modify the transmit section in Micromon to get it working with the ACIA... I've since moved to a NXP UART and am much happier.

I noticed U15 in your schematic... it looks like it's wired wrong.... you have an address line going to an input on each decoder, but you're only using one decoder. This is likely the cause, as the select is not being resolved with the two address lines.

Thanks! It's the most advanced board I've laid out and routed by hand so I am pretty thrilled that it's working, generally.
I will look into the WDC tool.

Also, yeah, I ran into that same resistor issue; forgot to add it to the design and had to solder it onto the back of the board

As for the U15 thing, you said I have one address line going into one of the inputs of each decoder... but, when I look at in the schematic, it says the inputs are `1A` and `2A`. Is the footprint wrong? Or did I misinterpret it? Will go look at the datasheet...

Anywho, I'm going to go mess with Micromon and see if I can get that up and running. Will post back if I have trouble or anything else comes up.

EDIT: Okay, forgive me, more 'dumb questions'... I have used the WDC tool to assemble MicroMon, but it's only 1880 bytes as a binary file. If I want to write this to my EEPROM, I will need a 32k file. What would be the correct way to handle this? I see there are .ORG statements in the code for things like the h/w vectors... but if I were to write this to the ROM as is, the h/w vectors wouldn't contain anything (from MicroMon).

EDIT2: Regarding U15, I declare that the footprint I used is misleading That said, clearly I should've noticed this from the datasheet. DOH!

[floobydust]

U15... there are two 2-4 decoders, you're only a single output from one of them (decoder 1). You have A3 going to 1A (A input for decoder 1) and A4 going to 2A (A input for decoder 2). You have the second inputs (1B and 2B) for each decoder going to ground.

As for the output file... The ROM code is less than 2KB in all. I generate S19 format S-Record output and then load that into my Dataman Programmer. The S-Record file has the actual address data for the location, but a 32KB offset is still required (32KB EEPROM addressed at $8000). What programmer are you using to load the EEPROM?

The vectors are located at $0300 and are loaded during the init routine from ROM to RAM. They are soft vectors which can be modified. The actual Micromon code starts at $F800, but note that my hardware has the I/O located at $FE00, so nothing code wise is from $FE00 - $FEFF.

[sci4me]

floobydust wrote:

U15... there are two 2-4 decoders, you're only a single output from one of them (decoder 1). You have A3 going to 1A (A input for decoder 1) and A4 going to 2A (A input for decoder 2). You have the second inputs (1B and 2B) for each decoder going to ground.

As for the output file... The ROM code is less than 2KB in all. I generate S19 format S-Record output and then load that into my Dataman Programmer. The S-Record file has the actual address data for the location, but a 32KB offset is still required (32KB EEPROM addressed at $8000). What programmer are you using to load the EEPROM?

The vectors are located at $0300 and are loaded during the init routine from ROM to RAM. They are soft vectors which can be modified. The actual Micromon code starts at $F800, but note that my hardware has the I/O located at $FE00, so nothing code wise is from $FE00 - $FEFF.

Ah, ninja'd me on U15

I am using a MiniPro TL866 II Plus universal programmer to program my EEPROM. I also have a simple XModem CRC-16 loader (https://github.com/sci4me/xboot) that has been working well for me. It just expects the first two bytes to be the load address and the second two bytes to be the run address, all bytes following are written starting at the load address.

I don't have any experience with (or knowledge of, frankly) the S19 S-Record format...

As for the I/O location, unless I missed something, all I have to do to change that is change the one place where it's defined as IOPAGE in your source code.. right? Along with removing the +$20 for SIOBase since my ACIA is at the very start of my I/O page.

[floobydust]

For some info on Motorola S Record files, check this: http://srecord.sourceforge.net/man/man5 ... orola.html

Does the software for your programmer accept S-Record format? I would expect the software to support multiple file types, but I've not used it, so I don't know.

Also, when you say binary file.... which file type did you have WDC Tools create?

And yes... you just change the I/O address start and remove the $20 offset as your 6551 starts at the beginning of the I/O address.

EDIT: One last thing... I always use RTS/CTS handshaking on the UART/ACIA interface. Micromon is configured this way as well. It's what was generally referred to as a 5-wire interface. It's also useful for doing data transfers. I have my own Xmodem code and the CRC-16 is calculated in realtime for each block of data received, i.e., I don't use the two lookup tables for CRC-16 calculation. Having the RTS/CTS handshaking, you won't timeout if you happen to run on a very slow processor clock.

[sci4me]

floobydust wrote:

For some info on Motorola S Record files, check this: http://srecord.sourceforge.net/man/man5 ... orola.html

Does the software for your programmer accept S-Record format? I would expect the software to support multiple file types, but I've not used it, so I don't know.

Also, when you say binary file.... which file type did you have WDC Tools create?

And yes... you just change the I/O address start and remove the $20 offset as your 6551 starts at the beginning of the I/O address.

EDIT: One last thing... I always use RTS/CTS handshaking on the UART/ACIA interface. Micromon is configured this way as well. It's what was generally referred to as a 5-wire interface. It's also useful for doing data transfers. I have my own Xmodem code and the CRC-16 is calculated in realtime for each block of data received, i.e., I don't use the two lookup tables for CRC-16 calculation. Having the RTS/CTS handshaking, you won't timeout if you happen to run on a very slow processor clock.

Thanks for the link, I'll definitely take a look at that. This probably isn't the place for this (and I can probably find the answer elsewhere) but it did get me wondering why people use things like S-Record or Intel Hex, rather than a plain binary file. The answers that come to mind would be for chunking the data (and possibly adding CRCs, etc.). But, like I said, I'll dig into this in a little bit.

When I said binary file, uh, well, I didn't tell the WDC tool what type of file to output, so I guess it was just the default. I assume it was just a plain binary file containing the raw machine code and data. This is what I have been using for all of my development.

I am using an open source program, confusingly called `minipro`. This one: https://gitlab.com/DavidGriffith/minipro/
I just checked and, it looks like it actually does support S-Record. So, I'll just tell the WDC assembler to output an S-Record file and try that.

Finally, regarding CTS and RTS, I had originally wanted to use these signals actually, but in the interest of rushing to rev1 of the board, I opted to just use plain-old RX and TX. But I _definitely_ want to use CTS and RTS in a future revision.
It was also convenient not to use them as I already had a USB to UART that only provides RX and TX, but these converters aren't really that expensive and I'm pretty sure I've seen them include CTS and RTS.
That all being said, I do need to learn more about how the 5-wire interface works/is used/is implemented. But, that's something for another day.

[floobydust]

I prefer S-Record format for programming the EEPROM... you can have holes between pieces of data and the decoding of the record handles it transparently, e.g., my I/O page ($FE00) is near the end of the EEPROM, and the S-Record file defines data from $F800 to $FDFF, skips over $FE00 - $FEFF and then defines data from $FF00 to $FFFF. However, note that when using the S-Record format, you need to tell your software about an offset to where the EEPROM is located. If you have a 32kb EEPROM, it's physical addressable space is from $0000 to $7FFF, so you need to give it an offset of $8000 so it's addressable space (in use) is from $8000 to $FFFF.

There's a file in the Micromon code with a .WDC extension... this is the config file that TIDE uses... it also defines the assembler/linker options and the output format. TIDE is pretty buggy... and I think WDC no longer include it, but I'm not sure. I still use it, as it does what I need and I don't need any command line stuff or batch files.

[sci4me]

floobydust wrote:

However, note that when using the S-Record format, you need to tell your software about an offset to where the EEPROM is located. If you have a 32kb EEPROM, it's physical addressable space is from $0000 to $7FFF, so you need to give it an offset of $8000 so it's addressable space (in use) is from $8000 to $FFFF.

Well that would probably explain why nothing happened when I tried to boot it for the first time

When you say I need to tell the software about the offset, which software? I looked at the help options for WDC02AS and WDCLN but didn't see anything about an offset.

As for TIDE, it was included in the package I downloaded, however it appears not to work correctly when running in Wine on Linux, but WDC02AS and WDCLN work just fine. Fair enough, I suppose.

EDIT: Ah, the -C flag? To WDCLN...

[floobydust]

Software... the offset is for the software that's programming the EEPROM. Note that the programmer software only knows that you have a 32KB EEPROM... it has no idea where you will have it addressed in a circuit. Furthermore, the assembler/linker is generating code to be located in addresses from $F800 and up (defined in the S-Record file), which doesn't directly correspond to the 32KB EEPROM range. That's why the programmer software needs to know about the offset... so it considers the addressable region for the EEPROM to start at $8000. Hope this clears it up.

Wine has been around a long time.. worked with the earliest versions

I run everything on OSX... but use VMware Fusion and have a Windows 7 VM running... I use it for WDC Tools, WinCUPL, the Dataman programmer software and ExpressPCB.

[sci4me]

floobydust wrote:

Software... the offset is for the software that's programming the EEPROM. Note that the programmer software only knows that you have a 32KB EEPROM... it has no idea where you will have it addressed in a circuit. Furthermore, the assembler/linker is generating code to be located in addresses from $F800 and up (defined in the S-Record file), which doesn't directly correspond to the 32KB EEPROM range. That's why the programmer software needs to know about the offset... so it considers the addressable region for the EEPROM to start at $8000. Hope this clears it up.

Wine has been around a long time.. worked with the earliest versions

I run everything on OSX... but use VMware Fusion and have a Windows 7 VM running... I use it for WDC Tools, WinCUPL, the Dataman programmer software and ExpressPCB.

Ohhh okay, I just got it. I had tried using the -C flag and got an error: "Attempt to locate section `CODE' more than once!". After Googling this, I stumbled upon another thread or two where you've explained this exact concept to others before. At first I was confused but after reading what you just said, it clicked. The S-Record file is telling the programmer to write to, in this case, $F800 and up, but the programmer knows that it has an EEPROM which actually only goes from $0000 to $7FFF. So, what we're doing by telling the programmer about the offset is essentially saying that the start address of the ROM is $8000 and it goes up to $FFFF. Did I get that right? Seems to make sense.

So I don't need the -C flag to WDCLN, I simply need to tell the programmer this offset. This may be a problem with the programmer software I'm using; I don't see any way to specify this offset in the CLI help it provides... but I may be able to use the "official" software for the TL866 (which, unfortunately, comes from one of the sketchiest-looking official websites I've ever seen).

Will spend some time trying to do this and post back if I run into anything I can't figure out or something comes up. Thanks for your help so far!

[sci4me]

Okay, I have gotten Micromon to boot! However, unsurprisingly, adding a delay loop to CHROUT wasn't enough to get serial output. Does Micromon only try to transmit on the serial port when the transmit interrupt occurs?

For that matter, does the transmit interrupt ever occur when using the WDC 65C51? I only vaguely recall the bug... I thought it was that some status bit never got reset, or something along those lines.

Or am I not getting output because of the CTS/RTS usage?

I'm guessing that I'd have to make some more significant modifications to your source code to get it working?

[floobydust]

sci4me wrote:

Okay, I have gotten Micromon to boot! However, unsurprisingly, adding a delay loop to CHROUT wasn't enough to get serial output. Does Micromon only try to transmit on the serial port when the transmit interrupt occurs?

For that matter, does the transmit interrupt ever occur when using the WDC 65C51? I only vaguely recall the bug... I thought it was that some status bit never got reset, or something along those lines.

I'm guessing that I'd have to make some more significant modifications to your source code to get it working?

I also found the XGecu software.... terrible stuff, but finally figured out how to use it and get code into the ROM image....

So, the CHROUT routine in Micromon simply puts a character into the transmit buffer, then turns on the transmit interrupt. This won't work on the bad chip. Modify CHROUT so it just send the character to the W65C51, then execute the delay routine to kill enough time for it to be sent. Don't turn on the Xmit interrupt, as that will hose it up.

Code: Select all

CHROUT          PHY                     ;save Y reg
OUTCH           LDY     OCNT            ;get character output count in buffer
                BMI     OUTCH           ;check against limit, loop back if full
                LDY     OTAIL           ;Get index to next spot
                STA     OBUF,Y          ;and place in buffer
                INC     OTAIL           ;Increment Tail pointer
                RMB7    OTAIL           ;Strip off bit 7, 128 bytes only
                INC     OCNT            ;Increment character count
                LDY     #$05            ;Get mask for xmit on
                STY     SIOCOM          ;Turn on xmit irq
OUTC2           PLY                     ;Restore Y reg
                RTS                     ;Return

to this:

Code: Select all

CHROUT
                STA     SIODAT          ;Send character

    ; put your delay loop here
  
                RTS                     ;Return

EDIT: Note: If you turn on the Xmit interrupt, it will continue interrupting the CPU endlessly, there's nothing to turn it off.

[sci4me]

floobydust wrote:

So, the CHROUT routine in Micromon simply puts a character into the transmit buffer, then turns on the transmit interrupt. This won't work on the bad chip. Modify CHROUT so it just send the character to the W65C51, then execute the delay routine to kill enough time for it to be sent. Don't turn on the Xmit interrupt, as that will hose it up.

Yeah, sorry, I realized this not too long after my post.

I tried modifying CHROUT to be essentially the same routine I've been using this whole time, in other code. Unfortunately I seem to have run into some other issue because now, all of the sudden, it won't boot Micromon correctly any more. Tried reverting back to the code I had that was working but it's still not working.

So, what I did, in order to know it was booting, without the serial port, is just turn on some of the 7-segment LEDs (I just wrote $AA to both of them), and that worked just fine. I just put that at the very beginning of MONITOR. So, I'm not sure... what changed between when it was working and now.

In order to write the ROM, I had to use an Intel Hex file instead of S-Record as the XGecu software doesn't appear to support S-Record. Additionally, I set the "From File Start Addr" to $8000. I'm not really sure if this is correct but it did work at least once before; I did see the $AA pattern on both 7-segment displays.
So, I'm not sure what's gone wrong. Will keep messing with it...

EDIT:

floobydust wrote:

EDIT: Note: If you turn on the Xmit interrupt, it will continue interrupting the CPU endlessly, there's nothing to turn it off.

Could this be the issue I'm having? Are interrupts enabled by the time the code reaches MONITOR? Although, if that were the case I'd think this would've been an issue before?

EDIT2: Nevermind, I don't know what I did wrong before but it's working again. Strange. I could've sworn I did things correctly, the same as I did before and as I just did.

EDIT3: Okay, I am getting serial output... but... well, it's certainly not working correctly. For lack of better words, the data is corrupted somehow. I can see it _trying_ to print out some of the string messages from the source code.
That being said, I haven't modified the hardware at all yet (i.e. remove chips). So, maybe that's part of the problem?
Although it does seem strange that it's failing to print to the serial port correctly as I have been using the serial port with next-to-zero problems this entire time.

EDIT4: Regarding EDIT3, I'm starting to worry that perhaps I messed up the stty settings by trying to use screen? I don't know. Last time I tried to do stuff with stty, I decided i never wanted to touch stty again But, now the program (moserial) I was using, for the most part, for serial comms isn't working at all. Hmmmm.

[floobydust]

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.