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

Gryphel Project Mail

Volume 11


To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Thu May 28 07:12:36 2020

Hi Paul,

when I copy the parameters from minivMac (ctrl-P) and paste them into the variations service in Safari (in my case: -br 37 -t mc64 -lang ger -magnify 1 -speed z -mem 2.5M), I the service responds with "Sorry, the Base Options need to consist of letters, numbers, spaces, hyphens, or asterisks, and be 1024 characters or less. Please press the back button on your browser and correct this."

What am I doing wrong?

Thank you.

Kind regards, Karl


status : fixed

Thanks for the bug report. I forgot that a period (as in “2.5M"”) needs to be allowed. This should be fixed now.


permanent link

Sent: (via email) Tue, 26 May 2020 10:28:19

Hi Paul,

> The first line of the Download section, after the title,
> has a link to other branches. I guess that is too easy to miss?

Oh, "other branches" in the context of open-source usually means versions of the software developed by other people, that differ from the trunk (main branch).

A newer or older version of the same software isn't usually a branch as such, but versioning.

This is likely why I didn't pay attention to that link.

> The main page of the Gryphel Project has a news section which regulary
> links to "the latest Development source snapshot". Or maybe you are
> talking about the Mini vMac main page. I could add a Branches link
> next to the Changes link. That really should be there, it is mistake
> that it is missing.

By the site's index page, I meant the Mini vMac homepage.

> I'm not sure about putting a link to Branches in the Variations
> Service page, that page I really want to keep as simple as possible.
> Perhaps in the directions page.

I think a clearer link in the Downloads section to the current in-development version of the software is completely sufficient. If anyone's looking to download a newer version of the software, Downloads is where they will first be looking for it.

Cheers,
Bryan


status : responded

Mini vMac 36.01, Mini vMac 36.02, Mini vMac 36.03, and Mini vMac 36.04, are versions. All together, Mini vMac 36 is a branch. The Branching (version control) article on Wikipedia is consistent with this usage, particularly the section on “Development branch”. The common concept with how you are thinking of the term is that there can be new versions of different branches of Mini vMac at the same time. Because there could be a bug fix to the Beta or even Stable branches as the Alpha branch is being developed.

I have tried to clarify this usage on the Download page, by explicitly saying “alpha, beta, and old” branches, instead of just “other” branches.


permanent link

Sent: (via email) Sun, 24 May 2020 10:50:31

Hi Paul,

Thanks. I'll give it a whirl in the coming days.

> Where did you look for it? I could consider putting links there.

I was looking for it in the "Download" section:
https://www.gryphel.com/c/minivmac/download.html

And in the Variations Service:
https://www.gryphel.com/c/minivmac/var_serv.html

(The pages I've used and am familiar with from before.)

I've also checked the site's index page for anything that may signal a new build.

Cheers,
Bryan


[previous message]

status : change made in documentation

The first line of the Download section, after the title, has a link to other branches. I guess that is too easy to miss?

The main page of the Gryphel Project has a news section which regulary links to “the latest Development source snapshot”. Or maybe you are talking about the Mini vMac main page. I could add a Branches link next to the Changes link. That really should be there, it is mistake that it is missing.

I’m not sure about putting a link to Branches in the Variations Service page, that page I really want to keep as simple as possible. Perhaps in the directions page.

update 5/25/2020 - I have put in a link to the Branches page page from the Mini vMac main page and from the Variations Service Directions page.

update 5/27/2020 - I have merged the stable and alpha Variations Services into a single set of pages, which have a pop up menu to choose the branch compiled. This new Variations Service should make it easier to find where to make alpha variations. And also it is easier for me to maintain.


permanent link

Sent: (via email) Sun, 24 May 2020 10:44:58

Hi Paul,

> Do you mean that it would not go full-screen by default, or
> that the toggle command (Control-F) was not there? The
> default variation very deliberately does not start full
> screen, to avoid getting beginning users into a situation
> they can’t easily get out of.

Both the default build and the variations service default build started with fullscreen off, but when using CTRL + F to switch to fullscreen mode, the default configuration would use the 2x setting, while the variations build would have the 2x setting disabled by default -- therefore creating an inconsistency in relation to user expectations (expecting the standard build's settings to be the default).

> In your previous message you
> mentioned using "-br 36 -t lx64 -fullscreen 1 -magnify 1
> -drives 16 -bg 1 -as 0 -svl 5". So my guess is that you
> forgot this is not the standard variation.

This is after I've figured out how to replicate the settings/behaviour of the standard build in the variations service, and customised them to fit my needs.

> To avoid this sort of situation, I’m thinking I could change
> the Basic Variations Service to allow and strongly encourage
> entering the options from an existing configuration (using
> Control-P), as in the current Text Based Variations Service.
> And then, by adding a text field at the bottom for
> additional options, a separate Text Based page becomes
> unnecessary.

This a good idea, so long as the HTML form recognises the values entered through the text input and checks/fills out those settings in the form. As the user ticks/changes new settingsin the form, the changes should be reflected in the text options (real-time).

Having just the text options makes it difficult to further customise the emulator, seeing as one needs to know what the text equivalent of those form options are.

I wasn't going to suggest going this far, but it *would* make the variations service a lot more useful -- even if it does involve quite a bit of additional JavaScript development for the web interface/service.

I still think keeping the default settings for the standard build and the variations build the same is the most important aspect of making the variations service more user-friendly.

I can deal with having to manually re-assign the same values again from memory (and using the text options as reference) in the web form.

Cheers,
Bryan


[previous message]

status : work pending

The reported behavior, no automatic magnify when first using CTRL + F, would be a new bug. But I can’t reproduce it. Could you give details of what variation you observed it in (i.e. the options string, and the md5 checksum of the downloaded archive)?

There is however a known similar bug, where a variation built with “-fullscreen 1” to start in fullscreen mode does not automatically magnify. It is on the list of things to fix, a bit down in the stack. Are you certain the variation you were using was not built with the “-fullscreen 1” option?

It really should not be possible for a Standard Variation to behave differently from the corresponding one generated by the Variations Service with a target platform and no other options, because they are bit by bit identical. You can test this. If you download “minivmac-36.04-lx64.bin.tgz” from the 36.04 (Stable) Standard Variations page, and then create a sponsored variation from Mini vMac 36 Variations Service (Basic), choosing only “Linux - x86-64” and no other options, you will get identical binaries, with an md5 checksum of 499827d3defee725c1decddc4497e637.

I have made the intended modification to the Alpha Variations Service. Using JavaScript is very definitely not my intention.


permanent link

Sent: (via email) Sat, 23 May 2020 13:58:52

Hi Paul,

Regarding the variations service, what made it more difficult to adopt primarily was the inconsistency in behaviour between the latest standard build I first tried, and the latest variations build by default.

As a user, what I expected is that the variations service will build the standard configuration without my customising/modifying anything. But instead I got a build where Mini vMac did not go full-screen and double-sized as in the standard build. I had to hunt down and figure out why my variations build wasn't behaving as the default build out-of-the-box.

So this inconsistency is what really threw me off and caused some confusion and difficulty grasping how the variations service works. That, and the fact that there are a lot of customising options in the advanced variations service, and too few in the default one. Thankfully your good documentation and resource links on the option titles helped me relatively quickly figure it out.

To make it more user-friendly, the variations service should follow the standard build configuration, with extra options to change things to the user's needs/liking, starting with the most common/obvious changes, and going into finer details down the line.

This way it feels less like building, and more like customising -- and requires less (potentially unnecessary) effort to learn.

Hope this user insight helps.

Kind Regards, Bryan


[previous message]

status : change made in Alpha

Thanks for the feedback. It is helpful.

The variation service should in fact “build the standard configuration without my customising/modifying anything ”. Anything else would be a bug.

Do you mean that it would not go full-screen by default, or that the toggle command (Control-F) was not there? The default variation very deliberately does not start full screen, to avoid getting beginning users into a situation they can’t easily get out of. In your previous message you mentioned using “-br 36 -t lx64 -fullscreen 1 -magnify 1 -drives 16 -bg 1 -as 0 -svl 5”. So my guess is that you forgot this is not the standard variation.

To avoid this sort of situation, I’m thinking I could change the Basic Variations Service to allow and strongly encourage entering the options from an existing configuration (using Control-P), as in the current Text Based Variations Service. And then, by adding a text field at the bottom for additional options, a separate Text Based page becomes unnecessary.

update 5/23/2020 - I have made this modification to the Alpha Variations Service. Except on second thought, I think the Text Based page for specifying additional options should remain separate.


permanent link

Sent: (via email) Sat, 23 May 2020 13:42:09

Hi Paul,

How do I get the updated build? I can't seem to find it on the website. Would I need to build it from source myself?

Thanks, Bryan


[previous message]

status : responded

It is available from the Download Mini vMac 37 Alpha page.

That page has a link to the Mini vMac 37 Alpha Variations Service page. (While Mini vMac 37 is in Alpha, and therefore frequently changing, the set of compiled standard variations is not provided.)

Where did you look for it? I could consider putting links there.


permanent link

Sent: Thu May 14 23:23:39 2020

Hello, I donated 10 dollars via a Debit card. It said the card was declined but when I looked on my account, the payment said I only had 3 dollars left (I originally had 13 dollars). I can still get the code right? Or can I get a refund? Thanks!

Email me back at [... email address ...]


status : responded

Thank you for trying to donate, and sorry for this problem. Searching on Google, I found:

https://www.freetaxusa.com/help/display_faq.jsp?order-declined-checked-bank-credit-card-issuer-charged-declined-orders&faq_id=1710

https://help.leaguesafe.com/hc/en-us/articles/215189143-My-credit-card-was-declined-but-I-m-still-showing-a-pending-charge-

https://www.simplex.com/kb/my-payment-has-been-declined-but-i-have-been-charged-why/

https://old.reddit.com/r/personalfinance/comments/7g4u1h/debit_card_declined_3_times_on_website_but_still/

It sounds like the charge should disappear within a few days (not including weekends).


permanent link

Sent: Thu May 14 17:42:04 2020

Hi.

I think a style guide would be very helpful.

Something that goes over your naming conventions and typedefs and why you used them.

Another thing might be including a file called OSGLUskeleton.

It would only contain what the emulator core needs and stubs for things that the porter would need to emulate.

It's not strictly necessary though; I pulled the 3DS version together from the SDL and XWIN versions.


status : work pending

The problem with a skeleton port is that since it is not used, it tends to rot. Mini vMac actually had such a port, "gen", from version 2.8.0 until version 3.2.0. After that the classic Macintosh port, "mac", was designated as the "reference" implementation, containing all comments about what platform dependent code is supposed to do, not repeated for each platform. That port was chosen to be neutral to the modern supported platforms. But at the current time, make the SDL port the "reference" implementation would be more practical. Because the easiest way to port Mini vMac to a new platform is to port it to SDL on that platform. Then if a more native port is desired, the source code for SDL can be merged with Mini vMac, all SDL code not used for that platform can be removed, and then a lot of cleaning up. I did the Cocoa port this way, without ever having used Cocoa or Objective C before.

One issue with this idea is that there are two SDL ports, for SDL 2.0 and SDL 1.2, and they are both still useful. I could merge the ports, even though there are significant differences (by testing whether SDL_MAJOR_VERSION is 1 or 2). And then put all comments about porting into it.

I could go further and say that if SDL_MAJOR_VERSION is defined to 0, then the SDL API is not used at all, and that would be the skeleton port again, useful when SDL does not exist for a platform.

Clearly, I should create a page that documents porting. People are otherwise may not have noticed that "mac" was supposed to be the reference platform.

For a style guide, I could start by a least documenting what rules are being enforced automatically by scripts of mine. I don’t require that code follow these rules before I would merge it into my version of Mini vMac. But I will rewrite the code to make it follow these rules. I don’t mind this rewriting, it helps me learn how the code works. I won’t merge code without feeling I understand it pretty well.

update 5/21/2020 - The source code for the SDL 1.2 and SDL 2.0 ports are now merged into one file, and it has been made the reference implementation, with comments that apply to all ports. The SDL port has been further modified so that if it is compiled without including the SDL headers, it will not use SDL, only standard C libraries, making a skeleton port.


permanent link

Sent: Tue May 12 17:23:07 2020

Hi.

The new repo for the 3DS port is at: https://github.com/TaraHoleInIt/minivmac-3ds

It also contains my hacky changes to the setup tool, but I still need to figure out how to generate a Makefile that devkitPro likes.

For the time being I've been doing the Makefiles manually.

Thank you again for Mini vMac. It's been a real treat to port, and I have learned a lot from it :)


status : responded

Thanks, I have updated the Ports page, and added an item to the Latest news section.

I would be interested if you have any suggestions for making Mini vMac easier to port.


permanent link

Sent: (via email) Fri, 8 May 2020 14:10:05

Hey Paul,

I'm working on an ARG and was wondering what the best way to package up a version with preinstalled files and folders would be?

files would be clues and image files related to the ARG.

Love your work! thank you so much!

-- *-Keith*


status : responded

Sorry, I’m not sure what ARG means in this context.

Generally, I now try to discourage people from downloading Mini vMac from anywhere but gryphel.com. Malware masquerading as Mini vMac has happened before. Also legitimate copies elsewhere would tend not to get updated, and become old.

And of course, including ROM images and system software violates copyright law.


permanent link

Sent: (via email) Tue, 5 May 2020 10:22:26

Hi Paul,

Sorry, personal troubles got in the way of my response. I will test the new build (and interface) and answer your letters soon. Thank you for looking into this, and (from what I understand) this solution sounds right. One of the main reasons people would be emulating the old System these days is precisely because of HyperCard. If this solution doesn't work out in the wider sense, it would be worthwhile considering creating a build specifically for HyperCard.

HyperCard may have been abandoned -- due to a now obsolete personal feud between Steve Jobs and Bill Atkinson -- but it is still the best multimedia/hypermedia concept testing software, still relevant to-date! And in many ways it still outshines what the Internet can do these days in terms of creative possibilities. Not to mention its historical-cultural significance.

Apple lost an unparallelled creative tool when they left HyperCard behind in the transition to OS X. They've been trying to recreate its success, without getting even close, ever since.

Kind Regards,
Bryan


[previous message]

status : received


permanent link

Sent: (via email) Mon, 27 Apr 2020 09:56:14

Hello Paul,

I am tinkering with Alpha 37 here-specifically the Mac II. I saw some notes about supporting greater than 4MB of RAM running in to ROM addressing problems. I notice that virtual memory isn’t an option in System 7.

For the Mac II would it be possible to emulate real memory as virtual memory? Increasing the usable memory well above the ROM and physical limits?

I don’t have the technical information on System 7 or the Mac II but I gather that the Mac II had a MMU coprocessor to handle memory and System 7’s virtual memory was actually a copy of main memory + the extra memory. This made it pretty awful when writing to a disk but if it was implemented to RAM behind the scenes it might work great?

https://retrocomputing.stackexchange.com/questions/2804/why-did-mac-os-7-perform-poorly-with-virtual-memory-enabled

Dean


status : responded

The Macintosh II emulation is currently limited to 8MB because the ROM isn’t 32 bit clean. It could easily emulate more memory, but the software would not work.

If Mini vMac had a working PMMU implementation, you could just use MODE32. It is possible that MODE32 might be gotten to work with a partial PMMU emulation, that it might only require supporting switching between a few simple memory mappings. While getting virtual memory to work would make much more extensive use of the PMMU.


:
:
:

For earlier mail, see the mail index.

:
:
:


www.gryphel.com/c/mail/v11 - feedback
copyright (c) 2019 Paul C. Pratt