odd VDIP behavior
glenn.f...@gmail.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
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
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.
- RST/0 to reset machine
- Install flash drive. LED2 access light flashes 3 times then goes solid (indicating successfully seeing the drive)
- 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>
- Attempt to save disk image. USB access light flashes rapidly and get “command failed”:
H8DUTIL> s disk3.h8d
Command failed
H8DUTIL>
- 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
- RST/0 to restart. Try again… same results as step 4. Command failed.
- 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!
- 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
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/71043edf-3ca1-d401-8e69-38814e2ab9bb%40gmail.com.
glenn.f...@gmail.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).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/71043edf-3ca1-d401-8e69-38814e2ab9bb%40gmail.com.
norberto.collado koyado.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
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.