Jump to content

Toni_

6502
  • Content Count

    62
  • 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. That looks interesting, I searching information about the project, and found youtube video of the NTK basilisk2 demo through newtontalk mailing list, and it looks like something fun to definitely try out at some point. I did quick snoop around the SDK, and I believe at least Edition Manager and Communications Toolbox are required for it, both which are not yet implemented in the emulator. They will be of course added someday, but as of now, they are still on the To-Do list, and thus the NTK will not - yet - run. The plan is to support serial ports both physically (for example, USB serial adapters), and as virtual devices (simple unix input/output streams). We don't have at this point much of that implemented, but the Device Manager DRVR driver code is ready to support serial devices when we implement them. I actually have two USB-to-serial adapters I have been playing around with, but for some reason I am having difficulty getting even native OSX serial applications to work properly with them (they're so outdated that actually I cannot get native OSX drivers for them updated). I really would like to get the native devices to work, so that we can implement the proper status & control codes and verify their functionality at the same time. The input/output stream support would be really trivial to add on top of that, because it could ignore the hardware-specific serial protocol configuration stuff (baud rates/stop/parity/etc bits, etc...). Also Pukka said he was looking into some serial port stuff a while back, but he has been busy recently, especially now with the epidemic causing rearrangements in the daily lives. But this is definitely something we have on the roadmap. We already have tested adding some MacTCP driver functions, mostly DNR/icmp echo, but that is another topic... Ps. Here's latest thing we got recently running on the emulator, with (sadly) fitting message for these times...I will write later a blog post about it, there's still issues that need fixing before that (i.e. outline text rendering crashes 10% of time because of unfinished color QD code, color QD menus are still leaving artefacts around screen because of more unfinished color QD code, and the Palette Manager seems to be misplacing a couple entries which causes those color indices to not display properly in this particular game)
  2. I hope everybody here is safe & healthy, now with the epidemic going on in the world... As for the good news, we have made some minor progress with color support on our spare time in the past 2-3 weeks: https://mace.software/2020/03/18/more-color-support-palette-manager/ Basically, we are now starting to have Palette Manager support, and one by one we are getting more and more color drawing features functional. Here's a screenshot of the latest status: I also made a short video clip of the demo running: https://www.youtube.com/watch?v=YdeiB91bNwo (I hope the youtube post-processing will improve the video quality, right now it is a bit messy being really low-res)
  3. No problem, glad to be of help. If you manage to figure out a way to get contact with the author (he's got IMDB profile btw at https://www.imdb.com/name/nm4184021/ but his contact info is behind a paywall), let me know, and I could ask him for permission for making a MACE bundle of the game (either demo or full) too. In the recent past I've managed to contact a couple authors (most notable Missile and Continuum developers) and received positive responses, so perhaps also he might be sympathetic for the initiative.
  4. Hi again, and sorry for late reply. Been super busy recently! What I understand (based on the "About" box contents), the author made Dungeon of Doom a commercial game with the 5.4 upgrade, it being previously a shareware game. It seems that Dungeon of Doom 5.4 is actually a demo, and "Dungeon Revealed" is the commercial version of this demo. So the 2.0 version is probably an older shareware release before they changed the purchasing/distribution model. If you have the disk image, you could consider uploading it to the websites which currently archive old mac games (I am not sure if their names are allowed to be mentioned here, so I'll just play safe and not name them). This way it might benefit other people who might also be interested in trying out that older shareware version. The reason why I have been quite busy is that, besides of having a lot things to do at the daily "real" job, we have been busy improving the color support, which I wanted to have something to write about now that our project has officially reached the second anniversary: https://mace.software/2020/02/23/2-year-anniversary-of-mace-and-some-color-progress/ I'm glad that we were able to squeeze already some color gameplay video into this update, but there is still a huge amount of work to be done. But I will keep you guys up-to-date as we get more progress done during the spring.
  5. Thank you It is always great to hear there are people who are interested in the project. Actually, Dungeon of Doom (or more accurately, version 5.4 demo of it) is one of the games we already tested during last year (it's on the status page at https://mace.software/status/ ). There were some problems getting it to work in the past - but I saw your message, and decided to give it a try - and after a couple tweaks and two bug fixes in Toolbox emulation a minute ago, the game seems to work now okay At least I managed to get to level 2, with save/load, the "demo version" sound effects, etc. working. Really fun game, used to play this also a lot when I was young. We should probably update the status page soon to reflect the fact it is working now, but I'll do it later when we get some more progress with the color quickdraw and other applications... It would be interesting to know more about the keyboard issues, I would assume Minivmac would have most accurate implementation (at least on Mac), because it has such low-level hardware emulation - and all the modifier keys map directly to Mac keyboard (I know that on windows default minivmac has a bit oddly F1/F2 mapped to command/option). I did not find any problems at least on M.A.C.E. with quick testing though, but I'm not sure if I tried all the buttons I'm not sure if it would be okay to bundle the demo version as a M.A.C.E. test application in the downloads - the about/other docs point out it is a free demo, but there is no mention about distribution permissions. To be safe, I would want to reach out to John Raymonds to check permission for this before adding it. However, when we get the generic M.A.C.E. environment (and possibly the MA.C.E. app bundle creator) soon working, this game and others should be testable by anybody.
  6. I know of the sound issue you mention, we looked briefly into it one year ago, and it may be problem with how SDL handles our (or classic Mac's) 22255 Hz sound frequency, which we use as the output format. It seems to be worse on higher CPU usage, but in most of our tests the "popping" has been minimal. It is however on the list of things to improve, and we will give it definitely a more profound look into when we start work on Sound Manager this year. Thank you Actually the color support is one of the next major features in our task list, and I posted just a moment ago a status update about it in the blog: https://mace.software/2020/01/31/first-steps-into-a-more-colorful-emulation/ It's still far from being ready for test applications, but we have started the work on Color QuickDraw emulation a couple weeks ago, and we will be improving it (hopefully) a lot during the spring. I think we should have first color test application(s) before summer, unless there are any sudden major obstacles or changes in schedule. Thank you for the feedback It is highly appreciated.
  7. And now the Windows version is ready for testing! For people who prefer to use that system https://mace.software/2020/01/07/windows-version-and-screen-mode-control/ We've package all the eight current test applications for Windows, and they are available in the downloads section at https://mace.software/files/ . It took some time figure out that WordPress (silently) does not allow linking EXE files (or ZIP files containing them), although it allows uploading them...weird. Anyway, for the time being, I put the Windows version ZIPs into my Dropbox and shared the downloads through it. It should be noted, that like Mac bundles, the Windows EXE files are also unsigned, so (depending on security settings) the Windows may also complain about that a bit. Theoretically everything *should* work, but we've only tested the new version on two PC computers (plus one virtual machine), and we haven't found any Windows-specific issues anymore. For now, the command key is mapped into ALT key on windows keyboard, and option key is mapped into left CTRL key. Another new feature is the pixel double and full-screen mode toggling, with Cmd+Shift+1 and Cmd+Shift+2 respectively. This new feature has been updated also to the existing Mac OS X app bundles. I hope you guys have fun with this, let me know if it works or if there are any issues
  8. Happy New Year (and belated Merry Christmas) from the M.A.C.E. team! There were not much news at Christmas time, so I did not post a link to the Christmas update here earlier (at https://mace.software/2019/12/26/happy-holidays/ ) - mostly it consists of Christmas themed Dark Castle near-playthrough, and MacTCP teaser. However, if you are using Windows (or Raspberry PI) platform besides Mac OS, you might be interested to know, that we have made significant progress on the ports of M.A.C.E. on both of those platforms: https://mace.software/2020/01/01/happy-new-year/ To sum up, we expect to be able to provide Windows versions of the test applications as soon as during January, with only polishing and tweaking to be done. I will let you guys know more later once we get them ready for testing!
  9. Hello, There's another minor update on the progress. Pukka mentioned somebody on Emaculation forums was asking if we could run Apple's Finder - so we attempted it, and made some fixes so that the original, unmodified Finder 6.1.8 from System 6.0.7 will (mostly) work on M.A.C.E.: This could be considered as another step towards the generic M.A.C.E. release. Of course, we cannot distribute Finder ourself, but it is nice to know that once we get to that point, people could use it if they want to Here's the full briefing on the recent development: https://mace.software/2019/12/12/finding-the-finder/
  10. There's a couple pages that might be of interest for you: - Ingemar's SAT page: http://www.lysator.liu.se/~ingemar/sat/sat-downloads.html - has the SAT 2.6 for 68k applications, should work both in THINK C and THINK Pascal 4. However, I don't think there is source code available for it, but it was a widely used graphics library, so it should be pretty stable. (He also has information and guide for THINK Pascal 4.5 at https://www.lysator.liu.se/~ingemar/tp45d4/think.html if that might be of interest). - SpriteWorld: http://spriteworld.sourceforge.net/ - At least 2.x version has 68k/ppc support, but it only works on 8-, 16- and 32-bit colors to my knowledge. So it would not work on monochrome macs...but it has full source code (including the BlitPixie blitters) included. I am not sure if either of these fits exactly what you are looking, but they might be useful resources.
  11. Hi again, Here's some replies to some earlier comments: I think the basic idea how Apple did it Mac OS 9 nanokernel, was abstracting the lower-level hardware through the nanokernel interface, running Mac OS 9 on top of it as a single task (and thus normal applications runnning on it would not directly benefit of the multitasking and memory protection features). I read that this abstraction was one of the key elements running the actual Mac OS 9 into Classic environment, where the low-level nanokernel was replaced with the Classic runtime, allowing most of the Mac OS 9 running on top of it to remain intact. There was some discussion here: https://groups.google.com/forum/#!msg/comp.sys.mac.programmer.help/tO0iuTNETGc/oTwfHPfuqXoJ In the old days the hardware limitations kind of forced people to create performance- and space-efficient code, which with current hardware is just blazingly fast and small. However, that comes with the downside, that a lot of the old System software (Toolbox APIs, etc), and many applications, bypass a lot of sanity checks, and tolerate a lot of even buggy behaviour without immediately crashing the system or having side effects. One example was "BattleCruiser" game which I was trying recently, which does DisposeHandle on a resource handle, which does not surface as bug until the resource handle in resource map is accessed next time (in that case, doing ExitToShell -> CloseResFile). Another example is actually from one of my very early shareware games, aWorm, which I noticed does not set a valid GrafPort using SetPort before doing CopyBits on the window. This by luck happens to work most of the time, but if that port is set to the screen port, it will crash in attempt to use the non-window GrafPort as WindowPeek. Good catch 21 years after after making that game... Something akin to this would be truly a dream OS. One of the motivations for writing the boot loader I mentioned in one post earlier. However, have to see how soon we will get there... now that Apple is, sadly, making it more difficult to publish independent software even on MacOS, there is growing motivation for having possibility to host the emulation on also other systems than Apple's own. It is true that Apple Events can be easily abstracted. However, they are not the only means of sharing information between Applications. There's also the PPC Toolbox, Process Manager APIs, and as Mac has linear memory with no memory protection, any process could share information with other process by simply finding a way to pass valid Pointers/Handles to other application's zone, which there is no way to prevent on Mac OS. There may be also other cases, I haven't looked for example much into CFM shared library mechanism, but I'm sure those will come up eventually. Actually the header does have. But true, technically this is not a big challenge to recalculate it. The file operations always operate on data on disk, as a 1:1 mapping to Mac OS Toolbox APIs. So when for example Mac application does _SetEOF call, we only do ftruncate call on the native side (which appropriate error checking, etc). I think the feature you are referring to might be disk caching, which caches file contents in RAM. All this however is delegated to the host system, because handling additional RAM cache in emulator would be unnecessary and complex work - and might even risk adding data corruption, for example if emulator crashes before data is flushed on to the disk. The aim is not to reduce data size, but to reduce complexity of operations and thus reliability. --- In other news, here's some latest advancement in the development - we can now run PC emulator inside M.A.C.E., so basically the emulator can emulate emulators https://mace.software/2019/11/27/softpc-and-the-quest-for-the-xt-memory-map/ Sorry for the slow development speed, real-life work is slowing down us at the moment, but we're making progress every week. The goal is still to reach some sort of generic release of Phase 1 emulator (in addition to the bundled apps), but there will be a bunch of unfinished Phase 1 stuff still in it, which may limit application compatibility. I think the next target is to implement "Shared" filesystem module for M.A.C.E., which would allow cross-process - and also native HFS+ - file access. Just want to make everything perfect, so you guys won't be disappointed because of the certain bugs and certain unimplemented features that are still in progress.
  12. Thanks for your reply. We actually considered MacBinary initially as the format last summer when we started work on the file system, but gave up quickly with it because of the performance (and disk-wear) overhead, CRC checksum calculation and added complexity of managing both resource and data forks in a single file which made it unpractical for real-time file operations. For example, adjusting data fork's size in MacBinary file would force relocating the entire resource fork's portion inside the single file. With AppleDouble, the both forks live in separate files on host system, allowing them to be easily resized without affecting each other as a near-zero-cost operations. This also has the benefit that we can support non-HFS host systems with current code, even though we currently only have Mac OS X builds available. We did structure the file system code in such a way, that we can easily add alternative file system backend layers, including the native HFS support (using ../namedfork/rsrc). However, this has not been a high priority (compared to other more important features), especially as it is unclear for how long Apple will keep the good old resource forks & file metadata working natively... for example, when 10.6 was released, there was an article that Apple had at least partially repurposed at the time resource forks of certain files as a way for implementing per-file compression ( https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/3/ ). It should be noted that the goal is to support more options in future, especially when we someday get the "generic" classic replacement good enough for release, to help transferring files to and from the environment. The native host system resource fork support is one the possible options, and we will also be investigating the support of actual MFS/HFS disk images - and we are also researching options for exchanging files between MACE application instances directly as one shared virtual volume. But all those options will still need more planning. The priority at the moment is to implement missing toolbox routines and debug & fix most important known issues to make as many of the test applications as possible to work. For now, the current file system approach seems to be enough, as it allows creation and using the app bundles which provide the easy-to-use one-click solution for people wanting to try out the (currently available) old applications as easily as possible - even though Apple is trying to make that also difficult with the code-signing and sandboxed filesystem hurdles.
  13. Hi, It's not that many days since my last post here, but there's some great news: We have now bundled three new games for you guys to try out! One of them is one of our favourite games - Continuum - which I got the personal permission from Brian Wilson to put up for free download as a M.A.C.E. bundle! The two other are some our favourite freeware games GunShy 1.3 (mahjong solitaire clone) and MacConcentration (match pair memory game). Also, all the test applications have been updated to the new Beta 7 version of M.A.C.E. runtime, which includes - among other things - fix for the disturbing Catalina keyboard permission popup, and writable file system support, which allows finally not only high-score saving to work in ZeroGravity, but also Standard File dialogs to be functional in GunShy and Continuum. This means that the Planet Editor is fully functional in Continuum. • More details about this newest update: https://mace.software/2019/10/28/continuum-two-other-new-apps-bundle-write-support/ • Updated app bundles: https://mace.software/files/ We have tested the updated app bundles on Mac OS X 10.6, 10.12, 10.14 and 10.15, and they seem to be working nicely so far. If you try them out, please let me know if you encounter any issues with them. I am especially interested in the performance of the new writable file system code - it is such a major and new feature that there must be still some bugs hiding in it...
  14. Toni_

    FPGA Mac

    It would be interesting to see this idea someday implemented by someone. A couple years ago I was reading about a project for creating a full Amiga similar way on FPGA, including a 68K which was also used in Macs. I think the project I was reading about was https://en.wikipedia.org/wiki/Minimig There was also a project to create a full 68K cpu using FPGA: https://blog.adafruit.com/2018/12/10/fx68k-an-open-source-68000-cycle-accurate-fpga-core-vintagecomputing-fpga-gaming/ One challenge with Macs are the ROMs, which are (to my knowledge) tightly tied to the certain hardware configurations they were originally used in, and on other hand, the Mac System software has a lot of overrides & hacks to specific ROMs. Using certain existing ROMs would limit the hardware "simulated" in FPGA to certain specific configuration, but on other hand creating a custom ROM specifically for the FPGA Mac clone might require a new System 7-type Enabler to be written for it. But that would definitely be interesting approach.
  15. Hi again, Sorry for not posting much recently, we have been super busy with real-life work, and implementing one really important feature - the Standard File Package! So, now we basically have finally are getting the "Open" and "Save" dialogs to M.A.C.E.! https://mace.software/2019/10/22/standard-file-package/ There's still work to do, but this will soon allow us to add a bunch of new test app bundles (one personal favorite I'm hoping we can finally add, if we get permission, is Continuum, which uses this for saving & loading of custom galaxy files). I will post more when we have something new for you guys to try out, but for now I have to keep this short due to late time and minor autumn cold I'm having that's slowing me down a bit.
×