Conference hydra::amiga_v1

    Has anyone seen more information on this board?  
    Is the magazine on the newstands now?
    
    Jean
    

     Yes, it is in Amazing Computings Feb. issue and should still be on
    the dealers shelf, I'll be biulding this one for shure.
    
    								Ed
    

    Ed
    I just ordered mine last night.  Did you get yours yet.  If so how did
    it turn out?
    
    Alan
    

 I still have yet to order mine, (Overtime being discontinued here).
									
 But still plan to make it in the future...

				Keep us posted on the project. :')
									ED

    
    Here is my story:
    
I received my kit last week, nice quality boards all parts needed
included except the parallel port connectors and cables 
ARRRRRGGGHHH, this was THE reason I bought the thing in the first 
place.  The second disappointment came when I made the parallel port 
cables, the only signals coming out of the two extra parallel ports 
are *DEMAND* data bits 0-7 and *STROBE*, This means that my frame
grabber will not work on the extra ports because it uses another
signal from the parallel port.

I decided to test it out on an old A1000 to keep from blowing up
my 2000.  At first it didn't work at all until I realised I had
a cable connected backwards, this was not too clear in the docs
and I had to rely on the pictures from the magazine article.  
This didn't matter too much because it didn't work with the cable
inserted the right way which led me to believe I had blown the
8520 CIA chip.  The article mentioned the 8520 could be replaced
with a 6526 (from a C=64), not quite, the chip is not fast enough
for the 68000 and locks up the mouse on occasion, and this was tried
without the expansion in place (so what's another $15 in useless
chips?)

The outcome was looking bleak to say the least.  They suggested
making the cable (this cable plugs in the 40 pin CIA socket and
brings the CIA on the module) as short as possible.  My cable was
about 6" long so I moved one of the connector closer to effectively
make a 2" cable, but alas it still didn't work (hardware fault, no
kick start "hand" on the monitor) even with just the CIA on the
module! 

In desperation I cut the 4" of cable protruding from the connector
and lo and behold, it booted kick start!  I then stuffed all the
chips in their respective sockets and tried it again.... and it
locked up and would not boot kick start.  A day later I thought
about it and came to the conclusion that the CPU chip may not
have enough drive for the extra loads imposed on it.  Fortunately
I had a couple of 12Mhz parts on hand thanks to an unfortunate
experiment to speed up the Amiga's clock to double it's normal
rate, but that's another story.  The "new" chip made the interface
work!  So finally I was able to check the new ports.

First I tried the parallel port, I installed the drivers in their
proper places (eighbit.device and newser.device) made the modifications
to the mountlist so that PAR1:  PAR2:  SER1:  SER2: were channeled
to the proper drivers, modified the startup-sequence so that they
were mounted on start up.  Then I connected my printer to the first
parallel port and copied a text file to it and IT WORKED!!!!
The second parallel port did not work however and I think I may
have fried a couple of bits on the VIA (65C22).  The two serial
ports work quite well.

They have a program called IOpatch running in the background which
intercepts calls to PRT: then a requester pops up asking for the
port to be selected.  I tried printing from DiskMaster and from 
DPaint and this worked well.  There is also a SERprefs program to
set each serial port for the proper baud rate, the number of bits,
the number of stop bits and flow protocol.

I will update this note when I have the thing installed in my 2000
and have both parallel ports working.

Jean

    Good to hear some one else got one.  I put mine together this weekend.  
    The Serial ports work ok.  I am using one now.  But I was also
    disapointed in the lack of full functional parallel ports.  But I
    wasn't to surprised the article showed 20 pins for two ports.  There
    just are not enough to do the full function.  Also thing like paper
    out, and busy from the printer.  So this is just for printers only.
      
    Also the Serial ports do not supply +12V and -12V on pins 9 & 10.  I 
    have not tried my ECE MIDI yet but I do not expect it to work.  It has 
    to get power from somewhere. Also I bought the four port version and 
    went and invested in the extra sockets and headers to fully populate 
    the module.  I can always insert the chips later if I decide to expand 
    and not have to solder the sockets in so add $20.00 to the project for 
    that and the connectors for the parallel cables.
    
    
    
    I cannot get either of the parallel ports to work.  What do you get
    when you run IOSETUP and IOPRINT.  I get the following.
    
    VIA0:  12 34 FF FF EC 0B FF FF D2 2C FF 00 00 00 80 34
    
    The first port is close to being correct but neiher ports work.  Looks
    like I killed my 65022 also.  I incorrectly plugged the 40 pin cable into 
    P1 the first try.  For any one else that wants to get this project.  The 
    8520 pin 1 is closest to the connector for the A14 and A15 signal
    connection. The ribbon cable pin 1 is also on that side.  
    
    Any body know of a source for the 65022 chip?
          
    
    I was hoping to run PARNET on one port to connect my A500 and A2000
    while still having the printer and my Digiview all connected.  But
    Digiview probably will not work and PARNET needs BUSY.  So I still need
    to keep my AB switch handy for those two.
    
    
    
    Alan
    
    
    
      
      

    I answered my own question.  I have two 6522's on order from Mouser
    Electronics.  At a whopping $2.67 each.  They were nice enough to waive
    the $20.00 minimum order.  So I will see if this fixes it this
    weekend.  
    
    
    Mousers address and number is in the Article.
    
    

I am using Amiga DOS 1.3.2
Amiga 2000 1.3 ROM

I got the hardware bugs worked out.  I had a bad 6522 could have been DOA 
or killed by static, we got lots of that here in Colorado.  For the most 
part the serial ports worked as advertised.  I had a problem getting VLT 
5.034 to accept the NEWSER.device, the file requester would freeze and I 
could not exit the program.  This ended up being the replacment for the ARP 
requester I was using.  Once I was able to select the NEWSER.device all went 
fine.  Handshake appears to work fine.  I did notice that I could not send a 
break from VLT last night but I will need more time to test this.  The wife 
started muttering something about computer widows so I had to stop playing.    
I used Zmodem and Ymodem for an upload and download with no problems.  I was
also able to run two versions of Handshake with both serial ports connected
together with a null modem cable.  I was also able to run Handshake on one port
and copy a file to the other port,  Handshake captured the file with no loss of
data, again both ports were connected via null modem cable.   I guess a good
test would bo to send a file to its self and see what baud rate it tops out
at.  This should vary from CPU accelerator to CPU accelerator.  


The parallel ports are another problem.  I have two 6522's installed and all 
four ports work ok with text.  Graphics are another story, I started testing 
with the Graphic Dump utility from the Utilities drawer.  The image was 
squashed vertically.   I do not believe this is a hardware problem but a 
problem with the eightbit.device.  This is supposed to be identical to the 
parallel.device.  But If I use CMD to redirect the parallel port to a file 
and then copy the file to PAR1: everything is OK.  I am also able to use CMD 
to redirect the output to PAR1: and the image is OK.  But if using IOPATCH to 
send the image through the eightbit.device directly the image is squashed down 
to about 3 inches for a full interlaced screen dump.  Showprint and Deluxe 
Photolab, and Posters also bring this problem out.  The first line is OK but 
it appears to not line feed correctly and overwrites the lines.  It looks like
it line feeds one pixel at a time instead of six pixels down.  Of course using
the original parallel port everything is fine, so I do not think it is a
preferances setting problem.  

Also it looks like the LPT1 progam for the bridge board twiddles with the 
hardware directly and I cannot get IOPATCH or CMD to redirect the MSDOS 
printer to the new parallel ports. IoPatch is never called up so it looks 
like CA used nonstandard calls for this program. I cannot find any referance 
to the parallel.device in the image.  I guess the next step would be to 
disasemble it and change the address for the CIAB to VIA0.  That is assuming
the registers to the VIA are the same as the CIA.  I am able to do a AWRITE 
TEMP.TXT PAR1: from MSDOS.  Anybody know of a good PD disasembler.     
    
    
    Also some of these problem might be relieved by Amiga DOS 2.0 whenever it 
    gets released.

    

    I have had some time to do a little more testing.  The new serial device 
    never sends a break.  Looking at the source for the driver he has some 
    routines that appear to be break routines.  They just do not work.  For 
    anybody that connects to terminal servers a break function is important.  
    Also in the source code is a comment that the driver will not send an Xoff 
    if its buffer gets full.  This is probably the reason that I get an 
    occasional requester thet the serial device temporarily cannot send data.  
    I am using Vlt and this usually shows up usings its mouse support, and I 
    am mousing around under a VMS editor. 
    
    I still have the problem printing graphics through the eightbit.device.
    The printout is always fine if I redirect the parallel.device through
    PAR1: with CMD.  Any time I send a graphic dump through the
    eightbit.device to the printer it overwrites lines.  sometimes just a
    few sometimes many of them.  It has never printed completely clean.
    
    Text printing works OK.
    
    I have an extra 6522 if some one needs one.
      
       

    More on the continuing saga of the eightbit.device.
    
    I wrote a little program a few years ago to print address labels.
    It send the esc sequence for double height char then prints four lines. 
    No big deal until I tried to use IOpatch and the Eightbit.device.  Then
    instead of getting double height characters I got a printout of the
    swich settings of the printer.  Pretty neat I did not know I could do
    that on the printer.  I set the printer up to print a HEX dump of all 
    data that it gets.  Under the Paralel.device and on the normal port it
    gets a HEX 1B 77 31.  This is the Epson esc sequence for double height
    characters.  Under the eightbit.device and on PAR1: I get the following
    HEX bytes FF 1B 00 77 00 31 00.  The ASCII data ia OK.  The ESCape
    sequences all have extra bytes inserted. 
    
    I dialed into Jeff Lavins BBS he does not want to hear about problems
    with the drivers.  I need to write to the authors. 
    
    I wonder how long it takes for mail to go to Australia and back?
    
    
                                                                    

    I found the grapic print problem.  You cannot use an Epson printer driver. 
    I put my NX1000 in IBM mode and selected the CBM_MPS1000 printer driver 
    and it works.  I tried both the EPSONX and EPSONXOLD drivers no good.  I 
    still get extra 00 bytes between the escape sequences from my label 
    printing program.  And I still need to do something about the LPT1 program. 
       
    
    Now for the next problem.  When printing from Deluxe Photolab the IoPatch 
    requester comes up I select unit 1, and the requester goes away leaving a 
    nice square hole in the picture I was going to print.  I tried to do a
    quick Amiga N to switch screen's after selecting the print gadget.  My
    little fingers are just not quick enough.
    
    
    Alan

    I extracted the IoBoard Expansion from Fred Fish 520 and copied it to
    Eot::Amiga:[upload].  Also included on that disk was NewerSer.Lzh.  I
    imbedded it into IoBoard.lzh.  This is version 2.10 of the
    Newser.device driver.  I included the update.doc from that file in this
    note.  
    
    This driver is a big improvement.  Break now works I no longer have to
    set my own local character.  It also fixed the random hanging during
    downloads.  I did notice that while using Zmodem to download and it I
    clicked on another window or icon the system will lock up.  Running
    another program from an existing CLI appeared to be ok.  Then I
    noticed that the Newser.device for port 1 was running at a priority of
    127 while port 0 as at 126.  I dropped it down to 10 and 9 respectively
    and fixed the hang problem.  I hope this was not the authors method of
    speeding up his driver.  This can get to be a real pain to change on the
    fly each time.   
     
    
    
Newser.device update information                     
--------------------------------

V2.10 --- June 27, 1991

This version is very similar to V2.00. It adds a routine for
controlling the RTS and DTR control lines directly. The method is
compatible with that of ASDG's Dual Serial Board. See the source
code for more information. A couple of potential problems were
fixed as well.

This will likely be the final "official" version of newser,
except perhaps for minor bug fixes. HAVE FUN!

Documentation for V2.00:

Please read this completely, since it contains information you'll
probably need to know sometime...

The time has come for another update to the serial device driver
for the I/O expansion board. Previous versions basically worked,
but had various shortcomings. This, the third release, tries to
finally do everything right...(and seems to succeed!!)

What's new?
-----------

* Better performance. The last version increased read performance
to the max; this version addresses write performance as well.
Context-switching overhead has been reduced to a minimum to make
writing much faster than the previous version, and faster than
the regular serial.device too. The overall performance of the
driver is now extremely satisfying!

* CTS handshaking now works. This is a major fix. Previous
versions would mysteriously hang if CTS was ever deasserted. (The
serial chip documentation was inadequate...). It is now safe (and
recommended) to turn on CTS handshaking. Actually there is no way
to turn off CTS handshaking (a limitation of the serial chip) but
if you specify no CTS handshaking, the driver will check the
status of CTS before starting a write operation: if CTS is not
asserted, the write is aborted. On the other hand, if CTS
handshaking is turned on, and CTS is not asserted (e.g. the modem
is turned off), the driver will wait forever for CTS to be
asserted; expect this. Terminal software is supposed to provide a
time-out to avoid "hanging" in this case, but I doubt the
authors' of these programs bothered to do it.

* The "random lock-up" bug reported by some users is fixed.

* IOPatch received a small update: It now calls CacheClearU after
duplicating itself, when running under kickstart 2.0. Also the
gadget text was changed to be slightly more intuitive.

One bug report remains an unsolved mystery. A user reported total
failure when using the I/O board in a system with a GVP Series-II
controller; when the controller was removed, the board functioned
normally. I have checked the driver very carefully and don't
believe that it could be responsible for such a drastic failure.
Instead it's probably a hardware problem. First suggestion: add a
pull-up resister on the reset line, as specified in the assembly
manual.

Tips for using newser.device
----------------------------

* Turn off XON/XOFF handshaking unless you really really really
need it (you probably don't). If XON/XOFF is on, the driver can't
use its "RAD_BOOGIE" mode to speed up reads; instead of doing a
fast bulk copy, the driver is forced to check each byte for
XON/XOFF...this is extremely slow!!!!

* If you are communicating with a modem at a speed higher than
the connect rate, CTS handshaking MUST be turned on for ZModem
transfers to work properly.

* Higher numbered serial "units" have higher interrupt
priorities. If, for example, you are using two ports, one at
19,200bps and the other at 2400bps, then a good arrangement is to
connect the 19,200bps line to unit 1, and the other to unit 0.
The other way around will give poor results.

Compatibility
-------------

This version of the serial driver was tested with the following
programs:

* JRComm 1.02
* Handshake 2.12a/2.20c
* Ncomm 1.9
* C-Net 1.95t (BBS software)

Special thanks go to John Hoyt for his beta-testing and
encouragement. Call his excellent C-Net BBS at 213-633-5002.


Important notice to all I/O board users!
----------------------------------------

Due to the longer cable length that the moved CIA must drive,
many of you are experiencing erratic floppy operation, even after
grounding the I/O board as recommended. Fortunately I seem to
have run into the cure! It turns out that this problem is highly
dependent on the CIA revision. The CIAs that came with my A2000,
labeled 8520A-1, worked absolutely horribly, BUT when I replaced
it with an 8520R2 from my old A1000, the erratic floppy problem
COMPLETELY disappeared even when the board had no extra
ground/power attachments. If you are having this problem, trade
CIAs around!  Note: New Amigas are being shipped with a CIA
revision that promises much better drive characteristics.
However, this new version is not a perfect replacement, requiring
some additional pull-up resisters. The bottom line is this. If
you have the latest CIA revision, you are probably not having any
problems. If you have an old CIA revision, you can't substitute
the latest revision without some hacking; instead, try swapping
with an old A1000 like I did. (The 1000 won't know the
difference).


The Future
----------

I'm still interested in a Zorro-II version of the I/O board,
maybe even with a 6502 on board...(or am I dreaming?). I talked
to one person who expressed interest in designing such a board,
but I haven't contacted him in several months. Don't be shy; give
me a call and get started!!

----------------------------------------------------------------

Since I put so much time into this upgrade (unpaid of course), I
would appreciate receiving a few disks in the mail...I especially
like programmers tools/utilities, megademos, and anything fun.
Thank you for your support!!!

My address...

P.O. Box 1532
Southgate, MI  48195
USA

Phone: (313)-479-1056
Internet: [email protected]
Bix: danbabcock