To send mail to me, use the feedback form.
( - latest - )
Sent: (via email) Sun, 24 May 2020 10:50:31
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:
And in the Variations Service:
(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.
status : work pending
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.
Sent: (via email) Sun, 24 May 2020 10:44:58
> 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 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.
status : work pending
My second guess is that you used a variation with “-fullscreen 1’ to start in fullscreen mode. This has a known problem where it does not automatically magnify. It is on the list of things to fix, a bit down in the stack.
That is still not a standard variation. 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. So there can be no difference in behavior.
Sent: (via email) Sat, 23 May 2020 13:58:52
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
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.
Sent: (via email) Sat, 23 May 2020 13:42:09
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?
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.
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:
It sounds like the charge should disappear within a few days (not including weekends).
Sent: Thu May 14 17:42:04 2020
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.
Sent: Tue May 12 17:23:07 2020
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.
Sent: (via email) Fri, 8 May 2020 14:10:05
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!
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.
Sent: (via email) Tue, 5 May 2020 10:22:26
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.
status : received
Sent: (via email) Mon, 27 Apr 2020 09:56:14
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?
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.