Math Coprocessor

[airship]

Wouldn't it be cool if some CBM hardware guru interfaced this $20 chip to the C64/C128 user port?

http://micromegacorp.com/downloads/documentation/uMFPU-V3_1%20Datasheet.pdf

I've always wanted a math coprocessor chip for my C128.

[Hydrophilic]

What a powerful little chip.  Not only does it do normal floating point math, it does compound operations, like matrix operations and fast fourier transforms.  Lot's of possibilities there.  I'm swamped in projects now so I won't be building an interface anytime soon.

[commodorejohn]

The only logical conclusion: Quake 64.

...um, not that one.

[airship]

What I love about it is that it's got a serial interface, so it would work great off the user port.

Of course, you'd need a bit of support software...a 32-bit math BASIC 7.0 extension would be nice.

[Mark Smith]

Nifty little widget!  I suppose the place to start would be to create an SPI or i2C interface for the Commodore on the userport, from there you could talk to the maths chip.

Be an interesting thing to read up about .. should only take someone like me about 10 years to figure it out ;-)

Mark

[airship]

Nifty little widget!  I suppose the place to start would be to create an SPI or i2C interface for the Commodore on the userport, from there you could talk to the maths chip.

Exactly what I was thinking! An I2C interface for CBM would be awesome; you could do lots of real-word stuff. There are temperature sensors and battery-backed clocks, as well as relays and LED/LCD displays with the right interface chips, among others

Since I2C is designed as a low-speed serial buss, it's perfect for old 8-bit machines.

Besides, AmigaOS has it, and I'm jealous. 

Edit#1: Seeed Studio's got pre-orders going for the Bus Pirate v3, an RS-232 to I2C converter board, $27.15 assembled. Too bad CBM didn't give us an RS-232 port. Maybe it could be adapted. http://www.seeedstudio.com/depot/preorder2-bus-pirate-v3-assembled-p-523.html

Edit#2: Here's a parallel-to-I2C chip that might have promise: http://www.standardics.nxp.com/products/i2c.bus.controllers/

[Alex]

Very neat idea but CBM has already given C128s coprocessor and in case od C128D(cr) it is even included in package. It's name is: 1571! Despite RAM space constrains you have a relatively fast CPU that can work independently to computer CPU and MMU! 

[Hydrophilic]

@Alex,

Airship is quite aware of using a disk drive for parallel processing.  One idea of his was a chess tournament with disk drives; see this thread.  More importantly, the stock 1541/71 only have 2kiB RAM for both code and variables.  Floating-point matrix and fourier operations are not trivial tasks, and I challenge somebody to write drive code to do all those things!  (not to mention I2C devices can do lots of a stuff a disk drive never could)

@Airship,

Looking at the datasheet for the parallel-to-I2C chip (PCF8584), I see it requires about half a dozen control lines (in addition to the 8 data lines).  The user port, AFAIK, only has two handshaking lines, /FLAG and bit 2 of $DD00.  That chip is expecting things from the host (Commodore) like R/W, CLK, IRQ, RES, A0, etc.  So this might be okay for a cartridge, but not for the user port.

Now the Bus Pirate seems like an idea.  There are at least four versions.  I think you are talking about Ver1 (or Ver0) which have the RS232 interface.  (Ver2,3 have a USB interface).  Anyway, looking at the schematic of Ver1, I see that it doesn't use +12V or -12V anywhere.  In fact, it's plain TTL (5.0V or 3.3V) except for the voltage regulators which are for output, not input.  Looking closer, I see it uses a MAX3232CSE for RS232.  Looking at the datasheet for that device, I see it operates on TTL voltages, and will accept either true RS232 or TTL levels for input and produces RS232 or TTL voltages for output (depending on V+ and V- lines).  Based on the schematic, it will output TTL.  Since the CBM user port is TTL (RS232-C), I think this should work.

[RobertB]

More importantly, the stock 1541/71 only have 2kiB RAM for both code and variables.

Or you could buy a RAMBoard to give you more RAM in the 1541/71... 

               Truly,
               Robert Bernardo
               Fresno Commodore User Group
               http://videocam.net.au/fcug
               The Other Group of Amigoids
               http://www.calweb.com/~rabel1/
               Southern California Commodore & Amiga Network
               http://www.sccaners.org

[airship]

Great work, HP! When will these interfaces be ready for sale?

Edit: I found out that the earlier version of the Bus Pirate is available as a kit here for the closeout price of $20, with a preprogrammed PIC!

[dr.v]

I certainly wouldn't be much help with the hardware design and implementation on this project - but I am willing (and capable) of helping write the software to take advantage of the math coprocessor.  In fact, I am working on several pieces of mathematics code for my 128 right now.  Just let me know if I could be of use.  I would love to have this chip running on my 128D.  This would open up myriad possibilities.

Tom

[airship]

Ok, I think this is it: a single-chip 8-bit parallel to I2C interface chip in a 16-pin DIP package:

http://www.standardics.nxp.com/products/pca/datasheet/pca9554.pca9554a.pdf

[Wagner]

I hope someone finds time to tackle this project.  There have been a lot of projects for the 64/128, but I can't recall anything quite like this.  The 128 has been around for nearly a quarter century and no one has ever interfaced a math coprocessor with the 8502 before?!

[Hydrophilic]

I hope someone finds time to tackle this project.

I agree, but it won't be me... at least not this year.

@Airship,

The PCA9554 is going the opposite direction!  It is for controlling an 8-bit I/O port over an I2C bus.

Looking at the pinout of User Port, I see (contrary to an earlier post I made), that there are 2 additional handshake lines: /ATN (the same as the CBM serial bus line, opposite ATN from CIA because it follows an inverter) and /PC2.  /PC2 should be really helpfull: it pulses low 1 cycle whenever CIA2 Port B ($DD01) is read/written.  Both CIA serial ports are available but I don't think they'll help (witness the KERNAL soft-RS232).

I decided to take another look at the PCF8584.  Although this was designed for direct motherboard (or cartridge) implementation, it could be possible to utilitize the UserPort with some simple glue logic and some programming.  Take a look at my circuit...

The biggest problem is the CLK line.  The PCF8584 might not like R/W and /CS to trigger asynchronously with CLK.  Several oscillators could be used because the PCF8584 is programmable for clock frequency.

The diode on the /RES line is to prevent the PCF8584 from resetting your Commodore because the chip can output a low if it receives a special multi-master signal.

Another problem is the specs state /RESET should be low for something like 60 cycles, but I believe the Commodore only holds /RES low for 12 cycles or less on power-up.  If you manually press Reset, there should be no problem because you'll probably hold it down for thousands of cycles.

The /INT to /FLAG connection is optional.  If you don't like NMIs (I sure don't), then omit it and use polling.

The basic programming method is to:

A. Set read (0) or write (1) mode into bit 3 of $DD00 (the output goes through an inverter then to serial bus /ATN and the PCF8584 R/W)
B. Set register select line A0 into bit 2 of $DD00.
C. Set data direction of $DD01 via $DD03
D. Perform read or write $DD01 to access PCF8584 register

Note steps A and B can usually be combined because both bits are in $DD00, and step C only needs to be performed when changing from reading the chip to writing it.

If you like VDC, you might like the PCF8584 because it has internal registers you access by specifying which one by writing to A1 (from what I can tell of the specs).  And then you read/write from/to A0.  The internal registers have names like S0, S1, S2, etc.  The primary one is S0 which is the parallel / serial converter.

And here is some hypothetical initialization code based on a flow chart in the datasheet:

Code Select Expand


LDY #$FF
STY $DD03 ;set $DD01 to output mode
LDA $DD00
AND #$F3
ORA #%1100 ;write, A1
STA $DD00
LDX #$80 ;select internal register S0'
STX $DD01
EOR #%0100 ;write, A0 (S0')
STA $DD00
LDX #$55 ;arbitrary address assigned to controller
STX $DD01 ;write S0'
EOR #%0100 ;write, A1 (S1)
STA $DD00
LDX #$A0 ;select internal register S2
STX $DD01 ;write S1
EOR #%0100 ;write, A0 (S2)
STA $DD00
LDX #$1C ;select crystal frequency 12MHz
STX $DD01 ;write S2
EOR #%0100 ;write, A1 (S1)
STA $DD00
LDX #$C1 ;enable I2C bus (idle mode), select register S0
STX $DD01 ;write S1

;from now on, read/write to A0 accesses (internal) register S0 which is the I2C serial data in/out

;example send a byte
EOR #%0100 ;write, A0 (S0)
STA $DD00
LDX #$12
STX $DD01 ;write S0

;example read a byte
EOR #%1000 ;read, A0 (S0)
STA $DD01
INY ;zero
STY $DD03 ;CIA input mode
LDX $DD01 ;read S0


The example send / receive code is completely stupid because it doesn't check the PIN bit of S1 to see if data has been sent / received.  I leave that as an exercise for others...

[airship]

WoW! 

Great work, dude. Looks like someone could take your info and just run with it. I'm sure the VIC and C64 guys would be interested in an I2C interface, since there are so many cheap sensors and EEPROMs that can be connected, not to mention this great math chip. And we already have someone who is interested in writing interface code for it!

So who's our candidate for building this thing?

Edit: It appears that the PCF8584 has been superseded by the PCA9564, which has an internal clock:

http://www.nxp.com/acrobat_download/datasheets/PCA9564_4.pdf

Digi-Key part No.: 568-2028-5-ND (20-pin DIP), $2.39 single-unit price.

Also, I found out that Andre over at 6502.org used the PCF8564 to add an I2C interface to his SCSI interface for his CS/A65 6502-based computer project. The details are sketchy, but you can see his schematic here:

http://www.6502.org/users/andre/csa/scsi/index.html

Our CBM buddies over at NKC Electronics now carry the math cip; it's $19.95:

http://www.nkcelectronics.com/umfpu-v31-floating-point-coprocessor-18pin3118.html

[Hydrophilic]

It appears that the PCF8584 has been superseded by the PCA9564... No.: 568-2028-5-ND (20-pin DIP), $2.39 single-unit price.

...NKC Electronics now carry the math cip; it's $19.95

That's like 834.7% the unit price or 734.7% mark-up!  (Not counting bulk discounts/profits.)  I need to go into cbm-hardware business!

After sleeping on the idea, I noticed there is a major flaw with this idea.  (There is also at least one minor timming problem if you look over the timing diagrams in the PCF8584 datasheet.)

The good news:  according the datasheet, CLK timing has nothing to do with R/W, /CS, A0 line (register access).

Anyone care to guess what the major problem is?

[gsteemso]

At a guess, the serial communication takes so long to transfer data that you’re better off just doing your calculating in the 8502 CPU.

[Hydrophilic]

At a guess, the serial communication takes so long to transfer data that you’re better off just doing your calculating in the 8502 CPU.

I should hope not!  As I understand it (I'm an I2C noob, remember), transfer rates are 10s of kbit / second.  So 32 bit FP basic math (add, multiply, etc.) should not suffer or benefit slightly, but when it comes to transcendental functions (sin, log, etc.) or especially compound operations (matrix or FFT), the math coprocessor should be a HUGE benefit.

The major problem is the hardware interface design.  Although my schematic might work for writing the PCF8584, I don't see how it would work for reading the chip.

You see, the basic idea as that when you read/write $DD01, the /PC2 is toggled low to signal read/write access to the chip via the chip's /CS.  So writing should work fine: you store a value, the CIA outputs the data, the CIA toggles /PC2, and the PCF8584 accepts it.

But, when you read $DD01, the CIA reads the data on the parallel lines (for the CPU to read) and toggles the /PC2 line.  Then PCF8584 outputs data for the C128 to read, but that doesn't matter because the CIA already has a value for the CPU.  Since the PCF8584 should be tri-stated before it receives the /CS (/PC2) pulse, the CIA might return $FF everytime.

Well that's my fear.  I haven't found the relevent timing specs on the CIA yet, so maybe if we're lucky, it will output /PC2 at the start of the register access and read the data near the end.  I don't count on that, because that seems like a design that would promote unstable data transfer.

Also there is a minor problem relating to accessing the PCF8584.  It is apparently not a static design because the datasheet specifies a maximum time the R/W line can be held low (I think 1000ns = 1us).  This should be trivial to overcome by using /PC2 to gate the R/W signal.

Looking at the C128 PRG, it tells me that the output from the CIA parallel lines can be delayed upto 1000ns from phi2 high (when the CPU finishes its access to the CIA).  Unfortunately it doesn't list a minimum or typical value.  This may cause the PCF8584 to read old data when the C128 tries to write to it.

The timing diagrams in C128 PRG have no information on /PC2 so I can't really be sure about what will happen... I also checked the 6526 Datasheet which provides essientially the same info.  Anyone know where/if detailed /PC timing info is available?

Well at least this is an idea to play with if you've got the hardware!

[airship]

Hydro-P, I appreciate the thought you've put into this, but you are wrong. This idea is just too cool to be impossible. The universe would not allow it.

Edit: Does this application note address the problem? http://www.standardics.nxp.com/support/documents/i2c/pdf/anz96003.pdf

[Hydrophilic]

This idea is just too cool to be impossible. The universe would not allow it.

I like your attitude!  Looking at the document you referenced, it seems that writing should work (if you gate R/W via /PC2 as stated above), but reading is very questionable because we don't have the timing for /PC of the CIA.  Unless somebody can find documentation for CIA timing of /PC, I think experimentation is the only solution.

As a completely retarded solution to the read problem, I provide a very combersome solution which involves a parallel to serial converter (see image).

I looked at a few parallel-to-serial converters, but didn't find one that fits our needs perfectly, hence the ?? ?? description of the mythical chip.

The idea here is to BIT $DD01 to trigger /PC2 and cause the PCF8584 to output a byte that is captured by the mythical chip and convert it to serial (at 4MHz), and then LDA $DD0C (the serial port of CIA 2).

For this retarded case, code would be something like

Code Select Expand


LDY #00 ;input...
STY $DD03 ;...all lines of $DD01
LDA $DD00
AND #$F3
ORA #%0000 ;for A0 or %0100 to for A1
STA $DD00 ;select register of PCF8584
BIT $DD01 ;trigger PCF8584 read, mythical latch
NOP ;2 C128 cycles; 8 mythical cycles
LDA $DD0C ;read mythical conversion of PCF8584


There is no gaurantee that the CIA can input at 4MHz.  I suspect that it probably can not!  So this is just another ida to play with!

I suspect that to use the PCF8584 or similar, you really need to use an expansion cartridge which would have full access to R/W, CLK, /IRQ, etc. as stated in my initial post.  Of course robbing the user of an REU / MMC / etc. is not nice which is why I've posted these mythical possibilities...


Didn't BDD offer cartridge/expansion port circuit boards before?  I remember he had some nice layouts prepared.  Maybe he never got enough preorders?  ...just another idea...

[Mark Smith]

The next thing to look at would be an i2c for the clock port, which is more and more C64 devices come from Jens these days.
He implemented one on the MP3@64 for the MMC64 clock port.

And there are schematics for making clock port only cartridges available, should be possible to make one of those that does not interfere with other carts in a cartridge expander (like the Fotios FB-3XP)

Hmmm ... maybe we could bribe Fotios into making us a FB-3XP with clock port and i2c interface on board ?   I've a bag of sweeties to add to the kitty .... ;-)

Mark

[airship]

RS-232 TTL to I2C converter using a small, cheap PIC. Looks PERFECT for our needs, unless one of you experts proves me wrong. (Which, I admit, is highly likely.)



http://www.gedanken.demon.co.uk/rs232-converters/i2c.html

[Hydrophilic]

The next thing to look at would be an i2c for the clock port

What is the clock port?  I'm guessing its a connector available on the MMC or 1541ultimate ?

According to the Atmel1280 datasheet, there is an SPI interface built-in.  This chip is used on the uIEC 3.0.  The related (father) storage device, SD2IEC, uses a similar chip (both devices use the same sourcecode for firmware) which may also have an SPI interface.

Although SPI and I2C are different serial protocols, both the uIEC and SD2IEC are readily available, so maybe this would be a possible route... unfortunately I am not an expert on either SPI or I2C so they may be completely incompatible, but as I understand they both use 2-wire serial communication so maybe there is hope?

BTW, I haven't checked my uIEC to see if there are actual connectors/pads for the I2C feature of the Atmel1280.  Actually, I'm not sure if the uIEC 3.0 uses the Atmel1280 or Atmel640... I have the PDF (covers both devices and more), and I was trying to access the schematics on Jim Brain's site, but it has changed with his new store front and I couldn't find it...

...using a small, cheap PIC.

Cool!  That looks like something even I could build! 

But... where is the PIC?  Those are usually large 18+pin ICs, but I only see a tiny 8-pin IC.  Is that some new-gen PIC?

Edit
Silly me!  Following airship's link, I see that this contraption (oooh, we need a name) uses the 8-pin PIC16F675.  Super cool!

It seems this would be easy to interface to the C128's User Port and a programmer could use standard KERNAL routines for 1.2k or 2.4k baud rates.  According to the coding page of said device, data rates of 57.6k are possible.  Of course you would need to bypass the KERNAL for rates above 2.4k baud and it seems like Berkley Software pushed the limits quite a bit with GEOS' Laser Printer driver which ran at 9.6k baud as I recall.

[airship]

Here's an assembled $25 I2C evaluation board. It has 4 dip switches and 4 LEDs for experimentation, then when you know what you're doing you can cut a couple of traces and use it as a real-world I2C interface.



http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en022017

Hey, I'm trying to make this easy for you geniuses!

[Hydrophilic]

Like many of your links, airship, this one looks promising.  Pretty cool from a quick glimpse.  I'll investigate some more when I'm sober. 

Edit
Now that I'm thinking clear, it seems that is a useful I/O board (after some hacking as airship mentioned), but you first need an I2C or SPI interface for the C128.

I really like the one you discovered airship: RS-232 TTL to I2C converter using a small, cheap PIC.  Now if somebody would build and sell them!  (not enough time to build it myself, but looks like a fun project)
/Edit