Jump to content

Toni_

6502
  • Content Count

    47
  • 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, It will be possible someday, but it will take a little bit more work than the 10.6 compatibility. My main development machine, which we use to create bundles, is running Xcode 9 on Mac OS X 10.12 which can go only down to 10.6, which allowed the 10.6.8 support to be relatively easily added. We do however also have lower end machines, and I can do builds on Xcode 4 on Mac OS X 10.7 on Mac Mini C2D, but we will also need to prep up a test machine with Mac OS X version lower than 10.6 to do the tests. Also, I am not sure how low SDL2 (our current front-end) can go. Pukka has mentioned a couple times, that he would like us to try to go as low as at least PowerPC G4 with OS X 10.3, so we definitely will not be ruling out lower end, it just will be a lower priority at the moment.
  2. Hi again! I recall reading about SheepShaver back in the day when BeOS on PowerPC was topical, but sadly I did not have chance to try BeOS until the x86 version (which I think SheepShaver did not work on at that time). It is such a long time ago, that I had to refresh my memory by doing some reasearch, but I found out (from http://www.atpm.com/4.09/page12.shtml ) that it is true that one unique aspect about SheepShaver on PowerMacs was that it did not require ROM image, but used the actual ROM in the machine in the emulator. That is quite neat feature, and is a little closer to Apple's Classic environment, compared to other emulators such as Mini vMac, Basilisk II, and the x86 version of SheepShaver. All of those options, even Apple's Classic environment, still require installation of the real Mac OS, which is something M.A.C.E. does not require. I think the closest equivalent would be ARDI Executor, which also requires neither ROM or system software, but compared to it we are aiming to have better compatibility in the long run (especially to get older classic games to work, which have strict requirements for hardware emulation especially for sound/video buffers, 24-bit memory manager, etc...) Actually not really, technically we are only using the multithreading capabilities of host system to simulate interrupt and CPU "idle" operations. From the perspective of emulated applications, everything is still working as on the real Mac. The same "thread-safety" rules apply as on real Macs (which mostly can be identified by warnings in IM documents mentioning certain calls not being interrupt-safe - such as memory allocation calls not allowed from VBL handlers, etc...). The main application code running on main thread in the emulator equals to the single execution context on real Macs, which the interrupt handlers can, well, interrupt, but the code running in interrupt handlers cannot be be itself interrupted. Technically, real Macs have various interrupt levels, which allow interrupts to be nested, but that is currently not supported as it has not been needed. For example, if VBL handlers exceed the 16ms limit (which is how often VBL interrupt fires), on real Mac a new VBL interrupt would be generated, which would only increase Ticks lowmem, but not re-enter the VBL task execution as it would already be running from the previous interrupt. This is one of the reasons sometimes on older computers, when VBL task exceeds the time limit, the mouse cursor would start getting "jittery" and "laggy", but the TickCount would still be valid as the Ticks would get updated properly. In our emulator, however, we run those "missed" Ticks increments on the next VBL interrupt, counting the number missed from the same timer which runs the audio synchronization with SDL audio thread. However, nothing prevents running multiple M.A.C.E. instances on the same host operating system, and as they would be individual virtual machines, each of them would have from their own perspective exclusive ownership of the CPU, while in actuality the host system would schedule execution time between them, like currently on Mac OS X when running multiple M.A.C.E. applications at once. The downside of this is, though, that process manager-aware applications would only see their own instance, as the memory space is currently unique to each application. This is not yet a problem, but at some point there will be work needed to see whether process manager support is better to be implemented as System 7-style cooperative multitasking using exact process manager emulation, or whether for example launching of applications could be delegated to host system. This would however create challenges on how to handle program-to-program-communications, "shared" memory (on real Macs all apps share the same address space, and thus see each other AND the temporary memory allocated from the process manager/system heap). I hope that information makes some sense - I am really better at writing code for all this, compared to writing documentation *about* it Semi-off-topic: Of course, a dream situation would be to be able to create a completely independent Mac OS 7/9 operating system, but that would require adding a kernel and drivers, as currently the emulator depends a lot on host system to do a lot of the heavy lifting. However, I did write a couple years ago a small x86 "PC" BIOS bootloader, which can parse real HFS+ filesystem on MBR volume and launch executable stage 2 boot loader from "System" file in "blessed" System Folder (posted on https://forum.osdev.org/viewtopic.php?f=1&t=12087&start=3297, direct link to image: https://forum.osdev.org/download/file.php?id=3851&mode=view ). This however is quite far-fetched idea, so not really in scope for at least the next couple years... I was actually checking the ZSculpt website recently, as we have Dark Castle 99.9% complete (only issue left is that some [probably] CPU bug is causing the robots to behave erratically - otherwise everything works including controls, sound, gameplay, high-scores, etc), to see who to contact in case we get the game finally to full 100% completion. It would be really great to have this original, iconic game again publicly available on the modern Macs. Although Return to Dark Castle is also an awesome game - we played it through on easy level with Pukka a couple years ago in the office after-hours (original Dark Castle we completed I believe at least on the intermediate difficulty, maybe even on advanced...cannot remember exactly). Ps. There was request on Facebook for 10.6.8 compatibility for the emulator, so I actually added it to the build today (previously 10.7 was minimum), and updated the bundles with new version. So if any of you guys have 10.6.x, you can now give the apps a try on that system (it's actually very ironic, and kind of sad, that how blazingly fast the 10.6.8 is on iMac 2006 compared to 10.14 on 2015 MacBook Pro...with less memory, spinning hard drive, and much older CPU...)
  3. Hi again, We're still in middle of preparing next update, but we just had yesterday a rather interesting thing happen by accident, which I wanted to share here because it is rather unusual: While trying out a couple potential test applications with the emulator, I ran into an application which was infected by nVIR A type virus ( https://en.wikipedia.org/wiki/NVIR ). What makes this interesting, is that it apparently was able to infect the System file of that application's bundle, as we now have near-complete resource write support: This is partial output of the "System" file's resource map debug dump, and the 'nVIR' and 'INIT' resources were actually written into the System file by the virus in infected application - and the system resource map seemed to be mostly still functional! I only found this out because a bug in resource writing corrupted Geneva font, causing the infected application to crash A kind of controversial achievement, having good enough compatibility for even viruses to work in the toolbox emulation... Luckily the infection was isolated to only a couple individual test applications, and I was able to identify the original source of infection on "MAC OS 6 App Collection.dsk" image at: http://www.toughdev.com/content/2016/12/system-6-0-8-on-a-vintage-macintosh-se-with-4mb-ram/ Please be extra careful if you download the disk image from page, I have written comment to the author to let him know about the infection. One of the positive sides of the current per-application bundling of files as isolated file systems, is that the infection never was able to break out of the application bundle. I've also scrubbed through all disk images to make sure there will not be any risk of infection at later time (and run Disinfectant on the source Macs regularly). These viruses are ancient, but can awake up at any time it seems...
  4. Sorry I could not reply earlier, we have been very busy with work and programming in the spare time Well, someday if we ever get to the point at which we implement MacTCP support and AppleTalk stack, theoretically AppleShare IP server could be run in the emulator. At least on Mac OS X native AppleTalk cannot really be used without special network driver, as the BSD sockets API on the system appears to be limited to only IP-based protocols of the OSI Network layer, although on some systems may allow implementing custom protocols on that layer. One solution might be the custom driver, such as I think Basilisk II was using at least on Windows. A FTP server would be rather unpractical, as all Macintosh files would need to be compressed and/or wrapped as BinHex/MacBinary to preserve resource forks and metadata, while AppleShare would allow files to be transferred directly without needing conversion on both ends. Actually one interesting option might be to explore possibility of using serial connection, and some BBS software which supports Macintosh files, such as FirstClass. Maybe the native FirstClass server could be run on the real Mac, which FirstClass client could connect to from the emulated environment on through a USB-to-serial converter or something. This was an idea suggested by Pukka a few weeks ago, which I almost forgot about. This would also have the benefit of not requiring file conversion on either end. (Ps. I myself personally do file transfers at the moment using USB sticks formatted with HFS+, from a PowerBook G3 running Mac OS 9 to the Mac OS X - Although I hope Apple doesn't retire HFS+ too soon now that APFS is out...) Thank you, I tried to shuffle the website for a moment but seems the search is rather obscure, or maybe my browsing skills are just limited In either way, it's probably better that I focus on the programming and worry about that particular game later I'm glad to hear the games work for you, we actually today updated the test bundles to new versions which have quite promising performance improvements, which I wrote a bit details about on the blog a few moments ago. Thanks for the support, we'll get back to the coding and *hopefully* we will get more test applications for the next update.
  5. Okay, I wrote yesterday the blog post about last month's improvements, AND we have now two more test games for trying out which I promised! The newest blog post: https://mace.software/2019/08/20/a-lot-of-fixes-improvements-and-new-test-applications/ The two new test apps are ZeroGravity and Blob Mgr Demo, available at: https://mace.software/files/ Please let us know if you have any major issues with them. There is one known problem with ZeroGravity highscore (or 'loscore') saving, in which 10.13 sandbox security prevents saving score at the moment when launched from Finder, but it should work fine with old enough Mac OS X - however, if you launch it from command line, the score saving should work on newer systems too. We have a solution for that problem in development, which however is not yet finished. Another improvements include support for the "touch to click" issue which was reported here on 68kmla, let us know if the clicking works now ok for you guys Both previous test app bundles Stunt Copter and Missile have been updated with newest M.A.C.E. runtime too. Thank you for the information and effort, sadly I could not get the link to work. But I guess it is easier to focus at this point on the development, and see which games are easier to get the permission to distribute for. There are a couple cool favorite games we have been thinking about (Continuum, Fool's Errand, etc), but we still have some minor things to improve in the toolbox API before we get to the 100% completion on them (currently only known task/issue is to finish Standard File Package).
  6. That would be a fun thought I would love for everybody to have a chance to experience these fun games on modern computers - and something like "GOG" would definitely help with all the copyright things etc... And speaking of games, check out this new video below Does anybody know who owns the copyright for Apache Strike currently? I wonder if they might be open for allowing making a M.A.C.E. bundle of the game... There's a huuuuuuuge amount of news since last update, but we just haven't had time to write about them in the blog...I think most important thing to mention briefly is that Dark Castle, Beyond Dark Castle, Apache Strike and PT-109 are currently 99.9% functional under M.A.C.E., mostly thanks to Pukka's recent integration of the "M68K Emulator Testsuite" by Gwenole Beauchesne, which has already helped to identify and fix most of the remaining CPU bugs
  7. Hi again, I just wanted to let you guys know that we've made an interesting break-through progress in the emulator, we can now "almost" run Apple's ResEdit 2.x As a side effect, we have now resource decompression support, and a bunch of cool screenshots https://mace.software/2019/07/24/update-on-resource-fork-writing-resedit-and-resource-dcmp-decompressors/ There's still a lot to do, but we're working hard on getting the more general release out later this year...I'll get back to you later Thank you very much for the link and idea, it is highly appreciated and I will definitely reach out for them at some point. I think the best time to do that would be when we are ready for a more general release, as the currently packaged Stunt Copter and Missile don't really demonstrate the full capability of emulator at the moment, and there are still many things we need to fix before the general release. It's just that we don't want to make release of unfinished project to give people the wrong impression what we will aim as the final end result, but instead finalize and polish it as much as possible I think however after we get resource file write support working reliably, we will most likely be ready for a third simple demo application
  8. Hi again We're back from holiday trips, and although we're still on summer vacation, I just wanted to let you guys know there's been some progress during this time; we can now basically run TeachText, with nearly all TextEdit features working. I did a quick blog update which includes one holiday photo from each/both team members, which also details a bit more what we've been up to in the past few weeks: https://mace.software/2019/07/14/second-mid-summer-update-post-holiday-textedit-progress-clipboard/ Next up is resource fork write support, which is already nearly completed, but there'll be more details about that later when it's done
  9. Hi, I found all this stuff out when reverse-engineering the tetris code as 68k disassembly, and investigating the program flow using debugger (to make the sound work on our emulator) - and Apple's four-tone synthesizer I figured out by disassembling the 68k source for DRVR 3 driver I extracted from the Mac Plus ROM - The lookup table they use is just a optimization to avoid division, basically it's a very small part of the overall mixer (where they sum up individual bytes from each of six channels and divide by six to get average). For example, if the samples would be hypothetically something random like 117, 39, 5, 220, 0 and 0, the sum would be 381, which when divided by six would be 63 - they avoid this division by stuffing value 63 into the lookup table at index 381 for quick access (byte values in the table would be [0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3....<continued total 1536 elements>... 255, 255, 255]) - This mixing is just what's done for each individual 8-bit sample passed to sound buffer, it's repeated for each byte in the instrument over and over again. From what I've seen from the docs you linked, the instrument format is quite simple and just contains loop information, so actually any attack/decay would probably be pre-sampled into the part before loop, sustain would be the looping part, and release would be the part following loop. This way the mixer has always only to fetch one byte at a time from the instrument, and use the loop information just to know when to wrap into beginning of loop, or when the end of instrument sample is reached. This part about ADSR envelope is however hypothetical, as that wasn't part of the code I disassembled during debugging (but is how it would be sensible to make it performance-wise). - It's true that the amplitude will get down a bit when playing solo instruments, but with fixed and small amount channels I think they've usually considered it to be negligible (I'm only 95% sure about the 6-channel mixer, without checking the disassembly, but at least Apple's fourtone mixer doesn't have any compensation for this - and I'm pretty sure the studio session 6-channel probably won't have either as on classic mac the CPU time is very tight so they most likely would have just been ok with it). It should be noted that there are techniques to avoid this amplitude loss ("muting"), for example dividing two summed samples by square root of 2 instead of two. However my knowledge on this part of higher-end audio mixing is a bit limited, but my friend Pukka knows a bit more about this (he's written even his own MOD music player for mac, and he told be about this square root of two thing). - I think the technique of dividing by square root is actually is based on this "hope" that the summed samples would not exceed maximum amplitude, and is (from what I've heard!) used in more advanced mixers, especially when the number of sound channels is not constant. Sadly I don't (before end of summer vacation) time to revisit the live disassembly of mixer, BUT I found an old screenshot (which I originally used in our blog) about tetris mixer, which shows the particular part which does the aforementioned mixing: It's really old screenshot, so some of the disassembly is not completely accurate (Pukka has since developed the disassembler further). However here's a few interesting parts: • Code at 30B9A and 30BA0 loads the active 6 channel instrument pointers into A0-A5, and current offsets into D0-D5 • Code between 30BAA and 30BC8 increments the offsets, using the immediate fixed-point values I mentioned earlier (frequency of channel) • Code at 30BD0 clears D7, which is where instrument samples are summed into from channels • The four instructions swap, move.b, swap and add.w are repeated for each channel, to sum current sample byte from instrument into the D7. The swap commands are just used to switch fixed-point number's integer portion temporarily to low-order word for add.w, and move.b is used to fetch the sample byte from instrument at memory address A(0-5)+D(0-5), where Ax is instrument address and Dx is offset inside the instrument's sample data • The lookup table (6 x 256 bytes) is assigned to A0 at 30C10, and the "pre-divided" sample byte is copied to hardware audio buffer at 30C14 and 30C18 (the instruction at 30C18 should actually be move.b (0,A0,D7.l*1), $0002(A6), there was a disassembler bug there still at that point). Note that this copy is done two times here for same output value, which is where the output sample rate is effectively halved from 22255) • This sample mixing process, code from 30BAA to 30C24, is repeated 185 times
  10. Sorry I forgot to mention, one another difference from Apple's four-tone synthesizer is absence of the 256-byte sample length limitation of wave table instruments (they don't clamp the offsets in channels at byte length), which enables them to use much longer audio samples for instruments & get better audio quality. Also, they avoid needing to divide the summed sample by 6 (channel count) by using a lookup table of 6x256 = 1536 elements which contains precalculated results of division by 6 (Apple's fourtone synthesizer does the division with 4 by shifting the summed sample right two bits).
  11. This sounds like a great project! And great timing btw also, as I was actually recently this week contemplating about doing something similar also in future for fun (Studio Session file playback for games) I noticed from your other thread that Tetris is using Studio Session files, and from this it dawned to me that I actually have recently (last winter) partially reverse-engineered their mixer when I was adding support to our emulator for playing music in Tetris. Here's at least some info that might be of use that I can quickly recall (which is why might not be 100% accurate, more like 97%): • They actually bypass the Apple's sound driver completely, and use their own carefully optimized (for timing the sound buffer writes) 68k assembler mixer to control classic mac sound hardware. • Their mixer is able to combine 6 channels in real time, as opposed to Apple's 4 channels. • They do this by instead of using 22255 Hz frequency for samples, they use roughly ≈11127 Hz sample rate, writing each sample *twice* to the buffer at SoundBase. This allows them to save CPU time in the mixer, allowing the two extra channels without compromising too much sound quality (185 samples mixed per VBL task compared of 370). • Otherwise their mixer appears to be pretty close to the standard Apple mixer, with fixed-point values used for tracking frequency and phase for each channel. I also recall, that have very cool hack that instead of fetching those values from memory like Apple's FTSoundRec, they actually write those floating-point values directly *into the mixer 68k code* as immediate load instructions, so that they save CPU time by avoiding extra fetch from memory. • I don't know yet about how they handle interpreting the song tracks to get the instrument frequencies and samples, but I'm wildly guessing they're probably doing this either in a callback in the VBL task, or from another VBL task...or maybe even from main loop like Zero Gravity does with regular sound driver. I can drop in more technical info later - I'm about to get on summer vacation for a few weeks, so I have to get back to you.
  12. Thanks for the feedback, it's appreciated Interesting to know that they work under virtualization, we haven't tried that on the Mac OS X version...we're actually currently using SDL2 as platform abstraction back-end, which actually when running on Mac OS X defaults to OpenGL rendering, so it may be that if other applications are having hard time doing OpenGL under virtualization, that SDL2 might be smart enough to switch to non-accelerated back-end... In any case, we'll some day eventually switch to more native platform abstraction, which in Mac OS X case would be (at the moment) Cocoa (and at the same time we'll also fix the nasty mouse click issue people have been reporting on touchpads when testing the current application bundles). Ps. I took a little break today to record a short video of how lemmings gameplay looks like, now that it finally works https://www.youtube.com/watch?v=qqSpRqhGf4U
  13. Hi again! It's been a bit quiet for the past month(s), a lot of the "getting-more-outside-less-staying-inside" type stuff going on in the summer, but I took a few evenings in the past weeks to do some work on TextEdit features, and wrote a quick summary on what's new: https://mace.software/2019/06/17/mid-summer-update-textedit-progress/ Most interesting parts are probably that Scarab of RA is now almost completely playable (yey!), and HyperCard 1.x can enter "userlevel 5" which opens door to a bunch of interesting new options to edit the stacks The progress will probably be quite slow in the summertime, but hopefully in the fall we'll be at least a little bit closer to the goal of getting the more "Classic replacement"-type release of emulator, so you guys could try out more than just the few bundled apps No promises yet though on the date...but we're definitely getting there someday!
  14. 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
  15. 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
×