I've always struggled with what a modern 6502 machine should be, and should do, and how it should be done. Specifically about peripherals.

Originally thinking how a floppy would be nice, but then looking around at what that entails today, and its limitations, how I don't even HAVE anything with a floppy drive anymore (could always buy a USB drive).

Then there's the IDE Flash interfaces, but even those are getting dated today. And whatever I would need to do, I'd want two of them! So I could copy from one to another, and move data around.

There's the CH376 chip with it's FAT support. But even it seems limiting, only opening one file at a time. Though with the block/sector read interface, you can always write your own FS.

Then there was the thread about the hexadecimal display and the $20 decoder chip, and that's kind of when it hit me, as I mentioned in the thread. You can get a Raspberry Pi 0 for $5.

Five dollars.

Five dollars and you have something that can potentially be the super duper I/O controller. From files, to USB, to printers, to Ethernet.

5 bucks. That's a real deal.

And I know it's not all about money. But, really. $5! Plug in a $15 USB/Ethernet port/dongle and the world is yours for $20.

So, the question becomes how to interface to something like the RPi.

Serially is very popular and common, either UARTs or SPI. But it just seems to make our already slow processors that much slower. Lots of processing for slow data rates.

So I looked around for simple parallel busses, and what that may require. I was initially thinking of just something ad hoc. Like, based on the protocol that the PC keyboards use where one machine is in control to of the interface based on the status of a line, and then data is transmitted (or not). But rather than using a serial protocol, it'll be an 8-bit parallel all at once. You have a some kind of control line, some kind of "clock" line (like the PC keyboard, or SPI), and...that's about it. Everything else is basically a data thing (some kind of command protocol to shove data back and forth).

I though about SCSI, but that seems a bit overkill.

Then I went back further and looked at GPIB/HP-IB/IEEE-488.

Well, it turns out the GPIB is pretty darn close to this, and seems pretty simple. It has the underlying handshake, and then there's a standard on top of it for some commands. I honestly don't know how applicable those would be out of the box or not.

But, anyways, GPIB is designed for daisy chaining, and has these other requirements. What I'm thinking isn't that sophisticated, as the pi board would be mounted right next to the CPU and what not.

Do you think a VIA can talk to the pi's GPIO ports directly? Would they need bus transceivers? Has anyone "bit banged" GPIB? I know the PETs used it. How would you make something like GPIB interrupt driven (that I'm not sure off).

Or is the whole thing a silly idea.

On the 6502 side, it would basically just have a mostly generic driver that uses URL formats to access services. So, if you opened "http://google.com", it would read that page. If you opened "file://readme.txt", it would read that file. There'd be a backing driver on the pi to handle the URLs. I'd even consider "serial:" as a url to open up a tty connection. It's completely flexible. In the end, it just sends URLs over to the Pi, associates a "channel" of some kind, and then packets start going back and forth.

Much of the heavy lifting is done on the Pi.

What other parallel techniques do you think would be simple and work in this case?

So, anyway, just musing.

Personally, I think GPIB is not a good idea, however I don't have any GPIB devices, nor do I plan on getting any, however...

Do use a VIA to talk to the Pi.

Well - that's what I plan to do for the Mk 2 graphics adapter for my SBCs.

My struggle is to keep it with a suitable retro feel though, however the TI99 thingy had a parallel graphics interface with separate RAM, so we're not a million miles away with that - I think...

Anyway, 8 bits, strobe out and and ack back, so 10 wires. The issue then is direction - my current solution - 2 x 8-bit ports, one to write, one to read. The Pi has more than enough GPIO for that, and it saves all the hassle of software bus turn-around at the expense of using up a VIA on the main 6502 side. (which costs as much as a Pi - go figure) This is a standard mode for the ports on the 65c22 - they handle the strobe + ack in hardware. Think parallel printer port...

One thing: The Pi is 3.3v, so you'll need level changers unless you're running your 6502 system also at 3.3v.

And with the strobe+ack type interface, you don't need to worry about latency and jitter on the Pi side, so you can code under Linux and be happy. (and arrange the VIA to IRQ the 6502 after the Pi has taken the data, however I suspect polling might actually be quicker)

If you want to code bare metal, then look for the Pi Zero device that emulates all (and then some) the processors that you could put on a BBC Micro Tube interface. It emulates the Tube ULA (which is a 4-word fifo from what I recall) all in software on the Pi - handling the Tube bus (which is a 2Mhz bus) One of the processors the Pi can emulate is a 6502 running at about 250Mhz.... I'm told Elite works very well with that...

Actually, that might be usable hardware as it comes with a board that has the level shifters already on-board.

Some links here:

https://github.com/hoglet67/PiTubeDirect/wiki
https://stardot.org.uk/forums/viewtopic.php?t=11325


All my side will be in C under Linux rather than bare-metal - mostly because that's what I do, and I wrote the wiringPi gpio library for the Pi which is all in C. Note that while you can vector "interrupts" to user-land code under Linux, so you might think you can take an interrupt on the Pi for the strobe signal, the latency at the Pi end to take that interrupt, feed it via the kernel, wake up your process and get it going is in the order of 150µS, so poll for the strobe on the Pi - you can poll in a C loop at speeds approaching 20M/sec.

-Gordon

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

I have no doubt that Rockwell's or WDC's VIAs are strong enough to drive the GPIB.

My introduction to GPIB (originally HP-IB from Hewlett-Packard, later licensed to other companies and called GPIB, and finally adopted by the IEEE as standard IEEE-488) was with lab test equipment in 1984 where I was working. I used it in a test set-up at my next job, in 1986, and I controlled it through my HP-41cx calculator, using HP-IL (which was part of the calculator's system) and an HPIL-to-HPIB interface converter that was practically transparent, using the same commands and all. HP-IL was basically a serial implementation of HP-IB. It does support interrupts. I never really had to get into the innards of HP-IB (GPIB) or HP-IL.

As for other interfaces though, serial doesn't have to be slow. SATA for disc drives is serial. USB is serial. Some SPI devices reach close to 100Mbit/s, the last I read. The Wikipedia article on Ethernet says it is expected to reach 400Gbit/s this year. I'm hoping Daryl finds a suitable CPLD to replace the discontinued one he used to make his 65SPI IC with. If it had an external clock source that's faster than phase 2, such an IC could send and receive a byte in less than the time it takes for the 65xx to read or write it. There are probably thousands of ICs on the market today that use SPI. SD card has an SPI mode, and these are much simpler than USB whose 2.0 spec is 650 pages!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I also continue to think about what to build up next to interface to my 65C02 based SBC. I have tons of stuff lying about the house actually... diskette controller chips and diskette drives as well. I also have dozens of older, albeit (aka hardly used) IDE laptop drives that are in the 3.53GB and 4.32GB capacities, plus a bunch of others that reach up to 100GB. I even have an original IBM Microdrive (340MB in compact flash format). I have Arduinos, the Zilog equivalents and a few Raspberry Pi devices kicking about.

So.... what to choose for something like a neat I/O device. In my humble view, I like the thought of mass storage, i.e., some sort of disk storage type device, whether rotating media or flash based. There's also adding a true RTC chip and additional serial and parallel ports for expansion.

Of course, trying to do everything on the one processor gets a bit busy after a while, but depends on your scenario for application. I always liked the Commodore approach of having devices that were somewhat intelligent, like their diskette drives. This approach could be nice for building up some useful I/O devices, for disk storage, other communications, etc. and allows more 65C02 code writing as well, not to mention more 65C02 processors.

Granted, the current Pi model B+ is a bargain at $35 with a 64-bit quad-core CPU, 1GB memory, Wifi, Bluetooth, Gigabit ethernet and the rest of the GPIO... but it's a bit like cheating. I use these for techie appliances... one running Octoprint to drive my 3D printer and another configured as a reverse access point (links to my WiFi network and does NAT, DHCP, etc. to the ethernet port) so I can have network access on a small Core i5 system that doesn't have WiFi. I'm also thinking about building up a 1541Pi setup, which emulates a Commodore 1541 diskette drive and provides the same Serial port for connection.

But back to the 65C02 hobby... I'll likely use a 65C22 parallel port to attach smart 65C02 devices to each other. The transfer speed would be very fast and you get to write more code as a bonus As for what those devices are, I see a smart storage setup like a 1581 with internal RTC, possibly a graphics display controller with PS/2 keyboard and then some basic I/O to round it out.

_________________
Regards, KM
https://github.com/floobydust

To my novice eye, I don't see a whole lot of difference between the parallel port protocols and GPIB. Basic parallel port requires 3 extra lines, just like GPIB does. The extended parallel versions just add more, similar to what GPIB does. Seems more a matter of taste, especially if you don't intend to implement the GPIB wire protocols.

For simplicity I'd want something that can be done with a single VIA, which offers only 2 ports.


Since I envision the pi potentially handling multiple I/O request simultaneously, I want an interrupt driven side on the 6502 since you don't necessarily know what kind of packet is coming next (you could be reading a file, and reading the internet for example). So, the interrupt handler would service the individual channels opened on the 6502 side. What I don't want is anything like DMA. I'd rather the pi send back a packet "here's some data for channel 2" and the routine routes it properly. I can see the interrupt happening at the beginning of a packet, the routine drains the packet from the pi, then it hangs up. The next packet would toggle another one.

Obviously have to suss out handshaking at the channel level to keep the pi from sending more than the 6502 can handle.


Serial protocols through a dedicate chip may be faster, but not one that's bit-banged from the CPU/VIA. And that was my reasoning. If I have to interface to a dedicated protocol chip (for ANY protocol, whether it's SPI, USB, that DOS chip, or even a UART), I may as well interface to a Pi as it provided universal, modern I/O. It can connect to anything. Just need to have some custom software on it. Ideally, a 1GHz Pi can provide I/O far faster than even a 14MHz '02 or '816 can feed or read from it.

Heck, it may be practical to mimic the 6551 interface: 8 data bits, some "register select" bits, a R/W bit and an the IRQ line. The benefit of the 6551 is that it can plug straight in to the address bus. I don't know if putting the pi GPIO pins on to the address bus is a good idea. If that's the case, that you could put the GPIO pins on both the address and data bus (skipping the VIA), well, that's interesting as well. I just don't know if it can work like that.

I like the idea of a data strobe ala SPI et al vs tying in to the system clock. For whatever reason I just find that simpler. But maybe the it can work with the pi.

What's about a a FIFO or a Dual Ported RAM as a bridge between the CPU and the Pi? They require some board space and aren't cheap but fast.

Regards,
Arne

Somebody else would know much more about this than I do, but isn't the Acorn tube interface a solution to exactly this problem. I do know that the tube interface has been implemented on both a 6502 and a Pi so there should even be existing hardware and software to do this.

I mentioned that above... viewtopic.php?f=4&t=5378&p=64564#p64497

-Gordon

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

The Tube is electrically very simple, but the protocol is a little complex, and the implementation is not trivial, all in the service of decent performance. Back in the day, there was at least one nearly-Tube implementation which didn't use Acorn's custom chip, but a pair of back-to-back VIAs (or PIAs) - a couple of 8 bit ports is enough, but I think one port might be too little. You can also run the Tube protocol over a serial link. So, bidirectional byte streams with a bit of handshaking is enough.

For more on that sub-topic, see
http://mdfs.net/Software/Tube/6809/

(GPIB is, I think, bidirectional and asynchronous. That's great for flexibility and a simple implementation, but there will be a performance cost. SPI might well be a good alternative, as it runs up to 12MHz and there's no need for bus cycle acks and turnarounds. One limitation with SPI and the Pi is that the Pi's SPI ports must be masters. I'm not sure how fast the Pi could bit-bang an SPI slave implementation. For the Tube, PiTubeDirect has the Pi bitbanging a 2MHz 6502-style peripheral interface - it was possible, it's now reliable, but it did take a lot of work to get there.)

I may still have a GPIB-to-serial converter laying around somewhere. And we used a colour graphic display which used GPIB for the image data, back in the day.
But I'm not sure I would want to use GPIB today. There's that clunky physical interface, for example.

Sure, if you plan to do the whole daisy chain thing with connectors, but that's not my intent.

I'm simply looking for a parallel interconnect between cooperating devices, so just wiring the VIA straight to the Pi GPIO pins in this case.

I don't know if it's viable to wire a Pi straight to the '816 addr and data bus, or how fast the Pi can respond.

Can thepi handle an up to 8Mhz (or even 14Mhz) 6502/816? Can it be done with anything higher level than a Linux kernel driver?

The PiTubeDirect project keeps up with a 2MHz bus, using baremetal code which takes over the (so-called) GPU. No linux, and not much margin, and it even has to use a trick of triggering off a decoded address (and then defending against glitches.) And it all took a lot of ingenuity and a lot of debugging. The timing of code running on the ARM had a long tail of too-slow responses - we suspected there was contention for the memory system, or something autonomous which interfered. The Pi's SoC is a complex chip, and not fully documented, so we don't know. But by using the GPU and keeping all data in registers, we got there.

I think 8MHz is out of scope - at minimum, you'd need to treat the Pi as a slow peripheral, and slow or stall the CPU for Pi accesses.

If you had the kind of bus connection with a handshake, so the peripheral can acknowledge when it has the bus and when it has the data, you might be OK with Linux on Pi.

That was my base goal. That's what attracted me to GPIB in the first place, as it should work "as fast as the slowest peripheral" on the bus (whether it's the Pi or 6502). That's nice because I should be able to POC the thing in Python using Pi provided libs until I can get the underlying protocols worked out.

But I also want something where both sides can initiate communication. I don't mind them sharing an 8 bit bus, since most of the time, most traffic is dominantly one way. As long as the bus isn't completely dominated by one side (i.e. the other can get access to the bus as well), then that's good too. As long as I can send 1MB "at full speed" from one partner to the other, while getting a 9600 baud stream back the other way, "simultaneously", it's successful.

Also, I'd like to just have to use 2 8-bit ports to pull the whole thing off.

Migrated from viewtopic.php?f=4&t=3052


Moving this over to my original GPIB thread (also now renamed).

This is essentially what I've been looking for. GPIB is basically this protocol, at its heart. But it would be nice to explore how the protocol would/should evolve, but also what the software side looks like as well.