Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Knezzen]

Hi!

As you might (or might not know) I work on a Hotline Connect client called HotStuff from time to time. All is working great in the PowerPC and Carbon builds, but I have an issue with 68k build that I'm trying to solve.

I use RealBasic 3.5.2 since it's the last version able to compile for 68k and it doesn't have support for sending resource data as a stream out of the box. In comes good ol' Nubz and their ResourceStream Class. Problem is, they never made it with 68k in mind and it calls a bunch of external PowerPC only routines (I've tried to add some 68k functions using traps and "init68k" to no avail).

Does anyone want to save the day and try to solve 68k support into this class (or help me to write a new class)? The class is attached in a .sit to this post.

Thanks!

[joevt]

What are "external PowerPC only" routines?

I don't have RealBasic but from what I can see, the ResourceStream class only uses these:

Code: [Select]

declare function FSClose lib "CarbonLib" (refnum as short) as short
declare function FSClose lib "InterfaceLib" (refnum as short) as short //inline68k ("A001" )

declare function FSpOpenRF lib "CarbonLib" (fsspec as integer, perms as short, refnum as integer) as short
declare function FSpOpenRF lib "InterfaceLib" (fsspec as integer, perms as short, refnum as integer) as short inline68k ("A00A" )

declare function FSWrite lib "CarbonLib" (refnum as short, count as ptr, buf as cstring) as short
declare function FSWrite lib "InterfaceLib" (refnum as short, count as ptr, buf as cstring) as short //inline68k ("A003" )

declare function FSRead lib "CarbonLib" (refnum as short, count as integer, buf as integer) as short
declare function FSRead lib "InterfaceLib" (refnum as short, count as integer, buf as integer) as short //inline68k ("A002" )

declare function FSpCreate lib "CarbonLib" (fsspec as ptr, maccreator as OSType, mactype as OSType, script as short) as short
declare function FSpCreate lib "InterfaceLib" (fsspec as ptr, maccreator as OSType, mactype as OSType, script as short) as short //inline68k ("A9B1" )

declare function GetEOF lib "CarbonLib" (refnum as short, eof as ptr) as short
declare function GetEOF lib "InterfaceLib" (refnum as short, eof as ptr) as short inline68k ("A011" )

declare function GetFPos lib "CarbonLib" (refnum as short, fpos as ptr) as short
declare function GetFPos lib "InterfaceLib" (refnum as short, fpos as ptr) as short inline68k ("A018" )

declare function SetFPos lib "CarbonLib" (refnum as short, mode as short, offset as integer) as short
declare function SetFPos lib "InterfaceLib" (refnum as short, mode as short, offset as integer) as short inline68k ("A044" )

declare function SetEOF lib "CarbonLib" (refnum as short, eof as integer) as short
declare function SetEOF lib "InterfaceLib" (refnum as short, eof as integer) as short inline68k ("A012" )

InterfaceLib is a shared library. Does RealBasic support 68K shared libraries / code fragment manager?

I don't think inline68k should be used with lib. Some of these functions (such as FSClose) do not translate to a single A-Trap. FSpOpenRF is 0x7003, 0xAA52. 0xA00A is _PBOpenRFSync which takes a parameter block in register A0 and returns a result in D0. If there's no method to specify ABI (Application binary interface), then your inline 68K code will have to modify the stack and registers. This info can be found in the Universal Interfaces from MPW or CodeWarrior.

You should find RealBasic sample code for 68K that shows how to use Mac 68K toolbox methods.

Maybe you need to create a 68K code resource with these functions that RealBasic can call.

http://preserve.mactech.com/articles/mactech/Vol.17/17.12/Dec01REALbasic/index.html

[laulandn]

I took a pretty close look at this with Knezzen, going as far as finding how FSWrite was implemented in CodeWarrior.  I believe what I found was correct, but take with a grain of salt.

It looks like Apple added a bunch of "convenience filesystem functions" at some point, these were implemented in glue code around the standard Parameter Block functions, and are not A-line traps or part of the Mac Toolbox, as we know it.  I eventually found FSWrite in Interface.o and disassembled it using MPW.  I found it was (basically) a wrapper around PBWriteSync.

The "inline68k" traps that you see were the best guess of what the functions should be, but, as far as I could tell looking them up, and as you pointed out specifically with FSpOpenRF, not correct.  (Nor should they be used with InterfaceLib).  So it does not look like Nubz/ResourceStream will work on plain m68k.  These functions may available to CFM-68k via InterfaceLib directly (and not a trap), but I didn't check. 

What is needed is code to do file access of the resource fork, as a stream, using RealBasic 3.5.2 for m68k. 

My thoughts: One way would be to write a new m68k-only version of the class, possibly using Parameter Block functions.  Another way would be to find a way to call the existing glue code in Interface.o from RealBasic.  A third way, if the functions are available in InterfaceLib for that platform, would be to use (and require) CFM-68k, but that might be tricky with RealBasic.

I don't know RealBasic so I can't judge the scope of any of the above possibilities.

[Knezzen]

Yeah, this is a bit out of scope for me competence wise. I'm not sure how to solve it.

[joevt]

Convert the glue code into inline68k (if it supports multiple 68K instructions). The inline68K can allocate space for a parameter block on the stack and fill in all the fields and setup registers. You right the code in 68K and assemble it into hex using MPW. Then copy the hex into the inline68K.

or

Use the parameter block variants of the methods (still uses inline68k but the setup is done by REALbasic code).

or

Look into creating a REALbasic plugin using CodeWarrior and the REALbasic Plug-ins SDK.

[laulandn]

Hmm...

If we convert the code from Interface.o (which is supplied by Apple, and CW uses), we'd have to get not just FSWrite, but all the other glue functions (esp FSOpen!)...but that is doable.  Maybe take just the disassembled functions, if RealBasic does assembly...or as joevt suggested, copy the hex itself as mutliple inlines.  The code already handles the paramters so could probably be used as is.

or

Doing it using PB Functions seems like the "Right Way", but would require more work, and figuring out how to use all those, if you're not already familiar with them...parameter blocks are a bit of a pain...but not too bad.

or

Writing a new plugin I don't think would be much better than the above, as it'd still have to be written...but...maybe could write it as RealBasic glue code and call what is in already right there in Interface.o directly.  So it'd just be wrapper functions.  This might be the best way, but involves CodeWarrior.

----

Knezzen, let me know if you're interested in pursuing any (or all) of these.

[joevt]

I used the TBFinder utility from REALbasic to look up the Mac OS toolbox functions.
I used CodeWarrior Pro 4 to disassemble MacOS.lib which contains all the glue code.
I've attached the results.

The glue functions cannot be directly converted to inline68k because they expect to be called as a function (with JSR or BSR). You either need to create different stack code or you need to add a call to the glue code. So your inline code would start with a bsr.s *+4 to jump into the glue function and that would be followed by a bra.s to jump over the glue function.

I did the inline code for the FSClose glue as an example. The rest should be similar except for FSWrite which starts a couple instructions after the start of FSRead (so just add 4 to the bsr.s instruction).

[laulandn]

Thank you @joevt!  I've never used RB so can't help all that much with that part, but it looks like you nailed it down and those ideas are extremely good.

@Knezzen, let me know if you'd like to look more into this.  If you're not familiar with CodeWarrior, I could do that part.

[Knezzen]

Thanks for all your insight and help, joevt! You shined a light on something I didn't know how to deal with so thank you for that. I need to reflect a bit how to solve this problem. It's the only thing left to fix in the 68k build of HotStuff to make it run like it should.

I didn't know of TBFinder until you mentioned it. I found it online and made a page for it over at Macintosh Garden, all in the name of preservation of course. Thanks again!

@Knezzen, let me know if you'd like to look more into this.  If you're not familiar with CodeWarrior, I could do that part.

I will most likely need your help on this, lauland if you feel like doing the legwork on this. Implementing the functionality in a plugin (or whatever might be the best approach) is beyond my knowledge. Thanks for reaching out

[joevt]

I had used TBFinder 2.0 so you should check the newer one that you linked (TBFinder 2.3.3 Carbon) to see if it has different/probably better info.

[joevt]

You won't need CodeWarrior unless there's glue routines that need to be disassembled that I didn't disassemble.

[Knezzen]

I found a RealBasic plugin that seems to do the trick, problem is that it's locked in trial mode and I have no idea if it's even possible to "hack" it. Right now HotStuff runs in debug mode but wont run when compiled. Instead a nag screen appears and then the application shuts down.

The plugin in question is "ResourceStreams" by Einhugur Software and can be found here for anyone interested. Too bad it's in trial mode and version 2.0 seems to be the latest one that supports 68k builds

It feels a bit like the end of the road for the 68k build. I'm at, what seems like, a dead end (for the time being at least).

[joevt]

My attachment should have had enough info. It has Inline68K for FSClose.

This attachment provides Inline68K for FSRead and FSWrite.
Compare both versions to see what I added to create the Inline68K.
Does REALbasic allow Inline68K to be as large as 76 bytes?

[Knezzen]

My attachment should have had enough info. It has Inline68K for FSClose.

This attachment provides Inline68K for FSRead and FSWrite.
Compare both versions to see what I added to create the Inline68K.
Does REALbasic allow Inline68K to be as large as 76 bytes?

Thank you! I'm not sure what the inline68k size limit is. I've tried to make some new inline68k "glue" based on your file, but I'm struggling. I'll give it a go tonight again. There must be something I'm doing wrong.