What Interrupts can I use from the cartridge port?

[D-Type]

I've bolted on an FT245R USB to FIFO device (i.e. a fast UART) onto the cartridge port of my Vectrex into $8000 of the memory space.

Initial tests are good, I can receive a byte and I can send a byte, and it's very fast to do it, but I've hit a snag on the receive side.

The FT245R has a 128 byte RX buffer and when you throw some data at it, it'll raise a Data-Available line, which I want to put onto an interrupt. 

FIRQ would be ideal, but the Vectrex circuit diagram shows this connected to the AY chip and it's not routed to the cartridge port anyway. 

IRQ would do and the logic circuit diagram looks like it goes out the cartridge port...but Malban says that it's actually connected to the 6522 - in fact the 6522 can drive it and that's how Vectorblade is able to support 4 banks, together with PB6, so I don't think it's an option to use it.

What's left is NMI, which I could use...but then I can't because it can't be masked and once I've the interrupt has triggered, I'd have to drain the whole FT245R input buffer of up to 128 bytes, which I don't really want to do.

So it looks like I'm going to have to present the Data-Available line back to the Vectrex as an address space byte via some additional decode logic. 

Before I do all of that, I wondered if anyone had any bright ideas that might save me having add more logic.

Any ideas?

TIA!

[D-Type]

Can anyone confirm that PB6 on the 6522 can be set as an input, when all the other PB lines are set to output?

[Malban]

PB6 output: Defenitly confirmative!
Example: all DS2430/2431 communication goes back and forth on that pin...

--

I have not tried it - but since the ~IRQ is available on the cartridge port - can't you just try to use it?
I mean it is defenitly also connected to the 6809.
It would not make any "design - sense" if you weren't be able to use it as an interrupt input.

Just set it to zero, and enable the 6809 interrupts - IMHO that should work fine.

Cheera
Malban

[D-Type]

Thanks Malban, your insight has got my brain working!

Regarding !IRQ, it did try using it previously (and !NMI), but they both caused my Vectrex to crash, but not immediately, sometime later. I'm not sure why, I have a Frankenstein cart port extender with my decoder logic and FT245R connected, plus a VecFever, and I haven't coded in any interrupt routines, so could be lots of reasons why it's failing!

So for !IRQ, I thought about it a bit more and I concluded, why would they put it on the cartridge port if it couldn't be used? Now connecting a bunch of standard TTL outputs together sounds like a bad idea, especially if one's at 5V, and another at 0V, so I looked into it a bit more and found a document (www.roust-it.dk/coco/6809irq.pdf) that describes various methods of putting multiple interrupts on a single IRQ line (page 12 of the PDF).

The simplest, in hardware terms, is using interrupts from multiple "Open Drain" output ICs, because you can literally connect them together and into the IRQ line, as a "wire-OR". So I then looked at the 6522 and it does utilize an Open Drain output for it's IRQ line. Ah-ha, so on the cartridge port, I could utilize another Open Drain IRQ. (However, newer models of 6522 removed the Open Drain functionality, to save on power consumption.)

Unfortunately, the FT245R does not utilize Open Drain outputs, I guess it's a bit too modern for that, so I'd have to incorporate an Open Drain buffer IC in my PCB to do this. Additionally, if you wire-OR the IRQs, then you have to work out which one triggered it, probably no big issue, but could potentially cause problems, so I'm not keen on this method. 

And anyway, the reason for using an interrupt is to not miss any data coming it, you use an interrupt to put the data into a ring buffer. But the FT245R already provides a buffer filled on interrupt, that's the whole point of using it instead of an FT232R for example, so my program can just poll the FT245R at it's leisure and, as I'm using Forth, that's exactly what it expects, it reads data coming in and puts it into an incoming "Text Input Buffer" (the TIB) anyway.

So, a simple polling of PB6 is suddenly looking very favourable as it looks like I can do it with a single wire, no extra ICs and no potentially complicated Interrupt Service Routines.

So, now I need to work out how to manipulate a 6522. Time for Forth to remind me why I used it...

[D-Type]

From what I can see in the BIOS source, as default, PB6 is already set to be an input:

;-----------------------------------------------------------------------;
;       F14C    Init_VIA                                                ;
;                                                                       ;
; This routine is invoked during powerup, to initialize the VIA chip.   ;
; Among other things, it initializes the scale factor to 0x7F, and      ;
; sets up the direction for the port A and B data lines.                ;
;                                                                       ;
; EXIT: DP = $D0                                                        ;
;                                                                       ;
;       D-reg, X-reg trashed                                            ;
;-----------------------------------------------------------------------;

Init_VIA:       BSR     DP_to_D0
               LDD     #$9FFF          ;Port A=all output
               STD     <VIA_DDR_b      ;Port B=OIIOOOOO
.
.
.
and appears to be confirmed in the EQU's file:

D000   EQU   VIA_port_b      \ VIA port B data I/O register
\ *       0 sample/hold (0=enable  mux 1=disable mux)
\ *       1 mux sel 0
\ *       2 mux sel 1
\ *       3 sound BC1
\ *       4 sound BDIR
\ *       5 comparator input
\ *       6 external device (slot pin 35) initialized to input <<<---------------- PB6
\ *       7 /RAMP

[Malban]

Perhaps your might also scan following pages:

vide.malban.de/1st-of-june-faulty-via-vs-inc

vide.malban.de/vectorblade/building-vectorblade/vectorblade-code-organization

vide.malban.de/1st-of-june-faulty-via-vs-inc

vide.malban.de/vectorblade/building-vectorblade/vectorblade-code-organization

It is not 100% PB6 and bankswitching... but gives you some background..

But it mostly "output" to the cartridge port, not input.

[D-Type]

Thanks for the links, I will review them... Yes, now I remember you had some tricky problems with the 6522, hopefully I will not be affected so severely. I gave it a try yesterday and interactive Forth can successfully read the port containing the PB6 line, I used something like:

: view_port_b begin $d000 c@ u. key? until key drop ;
2 base ! \ set to binary
view_port_b

to live stream the port data to the terminal.

Unfortunately, the VecFever doesn't like it, when you enable the serial port UART it enables some bank switching settings that clash with my PB6 usage.

So, for development, I need to disable the port or try a VecMulti or pull out the Stag PP39 and try and find a PC with a DB9 com port and go back 30 years.

A series of twisty and turny challenges...

[kokovec]

I played around with IRQs on the Vectrex for a little while but abandoned it in favor of polling.
You might find that most carts check the PB6 line for bank switching.
I recently built an SPI interface between a C64 and Vectrex.
The C64 could read and write to the SPI interface simultaneously while the Vectrex had to poll the buffer address.
Since the Vectrex has to loop through programs in order to draw the screen, IRQs don't really give you much.
You need to spend cycles dealing with screen timing.

[D-Type]

Nov 21, 2020 11:45:04 GMT -5 kokovec said:

I played around with IRQs on the Vectrex for a little while but abandoned it in favor of polling.
You might find that most carts check the PB6 line for bank switching.
I recently built an SPI interface between a C64 and Vectrex.
The C64 could read and write to the SPI interface simultaneously while the Vectrex had to poll the buffer address.
Since the Vectrex has to loop through programs in order to draw the screen, IRQs don't really give you much.
You need to spend cycles dealing with screen timing.

Thanks for your thoughts. 

The serial port I'm using, the FT245R, I chose mainly over an FT232R or equivalent because it's a one-chip solution and it provides Tx and Rx buffers, so you don't need to provide your own and service on interrupt. 

Forth in interactive/interpret mode has a (non-ring) Text Input Buffer, which is polled continuously anyway, so this works perfectly in conjunction with the FT245R.

I have now worked around the VecFever PB6 problem (by disconnecting the PB6 line from the VF) and my FT245R serial port now works great. There are some side-effects with the VF dev mode, but it's not really a problem for my usage.

Here are my drivers, they're nearly the same as those I use for the VF serial port UART.


8000 EQU ft245TxByteReg
8000 EQU ft245RxByteReg

CODE KEY?  \ -- f    return true if char waiting
 6 # ( D) PSHS,   CLRA,   40 # LDB,   VIA_port_b BITB,
 EQ IF,   -1 # LDD,   ELSE,   CLRB,   THEN,   NEXT ;C

CODE KEY   \ -- c    get char from serial port
  6 # ( D) PSHS,   BEGIN,   40 # LDB,   VIA_port_b BITB,  EQ UNTIL,
  ft245RxByteReg  LDB,   CLRA,   NEXT ;C

CODE EMIT  \ c --    output character to serial port
\   BEGIN,   v4eTxStatReg  LDA,  MI UNTIL,    \ No Tx-Ready control line
  ft245TxByteReg STB,   6 # ( D) PULS,   NEXT ;C



I'm new to SPI and I2C, I'm learning about them currently!