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:
Let me know if anyone else has seen this or has suggestions. Thanks!
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.
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.
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>
H8DUTIL> s disk3.h8d
Command failed
H8DUTIL>
H8DUTIL> s disk3.h8d
Using drive 0, volume 0, secmap 0 1 2 3 4 5 6 7 8 9
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…)
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/71043edf-3ca1-d401-8e69-38814e2ab9bb%40gmail.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….
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).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/71043edf-3ca1-d401-8e69-38814e2ab9bb%40gmail.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!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855E8B446F88C3B3C3A77E5F7409%40SN6PR01MB3855.prod.exchangelabs.com.