New Z67-SD Controller

[Norberto Collado]

I'm planning to refresh the Z67-IDE+ Controller as some parts will be difficult to get and the Micro-Controller is getting very expensive. These days new microcontroller's are about $4.00 to support the Z67 requirements. It is going to be a smaller version as I will like to use the SD card instead, to move away from the CF cards. It just need two 40-pin IC's and the glue logic.

I will keep same format to leverage current Z67-IDE+ images.

Attached is my vision on this project for next year; hopefully!

Norby

[Terry Smedley]

Norberto:

SD cards would be nice, and kicking the DS89C430 to something cheaper also sounds good.

I'm late to the party with the Z67-IDE+ controller for the H8.   Got one built a few days ago.  I've only tried HDOS with it so far.  Everything seems to work except front panel booting from PAM-37.   If I first boot HDOS to an H37 device, I can then boot HDOS from the Z67 image using "BOOT DKx:".  And subsequent soft reboots from the Z67 device ("BYE", then return to reboot) work fine.  But a front panel boot from the Z67-IDE+ (either with the quick "PRIMARY" boot key, or by the universal DEVICE/PORT/UNIT sequence) results in a hang (no interrupts, front panel blank, reset required to recover).  I have only occasionally seen the boot image selection menu, but when it did come up, the H8 would hang as soon as I selected an image to boot.  I followed the advice to avoid multiple occurrence partitioning.

I'm using the Trionyx Z80 CPU, and the Org-0 port on that card.   The Z67 controller is the WH8-37 card, configured for Z67 on 174, Z37 on 170.  The H17 controller has been removed from the system.  I used "PREP67 174" and "PART67 174", and those programs ran to completion without error.  HDOS 2.0 INIT and SYSGEN also ran to completion without error.  Mounting a partition as a data drive works fine, and booting a Z67 image through the "BOOT" command also results in a stable system.  

I'm chewing through the possibilities, but thought I would ask if you have encountered issues with H8 PAM-37 booting before.

Terry

[Glenn Roberts]

Terry: when you boot using “universal” sequence can you tell if the Z67-IDE+ consistently reads the software boot code record (LED shows brief disk activity)?  If not then the problem might be with PAM 37?; if yes then we could look at the software boot code.  I disassembled and commented this a while back. Norberto has the listing on his site

 

http://koyado.com/Heathkit/HDOS_H67_Boot_Code_files/bootcf0b%20Listing.pdf

 

this is the first code loaded off the Z67 and it is what presents the boot image selection menu. 

 

Since you have gotten this to run at least occasionally we know that at least those times the Z67 read worked.

 

Don’t know if you can spot anything in this code that would be an issue.  Or could compare to the boot code in BOOT and/or the H37 boot to see what those do that this doesn’t?

 

Do we know that the PAM-37 is fully compatible with the board?  Trionyx apparently sold their own firmware (below).

 

I also saw that the Trionyx board implements “software control of all three Z80 interrupt modes” (which the Heath and DG boards do not do).  Could it be that the interrupt processing is somehow not being initialized properly (since you’re observing inconsistent failures)?

 

 

 

--
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/af63f091-4ed9-4313-b632-c1228ff46fa5n%40googlegroups.com.

[Terry Smedley]

Great troubleshooting ideas, Glenn. Thanks.

Yes, I can see the H8 hit the drive as soon as the boot keys are pressed on the H8.  As far as the PAM-37 goes, Tryonix provided documentation on using it with their board, and I have not previously observed any incompatibilities.  Which is not to say that the intervening decades haven't revealed some incompatibilities that weren't initially observed.

The interrupt issue you mention is certainly a possibility, as interrupts are lost when the boot process hangs.

I will look at the boot code - thanks for the reference. 

Perhaps this is a good reason to put in Norberto's latest Z80 board :-)

Terry

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/rYvPGsJBy8w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/025001d6be20%24ae6369f0%240b2a3dd0%24%40gmail.com.

[Glenn Roberts]

You could also try replacing the Heathkit boot process with the Quickstor one which uses a different boot code.  Ken Owen can probably help with any questions.  He has a lot of info on Norberto’s site though, including some images that you can burn directly to a CF card…

 

http://koyado.com/Heathkit/Z67-IDE-plus.html

 

there’s a lot of stuff there and not that well organized but Ken or Norberto can probably help you figure it out.

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CALt%2BXpM_zgirvz_%3DSZ-HN-Wf4Rh-_a5GCviVX4o750Tr56corw%40mail.gmail.com.

[terry.smedley]

Glenn

A CF adapter for my Windows computer is on its way so I will be able to try the Quickstor boot process using Ken's images.  I may not have a faithful enough emulator of H19 ANSI mode to navigate the QuickStor menus.

Terry

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004a01d6be7b%2492590250%24b70b06f0%24%40gmail.com.

[Kenneth L. Owen]

Hi Terry,

 

I have teamed with Norberto to try to give implementation support to the group members who are trying to implement the Z67-IDE and Z67-IDE+ on their Heaths.

 

I have increasingly been less active on the group over the past 10 years as my wife was not well, declining in health and needed me more that the group!  She passed away in August of this year and I am trying to get back into things that had to fall by the wayside over the past 10 years.

 

Feel free to contact me directly for your needs.  It may take me a bit to get back up to speed on things, but I will give you my best.  My email addy is: tx83...@bellsouth.net

 

• ken

 

Sent from Mail for Windows 10

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5fb69c06.1c69fb81.f9ffd.07aa%40mx.google.com.

 

[Norberto Collado]

Please try the following image and use the Windows tool to deploy it on CF#0.

 

Image: http://koyado.com/Heathkit/Z67-IDE-plus_files/H37_H67_Heath_HDOS_CPM_Drive0.zip

Tool: http://koyado.com/Heathkit/Z67-IDE-plus_files/Z67-IDE%20Windows%20Imaging%20Utility.zip

 

If booting from this image fails, then you have a corrupted PAM-37 monitor or a marginal broken CPU.

 

Make sure all the switches on the H67 are set to the “ON” position (DS1), to the right of the arrow on the switch.

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004a01d6be7b%2492590250%24b70b06f0%24%40gmail.com.

[Norberto Collado]

Also I developed the Z67-IDE+ on the Trionyx CPU using the PAM-37 monitor.

 

Norby

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CC959DD5-287D-4CE8-9A03-9F7A4B8E6E3C%40koyado.com.

[Steven Hirsch]

On 11/19/20 12:04 PM, Kenneth L. Owen wrote:

> I have increasingly been less active on the group over the past 10 years as
> my wife was not well, declining in health and needed me more that the
> group! She passed away in August of this year and I am trying to get back
> into things that had to fall by the wayside over the past 10 years.

Hi, Ken.

I'm so sorry to hear about your wife. My condolences and best wishes go out
to you!

Steve

[Terry Smedley]

Ken:

Thank you for your reply and kind offer to help.

I am very sorry to hear about your wife.  

The fine work you have already done during development of the card will resolve my issues, I'm sure.  

Terry

[Terry Smedley]

Norberto:

Thanks for confirming that there is not a fundamental compatibility problem with the Trionyx and PAM-37.  

I will have a CF writer today.  I will try the images you mentioned.

I will also have a look at the myriad of jumpers on the Trionyx card.  I have a stack of addenda describing PCB fixes and jumper settings that were changed early in the card's life as incompatibilities surfaced.  I'm looking closely at the addenda related to interrupt handling.

Terry

[Glenn Roberts]

It seems like Trionyx did this a lot.  I had a few of their memory boards and there were multiple patches applied over time.  The temptation is to remove them but they were all bug fixes or enhancements, if you can track down the documentation…

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/98ad6326-2f64-4bf4-af85-4bc2058f466an%40googlegroups.com.

[Terry Smedley]

Norberto:

Is there a hex/bin/S19 image of the PAM-37 ROM on your web somewhere?  The link to the ROM images at the github site is broken.

I loaded the H37/H67 image you suggested, and got similar results.  I can see the read request for the SBC go to the H67, but the H8 hangs right away.  Pulled both the Trionyx and WH8-37 cards, confirmed all jumpers, reseated all ICs.  All the Trionyx jumpers/switches are set to their defaults as noted in their "Standard Jumper Selections" document.  I had also made the "Extended Performance Modification No. 01", which bypassed the LS244 at U51 as recommended by Trionyx.   I had also previously made the "Extended Performance Modification No. 02" to install the WH8-37 card, and "... No. 03" to install the PAM-37 ROM at U24.  Per those instructions from Trionyx, I have SW2 1-6 OFF, and 7-8 ON.

As before, I can warm boot to the H67 image ("BOOT DK0:"), with normal startup and a stable system.

If you can point me to the PAM-37 image, I will burn a new copy and give that a try.

Thanks.

Terry

[Norberto Collado]

You can download latest PAM-37 from here: http://koyado.com/Heathkit/H8-Z80-64K-RTC-ORG0-V3_files/PAM37%20Mods.zip

Is there any information coming out of the serial port on the Z67-IDE+? 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/63efee63-dfe1-4d0e-a8c5-68223da04000n%40googlegroups.com.

[Terry Smedley]

The serial port is quiet, after displaying the "ready to transfer" message.

Terry

[Terry Smedley]

Norberto:

Thanks for the PAM-37 link.  I created a new ROM, but get the same results.  If I repeatedly reset the H8, and do a PRI H67 boot, I can see the SBC menu about 1 in 20 attempts.  Even when that boot menu displays, I have been successful at booting an image from there only once in the hundreds of times that I've tried - but that one time did result in a normal HDOS boot and stable system.  This just smells like a timing issue to me.

I think I will extract the PAM-37 "BH67" boot code and try to run it standalone, with plenty of progress prompts.  Hopefully, I'll be able to identify where it is hanging and figure out what is unique about that process compared to the warm boot code.

The PAM-37 files you linked say that an official listing for PAM-37 could not be found.  I see that's been a while ago, but I have Heath manual 595-2908, "Using the H-8 Computer with the PAM-37 Panel Monitor" that contains a complete assembly listing for PAM-37, on pages 33-147.  That's the listing I will use to duplicate the BH-67 code, because it's "Heath assembler friendly" and uses the standard XTEXT decks.

Terry

[Terry Smedley]

Norberto

Is there a "magic hidden menu option" that would display the conversation at the H67-IDE+ end of the link?  

Terry

On Thursday, November 19, 2020 at 6:26:07 PM UTC-8 Norby wrote:

[Norberto Collado]

If you leave the system hung for at least 5 minutes, do you get any other information? Just curious.

 

If not, send me the Z67-IDE+ to check it out.

 

Address: Norberto, Collado, P. O. Box 988 Hillsboro, OR 97123-0988

 

Thanks,

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/dcaafb32-83aa-4836-899d-14a06dc00e13n%40googlegroups.com.

[Norberto Collado]

Yes, type the “esc” command to enter the menu.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/308a8a61-728e-4a70-9bbe-6893ae21a588n%40googlegroups.com.

[Norberto Collado]

Any updates???

[Terry Smedley]

Norberto:

I was trying to give you a break from my issues for a day or two.  :-)  I have worked through a number of different scenarios and here is what I have found:

First, to answer your question about serial port data:  I do not see anything on the serial port after the controller boots and displays the "ready to copy" message.  My gut tells me that the Z67-IDE+ is not where the hang occurs.  I believe it has responded to the commands from the WH8-37 board and thinks that life is good.  Initiating a cold boot sequence results in a very consistent activity pattern.  The Z67 activity light flashes rapidly in succession about four times, a very brief pause, then one more single activity pulse.  With that last pulse, the H8 front panel blanks, interrupts are off.  No messages are posted on the Z67-IDE.    I believe that the first set of pulses is reading the MBR, and the last pulse is reading the SBC.'

Here's an interesting twist.  If I prep the drive with PREP67, then use the ZDS PART program, I will see the partition selection screen at boot every time.  But choosing a bootable partition from that screen results in the front panel out system hang.  But if I PREP67 followed by the customized PART67, I never see the selection screen - it's lights out as soon as that single activity pulse occurs.  I've done this experiment many times - it's very reproducible.

I read in the documentation that re-running PART67 to revise the partition layout didn't work.  I have observed that often - not always - if I attempt to re-run PART67, I'll get an error message that the superblock checksums are bad.  The partitions continue to mount and warm boot just fine.  Is this the normal behavior when re-running PART67?  I've seen that message at one time or another on all four of the Transcend 2GB CF cards I have.  But again, that's only on a re-run of PART67, and the partitions continue to operate normally.

I also read in the documentation that the Z67-IDE microcontroller serial port displayed a message that it had intercepted commands from PREP67.  I see no such message when running PREP67, but I was suspicious that perhaps that was true of some earlier version of the code but had been changed.  

I apologize for my inquiry about the menu.  I was aware of the ESC menu.  I meant to be clear in asking if there was a further debug option where I could view a trace of the commands and data going in and out to try to get a handle on where in the boot process the H8 was hanging.

I am using the Z67 controller section of the WH8-37 card.  From the postings I've read, it seems like that's not a very popular option.  Are there others that are using that card successfully with the Z67-IDE?  It sounds like most folks have used your H8-67 card either because they didn't have the WH8-37, or because they wanted to address the Z67 SASI controller at 27x.

Since the boot code for the QS partitions is at least slightly different, I was just starting to head down the path of trying to bring up a QuikStor setup to see if that behaves any differently.  Unfortunately, I don't think I can quickly use the QS images on your web site, because they have the Z67 controller at 170 or 270.  I'm trying to get an ANSI-capable emulator up and running now to start a QS system from scratch.  I may pull cards and temporarily put the H67 portion of the WH8-37 card at 170 so I can use one of the canned images.

Lastly, I will confirm that I have moved a lot of data across the Z67-IDE and have not had the slightest hiccup during reads and writes.  Cold booting is the issue I am struggling with.

Terry

[Norberto Collado]

Thanks for the update! Please check your serial board to be configured  properly. Also check your RS-232 handshaking signals as well. It seems to be stuck polling the serial port based on your description, but not sure. Have you seen on the Z67-IDE+ any watchdog timeout messages?

 

When you use the PAM-37+ image I gave you, do you see on the screen “H8 Initialized…” on power-on?

 

I will review your data tomorrow again. I can send you a modify FW for the microcontroller that will display the command and data read/written.

 

Thanks,

Norberto

Any updates???

Error! Filename not specified.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a43b13dc-9412-4803-8449-350bf688c868n%40googlegroups.com.

[Terry Smedley]

Norberto:

Yes, the modified PAM-8 displays the "H8" message on powerup/reset.  Thanks for the link to that.

The serial connection to the Z67-IDE seems to be OK.  I can ESC to the menu and see what appears to be a normal response to menu commands.  When the board is RESET, I see the status/signon screen that seems normal.  I am using the serial window in the MTK2 program.

I have never seen any watchdog messages, or any other messages, when the Z67-IDE is in operation.  Should there be some kind of message when running PREP, or when processing data normally?

Terry

[Glenn Roberts]

You say when you use the ZDS PART/PREP you get the boot selection menu every time. Thats great. When you select from that menu it will load whatever boot code was installed during the INIT process (I'm assuming HDOS). Were you able to INIT the partition and SYSGEN successfully?  Assuming you boot from a floppy on your '37 you will need the correct Z67 device driver for DK: on your boot floppy or the INIT won't install the correct HDOS boot code. 

I am the one who modified PART67. The modifications let you use 15 meg instead of 10. Also lets you specify port number as I recall? (I'm not at my system now)

I use the WH-8-37 board to talk to the IDE+ and have seen no issues.  Works fine at all CPU speeds.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7139eba7-6b55-4869-abe8-ef62ccf55c36n%40googlegroups.com.

[Glenn Roberts]

My guess is the H67 driver you used to INIT had the wrong port. There should be versions for all 4 possible ports on Norberto's site. There are also instructions there from ken on how to patch it. Look under the Z67IDE page i think (not IDE+ one)

[Terry Smedley]

Hi, Glenn

Thanks for the great suggestions, and especially for confirming that the WH8-37 card is working for you!

I have confirmed the H67 driver I am using is the one for port 174Q

And I observe that when a CF is loaded with Ken's image for H67/174 + H37/170, I get identical response there - no display of the selector screen, and no cold boot.  But I can mount it or warm boot into it (just as with the partitions that I created and formatted).

Since I can warm boot into Ken's H67 image, I created new H37 boot disks using only the software on Ken's disk.  After PREPing and PARTing from those "pure" copies of Ken's system, I still get the same result - unable to cold boot, but those partitions are mountable and can be warm booted to a stable system.

I'm attempting to create a QS HDOS system now to see how that different boot process might work.

And lastly, I'm gathering components to build a second Z67-IDE+ card.

Thanks again for your suggestions.

DId you get the information I sent you about the H8 I2C implementation?

Terry

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CACkv5mDvBgyOLL2ONR6pMuKO0KLY0zPT%3DUHV_gTeEO8Nfn1E7A%40mail.gmail.com.

[Glenn Roberts]

Hmm. Stumped for now.

I bet you get it working with the quikstor version ...

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CALt%2BXpNns36J1%3D7UN8P18Qqi7fpPm4%3D8f%3DnvzMNVzep%2B-2V%2BhA%40mail.gmail.com.

[Kenneth L. Owen]

Hi Terry,

 

I have been out of the loop for quite a while due to caring for my wife.  Since I don’t remember the image file below, I can’t give you very specific instruction, you might want to pull the Z67 card and set all switches on.  This will give you the SASIX boot menu if that image is using it.  Also, you can try the command line:        “Boot SS-0 <cr>                          If the image is using the SASIX Boot system it should boot partition 0 of the system.

 

• ken

 

Sent from Mail for Windows 10

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CALt%2BXpNns36J1%3D7UN8P18Qqi7fpPm4%3D8f%3DnvzMNVzep%2B-2V%2BhA%40mail.gmail.com.

 

[Terry Smedley]

Yes, the QuikStor configuration works fine.  I haven't checked CP/M yet, but the HDOS version works fine.  The only emulator I could lay hands on quickly that would do "good enough" ANSI for SASIX was PUTTY.  It was a little kludgy getting through SASIX, but I eventually guessed the right command keys to use.

The only thing that doesn't work (which I anticipated) was the QS-Boot menu, which apparently requires an ANSI emulation good enough to report its baudrate.  A  minor issue that I will eventually work around with better emulation.

I can say that Dean Gibson's handiwork is readily apparent here - the speed of the QS disk access is palpably faster than with the ZDS drivers.

Thanks for all of your suggestions, including the idea that the QuikStor boot code might behave differently.  At some point, I would like to uncover the root cause of the Heath configuration incompatibilities, but that can wait for another day.

Terry

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

[Norberto Collado]

If HDOS QuikStor works fine, then you were using the wrong port #. Great news.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CALt%2BXpO_XWpUXhvaoSV2-sh6910CxRyrQ-hAjh3b80ckEtyZPA%40mail.gmail.com.

[Terry Smedley]

Well, I don't think that explains why the canned image for 170/174 didn't work either!

Terry

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3481B136-0193-4FA0-BE39-1CD3E86EA84A%40koyado.com.

[Kenneth L. Owen]

Hi Terry,

 

The SASIX boot screen needs the H-19 Terminal using VT-52 mode and the Heath enhancements.  If you don’t have an H-19 Terminal, several on the group have H-19 emulators that they have developed.  I believe George Farris has one that will work with the SASIX boot system.  Contact him here in the group.

 

• Ken

 

 

Sent from Mail for Windows 10

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CALt%2BXpO_XWpUXhvaoSV2-sh6910CxRyrQ-hAjh3b80ckEtyZPA%40mail.gmail.com.

 

[Terry Smedley]

Thanks, Ken!

Terry

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5fb9c933.1c69fb81.5895a.7a12SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[Norberto Collado]

 Updates:

 

I decided to eliminate the 82C55 IC and to use some TTL IC's to do the same work. So the board is just the Micro-controller + logic to support two SD cards. I was able to complete the schematics and layout the module by leveraging the schematics from the original Z67-IDE controller.

 

The $5.00 Micro-controller supports the SPI bus and the I2C bus, so there is not need to do a bit bang to initialized the SD card or the I2C LCD board.

 

On the SD card specs, I lost previous knowledge (getting old), so I will appreciated a good pointer on how to initialized, read/write from the SD card. My plan is to load current Z67-IDE+ images and it should read/write them.

 

Still deciding to use SDCC C compiler to have a better interface. To do a quick test, I will use current code written in assembly code to get the best performance to test the HW. The only module to debug will be the SD code as everything else has been already tested. 

 

This new board should provide continuity to the previous Z67-IDE boards as some parts are expensive or hard to get for years to come.

 

Attached is a picture of the new Z67-SD board.

 

Thanks,

[Glenn Roberts]

Great work Norberto! Good to see more room around mounting holes as current design requires nylon hardware or fiber washers to prevent shorting.

https://goo.gl/photos/P8wk1j8eD14t8Efx9

Would it be possible to accommodate accessing SD card from the front? (When mounted in 3.5” drive position). With current design I must open the chassis to change out the CF card

Sent from my iPad

On Nov 24, 2020, at 4:06 AM, Norberto Collado <norberto...@koyado.com> wrote:



--

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/20201124020545.1321cca37f09b4ab87c5049afdc8ceaa.11994675f8.wbe%40email09.godaddy.com.

<New_Z67_board.pdf>

<H8-Z67-SD CONTROLLER.JPG>

[Douglas Miller]

Had a thought, and keep in mind I know nothing about this microcontroller and it's SDK. But, does the SDCard library support a partition table (e.g. MS-DOS boot sector (MBR), or more modern forms) on the SDCard? And if so, do we want to use it? This would, in theory, allow one to partition the huge SDCard into "reasonably" sized partitions for HDOS or CP/M on the host, and no longer be constrained by the 128M fixed segment size. It makes it easier to update and backup images on the card from the host PC, and provides the potential for less wasted space. Still, it's a trade-off and I'm not sure if it is worth it.

And, of course, Glenn's comment about making sure one can insert/remove the cards without disassembling the unit would be essential.

--

[Norberto Collado]

For accessing SD cards from the front, the only solution I know is to use an extension which sells at Amazon.

 

Link: https://www.amazon.com/LANMU-Extension-MicroSDHC-Monoprice-Raspberry/dp/B07WWVBK8V/ref=sr_1_2_sspa?dchild=1&keywords=micro+sd+extender&qid=1606268908&sr=8-2-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUE2MUNONzRHM0dXMDUmZW5jcnlwdGVkSWQ9QTAxOTgyMzcyQ1lHRFhMUUNPUjVKJmVuY3J5cHRlZEFkSWQ9QTA0MjA2OTdOUjdDUUszN0gzVkgmd2lkZ2V0TmFtZT1zcF9hdGYmYWN0aW9uPWNsaWNrUmVkaXJlY3QmZG9Ob3RMb2dDbGljaz10cnVl

 

If someone knows a better solution, please let us know.

 

Thanks,

Norberto

 

From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Glenn Roberts <glenn.f...@gmail.com>

Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Tuesday, November 24, 2020 at 2:46 AM
To: "se...@googlegroups.com" <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/6C1F5BDB-F46D-4BC0-99B1-3F61A3E30AA0%40gmail.com.

[Norberto Collado]

The 128MB limit is because of CP/M supporting 8MB * 15 partitions + spares MB. HDOS uses 15MB if using Glenn changes.  This allows me to divide a 4GB CF card into 128MB chunk sizes. What is a reasonably sized partition?

 

I know that the SCSI2IDE controller was tested with a Z80 using the SDCard MSDOS library and performance was very poor. With CF cards was much better.

https://www.retrobrewcomputers.org/doku.php?id=boards:other:scsi2ide:start

 

Thanks,

Norberto

 

 

From: "se...@googlegroups.com" <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Reply-To: "se...@googlegroups.com" <se...@googlegroups.com>
Date: Tuesday, November 24, 2020 at 4:20 AM
To: "se...@googlegroups.com" <se...@googlegroups.com>
Subject: Re: [sebhc] New Z67-SD Controller

 

Had a thought, and keep in mind I know nothing about this microcontroller and it's SDK. But, does the SDCard library support a partition table (e.g. MS-DOS boot sector (MBR), or more modern forms) on the SDCard? And if so, do we want to use it? This would, in theory, allow one to partition the huge SDCard into "reasonably" sized partitions for HDOS or CP/M on the host, and no longer be constrained by the 128M fixed segment size. It makes it easier to update and backup images on the card from the host PC, and provides the potential for less wasted space. Still, it's a trade-off and I'm not sure if it is worth it.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/361d028c-7e6e-b375-6069-da9d6490d6d9%40gmail.com.

[Norberto Collado]

Glenn,

 

I saw this board which shows that I need to extend the SD adapter out of the board to be access from the front. I will incorporate such change as we can do a 3D print case for it. See attached picture.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/210A260B-2E35-4B17-96A4-061727F15918%40koyado.com.

[Douglas Miller]

It may be better to just access the SDCard "raw", but I thought I'd ask. FYI, CP/M 3 does not have the 8M partition limitation, it can support a 256M drive (partition). It just seemed that getting out of the fixed-size segment might be worth exploring.

I'm not sure why the performance would be worse, seems to me that the partition table should be read only once at power-up of the Z67-IDE (or Z67-SDC as the case may be) - or rather at insertion of the SDCard if supporting hotplug, so I don't think the Z80 comes into it at all. Keep in mind, I'm suggesting that the microcontroller in the Z67-SDC use the MBR partition table, not the Z80 (CP/M). I was thinking that each MS-DOS partition on the SDCard be "exported" by the Z67-SDC as a raw disk, and CP/M / QuickStore / HDOS, whatever might sub-partition it as needed. So, instead of the fixed-size 128M "segments", the Z67-SDC just reads the MBR partition information and uses those partitions instead of the fixed segments. But, if the SDK you are using does not have library support for MBR, it wouldn't make sense. And if the microcontroller is limited in speed and/or memory, it also may not make sense.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/49F135BD-6A87-409B-BCEE-61E4DCED1514%40koyado.com.

[Glenn Roberts]

That’s exactly what I was thinking. Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/C0BD9CCD-2CC3-4586-8D72-EF956C817B71%40koyado.com.

[Norberto Collado]

The current Z67-IDE+ supports only the 128MB when using the switches to divide the CF card. If you leave the switches at “00”, then all 1GB range is available to the system. Today 256MB partitions are supported, but the user must avoid selecting such partition with the switches. So for 256MB, the user will select “00” and the next available partition will be “002” as “00”-> “01” will be used by CP/M3 OS. For this controller, I will use the 256MB range to divide the  SD card as it makes sense to redo some of the Heath CP/M-HDOS images.

 

Please send me a CP/M3 256MB image to test with the current Z67-IDE controller. I want to see it any issues.

 

I will review about the MBR to understand on how that works. Yes, we need to use raw as it is a 20MHz 8bit CPU with 1KB of RAM. It is faster than the original SASI 10MB hard drive.

 

Thanks for the feedback,

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/42dcf794-bdbb-0174-ad0d-a732775accbd%40gmail.com.

[Douglas Miller]

I was not aware that the Z67-IDE+ did not enforce the end of the segment. So, it is possible to corrupt later segments on a CF card?

I mis-quoted earlier, CP/M 3 supports drives of up to 512M each.

The MMS "master boot record" supports 8 (or maybe 9) partitions, so for CP/M 3 one could use 4+G of space on the card. I'll need to make sure my Z67-IDE+ emulation supports the above behavior, and then I can create and test a CP/M 3 image that uses more space.

It is sounding like maybe this new controller is not going to work well with MBR, even *if* the SDK contains code for it. It would make handling the "segments" on the host PC easier/safer, but it may not be practical to implement on the microcontroller. It also would not have the behavior of the old Z67-IDE+ segments, as you cannot access beyond the end of an MBR partition like you can with the segments.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/966643C6-FE10-42E3-BEBD-7226967D029B%40koyado.com.

[Glenn Roberts]

The Z67 uses the interface protocol defined in the MRX101D controller which was originally designed for Memorex 101 disk drives.  This is what Norberto has emulated in his implementation.  The interface specification is here

 

http://koyado.com/Heathkit/Z67-IDE_files/MRX101D.controller.pdf

 

It uses sectors that are 256 bytes in size.  the “Class 0” command (I/O) data structure (p. 14) allows 21 bits for sector addressing and three bits for logical unit number.  Norberto’s controller maps the logical unit number to the CF (or soon to be SD) card, so LUN 0 is card 0, LUN  1 is card 1, etc. (though this could presumably be changed via software to refer to portions of the same SD/CF card).  Each card can have 2**21 sectors which is 2,097,152 sectors or 538,870,912 bytes ( ½ Gig).  So without software changes to the IDE+ software you’re constrained to ½ G per SD/CF card.  the thumbwheel switches let you extend that space by remapping it within the card in 128 Mbyte chunks, but for any given thumbwheel setting your limited to the ½ Gig aligned to any given 128 Meg boundary specified by the switch settings.

 

If we were to partition the card into 8 logical units (rather than have the LUN refer to the physical card slot) you could support up to 4 G per card, however currently the LUN is used to select different cards. Not sure how hard it would be to redefine sector size (e.g. to 512, 1024, etc.) but that might be another option.

 

Frankly ½ Gig is so much space from an HDOS/CP/M concern I’m not sure it’s worth spending a lot of time on.

 

Now how much of the ½ Gig is usable at the OS level is a function of the drivers and BIOS definitions.  The Heath/Zenith HDOS drivers used a 2-byte sector addressing scheme (presumably more efficient than juggling 3-byte entities).  With 2 bytes you can address at most 65,536 sectors or 16 megabytes..  I believe the Quickstor and CP/M drivers are smarter and can access more.

 

Norberto implemented a special feature of his firmware that uses a control byte to access the full ½ Gig address space.  I use this in my “jukebox” software to access a whole swath of space that’s “invisible” to HDOS otherwise.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c8eaa81a-9f49-ff4d-9bb0-0de539aab325%40gmail.com.

[Douglas Miller]

right, I had neglected to consider the SASI protocol in computations of usable space. CP/M 3's 512M per drive capacity matches the SASI protocol max capacity per LUN, but not when you put a bunch of "pseudo SASI drives" onto a single storage card accessed via SASI.

The GIDE, and possible (direct) SDCard, interfaces should not have any such limitation.

Although, a 512M CP/M drive still has it's issues. Not least of which, it probably needs an 8000-entry directory which would take a long time to read on first access, let alone that that requires a huge amount of directory HASH space (32K). Also, addressing that much storage requires the use of fairly large allocation blocks, so there is more wasted space (esp. for small files).

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/004201d6c328%245c7f8ee0%24157eaca0%24%40gmail.com.

[Steven Hirsch]

On 11/24/20 9:43 PM, Douglas Miller wrote:
> It may be better to just access the SDCard "raw", but I thought I'd ask. FYI,
> CP/M 3 does not have the 8M partition limitation, it can support a 256M drive
> (partition). It just seemed that getting out of the fixed-size segment might
> be worth exploring.

CP/M 2 with ZSDOS (and other BDOS replacements) can also handle very large
partitions. Limit is 512MB, I believe.

[Norberto Collado]

The original FW of the Z67-IDE was using 512MB for Drive 0 and drive 1 which gave best performance. There was a pushback to use the whole CF card and to use 512 bytes per sector to use all available storage space. That is when I added the BCD switches to define 128MB partitions and decided to use 512 bytes per sector, so two 256 bytes sectors are combined into one 512 byte sector. 

Should I go back to the original Z67-IDE code that supports only 512MB for drive? This will eliminate the need for the switches and allow to create a single partition from 8MB up to 512MB. You can only do a single partition per drive for CP/M and HDOS the same as when using a Winchester hard drive.

Thanks,

Norberto

It may be better to just access the SDCard "raw", but I thought I'd ask. FYI, CP/M 3 does not have the 8M partition limitation, it can support a 256M drive (partition). It just seemed that getting out of the fixed-size segment might be worth exploring.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/90eef9c6-a44f-43a7-8fad-4c03c058617d%40gmail.com.

[Kenneth L. Owen]

Hi Norberto,

 

The Z67-IDE (and IDE+) use the switches for multisystem boots.  Unless there is a problem with the root data, if a system fails to boot, you can select another one which will boot and now have a way to recover the one that quit working.

 

• Ken

 

Sent from Mail for Windows 10

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20201125100411.1321cca37f09b4ab87c5049afdc8ceaa.37964701c5.wbe%40email09.godaddy.com.