Thanks for relocating, whartung!

I think there are maybe three kinds of things to be designed or explored:
- flow control, so neither side loses any bytes in transit
- synchronisation, so you can pass messages and have them dealt with exactly once, and soon
- higher level protocol, so you can distinguish and possibly interleave different I/O streams, interrupt events, data transfers

It may be that you can get some ideas from Acorn's Tube protocol, but it may be that what you want has different features and different priorities. It's clear from the example of running a Tube-like protocol over back-to-back VIAs that you don't need custom hardware. Being able to handshake and cause interrupts is enough.

There is another bus that is common, designed for Small Computers - is 8-bits wide, supports multi-master, or master/slave with up to 8 devices on a single bus and can be implemented with a single 6522 at one end, and something similar at the other end, be that another 65xx, Pi, ATmega or a peripheral...

This bus is, of-course the Small Computer Systems Interface - aka SCSI. Specifically SCSI-1 here.

At its simplest, it's a strobe+ack type of bus with some more signalling bits to allow for device selection and bus arbitration.

The down-side is that as the bus complexity goes up (e.g. from what's effectively a parallel printer to GPIB to SCSI) so does the software complexity. Even in more capable computers, it was some time before hosts could do a "disconnect" from a target device to address another device (ie. send 'get this block' to a drive, then rather than wait for it to return, disconnect, send another command to another drive, then re-attach to the first drive when it was ready to send data back).

SCSI was never intended just for disks though - although it's a bit heavy-handed for emulating a serial port, it can be done.

Anyway, some food for thought.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Tangent, maybe suitable for its own topic: use FPGA to implement a multi-core 6502 system, using shared memory for communication/cooperation.

I think you'll need interrupts on both sides, but with that, you should be fine. Each side treats the far side as a peripheral which might suddenly send a packet, so it needs an ISR which is at least intelligent enough to raise a flag for the application's benefit, or possibly intelligent enough to pick up a whole packet and do something useful with it.

It might be notable that Acorn's Tube protocol has ordinary messages, unsolicited events, and also has full-steam no-flow-control transfers of 256 bytes. This is for performance: each byte coming off a floppy on the frontend machine is streamed over the Tube to the application side, IIRC. Maybe the same for network packets, I don't know. A more sedate approach would be to have the frontend machine put such data into a frontend-side buffer and subsequently allow a transfer to the application side, perhaps even as a 'pull' rather than a 'push'.

I took a glance at SCSI, but not a deep study.

Initially, to me, it seemed rather complicated. I'm on the crass assumption that it uses dedicated controller chips for a reason.

After an evening of poking around, my eye is currently on IEEE-1284 EPP. I haven't looked at it in complete detail. It's the 3rd or 4th generation of what started as the classic Centronics Printer port.

Yea, I plan on taking a deeper look at EPP tonight to see how to make it interrupt driven. Actual compatibility with the specification is not a goal if a subset can be used just for this use case. There's no intention of plugging random devices in to this bus.

But this is essentially the case. While the bus is idle, either side can initiate a transaction and push it over to the other side. Meanwhile the other side is locked out while the transfer is in progress.

Do folks think its OK for an interrupt routine to transfer as much as 256 bytes at a time? The simple truth is that in the modern case, notably for bulk transfers, the I/O is actually faster than the CPU. I expect that the CPU will be able to draw data over as fast as it can. So I don't think this would be a problem.

The game there, to me, is to have the interrupt trigger at the start of a packet, not just a single byte clocking in (that seems quite expensive). Dunno yet quite how that might be possible. But the bright side is that it should be doable over 2 8-Bit ports (which is something I'd like to stick to).

If it can't be truly interrupt driven, then I guess I'll just poll it using a timer.

The other thing I discovered, which is germane, is that there is an IEEE-1284.4 "Data Delivery and Logical Channels for IEEE 1284 Interfaces- allows a device to carry on multiple, concurrent exchanges of data" which is just what the doctor ordered.

What's interesting about this, is that it, in fact, has pretty much NOTHING to do with the rest of 1284, since it's really doesn't care about the underlying interface. In fact this is the underlying protocol being used notably by multi-function printers over USB. It is essentially a simple packet protocol and the example high level API layered on top of it looks like a modern socket API with Open, Close, Accept, Listen, Send, and Receive.

A nice thing about 1284.4 is that answers basic questions of bus saturation. For example, if the CPU wants to send a command to the client, and, meanwhile the client wants to send packet as well, who gets the bus? 1284.4 addresses this (I can go in to it in more detail in a followup post).

However, it's not a well known protocol in the wild. Most of the software is from HP as closed source printer drivers.

All that said, I'm still open to something like SCSI if it can be "bit banged" on 2 8 bit ports. Perhaps using the SCSI command protocol over the EPP interface. I'm completely content on a hybrid approach.

When you say two 8 bit ports, do you mean one undirectional port in each direction, so each end sees two ports, or do you mean the two ends of a single half-duplex byte wide channel, so each end sees one port?

When serial data started to get faster, the UART chips started to have on-board FIFOs - then to send, you'd typically fill the FIFO in a loop until you got the 'full' interrupt (or polled for it), then wait until you either polled or got the 'empty' interrupt. It was generally quicker in cpu cycles to do the tight loop fill, than an interrupt per byte.

Same for incoming data - the UART would generate the interrupt as soon as the first byte was in the input FIFO, then you'd poll the chip, removing bytes until it was empty. That way you had a bit of slack time as e.g. incoming data at 115200 baud is more or less 10,000 bytes/sec or 100µS per byte - which seems like plenty of time, but add the overhead of taking an interrupt per byte and it soon adds up - especially on a relatively slow 8-bit micro..

So essentially "yes" to your question about transferring 256 bytes inside the interrupt.

My shared memory approach uses a very similar FIFO like buffer for sending text - I store up to 128 bytes of putchar in the buffer then when it's full (or I print a new line) I send the flush and print command to the host. That flush command is also sent if the buffer has anything in it before any other command to the host e.g. getting a character or file block, etc. the 6502 is stalled while the host accesses the shared RAM, so I want to minimise that stall time if I can.

(The host code is completely stateless - it just executes commands from the 6502 as they come in - it can't signal the 6502 in the current PCB incarnation, but it could on the previous stripboard incarnation, so the 6502 has to poll the host for character-ready which slows it down somewhat in e.g. EHBasic which polls for Ctrl-C far too often...)



SCSI can be "bit banged" (and has been in the past), however you don't need to use the actual SCSI protocol unless you want to talk to a real SCSI device. Same for an EPP or EPP style interface - the main issue being compatibility - which isn't an issue at all if both ends are made by you, then you invent your own standard, or maybe we, the 6502.org community can come up with something? I do have ideas for a peripheral bus for my systems, but it's unclear (to me) if it's worth it - (am I going to make an SBC with slots? Not sure) the down-side for you might be the data transfer speed because it was at the load 8-bit data, set strobe, wait for ack (done by the 6522) level so transfer speed would be well under 1MB/sec, even on a 10Mhz 6502. I think to go faster then you'll need some sort of dual-port RAM or a DMA engine.


How many devices do you want to hook up? Are we going to see a Beowulf cluster of 6502s?

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I mean one bi-directional 8-Bit port for the data to and from, the other 8-Bits for control information. You can multiplex command vs data on the data port based on the status of a control line, for example (vs using a modal transfer).

All sorts of ways to mix it up.

I think I'm right in saying that a VIA offers two 10 bit ports - 8 bits of data, and two for handshaking. Something like that. And built-in capability for raising interrupts.

Exactly that, although on the 6522, port A can do write handshake only while port B can do read and write handshake. That's the write data to port, and with the 6522 set to the right mode it will automatically do the outgoing data ready (strobe) and interrupts on the incoming data ack from the remote device. Just what you need to implement a parallel printer port for example...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The intent is to interface the 65xx to a single device, in this case a RPi Zero. The RPi0 then becomes the I/O Processor for the entire system.

So, basically, CPU, RAM/ROM, I/O Processor and the interface between them.

For $10 I get a device that gives me Serial, USB, (slow, i.e. not memory mapped) Video, SD Card, and networking/wifi. That's a lot of I/O for $10.

If I understand it right, the Pi has 17 dedicated GPIO ports. It also has some that (I think) are multi-purpose, and if so, then it can go up to 26 ports. If you go that route, then you lose things like the UART, SPI, and I2C.

The 2 8 Bit ports constraint are a combined issue of dealing with the 17 open pins on the Pi, and the fact that a VIA has 2 8 bit ports. Also, the '265 has 2 free 8 Bit ports.

My initial vision of getting this working is wiring up WDCs '265 board to the Pi as a proof of concept, and then going from there. You can see in this example, there's no extra hardware needed -- just hookup wires. Low barrier to entry.

I don't expect any amazing bandwidth out of this thing. But I do expect it to be faster than a bit banged serial interface (ala SPI).

It seems as if there might be enough pins on the Pi to actually do some kind of DMA. If you can indeed utilize the 26 ports, there's a 8-Bit DBus and 16-Bit address bus. You can knock it down to 12-Bits and some control signals, giving you 4K of shared RAM. Maybe.

That's where my little Pooh brain falls apart.

The basic thinking is wire the two boards up, hack a Python script to work on the Pi side, work on a Hello World protocol router and interrupt handler on the 65xx side. If that's successful, then, shazam -- 65xx with at least a hard drive (i.e. some folder rooted on the Pi someplace). Extra devices can be added in to the Pi side (networking, terminal, etc.). At that point it all (mostly) looks the same to the 65xx.

If/when the Python gets too slow, rewrite it in C. I don't think there's a any need to go bare metal - I think that Linux should be able to keep up with a 4-8Mhz 65xx.

Anyway, that's the murky vision.

BTW, I find Acorn's chosen nomenclature of 'host' and 'parasite' not very helpful. So I've started to converge on using 'frontend' and 'application'. But, that's looking at things from an Acorn perspective, where the application system is faster and larger and is generally the one initiating actions (other than user input, which happens on the frontend system.) I'm not sure, but is your vision like that, with the Pi as frontend and the 6502 as application? Or is it more like the Pi as both frontend and main system, with the 6502 as a sort of appendage, an accelerator as it were, but oddly enough with lower performance?

Using the Acorn model, the Pi is the Acorn, and the 65xx is the "co-processor". In the Acorn model the original Acorn is subjugated to the role a merely handling I/O, while the "work" is done on the co-processor.

I visualize the Pi as a Magic UART. The fact that it's a general purpose CPU is simply a detail.

Consider the CH376 USB chip, which is a chip that lets you interface a CPU to USB and includes a FAT filesystem, it's a dedicated MCU to handle the USB and FAT duties, along with the support for the Parallel, SPI, and I2C(I think) interfaces.

I look at the Pi essentially with the same eye as I view one of these chips in this case.

Well, we're in the same boat, but might take different approaches.




On the Pi 0 (and all 40-pin Pi's), you have 26 exposed/usable GPIO pins. They can all be used as general purpose.
( plus 12 power/gnd pins plus 2 I2C pins that you're not supposed to use - for HATs)

Of this 26, 2 are the on-board serial (but personally, I don't use that for a serial port any more, preferring USB serial adapters, however I'll count them here, so we're down to 24.

2 are I2C, so 22.

5 are SPI, so 17.

Of those 17, 2 can be used for hardware PWM and one for a hardware clock source (or as a 1-wire interface), however those are optional.

The 2 I2C pins you're not supposed to use can actually be used without too much hassle, as long as you're aware they'll be put into I2C mode at boot time as the bootloader tries to extract a device tree entry out of an EEPROM on a HAT.

On my ATmega host system I'm using 8 pins for A0:7, 8 pins for D0:7, pins for RD, WR, Reset, BE, Rdy, and IRQ, so 22 pins. So to use a Pi in the same way I use the ATmega would mean using those 17 pins plus the 2 serial (19) plus the 2 I2C you're not supposed to use (21) plus one of the SPI select pins. That leaves me an I2C port and a single SPI channel on the Pi.

If I went with a plan B - and had a ROM in the system, then I'd need 10 pins for the data bus (8 bi-directional data plus strobe and ack) and possibly an 11th from the Pi to the 6502 to act as some sort of "I have data for you" feedback. The 6502 end would be port B of a 6522. A protocol would need to be devised to work out bus direction and make sure you didn't clash - also level shifters if the 6502 side is at 5v - the 74LVC245A is good here bi-directional, but needs a direction signal input, so we're looking at 2 pins from port A of that 6522.




You can re-provision all those 26 pins, but be aware that the 2 normal I2C pins have 1.8kΩ pull-ups to 3.3v. Normally not an issue if you know the signal you're driving would be normally high anyway. You would not be able to DMA on the fly (e.g. on the other half of the Ph2 clock), but would have to do what I do currently - stall the 6502 via the Rdy pin, disable it's bus with BE low, then you can access it's RAM, then let it go again and poke it with an interrupt to tell it something is there for it. My current system is entirely 6502 driven and on the 6502 end I put data + command into a small buffer (128 bytes + a command byte, a parameter byte and a return code byte), then sit on a WAI instruction - the ATmega sees the Rdy line going low, then pulls it low, then pulls BE low before enabling it's AD buses to the memory, reading the command, doing "stuff", writing data back then letting the 6502 go, by BE high, release Rdy (which the 6502 will still be pulling low), then send an IRQ to make it go again. The latency here is down to the ATmega which isn't that fast when the software generated video is running (which consumes about 60-70% of all CPU cycles - that's 'free' on the Pi)



On the Pi speed front - it's not that Linux cant keep up, but the Pi hardware simply isn't right for the job. The Pi has dynamic RAM that gets refreshed at non-deterministic intervals (or so it seems). The video RAM takes a hit too - at these times the ARM is stalled. Even bare metal the PiTube folks find that it's marginal to capture the 2Mhz clock from the Beeb (on a Pi Zero) from what I've read, however - the advantage of either of these ways is that we never have to capture a signal - put byte on bus, set strobe - then the Pi has all the time in the world to see the strobe, read the byte and set the return Ack signal.

All my Pi stuff will be in C - because apart from BASIC that's what I use on the Pi. I also wrote a whole lot of GPIO stuff on the Pi in C - as well as a BASIC interpreter which has all the graphical functions I need (uses SDL, but that's just an easy way to poke pixels into the framebuffer) I have a fairly comprehensive 2D graphics library anyway that's easy to port though.

Anyway enough ramblings on from me for tonight..

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks for that, that was interesting


Yea, that's what I was thinking. I'm not looking for precision, the whole thing is mostly hamfisted anyway.

I don't know what's weaker, my C or my Python. I was simply gravitating toward python as a low barrier to entry to get Hello File System working and proof out protocols and handshaking.

I don't even like Python.

In fact, my first approach is to simulate the handshaking just using Java (which I'm most comfortable with), not even hardware at all. Get that working, I'll pick up a Pi0 and try to get two Pis chatting with wires and everything. If I can get that far, I'll pony up for the '265 board from WDC and try again.