This page is a wiki. Please login or create an account to begin editing.


297 posts / 0 new
Last post

Comments

Lauri's picture
Offline
Joined: 2020 Sep 4

No, I haven't heard from him for ages. After ARDI, he went on to found a new company "Stolen bases" ... how that did work out, I do not know. Did you ever talk to him? The way he expressed himself was unusual. He was verbose, polite, humorous and very clever. I have a warm spot in my heart for him.

Btw, M, I remember the first time I talked to you in 2000. I had just taken down the HFVExplorer page because of the lawsuit, and you sent me an email to ask me why! Haha! I restored the page soon afterwards, a good thing that this issue was resolved and Symicron lost the case in court. Maybe there is some justice in this world after all.

Lauri

watchsmart's picture
Offline
Watcher
Joined: 2009 Apr 10

Yeah, "Stolen Basis" was one of the early iPhone app developers. He had an app called "Wish you were here" which seemed kind of neat at the time - https://www.cultofmac.com/10067/wish-you-were-here-send-real-postcards-f...

It got bought out by a big company. I hope he made a lot of money from that.

Meanwhile, if you are curious, you can find Darek Mihocka on Facebook nowadays. He seems to have mellowed out a bit. I actually communicated with him a couple of years ago.

Lauri's picture
Offline
Joined: 2020 Sep 4

Btw, this was also an example of his humour; a "stolen base" is a baseball term Smile

Many stories could be written about Darek. I never had any conflicts with him, our discussions were civilized, but he butted heads with so many people.

Lauri

watchsmart's picture
Offline
Watcher
Joined: 2009 Apr 10

Oh... I would have been in high school when I sent that message to you in 2000. Go figure.

Lauri's picture
Offline
Joined: 2020 Sep 4

Never mind, I thought that you were Mike Smile It is so small world! Haha

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

We talked about QuarkXPress before. It made me remember the days when the version 3.something came out ... it was a disappointment for us since it did not ship with a hyphenation & justification module for the Finnsh language even though the previous version did. The reason was unknown. Anyway, our local customers wanted and needed it.

I had already made Xtensions for Quark and knew it inside out. I disassembled the new version and made a new h&j Xtension with a twist: it patched the memory image of the main program, some functions now called our own h&j.

It was a legally grey area, maybe even illegal and definitely against the licencing agreement. We had never any trouble though, and Quark Inc also benefited from it: it made some more software sales, so I feel that I helped them, too. Win-win. In any case, so many years has passed that I can talk about this, the "crime" can no longer be prosecuted Smile

Quark made another, far more serious mistake by overpricing their software, leaving the door wide open for Adobe to attack with InDesign. People were also generally not satisfied with the speed Quark was trying to keep up with the changing times. Tables were eventually turned. We didn't care, now I wrote InDesign plug-ins as well, and at some later point in time, we stopped supporting new Quark versions because of the diminished user base. Now it's already 7 years since I even launched either of the programs Smile

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Lauri, I am really enjoying these posts of yours. Thank you for every one of them.

I too had my QuarkXPress v4 moment (of displeasure) when I discovered it wouldn't run properly in build 142!

But I preferred using QXP v3.32 anyway as it turned out, so it didn't matter in the end

I wrote a bit more about that experience back over here, if you didn't see that post Smile

Lauri's picture
Offline
Joined: 2020 Sep 4

Thanks Mike! Yes I saw that post, amusing Smile

As I mentioned earlier, HFVexplorer started as a learning project, it was evident that I soon needed to write MFC code at work. So I wrote some tester programs to interface with emulators, extract icons from HFS volumes, create Windows shortcuts ... and learned enough MFC while having fun at the same time Smile

Looking at the source code, it is obvious that this was not professional quality work! And there is more, it is confusing that it uses two distinct implementations of HFS routines! Sounds quite ridiculous, right? The reason for this is that the application started as a launch-pad for several emulators. I wrote my own read-only HFS implementation to do that. But then people got more interested about HFVE and I realized that it would be cool to have a writing ability as well. At that time, I didn't have enough time to write a full-blown HFS layer, so I decided to use the "HFS utils" package written by Robert Leslie. Alas, I didn't dare to change some parts of the program, so this HFS*2 anomaly remains ... until someone wants to fix it! Haha!

The source code was under GPL, but it was "by request" back then, as per GPL rules. Why? Because I was not sure at all that there was not some catastrophic bug lurking inside the code and wanted to be able to contact the downloaders immediately if one was ever found.

At that time, "by request" caused no problems; but after I stopped distributing it and my email address changed, some people could not get the code -- so I have heard. Sorry about that, now it should be available somewhere at www.emaculation.com. I also temporarily lost the code, but found it again.

I described the irritating lawsuit already elsewhere.

As a side note, HFVE may very well be my most widely used freeware project; and the second-most widely distributed, after a patch I made to Linux etc. pppd, the point-to-point protocol daemon. I once needed my Linux box to connect to Win95 computers, so a small change in "chap_ms.c" was needed, a LANManager type password response to MS-CHAP challenges. Nobody had done this before because it was only possible by knowing the secret key hidden inside Microsoft software ... I took it from rasapi32.dll. It was/is surely not widely used at all, but present in surprisingly many computers Smile

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

Series of interesting email exchanges, nro 0007:

When Christian at the end of the year 2000 decided to make SheepShaver open source, the following exchange happened in the Basilisk II Development Mailing List. He was pondering how it should be named. I decided not to "snip" those technical details below, they may interest technically-minded people. For me however, this story is memorable because of the amusing discussion about how to name the program Smile All this text could still be publicly readable in the dev-list archives somewhere:

---------------------------------------------------------------------------------------

CHRISTIAN:

To: Basilisk II Development List
Subject: [B2-devel] B2+SS=?
From: Christian Bauer
Date: Wed, 29 Nov 2000 19:17:51 +0100
Hi!

Because of the stagnant state of BeOS/ppc, the superiority of open sourced
software, and the success of Basilisk II, Marc Hellwig and I (actually just
me because Marc left the decision to me) have decided to make SheepShaver
open source, too.

The internal structure of both programs (B2 and SS) is quite similar (because
B2 was modelled after SS) and in fact, the only difference for many source
files is just the copyright header. With a little more work, I think that
about 80% of the source files could be shared between both projects.

The logical conclusion is thus to merge both projects in some way. The most
extreme (but probably possible) way would be to put both 68k and PPC Mac
emulation into one program. Which CPU architecture will be emulated is then
decided by the type of ROM being used. A couple of thoughts about this:

 1. The most important issue to be resolved is of course: how should this
    combined emulator be named? Smile
    "Basilisk III" sounds a bit boring and is also not completely accurate
    since Basilisk II was named this way because it (originally) emulated
    a Mac II class machine, not so much because it was the successor to the
    original "Basilisk". I also like the "SheepShaver" name.
 2. SheepShaver only has native PowerPC support. There is no PowerPC emulation
    for other systems yet (I've started with a simple interpreter but this
    would need a lot more work to be usable, let alone efficient enough).
 3. Some things need a little rearranging. We would now be concerned with
    3 different configurations:
     - native 68k, emulated PPC (possible, but probably too slow to make
       much sense)
     - emulated 68k (could use 68k emulation from MacOS ROM), native PPC
     - emulated 68k, emulated PPC
 4. Because there is only one set of MacOS memory access functions, it is
    necessary for the emulator to run in the same addressing mode, whether
    a 68k or a PPC Mac is to be emulated. Luckily, 68k and PPC have the same
    endianness and alignment restrictions. So on a native 68k machine, the
    PPC emulation will have to run in real addressing mode, which is possible
    (likewise for a native PPC machine).
 5. The memory access subsystem will have to be separated from the CPU
    emulation (currently the memory access is from UAE's 68k emulator) to
    make it possible for 68k and PPC emulation to use the same memory module.
 6. Due to the way SheepShaver works, it needs 12k of Low Memory globals
    (instead of 8k as B2, or 10k as a real PowerMac). But this shouldn't be
    a problem.
 7. Because SheepShaver was designed for PPC systems, there are many places
    where it more or less directly jumps into MacOS code. These places will
    have to be rewritten carefully.
 8. This especially affects the SheepShaver Ethernet driver which is
    completely different from the B2 one. It is a proper DLPI module for
    Open Transport and as such calls many OT functions for message and
    queue management, and it also requires OT headers which cannot be
    included in a source release.
9. Video mode selection is also different because SheepShaver provides
    run-time mode and depth switching (there is a nice and clean interface
    for PCI video drivers for doing this). But with some clever redesign,
    this should provide the 68k emulation with mode/depth switching, too.

In any case, I would like to have at least one more stable release of
Basilisk II (with JIT) before starting with this (probably not this year
any more).

Bye,
Christian

---------------------------------------------------------------------------------------

LAURI (OBVIOUSLY EXCITED):

On Wed, 29 Nov 2000 19:17:51 +0100, cbauer@student.physik.uni-mainz.de
wrote:

>Hi!
>
>Because of the stagnant state of BeOS/ppc, the superiority of open sourced
>software, and the success of Basilisk II, Marc Hellwig and I (actually just
>me because Marc left the decision to me) have decided to make SheepShaver
>open source, too.

Wow! Thank you on behalf of the open source community.

> 1. The most important issue to be resolved is of course: how should this
>    combined emulator be named? Smile
>    "Basilisk III" sounds a bit boring and is also not completely accurate
>    since Basilisk II was named this way because it (originally) emulated
>    a Mac II class machine, not so much because it was the successor to the
>    original "Basilisk". I also like the "SheepShaver" name.

Forgetting all healthy self-criticism, just brainstorming:

SheepShearer
SheepSaviour
SheepHerder
SheepSorter
SheepDog
SheepShaver++
Shepherd
SharpShooter
Nomad (they keep sheeps)
Antilope (fast and beautiful)
Jabberwocky (powerful)
Nebula
Constellation
Seahorse
Bearhunter
Whirlpool
Raincoat (as Macintosh)
Orwell
MODEM (MODular EMulator)
Miranda (I just happen to like that name; but there is already a programming language w/ the same name)
But Basilisk III is great too; the word "basilisk" tends to stirr positive associations:
  - the animal is sympathetic unlike some other reptiles
  - some species can walk on the water (making "impossible" true)
  - Basilisk, Basilisk II.

> 2. SheepShaver only has native PowerPC support. There is no PowerPC emulation
>    for other systems yet (I've started with a simple interpreter but this
>    would need a lot more work to be usable, let alone efficient enough).

If needed, I would be glad to help with the interpreter.
Given the speed that the hardware keeps evolving, I think that
an interpretive solution might be eventually usable.

And I think I know someone on this list who has an excellent track record
concerning JIT cores Smile [I was referring to Gwenolé, of course]

Regarding the rest of the list: what parts do you feel that could be
delegated to other people, to ease your "burden"? Clearly some
items are beyond at least my knowledge.

>Bye,
>Christian

---------------------------------------------------------------------------------------

CHRISTIAN (OBVIOUSLY AMUSED):

Hi!

On Thu, Nov 30, 2000 at 01:02:40AM +0200, Lauri Pesonen wrote:

> [lots of names]
> But Basilisk III is great too; the word "basilisk" tends to stirr
> positive associations:

The associations are probably not so positive amongst D&D players. Smile

>   - Basilisk, Basilisk II.

Maybe I should just drop the "II" and revert to plain "Basilisk".

> Regarding the rest of the list: what parts do you feel that could be
> delegated to other people, to ease your "burden"?

The PPC CPU emulation and the rewriting are probably the most "delegatable"
items. Everything else is mainly small changes in a lot of places.

Bye,
Christian

---------------------------------------------------------------------------------------

... so apparently at that point I thought that I would help with the PPC core Smile But it so happened that I drifted away due to a horrific amount of work and other priorities. Luckily there was Gwenolé! He did better job than I could ever have, for sure.

And of course, the name remained the same, SheepShaver; none of my wonderful suggestions was good enough. How curious! Haha!

Lauri

IIGS_User's picture
Offline
Joined: 2009 Apr 8

I like the name "Antilope" for this purpose.

24bit's picture
Offline
Joined: 2010 Nov 19

Such an bodacious idea, an all in one Mac emulator with a new memory sub-system choosing the type of emulation by the Mac ROM thrown at it. Even a MMU might have been possible.
Thanks for sharing your memories!
Did there ever exist some sort of pre-Antilope emulator?

Lauri's picture
Offline
Joined: 2020 Sep 4

Yes, 'Antilope' has a nice ring to it -- using ''i' sounds so modern Smile Like iPhone, i-anything nowadays. (but as far as I know, blackbucks or the Indian antelopes are the only 'antilopes', the common 'antelope'' covers many species).

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

Series of interesting email exchanges, nro 0008:

It is widely known that I'm an expert in many things. For example, embarassing myself. Here's a perfect example:

When Escape Velocity Nova (EVN) was released on March 2002, I had already drifted away from Basilisk II development and under tremendous pressure at work. It seemed that even days and nights combined were not enough -- we had our own company and it was a do-or-die situation. Well, luckily we did not die, but it took the maximum effort from all of us.

The "Escape Velocity" series was -- and I guess still is -- immensely popular. Ambrosia Software chose to release it as a fat binary, containing both PPC and 68k versions, so it was in theory capable of running in Basilisk II, too.

But it did not. Ambrosia chose to be fancy; the start-up sequence used fade-in and fade-out effects -- using so called gamma tables to dim the Mac screen. Fine, but B2 did not support them yet -- or so I thought!

At first, it was not obvious to all users that EVN could even run on a 68k because there was confusing information on their web site. But as more and more people realized that, the more my email box was filled with "desperate" requests! Haha! And I could not resist.

So, I wrote a quick "EVN gamma ramp patch", Basilisk II for Windows build 143. Implementation for the gamma tables needed changes in both the B2 core and the Windows code. And I wrote it without bothering to ask anybody whether this was already implemented. Well, what is your guess -- was it done before or was it not? Smile

I uploaded the patch -- only binaries -- to my site and also dropped a note to the basilisk-devel mailing list, in the hope that the code could be useful to others as well. I had not read the list for awhile, nor any other list that was not related to my work.

------------------------------------------------------------------------------------

LAURI, PROUD OF THIS SUPERIOR ACCOMPLISHMENT AND GLAD THAT HE CAN NOW CONTINUE WITH OTHER WORK:

To: basilisk-devel@lists.sourceforge.net
Subject: [B2-devel] Escape Velocity Nova: gamma ramp patch
From: lauri.pesonen@anygraaf.fi
Date: Fri, 29 Mar 2002 17:21:25 +0200

Hello,

Here's a patch which implements VideoDriverStatus/cscGetGamma
and VideoDriverControl/cscSetGamma. These are needed to run
Escape Velocity Nova which came out some time ago.

If there is no obvious way to set gamma ramps on your
platform, just fill the gamma data with a linear ramp
and return noErr in cscGetGamma:

for( int i=0; i<256; i++ ) red[i] = green[i] = blue[i] = (uint8)i;

That is enough to make Nova happy, naturally without fade
effects of course.

Source code (based on very old sources):
http://gamma.nic.fi/~lpesonen/BasiliskII/recent/build143_EVN_patch_src.zip

Win32 binary:
http://gamma.nic.fi/~lpesonen/BasiliskII/recent/build143_EVN_patch.zip

Regards,
Lauri

------------------------------------------------------------------------------------

CHRISTIAN:

Hi!

On Fri, Mar 29, 2002 at 05:21:25PM +0200, lauri.pesonen@anygraaf.fi wrote:
> Here's a patch which implements VideoDriverStatus/cscGetGamma
> and VideoDriverControl/cscSetGamma.

Gamma tables have been implemented 9 months ago. Methinks you should
update to the latest CVS sources.

Welcome back, BTW. Smile

Bye,
Christian

------------------------------------------------------------------------------------

LAURI, BLUSHING:

>Gamma tables have been implemented 9 months ago.

Oops, sorry...

>Methinks you should update to the latest CVS sources.

You're right of course -- and I will sooner or later.
Actually I have rather recent CVS files, but haven't really
looked into them much. As you have probably guessed I haven't had
too much time to work with B2 currently, I did this patch only as a
quick self-defense to cut down the incoming B2/EVN email request
flow. I was *quite* sure that gamma was not implemented Smile

>Welcome back, BTW. Smile

Thanks Smile

------------------------------------------------------------------------------------

CHRISTIAN:

Hi!

> >Gamma tables have been implemented 9 months ago.
>
> Oops, sorry...

And we even have run-time resolution/depth switching now! Smile

Bye,
Christian

------------------------------------------------------------------------------------

So a stupid mistake -- I should have asked. But it was nothing serious, of course. Life went on Smile Sadly, I never continued with B2 even though I intended. I'm a bit sorry about that.

Lauri

Elyus's picture
Offline
Joined: 2009 Aug 9

Lauri, thank you for sharing these very entertaining anecdotes! I've enjoyed reading them very much.

I think it's especially funny and coincidental to see you mention the gamma ramp patch since the setGamma function has continued to cause consternation for the Mac emulation community even to today. Smile

In the case of BasiliskII and SheepShaver, although the gammaramp code was added long ago, just a few months after the email you shared, the functionality was accidentally disabled. I assume someone was debugging and forgot about the change, but they'd added a "return paramErr" right at the beginning of setGamma. That line remained in the source code for over a decade! It wasn't until a bunch of us at Emaculation were trying to get EV:Nova and Ferazel's Wand running that we found the code was there all along!

In fact, recently a contributor kindly finished the setGamma implementation by passing the settings through SDL2 to the host display, which led to a discussion just this afternoon about the feature. And yesterday, a fellow emulator enthusiast mentioned to me out-of-the-blue that they're having to patch Ambrosia game binaries by hand to not call gamma fades since the implementation is still missing in Qemu.

Thank you for indulging my own little anecdotes, but I was too amused by seeing your story at the level of nuisance this seemingly small feature has caused. I guess I've learned that every emulator should implement gamma tables first and then do everything else! Big smile

adespoton's picture
Offline
Joined: 2015 Feb 15

Hah... and on top of that...
https://mace.software/news/ -- MACE just got EV working in their wrapper in the last few weeks too. This of course means that if they make the wrapper public like they did with earlier versions, people can now play EV on a modern OS without having to run Mac OS under emulation to do so. It'll just launch like a regular app!

Of course, emaculation discussion regarding gamma is exposing some odd behaviour when the guest OS doesn't handle the gamma tables correctly (I'm looking at you, Mac OS 7.5.5).

Everything old is new again.

Elyus's picture
Offline
Joined: 2009 Aug 9

Yes, MACE is an exciting project! A lot of people who don't want to deal with emulators can benefit from it. I do hope they choose to open source it in the future. I've not seen any details about source code or licensing as yet, but from an archival perspective, it'd be great to see implementation details.

Lauri's picture
Offline
Joined: 2020 Sep 4

I have been wondering who you really are, adespoton Smile You said previously that back then you were present in the vMac-dev mailing list ... I'm scratching my head ... one more hint, please? Haha!

Lauri

adespoton's picture
Offline
Joined: 2015 Feb 15

Laughing out loud I've kept myself pretty private for years, even back then. I wasn't active on the list, just a subscriber, although I did send a few bits of feedback IIRC. Same goes for BII-dev.

So it's more a case of "what pseudonym did I go by back then, and what throwaway email address?" I stopped using my real name online around 1994.

Lauri's picture
Offline
Joined: 2020 Sep 4

Thanks Elyus!

>> In the case of BasiliskII and SheepShaver, although the gammaramp code was added long ago, just a few months after the email you shared, the functionality was accidentally disabled. I assume someone was debugging and forgot about the change, but they'd added a "return paramErr" right at the beginning of setGamma. That line remained in the source code for over a decade! It wasn't until a bunch of us at Emaculation were trying to get EV:Nova and Ferazel's Wand running that we found the code was there all along!

Wow, it is strange that nobody complained -- or did they? There was really an enormous initial interest in running Nova under B2 Windows port! Maybe those people were satisfied with having already some version of B2 to run it with. Hm, I just checked Wikipedia: a Windows version of EVN was released on July 11, 2003. That could explain part of it.

You discussed about this this afternoon?! -- wow again! Small world phenomenon once again Smile

>> Thank you for indulging my own little anecdotes, but I was too amused by seeing your story at the level of nuisance this seemingly small feature has caused.

Related stories are of course most welcome, thank you!

>> I guess I've learned that every emulator should implement gamma tables first and then do everything else!

Let's write this advice down in the first chapter of the upcoming best-seller book "How to write an emulator for dummies" Smile

And in retrospect, maybe I should not have written that "gamma ramp patch" at all. Or at least made it so that it just ignored the gamma commands. I have later read some comments that at least in some cases it left the user's gamma values in a different state than they were before ... not good. But it is so easy to be a Monday morning quarterback, even when thinking about what I did myself, let alone others doings!

Just before posting this, I also read the comment Adespoton made ... indeed, MACE is really interesting, Executor on steroids Smile

Lauri

Elyus's picture
Offline
Joined: 2009 Aug 9

I think a lot of Windows users continue to rely on Builds 142 and 143 as their main BasiliskII! You implemented a lot of great features which are sadly still missing in current SDL branches.

The Windows release of EV: Nova did bring in a lot of new players and helped cement Escape Velocity as Ambrosia's most successful series. Over time, they'd released EV: Nova for 68k, PPC, PPC and Intel OS X, and Windows. Pretty impressive, especially considering it only stopped working with the latest Mac OS Catalina and removal of 32-bit apps.

Lauri's picture
Offline
Joined: 2020 Sep 4

Hey, now that you mentioned those "extra" features, one thing came to my mind that was always curious to me; I don't remember people in the forums back then ever talking about the mount modes. They were on the "Disk" tab of the old BasiliskGUI. I thought that it would be a very well-received feature, because it was for me! Selecting for example an "undoable" mount mode, I could undo any changes to an HVF partition image if the program crashed, preventing the possibility of any corruption. The GUI had a help button, too, to describe what different modes did.

Maybe it was so that I didn't "advertise" the feature as much as I should have. Probably I only wrote some terse description in the release notes? Anyway, even now when I occasionally launch the old 142 to play some game, I have very carefully selected mount modes. I don't need to backup the HFV volume files by doing so. I wonder if anybody else is using those modes?

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

And by the way, I made an error before. The link I posted to an article and a picture of Christian Bauer: yes it was a man with the same name; yes he was a nuclear physicist too; and about the same age, and a bit of a resemblance -- but that's not him. I contacted Christian, and he categorically denied to be the man in the picture! Haha!

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

About other freeware programs I once wrote ...

There was a helper program, "HPBurner", which was able to write CD image files -- including HFV files even though they were only partition images -- to CDR and CDRW. It worked quite well, and I think that it was somehow even integrated to HFVE. The funny thing was that although it was not that difficult to implement it ... but when I wanted to expand it beyond HP devices, I got a rude awakening: how to write to other devices of different manufacturers was not standardized at all. It was a Wild West. I contacted two manufacturers (which I do not name here) and the answers were the same: I would have to sign an NDA (Non-Disclosure Agreement) to get that basic information what codes to use!

I wonder how this is nowadays, does anybody know?

Well, what a bummer, I won't sign NDA's for freeware projects. So that was pretty much the end of the HPBurner, and I soon stopped distributing it. I'm sure that there are some ways around this, but at that time, I could not figure them out with the limited time I had. Why on earth they did this is beyond me.

Btw, when writing this, I had to google whether it is correct to say "standardised" or "standardized" and I still don't know what is the correct spelling. And those small critters, on, off, to, in, at, about ... Why did your ancestors made your language so difficult, we should all be speaking Finnish, it's so easy Smile Haha!

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Hi Lauri, "standardised" or "standardized" depends on who's English speaking country you reside in (or not) Wink

Words ending in "ised" would follow a UK English spelling form, words ending in "ized" a US form. For me, I grew up under UK English spelling rules but I tend to use a lot of US English spelling here. I'm not sure why, maybe it's because my spelling checker in this browser is US English and I'm just too lazy to change it. It's telling me "standardised" is "incorrect" even tho' I know it's perfectly fine UK English. I see that you settled on the US version.

CD Image files. I sometimes use HFVE to create custom HFS ISO images, up to 2GB or less. Tho' I more often use Disk Copy 6.3 for the same reason on classic Mac hardware, when creating ISO images under 2GB. As long as the image sizes are created using multiples of 512kb (I use multiples of 1024kb as it's easier for me to judge the size I'm needing) then the resulting image is always ISO 9660 compliant. I can fill up the image with files in Basilisk II (or via HFVE, but additionally mount it in B2 or Mini vMac to rebuild it's desktop database files). When finished, exit, change the .hfv suffix to .iso and then burn it in my favorite (<-- US spelling ) Windows burner, ImgBurn. - Sweet Smile

Lauri's picture
Offline
Joined: 2020 Sep 4

I thought that you lived at least now in Australia? If so, please tell me, is the saying "down under" derogatory? I seem to remember that some people were offended hearing or seeing that.

Yes this is off-topic, but who cares, let's get back to the topic after these extremely important linguistic issues have been resolved! Smile

And yes, there are actually quite many ways one can use to burn Mac cd's under Windows. I haven't done that in a while and "ImgBurn" was new to me, I'll try to keep it in mind in case I will someday need to do it, thanks!

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Hi Lauri. Yes, I am living in Australia and it's not to my knowledge that the term "down under" is derogatory or no-longer used as a nickname for this country's location on the globe. But hey, I don't get out much, so maybe I'm missing out on latest trends. Myself, I favour the term "Antipodes" for my locale, as I stem from New Zealand originally Wink

Lauri's picture
Offline
Joined: 2020 Sep 4

And btw, now that we are talking about linguistics ... I'm scanning through old emails, this is a small sample of how people misspelled "Basilisk II", the list would continue but I got tired:)
Upper/lower case differences ignored ...

Basilisk II
Basilisk 2
Basilisk
BasiliskII
Basiliski
Basilik II
Basilis II
BaseliskII
Basilsik II
Basillsik II
B2
Basilisk2
Balinski
Balinski II
Brasilisk (interestingly, the guy was a Brazilian!)
Basalisk
Basalisk 2
Basallisk
BasII
Bas 2

I could write almost as long list how my full name was misspelled Smile

Laurii

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

I'm guilty in the overuse of typing "B2" Tired

Actually, I'd quite like B2 as a potential "new name" should the project ever become reinvigorated.

- Easy to pronounce, quick to type, and hard to misspell Wink

24bit's picture
Offline
Joined: 2010 Nov 19

As a lazy guy I´m guilty of using B II too - not so much for B2.
Not that I feared of getting it confused with B-2 (Northorp-Grumman) Smile

Lets hope B-2 will stay in their hangars instead of being assigned to the South Chinese Sea.

cbone's picture
Online
Joined: 2011 Sep 17

I tend to abbreviate it to BII as well, favoring the roman numeral-touch that gives it the Macintosh II-series classic feel – the ci and fx being my old-time favorites – followed by its next iteration, the Q700 Wink

adespoton's picture
Offline
Joined: 2015 Feb 15

If anyone ever does combine BII and SS, it should be renamed STP Laughing out loud

*STP was the codename for the 68040 to PPC upgrade card. Then we just need to backronym it.

Lauri's picture
Offline
Joined: 2020 Sep 4

Another thing that I wondered back then ... those of you who have delved into B2 source code might have noticed that the emulation begins at ROMBaseMac+0x2a. Does this ring a bell to anybody else but me?

Note that:

a) 0x2a = 42 decimal ...
b) the original Mac Team was very well known for pranks and Easter eggs ...
c) according to the Hitchhiker's Guide to the Galaxy which was already famous back in 1984, "The Answer to the Ultimate Question of Life, The Universe, and Everything" was indeed "42".

... so, what's the verdict, was this a joke and a deliberately chosen offset Smile

Lauri

adespoton's picture
Offline
Joined: 2015 Feb 15

I'm pretty sure 42 was deliberately chosen. The Mac dev team were fans of Douglas Adams, and Adams was an outspoken fan of Apple. And, as in the book, figuring out that it all starts at 42 is only the first half of the problem. Then you need to build a second computer to figure out the question. I figured that was Jobs' schtick with NeXT....

cbone's picture
Online
Joined: 2011 Sep 17

It sure sounds like an Easter egg joke to me, Lauri Wink

Lauri's picture
Offline
Joined: 2020 Sep 4

Yeah, I tried to google about this but found nothing so far. Somehow it sounded very much like Andy Hertzfeld's doings, it would have been typical for him! But he left Apple already in March 1984 to invent those strange early smartphone things at General Magic and other stuff. And this code I mentioned was a Mac II entry point, I don't remember how it was in 128k/fat mac/plus and I'm too lazy to check it out. Well, there sure was a lot of other good "old" jokers as well in the Mac team Smile

A few years back, Andy maintained some kind of forum and told stories about those early Mac days. He was very active and would surely answer and tell the story if I would find the url Smile

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Anything in here, Lauri ? Folklore.org

A note about Folklore.org: "The code behind the Folklore website is a set of scripts written in Python by Andy Hertzfeld. Susan Kare helped with lots of images and the overall look of the site."

Lauri's picture
Offline
Joined: 2020 Sep 4

Thanks! That's the one. I will ask him, I hope that he is still around. Haha!

[Edit #1: ok, I tweeted him. I have never done this before, I created an account just for that. I hope that the message was delivered. Let's see what happens.]
[Edit #2: My tweet was obviously not delivered. I think that I will delete the Twitter account, I have no use for that. I dropped a note to Susan Kare, no reply so far. But I got Andy's email address from Bill Atkinson and asked Andy, let's see.]

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

One of the hardest parts of my contributions to B2 was to fix the FPU. It was initially written by a man named Herman ten Brugge, for the UAE. I have nothing but respect for him -- but the FPU code was, sad to say, very buggy. I spent countless nights trying to fix it, and eventually rewrote it in assembler to get those NaN's, infinities and re-normalizations finally working -- it was the only way when using my pitiful Microsoft compiler. Gwenolé later ported this code to a more senseful NASM assembler syntax to be used in the Linux x86 version. I don't know what the situation is nowadays. Probably something more advanced.

For example, I remember the OS8 "scrollbar bug" ... although we got OS8 finally booting up, trying to use scrollbars in the Finder was impossible, the bars just got stuck. Before I got it fixed by rewriting the renormalization in asm, the workaround was to replace the Finder with the OS 7.6 version! Or alternatively, to disable the FPU. But disabling the FPU was not possible for the people who had ROM images requiring that the FPU was present, for example Mac II fx. And yes, there actually were people who respected Apple's copyrights -- I never participated in those ROM flame wars in any way Smile

The other day I stumbled on a comparison of the FPU's of the emulators, this is dated 2013. See this, about half-way down the page:

http://geocities.ws/d/a/daedheadap9/2013/emu-tests.htm
-----------------------------------------------------------------------------------------------------------------
-Bitfield comprehensive (updated 2013.12.20)

Results from different Mac OS emulators:

BFEXTU $12345678{8:0} test (should be $34567812)

The older UAE (Basilisk II, some of the Mini vMac code) incorrectly uses a left shift and always reads 5 bytes, writes 4 or 5. This was corrected in later versions of UAE.

Emulator | Return Value | Comment

Fusion: $34567800
SoftMac: $00345678 Unusual method (clipped) Darek’s Gemulator src here
BasiliskII: $34567800
Mini vMac: $34567800 Bugs reported, fixed (v3.3.3)
MAME/MESS: $34567812 Better/correct 68020 r/w
qemu-1.7.0 (not handled)
Executor 2.1 $34567812 Passes all singlemath tests

The disassembler provided in qemu covers all 68KMotorola relatives, but execution is quite limited. QEMU has PPC emulation (but for Linux, not Mac).
-----------------------------------------------------------------------------------------------------------------

... this guy, whoever he is, apparently spent a lot of time comparing the emulators! Inspired by this discovery, I just checked the definition of the BFEXTU instruction in the Motorola manual, near the page 146:

https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf

No wonder that most people got it wrong, it is not a very good description. This is like reading an alien language -- I had to push my aching old brain to the limits to make any sense of that text. Most remarkably, I see no mention that the data should actually be rotated instead of shifted. Maybe this vital information is there somewhere, hidden by the technical jargon, but I fail to see it! Haha!

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

Let's talk about Darek, he was a very interesting person!

I won't get into details about his conflicts with other people -- that is none of my business.

I first "met" him when PC, or Philip Cummings, the leader of the vMac team, invited him to join the vMac development list. There were plans to co-operation of vMac and Gemulator. Darek offered his fast emulation core for x86 as a DLL; in return he wanted help with implementing Mac II video code, details about Nubus based Mac II video card or something like that. The discussions were in part fruitful, in part a bit heated. Some people didn't like the idea of co-operation at all, I'm not quite sure why. In the end, Weston implemented support for reading the ROM card of the Gemulator in the Windows version of vMac.

Among other things, he told things how to make emulators faster. One of them was how to speed up the screen updates -- the same thing that I had already implemented in the B2 Windows port and that Gwenolé later adopted as VOSF in the later B2 versions. (VOSF = Video On Segmentation Fault; in Windows port, it was handled by "Screen_fault_proc") The screen did not need to be drawn all the time. Using page faults, it was possible to keep track of the memory pages that were changed and draw only those. This was actually the same technique that full-screen MS-DOS prompt in Windows used to virtualize the VGA card memory.

He also described his method of reversing the address space so that no memory swap operations were needed -- Motorola used the big-endian and Intel the little-endian byte order. That was clever, never occurred to me before! I wrote some testers but decided not to use it after all. I don't remember why, perhaps I just ran out of time. I also seem to remember that Christian used a bit similar but still different idea in ShapeShifter video driver: it decremented the Mac frame buffer address by 1 to perform xRGB to RGBx conversion for some Amiga graphics card. The penalty was that the accesses were unaligned, but it was still much faster than copying the whole frame buffer.

There were two cases where one needed linear addressing, the video buffer and the disk I/O. Those could be handled by writing for example a custom made memcpy() routine for video which did a backward copy -- the source pointer was incremented while the destination pointer was decremented. Ditto for I/O, reversing the memory in-place before and after the i/o reads and writes. And at that time, accessing RAM was always faster than accessing the video memory!

In those days, everybody was very concerned about the emulation speed! The hardware was evolving all the time and it was actually only a waiting game -- but I also fell victim to this optimization business. That was one of the reasons I rewrote the B2 CPU in assembler, another one was to make the FPU finally work ... maybe I should not have done that. It is kind of interesting that the code still works 20 years later ... and even compiles.

Darek was very fluent in assembler and had a strict opinion that the emulation core should not be written in anything but asm. It was interesting to listen to the vMac-dev list discussions ... but early in April 1999 my nic.fi email address expired. I dropped a note saying that could someone please update my subscription to point to my new clinet.fi email address .. but nothing happened and I was dropped off the list. I didn't care, I was already involved in porting Basilisk II and vMac was clearly dying anyway.

In June 1999, Darek wanted to do a comparison (for speed, of course!) with all the emulators and emailed me for instructions on how to compile the B2 Windows port with Visual C++ 6.0. I provided them, and meanwhile we discussed other things. He was quite open about the things he was doing to speed up his product. When I mentioned the VOSF method, he said that he had used that technique in Gemulator already since 1995. I had thought that I had invented something original! Haha! He also told me about the brand new "write watch" mechanism that was now implemented in Windows; or actually it was there even before that, but now the API was exposed to the developers. I took advantage of it later on.

It was in his interest to advise how to make Basilisk II as fast as possible, in order to make Fusion look worse -- he was in a direct conflict with Jim Drew, the main author of Fusion Mac II emulator. Darek could not understand how some people still wrote programs for DOS instead of Windows and claimed that there was a speed advantage for DOS programs! I also knew that it was a misguided notion. However, unlike Basilisk II and Gemulator, Fusion was a DOS program and had the benefit of being able to access the page table dirty bits directly (which is why Fusion was "DOS only" and could not run under Windows except in Win9x DOS prompt. I don't remember whether there was a "true" Windows version of Fusion later on, maybe there was; and was it or was it not significantly slower because of this.

During this time, the summer of 1999, I was quite busy fixing bugs in our new InDesign plug-ins -- the Quark-killer from Adobe which was due to be out soon. But I still had time to study all of these things.

Darek told me that VC5 implemented many Pentium and code size optimizations that were necessary to make Microsoft Office smaller and faster. Prior to doing his Mac emulator, he spent 8 years at Microsoft working on such projects as the Visual C++ compiler back end and the runtime libraries, and he also hand-coded optimizations in the Office series of products. The previous year he had done some contracting work at Microsoft.

Earlier I wrote that I never had any conflicts with him. That was almost correct: I enjoyed the few discussion I had with him because of his thorough knowledge of Windows internals; but at the end, there was a small clash, I remember it now:

He chose to include the Basilisk II Windows port in some CD he distributed ... and for some reason, I took offense at it, for a short while! Maybe it was because he charged some small amount of money for the CD. He had asked Christian for a permission to do this, but didn't ask for my permission. I was offended Smile I even put some short notice on my web page about how I felt B2 should be distributed. But quite soon afterwards, I realized that I was wrong and acting childishly. I took down the message, hid in a closet for a few minutes, and all was well again. Haha!

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Your FPU implementation is one of the many aspects of your B2 build 142 that I really appreciate, Lauri. Plus the stability of this build. I find that I really have to be doing something very stupid to crash it, it is that solid. It dosen't occur to me that I'm using an emulator when I run it. I don't have to think about gotcha's, there are so few of those.

About your time working on InDesign plug-ins. Were you familiar with the "K2 or Shuksan" project at the time?

I ask because the copy we have specifically names the InDesign prototype's executable as "ShuksanPPC", which made me think that there may have been a "Shuksan68k" counterpart floating around. And as the code for Shuksan originated from Aldus I had thought/hoped this might has been a possibility. Is this something you may know of?

Lauri's picture
Offline
Joined: 2020 Sep 4

Yes, "K2" was the work name of the InDesign project before it was released ... we developers got pre-release versions of K2/InDesign so that there would be a bunch of plug-ins right from the start.

The name "K2" was an inside joke Smile What is the world's highest mountain? Mount Everest. The second highest? K2. So, at that point, Adobe people felt that they were challenging QuarkXPress, the market leader Smile

Programming InDesign plug-ins was not that easy (for me at least) at the start. They used a kind of Component Object Model -type interface.

Lauri

Lauri's picture
Offline
Joined: 2020 Sep 4

I also remember now that at the very beginning, it was indeed called "Shuksan". I'm not sure whether they even had a developer kit to offer us. It was a very early, maybe an alpha release.

But since that mountain in Whatcom County, Washington, is not that high, they probably got more ambitious and upgraded the name to K2 when they realized that the program could actually be a big hit! And it eventually was, of course. At that point, there was already a dev kit, although an incomplete one and somewhat buggy.

Heh, I just checked: even in InDesign CS4, CS5 and CS6 dev kits, there are two files left that begin with the name "Shuksan" Smile. "ShuksanID.h" and "ShuksanBravoFlags.h". And "ShuksanBuildFlags.h" in CS2 dev kit!

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Thanks, Lauri. You don't recall if there was a 68k executable as well as the PPC K2-Shuksan, do you?

I'd love to know if there could have been one, and to see it running on B2 Wink

Lauri's picture
Offline
Joined: 2020 Sep 4

I'm pretty sure that even the first InDesign 1.0 release version was PPC only ... but how about the pre-release versions ... I don't remember, sorry, and I have no means to check it out. I left all this kind of material behind me when I left the company. I'll let you know if I happen to remember something more, but that is unlikely Smile

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Thanks, Lauri.

I continue to hope that there may have been a 68k version in the wings - based on the InDesign code being an unfinished acquisition from their Aldus absorption and the executable we have is named "ShuksanPPC" which to me hints that there may have been a "Shuksan68k" also. But as yet this is unsubstantiated. C'est la vie.

Lauri's picture
Offline
Joined: 2020 Sep 4

Btw, about stability: I remember now that some years ago I had a short discussion with someone who had crashes under Windows 10. He/she said something like that when clicking outside of the B2 window, the program tended to crash.

Even though I was interested, I was too sick to look into it at that time, but later on I realized what the problem probably was: when using a fast and heavily multi-tasked environment, the code in "audio_windows.cpp" is not sufficiently protected by critical sections. Some calls to enter_sound_section() / leave_sound_section() are clearly missing. I could probably easily fix that one if anybody cares.

This concerns only the versions that are derived directly from my old code, if there are any. I think that Gwenolé dropped this kind of code from his Windows version.

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

I would also love to see any improvements made to B2, Lauri. Would it be called build 144? I think there's a build 143 out there, but I've stuck with build 142 since new.

I tend to run B2 at full screen, so this probably would explain why I haven't spotted that one Smile

Lauri's picture
Offline
Joined: 2020 Sep 4

I'll think about this -- it could actually be fun, now that I am sometimes feeling a bit better Smile

Lauri

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

I do hope that your health is returning to full, Lauri. Anyway, don't feel pressured into taking on anything that'll wear you down if you're not feeling up to it.

watchsmart's picture
Offline
Watcher
Joined: 2009 Apr 10

Your old version still has a following, as a lot of users find it much more stable than the later JIT versions. Actually, the speed enhancement can actually make things run too fast on modern systems, so we recommend it be turned off.

We wrote a guide sometime ago for people who still want to use it - https://www.emaculation.com/doku.php/basilisk_142_setup