#253 CMD HD support

[Roberto Muscedere]

Attached is a patch for r38916 to add in CMD HD support.
To facilitate the configuration and installation modes, changes were made to the GUIs (GTK3 and SDL) to add in menu options. Also added stuff for rom names, drive type selection, etc.
I also added in "DHD" image support to identify and attach the disks.
DOCs are updated too with info on DHD format and a little blurb on the different HD modes.

[gpz]

This patch looks really complete and is mostly ready to merge, well done :) Some (really) minor nitpicking ahead:

• at some places spaces are missing, eg before line continuation character (\)

• this should not be in the implementation, rather get this value from the standard header files (stdint.h):

#define UINT32_MAX             (4294967295U)

• should cmdhd_init really be called in iec_drive_init? it looks like that function initializes certain chip cores, but not entire drives? similar question for cmdhd_setup_context in iec_drive_mem_init and cmdhd_shutdown in iec_drive_shutdown. I am really just wondering here - i cant say if this is correct or not because i dont know this part of the code well enough. (Perhaps someone else can chime in)

• I have briefly checked the UI additions, which look fine to me. Compyx should probably comment on them too.

My major gripe with this patch is the introduction of a new image format for CMD HD - it seems a bit arbitrary and unnecessary to me (we do not have image formats for SD Cards or IDE64 etc either). IMHO we should only add "fixed size" images, or image formats that can be safely identified by their respective headers - not some arbitrary random sized "raw" images. Is there really a requirement for adding it? If not, i'd rather see it removed.

That said, i think we are at the point of considering to just give you svn access. Once you have that you should commit this stuff in smaller portions like this, always keeping the code compiling (that allows easier searching incase something broke):

• additions/fixes to "core" directory, one by one
• additions to common code, and the new cmd hd emulation
• GTK UI updates
• SDL UI updates

[Roberto Muscedere]

Okay. I've made the changes. The "autodetect" code now looks for the CMDHD signature. Added in the IO dump for the monitor too.

[Al DeRosa]

Hi Roberto, is there any docs on how to use it? I have tried attached a Bootrom I have CMD HD BOOTROM v280.bin and am trying to create a image via the create image option but am getting failure messages.. Any info??

[Roberto Muscedere]

I can't share the boot roms or install files as there is active ownership over the jiffy dos code.

[Al DeRosa]

I'm not looking for the boot roms I have that, just looking for an idea how to create the HD itself?

[Roberto Muscedere]

You need the CMD HD tools v1.92. Attach it as drive 9, create an empty file (DHD) and attach it to drive 8 as a drivetype 4844. Run the "create sys" program; the drive will automatically be put in installation mode. Later you can go to configuration mode by left-clicking on the on the status bar.

[Al DeRosa]

Excellent, thank you... :)

[Bob Reid]

How are you creating the empty DHD file? I have a DHD image which I had made years ago from my CMD HD drive (something became corrupted, but DirMaster is able to access the partitions and data, so the corruption only prevented booting up. Anyway, mounting the 4GB DHD image doesn't work. Since this is just a backup copy, I planned to just format and start it fresh. However running Create Sys produces an error "Write Error 13". I've tried switching to both install and config modes. One gives the same error and the other simply hangs. I also created a blank DHD file using fsutil (windows) but still get the same error.

Also, while I'm sure this is a small think to note, trying to run LLFormat, you don't see any LU unit detected to select. While doing a Low Level format in Vice is probably silly to do, but since it can't detect an LU, this might be a cause of other issues for support and just wanted to point it out.

[Roberto Muscedere]

Well it seems there is a limitation with the image detection code. I was told it only checked the images for smart attach but it seems it is doing it regardless. Now it seems it will only attach to files that have a DOS installed on them. I will discuss with the other team members on an acceptable solution to this. The concern about attaching to "any size" file with what ever is in it can cause other issues later on.
Hopefully once this is resolved, you should be able to just run "rewrite dos" to fix you old HD image issue.

[Roberto Muscedere]

You can now mount empty (0 bytes) images as long as you have the CMDHD boot rom loaded.
Fixed in r38943.

[Querino]

cool, seems to work now, at least i could mount the empty image, create a partition and format it using llformat.

i haven't done any further testing... my knowledge here is zero.
i need to play with this new toy first. :)

[Querino]

i ran into the same problem, it seems VICE does not attach "unknown" images.

[Mark Newsom]

The .DHD image must have the CMD HD DOS written to it already so, WinVice will attach the correct file. But, I am having problems with running a BBS with the newest nightly build and TCPSER if anyone can explain how to get it to accept the init string of any BBS and answer that would be great.

[Jay Campey]

With TCPser, it's a good idea to run your init string at the command line level before ever launching the BBS. Also know that ATZ is ignored in TCPser. If you make any AT calls in your BBS that are contrary to the init string, you need to remember to set those back manually.
(It also greatly depends on whether or not you're running ACIA or userport)

[Jay Campey]

So, I'm noticing the RTC save feature is grayed out for CMD-HD. Is that by design or is this handled some different way than the FD2k/4k series?
I did notice that I can switch to a different drive type that has RTC and back again, and the checkbox opens up to be able to select it.

[Bob Reid]

Is there an option to swap partitions? Like you can using the front panel buttons? I know this is probably rarely used. But I have used it a few times in the past (2 disk-side cracked games that would load fine off the CMD, but needed this to swap partitions). If not, certainly not a major loss but would be nice to have. I think write-protect can already be done in the Vice drive config menu.

[Mark Newsom]

Still seems like CBase does not want to play nice with TCPSER... I tried all the tricks and when CBase throws that init to TCPSER it says that it seems that the peer closed TCPSER. I have no idea why it is doing this.

[Al DeRosa]

Are you using the latest Vice? 38959? If so I am having issues also, it's not the CMD emulation as it works fine in 38928... Mine throws a RS232Net: error 32.. I have Jim Brain working on seeing if it is tcpser or not... I have it running fine in Windows with the latest Tcpser. on 38928...

[Mark Newsom]

I am on r38945 and having issues.

[Mark Newsom]

Now we have CMD RAMLink Emulated and we still do not know how to use it!

[Roberto Muscedere]

From command line:

x64sc -cartramlink ramlink.bin -ramlinksize 4 -ramlink

You can change the 4 from 0 to 16 for the number of MiB you want on the internal ramcard. RAMLink will be device 16. You can also add all this via the resources file.

[Mark Newsom]

Does the RAMLink need the RAM DOS? I did what you said and still nothing. And where is the resources file at?

[Roberto Muscedere]

The ramlink.bin (attached in previous message) is the RAMDOS.
As for the resources file, read the vice.pdf file. It explains it all and where it is depending on your platform.

[Querino]

thanks Roberto

a nice addition to VICE again!

also your ramlink.bin does work, unlike one i got from the net.