Commander X16

21 minutes ago, Andre said:

(does X16 have an NMI key?).

The emulator implements the NMI operation which pushes the program counter and status registers to the CPU stack, sets the interrupt flag, and then jumps to the address pointed to by $FFFA-$FFFB; but the emulator currently does not call it under any circumstance. I can't speak for whether the hardware wires anything to the NMI pin.

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.

Are you guys opposed to an SPI UART?


Sent from my iPhone using Tapatalk

9 minutes ago, Lorin Millsap said:

NMI is reserved for PS/2. Technically you could snag it. Basically there are 2 6522s. The first one handles the PS/2 ports, joysticks, and the IEC bus. This VIA has its IRQ wired to NMI because we found that PS/2 was not working on all keyboards due to timing issues largely caused by IRQ handling delays. By moving it to NMI that eliminated audio, video, and other events from the IRQ and allows the KERNAL to assume that the only NMI events are keyboard or mouse related. If you enable a TIMER in VIA 1 it could be used as a watchdog. You’d just have to hook into the NMI loop.



Are you guys opposed to an SPI UART?





Sent from my iPhone using Tapatalk

Now you don't tell me that if you move the mouse while loading a file breaks the IEC bus (as this is big-banged and allergic to NMI)?

I'm not opposed to SPI, or SPI UART, in fact I think an SPI interface with potentially multiple devices on it is a nice thing - given that SPI is not bit-banged but using a real shift register. I've done USB-over-SPI on the Commodore PET userport using the VIA shift register, and can use a USB mouse on the PET just fine. But it required a) VIA shift out via SR, and b) a 74 series TTL serial-to-parallel shift register to shift in the data at the same time as SPI does. And it VIA can only handle SPI mode 3 "out of the box". See my solution here: http://www.6502.org/users/andre/csa/spi/index.html

Edit: the userport USB is here: http://www.6502.org/users/andre/cbmhw/cbmusb/index.html

In fact _my_ dream computer nowadays would just have a number of SPI-based module ports, and no parallel bus connector anymore. You could plug in SPI modules for serial, USB, memory, Ethernet, whatever you dream of.

And btw run your main computer on any fast speed as you like, as there is no external bus to take care of.

3 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).



 

My experience has been that with a single tasking system and a decent buffer, polling the serial port uses fewer cycles and is more reliable than interrupt driven I/O. And it's certainly less code. But I don't see the harm in designing the implementation so that it can be polled or interrupt driven...

What I don't want to see is an interrupt-only system, since I want to retain the simplest possible I/O API for programmers - especially when using BASIC (as Commodore BASIC has no ON COM keyword.)

Since this actually has some peoples' interest, I'll work up a Google Doc for this, including the suggestions people have made.

I think we have the beginning of a workable specification; once I'm done moving, next month, I can grab a WDC prototype board and we can test this on a real VIA and an Arduino. 

https://docs.google.com/document/d/1HwHCv2txDu91l3uozRH8hwBrq6Fw06lmrQl3kidKQ1c

 

On 7/17/2020 at 4:02 AM, BruceMcF said:

The latter is what an EPP interface would rely on ... as far as I can tell, CA1 set to 0 and CA2 set to 001 so both are independent negative edge detects would be fine for an EPP protocol ... especially since what connects to EPP are typically ISA bus speed devices, so being unable to keep up with the CX16 would rarely be a problem.



Whether CA1 should trigger an IRQ or not depends on whether you want an interrupt driven routine or want to poll.



However, as the User Port is most recently specified, would require a little rewiring of the standard block header to parallel port connector so that /Reset is on a spare GPIO. WIth a jumper setting, the same cable could be used for a standard parallel port and for an EPP.



A custom parallel port protocol could indeed be faster by relying on the hardware handshake to allow you to read or write a packet with very little delay.

 

So I'm rethinking the pins to take your suggestions into account. The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)

 

@BruceMcF @Andre @Michael Steil @Lorin Millsap

I'd like to move the external UART discussion to a new thread. 


Since it's getting a bit off-topic for the original question here. 

 

Discussion about PS/2 has been split in another thread.

6 hours ago, TomXP411 said:

The problem is that I don't know if there's a way to directly read CA1/CA2. Can I read those pins with a PEEK? Otherwise, I need a separate ACK line, since ACK is currently tied to CA1, which is also the interrupt pin. (And I don't want the board triggering an interrupt when I do a read cycle.)

I'll leave this here, since it's still relevant to programming a software serial port.

(1) Either CA1 or CA2 or both can be used to trigger an IRQ, depending on the setting of the Interrupt Enable Register ... CA1, CA2, CB1 and CB2 IRQ enable are four of the seven interrupt enables in the VIA (the other three are two timer underflows and the serial shift register has completed 8 bits).

(2) As inputs, CA1 and CA2 can ONLY detect edge transitions, they cannot detect levels. The only really convenient way to detect both edge transitions without constantly resetting the CA&CB mode register is to tie them together and have one set to detect positive edges and the other set to detect negative edges. Then they will detect any edge transition since the last Read/Write of Port A. Having Centronics ACK tied to a GPIO makes more sense ... similar to the way that have external device Initialize under program control instead of tied to the CX16 system reset via the reset signal sent to the VIA makes more sense, but now unless Port B pin 6 and 7 are available to perform those functions, we are starting to run out of pins.

(3) By contrast, CA2 as /Interrupt detect, and then read the status to find out the cause of the interrupt would work fine ... CA1 really only has two states, for detecting positive or negative edge transitions and is ALWAYS reset after a Port A Read/Write, but CA2 can be used as an independent interrupt, so even if you are polling for the interrupt, you won't lose it because there was a Port A Read/Write in between the interrupt trigger and the poll.

(4) Both the Interrupt Flag Register and Interrupt Enable Register can be PEEKed or POKEd.

10 hours ago, Andre said:

Absolutely agree. A couple of cycles is ok, but if it gets more, the driver should back up and e.g. enable interrupt, if only to be able to break out of the wait loop and not maybe hang indefinitely. (does X16 have an NMI key?).

The EPP is not a timing sensitive handshake, so it would be safe to have IRQ enabled, as long as all of the IRQ users respect the state of the handshake. In a fully IRQ driven I/O system, you can add that to your watchdog timer tasks.

In single tasking, if the busy loop is branch OUT on success, decrement X and branch back on nonzero, you can set a timeout and return with read/write failed.