No programming categories?

yock1960

Tinkerer
Mar 24, 2022
65
24
18
I don't see any, pecifically for MacOS. Until now, I have done zero Mac programming, although I did purchase Futurebasic back in...the day 😄🥴.

Now, I'm trying my hand...with a slightly newer version of Futurebasic (v2 vs. V1) and while I've generally been able to accomplish my goal, there are a few things that aren't provided for 'out of the box' and require delving into the toolbox routines. This is possible with Futurebasic, but not well documented. Additionally, so far, I've found Inside Macintosh and the few other old books I've perused to be unhelpful to a casual programmer like myself.

I guess most folks don't actually program there Vintage Computers...

Why not?! 😄
 

Paolo B

Tinkerer
Nov 27, 2021
243
138
43
Nagoya, Japan
I still have the FutureBasic package I bought too many years ago now.
It was an extremely appealing proposition for “easily” writing GUI driven applications on 68k Macs.
I never liked Basic, though, so after a little while I went back to my beloved ThinkPascal for writing my “engineering focussed” code.
Until I came into some interesting stuff called “Matlab”. And it was a revelation.
 
  • Like
Reactions: yock1960

yock1960

Tinkerer
Mar 24, 2022
65
24
18
I still have the FutureBasic package I bought too many years ago now.
It was an extremely appealing proposition for “easily” writing GUI driven applications on 68k Macs.
I never liked Basic, though, so after a little while I went back to my beloved ThinkPascal for writing my “engineering focussed” code.
Until I came into some interesting stuff called “Matlab”. And it was a revelation.
I never used Pascal much. Started with horrible Microsoft 'Basic 2.0' on the Commodore 64, later on, some C on DOS PC's and later again, some Visual Basic. I think I did use a version of Pascal on Palm OS. I think I'm making progress on my issues...downloaded an old Macworld book, FAQ on MacOS programming that looks to possibly have the information that I need...in a format I can assimilate!

Yes, Futurebasic is pretty nice. It looks like version 4 would be even nicer, but it doesn't seem to be available.
 

Eric's Edge

Tinkerer
Oct 31, 2021
121
87
28
I've been working with HyperCard and a little with Think C. HyperCard is my go-to for developing applications for 68K Macs. Although I know C, I'm new to using the ROM toolbox routines.
 
  • Like
Reactions: yock1960

yock1960

Tinkerer
Mar 24, 2022
65
24
18
I've been working with HyperCard and a little with Think C. HyperCard is my go-to for developing applications for 68K Macs. Although I know C, I'm new to using the ROM toolbox routines.
Back when I used Macs for a time, I played around with Hypercard and Applescript. I actually wrote a version of YAHTZEE in...I guess Applescript....I don't remember now and sadly, I don't see that the code survived the years. I did write another version in MMBASIC on the Color Maximite Computer 2, back in '20. I could probably convert that fairly easily to Futurebasic, but there are some built in sort commands that I would have to recreate. Currently I'm working on a Mandelbrot/Julia Set explorer. Something I've been fascinated with from my first experience with them! Next will come a 4 state linear automata generator...a program I typed in on a C64 back in the 80's.
 
  • Like
Reactions: Eric's Edge

Eric's Edge

Tinkerer
Oct 31, 2021
121
87
28
I recently created yet another Wordle clone in HyperCard. It's up in archive.org along with a game I write last year for the Royal Game of Ur.
 
  • Like
Reactions: yock1960

Paolo B

Tinkerer
Nov 27, 2021
243
138
43
Nagoya, Japan
I started programming in a committed way on an LC and ThinkPascal. Hard to believe, but back at the time it was considered a diminutive, yet viable entry point.
Pascal had an intrinsic elegance that was simply unbeatable, and the implementation offered by Symantec with the “Think Pascal” series was classy and irresistible.
However, when things scaled up and got serious, I switched to Matlab and (metaphorically) fell in love with it. Still today, my favorite environment for developing scientific applications (not necessarily on a Mac, though).
 

YMK

Active Tinkerer
Nov 8, 2021
345
266
63
I develop with Think C. Is there an established forum somewhere for classic MacOS dev besides the MLA?
 

yock1960

Tinkerer
Mar 24, 2022
65
24
18
I develop with Think C. Is there an established forum somewhere for classic MacOS dev besides the MLA?
I did see a bit over there, but I haven't yet registered there yet...

As much as I don't want to, I'm probably going to have to go to C, since so much of the literature is geared for it, or certainly not geared for BASIC. BASIC is more my 'speed', but it's slow. I'm presuming that compiled BASIC < C < assembly...assuming a decently coded program, as is my experience on other platforms. Speed aside, I think FutureBasic could do what I want...if only I knew how to 'tickle' the bits correctly!
 

YMK

Active Tinkerer
Nov 8, 2021
345
266
63
I'm presuming that compiled BASIC < C < assembly...assuming a decently coded program, as is my experience on other platforms.

That's probably accurate. The speed of the "compiled" BASIC depends on what the compiler is doing. If it's merely packaging the interpreter with the source, I'd expect it to be slow.

C becomes assembly and the two can be mixed. Handwritten assembly may or may not be faster than compiler-generated. You can rewrite C functions as assembly and compare their speed. Also, it helps to know assembly because you'll be looking at disassembled machine code after a crash.
 
  • Like
Reactions: skate323k137

BusError

New Tinkerer
Jun 17, 2022
14
7
3
On pre-g3/g4 it was often a good idea to convert strategically from C to asm. But I would never 'write from scratch' in asm; I'd make the code in C first, disassemble it and see how bad/good it was. VERY often just changing the C code a bit was enough to get the optimiser to do the 'right thing' -- but even if not, I'd start with the original disassembly, convert it to an asm() statement, and tweak it from there, making sure I'd kept the C code as a 'master'. This last thing helped my ass many times over when processor changed over time.

On g3, and especially G4/5 it became a lot 'harder' to write assembly that was faster than C, mostly because of the pipeline and the ram latency. It was still a good idea if you wanted do stuff like altivec etc, but even in scalar code I'd often apply the same methods as before, just had to bench a hell of a lot more as something that 'looked' faster wasn't necessarily so.

Here's a piece of a PCI audio driver I wrote all the way back then, for OSX. It converts audio back/forth between (little endian) 24 bits integer and floating point, 8 channels at a time. All the tricks of the book were used here, but as you can see, very little 'assembly'. The important bits were in fact writing a (perl) script to find the 'right' meshing of operations to make the pipeline happy.

static inline double __clip( register double B ) { register double result; asm( "fctiw %0, %1" : "=f" (result) : "f" (B) ); return result; } void F32L24_48_8(double *v, float *ii, UInt32 *oo, long count) { register double v0=v[0],v1=v[1],v2=v[2],v3=v[3],v4=v[4],v5=v[5],v6=v[6],v7=v[7]; // better see that with tabs == 4! register double scale = 2147483648.0; #if FASTPLAY #define _load(i) s##i = ii[i] #define _volc(i) s##i *= v##i #define _clip(i) __clip(s##i) #define _d2l1(i) s##i *= scale #define _d2l2(i) o##i = (SInt32)s##i #define _stor(i) __asm__( "stwbrx %0, %1, %2" : : "r" (o##i), "b%" (i << 2), "r" (oo) : "memory" ) #else // this is the equivalent, without using assembly #define _load(i) s##i = ii[i] #define _volc(i) s##i *= v##i #define _clip(i) if (s##i > 1.0) s##i = 1.0; else if (s##i < -1.0) s##i = -1.0 #define _d2l1(i) o##i = (SInt32)(s##i * scale) #define _d2l2(i) o##i = (((o##i >> 8) & 0xff) << 16) | (((o##i >> 16) & 0xff) << 8) | (((o##i >> 24) & 0xff)) #define _stor(i) oo[i] = o##i #endif register double s0,s1,s2,s3,s4,s5,s6,s7; register UInt32 o0,o1,o2,o3,o4,o5,o6,o7; while (count--) { // staged pipeline 6x8 _load(0); _load(1); _load(2);_volc(0); _load(3);_volc(1);_clip(0); _load(4);_volc(2);_clip(1);_d2l1(0); _load(5);_volc(3);_clip(2);_d2l1(1);_d2l2(0); _load(6);_volc(4);_clip(3);_d2l1(2);_d2l2(1); _load(7);_volc(5);_clip(4);_d2l1(3);_d2l2(2);_stor(0); _volc(6);_clip(5);_d2l1(4);_d2l2(3);_stor(1); _volc(7);_clip(6);_d2l1(5);_d2l2(4);_stor(2); _clip(7);_d2l1(6);_d2l2(5);_stor(3); _d2l1(7);_d2l2(6);_stor(4); _d2l2(7);_stor(5); _stor(6); _stor(7); ii += 8; oo += NUM_CHANNELS_OUT; } }