The Proto65 experiment gave me a couple ideas and I want to explore them separately.

The purpose of Proto65 is to have a flexible, programmable logic fabric to check out parts from eBay. Flexibility is expensive, so once the unknown parts become known, the design can be pared down significantly. There is no question EPM7192S is an overkill for 6502. To fill the void, the Proto65 project is adding more features to fill up EPM7192S, but another approach is shrink the CPLD to fit the current design. There are no doubt a EPM7128S (same as ATF1508) can fit the current design (Proto65 V0.2), the more interesting question is whether EPM7064S (ATF1504 equivalent) can fit. ATF1504AS-10 is about $3 from Mouser so that will make it a frugal 6502 SBC.

It is easy to re-target the EPM7192S design to a different CPLD and at the first glance, it won't fit the EPM7064S; the I/O pins can be trimmed to fit, but the logic is 150% of EPM7064S. The two big consummers of logic are the serial port and bootROM. While the bootROM is 64 bytes in size, it is constructed of combinatorial logic. The large fan-in does consume some macrocells, but cutting bootROM from 64 to 32 bytes do not make up for the 32 macrocell deficit. The other possibility is the serial port. A hardware serial receiver is needed to handle high speed (115200) serial input and to keep the boot ROM small; serial transmitter, on the other hand, can just be bit-banged with software. So by replacing the hardware serial transmitter with a flip flop, the design actually fit! 100% of I/O pin and 97% macrocell utilization.

To make the design fit the 32 I/O pin of EPM7064SLC44, some address lines are sacrificed which make the memory map less efficient. The memory map looks like this:

0xF800-0xFFFF is internal ROM
0xF000-0xF7FF is internal I/O (serial port and I2C)
0xE800-0xEFFF is external I/O (IDE interface)
0x0000-x0E7FF is RAM

To summarize, the goal of CRC65 is a frugal 6502 SBC with the following spec:
* W65C02 operating at 14.7MHz, nominal
* 58K RAM based on 25nS CY7C109
* Compact flash interface
* EPM7064S (ATF1504AS) CPLD with the following resources:
* 64-byte ROM, dual boot either from serial port or CF disk
* Serial port at 115200 N81, hardware receiver, bit bang transmitter
* I2C, bit bang
* RAM decoding
* Compact flash drive decoding
* Economical 2-layer PC board.
* PC board size goal of 100mm X 50mm, so 2 pc boards per 100mm X 100mm panel.
* CRC65 stands for CPLD_RAM_CFdisk_6502, the major components of the 6502 SBC.

It just so happen I have a EPM7064S prototype board all ready to be wired up.
https://www.retrobrewcomputers.org/doku ... o:protorc3

Gosh, what a coincidence!
Bill

This is incredibly impressive and shows what a 65C02 can do at 14mhz. The idea of bit banging 115200 seemed mad until I noticed how fast you were running. I hope you put a few of these up on eBay when you finish the PCB, I would gladly grab one.

It is rather early in the design to think about selling them on eBay. I will certainly make them available if I'm successful.

Bit banging actually makes sense for high speed serial. In absence of a deep FIFO, the overhead of interrupt service is such that CPU is better off just polling. In that case the CPU can spend its time spin on transmit empty flag, or it can roll up its sleeve and bit bang the bits out. It is the same difference.
Bill

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

Hmm... I see bit-banging 57,600 with a 1MHz 6502, and similarly 115,200 with a 2MHz 6502:

Bit banging serial comms with a PIA
1Mhz 6502 bitbang 57kbaud

6502 may very well be better at interrupt handling. I don't know enough to have an opinion. I do know file transfer at 115200 in Z80 CP/M environment is best done without the overhead of interrupt. It may not be an apple-to-apple comparison.

I found my EPM7064S prototype board and build it up and programmed the CPLD. So I'm off with breadboarding of CRC65.

Bill

Thanks for the links. CRC65 clock is 14.7MHz (I probably will start with 7.3728MHz) so each bit of 115200 is 128 14.7MHz clock or 64 7.37MHz clock. Those are nice integer numbers, so I should be able to pad enough 6502 instructions to get it right. Beside serial communication can tolerate few percent of mismatch in baud clock so even if I messed up counting instructions, it probably still work OK.
Bill

I did 9600 send and receive bit-banging in software (half duplex though) many years ago on a 1Mhz 6502 system. I don't recall really trying to do much to tweak it as it just worked when I first coded it, so left it...

Your system might run BBC Basic too - I have a nice little system that does that myself - however writing the filing system in 6502 may be the challenge there though.

Cheers,

-Gordon

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

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

In the Z80 world, CP/M reign supreme so there is a well known common environment to measure interrupt performance against. XMODEM in CP/M is a common file transfer protocol. You can imagine the management of circular buffers, CP/M BDOS function & BIOS calls can add up to significant overhead. 6502 world may not impose such rigid OS overhead for an interrupt service to fit in. I'm unfamiliar with 6502 applications to judge the lost of performance due to bit bang vs UART with deep FIFO. In any case, this is just a console I/O to get the hardware running. For applications require sophisticated serial ports, I have plenty of OX16C954 quad UART.
Bill

Perhaps the misconception comes from the slowness of bit banged serial on the older, widely available machines we used when they were commercially available.

I thought about it a bit and remembered that Dolphin DOS pushed the C64 to ~70Kbps under certain circumstances so maybe my initial reaction was unwarranted.

A mock up of what finished CRC65 prototype may look like.

So it begins...

I know you aren’t there yet, but will be really curious to see how you implement the Compact Flash.

There is are several threads on that topic here, as well as a new implementation of FAT32 for the 65C02 on GitHub that is open source:

https://github.com/commanderx16/x16-rom ... /dos/fat32

Currently I use the CF disk as system and application program storage. I have not developed any filing system so I only use track 0 to store programs like monitor, and EhBASIC. The master boot record contains the bootstrap code that's read into memory and execute immediately after power up. The bootstrap program is small enough that it does not encroach on the partition tables located at 0x1BE to 0x1FD, so the conventional file systems can coexist on the CF disk.

I have used CP/M on Z80-based systems. I'm a 6502 newbie and have no experience or preference regarding file systems.

Bill

I'm following with interest to see where this goes. I was unaware of the CF with Fat32 just alluded to here. I was aware of the Symbiosys version using only 8 bit IDE transfer to CF by House Harris viewtopic.php?f=2&t=1696 which works well on my Sym (I used an inexpensive DS1301 board for the date stamping).
I also have looked at Daryl Rictor's website which has an SPI to IDE interface to CF. I have worked with the various Multicomp implementations using the board using the low cost Cyclone II version and SD card on the Retrobrew site. On that system I implemented a monitor based on Daryl's SBOSlite for the 6502 and used the code of Maik Merten for FAT16 reading from the SD card to get code to the board. Even though I can use that code to read and write "sectors" or blocks of 512 bytes to the SD card I have yet implement the OS. I have a version of FIG-Forth that runs on that system in limited fashion (for screen reading a section of the SD card).
I would like to get the Symbiosys working first (in another region of the SD card) and then implement the DOS/65 of Richard Leary for the Multicomp and SD card. My programming skills are somewhat limited to patching and improvising others code so I haven't really tackled the hard bits yet. In the 80's I had DOS/65 working on both the KIM-1 and SYM with floppies and could read sectors from CP/M machines. When I resurrected my SYM-1 a few months ago my original FDC-1 floppy controller hasn't been reading my 40 year old floppies, hence the IDE to CF interface from House Harris. I know the floppy drives work as they work with the COCO3 and disk controller. But non-magnetic media is obviously the way to go at the current time unless you really want to stay "old school".
I am benefiting greatly from the hard work of others in this forum even though my skills are way behind those who are working in the programmable logic and emulation areas that make my "6502 first love" possible again on relatively current hardware.