Jump to content

Toni_

6502
  • Content Count

    40
  • 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 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
  2. 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
  3. 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).
  4. 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.
  5. 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
  6. 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!
  7. 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
  8. 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
  9. 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.
  10. 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...
  11. 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).
  12. 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.
  13. 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
  14. 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
  15. 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!
×