Commander X16

I honestly don’t know if the Arduino will be fast enough for pulse output. In fact, I’m certain that an Uno, running C, will not be as fast as an 8MHz 6502 running assembly. So it will be necessary to hold the strobe for at least a few clock cycles. The fact that there’s no consistent way to read from all of the pins at once in the Arduino API makes it worse, as you have to poll each pin and rotate the values in to the data byte.

So I may end up recommending holding the strobe active for a relatively long period of time, such as 10 microseconds (80 machine cycles on the Commander.) While that seems like a long time, it is still an order of magnitude faster than a single character transfers, even at 115kbps. 



of course, faster Arduinos, like the Due and Grand Central, blow the Commander away, but the basic Uno is actually very similar to the Commander in terms of performance (and has far less memory.)

in fact, when doing software serial, the software UART is limited to 9600 baud. So this really only makes sense with a Mega or better. 

its giving  me stuff to think about, though. I need to read through the programming guide for the VIA to really understand the CA lines and their utility. 

 

Of course, again there’s not much use splitting hairs over implementation yet. We won’t even see hardware for a while longer, and so everything we do now is going to be theoretical or developed on analogues. 

Yes, though the analogue for my CP/M box is a C64, so using the process:

1. set R/W,

2. busy loop until /ACK=1

3. pull down data|address

4. busy loop until /ACK

5. Read|Write to port

6. pull up data|address

7. If data packet, back to 2 for the next byte

... it's got full handshaking, so if it switches from the device waiting on the C64 to the CX16 waiting on the device, that'd be OK.

But I'm looking at using an 8-bit PIC microcontroller to manage the interface, because of the set-up cost for programming SPLDs ... and the one that has enough GPIO also has a UART. So having a compatible interface with another UART box would be interesting.

4 hours ago, BruceMcF said:

Yes, though the analogue for my CP/M box is a C64, so using the process:



1. set R/W,

2. busy loop until /ACK=1

3. pull down data|address

4. busy loop until /ACK

5. Read|Write to port

6. pull up data|address

7. If data packet, back to 2 for the next byte



... it's got full handshaking, so if it switches from the device waiting on the C64 to the CX16 waiting on the device, that'd be OK.



But I'm looking at using an 8-bit PIC microcontroller to manage the interface, because of the set-up cost for programming SPLDs ... and the one that has enough GPIO also has a UART. So having a compatible interface with another UART box would be interesting.

The ACK signal is a good idea. I will add that to the logic flow. 

A PIC is also an interesting choice. I’m not saying it’s a bad one for a complete product,  but using a bare chip has a higher implementation cost for users. Arduino boards include the in-system programmer needed to do the job, which is why I plan to use that as a baseline implementation. I do want this to be something a user can assemble themselves in just a few minutes. In fact, I plan to build this on a breadboard and mount it inside my Commander, leaving off the female DB25 and going straight out to a male DE9 and DB25, instead. Since the Mega has room for 4 serial ports, I will probably actually mount 2 D-Sub ports on the back, in addition to an ESP32 and the Arduino’s USB port. 

2 hours ago, TomXP411 said:

A PIC is also an interesting choice. I’m not saying it’s a bad one for a complete product,  but using a bare chip has a higher implementation cost for users. Arduino boards include the in-system programmer needed to do the job, which is why I plan to use that as a baseline implementation. 

I see PIC programmers for under $10 on ebay. I don't know if those program the PIC's I have the datasheet for, but that's what turned my attention to the 8bit PICs ... when I was searching for programmers for the +5v Microchip SPLDs, below a certain price point all of the programmers that were listing Atmel or Microchip were only listing PICs.

Of course there would be a pride element to having a 4IC CP/M board where the microcontroller is an 8bit microcontroller ... AND it addresses the "but the support microcontroller is more powerful than the main system" whinge from the whingers.

On 7/20/2020 at 5:36 AM, BruceMcF said:

I see PIC programmers for under $10 on ebay. I don't know if those program the PIC's I have the datasheet for, but that's what turned my attention to the 8bit PICs ... when I was searching for programmers for the +5v Microchip SPLDs, below a certain price point all of the programmers that were listing Atmel or Microchip were only listing PICs.



Of course there would be a pride element to having a 4IC CP/M board where the microcontroller is an 8bit microcontroller ... AND it addresses the "but the support microcontroller is more powerful than the main system" whinge from the whingers.

It's not about the programmer, it's about having a ready to go board with everything on it. AFAIK, there isn't a board like that for PIC - or if there is, it's not very common. 

For that matter, I'm not sure I see any advantage to using a PIC when Arduino is everywhere and in so many form factors: the software works on ESP32, Teensy, and Arduino branded experimenter's boards, among others.

just my $0.02 from an operating system programmer:

- polling/busy loop/busy waiting is the most wasted time on a computer. As an OS programmer I'd want an interface that has automatic flow control, and does basic handshaking in hardware and interrupts to trigger further processing (sending/receiving). That relates to a UART with auto-handshaking on the RTS/CTS lines when the buffer gets full/empty, but even to the VIA port handshake mode as one side can signal the other when data has been provided / sent automatically.

- bit banging a serial line (RS232 and yes, IEC too) is the most stupid version of CPU wasted cycles. A simple shift register can help so much here taking load off the CPU. Especially with async serial (like RS232) where exact timing needs to be matched, you have to disable all interrupts in the meantime which is a major hassle. Actually I wonder how serial IEC will be implemented in X16 - in my(tm) dream computer, the CPU would run full speed off-screen and only slow down during screen access. But then you end up with a slower version of the IEC than what would be possible because you'd have to account for the video slowdown. Remember that the C64 IEC is slower than the VIC20 due to VIC badlines stealing CPU cycles? Exactly what would happen and what could be avoided with a simple shift register. (at least I hope the VIA shift register of the WDC6522 is used for that, as serial IEC would make _no_ sense otherwise, and WDC has actually fixed the longstanding shift register bug)

And yes, I built my own 6502 back in the days, and those reasons are exactly why I stayed on IEEE488 (parallel, not bit-banged IEC) and switched from ACIA to UART with its FIFOs. Makes life so much easier as a programmer. Some programmers may see this as a challenge - but I say better focus on the real challenges like nice video/graphics instead - it's totally worth the hardware. If a UART does not fit in the original budget (space / scope / power / ...), provide an extension card / slot for it but don't do bit-banging...

(sorry didn't want to write a rant, but came out this way. I know there are many reasons for including/excluding features, just wanted to add the aspect of ease of programming for an operating system)

 

8 hours ago, TomXP411 said:

For that matter, I'm not sure I see any advantage to using a PIC when Arduino is everywhere and in so many form factors: the software works on ESP32, Teensy, and Arduino branded experimenter's boards, among others.

I see a 40 pin, 14KB program EEPROM, 1KB SRAM +5V through hole PIC with in circuit serial programming at mouser for under $2 q1. So there's an "any" advantage for an all parts kit. Obviously an assembled board would use the surface mount versions of the ICs.

From the view of an operating system programmer, busy waiting / polling is wasted CPU. I would want something that does automatic handshaking, and provides interrupts when data is available or buffers are empty. That relates to VIA handshaking mode, or an UART with its FIFOs. Even the Commodore serial bus wanted to use hardware features to avoid bit-banging. It only became a total failure just because the VIA shift register they planned to use was buggy (which isn't in the WDC VIA anymore as far as I know).

If we're building a "dream" computer, we should avoid such decisions. Rather have an expansion slot where e.g. a UART can be placed.

12 hours ago, Andre said:

From the view of an operating system programmer, busy waiting / polling is wasted CPU. I would want something that does automatic handshaking, and provides interrupts when data is available or buffers are empty. That relates to VIA handshaking mode, or an UART with its FIFOs. Even the Commodore serial bus wanted to use hardware features to avoid bit-banging.

It does depend on how many times you cycle on the busy wait ... a load absolute, AND# and test for two loops and then succeed adds 26 clock cycles would mean that by the time that the interrupt is set up and you return to the caller to allow something else to be done, the interrupt will be triggered, and then you have to work through the IRQ vs BRK parsing to get back.

200 loops through a busy loop is something else entirely.

On the EPP interface and without rewiring the current proposed User Port wiring, CA1 is on /Interrupt, and CA2 is on /Wait.  For the application I was originally discussing for it,, that's where you'd want it, because in this application, the CX16 and the 6502 is acting as a server and the user client is the Z80 and the program it is running ... so yes, if busy looping the 6502 make it more responsive to the demands of the Z80 than an interrupt driven set-up, busy looping is more efficient.

In the original applications of the EPP port to access CD-ROM drives and Zip drives and IDE Hard Drives, etc., I think that /Interrupt on CA1 is probably still preferable, but if the display and audio needs serving at a higher frequency than the EPP I/O device, yes, I could see putting the EPP port service on timer ticks.

As far as the demands of the operating system for clock cycles, so that the application cannot hog them all, that is less of an issue in the CX16 ... in a single tasking system, there are a lot more scenarios where the application gets to hog most of the clock cycles if it wants to.

For a serial box, busy loop on waiting for an Arduino to answer while reading or writing parallel data, as Tom was referring to, would not loop many times. As far as polling CTS and Data Available, that can be done on a timer tick without requiring throwing an interrupt given the depth of FIFO queues available and the speed that data can be read out of the queue when servicing Data Available.

On 7/22/2020 at 4:21 PM, BruceMcF said:

It does depend on how many times you cycle on the busy wait ... a load absolute, AND# and test for two loops and then succeed adds 26 clock cycles would mean that by the time that the interrupt is set up and you return to the caller to allow something else to be done, the interrupt will be triggered, and then you have to work through the IRQ vs BRK parsing to get back.



200 loops through a busy loop is something else entirely.



 

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