Turnkey get-started-fast solution

[faybs]

@kc5tja

I have a related but off-topic question for you... please check your PM.

[kc5tja]

You can always post questions regarding lib65816 in the emulation section of this forum too. lib65816 deserves some amount of publicity.

[GARTHWILSON]

Daryl and everyone,

About checking on the 6551 from WDC, I wrote to them:

Is there a fixed W65C51S in sight? We'd like to offer a low-cost board to help newcomers get going in 6502, and it would be nice to include one or two 51's on it.

(I should mention that in the "Company" field in their contact form, I put "6502.org".) Bill Mensch wrote back and said: (I'm sure he won't mind my pasting this in here)

Hi Garth,

We are very close to wrapping up the next tape out to have new devices built. We should have new silicon in the May-June time frame. Hopefully these will be fully functional and production-ready.

Thanks for including the '51 in your plans.

Best Regards,
-Bill

William D. Mensch, Jr.
Chairman & CEO
www.WesternDesignCenter.com
65xx - Yesterday, Today, and Tomorrow.

[8BIT]

That's good news. The datasheets are now claiming 14MHz rating vs. the 6MHz that I recall from last year. We (6502.org colectively), should start collecting pre-order quantities so we can do a bulk purchase once they are in production. You can put me down for two DIP and 2 PLCC.

[kc5tja]

The only problem I have with the 6551 is that, as far as UARTs go, it's woefully underpowered. Yeah, I suppose it covers most of the "usual cases," but it's not like the Paula's UART at all.

[GARTHWILSON]

Quote:

I suggest using standard pin header pads on the board and using the 90 degree pin headers and using standard ribbon cable to tie the boards together. This should prove less expensive than the stackable connectors.

A neater solution that's at least as cheap would be to use board-mounted sockets for the pin headers, like Jameco's part number 105056 at just over a dollar each for a 15x2 which is enough for an entire VIA's I/O connections plus power supplies, grounds, and a few other things. It can't practically be put directly on the back of a pin header to be like the stacking male/female headers, so there would have to be an offset. I don't see this as a huge drawback though.

6502.org wrote:

Image no longer available: http://www.jameco.com/Jameco/Products/ProdImag/105056.jpg

[faybs]

kc5tja wrote:

The only problem I have with the 6551 is that, as far as UARTs go, it's woefully underpowered. Yeah, I suppose it covers most of the "usual cases," but it's not like the Paula's UART at all.

If you use the "phi2 divided by 16" baud rate you should be able to get over a megabit per second, unless I am mistaken.

[kc5tja]

faybs wrote:

If you use the "phi2 divided by 16" baud rate you should be able to get over a megabit per second, unless I am mistaken.

Correct, but your choices for other parameters are more or less limited. The Paula chip exposed 12 bits to the programmer, allowing the coder to select precisely how the data was sent, and could even, if he so chose, send data with Huffman compression. The only requirement was that all data words were frames with at least one start bit, and at least one stop bit.

Let's assume that you wanted one start bit, one stop bit, 8 data bits. Then, for each byte you'd send, you'd need to send it like this:

Code: Select all

ASL
ORA #$0200  ; set stop bit
STA TXOUT

Note the manual framing: ensuring bit 0 is 0 for the start condition, and bit 9 is 1 for the stop-bit condition. In this way, you could send any arbitrarily sized data. Paula knew when to stop the transmit clock because the end of the data frame occured only when TXOUT==$0001.

Pretty slick. And a whole lot less hardware required to make it happen to. Oh well.

As far as speeds are concerned, if you want truely programmable clock rates, you can feed its PHI2 input with the output of a programmable frequency divider. However, you'll need one of my clock synchronization circuits to talk to the chip. Paula, OTOH, had its own arbitrarily programmable down-counter (like the kind you see in a VIA chip), whose output directly fed the transmitter and receiver.

[GARTHWILSON]

Quote:

If you use the "phi2 divided by 16" baud rate you should be able to get over a megabit per second, unless I am mistaken.

You can use the 16x clock input to get arbitrary speeds, but the previously available hardware (up to 6MHz from CMD IIRC) was limited to something in the neighborhood of 100-200kbps. Maybe WDC's new ones will be able to go faster. Again, what I've done to get MIDI's odd 31.25kbps with the 65c51 was to use a free-running timer on a 65c22 to toggle PB7 at 500kHz and run that into the 65c51. You're not limited to 500kHz of course. You can set the frequency by storing the T1 re-load value in the '22, and let it free-run without further attention from the processor.

The '51 is easy to use in some ways, but has various limitations. One is that it does not have multi-byte buffers, so the processor has has to be able to service it every single time a byte goes in or out.

[faybs]

GARTHWILSON wrote:

The '51 is easy to use in some ways, but has various limitations. One is that it does not have multi-byte buffers, so the processor has has to be able to service it every single time a byte goes in or out.

That's probably the biggest speedbump. Given that 32 bit 486s running at 66MHz needed a 16550 with its FIFO to handle higher bit rates, it's possible that a humble 6502 or 65816 running at less than 20MHz may not be able to cope without similar help for higher bit rates. Do they still make discrete 16C550s?

[GARTHWILSON]

Quote:

Given that 32 bit 486s running at 66MHz needed a 16550 with its FIFO to handle higher bit rates, it's possible that a humble 6502 or 65816 running at less than 20MHz may not be able to cope without similar help for higher bit rates.

The 6502 has really much better interrupt performance though. It is not unreasonable to have an entire interrupt, including overhead, get carried out in one microsecond at 20MHz on a 65c02. An x86, if it is running Windows CE, can't do that at any clock speed! Of course to do it in 1µs, it will be too simple to service the '51; but if you have a lot of other interrupts going at once in a real-time system, it might be nice to have the flexibility offered by the multi-byte buffers of other UARTs. In my article on zero-overhead interrupt service in high-level Forth on the 6502, I mention that on the system where I developed this, the RS-232 input from the PC for software development was handled at 9600 bps through a 65C51 ACIA entirely by interrupts in high-level Forth (not assembly language) on a 2MHz 65C02.

[kc5tja]

Let's not forget that the 7.15909MHz Amiga could handle 1.5Mbps through its UART provided you polled the port with interrupts and OS multitasking disabled. I can remember at least one Amiga-specific networking system placed in the public domain which utilized this approach.

You can, for example, define your protocol so that it's normal interrupt-driven, byte-at-a-time communications by default, but when you need to burst, you could disable interrupts, switch the UART into megabit-per-second mode, and just babysit the port for however many bytes you need. ATM cells, for example, are fixed in length (53 bytes), which means you can eliminate the "am I done yet?" checks that you'd otherwise need to perform. If you simply must have the ability to check for termination of a packet, you can do so by either slowing the overall data rate down to allow enough time to do this check, OR, you can pass a count as part of the "slow-mode" setup phase of the protocol, and use it to jump into the middle of a function.

For example,

Code: Select all

jsr slowGetByte
asl
asl
asl
asl
asl
asl
asl
asl
pha
jsr slowGetByte
and #$00FF
ora 1,s
sta 1,s
asl
adc 1,s  ; assume carry bit is clear
sta 1,s
clc
lda #GrabPacket-1
adc 1,s
sta 1,s
rts

GrabPacket:
jsr GetFastByte  ; byte 0
jsr GetFastByte  ; byte 1
...etc...
jsr GetFastByte  ; byte MAX-1
jmp GetFastByte  ; byte MAX

But, realistically speaking, with 12 cycles of overhead between the JSR and RTS instructions, you might as well just do an explicit check and make sure your UART is slow enough to not overrun the CPU.

[lordsteve]

Is there a law that says you have to use an actual UART as a UART? Why not use a cheap less-than-three-dollars-in-single-quantities microcontroller that has plenty of ram in it for a few buffers and plenty of IO lines for multiple UARTs, if desired? The chosen microcontroller would not have to be programmed by the board user; it would just be a UART or whatever you tell him it was and "factory preprogrammed". All the trouble with baud rates and inflexibility could go away and perhaps the microcontroller could be purposed for multiple jobs. It's a UART/keyboard/mouse/eeprom programmer thing.

Maybe that's the issue with an educational board...the user knowing how every piece works. But maybe the focus is rather on getting low-cost 65x systems to the kiddies and not education. I don't know.

If I were to do this board, I would have a microcontroller that could do 75-100 MIPS sitting on the board which would be hooked up to a serial terminal. The micro would also clock the 65CX processor. That's right, clock it. With such a getup, you could send commands to the micro and implement single-step debugging, register/variable watching, dump/watch memory, breakpoints (address OR data), etc. If those things weren't desired, the micro would clock the 65Cx processor at full speed: 20/14/12/whatever-you-want MHz.

The micro could also do the address decoding between SRAM banks by watching the high bits of the address lines.

That $3 micro could also be used to boot 64K of RAM from a 64K serial EEPROM. The micro could program the EEPROM when it's attached to the terminal (or hyperterminal on the PC). No run-time sobbing about wait states from slow EEPROM. 24C512 EEPROMs are cheap.

The same micro could also be used to interface to an SD card for nonvolatile storage. Why worry about all the different EEPROMs or EPROMS or FLASH. SD card's are cheap and so are their PCB-mount sockets. They also have tons of capacity. To make it happen the micro could watch for the COProcessor opcode by watching the data bus and the SYNC(?) line. The micro could be memory-mapped, watching for addresses that talk to it (it may be doing address decoding for SRAM chip selection already anyway).

You may disagree with any or all of this...but there are lots of options there and they sound pretty inviting to me, especially when considering a medium-powered, low-cost board for beginners...especially the debug options that possibly don't plague the 65Cx with special-case software just for debugging.

rough BOM to make simple system happen:
24C512 serial EEPROM for booting
2 32Kx8 SRAMs1 for run-time main memory
65Cx processor
1 <$3 microcontroller for clocking the CPU, UART (host machine), bootloading, debug, DMA, address decoding, your wildest dreams, or some combination of these
1 MAX232 or clone
right-angle DB9 connector for serial comms to the host terminal
VIAs/PIAs if you still like

A lot of this is off the top of my head, sorry for any incoherence. Oh, and I may know just the microcontroller!

[8BIT]

Lordsteve,

While I like your ideas, I think the idea here was a basic platform for new folks to get started with. A simple set-up with CPU, RAM, ROM, and simple IO.

However, your idea would be great for an advanced system. I have been working with AVR controllers for ethernet and FAT16/32 interfaces. The UART is onboard as well, making those a good choice for IO controllers. They do not have the MIPS you described, most are 16Mhz parts.

What microcontroller did you have in mind? I would like to work with something that has 75+ MIPS that does not require complex interfaces.

Daryl

[GARTHWILSON]

For many applications, I would favor some microcontroller support. Even 100MIPS would not be nearly fast enough to use for the actual address decoding, but there are I/O functions that would be good to make a semi-standard part for. SPI functions at 40Mbps transfer rates might be a good example. A modern video driver with a large video RAM is probably not something we could do with any microcontroller. It would be great to make the part interface directly to the 6502 bus with a top bus speed of at least 16MHz and give it a 65xx number.

That may be for a separate forum project though. Right now the point is to keep it simple. I got started in 6502 in 1982 on an AIM-65, and at that time, even the monitor program and other stuff in ROM was mysterious and I felt like there was something I wasn't supposed to understand. I didn't like it that way, but I suppose it was the only practical way for the class to be taught at the time.