Okay...I finally decided to get a real C-128D instead of making do with WinVICE (although 80CDM (http://www.commodore128.org/index.php?board=69.0) and CC128 (http://www.commodore128.org/index.php?board=72.0) were both tested and debugged in VICE). The "D" should be here soon. Only thing I'm missing right now is an RGBI monitor to go with it.
Also sitting on the shelf awaiting a call to duty is a Lt. Kernal hard disk unit. With this hardware in hand I may suddenly get the urge to step back in time 20-or-so years and do some eight bit database software engineering. Of course, this being 2010, no one would actually have a need for anything of the sort, eh? And, if I did do it, I'd have to multiplex a second 128 to the Lt. Kernal to test file and record locking semantics, as well as inter-port communication. Nevertheless, I've got far more powerful development tools than what existed in 1990â€"all editing and assembly will be done on my UNIX development system. So whatever I decide to do will take less time and hopefully be more refined. :)
One of the little "infrastructure" items I have to settle is how to transfer executable binaries to the 128. I'm looking at creating a EIA-232 link between the "D" and my UNIX box, as the latter has lots of serial ports. On the 128 side, a little machine code will drive the serial interface and stuff the incoming bytes into RAM. However, I historically have avoided the fake RS-232 code in the kernel like the plague. It's a prime example of crap software. :D Ergo, it appears I'll have to design and build a real serial interface. I can assure you it won't be equipped with a 6551 UART. The only problem will be that of getting the driver to the "D", since there initially won't be a working connection...problems, problems!
Sounds like you have a lot of fun in store. As far as transferring data, you could try an X1541 cable, or a memory card device like uIEC, or do it the old-fashioned way: print out the code and then type it in :)
Quote from: BigDumbDinosaur on June 23, 2010, 03:48 AMAlso sitting on the shelf awaiting a call to duty is a Lt. Kernal hard disk unit.
Rear Admiral unit?
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex (http://www.portcommodore.com/commvex)
Congrats, BDD! Welcome (back) to the world of real iron! :D
Quote from: RobertB on June 23, 2010, 04:56 AM
Quote from: BigDumbDinosaur on June 23, 2010, 03:48 AMAlso sitting on the shelf awaiting a call to duty is a Lt. Kernal hard disk unit.
Rear Admiral unit?
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex (http://www.portcommodore.com/commvex)
Well, it does say "Xetec Lt. Kernal" on the host adapter. :D But, yes, it is an RA enhanced unit. It's going to seem really weird when I first get it going. I haven't run any kind of CBM hardware since 1994.
Quote from: Hydrophilic on June 23, 2010, 04:17 AM
Sounds like you have a lot of fun in store. As far as transferring data, you could...do it the old-fashioned way: print out the code and then type it in :)
Typing in all that machine code inside the monitor and hoping I didn't mess up is more work than I care to do. I might have to resort initially to using the fake RS-232 routines to get the driver over to the 128. Another possibility might be to load DEVPAK on there and use it to build the driver. DEVPAK is a pain to use (horrible VAX-derived editor) but beats typing raw machine code into a monitor.
Im really glad you're getting a 128D, BDD. And it's especially nice that you have a Lt. Kernal HD lying about! You have helped me personally several times with hardware and programming issues and I know I'm not alone in these forums in appreciating having you around for advice.
A couple of comments (and a question)
- the X1541 cable that hydrophilic mentioned (about $15 on ebay) is really useful. That is, assuming you have a parallel port on your PC. Even if you don't use that as your primary mechanism for porting data over to "genuine" commodore medium, it is certainly worth the investment. I dump files staright to my 71 and 81. But of course, you need plenty of blank floppies for that approach.
- In my limited experience, getting an RBGI monitor is a very temporary solution. I landed a 1902 and it fried soon after I started using it. I think a lot of the monitors left are nearing the end of their life cycle. I ended up getting a 19" LCD for about $150 to use as a monitor. I do not have any color on the 80 column - but one of my projects is to build a device similar to those found on these forums for that purpose.
- Now for my question: Can the Lt. Kernal mulitplex natively or does it require a "multiplexer" to allow sharing between two systems? I apologize if that's an ignorant question, but I have only read about the multiplexing capabilities and have never actually used a Lt. Kernal. I use a CMD drive which is nice, but it obviously doesn't have multiplexing capability.
Tom
Quote from: dr.v on June 28, 2010, 08:59 AMIn my limited experience, getting an RBGI monitor is a very temporary solution. I landed a 1902 and it fried soon after I started using it. I think a lot of the monitors left are nearing the end of their life cycle.
What usually happens with these old monitors is the electrolytic capacitors dry out and then fail, sometimes by blowing up and scattering scum all over the interior of the monitor. The C-128 is susceptible to the same failure, especially the switcher power supply used in the 128D. Fortunately, there was nothing special about the electrolytics used in Commodore machines, so replacing them is not a big deal for someone with experience in that sort of thing.
QuoteI ended up getting a 19" LCD for about $150 to use as a monitor. I do not have any color on the 80 column - but one of my projects is to build a device similar to those found on these forums for that purpose.
That will probably be the path I take.
QuoteNow for my question: Can the Lt. Kernal mulitplex natively or does it require a "multiplexer" to allow sharing between two systems?
A multiplexer is required to allow sharing. The host machines can be a mixture of C-64 and C-128, as the Lt. Kernal DOS will adapt itself to the particular architecture. The original Xetec multiplexer could support up to four machines and up to four multiplexers could be daisy-chained to support a maximal 16 machines.
To make this all work in an orderly fashion, each host adapter is set to a different port number, with port zero being the first (and only if not multiplexing). Advanced programming techniques can be used to take advantage of this arrangement and create a true multiuser system.
Well, my plans got derailed a bit. The person from whom I purchased the 128D did a very poor job of packaging it and then, adding insult to injury, shipped it via USPS, virtually guaranteeing it would get kicked around. The 128D arrived all banged up and completely unusable. The attached pic gives you a bit of an idea of what the poor thing went through.
Quote from: BigDumbDinosaur on July 04, 2010, 02:26 PM
The 128D arrived all banged up and completely unusable.
Unusable electronics, mechanicals, or both?
QuoteThe attached pic gives you a bit of an idea of what the poor thing went through.
Aw, crap! Well, remove everything from the inside of the C128DCR, get a block of wood and a hammer, lay the wood on the inside of the dent, and hammer the wood against the dent.
Editing movies right now,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex (http://www.portcommodore.com/commvex)
Quote from: RobertB on July 04, 2010, 04:08 PMUnusable electronics, mechanicals, or both?
It appears at this time to be mechanical. The floppy drive was badly damaged and it doesn't seem as though a reliable repair can be made.
QuoteAw, crap! Well, remove everything from the inside of the C128DCR, get a block of wood and a hammer, lay the wood on the inside of the dent, and hammer the wood against the dent.
I'd do that if I had paid 25 or 50 dollars for the machine. I didn't and I'm not repairing anything. The seller is going to eat this one. In any case, getting the cover off would probably require a crowbar. The picture doesn't really show the full extent of the damage. She packed the thing with a pair of joy sticks, with nothing between the two. The joysticks, which I didn't want anyway, somehow survived the carnage,
The beat-up 128D is on its way back to the seller. Guess I'll have to wait until something else becomes available. And, no, I don't want a flat 128. :)
Man, that really sucks... and not just for you, it's disappointing in general that the C128D was damaged through such negligence.
I'm going to be selling eBaying mine soon (modded, tested, accessories), and I know how to pack delicate CBM electronics. :-) Will keep you in mind unless you've already acquired one.
Quote from: saehn on July 20, 2010, 05:33 AM
Man, that really sucks... and not just for you, it's disappointing in general that the C128D was damaged through such negligence.
Adding insult to injury, the seller sent the thing through parcel post, virtually guaranteeing its destruction.
QuoteI'm going to be selling eBaying mine soon (modded, tested, accessories), and I know how to pack delicate CBM electronics. :-) Will keep you in mind unless you've already acquired one.
Thanks for the offer. Actually, I'd prefer one that has not been modified, as it will be getting connected to a Lt. Kernal (aka Rear Admiral) system.
Ah, gotcha. Well since it's already a subject and I feel like talking about it anyway ( :) ): it's got a JiffyDOS switch, an adjustable fan, a switch to disable the internal 1571, and an 8/9 switch for that drive. The C128D was modified by that great CBM modder Al Anger (http://alanger.net/). It's awesome, but I just can't justify keeping it anymore when I'm trying to get rid of so many things.
Quote from: saehn on July 21, 2010, 01:46 AMAh, gotcha. Well since it's already a subject and I feel like talking about it anyway ( :) ): it's got a JiffyDOS switch, an adjustable fan, a switch to disable the internal 1571, and an 8/9 switch for that drive. The C128D was modified by that great CBM modder Al Anger (http://alanger.net/). It's awesome, but I just can't justify keeping it anymore when I'm trying to get rid of so many things.
I'd take it if it weren't for JiffyDOS.
The 8-bit database would be neat. I'm always interested in such things. I remember there was a rather large, complicated (for me, an ML n00b) discussion of a database written natively for the LtK, came with some documentation about the LtK on a web site. I didn't do much more than glance over it, since I no longer have an LtK.
Quote from: BigDumbDinosaur on July 26, 2010, 03:06 PMI'd take it if it weren't for JiffyDOS.
Really? No worries, I'm sure it'll sell... but you know that most JiffyDOS installations come with a switch, right? This one included. Flip the switch and poof, it's gone.
Well, I finally have a working C-128D here and can now get started on the painful(?) process of relearning the Commodore keyboard layout. Should be interesting.
Quote from: BigDumbDinosaur on October 04, 2010, 08:43 AM...the painful(?) process of relearning the Commodore keyboard layout.
Painful? I find it a joy to be on the C128 keyboard. :)
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Quote from: RobertB on October 04, 2010, 09:01 AM
Quote from: BigDumbDinosaur on October 04, 2010, 08:43 AM...the painful(?) process of relearning the Commodore keyboard layout.
Painful? I find it a joy to be on the C128 keyboard. :)
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/%7Erabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
It's "painful" because of the non-standard layout, e.g., ; and : on different keys, " on top of 2, etc.
Heh, the C128 keyboard is standard to me, and everything else is non-standard. :)
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
I learned to type on a VIC 20 and a C64 and the C= keyboard layout is so deeply ingrained in me that I still get frustrated by $ being on Alt Gr + 4 on a Swedish PC keyboard, not on Shift + 4 as it should be.
When I run Commodore emulators I always set the keyboard to positional mapping, otherwise I can't find the right keys. I find it quite amazing - when I used a real C64 in 2002 for the first time since 1987 the layout was still second nature to me.
Quote from: bacon on October 04, 2010, 08:17 PM
I learned to type on a VIC 20 and a C64 and the C= keyboard layout is so deeply ingrained in me that I still get frustrated by $ being on Alt Gr + 4 on a Swedish PC keyboard, not on Shift + 4 as it should be.
When I run Commodore emulators I always set the keyboard to positional mapping, otherwise I can't find the right keys. I find it quite amazing - when I used a real C64 in 2002 for the first time since 1987 the layout was still second nature to me.
The problem for me is I spend much of my waking hours typing on PC style keyboards, since that's what's connected to the servers and workstations that we build here.
Although I have a software development project in mind for the C-128D and Lt. Kernal setup, all of the coding will be done on my UNIX box, which, of course, has a PC style keyboard. So I'll not be doing nearly as much typing on the 128 as I did in the distant past.
Quote from: BigDumbDinosaur on October 05, 2010, 12:24 AM
The problem for me is I spend much of my waking hours typing on PC style keyboards, since that's what's connected to the servers and workstations that we build here.
Although I have a software development project in mind for the C-128D and Lt. Kernal setup, all of the coding will be done on my UNIX box, which, of course, has a PC style keyboard. So I'll not be doing nearly as much typing on the 128 as I did in the distant past.
The thing is, my situation is the same. I write technical documentation for a living and type on a PC keyboard all day, but parts of the C= keyboard layout still feels more natural to me, probably because of all the time I spent using one from ages 12 to 17 (19 if you count my Amiga 500 days).
Well, after being left powered on for several days, it appears the "new" C-128D is healthy. It is also apparent that adding a cooling fan to it does a lot to keep the internal temperature down. My only reservation at this point is the video monitorâ€"it's old and who knows when something will go bang in it. Sooner or later, I'll have to figure out how to connect a standard VGA monitor to the D. But for now, the old CBM 1084 will do.
My next project with this machine is to arrange so I can transfer files from my UNIX development system to it. As my UNIX box has a plethora of serial ports (16, to be exact), I can rig up a serial interface between the two machines. On the UNIX end it's easy: a shell script can cat the file to the appropriate serial port. At the C-128D end, it's a bit more involved. The fake RS-232 routines in the kernel are error-prone at higher speeds and the problem is exacerbated by a bug in many 6526 CIA chips that causes dropped interrupts in some cases.
Accordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps. The core of the card is an NXP 2692A dual ACIA or "DUART," which contains two independent EIA-232 channels with FIFOs, as well as some extras, such as programmable timers. The 2692 was originally targeted at the Motorola 68000 MPU bus, so some glue logic is needed to adapt the DUART to the 128's busâ€"several signals on the DUART have inverted meanings relative to the 8502 MPU equivalents. As I have already worked out the details of interfacing the 2692 to a W65C816S MPU, which uses a bus structure that is almost identical to that of the 8502, the adaptation required only minor engineering to work on the 128's expansion port (see attached schematic).
Although each channel of the DUART is capable of operation at a maximum of 115.2 Kbps, 38.4 Kbps is probably the maximum practical speed with the 128 running in FAST mode. With both ports continuously receiving and transmitting at that speed, the MPU would have to process as many as 15,360 IRQs per second. When interrupt latency is figured into the equation (up to seven clock cycles if an indexed read-modify-write instruction is being processed) and execution time for the IRQ handler itself is added, as much as 25 percent of the 128's maximum possible throughput would be consumed in processing DUART IRQs. So a steady data flow will definitely slow down the machine.
To make this work, a driver will have to be installed on the 128D to service the DUART, and code will have to be written to receive Motorola S-records and generate a binary image to save to disk. I may burn the driver and processing code onto an EPROM and install it into the empty ROM socket in the 128. That would solve two problems: 1) getting the driver itself over to the 128; and 2) not using up a lot of RAM to ensconce the driver. The two RS-232 buffers at $0C00 and $0D00 can be usurped, along with the appropriate zero page pointers, to handle the data stream. The rest of it is an IRQ handler and a front end in low RAM to map in the ROM as needed. Writing this code should keep me out of mischief for a while. :)
Quote from: BigDumbDinosaur on October 07, 2010, 03:24 AMAccordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps.
It sounds like you've created a modified CMD Turbo-232 interface.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Would you get more or less speed buffering to an REU?
Quote from: RobertB on October 07, 2010, 08:59 AM
Quote from: BigDumbDinosaur on October 07, 2010, 03:24 AMAccordingly, I've concocted a dual-port serial interface card that can plug into the 128's expansion port, and can operate continuously at a maximum of 115.2 Kbps.
It sounds like you've created a modified CMD Turbo-232 interface.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/%7Erabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Not exactly. The CMD cartridge used a Motorola 6850 type UART, which does not have a FIFO (or a second channel). The 2692 I'm using has both input and output FIFOs for both channels to reduce the interrupt processing load, so it can generally sustain a higher transfer rate.
In this design I didn't implement carrier detect, since the logic to accept and drop calls is in all modern modems. All the host machine has to do is provide a data stream, and assert or de-assert DTR as required to indicate when it (the host) is able to process.
Quote from: airship on October 07, 2010, 12:27 PMWould you get more or less speed buffering to an REU?
You would get less speed. Serial I/O is byte-at-a-time processing, which is something that is not efficiently handled with an REU. Each access to an REU, whether for 10 bytes or 10 kilobytes, requires a setup procedure to configure the REU's DMA controller according to what is to be done. Also, while the transfer between host bus and REU is in process, the 6510 or 8502 microprocessor itself is halted, which means that interrupt processing is also halted. In a case of high speed serial I/O, the required interrupt rate may be such that the time required for the REU to finish its work results in too much real time elapsing before the MPU can resume processing interrupts. The result, in the case of serial input, will be a data overrun.
This fundamental and unavoidable problem of limited serial I/O performance is a result of the relatively low clock rate at which the MPU is run, and in the case of the C-128, the memory mapping gyrations that must occur before the interrupt handler can actually get some useful work accomplished. While there have been reports of people achieving very high serial speeds with C-128s through the user port, it has been accomplished by optimized code that does nothing but service serial data flow interrupt, leaving no time to accomplish anything else. The intensive nature of serializing/deserializing data is why UARTs were invented. The work is off-loaded into another piece of hardware (the UART), which only interrupts the microprocessor when there's a complete byte to process.
UARTs like the 16550/16650 found in a lot of PCs, as well as the 2692 I like to use, also have a data FIFO, which acts like a small buffer. The 16550 type can buffer up to 16 bytes before a data overrun occurs, which means the MPU isn't hammered as much with interrupts as it would otherwise be. This was important in the case of PCs because much of the x86 processor family has relatively poor interrupt performance when compared to other processors. The 65xx/85xx family actually has very good interrupt performance, and exhibits low latency (never more than seven clock cycles). In contrast, some processors may goes 20 or more cycles before getting around to acknowledging an interrupt.
The 2692 DUART has a 3 byte FIFO, but owing to the relatively low interrupt latency of the 8502, the FIFO won't be important until the data rate gets up to 57.6 Kbps or higher.
Sadly, I have no time to read the voluminous amount of text that precedes this reply. Please excuse any repetition of ideas. etc., that may follow ..
--
This thread, seen from a distance, reminds me of a time when I used to xfer files in the following configuration:
PC <-nullmodem-> C128 mode 2MHz @ 115.2k 6551 ACIA, as follows:
.. using ACE R16 on the c128 side (no apparent hiccups at R16 (1997 AD) for me, but results may vary)
.. and ace's FX on the PC side =)
As some of you may recall, when Craig Bruce (ACE & ZED128 author) did his "crystal magic" on the Swiftlink (6551) ...and posted results to comp.sys.cbm, Turbo232 from CMD mysteriously appeared shortly after (or so it would seem). :D
ACE R16 list -- http://csbruce.com/~csbruce/cbm/ace/files-doc.html
XmX
--
EDIT - snippet of crystal mod below... with respect to a version of ACE prior to R16
>From: csbr...@ccnga.uwaterloo.ca (Craig Bruce)
>Subject: Even swifter
>Date: Sat, 11 Nov 1995 11:40:11 GMT
>I have just made a trivial but important hardware hack to one of my (two)
>SwiftLink cartridges to see if I could make it go faster, and IT DOES!
>As anyone who has read the SL technical documentation knows, CMD chose to
>use a double-speed clock crystal in the SL in order to allow it to work at
>speeds up to 38,400 bps, doubling the maximum baud setting for the 6551 chip
>of 19,200 bps ($0f in the control register). For the general purposes for
>which the SL is intended, this was an excellent design decision.
>However, the 6551 also has the ability to use 1/16x the external clock rate
>in order to generate "non-standard" baud rates (well, non-standard in 1987),
>for rates up to 125,000 bps. The speed of the double-speed clock crystal is
>3.6864 MHz, so 16x slower than this is 230,400 bps. I tried this rate out
>and it didn't work at all.
>I replaced this crystal with a 1.8432 MHz crystal, which is the standard
>frequency for serial-chip crystals. One 16th the rate of this crystal is
>115,200 bps, which is both below the 125,000-bps limit of the 6551 and is a
>standard serial speed for newer, high-speed modems, such as my USRobotics
>28.8 Sportster.
>I tried it out and it works; I can communicate with my modem successfully at
>115,200 bps using ACEterm on a 2-MHz C128. Well, mostly. The problem with
>such a high baud rate is that 11,520 interrupts per second have to be
>handled by the processor, which means that each interrupt must be handled in
>177 clock cycles (at 2 MHz). ACE can normally handle this (much to my
>surprise), but occasionally it cannot and so it gets trampled by interrupts
>and crashes. This apparently happens when it is about to assert hardware
>flow control. I should be able to tune the interrupt routines to always be
>able to handle this baud rate. This baud rate doesn't work at all with the
>processor at 1 MHz--ACEterm crashes immediately. It is likely that this
>baud rate will work perfectly with the upcoming Super-64 accelerators from
>CMD.
Quote from: XmikeX on December 02, 2010, 08:35 PMAs some of you may recall, when Craig Bruce (ACE & ZED128 author) did his "crystal magic" on the Swiftlink (6551) ...and posted results to comp.sys.cbm, Turbo232 from CMD mysteriously appeared shortly after (or so it would seem). :D
ACE R16 list -- http://csbruce.com/~csbruce/cbm/ace/files-doc.html (http://csbruce.com/%7Ecsbruce/cbm/ace/files-doc.html)
XmX
--
>From: csbr...@ccnga.uwaterloo.ca (Craig Bruce)
>Subject: Even swifter
>Date: Sat, 11 Nov 1995 11:40:11 GMT
>However, the 6551 also has the ability to use 1/16x the external clock rate
>in order to generate "non-standard" baud rates (well, non-standard in 1987),
>for rates up to 125,000 bps. The speed of the double-speed clock crystal is
>3.6864 MHz, so 16x slower than this is 230,400 bps. I tried this rate out
>and it didn't work at all.
No knocks on Craig (he's a very smart fellow) but why would he expect the 6551 to operate on a 3.6864 MHz clock crystal? The NMOS silicon in the 6551 can't switch that fast.
Quote>I replaced this crystal with a 1.8432 MHz crystal, which is the standard
>frequency for serial-chip crystals. One 16th the rate of this crystal is
>115,200 bps, which is both below the 125,000-bps limit of the 6551 and is a
>standard serial speed for newer, high-speed modems, such as my USRobotics
>28.8 Sportster.
Actually, this feature of the 6551 (it's not a "trick") was noted in the late 1970s by someone (Lance Leventhal?) whose name escapes me now. I recall reading about it back when I was trying to hack a real 6551 onto a C-64 (I ended up with a 6850 design instead).
Quote>I tried it out and it works; I can communicate with my modem successfully at
>115,200 bps using ACEterm on a 2-MHz C128. Well, mostly. The problem with
>such a high baud rate is that 11,520 interrupts per second have to be
>handled by the processor, which means that each interrupt must be handled in
>177 clock cycles (at 2 MHz).
I alluded to that earlier, which is why I decided to use the 2692A dual ACIA. While the absolute interrupt rate with high speed communication can't be avoided, the FIFOs in the 2692 tend to reduce burst activity, making the workload more manageable. Very tight coding is required, however, to maintain good throughput at anything above 38.4 Kbps. Compounding the difficulty is the fact that any I/O access on the C-128 is at 1 MHz, regardless of MPU clock rate, which applies when reading or writing to any UART register. The effect is almost like wait-stating the MPU for one Ø2 cycle.
Craig's interrupt rate is based on single-directional communication, not CBAT, which is far more demanding. CBAT at 115.2 Kbps would result in over 23K interrupts per second, which would virtually saturate the 128 running in FAST modeâ€"at best, only 88 clocks would separate consecutive interrupts. After factoring in minimal overhead in the interrupt handler's front and back ends, about 65 cycles would be left to actually process dataâ€"and that would not include the code required to determine if the UART was actually the interrupt source.
Point to note: if the UART is attached to IRQ instead of NMI, as is often done, no interrupts will be dropped if they overlap, as IRQ is a level-sensitive input and will re-interrupt the MPU if an unserviced IRQ is pending. However, such a condition would soon lead to a data overrun.
All that aside, the 6551 is a pretty lame design with quirky behavior. The CMOS version isn't much better. Although the Motorola 6850 UART is as old a design as the 6551, it is a better performer in almost all respects, and was not at all difficult to interface to a 65xx bus (except for reset). However, more modern ACIAs (e.g., the 16550 and 2692) are even better due to on-chip FIFOs and more sophisticated control functions. In particular, the 2692 is natively clocked at 3.6864 MHz and runs asynchronously to the MPU bus, so high BPS rates are no big deal. I wouldn't even consider a 6551 at this point in time. Better alternatives exist.
Quote from: BigDumbDinosaur on December 07, 2010, 03:40 AM
No knocks on Craig (he's a very smart fellow) but why would he expect the 6551 to operate on a 3.6864 MHz clock crystal? The NMOS silicon in the 6551 can't switch that fast.
Curiousity, I suppose? ..at least the 6551 in my SL seems to handle ~2 MHz.... whew.
Quote from: BigDumbDinosaur on December 07, 2010, 03:40 AM
All that aside, the 6551 is a pretty lame design with quirky behavior. The CMOS version isn't much better. Although the Motorola 6850 UART is as old a design as the 6551, it is a better performer in almost all respects, and was not at all difficult to interface to a 65xx bus (except for reset). However, more modern ACIAs (e.g., the 16550 and 2692) are even better due to on-chip FIFOs and more sophisticated control functions. In particular, the 2692 is natively clocked at 3.6864 MHz and runs asynchronously to the MPU bus, so high BPS rates are no big deal. I wouldn't even consider a 6551 at this point in time. Better alternatives exist.
....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm .. keeping the tradition, and software-lock-in, alive.....maybe.
XmX
Quote from: XmikeX on December 16, 2010, 01:44 PM
....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm (http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm) ..
Hmm, very interesting!
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
The Other Group of Amigoids
http://www.calweb.com/~rabel1/ (http://www.calweb.com/~rabel1/)
Southern California Commodore & Amiga Network
http://www.sccaners.org (http://www.sccaners.org)
Quote from: XmikeX on December 16, 2010, 01:44 PM....and then there's something like this : http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm (http://www.westerndesigncenter.com/wdc/w65c51s-chip.cfm) .. keeping the tradition, and software-lock-in, alive.....maybe.
The W65C51S' only real advantage over the NMOS part is its ability to operate at much higher bus speeds. Otherwise, it's the same old, same old...
As I said before, much better UARTs are available. Why bother?