www.gryphel.com/c/mail/v12 - feedback

Gryphel Project Mail

Volume 12


To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Mon Oct 19 05:55:43 2020

i have been having issues getting the ua608d utility to unarchive the system 6 os files using command prompt on windows 10

i keep getting

usage: unar archive_file dst_file

as a response or nothing at all

so i am pretty sure i am mostly trying to use it correctly but missing something small in the syntaxing

after using cd to navigate to the folder i am using i have tried just running the command supplied './ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"'

but that errors as '.' is not a recognized internal/external command program or batch file

running 'ua608d.exe ./ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"' gets me my error

and using 'start ua608d.exe ./ua608d SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"'

to run the executable just runs it for an instant before it quits

and follow up or advice to correct this probably user error would be appreciated

if it would be easier to email me feel free to on [... email address ...]


status : received, definitive reply pending

I’ll need to try it on a Windows machine to be sure, but I’d suggest:

ua608d.exe SSW_6.0.8-1.4MB_Disk1of2.sea.bin "System Startup"

That is, get rid of the extra “./ua608d”.

In a unix style shell, “./ua608d“ will run an executable file named “ua608d“ located in the current directory. Just saying “ua608d“ will not find it in the current directory, it will instead look for it only in previously defined paths. If I remember correctly, this is to prevent unpleasantness if some joker has made an executable named such as “ls”. Apparently though, in the Windows shell it will look in the current directory.


permanent link

Sent: Sun Oct 18 18:22:50 2020

Paul,

I have a small request for the next version of Mini vMac. I know the "v" icon that shows on the desktop for non-800k disks reflects the fact that you basically replaced the floppy driver with a custom virtual device that reads any size of disk image. While I would absolutely love it if Mini vMac eventually emulated a real hard drive I understand that it's not currently and might never be on your road map.

That's all great but I don't really want or need to be reminded that the underlying devices are non-authentic. So, if was hoping that you might introduce a new compile option--that would be entirely cosmetic--that would cause 1440kb (for HD floppy disks) to show the standard floppy disk icon and images of all other sizes to show the hard disk icon?

Thanks for considering my request.


status : possible feature pending

That would be a reasonable run time preference. One complication I remember from the last time a similar request came up is that there does not seem to be a standard hard disk icon to be found in the System or Finder files, I suspect that various driver software just provided their own icon.


permanent link

Sent: Sat Oct 17 00:45:24 2020

Hi, tried running Mini vMac but keep getting a "unable to locate ROM image error"


status : responded

Please see the Getting Started with Mini vMac instructions.

The relevant sentence is:

To get past this, drag the icon of your ROM image file, “vMac.ROM”, onto the Mini vMac window.


permanent link

Sent: Sun Oct 4 09:30:41 2020

Hi Paul... I've been having a bit of trouble getting Mini vMac to auto load (find) my rom and dsk images on my Mac. It works fine on my PC, but I can't seem to get it to work with the same setup and files on the Mac. I started a post about it on the emaculation forums, but wasn't sure if you still stop by there. If you can offer any advice I appreciate it.


status : responded

Most likely this is because of “Path Randomization” misfeature added in macOS Sierra (10.12). See OS X notes for Mini vMac.


permanent link

Sent: (via email) Sun, 27 Sep 2020 13:50:13

Paul Pratt,

Okay I see,

Yes, I moved CopyRoms into the applications folder and it gave me back a 1.00 MB (1,048,576 bytes) file - success.

Sadly vMac says the checksum failed.

Here is the checksum on the new ROM file:

E:\Virtual Machines\minivmac-36.04-wx64.bin>C:\tools\sysinternals\sigcheck.exe 
-h PB165.ROM

Sigcheck v2.73 - File version and signature viewer
Copyright (C) 2004-2019 Mark Russinovich
Sysinternals - www.sysinternals.com

E:\Virtual Machines\minivmac-36.04-wx64.bin\PB165.ROM:
        Verified:       Unsigned
        File date:      1:49 AM 2/6/2040
        Publisher:      n/a
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    A495708975AEF7E23E78358547DE5F23
        SHA1:   C0510682AE6D973652D7E17F3C3B27629C47AFAC
        PESHA1: C0510682AE6D973652D7E17F3C3B27629C47AFAC
        PE256:  D43EB16CE4719D96C45BE61737B497918C4EBE27640A7AAFA058B7706971BD1C
        SHA256: D43EB16CE4719D96C45BE61737B497918C4EBE27640A7AAFA058B7706971BD1C
        IMP:    n/a

I appreciate it. I look forward to hearing back.

[... name ...]


[previous message]

status : responded

Checking the md5 against the 680x0 Macintosh List indicates you have successfully acquired the PowerBook 165 ROM image.

However, this ROM image will not work in the Macintosh Plus emulation of Mini vMac. Renaming it to “vMac.ROM” will not help.

Unfortunately, Mini vMac can not emulate a PowerBook 165 (or PowerBook 165c). To make this clearer, I have edited the 680x0 Macintosh List to put the “Supported by Mini vMac” line at the beginning of each entry, and to add an explicit “Supported by Mini vMac: no”, instead of just omitting this line.


permanent link

Sent: (via email) Fri, 25 Sep 2020 00:36:04

To whom it may concern,

Great little program. I just started learning how to make floppy disk images. I am a forensics student at [... school ...]. It would be great to see how software is made for these [...] operating systems.
I wanted to get the ROM off of a Powerbook 165C. It didn't create a file called "Unknown.ROM". It did create a 0 byte file called PB165.ROM. It wasn't crazy at least, yet as I understand it if the hash isn't in the list it isn't supported.
I'll provide the hashes from sysinternals/sigcheck.exe.
I am not sure these are necessary on a 0 byte file. If I can help any other way let me know.

c:\users\[...]\desktop\PB165.ROM:
        Verified:       Unsigned
        File date:      12:06 AM 9/25/2020
        Publisher:      n/a
        Company:        n/a
        Description:    n/a
        Product:        n/a
        Prod version:   n/a
        File version:   n/a
        MachineType:    n/a
        MD5:    D41D8CD98F00B204E9800998ECF8427E
        SHA1:   DA39A3EE5E6B4B0D3255BFEF95601890AFD80709
        PESHA1: n/a
        PE256:  n/a
        SHA256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
        IMP:    n/a

Thank you.
Signed.
[... name ...]


status : added to documentation

The most likely reason CopyRoms failed is that there wasn’t enough free disk space. 1 megabyte (= 1024K) is needed for the PowerBook 165c ROM.

An excuse for why CopyRoms doesn't display an error dialog is that it is designed to work without a keyboard, mouse, or even screen.

It could be changed to create a file containing a useful error message. But running out of disk space is about the only error that could occur where an error file might be successfully written. And then looking for that error message would need to be documented. It might be simpler to just document that a zero length file means not enough disk space.

So I have done that, adding a paragraph to the CopyRoms documentation.

update - follow-up message


permanent link

Sent: (via email) Mon, 21 Sep 2020 23:17:38

Hi,
I'm not sure how much you check Twitter, so I'm emailing you too. After some time debugging, I found out why Winter Games doesn't work in Mini vMac (and fixed it):

Wintergames modifies the VBL queue directly, inserting its own task at the head instead of calling VInstall, but it doesn't account for the possibility of the queue being empty, since on a real Mac the queue would have the task installed by the .Sony driver to track the disk speed (I think that's what it does, it's DT81 under P_Sony_FigTrkSpd in the Mac Plus ROM disassembly).

I fixed it in the replacement .Sony driver, by adding a task that does nothing to the queue, similar to how the time task is already added.

You can find my fix here, I'd be glad for it to be included in a future version of Mini vMac:
https://github.com/zydeco/minivmac/commit/53c291ac120a036131a73cb2e568b57c493f51d7


status : patch merged

Thanks! That’s impressive debugging. The patch is now merged into my development version.

I’ve made a few changes. Moving the VInstall block before the conditional branch instead of after allows it to work in Macintosh 128K emulation. Putting the record for the VBL task into the SonyVars structure instead of calling NewPtr may help minimize differences from previous versions. Changing the VBLTaskFreq to once a minute (instead of the maximum of about 9 minutes) may make it easier to notice if this task is having any unexpected effect.


:

Older Mail (Index)


www.gryphel.com/c/mail/v12 - feedback
copyright (c) 2020 Paul C. Pratt