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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Right. And this is exactly how USB serial works, at least on Linux. The USB serial driver in Linux simply pops up a new /dev/ttyUSB0 (or whatever number) device and you use this as you'd use any other /dev/tty* device. (Reading and writing the device sends and receives data. Using a standard set of ioctl() facilities lets you set data rates, stop bits, etc.; the stty program offers a command line interface into this.)

That said, the internals are a little more complex than I'd thought. I'd assumed that all or most USB serial interfaces (including devices like the FT245 that just present as a serial interface) used the USB CDC (Communications Device Class) which defines a standard protocol for doing things like setting bps rates, start/stop bit configurations, and so on. (It's described in §6.2 of the 1999 standard.)

But apparently a number of vendors work slightly or significantly differently from the standard USB CDC interface, and the Linux kernel is internally selecting from a number of different drivers depending on what it's detected. That said, I don't recall ever plugging in a device that I expected to present a serial interface that didn't Just Work.

The interface the user sees in Windows is perhaps more complex than this, though I'm sure I've seen generic USB serial driver frameworks for it that work more or less like the above. But yeah, if you're doing development on Windows, it's worth checking out whether you really want to go USB here.


No, 35 Mbps is about three times the speed of USB 1.0 Full-Speed, which is 12 Mbps. USB 2.0 High-Speed is 480 Mbps. 33 feet is about 10 m, so RS-485 does offer twice the distance of USB at 35 Mbps, or much, much more at lower data rates (65 m at 1.5 Mbps, which is the USB 1.0 low-speed rate, or 1200 m at around 80 kbps).

But obviously the limiting rate here for most of us is going to be how fast the computer can run, not the communications medium. Even 65816 running at 20 MHz is going to be hard pressed to handle a 10 Mbps data stream. (That's about the maximum FT245 rate, as it happens.)


Well, that's pretty much the USB FIFO situation when viewed from the "just buy the chip, connect your device to the simple parallel interface, and plug the USB cable into your host computer" point of view. One of the things I like about it is that it gets rid of having to deal with bps rates, bit counts, stop bits and all of that. (On Linux you can still set the port speed, but it's ignored and always just runs at the maximum speed possible, blocking when the FIFOs are full.)


Ouch. Again, a place where Linux shines: the driver for FTDI chips is open source and maintained by non-FTDI coders as part of the Linux kernel, so code like this can't sneak in.



You might be surprised at how much you understand. "Das computermachine ist nicht fuer gefingerpoken und mittengrabben...."

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

I looked into what was necessary to add a USB keyboard and mouse to a project. Wouldn't it be handy if there were a single connector, protocol, and operating speed?

Most keyboards use a USB-A connector and operate at 1.5Mb/s; some use 12Mb/s; and I'm sure there are some out there that use 480Mb/s (anything to keep the gamers happy, right?). To further complicate, if you want to use a wireless keyboard or mouse (assuming it has a USB dongle, and not a proprietary Bluetooth or similar mechanism) then one option for the dongle is that it contains a hub presenting two devices. Which means you're looking at not one, not two, but three protocols which need managing...

I have been searching for what seems to me to be an obvious solution: something which has a UART (or two) on one side and is capable of talking to *at least* USB1 and USB1.1 HID devices and hubs. I have not found one. I have come across a couple of cases where a single keyboard or a single mouse can be converted to UART (but using different firmware in the adaptor chip, and unable to handle a hub connection). So while this is a solution which may work for a specific case (e.g. a generic keyboard only) it doesn't work in the general 'attach anything to it' even if anything is merely a keyboard through a hub.

Looking into processors which provide USB facilities I find lots of examples of how to use them to *be* a keyboard or a mouse, but very little on how to make an OTG general USB port using them, even from the manufacturers.

In short, we had an easy way to attach a keyboard and a mouse thirty years ago, but we seem to have complicated it into incomprehensibility. At the moment, it looks as if the best way is to use PS/2-connector equipped parts (though even there there is a protocol to contend with that is somewhat more complex than one might like for a simple system). But with all that said, using a UART to USB adaptor part remains an easy way to use a terminal on a computer to talk to a 6502 system, even if the computer running the terminal could emulate the 6502 significantly faster than the 6502 can!

Neil

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

There is; it's called PS/2. :-P (Though apparently it wasn't so handy, because almost everybody switched to USB. Perhaps "I want to wire up a keyboard on an SBC I built myself using an ancient CPU" isn't the biggest use case here.)


Actually, even USB keyboards may present as a hub with the keyboard behind it. If your keyboard has additional USB ports (so you can plug your mouse into the keyboard, rather than the computer) or has a built-in pointing device it must present as a hub.

BTW, Bluetooth keyboards and mice don't (usually) use a proprietary protocol; they run standard USB HID over standard Bluetooth.


Yeah, you can get close with one of these:

They used to be moderately common, but seem to have vanished now.


It doesn't seem to be that hard to find this stuff; a quick look around turned up ST's STM32 USB library (which does include host support for hubs and various devices, including CDC and HID), and this USB keyboard to PS/2 port converter project that appears to use it.

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

This sounds like an editor issue: if you can tell your editor to write the selected block to /tmp/foo.txt you can tell it to write to /dev/ttyUSB0 in the same way.

That said, depending on the driver, you may need to hold the device open both to configure it and to avoid a configuration reset when everything has it closed. The easiest way to do this is to cat /dev/ttyUSB0 in another window (if you want to see the output, otherwise just cat /dev/ttyUSB0 >/dev/null & to make the output quietly go away in the background). You can then stty -f /dev/ttyUSB0 --all to see the current configuration and replace --all with configuration commands to change it.

If there's a standard configuration you always use, it may be easier to write a script that just takes whatever you give it on standard input and configures the port for you and writes it. And, if you're like me and may have more than one USB serial adapter connected, this can be tweaked to find the right one (using /dev/serial/by-id/...) as well.

If this isn't enough, feel free to PM me and I'm happy to help you work out the details. I actually use scripts like this myself, so I'm open to improving on what I've got and distributing it to others.


If you're talking about getting it working under Linux, that won't help with your problem since your interface to ttys is the same regardless of whether the upper-level tty driver providing the interface is talking to a lower-level USB serial driver or lower-level UART driver.

If you're talking about DOSBox on Linux, my understanding is that you just need to configure it with serial1=directserial realport:ttyUSB0 to use your USB serial adapter.

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

I do plan to dive into the 6522 and it has some interesting audio and DAC/ADC opportunities. For this system, I have been doing a lot of digging and I think I am going to build for the PIC18FxxxxQ71. It has DMAC, ADC/DAC, OP Amps, Comparators, a 8 macrocell array and several timers. It houses adequate RAM, Flash and enough assignable pins it can interface with the 65xx address and data busses directly as well as support a few control lines and other devices. They cost https://i.gifer.com/DBce.mp4 Since I plan to use PIC controllers in several other designs, it is as good a choice as any and given the size and space constraints, probably the best choice, it does increase my complexity of implementation in some ways, and simplifies it in others.

I also found the super tiniest 32.768k can, https://www.microchipdirect.com/product/VC-889-EAE-KAAN-32K7680000TR if I still want one, I think the 'Q71 has this covered though... Ill post another post after this specific to that chip, after I respond to two pages of dialogue and commentary
it is more that Id have one extra, to me it is like having the demultiplexing latches for a 65816, it is just something you do. 2 extra modes for a couple of pins on an IC?!
___________________________________________________________________________________



the problem was 'can I plug this in and "just have it work"

Plug and Play
I would be a "Cantankerous Curmudgeon" myself.

I am planning to use the FT240X IC for USB as the 'Q71 does not include onboard USB. The Max14748 or prolific MA5889 to possibly charge batteries, I need a way to get data on these chips somehow, its this or a jumper port on the board... USB is ok. I am not certain I can solder 0.65mm SSOP or the QFN by hand, which precludes a major design point...
This sort of thing is why I am leaving user space on the board for 'whatever the builder wants there'
______________________________________________________________________

yeah it is not a design decision to take lightly and I certainly at this level see 'why' different choices are made. Lets go with 'I prefer a buss system to bike paths'. I may use SPI/I2C in the future or even on this design, especially to control the screen. at this point, its make things as 'plain' as possible, as few protocols or extra steps, and to try to make all devices 'homogenously connected', it simplifies things and helps reinforce the bus mentality I want to use later about 3/4" just shy of that with the 'lip' of the can.
yeah... so two designs in an Altoids can, one is how you are thinking, a clamshell you open with the screen and controls inside (D-pad and 4 buttons). I call this 'type II'. Id put the screen inside the lid like a laptop, and controls 'in the can'.
Im building a bit different, "type I", with the screen and controls glued to the top of the can outside of it, and you only open it to change batteries or fix stuff. the Altoids can is a bit of tradition, once this is working, I plan to use a nice enclosure I found that is much larger and sturdier for future use.

_____________________________________________________________________

next post: more on the Q71 and current designs!

the 'Q71 has an NCO (and a buuunch of waveshaping toys!)
'Q71 has this ability I think!
... Nyquist ... Got it!

totally going to just use an IC solution here. One complicated problem at a time, it really just needs its software updates and charging port. Mostly charging...


Ich sprechen zehr klein Deutsch in seibehn grade. (my spelling is as good as my pronunciation )

USB complicated, open source good, gotcha.

ah yeah I have other designs that 'might have all that', for this, its basically an 8-bit input, 4 way D-Pad, 4 buttons, probably an on off switch or reset maybe... USB would just be to write stuff to the Flash storage on the PIC or to charge a battery... not sure how many design challenges to solve on this implementation... I might have a desktop 6502 I build in the future with a KB and Mouse. idk if Ill use USB for those.
Yeah I am not so sure I want USB on here, I might break out the pins on the perfboard to use a programmer instead and just use rechargeable AAA batteries.I used Linux 15 years ago and switched to windows for college classes that used commercial software. I am probably going to a BSD variant in the near future, especially for development purposes.
part of why I am building the Integrity it to address legacy support concerns like this. For now, a minimal Game and Watch in a mint can would be accomplishment enough. In the "user extension" area, one can use an RS-232 on a DB-9 if desired. FTDI makes a parallel version I think that should drop in for the 240x series USB option intead. So even in this design user extensibility and customization is forefront, and to the extent possible, this will expose the full CPU/6502 "buss".
I am not planning to have antennae of any kind in this device at this time, however, you could add one in the "user extension" area of the protoboard! good to know for future designs!
I am sure they exist somewhere and you can add one to the user extension area of the protoboard to your liking!
yeah the whole system is basically going to be that size, I dont need a USB KB and Mouse on this build, though you can add one through the user extension area of the board if you want!
I might look into those in the future. Have you looked at the ST7/8? they are remarkably similar to the 6502.


Part of why I am building the Integrity platform is to address legacy support concerns like this!!

So going back to the basic design, it is looking like a PIC18FxxQ71 as the support chip.
such as the: https://www.microchip.com/en-us/product/PIC18F56Q71

https://ww1.microchip.com/downloads/aem ... 002348.pdf

while the Q43 seems more suited to a larger system, https://www.microchip.com/en-us/product/PIC18F55Q43, it has more DMA channels etc.

Either 4xQ71 or 5xQ71 will be used as they provide adequate pin count for interfacing with 6502 busses. 37 or 45 assignable I/O pins on the package.

the Q71 has both SPI and I2C if desired, ADC and DAC, an NCO and Waveshaping Generators.
There is an 8 Macrocell array. PWMs, Timers/Counters, Flash, EEPROM and RAM. It has 2x UARTS.
There is a Real Time Clock and a Watchdog. it is 1/5th the price of the 6522 and runs at up to .. 64Mhz with PLLs.

so I am reading the 1000+ page datasheet, little by little. It is comprehensive and a good reference.

the 6502 will have something like 4k or so of "Lower Ram", maybe a bit more.
it will connect possibly to the screen, to RAM and to the Q71. It doesnt need to connect to much more.
I am looking further into the Q71, I may or may not need a 76489 sound generator. I may want extra op-amps or a volume control on the headphone jack or speaker.
If I can, Id set the Headphone Jack up as able to be used as a probe or microphone as well for other experiments.
It is an interesting setup, I think I can 'build a sound card" out of the Q71 analog circuits, and run the display as well.

The Q71 Flash will hold both the Q71 Routines and the 6502 ROM for program code etc. I am looking further into if this chip will do what I want, and expose its RAM and ROM and registers/circuits, to the 6502 if configured for its data and address lines. There is some concern that this will not be as 'direct access' as required, even though the Q71 will be running 4 or 8 times as fast as the 6502, it may require that the PIC copy out things to RAM for the 6502 to use, the nuances here are not obvious, though it does seem possible.

If anyone has experience getting a PIC device to expose its RAM/ROM to the 6502, any caveats or advice would be quite helpful.
I am going to update the first post later with new drawings, charts, links and descriptions.

6502+4k/8k of SRAM starting at 0x00.
PIC18x6Q71 providing support, I/O and sound synthesis
power, small LCD screen, speaker/headphone jack
user extension area for other chips... this might end up being a few pin headers on 2x proto-boards.

challenges now include sizing, level selecting, power, space, configuration etc.
the Q71 should open a lot of doors... I do like maybe having 2-6 pins for 'whatever' wire i want to connect with.

I have a few questions about the Q71 analog circuits and how they might be used. Im ordering one in DIP shortly to get started, maybe a dev board for it plus the 6502 and some RAM. The question then is. how many "pages" do I want in lower RAM? minimum 2 Pages for Zero Page and the Stack. That's 512 bytes right? 4Kbit? I think Id go with at least 1KB then, really need to check costs. Id want nice fast 55ns or faster SRAM, right there all but soldered leg to leg on the 6502... I might piggy-back them as shown earlier if it makes sense to do so. If I go with 'multiple stacked protoboards', then the 6502 and its RAM go right next to each other and I think I want this where like the 'first chip' is pretty much only wired to the 6502, and any other chips might be used by the whole system, shared for I/O.

I'll update the front page and gather more datasheets. Couple of questions I posted here already, I'll have better questions later tonight.

That's not a normal thing; MCUs normally don't have any external address and data lines because why would you do that at the cost of I/O pins? And then there still would be the issue of the bus protocols, and stopping the MCU while an external device used its memory, and so on.

But emulating Motorola 6800 or Intel 8080 bus devices (including memory) using the I/O pins is a common technique used on fast microcontrollers.


That may not be fast enough. Mostly where I've seen an MCU emulating a bus device, it's been with at least a 16 MHz AVR for a 1 MHz CPU.

If you take the route of the MCU emulating RAM and ROM for the CPU, you don't really need any other peripherals at all. You can even get it to generate the clock. Tadashi Takaoka has been doing this with a 16 MHz AVR for quite a while with projects such as his Z80-MBC2. I've not talked to him for a while, but it looks like his RetroCyborg project is doing this for a lot of different CPUs. And I'm sure a couple of folks around here have done something similar, though I can't remember who off-hand.


That can be done, though you'll also need to handle halting the CPU so you can do DMA to the RAM on the board (unless you're doing it only during the ϕ1 cycles). The C64 supported this and it was used for things like the REU (128K-512K RAM Expansion Unit). There are a fair amount of details about this on the 'net.


I'd probably just put 64K in the thing, though some of the address space would be decoded for ROM and I/O. But the minimum is even smaller than two full pages. On the smallest systems it's normal to have as little as 64 or 128 bytes, with 6502 systems doing this decoding that in both the zero page and the stack page (i.e., $00-$3F and $100-$13F access the same RAM). The Motorola 6802 even had 128 bytes of RAM on board the CPU itself.

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

you seem to say what I propose is odd, then say the same thing I was thinking. There are many videos about using an MCU to act as RAM/ROM (especially ROM) for an MPU like the 6502. I think there may be a bit of a misconnect here. I am not suggesting doing anything strange or unusual that is not explained in great detail on youtube.

if there is a heuristic for matching these devices., it is good to note


So cost is a factor, and while I can get smaller ICs, 32k is pretty cheap and I need about 8k for a single buffer of 1bpp@128x64, plus zero page and stack... its just cheap enough to grab.

I updated the first post with some design choices, I am leaning away from an MCU, its just too much complexity and too much space.
It is better to run a 6502, RAM, ROM and the video connector and the clock. If somehow I can fit a few audio circuits or an I/O port so be it. The core system will be 6502, 32k RAM, 8/32K ROM (8k is only $5...) and the ST7xxx 128x64 screen and a buzzer, maybe an audio IC somehow. a nice RTC would be cool if it fit the board,

Im leaving the final design open a little longer,. to see if I can get a TimeKeeper RAM IC with RTC built into ram to use. That would be ideal. The design has been simplified, no 6522, no PIC, just a 6502 running a screen and some buttons, mybe a clock and soundcard.
At least for this. Further projects might get more features, Id love to put a sensor in here, there isnt room.

Constraints (both physical and intentional) dictate this be as minimalistic as possible. First post has a revision. More work tomorrow.

I think you said something you didn't mean to say. If you use the usual method you will not be "expos[ing] its RAM and ROM and registers/circuits"; these will all remain only privately accessible to the CPU within the MCU itself. You'll be simulating RAM and ROM on the external I/O pins, but that will not be a direct connection to the MCU's memory, but the MCU's CPU accessing the MCU's memory and then placing data on the MCU's I/O ports. (Or maybe not even accessing the MCU's memory; for some things you might instead just calculate what "ROM" data you want to put on the I/O ports.)

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

if you want a simple interface between an MCU and the CPU, i recommend SPI! every modern MCU supports it in hardware it.
have the MCU be a slave device and the CPU the master.
while relatively slow (especially if the CPU bitbangs the interface), it won't take up as many IO pins on the MCU as a parallel interface. plus you'll never run into bus contention issues that come from bi-directional interfaces bewteen differently clocked devices, that could require extra circuitry to avoid.

also once you have SPI you can connect a lot of other things as well. SD Cards, RTCs, small displays, various sensors, etc. or just have some headers that you can plug SPI modules into so they don't take up more space on the PCB.

this is probably; I should simplify and say "use the mcu as RAM and ROM"
at this point however, I am not using the MCU, its just too big (too many pins) and a lot of extra work (a whole other architecture!)
so I will save that for the next one


I am avoiding a lot of chips on here and plan to just use the basic busses, everything, needs to fit in an altoids can, and be hand assembled. SPI is probably going in some other devices later, though Im more likely to implement ISA, lol
on this system, it just doesnt make sense to use right now.

What I really need to figure out now, is which 128x64 mono LCD for under $20 to use.
UC170x, ST7xxx or similar chip?

system is simplified to:
6502, RAM,ROM, Clock and Screen (with controller built in)