whartung wrote:
drogon wrote:
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.
Quote:
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?
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.
Well, we're in the same boat, but might take different approaches.
whartung wrote:
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.
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.
whartung wrote:
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.
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)
whartung wrote:
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.
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