Jump to content

Toni_

6502
  • Content Count

    34
  • Joined

  • Last visited

2 Followers

Profile Information

  • Location
    Finland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi again! Today we managed to get a really cool feature functional - We can now run After Dark (and in future theoretically any *compatible* extensions/control panels) in our emulator https://mace.software/2019/04/08/experimenting-with-init-cdev-support/ I've written a blog post about this feature above, and there's also screenshots (and video!), in which we run After Dark (using default "Starry Night" as modules cannot yet be configured) loaded "inside" MacPaint application. I'm guessing (but not sure, as I haven't had time to verify this assumption) that the original versions of HyperCard didn't actually have any speed throttle, but it was probably added in later versions of HyperCard - A lot of the early software seems to have this same issue. Considering that HyperCard 1.x was developed in 1987, the same year as Mac II was launched, I thinks this the be highly probably. However, we will check this hypothesis when we someday get the Styled TextEdit to work and can start to work on adding HyperCard 2.x support
  2. Hi, In the cards we tested, there appear to be at least two transition types that I've seen. Other more common one is the "zoom rectangles" transition (such as seen on a real Macs' Finder when opening folders/apps), and other one is "card appearing in growing box from center" transition (which appears at least when entering the "Phone" card). I hope those explanations make any sense to describe how they look like There may be others too, but we need to add more stacks to test them at some point. One important note we found out was that the transitions don't appear to have a speed throttle, so they're running too fast at least in HyperCard 1.0.1 we're testing. In the debug version with full logging the emulation slows down enough to allow transitions to be visible, but in release mode with no debug logging they're basically instant. I've checked that at least on Minivmac the speedup appears to follow same pattern. I'm myself not that familiar with HyperCard, but Pukka has been using it a lot in the past, so when we get bugs fixed he can probably try the features of HyperCard better and comment on their status. (He pointed out that currently user mode changing through entering commands is blocked by unfinished TextEdit support, and trying to create new stack gets stuck on HyperCard repeatedly trying to call PBGetCatInfo for some reason which needs to be debugged). Thank you We'll keep you update on our progress
  3. Hi again! Your question about HyperCard actually was quite inspiring, as it motivated us to add experimental write support to M.A.C.E. this past week, and we can now *partially* run the stacks bundled with HyperCard 1.0.1 I added a gallery with pictures of current state of what HyperCard can currently do on M.A.C.E. to our blog: https://mace.software/2019/03/31/hypercard-1-0-1-works-now-kind-of/ (The pictures in gallery can be clicked to zoom them bigger) We're really excited about this, and can't wait until we someday this year get to the end of "Phase 1" so you guys can also try this out HyperCard is still highly unstable, so it wouldn't be useful to try bundling the free HyperCard player yet at this point, but this should give some basic idea what to expect when get things stabilized.
  4. Toni_

    640x480 on LC II?

    That's a good point, I luckily had a Macintosh 12" Monochrome Monitor also stashed away so tried with it now too: Sadly, it appears to have same output. However, I did notice there was vague "ghost" image of "Welcome to Macintosh" screen visible during the boot, so I'm guessing my LC II may have some kind of hardware failure that's specifically appearing when using the built-in monochrome mode...
  5. Toni_

    640x480 on LC II?

    This is an interesting topic, did any of you manage to get the zero-VRAM monochrome mode to work? I dug out my LC 2 tonight from the storage closet, remove the VRAM, and went through all my VGA adapters to check which of them would work. Most of them did not give any output to VGA, but two of them (which I believe are hardwired to 640x480 sync-on-green) gave output on a VGA monitor - BUT the output was only only full screen of gray color which I guess is the output given by any mac video cards before it is initialized (not the black&white pattern, but solid 50% gray). However, after I connected a real 14" Macintosh Color Display, I got rather odd pattern on the screen: Unlike the 50% gray on VGA adapters in previous attempts, there appears to be 16 pixels of some data on the screen which gets repeated for the whole screen (40 times horizontally x 16 = 640 pixels). It does not appear however to be actual, real video data, as the 16 bit data seems to change randomly when anything happens during the boot. Everything works normally though, when booted with the 512K VRAM installed (in picture laying on top of LC II case).
  6. Thanks! HyperCard 1.0.1 and 2.0 are actually part of the (dozen) test applications we're experimenting with. HyperCard 1.0.1 appears to require write access to stacks (it opens the "Home" stack and exits immediately after failing to write to it), and as currently the filesystem is read-only, it won't work until write support is implemented: As for HyperCard 2.0, it appears to have some bugs in the menu bar (literally!!!): No idea what's going on here, as we haven't yet looked into this much...do love the irony though This version is however blocked in practice by missing Styled TextEdit routines (trap A83E = TEStyleNew), which we can't work on before we first finish the basic (non-styled) TextEdit support someday. I'm guessing it will also eventually require the write support to file system like HyperCard 1 does.
  7. Thanks! Yeah, back in the late 90's I was reading about BeOS in a local Mac magazine and always wanted to try it out, but the Macs I had were never supported by it (I recall the versions they made for PowerPC required PCI-based Macs and were not compatible with G3). I've been following Haiku since it was still known as OpenBeOS, as (being based on BeOS) it feels like it captures some bits of the original MacOS essence with it (spatial file browser with multiple windows, etc). It does feel like a promising light-weight alternative for windows/linux on non-Mac computers. Thanks We're keeping the issue definitely on the "must-fix" list, not sure yet though how soon it will be as there's a trainload of stuff to do still This past week Pukka's been busy optimizing the 68k emulation, while I've hacked around the toolbox emulation layer enough to get Photoshop 1.0 to finally run without crashing at least long enough to allow drawing some scribbles with it
  8. Just a small quick update: I got this week personal permission from Robert Munafo for distributing his "Missile 2.3" as M.A.C.E. bundle, so it's now also available for trying out
  9. Thanks for the feedback! I've now added this to our list of things to fix - I was actually already thinking of improving the mouse input someday, the issue is that we don't actually react to mouse events, but rather poll the mouse in VBL interrupt handler about 60 times per second to generated mouse events, and the trackpad tap appears to happen so quickly that most of time the mouse button state doesn't even register before it's ended. This might also happen on a regular mouse if button is clicked fast enough (faster than 16 milliseconds). Great to hear that the app wrapper is working on your Mac!
  10. Hi again, We finally got the first prototype in good enough shape for public preview (One day later than promised - It took a bit longer than expected due to a number of minor tweaks needed in the build system (including adding proper credits/copyrights etc), and extra work needed to implement StretchBits trap handler) Here's link to the download page: https://mace.software/files/ The only thing what we have there at the moment is the public-domain game "Stunt Copter" wrapped as a emulated 68k app package as promised, with all features of the game working 100% (including Sound Driver-based sound). It should be compatible with MacOS X versions from 10.7 to 10.14 on 64-bit Macs (tested briefly on 10.7 Mac Mini, 10.11 MacBook Pro, 10.12 Mac Pro and 10.14 MacBook Pro). Please let me know if it works or not, any feedback will be highly appreciated (Ps. I've been checking legal stuff regarding fonts etc, and it should all be good enough as long the above application is run on a Mac computer, to satisfy Apple's font embedding rules)
  11. Some progress to report We got the prototype of Mac OS X application bundle creation to work today with the new build system, so we can soon semi-automatically package any apps converted to AppleDouble format into .app packages. This will be important step to first general public preview version, which we hopefully will be doing by end of this week with Stunt Copter, which is ≈99% completely emulated at the moment. It should be noted that at the toolbox emulation is still far from complete, and we plan to only package legal, public domain apps for demonstration. When emulation is more complete, we plan to figure out more general way of using the emulator for running also non-packaged apps. !!! - If you have any suggestions for which public-domain apps/games you would like us to target, please let us know so we can add them to our list if applications to target emulator and package for testing. Currently PD games we plan to support are Stunt Copter and Continuum, but if you know any others that are legal to copy, we're happily accepting suggestions. (We have already a bunch of other games more or less working as can be seen in the screenshot, but sadly can't and won't share because they're copyrighted or not yet verified to be in public domain) - !!! There's still a lot of work to do for this first preview though (and before it we also still need to figure out legality of allowing the 68k applications to put Apple logo into the Apple menu or if we need to replace it with something else, but I don't think that should be much issue as even a big entity such as archive.org appears to be displaying the logo in the mac games they host on their page...) (Ps. Today marks the 1-year anniversary of this little project, which we rebooted one year ago on 19th February 2018 )
  12. Thanks for the good question! We don't actually currently target any specific ROM level for compatibility, but rather use generic model which has sets of configurable features (currently static at build time, but we plan to make them dynamic later to allow changing compatibility without needing to use different binaries). The most important architectural decision is that we have abstracted the emulated toolbox APIs from emulated "hardware" in such way, that we can choose between two operating modes for emulation, "Classic" and "Universal". (And memory manager can also switch between 24bit and 32bit modes like on real 68k Macs.) The "Classic" model forces 24-bit mode, and attempts to simulate the environment of Mac Plus/Classic/SE type Mac as much as possible (with maximum of 4 megabytes of addressable memory), which allows us to emulate neat features hardware page flipping through alternate screen buffer & hardware audio buffer (both of which for example at least Dark Castle appears to require to work). It also only supports non-color QuickDraw. This is the model we will be aiming in first version. The "Universal" model will allow either 24-bit or 32-bit memory manager operation, and use Color QuickDraw with multiple displays, any screen resolution and any color depths. It also does not attempt to simulate any specific hardware configuration, so it will allow much more flexibility over the "Classic" model. This would be in the version 2 someday. Thinking about the original question about ROM version compatibility, one major difference between those ROM versions would be the trap table size... We have the "full" trap table at the moment (256+1024 traps, as in SE/30, II and later), although theoretically we could introduce even 64K ROM/128K Mac (512 traps with 15-bit offsets) compatibility but hopefully that won't be needed. (Another feature we're planning is also the "seamless" mode, where desktop could theoretically be made invisible like in Apple's Classic Environment. This would however only work from version 2 onwards with Color QuickDraw, as the "Classic" mode is hard-wired to 512x342 pixel resolution, which cannot be made seamless, at least not without looking really weird...)
  13. Hi again, I don't want to spam this thread too much, but I think this might interest you guys... tonight we quickly added full support for Desk Accessories to the emulator, and got actual System 6 Calculator DA (written in 68k code) to work almost "out-of-the-box" I made a quick video of how it looks like (There's also a audio bonus at end of the video ): https://youtu.be/60jG0wDSiB8 I did a short post about what we technically needed to do on our blog at https://mace.software/2019/02/13/desk-accessory-support/ (I hope the text there & here makes sense - I'm more of a programmer than writer, and it's almost half past three in middle of night here after coding entire evening so a bit tired... )
  14. It may be that the discussion was about the other emulator (mentioned by nglevin), I didn't find any references to our project since 2010 on the forums. Thank you so much for the positive feedback! It's nice to know there's interest about what we are making, which will help us keep motivated and focused on the goal to getting the first stage of this project completed soon! Yes, this is different project. We actually didn't know about AMS until about last week, about the time when we were encouraged to go public about our project, which we had kept secret up to that point. I'm not sure about how AMS compares to our project, as I tried to compile it but sadly couldn't get it to work. At least technically they appear to have quite different approach to the toolbox emulation. Originally we planned to stay quiet until end of phase 1, and announce publicly at that time (I hate promising and failing to deliver!), but our progress seems to be pretty good at this point - given that in a few weeks it's exactly one year since we started our current attempt at creating this emulator from scratch.
  15. Hi, I posted about our project a few weeks ago on LEM facebook group, but wanted also to share information about it here on 68kMLA: We're working with my friend on a new Mac emulator, which does not require any ROM or system software, which would basically work as a intel-era "Classic" environment replacement. So far all development has been done only by the two of us on our spare time. It should be released by end of this year in some form, and there's no builds yet to try out (work-in-progress), but we have a bunch of screenshots, and a few videos what it currently does. We created a new blog, where we've been documenting our progress for the past year: • Most recent news: https://mace.software/news/ • About the project: https://mace.software/ • Status of which applications we have tested and how they work currently: https://mace.software/status/ • YouTube playlist of some of the videos: https://www.youtube.com/playlist?list=PLEW7v-eMZEJElUv0UchqQ1BVqcKjbHWdq I'm implementing the toolbox part of the project, but credit for original idea (and 68k CPU emulation) goes to my friend "Pukka", who posted about this project originally here on 68kMLA in 2010 when he originally started it: https://68kmla.org/forums/index.php?/topic/43720-coding-projects/&do=findComment&comment=469818 We haven't yet done much planning on how to release/publish the emulator, but hopefully we will have before summer some way of packaging at least a small test application.
×