Jump to content

fstark

6502
  • Content Count

    42
  • Joined

  • Last visited

Everything posted by fstark

  1. That's really kind of you, and your words of support are more than enough motivation. The only thing I really struggle with is getting my hands on hardware. In particular, I'd love to get some network card for the SE/30 ( to try streaming ), but even after a couple of years looking at ebay, I can't get one (the few I saw didn't ship to Europe, and I missed them). Or if you know someone that would like to sell a NeXT Cube Turbo...
  2. It is an original jumper I got in the early 90's, when I was a NeXT developer. I should probably make new one to keep this one as pristine as possible...
  3. I unfortunately cannot upload most sample videos to youtube due to the copyright police. I'll publish the encoder at some point, so don't worry, you'll be able to have your familiy holiday movie on your Mac I also may try to do a video on the process. My editing skills are not to good, so it may take some time to come up with something watchable...
  4. Weirdly, Bad Apple is both a best and a worst case: it is a best case as there is generally very little change from frames to frames. However, it curently triggers two edge cases: First, by having 100% white or black parts, *any* missed pixel is visible. As of now, the algorithm concentrate on parts where there are the most differences, and won't care about a single wrong pixel somewhere, unless eveything else is perfect. This leads to occasional visible artifacts in bad apple. I know how to fix that, but it will end-up as yet-another-subtle-parameter to the encoder, as concentrati
  5. To be honest, I didn't plan to spend that much time on it, but so many people requested it and @Crutch cornered me into implementing it by gaving me the crucial info I needed. Thank you so much! I rewrote the whole thing maybe 5 times, but at the end, it was *totally* worth it. It is much better than the original MacFlim on almost every level (sound, better quality, consistent framerate, smaller files, etc.). This is only a tech demo, it may or may not be integrated in the main app (because it is completely different and shares zero code. even the encoder is completely
  6. Good feedback, thx! You'll get the version with sound pretty soon, maybe that will impress her more. Stay tuned!
  7. The short answer would be no port of MacFlim to NeXT. 
 You know, I am found of computers with uncommon display capabilities and low bit depth that I used when I was younger. And it just happens that, if you could look on the right on that MacFlim video, you would see an original NeXT Computer sitting there... And, well, I did code on NeXT in ObjC for something like 10 years, so... Why no MacFlim on NeXT? 
 Well, I was a NeXT user for years, and seriously, we were not keen on ported software, we wanted *original* stuff! 
 So, no MacFlim for NeXT, no. 
 However, it just happens
  8. The good news is that the "tech demo" works pretty well, modulus a few needed optimisations. The bad news is that I cannot upload good demos to youtube due to the !@#$&* copyright filter that make sure you can't exercise your fair-use rights (which I don't have anyway, being non-American ). I'll make another video when the demo is complete, with short extracts and downloadable content for you guys/gals to try...
  9. Yes, the code is hardcoded for 512x342x255. Sure. I did not want to release the code, as it is pretty crappy. Wouldn't pass my code review, for sure. But, well, you guys wanted it If you have a merge request, I'll take it, no problem. If you don't, you may have to wait a bit. Note that this whole thing is going to soon be quite obsolete. Note: do not hesitate to create github issues, for things from feature requests, encoding movies ideas, or bug fixes.
  10. Well, I actually used a lot of CVS, back in the day. And even RCS before. However, I really find this vintage source control problem difficult. I don't want to make my life harder by setting up CVS in the Mac. At one point, I did use hmount + hcopy, so I could edit the files in vscode in linux, and auto-sync with the versions in the emulator for testing. I think with some smart scripting, I could use some sort of git workflow. In my "fuzzy" ideal world, the files would be commited "nicely" in github, and the Makefile would handle details like creating the .dsk file and
  11. I am sorry, I was *absolutely certain* that I answered you immediately. I remember even typing the answer! I did update the github instructions right after your original question with a shorter way to do stuff. And yes, absolutely, there is zero magic, just do as you want, but generate *8 bits gray* PGM, as the code is well, extremely primitive! Donc, oui, pas de lezard, j'ai mis les instructions version completes pour ceux qui, comme moi, ne sont pas des pros de la conversion video. Et desole, je n'ai pas d'accents sur mon qwerty/linux de dev.
  12. a) no you cannot edit the flims. However, you have the encoder if you want. This was a feature in my roadmap (turn the app as some sort of flim editor, as if it was actually used for such, but the roadmap took a completely different direction) b) technically, you could create a smaller flim by piecing the parts together (removing the unwanted streams would cut the file in half already) c) alternatively, you can wait a few more days, I had to implement compression for a new feature... It will at first be a separate "tech demo app", but I suspect it will fit your needs mu
  13. Sorry everybody, didn't saw any of the replies until now! Had a busy week and failed at checking here Let me just say I spent my Saturday re-caping my SE/30 so I now get sound... Not hinting at anything ...
  14. I had a few moments like that in the last few days. Tried to understand the arguments of some sound format, and the only thinkg InsideMac said was that it was an "extended80". To understand, I went into THINK C headers, to find this gem: typedef struct { short man[4]; } comp; typedef struct { short exp[1], man[4]; } extended80; typedef struct { short exp[2], man[4]; } extended96; typedef extended80 __extended; // <-- this line is magic typedef __extended extended; I really remembered why I dropped developping on Macs as soon as I started
  15. That was not a small way, I thought I was getting crazy. I should be able to test most of the pieces together tomorrow on the real hardware for a proof of concept... Fingers crossed!
  16. This is awesome! I was going to try the _Write method (as InsideMac says: "StartSound Call Write with ioRefNum=-4, ioBuffer=synthRec, ioReqCount=numBytes" ), but you beat me to it. Going to check this right now and will report the results. I owe you a lot.
  17. No, I am not running under MultiFinder. I looked at other ideas to get A5, but found none. > You are calling StartSound at interrupt time. Inside Mac lists StartSound as possibly moving or purging memory, are you sure this is OK to do? Well, this is what Inside Mac vol II, page 231 says on StartSound: "You may want the completion routine to start the next sound when one sound finishes, but beware: Completion routines are executed at the interrupt level and must preserve all registers other than AO, A l , and D0-D2." Adding that the May198
  18. Hi, For a current project (mmm, what could that be?), I need to play continous digital sound on a MacPlus, with an old system (6.0.8 right now). I tried the SoundManager routines, with little success, so I ended up with the real vintage StartSound(), below. C Code, "works" on THINK C 5, should loop sound until mouse clicked. However, it only plays 2 samples and stops sound. It is driving me crazy. Any idea? #include <Sound.h> #define SAMPLES (370*50L) FFSynthPtr snd; pascal void MyStartSound() { asm {
  19. Ok. Worked on compression, as I need to attain a higher frame rate to have a chance to get sound (flims are slowed down today from 24 to 21fps, which won't be ok for sound), and I also need more space to store the sounds, and I need more CPU to actually play the sound. So, compression is the first step, the big unknown is the CPU cost of decompression which may eat all the savings... So, not sure if this will work at the end, but that is the kind of image degradation we get with compression: uncompressed: average compression (expected savings ~30%):
  20. Wooow. The way I am moving the files is by mounting a SCSI2SD SD card on my linux system and mounting the first partition as a .dsk in minivmac. From there, transferring is trivial, using ImportF1. I did had to fight when I reformatted my Lisa, due to the 532 bytes blocks and some disk not having the tags. I am a n00b as far as Lisa goes, it took me forever to re-install mine, and I am very worried that my internal Widget may fail on me. > check out some of the other emulators for Apple parallel port hard drives, like X/ProFile and IDEfile IDEfile can't b
  21. Ok, other people asked for it, so I give up: You can get the flim from http://www.macflim.com/#badapple ...
  22. @stepleton Are you me? I mean, first you are awesome! Second, I have a Lisa 2 here, and running MacFlim it on it was one of my goals -- unfortunately, I need the internal floppy drive to boot the Mac environment, and I don't know how to connect both the FloppyEmu in HD20 mode and the floppy. I was looking into it yesterday, but you did beat me to it! That profile hard drive emulator is *exactly* what I need. Who do I need to kill to get my hands on one? Third, rickroll is *the* video I used a lot for debugging (first was Star Wars, then Adrian Di
  23. Rejoice: https://github.com/fstark/macflim MIT Licensed. Contains only the linux-based encoder for now. Appreciate all feedback, success and/or horror stories. Have fun!
  24. If you have a plus, this is all you are going to get currently. I get 21fps on a SE/30, and 10 fps on a plus, with a SCSI2SD 5.2. I guess a SCSI2SD 6 may get a bit more, but on the plus I would be surprised if we can get anything betterwith the current approach.
×
×
  • Create New...