odd VDIP behavior

39 views
Skip to first unread message

glenn.f...@gmail.com

unread,
Sep 6, 2022, 9:10:21 PMSep 6
to se...@googlegroups.com

Now that I’ve made the mod to the USB board the activity light is much more visible, but this has exposed an issue of some sort.  I frequently see the I/O LED go into a rapid flashing mode indicating some kind of hitch in communication.  This happens when data are being written to the USB.  I’ve seen it with my VPUT utility but now I am also seeing it with the “save” command in Douglas VH8DUTIL program.  I’ve seen this behavior on the Rev 3.1 and Rev 4.0 Z80 CPU boards with the USB daughterbard.  I’ve tried it with two different daughterboards and two different VDIP modules.

 

When I get a chance I’ll see if I can replicate this on the Z80 2.6 setup or if it’s unique to the newer boards.  My hunch is that I won’t see this there as that’s where I did the development and testing of the Vinculum utilities and I didn’t experience this problem then.  May take a while to figure out, meanwhile I’d be interested if anyone else has any information.

 

What I’ve observed is:

  • The problem is indicated by a regular and rapid flashing of the I/O LED (LED2) – I estimate about 4 times/sec.
  • During this time the application accessing the USB appears to be blocked.  For example when I was using the ‘s’ command in VH8DUTIL the “SSSS…” update stopped progressing when the rapid flashing began.
  • At some point something times out and things resume (in the above example the “SSSS…” update picked up where it left off).
  • If I use the ROM’s “talk” function to try and talk to the USB while this condition exists I get no response, however when it eventually times out I get the expected D:> prompt.
  • Feels like some kind of handshake or buffering issue ???

 

Let me know if anyone else has seen this or has suggestions. Thanks!

 

  • Glenn

 

Douglas Miller

unread,
Sep 6, 2022, 9:43:56 PMSep 6
to se...@googlegroups.com

If there was a timeout on the vh8util.sys end, it should have resulted in an error and abort (unless there's a bug in error handling). The vh8util.sys timeout should be based on 2.5-3 seconds, while waiting for input. Output status loop spins indefinitely. I'm not sure what causes LED activity in this case,  but I assume it is input/output of data bytes (and not status checks).

Could this be some artifact of the VDIP1 firmware handling of FAT filesystems, or something to do with the way the USB drive was formatted? Or even a failing USB drive (the VDIP1 hits bad blocks and is stuck doing redirection/recovery)? Sounds like each burst of LED activity is writing a sector (or track?) and then the quiet gaps are waiting for the VDIP1 to complete the file write.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/091501d8c256%249802dc90%24c80895b0%24%40gmail.com.

glenn.f...@gmail.com

unread,
Sep 7, 2022, 11:08:06 AMSep 7
to se...@googlegroups.com

Douglas: some more info on this issue. I’ve been able to repeat this sequence multiple times. This is with Version 2.0(beta30); Z80 Rev 4 board with DUART/USB daughterboard.

 

Pre-condition: Disk that I want to make an H8D image from is installed in the 5.25” hard sectored drive; system is powered on. nothing installed in USB.

 

  1. RST/0 to reset machine
  2. Install flash drive.  LED2 access light flashes 3 times then goes solid (indicating successfully seeing the drive)
  3. Run V8HDUTIL:

 

H8: Boot VV-:vh8dutil

H8DUTIL v1.0 - Type H(cr) for help

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

H8DUTIL>

 

  1. Attempt to save disk image.  USB access light flashes rapidly and get “command failed”:

 

H8DUTIL> s disk3.h8d

Command failed

H8DUTIL>

 

  1. Wait ‘til rapid flashing ceases, then try again. Disk drive motor starts; USB LED2 is solid but appears nothing is happening. After a while disk motor stops but system is doing nothing:

 

H8DUTIL> s disk3.h8d

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

 

  1. RST/0 to restart. Try again… same results as step 4. Command failed.

 

  1. RST/0 again, this time I try to “talk” to the VDIP.  At first no response (because USB LED2 is rapid flashing) but then I get a prompt!

 

  1. Now try to boot vh8dutil.  Just get back a ‘?’ !!  but I know it’s there (and I did a DIR just to make sure…)

 

H8 Monitor v2.0(beta30)

 

H8: XV VDIP1 talk

Ready.

 

 

D:\>

D:\>

 

H8: Boot VV-:vh8dutil

?

H8: XV VDIP1 talk

Ready.

 

 

D:\>dir

 

 

VIDEOS DIR

UCSDFI~1 DIR

TEMPLA~1 DIR

PUBLIC DIR

PICTURES DIR

MUSIC DIR

MIDI DIR

MACBAC~1 DIR

FROMKE~1 DIR

DOWNLO~1 DIR

DOCUME~1 DIR

DESKTOP DIR

ASMX-M~1 DIR

FOUND.000 DIR

ECHO.LST

VTOC.OUT

DISK1.H8D

SYSTEM~1 DIR

TURBOTAX DIR

SCHWAB~1.PDF

M-TG70~1.BIN

DISK2.H8D

DISK3.H8D

BIOSRE~1.EXE

TGB550PW.CAP

OLDFAM~1 DIR

VTALK89.C

VUTIL.C

VUTIL89.C

VDIR.C

VGET.C

VPUT.C

VTALK.C

FPRINTF.C

STDLIB.C

CLIBRARY.ASM

FLOATLIB.ASM

LONGLIB.ASM

LGFLTLIB.ASM

FTRFB.FTD

S_V1_8~1 DIR

DAD'SS~1 DIR

VH8DUTIL.SYS

D:\>

 

H8: Boot VV-:vh8dutil

?

H8:

 

I have tried at least three different USB flash devices and see the same behavior.

 

I’ll continue to monitor and try and collect info….

 

At some point, some how I got it to work and was able to save disk images.:

 

H8: Boot VV-:vh8dutil

H8DUTIL v1.0 - Type H(cr) for help

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

H8DUTIL> s disk1.h8d

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

H8DUTIL> s disk2.h8d

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

H8DUTIL> s disk3.h8d

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

 

However when I removed the flash drive only DISK1.H8D and DISK2.H8D images were there.  There is a “CLF” command in the vinculum command set (close files) – perhaps the file was never closed out???

 

Tried one more thing:  booted the system (RST/0) with the USB flash drive installed.  This time I was able to perform the image save, however there was a delay after the third “S” was printed since the USB light was rapidly flashing, but it recovered and continued

 

H8 Monitor v2.0(beta30)

 

H8: Boot VV-:vh8dutil

H8DUTIL v1.0 - Type H(cr) for help

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

H8DUTIL> s disk3.h8d

Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

H8DUTIL>

 

Just to be sure I did a VTALk and issued the CLF command.  The file is there now!

 

H8 Monitor v2.0(beta30)

 

H8: XV VDIP1 talk

Ready.

 

 

D:\>clf

 

D:\>dir

 

 

VIDEOS DIR

UCSDFI~1 DIR

TEMPLA~1 DIR

PUBLIC DIR

PICTURES DIR

MUSIC DIR

MIDI DIR

MACBAC~1 DIR

FROMKE~1 DIR

DOWNLO~1 DIR

DOCUME~1 DIR

DESKTOP DIR

ASMX-M~1 DIR

FOUND.000 DIR

ECHO.LST

VTOC.OUT

DISK1.H8D

SYSTEM~1 DIR

TURBOTAX DIR

SCHWAB~1.PDF

M-TG70~1.BIN

DISK2.H8D

DISK3.H8D

BIOSRE~1.EXE

TGB550PW.CAP

OLDFAM~1 DIR

VTALK89.C

VUTIL.C

VUTIL89.C

VDIR.C

VGET.C

VPUT.C

VTALK.C

FPRINTF.C

STDLIB.C

CLIBRARY.ASM

FLOATLIB.ASM

LONGLIB.ASM

LGFLTLIB.ASM

FTRFB.FTD

S_V1_8~1 DIR

DAD'SS~1 DIR

VH8DUTIL.SYS

D:\>

 

This part is *not* repeatable.  Sometimes when I RST/0 with the USB drive inserted it behaves as before….

 

(these are the CP/M 2.2.04 disk images that Mitch wants…)

 

  • Glenn

glenn.f...@gmail.com

unread,
Sep 8, 2022, 9:04:00 AMSep 8
to se...@googlegroups.com

So I have made some progress in this investigation but not much.

 

I went back to Rusty (Z80 rev 2.6 board with “new” H17-H37-H67 I/O board; VDIP-1/USB mounted on the H17 portion).  This is the system where I developed and tested the Vinculum utilities.  Everything seems to work fine on this system. I am able to consistently write files to the USB with no pauses or flashing LED access indicator… 

 

So the only difference between Rusty and my Z80 4.0 setup (other than the CPU board) is how the USB is interfaced (via the H17 board on Rusty and via the DUART/USB daughterboard on the 4.0 system).  So as an experiment I reconfigured the 4.0 setup to access USB via the H17 board, disabling the VDIP functionality on the USB daughterboard (and in fact replacing it with the original DUART-only version).

 

This did not solve the problem.  I still see issues when trying to write files to the VDIP/USB, either via my Vinculum utilities (e.g. VPUT, VPIP) or via Douglas’ VH8DUTIL utility.

 

So I have seen the issue only on Rev 3.1 and Rev 4.0 CPU boards.  I can’t’ reproduce the problem on the Rev 2.6 one (Rusty)

 

So that’s some progress I guess…

 

Getting ready for a little vacation time away  in the Canadian Rockies so maybe after a pause I’ll have some brilliant new ideas for solving this, meanwhile it remains a mystery.

 

Not sure if anyone else uses any of these capabilities or can replicate the problem? Would love to either see confirmation that I’m not going crazy or a system where someone has the same setup and does *not* see the problems I describe….

 

  • Glenn

 

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller
Sent: Tuesday, September 06, 2022 9:44 PM
To: se...@googlegroups.com
Subject: Re: [sebhc] odd VDIP behavior

 

If there was a timeout on the vh8util.sys end, it should have resulted in an error and abort (unless there's a bug in error handling). The vh8util.sys timeout should be based on 2.5-3 seconds, while waiting for input. Output status loop spins indefinitely. I'm not sure what causes LED activity in this case,  but I assume it is input/output of data bytes (and not status checks).

norberto.collado koyado.com

unread,
Sep 8, 2022, 4:02:31 PMSep 8
to se...@googlegroups.com
Please retest with the old H8 USB controller and let me know the status.

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of glenn.f...@gmail.com <glenn.f...@gmail.com>
Sent: Thursday, September 8, 2022 3:03:54 PM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: RE: [sebhc] odd VDIP behavior
 

glenn.f...@gmail.com

unread,
Sep 8, 2022, 9:39:12 PMSep 8
to se...@googlegroups.com

Let me take a more scientific approach.  I’ve been intermingling two problems in this thread and they may be very different.  I’ve had a problem with VPUT on a system I’ll call Game Boy (where I’ve been doing some HA-8-3 graphics and any other gaming work).  This is a Z80 Rev 3.1 box with the HA-8-3.    I had tested my Vinculum utilities on Rusty (Z80 2.6; HDOS 2.0 and CP/M 2.2.04) and Big Blue (Z80 4.0; HDOS 3 & CP/M 3).  At the moment I am unable to demonstrate an issue with either of those configurations with the Vinculum (VPUT and VPIP) utilities, so I’ll focus on Game Boy to see if the issue is mainly there.

 

I have also struggled with the VH8DUTIL tool on Big Blue.  That’s where I tend to have a repeatable problem with the USB hanging up in “LED flashing” mode.  That’s not nearly as big an issue for me as I’ve never really used or needed that (was trying to help Mitch). I’ll put that aside for now.

 

So let me focus on the Vinculum stuff and make sure there’s not an issue there.  Terry Smedley has a similar configuration and has been helping me…

 

Thanks!

norberto.collado koyado.com

unread,
Sep 9, 2022, 12:21:39 AMSep 9
to se...@googlegroups.com
The old H8 USB has a different read/ write cycle when compared with the new boards.

Sent: Friday, September 9, 2022 3:39:08 AM
Reply all
Reply to author
Forward
0 new messages