h8dutility woes (again)

[smb...@gmail.com]

I seem to have lost my magic recipe for making h8dutility work. Some questions.

1) Is the "XH" command to load the h8dutility monitor in the Z80 board's monitor believed to be functional? This has never done anything for me other than print "h8d ready" on the display and then hang as soon as I send anything to it.

2) Back to using my original 8080 board, which used to work, now after sending the h8dutility client over from the h8duitility command (which always says it's successful), random behavior occurs, which is either a) lock up, b) set PC to some strange address, c) blank the display, or d) garbage characters on the display.

3) I've tried Norberto's tape board, with the PLD set to put the 16550 at 340Q. I've tried my H8-4. No difference on any of them. Last time one or the other of these failed.

4) The computer otherwise works fine and the serial ports are stable.

5) Anything else I should try?

6) Somewhere around here I had the documentation for Maple, but I can't remember where. Google isn't helping me. Does anyone have a pointer? If I could figure out how to get maple working, then I would at least have some file transfer capability.

Scott

[norberto.collado koyado.com]

The “XH” command works.

 

Per Douglas: The missing step for using the XH command is to replace H89LDR3.BIN with the one from the URL that I posted.

https://github.com/durgadas311/MmsCpm3/blob/master/rom/newmon/src/h8dutil/bin/h89ldr3.bin. 

 

I used the vh8dutil file instead.

 

 

Norberto

--
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/de5a40f5-ae75-4320-b12f-870b89198864n%40googlegroups.com.

[norberto.collado koyado.com]

For the vh8dutil.sys file, I just copy the H8D file to the VDIP1 USB flash drive using my laptop. Rename to 8 chars or less such as “HDOS2.H8D”.

 

Then at the Z80 console I just boot from the VDIP1 the vh8dutil file, then type r HDOS2.H8D and done. It will be looking for the H17 controller to complete such operation.

 

No need to use the laptop to do the same thing on the H17 controller.

 

Norberto

[smb...@gmail.com]

Thanks Norberto, I'll give XH a shot this weekend with the file you linked.

I just got a successful run with h8dutility (and then I rebooted and it succeeded again). This time I've written down every single board installed, which slot, and configuration of the jumpers on the H8-4. I also saved two backup copies of the loader to floppy as last time I did this there was an issue with the floppy (fool me once shame on you; fool me twice shame on me). Then I tested the backup floppies. So I have multiple reliable boot media now and I'll never have to send that loader across again. I'm still not sure what the magic was.

I really do need to investigate the USB. Haven't used it yet.

Scott

[norberto.collado koyado.com]

For sure you will love the USB VDIP1 vh8dutil file….

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3f338d8b-d96e-42bf-b781-faefcb20180bn%40googlegroups.com.

[glenn.f...@gmail.com]

There’s an “off by 3” addressing problem with the H89LDR3.BIN files on the versions on the SEBHC site. the way the software works this will cause failure. we need to fix this as multiple folks have had this problem.

 

I’ll take a look and work with Les to make any necessary updates.  Watch for follow up, meanwhile I think if you make the replacement with the version on Doug’s site you can get things working.  This seems like a configuration control issue of some sort…

 

• Glenn

 

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of smb...@gmail.com

Sent: Tuesday, February 14, 2023 2:27 AM
To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] h8dutility woes (again)

 

Thanks Norberto, I'll give XH a shot this weekend with the file you linked.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3f338d8b-d96e-42bf-b781-faefcb20180bn%40googlegroups.com.

[smb...@gmail.com]

Thanks Glenn,

I think one of the frustrating factors is that documentation seems to be somewhat temporally ordered -- as people discover new approaches, discover bugs and implement fixes, re-discover old things, etc., it forms a narrative with the git repo as a source of supporting artifacts (i.e. software) rather than going into a git in a structured documentation effort. To know how to setup an H8, you follow a series of documents that are one-offs and/or research forum topics for inbetween things that didn't make the one-offs. If you're lucky, you stumble on someone else's forum thread where they recently restored an H8 and learn the latest process. Someone doesn't amend a user guide; instead they make a forum post or drop a document somewhere or upload some new software version.

If I've been following correctly, you've started working on a new git repo (or spiffing up the old one). I think this offers a good opportunity to create a more evolving users guide. You can always pull older by using git history, but pulling latest always gets you the current documentation. One of the great things about git is that it's easy to collaborate.

Scott

[dwight]

Do make sure that both variants of serial board work. I recall a speed issue with H8-5 ( the one with the TTY interface? ). The optical isolator was the source of the speed problem. The regular RS323 board always worked fine. I have both boards but haven't had the H8 powered on for years.

One thing that could be done is to add a manual entry for the locations that the H17 code initializes to those that can be hand entered. I never did that because I found it hard enough to just enter the minimum bootstrap code, correctly. That is the main issue with the correct order.

It could possibly be added to the client but that has to be a specific length to match the bootstrap. Both would need to change at the same time. If someone thinks they can enter a couple hundred bytes by hand, there is no reason the client couldn't be entered by hand as well. After all, that is all the bootstrap code does. It reads the client in in reverse order. When the last byte of the boostrap is overwritten, it then does an alignment check of the client code with a small piece of non-address dependent code. Then it starts the client code. That interprets the various active file transfer commands.

Dwight

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of smb...@gmail.com <smb...@gmail.com>
Sent: Tuesday, February 14, 2023 10:45 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4b80c660-ecfd-4510-9442-6e524a2a8cc2n%40googlegroups.com.

[smb...@gmail.com]

Thanks Dwight. That the client length must match between client and loader helps to explain a lot. Also, I've wondered by the last byte of the loader changes, and now I know! :)

I agree with keeping the loader simple to facilitate keyboard entry. I had not thought about entering the client directly. The Raspberry Pi Bus Monitor board I mentioned a month or two back could actually push it into RAM, though one has to use an external RAM board if one wants to make use of a HOLD.

Scott

[smb...@gmail.com]

No joy on the Z80. H8loader does actually go into "Ready" state after uploading the client that Norberto linked, but then it does not successfully accept the track data. Z80 board also does not work with the client that I saved to floppy. Pull the Z80 and install an 8080 board and it works fine.

I feel like there's a bus stability issue on this computer that I've been chasing since the day I build the H8-4, that I just can't wrap my head around. It feels like we're dropping bytes.

Scott

[norberto.collado koyado.com]

Scott,

 

I can try tomorrow on my system using the Z80 V4 board. Send me some steps to reproduce here and the H8D file to use. I will be using the Z80 on-board serial port. I’m not using the H8-4 anymore.

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cf9c8d6d-4ea9-47e7-a953-807667ef97c1n%40googlegroups.com.

[norberto.collado koyado.com]

Can you remove the H8-4 board and use the Z80 v4 on-board serial port instead and try again? As you mentioned that works with the 8080A, it looks like a jumper setup on the Z80 v4 board..

 

Removing the H8-4 will give me information on what might be the issue.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38558CB5CC12F14CF6171320F7A39%40SN6PR01MB3855.prod.exchangelabs.com.

[Scott Baker]

I haven't built the DUART card for the Z80 yet. I can do that this weekend and let you know... This would be way better than dealing with the H8-4.

BTW, Is it possible to use an 8250 instead of a 16550?

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855C096F3C56AE8A1ABABE6F7A39%40SN6PR01MB3855.prod.exchangelabs.com.

[glenn.f...@gmail.com]

This may be the same issue that Joe Travis recently had, and that I encountered some time ago.  The “Dwight Elvey” H8 loader was originally designed/tested (nearly 20 years ago!) on 8080 CPU H8 systems (H8-5) and the H89.  The H89 code (8250 UART) also works fine on the H8 with H8-4/8080 CPU.  On Z80-based H8 systems there appears to be enough lag due to the 2ms/Front Panel ISR that occasionally bytes can be dropped on the receiving end, since the serial handler uses task-time polling (not interrupt-driven).  Some time ago I developed a fix for this by turning off the front panel refresh while the program is receiving data.

 

I’ve also been having a sidebar with Douglas on his H8DUtility support in the Rev 4 Z80 ROM.  it seems there are a few things we need to do to synchronize all these efforts and get to the point where this works reliably on all configurations.  May take a bit to get there… stay tuned.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cf9c8d6d-4ea9-47e7-a953-807667ef97c1n%40googlegroups.com.

[norberto.collado koyado.com]

BTW, Is it possible to use an 8250 instead of a 16550? Yes you can use an 8250 instead. I will double check tonight.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CA%2B8qVMMMsdwBnbSvC2m-ORM7eM7M7-pfWjnXTP79XGDxr6uRog%40mail.gmail.com.

[Joseph Travis]

It bothers me that the myth about the H8-5 optical coupler continues to be propagated as not being able to handle "high speed" which is not true. Some make it sound like the light source is incandescent!

At 9600 baud, the bit rate is ~10 KHz (100 uS) which no problem for this device where it's typical rise/fall times is 2 uS and propagation delay is 1.5 uS.

I've used the H8-5 numerous times with H8DUtility without trouble. I also use it as the console device at 9600 baud when running tape based programs.

 Where I have encountered problems is when using a Z80 CPU board with PAM37 installed. In that case, the 2mS interrupt is overloaded and indirectly causes H89LDR to fail.  My understanding is that Glenn was able to fix that issue by turning off the FP LED update during transfers.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/23acebe6-5f49-493b-b7f7-ece3b5353e7cn%40googlegroups.com.

[Les Bird]

Joe brings up a good point.

I've had rock solid performance with my H8-4 when using it with H8DUtility but like Glenn with his Rusty H8 I'm using a V2 CPU with XCON8 ROM. Joe's point about the 2ms interrupt in PAM37 being overloaded could be the problem. When I made H37IMGR I made it work at 38,400 baud on a H8-4 by turning off the front panel monitor using a DI command. My H8-4 has 16550s.

Les

[Douglas Miller]

Opto-isolators are usually intended for current-loop. Is anyone actually running current-loop? I'm not clear why anyone would be trying to use opt-isolators for +/-12V RS-232.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/189fdb22-2271-4f08-b48f-acb97551f50en%40googlegroups.com.

[Glenn Roberts]

After 19 years it's probably time to discuss some updates to Dwight's code. The trick will be to coordinate across all the use cases. The current version for use with the Rev 4 Z80 (and presumably 8080A and Z180 to follow) does blank the LED refresh, but also makes a call to a ROM-based routine to detect user interrupt (ctrl-c)

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/189fdb22-2271-4f08-b48f-acb97551f50en%40googlegroups.com.

[norberto.collado koyado.com]

I couldn’t resist and did a quick test on the Z80 V4 board as a console. It worked fine and booted HDOS2.0 without any issues. I kept the circuit backwards compatible.

 

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855440C25231C692CB79C11F7A39%40SN6PR01MB3855.prod.exchangelabs.com.

[norberto.collado koyado.com]

Scott,

As this is becoming a nightmare for you, I’m going to revive the project I started a while ago and that was to convert the Z67IDE+ to be a hard sector floppy drive. I did the schematics but never layout the pcb. It contained 512KB of RAM + micro at 33MHz + serial port + CF card + other stuff. As it is a raw device you can do reads and writes. The analog part is done by HW and not software. 

It will be a low priority design.

Norberto 

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of norberto.collado koyado.com <norberto...@koyado.com>
Sent: Wednesday, February 15, 2023 7:13:43 AM
To: se...@googlegroups.com <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385508671A289E0BE153C25DF7A39%40SN6PR01MB3855.prod.exchangelabs.com.

[Steven Shumaker]

Yes!  I'd like to try connecting a modern setup to ASR33s for "classic" I/O. It's doable with convertors but native would be nice!

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/361311e4-5738-f479-43f5-2aa8c3b65946%40gmail.com.

[glenn.f...@gmail.com]

So I’m investigating all of the ways we use the H8DUtility and I can’t seem to get anything to work with the “XH” command in the new ROM.  I have substituted in the h89ldr3.bin image on Douglas’ site (below). I’ve tried both Les’ older H8DUtilitiy (v 2.2) and his new V3.  When I get to the point where the .BIN gets downloaded that appears to partially work, at least something happens – the H17 disk drive motor comes on, head loads, and activity LED lights, but then nothing further.  This is with the 2.0(beta30) ROM.  Since RTM/0 is not supported by the ROM I can’t break out and see where the code is hanging, nor can I monitor the Program Counter as the ROM takes over the LED display.

 

Norberto: do you have this working?  what are you using for the PC client?

 

Doug has pointed me to the ROM and h89ldr3 code so I’ll start digging there…

 

• Glenn

 

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto.collado koyado.com
Sent: Tuesday, February 14, 2023 2:09 AM
To: se...@googlegroups.com
Subject: RE: [sebhc] h8dutility woes (again)

 

The “XH” command works.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855940679AC5F9A9984B419F7A29%40SN6PR01MB3855.prod.exchangelabs.com.

[Douglas Miller]

RTM/0 should be working, but that requires interrupts to be enabled. So, can't always guarantee it will work - especially with something like this.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/05f101d94191%247b9dc1e0%2472d945a0%24%40gmail.com.

[norberto.collado koyado.com]

Glenn, I will check once I get home.

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Sent: Wednesday, February 15, 2023 3:26:38 PM
To: se...@googlegroups.com <se...@googlegroups.com>

Subject: Re: [sebhc] h8dutility woes (again)

 

RTM/0 should be working, but that requires interrupts to be enabled. So, can't always guarantee it will work - especially with something like this.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/96067a6d-f069-d67e-e641-83d9fb7e22e5%40gmail.com.

[smb...@gmail.com]

Norberto, sounds interesting. Would like to hear more.

I also wanted to mention, as a console the serial works fine. Even at 16 MHz (see other thread) I'm having success. It's only when loading h8dutility. I wonder if there's something to the speculation that it's falling behind at 2MHz and dropping bytes. Anyhow, if others can get it to work, I'm sure I can. Having a known set of component version (ROM, loader, client, and PC app) would probably be a diagnostic help in at least reproducing a known configuration.

I would like to know more about the Vinculum. I know nothing about it. I know it's a USB device and provides the ability to read USB thumbsticks. But what kind of driver support does it require? Do you need a special HDOS driver?

Scott

[Douglas Miller]

The VDIP1 device we're talking about isn't really practical as a online storage device for CP/M or HDOS. But Glenn makes a fine set of utilities for CP/M and HDOS that allow copying files in and out (and other interaction required). And The new ROMs have a way to load "standalone" programs off the thumb drive, and update the ROM from it, and also save/restore H17 floppy images on it.

Basically, the VDIP1 only allows one file to be open at a time. But within those limits it has become a very essential add-on.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7c5244e9-1d41-4c23-9d2d-f3a527c9ede5n%40googlegroups.com.

[smb...@gmail.com]

Yeah, I just found one of the pages on the USB adapter board that described the VDIR and VGET commands.

I need one. I should have bought one from the start.

Scott

[smb...@gmail.com]

Well, damn. Seems I can't have one. They're out of stock everywhere. :(

Scott

[norberto.collado koyado.com]

Glenn,

 

I’m using Monitor v2.0(beta30) and having same issue as you. I do get the “Ready” message on the H19 terminal, the H17 disk drive motor comes on, head loads, and activity LED lights, but then nothing further. 

 

Douglas, I had to boot first from the H17 to get the same state as Glenn. I thought that was fixed.

 

 

BKM: http://koyado.com/Heathkit/H89-SBC_H8D_Utility_files/H89-SBC-H8D_Utility.pdf

 

 

I tested way back with beta 20 and it worked. I cannot find such monitor anymore.

 

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385588898420308A115426B6F7A09%40SN6PR01MB3855.prod.exchangelabs.com.

[norberto.collado koyado.com]

On Order:

814

Expected 16-Mar-23

 

Just around the corner.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cb92d5ee-f8ea-43ec-97af-accab9c7a34fn%40googlegroups.com.

[Glenn Roberts]

So the VDIP1 module is an older part, introduced at least 15 years ago. FTDI makes a newer module based on their second generation Vinculum product. A while back we looked into switching but at the time VDIP1 devices were plentiful.

Terry has begun experimenting with the V2DIP1 and so far there appear to be only minor differences. We may have to tweak our code to detect which module is in use. We should know more soon, meanwhile, as Norberto says, Mouser is expecting more devices next month

Sent from my iPad

On Feb 16, 2023, at 2:28 AM, norberto.collado koyado.com <norberto...@koyado.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB38447E0D71E7C0818AB03B99F7A09%40BN7PR01MB3844.prod.exchangelabs.com.

[Glenn Roberts]

Scott: my VDIP utilities live here

See docs directory for documentation.

Sent from my iPad

On Feb 16, 2023, at 12:34 AM, smb...@gmail.com <smb...@gmail.com> wrote:

Yeah, I just found one of the pages on the USB adapter board that described the VDIR and VGET commands.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/55d8bf7c-58b8-48d5-9da3-cdfdd7e46706n%40googlegroups.com.

[Douglas Miller]

I'm not sure I fully understand the scenario. The XH command already does the H17 initialization, so it should not be necessary to manually fake-boot the H17. Not sure if that unnecessary step is causing the problem. If there is a way to run the H8DUtility client on Linux, I could try and reproduce with the simulator (not sure how I get it to connect to a simulated serial port, though).

Keep in mind, that the bootstrap code puts "ready" in the display (and prints to the terminal) and jumps to the downloaded routine. The fact that the display says "ready" does not really mean anything after that, unless the code crashed badly enough to disable interrupts or corrupt the display memory.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844144FE507A0DE95F3D1B7F7A09%40BN7PR01MB3844.prod.exchangelabs.com.

[Glenn Roberts]

Ok thanks for checking Norberto. I’ll investigate

And Scott: I don’t think there’s anything going on with your H8-4 board. The fact that you can get this working with the 8080 board but not the Z80 board seems to be the smoking gun pointing to the LED refresh issue. I solved this problem years ago, but the code never got folded into our baseline, and now we have the new XH ROM command version to accommodate.

We’ll work it…

Sent from my iPad

On Feb 16, 2023, at 2:26 AM, norberto.collado koyado.com <norberto...@koyado.com> wrote:



Glenn,

 

I’m using Monitor v2.0(beta30) and having same issue as you. I do get the “Ready” message on the H19 terminal, the H17 disk drive motor comes on, head loads, and activity LED lights, but then nothing further. 

 

Douglas, I had to boot first from the H17 to get the same state as Glenn. I thought that was fixed.

 

<image001.png>

 

BKM: http://koyado.com/Heathkit/H89-SBC_H8D_Utility_files/H89-SBC-H8D_Utility.pdf

 

 

I tested way back with beta 20 and it worked. I cannot find such monitor anymore.

 

<image003.png>

 

<image004.png>

<image002.jpg>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844144FE507A0DE95F3D1B7F7A09%40BN7PR01MB3844.prod.exchangelabs.com.

[Scott Baker]

Glenn, I will order myself a couple VDIP1 if they do in fact come back into stock next month. I have my doubts as the chip shortage still seems to be having a disproportionate effect on anything the hobbyist community might possibly want to use.

In the meantime, I did have a wild idea. I looked at the schematics and I looked at your code. It looks like a fairly straightforward approach of a couple latches and a flipflop and I could easily interface a raspberry pi zero w to replace the vdip1, using your original VDIP HDOS tools. Perhaps more work that I want to go to, but it is an interesting thought. No more sneakernet of USB sticks.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/41A219C0-9311-4C12-B4B5-A958957729A2%40gmail.com.

[smb...@gmail.com]

Also, is there a thread on the differences between VDIP1 and V2DIP-32? Looking at the datasheet, it appears they tried to make the hardware pin compatible (it seems possible to ignore the bottom-most 8-pins of the 32-pin part). That attention to hardware compatibility maybe means they also attempted to be software compatible? You mentioned "minor differences".

Finally, are there instructions on how to compile your VDIP utilities?

Scott

[Glenn Roberts]

Terry is experimenting with the V2DIP. He has verified that the -48 version works with my utilities but there is a slight difference in the DIR output, necessitating a change to either the VDIP firmware or my code. We will figure out the best way to handle this. He will look next at the V2DIP-32

Instructions on compiling my utilities are in the documentation in the docs subdirectory on GitHub. Douglas has also been working on Linux-based tools to do these builds, and I believe that is working now. Ive been doing the builds on my H8 directly. One thing I don’t think is mentioned in the docs is the difference between how HDOS and CP/M handle end of line in ASCII files. HDOS uses Unix-style NL termination and CP/M uses CR-LF. C/80 does not like those CR characters! The code is stored in GitHub in CR-LF format. There is a STRIP utility there to strip out the CRs.

 If you would like to make enhancements that would be beneficial to the group I’d be happy to work with you to test and release..  given recent issues we’ve seen with the H8D utility configuration control, to take an example, I’m anxious to avoid proliferation of multiple versions…

Sent from my iPad

On Feb 16, 2023, at 11:40 PM, smb...@gmail.com <smb...@gmail.com> wrote:

Also, is there a thread on the differences between VDIP1 and V2DIP-32? Looking at the datasheet, it appears they tried to make the hardware pin compatible (it seems possible to ignore the bottom-most 8-pins of the 32-pin part). That attention to hardware compatibility maybe means they also attempted to be software compatible? You mentioned "minor differences".

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7423709e-5510-41a0-a129-c9a1f0e558dan%40googlegroups.com.

[Douglas Miller]

Glenn also provides already-built images of the utilities, so there's really no need to build them again.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/131B0DD0-7FE6-4EA3-B85D-F2E805C2F6B3%40gmail.com.

[dwight]

My H8-5 would work, reliably, above 4800. I was able to tune the optical coupler with a bias resistor and get 9600 to work. Be careful when looking at the specification of the isolator. The rise and fall times shown in the manufactures documentation use optimal load resistors for that transition! The delay is different for rise and fall. The spec it meaningless for both transitions. I worked with designing the use of optical isolators when at Intel.

You may be lucky with the particular opto you have but not everyone has luck with them.

Dwight

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Joseph Travis <jtravi...@gmail.com>
Sent: Wednesday, February 15, 2023 6:22 AM
To: se...@googlegroups.com <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBAMOKRz5dHdvjgC04St3PhQyBQ1ONUvHus-hC%3Dpg9h0ww%40mail.gmail.com.

[norberto.collado koyado.com]

Dwight,

 

Can I get the schematics with your tunning and which opto to use?

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SA1PR11MB6941CCE8003DF0371B9132EBA3A19%40SA1PR11MB6941.namprd11.prod.outlook.com.

[norberto.collado koyado.com]

I got never the V2DIP-32 to work as by default the parallel port fw is not loaded. You will need the adapter to program it to load the parallel port fw. That increases the  overall price. If I find the parts, I can send to Terry.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/131B0DD0-7FE6-4EA3-B85D-F2E805C2F6B3%40gmail.com.

[Terry Smedley]

I have the programmer, Norberto.  

The V2DIP1-48 is a drop-in replacement for the VDIP1, with one exception.  VDIP1 firmware inserts a blank line before the DIRT command results, V2 firmware does not.  I modified the V2 firmware to include the extra line and Glenn's utilities work without issue with the V2DIP1-48 module.  FTDI provides the Vinculum-II firmware source and a full IDE which makes firmware customization straightforward.

Looking at the source for the V2 firmware, I think firmware upgrades will be possible over the USB port (as with the V1 firmware) for the -48 module.  I just need a little time to confirm that. If the "firmware over USB" procedure works as expected, then the V2DIP-48 becomes a reasonable replacement for the VDIP1 requiring no external programmer and no changes to Glenn's software.

The V2DIP-32 has a different set of challenges.  As Norberto points out, the 32-pin package doesn't have enough pins to support the interface selection jumpers that were available on the 48 pin devices.  A separate programming adapter is needed to load the interface-specific firmware.  Once the V2 FIFO firmware is loaded onto the -32  module, I expect it will be compatible with Glenn's utilities.  It is also possible that a firmware upgrade of the V2-32 device will be possible over the USB port, eliminating the need for the external programmer.  I have a V2-32 module coming, and I'll check that possibility out.  I can't tell without the hardware in hand because the source has a number of conditionals for assembly of that functionality, and I don't know which functions have been enabled on the firmware that is pre-loaded on the module at the factory.

The V2DIP1-32 also omits the DATAREQ# and DATAACK# pins that are found on the V1 and V2-48 modules.  This does not affect Glenn's utilities, but it does mean you can't operate the V2-32 module in DATA mode.  I use DATA mode for direct USB-serial communications with other FTDI devices, but if you're not looking for that functionality the loss of those two pins doesn't matter.

You should also be aware that the V2DIP1-48 (at least the one I received) uses square pins rather than the round machined pins found on the VDIP1.  It won't fit into a machined socket.

tas

Links:

Vinculum-II IDE and firmware source

https://ftdichip.com/firmware/vnc2-tools/

VNC1L to VNC2-48L1C migration guide

https://ftdichip.com/wp-content/uploads/2022/03/AN_118_Migrating_Vinculum_Designs_From_VNC1L_to_VNC2-48L1C.pdf

[norberto.collado koyado.com]

I will keep using the VDIP1 until end of days. 

Great feedback and thank you.

Norberto 

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Terry Smedley <terry....@gmail.com>
Sent: Friday, February 17, 2023 8:23:01 AM
To: SEBHC <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/18768ca4-04bb-4ca2-9cc7-9d281450ac6an%40googlegroups.com.

[Terry Smedley]

For anyone who already has a VDIP1, there's no reason to move to the V2 product.  But the V1 is getting difficult to find, and has been listed as "NRND" at FTDI for quite a while.  The only reason I began looking at the V2 modules was to try to find an alternative to the VDIP1 for those who can't source one.

If you're interested in tinkering with the internals of the Vinculum chip, the V2 IDE and supplied source provide a playground that isn't available for the V1 product.  I'm sure that with enough concentrated effort, it should be possible to brick a V2DIP1 in short order.

tas

[glenn.f...@gmail.com]

I did a search on Octopart

 

https://octopart.com/search?q=vdip1&currency=USD&specs=0

 

I think the only ones who have them seem to be OEM suppliers…

 

Utmel seems to have cornered the market.  not sure the price means anything but if it does it’s no wonder they haven’t sold !

 

Do companies like this ever deal with the consumer market for bulk buys? I’d be happy to buy out  a chunk of Decca’s stock at $4.39 a pop!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855D006575F41B9AEAB2A95F7A19%40SN6PR01MB3855.prod.exchangelabs.com.

[smb...@gmail.com]

Changed the subject line in hopes we can stop contaminating the h8dutility thread (my fault!).

I think Radwell was offering them at ~ $55 from an external supplier, perhaps they're using Utmel as that supplier.

Anyhow, I went ahead and ordered a couple V2DIP1-48. I can't see any reason to wait to see if VDIP1 comes back into stock as promised and pay extra $$ for it (Mouser's price for VDIP1 is higher than V2DIP1-48).

Scott

[norberto.collado koyado.com]

On the square pins it should not be an issue with the new H27 board.

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of smb...@gmail.com <smb...@gmail.com>
Sent: Friday, February 17, 2023 1:38:31 PM
To: SEBHC <se...@googlegroups.com>
Subject: [sebhc] Re: Vinculum VDIP1, V2DIP1, and related

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1a77ce05-3258-43d6-8559-ae08cabcd6e8n%40googlegroups.com.

[Mark Garlanger]

What's the H27 board?  "H-27" was the drive unit for the H-11.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385517D2D6C0A44B4C98CEBDF7A19%40SN6PR01MB3855.prod.exchangelabs.com.

[Scott Baker]

Maybe Norberto meant H-17?

Norberto, are you referring to the new socket pins that recess into the board? Is there a part number for those?

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm79QxK3bM6fyiksRxAXczdkDhjnoP%2B%3DT%2B9LoMUXnbh-1YQ%40mail.gmail.com.

[norberto.collado koyado.com]

It was a typo on cell phone; H17. The holes for the VDP1 on the H17 are bigger to hold any headers needed. For the square pins I do not have any part number. Perhaps you could use the Arduino headers sold in Amazon.

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Scott Baker <smb...@gmail.com>
Sent: Friday, February 17, 2023 4:32:53 PM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: Re: [sebhc] Re: Vinculum VDIP1, V2DIP1, and related

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CA%2B8qVMPHQ2WxJt7-DVTaLcZqdMDE5660bm%3DFkortR6ssMN2%2Byg%40mail.gmail.com.

[smb...@gmail.com]

Terry, I need to validate that my Pinculum board works with a V2DIP1-48 module before I can consider it ready to hand off to others. Is your modified firmware available? The one that adds the blank line after DIR ? I can probably duplicate this given the IDE and source code, but it would be easier just to use what you already figured out, especially if you've sorted out anything else, such as mapping the pins to their VDIP1-compatible functions.

Thanks,

Scott

[Glenn Roberts]

FYI: I’ll be modifying my Vinculum utilities to account for the difference in output format once I get my hands on the V2DIP… the resulting code will support either version.

Sent from my iPad

On Mar 8, 2023, at 9:37 PM, smb...@gmail.com <smb...@gmail.com> wrote:

Terry, I need to validate that my Pinculum board works with a V2DIP1-48 module before I can consider it ready to hand off to others. Is your modified firmware available? The one that adds the blank line after DIR ? I can probably duplicate this given the IDE and source code, but it would be easier just to use what you already figured out, especially if you've sorted out anything else, such as mapping the pins to their VDIP1-compatible functions.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c344f0a1-86db-40f4-8c7a-b4e27b0b45b6n%40googlegroups.com.

[Terry Smedley]

When I return home tomorrow I will post the revised firmware.  No changes were made to the FTDI posted source except for the single blank line.  

I believe Glenn is going to revise his V-utilities to accept both formats so that either the VDIP-1 or V2DIP1-48 can be used "out of the box".

For those waiting for Mouser to receive more VDIP1s, note that the expected date is now shown as 10/19/2023.  V2DIP1-48s are in stock.   The V2DIP1-32 will not function in FIFO/parallel bus mode, or at least I and several others posting to the FTDI forums have been unable to make it work in that mode.  The V2DIP1-48 is a pin-compatible replacement for the VDIP1.

tas

[norberto.collado koyado.com]

Scott,

 

I have two new VDIP1 modules which I flashed a different FW to test the second USB pot. But I couldn’t flash it back with the default FW. I can send both to you and I just need one back running the correct FW, if you can recover them.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b0f90356-76b1-46a5-9c76-30fe0aaaa359n%40googlegroups.com.

[smb...@gmail.com]

No need Norberto, but thanks. I have a couple of V2DIP1-48 here. If they work in my board, I'll assume the VDIP1 also works.

Scott

[glenn.f...@gmail.com]

Norberto: if you’ve “bricked” your VDIP1 modules we may need the VPROG1 programmer to reprogram them

https://ftdichip.com/products/vprog-1/

 

or the ZIF equivalent:

 

Terry may know of other ways to do this?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385597455C3A68C12DD5FCABF7B59%40SN6PR01MB3855.prod.exchangelabs.com.

[Terry Smedley]

Here is the updated V2DAP firmware for the V2DIP1-48 module.

The modification to the V2DAP sample provided in the Vinculum-II Toolchain IDE is a one-line change in cmd_disk.c (below).

NOTE:  The interface selection jumpers on the V2DIP1-48 must be set opposite of what is described in the datasheet (and how they were set on the VDIP1).  Oriented with the USB ports on the left, the debug pins on the right, JP1 must be DOWN and JP2 must be UP.  It would be simple enough to modify the firmware to use the same jumper positions as the VDIP1 (and the datasheet).  But this is "set once and forget" so I didn't bother.

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

code snippet from cmd_disk.c showing my extensive modification:

/*
** cmd_dirt
**
** Show file create, modify and access times.
**
** Parameters: none
** Returns: MON_SUCCESS, MON_ERROR_INVALID_FILENAME name is not a valid file name,
**  MON_ERROR_CMD_FAILED could not show time information for file.
** Comments:
*/
unsigned char cmd_dirt()
{
char cr = 0x0d, sp = ' ';
file_context_t fileFind;
unsigned char result = MON_ERROR_CMD_FAILED;
void *findHandle;
unsigned short date;
unsigned char i;

// filename specified:
monReadFileName(1);
// purge until CR
monReadCr();

result = monValidateFileName(1);

if (result == MON_SUCCESS)
{
// We have a valid parameter.
if (fat_dirTableFind(fatContext, &fileFind, (char *) param1Data) == FAT_OK)
{
-----------------------------------------------------------------------------------------------------------------------------------

// TAS added for compatibility with VDAP
monWrite(&cr, 1);
// end of extensive modification by TAS
-----------------------------------------------------------------------------------------------------------------------------------

monWriteFileName((char *) &fileFind);
monWrite(&sp, 1);

date = fat_dirEntryTime(&fileFind, FAT_DIRENTRYTIME_CREATE_TIME);
monAddNumberToConsole((unsigned char *) &date, 2);
date = fat_dirEntryTime(&fileFind, FAT_DIRENTRYTIME_CREATE_DATE);
monAddNumberToConsole((unsigned char *) &date, 2);
date = fat_dirEntryTime(&fileFind, FAT_DIRENTRYTIME_ACCESS_DATE);
monAddNumberToConsole((unsigned char *) &date, 2);
date = fat_dirEntryTime(&fileFind, FAT_DIRENTRYTIME_MODIFY_TIME);
monAddNumberToConsole((unsigned char *) &date, 2);
date = fat_dirEntryTime(&fileFind, FAT_DIRENTRYTIME_MODIFY_DATE);
monAddNumberToConsole((unsigned char *) &date, 2);
monWrite(&cr, 1);
}
else
{
result = MON_ERROR_CMD_FAILED;
}
}
else
{
result = MON_ERROR_INVALID_FILENAME;
}

return result;
}

On Wednesday, March 8, 2023 at 6:37:09 PM UTC-8 smb...@gmail.com wrote:

[Glenn Roberts]

So if you haven’t been following this:

The VDIP is the module from FTDI that we’ve been using for many years to do file transfers to/from USB flash drives. I wrote the software we use. Our designs use the VDIP1, which is a sort of breakout board with the VNC1L SMT chip mounted on a small board with a 24-pin form factor that fits into a machined DIP socket.

But VDIP1 is nearing end of life so we are looking at a slightly newer product V2DIP, which is still available. It has the same form factor as the VDIP1, but with header style leads necessitating a different socket style. The firmware is almost identical but there is a slightly different format of output from the DIR (directory) command, which causes issues with my Vinculum utilities.

Terry has temporarily tweaked the VDIP firmware to make it behave like the older VDIP1, but I will modify my utilities to solve this problem so that we don’t have to maintain our own firmware

Sent from my iPad

On Mar 9, 2023, at 10:19 AM, Terry Smedley <terry....@gmail.com> wrote:

Here is the updated V2DAP firmware for the V2DIP1-48 module.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/bf8a4fdf-6967-427f-9ab3-4af08dd111f5n%40googlegroups.com.

<V2DAP.rom>

[smb...@gmail.com]

Question about booting from the VDIP module. I can see that this attempts to load a file called "defboot.sys", but what should I put in that file? an H8D image? an H8T image? Something else?

Thanks,

Scott

[Douglas Miller]

That is an extended CP/M 3 .SYS file. The basic format is described in the CP/M 3 System Guide Appendix D. I thought I had added documentation of this in the Monitor ROM document, but it is not there yet.

The VDIP boot command allows you to specify the name of the file to run, so you don't need to force anything to be named "defboot.sys". Have a look at the ROM documentation at https://github.com/durgadas311/MmsCpm3/blob/master/rom/newmon/doc/H8-Monitor-2.pdf and let me know specifically what you want to do. There are SYS files (standalone commands) in the https://github.com/durgadas311/MmsCpm3/tree/master/rom/newmon/bin folder (mixed in with other files).

Note the VDIP "booting" is only available on the new Monitor ROMs (32K EEPROM new CPU boards).

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/8cee1c22-44d1-447d-8478-485738a71301n%40googlegroups.com.

[smb...@gmail.com]

I wanted to try to use it to load the HDOS boot loader for the dual CF card. There were tape and rom images, and I thought I'd read the VDIP loader would load one of those, but I see now it's for cpm sys files.

I realize the 32K ROM also has a compactflash boot loader built into it, but I'm assuming that's for the old 8255-based compactflash board? or is it for the new direct CF board?

Scott

[norberto.collado koyado.com]

I realize the 32K ROM also has a compactflash boot loader built into it, but I'm assuming that's for the old 8255-based compactflash board? or is it for the new direct CF board?

 

It is for the new direct CF board. If you have a Z80 you can boot MMS CP/M3 without any issues.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/28c03cc7-f04c-4536-8d9d-4f4409f79f17n%40googlegroups.com.

[smb...@gmail.com]

Only CP/M, or CP/M and HDOS?

Scott

[norberto.collado koyado.com]

I will need Rick help to get Heath HDOS and Heath CP/M booting on such CF card. The method that he put together is to support the Heathkit 8080A CPU board as an alternative to floppy disks. Next steps is for me to enable him to get an 8080A 32K board to update his boot-strap to work on such configuration for both OS’s.

 

For now we only have CP/M3 on the Z80 32K board working on such CF card board.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/e6611dc2-36c8-4cbc-aab6-03de01089357n%40googlegroups.com.

[Glenn Roberts]

Scott: I have written utilities to convert various executable formats to .SYS and .H8T formats but haven’t had a chance to finalize and document them and share here. For example, I have converted and run large C programs to be loadable from the H8-5 (.H8T) and that works fine. This way you can create, say, HA-8-3 video games that run without an OS! (I actually did this). 

This can be very useful. Imagine, for example, an OS-free version of TEST17. You could run it directly from the flash drive to diagnose disk drive problems.

I’ve been trying to get a more reliable way to run the H8DUtility program to create disks. What I’m learning is that there are restrictions in where you can load .SYS images. For example, I have a bootable floppy disk that boots the H89LDR server code just fine (the H17 boot ROM loads this at 2280H) but I can’t just convert that code to .SYS as it interferes with the code in Douglas’ ROM. I have to relocate it to at least 3000H and on a page boundary. That’s still a work in progress…

So we’d have to work closely with Doug to build a .SYS image that could boot, say, HDOS off the dual CF card

I’ll send you my beta code and as I get time I will polish this up and post on the GitHub site.

Sent from my iPad

On Mar 10, 2023, at 1:57 AM, norberto.collado koyado.com <norberto...@koyado.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855D3CA276B9CEFA4B43D19F7BA9%40SN6PR01MB3855.prod.exchangelabs.com.

[Douglas Miller]

Just to expand on all this, and clarify, the .SYS file format is not restricted to CP/M - it is just the origin format chosen. The files are "standalone programs" (or OS images), and as such are not restricted to any particular OS. Also note, these .SYS files may be booted from either the VDIP or the WizNET. The same format and same file may be used on either without conversion.

I have a java program for creating .SYS standalone programs. This requires the CP/M toolset (or the Linux zmac/ld80 tools) because it requires the .SPR relocatable format. However, the programs being created have no dependency on CP/M (they are "standalone" and thus have no OS dependencies). Note that this toolset supports the Software Toolworks C/80 compiler, allowing the C language to be used, in addition to RMAC/M80 assembly language. To re-iterate, using CP/M tools to build programs does not require that the resulting program be run under CP/M. I've been using the CP/M tools to build HDOS programs, as well as standalone programs.

Note that HDOS .ABS files are not required to be located (ORGed) at 2280H, but it seems that most of them are. If one does not have the source code, it becomes difficult to convert these to .SYS files (ORGed above the normal 2280H, recommended 3000H). Also, "normal" HDOS programs cannot be run standalone as they (typically) require HDOS syscalls.

As background, this originally started as a way to recover from a common problem on CP/M 3: rebuilding CPM3.SYS and finding it had a mistake and was unbootable. This way, a backup copy of a working CPM3.SYS can be used to recover, as you can boot directly into CP/M 3 using the WizNET or VDIP and then repair your broken CPM3.SYS file (disk). This scheme just also allows almost anything to be booted, opening up "standalone utilities" for test and diagnosis. We even have a "core dump" utility that - while not perfect - does give a decent dump of memory which has been handy on several occasions for debugging problems.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4441B9C8-CDB3-453A-9309-06700A3C18F2%40gmail.com.

[Douglas Miller]

Also note that there is already a standalone program that will allow you to use H8D images on the USB drive on the H17. You can create disks or save disks to H8D images. https://github.com/durgadas311/MmsCpm3/blob/master/rom/newmon/bin/vh8dutil.sys. You put this program on the you USB drive and boot it. If you are creating H17 disks, you put the H8D images you want on the USB stick as well.

On 3/10/23 04:26, Glenn Roberts wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4441B9C8-CDB3-453A-9309-06700A3C18F2%40gmail.com.

[glenn.f...@gmail.com]

So a while ago we had a discussion about how the ‘XH’ command in the new ROM wasn’t working with H8DUtility – there was a synchronization issue with the H89LDR3 code. I said I’d take a look.  Currently the ‘XH’ command simply saves you from typing in the short server program from the keypad – you still have to run H8DUtility and download the full server.  I did take a look and decided that what the ‘XH’ command should really do is simply run the full server – saves the step of downloading (which is where we are having issues).  Then you’d be able to type ‘XH’ and the H8DUtility would immediately indicate “client ready”.

 

This was not as easy as I thought it would be. I tried moving the full server code to a .SYS file (for test purposes; if it works Doug would fold the code into the ROM) but it’s ORGed at 42.200 and that conflicts with the ROM code working space, so it would have to be ORGed at more like 60.000.  It’s doable but has been a little frustrating.  So far my attempts have failed.

 

So, stepping back: all of this is really only necessary for machines that have the Z80 4.0 and new ROM but don’t have a USB interface.  If you have the VDIP device it’s much better to just run vh8dutil.sys, as Doug suggests.

 

I don’t have much of a sense for who has what but I’m going to assume for now that there are few users who need the ‘XH’/H89LDR incompatibility to be fixed right now?

 

For now I’d say just boot vh8dutil.sys as doug suggests. It’s a great way to create and archive disks and really the kind of approach we should focus on moving forward when we can.

 

Fixing this should remain somewhere on the to do list, but right now I can’t take it further…

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/8d398953-2399-6644-bd6a-c9221edd286f%40gmail.com.

[smb...@gmail.com]

Well gosh, I feel silly. I didn't realize the V2DIP1 required a dedicated programmer. I figured worst case it could be programmable via a couple serial pins, just like a gotek.

Oh well, next time I place an order with mouser...

Scott

[smb...@gmail.com]

Hmm, enough googling, and I think I did find UART instructions for programming the V2DIP1. It's verifying now! Very exciting!

Scott

[smb...@gmail.com]

Alright, V2DIP1-48 modules tested and working. Thanks again for the firmware!

Scott

[glenn.f...@gmail.com]

Long note: if you use (or think you might want to use) flash drives to read/write from your H8/H89 this may be of interest.

 

It’s been some time since we started this discussion so here’s an update:

 

Years ago we adopted the FTDI “VDIP1” USB host module as our “standard” way to read/write files from/to USB flash drives.  The VDIP1 was designed specifically to provide a USB host function for small or embedded devices (e.g. rPi, Arduino) but it is also ideal for older 8 bit computers.  I wrote a set of “Vinculum Utilities” that let us list flash drive contents, copy files back and forth and use the hierarchical directory structure of the flash drive.  The general description of my work is in this REMarks article:

REMarks Issue 6 - 14 February 2022.pdf (sebhc.github.io)

 

The software repository is on GitHub:

sebhc/vdip-utilities: Utility programs for use with the FTDI VDIP1 (github.com)

 

Norberto has built this interface into several of his recent boards including the DUART/USB daughterboard for the Rev 4 CPU board but also his H17 controller boards and perhaps others.

 

It appears that the VDIP1 module (introduced around 2007 I think?) is now at the end of life. DigiKey lists zero in stock. Octopart lists zero in stock at all “authorized distributors”. Mouser says the expect to get a dozen of them by October, but who knows. FTDI lists it as “out of stock.”

 

The point is we need a new solution.

 

The recommended progression is to the V2DIP1-48.  These are also a little hard to find but I believe that’s a supply chain/distribution issue. DigiKey currently has 73 in stock.  You can also purchase directly from FTDI. This module is based on a newer version of the processor (VNC2) and (as far as I can tell) is in production and a supported product, just a bit backlogged.

 

But the module itself has one noteworthy physical change: it uses header style square pins (not sure what you call those?) vs. machined pins, so it *wont* fit into a machined socket.  It does fit into a dual wipe socket fine.

 

There is also a minor change that somehow crept into the “VDAP” firmware that unfortunately changes the output format for the DIRectory function which “breaks” some of my Vinculum utility programs.

 

Also, while the old VDIP1 came pre-programmed with the VDAP firmware the new device does not, therefore it is necessary to program it. This is unfortunate.  you can either purchase the programmer (“VNC2 Debug Module, DigiKey part # 768-1052-ND) or use a UART interface to program the software. The UART interface requires an appropriate USB to serial interface such as the FTDI TTL-232R.

 

Terry Smedley took the time to modify the source code for the VDAP software to make it produce the same format output as the previous version and shared his ROM code (email below). The good news is that I have been able to use the UART approach to program the device using Terry’s modified firmware and all is well. The new device seems to work exactly like the VDIP1 in all the test cases I’ve tried!

 

I will expand on this writeup at some point and document this as an update to my previous REMarks article, but for now just wanted everyone to know that we are “back in business” on the VDIP/USB front.

 

In the near term if you want to get started feel free to contact me (probably off list) and I can help you get set up with a programmed V2DIP1-48 device, and if you’re building out any of the boards mentioned please make sure you use a dual wipe (not machined) 24-pin socket for the VDIP module.

 

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/bf8a4fdf-6967-427f-9ab3-4af08dd111f5n%40googlegroups.com.