Yes, that's a much better phrase and I'll update my docs!

V0.1 of the board is on its way to my apartment from Shenzhen today. I'm using the latest layout to do some simple testing, but mostly physically hold the thing and decide on standoff locations, silkscreen needed, and think more critically about the backplane connector spacing. I'm a kinesthetic human, so it'll be easier with the rough version in my hands.

I'm starting to draft up expansion modules. The first actually doesn't use the bus backplane, and instead connects to the two IO Ports to provide LEDs, Pushbuttons, and an 2x20 Character LCD output port with a jumper to select 4 or 8 bit mode.





As you can see, I'm venturing into SMT parts for this card. I want to try the JLCPCB SMT assembly service, and I was able to do this design with only two "Extended Parts".

I want to get comfortable with it, because JLC has the FT245RQ as a basic part for ~$3, and it would be amazing to do a USB<->FIFO rather than an of the shelf ftdi breakout & UART. Should be able to make an RC6502 compatible FT245RQ breakout for cheaper than the UMFT254R and use a more modern USB connector too.

_________________
https://github.com/Individual-Solid/

Oh, that's sweet! Yeah, those USB FIFOs look as if they may be somewhat easier to use than a UART, not to mention faster. I had actually had recently ordered some FT240 parts myself to put in my "to play with some day" bin, but apparently the seller has had second thoughts since he cancelled my order and jacked the price up by almost 10×.

_________________
Curt J. Sampson - github.com/0cjs

I would definitely get some of those FT240's - they're fantastic! You can get them from digikey or mouser for around $2 each. They just connect straight to the processor data bus, with a little bit of glue logic to generate RD and WR strobes, and you need a couple of GPIO pins from somewhere to hook up the RXF and TXE signals to be able to see when you can read or write data. And they just work (well, they do once you've got them wired up correctly...) They'll transfer data as fast as your 6502 can deal with it - 16K transfers in the blink of an eye.

You're going to need some decoding anyway if you're going to put the data pins directly on the data bus and read them that way, so couldn't you use your decoding scheme also to put the ready bits on an address in your I/O space?

If you're going to go to the extra expense of runing it through a 6820-style PIA, I think that you could probably rig up something using the sort of "automation" behaviour of the CS lines, which I think would even give you the option of enabling interrupts when you're waiting for a packet start, but then not dealing with the overhead of an interrupt-per-byte during bulk transfers.

Well, I'm just arm-waving here, but the more I look at these USB-FIFO things, the more they look like a good idea. (So long as they have drivers already built in to Linux, which these ones do, I understand.)

_________________
Curt J. Sampson - github.com/0cjs

Well, that's actually what I did, since on my board this stuff was controlled by a CPLD. The CPLD decoded two addresses - one generated the RD and WR strobes to access the FT240X data port and the other address read the RXF and TXE lines into bits 7 and 6 respectively. Writes to the second address controlled interrupt enable bits, so an IRQ could be generated if there was RX data or TX space available. If you're doing it with discrete logic and have a couple of spare I/O lines for RXF/TXE you could save yourself some glue logic.
Also I can confirm that the drivers are built into any vaguely recent version of linux - I have Ubuntu 16.04LTS on one machine and that just works - you can just do "cp data.bin /dev/ttyUSB0" to transfer a file to the 6502 system.

Oh, very nice!


So it looks just like a regular old (but presumably very fast) serial port to the Linux box. Also very nice. and I'm guessing you need not set a baud rate: it just works regardless of the serial settings?

For anybody else playing around with this sort of stuff, or /dev/ttyUSB* in general, I should mention that on not-too-ancient Linux kernels (at least as early as 4.19) you can look in /dev/serial/by-id/ for tty devices that are a little more stable, if you're unplugging and replugging several different USB serial devices. (This has worked well for me so far in distinguishing my Apple 1 clone RC6502 SBC from other devices.) I believe that some of the FTDI chips may actually allow you to change the ID that's present to the host so you could write software that will always be able to connect directly to a particular device or let you know that that device is not connected, no matter what other USB serial devices are also connected to your development system.

_________________
Curt J. Sampson - github.com/0cjs

Pretty much all FTDI USB interfaces can be programmed to some extent. The documentation for each chip will note this, either as MTP memory or the EEPROM. Nothing special is required, just their FT_PROG utility, which is a free download.

https://ftdichip.com/utilities/

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

_________________
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?

That's only one side of the transfer.... you still need something on the 6502 side to receive the data. If you only have a single connection from the 6502 system to your PC, likely used as a console (OS doesn't matter), then you need some sort of protocol to manage the data transfer and decide what to do with it, i.e., move it to memory (and what address location) or store or use it some other way.

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

Indeed, I'm trying to think through the options for a board here. The JLC inventory mysteriously disappeared, so I just ordered a handful from mouser and a breakout board to solder it to. I've been practicing SOIC, we'll see how SSOP goes...

Certainly seems easiest to "just" attach it to the CPU bus. /RD and /WR lines is easy enough to accomplish. I guess a 74HC245 would be very easy (but maybe overkill) way to stick TxE/RxE on a second address.

On the other hand, doing a 6521 PIA or 6522 VIA would make interrupt handling much easier, with a definite increased BOM cost. I guess without an additional 65xx peripheral, how would I do interrupt handling at all (with 7400 logic)? TxE and RxE are ORd together into an SR Latch, which is connected to a /IRQ and a qualified read of the TxRx245 buffer would also reset the latch? This should be fun to play around with.

_________________
https://github.com/Individual-Solid/

Well, I had another look around and I found cheap FT245s on breakout boards (basically, modules) on AliExpress, so I've ordered three of those. They cost almost three times what the chip itself does, but save me building essentially the same board for prototyping. So all I need is the address decoding design and I can hack together a prototype RC6502 board for this. (I'll be bringing a 4K I/O select to the bus from my CPU board, so I need to decode only some subset of that. I'll probably bring out the $D000-$DFFF select and do something that doesn't collide with the $D010-$D013,$D020-$D023,... of the Apple 1 clone's on-board PIA.)

(BTW, if this USB connectivity stuff, and espcially the following, is getting too off-topic for this thread, anybody should feel free to start another one and I'll redirect all my new replies there as appropriate.)


There is absolutely no special software required for this sort of thing on Unix systems, even in the general case. (Well, so long as the device drivers are sensibly written, as this one is.) If you have a program that does anything with data, you simply needed to have your editor feed the data into that program. (Even if the program must read a file instead of using stdin, this can be done with file descriptors reified into the filesystem: /dev/fd/....) In the case of this particular device driver, you can just feed it directly, e.g., in vim, ex, ed and similar editors just `w! /dev/tttyUSB0`, using any of the multitude of selection options before the write command.

But this is getting pretty off-topic, so my suggestion is that you take it as a general thing that if you want to do it, it can be done on Unix (which I've found to be far more configurable and customisable than any other OS) and if you need help with something in particular, feel free to get in touch with me via PM (or at least start a new thread about it).


Well, yeah, as with anything that communicates with anything else. But if you're already connecting to your board via some sort of "serial" (or serial-like) connection, such as this or a UART, you've already got that: it's whatever you're typing in there. E.g., in WozMon the "protocol" for the host to send data to memory is `0300:12 34 AB CD` to load those four bytes at location $300.

In case it wasn't clear, this "USB FIFO," as far as I can tell, works just like any other serial connection on the host end, and jsut requires a simpler driver on the microcomputer end. Basically, just like any other USB-connected serial interface but without bps rates, stop bit settings, etc. etc.

_________________
Curt J. Sampson - github.com/0cjs

I'm thinking that, at least on 1-2 Mhz systems, you'd never need a transmit interrupt because the data rate on the full speed (12 Mbps) USB link, even with overhead, is probably faster than the CPU can deliver data to the chip. But even if it's a bit slower, or there are large "chunks" of waiting at USB packet boundaries, it will still almost certainly be more efficient and faster to busy-loop while waiting for transmit than to use an interrupt. (I think you're almost always going to be servicing the interrupt immediately on returning from the previous interrupt!)

For reads, however, if you expect the host to be going long periods of time (as in, hundreds or thosuands of clock cycles or more) between sending chunks of data, yeah, you might want to do an interrupt instead of polling. (Or you might want do an interrupt anyway just because it fits your software system design better.) In that case you'll still probably be able to read many bytes at once in the interrupt routine, though.

I don't think you need to get fancy with latching the RD# for the IRQ line: it will stay low until you read anyway, which is just the behaviour that you want. You do want to be able to turn it off, however, so you should have a latch for on/off that feeds with RD# into an OR gate with an open collector output on your IRQ line. You need to be able to read RD# and TXE# for polling anyway, so both those and the receive interrupt enable latch can go into a '245 as you proposed and that will also let you check to see if it was RD# that generated the interrupt.

(This is all real arm-wavy on my part; feel free to correct any errors I've made, or better yet just design the circuit for me. :-))

_________________
Curt J. Sampson - github.com/0cjs

Well, I haven't gotten to the interrupts part yet, but still drew up an initial schematic that I'll probably start from.



an '138 provides PHI2 qualified /RD and /RW for the FT245R, and an /ENSTA (enable status) for the '245 buffering TxE/RxE. Right now input A2 of the '138 is drawn hard connected to A11. For the Wilson style linear decoding I'm using, I'd probably have a set of jumpers on board to pick which of A12-A4 is for the board.

I'll come back to think about interrupts this weekend, and also get my github updated with latest schematics of everything we've been discussing in this fun thread!

_________________
https://github.com/Individual-Solid/

I'll echo what cjs said above - you are unlikely to have any use for a TXE interrupt. Data is sent so quickly relative to the speed of a 6502 that, unless you're clocking the 6502 at 20MHz or more, or the PC pauses for whatever reason and flow controls the device, you'll rarely see TXE deasserted.
Regarding your schematic, note that whereas the RD strobe is active low, the WR strobe is active high. Data is latched on the falling edge of WR, so that needs to be coincident with the falling edge of the 6502 clock.

This is true, but for the moment I'm happy to have a fast way of transferring data to and from the 6502 system. Currently I just use a small assembler utility that just transfers a block of raw data from 6502 memory to the PC, or from the PC into 6502 memory. It's an 80's home computer where previously the only way to store code/data off the device was on audio cassette at 1200 bits per second, so it's a vast improvement on that. When I get round to it, I'll come up with some sort of protocol with a "port number" in each data packet so you can have multiple connections over the same wire. Then I can have a file system where the data is stored on the PC as well as a remote console and maybe even a network connection.