• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

[C Programming] Cursed INIT making

Crutch

Well-known member
(Further thought: just realized you are blanking a rect with FillRect(&white). The QD global white definitely won’t be initialized until you set up your A5 world, which explains why that tosses nonsense onto the screen.)
 

Mu0n

Well-known member
I got it.

Had to do the A5 fetching and setting
Had to receive the quickdraw globals in a custom made struct as per that last article so I could get to the baseAddr of the screenBits.
Doing InitWindows to display my own plainDBox white featureless window was a no-no because it requires InitWindows but that would put an empty unremovable menu bar at the top over my splash image
So I had to parse an eraser char pointer to go over the exact dimensions of the homemade screenBits, a sort of white forcing of the right video memory area without the usual functions that are made for this (ie FillRect).

I'll release it in .sit, .dsk in Mac Garden and on my website and do a funny video about it.

Thanks to Crutch and cheesestraws, you saved me once again! I'll put some credits in my releases.
 

cheesestraws

Well-known member
without the usual functions that are made for this (ie FillRect).

Just open a port over the whole screen, no need to create a window. Then you can use whatever QuickDraw stuff you like.

See ShowInitIcon for an example (this is just the version I have to hand, I obviously didn't write it):

 

Mu0n

Well-known member
I've tried and failed over a hundred combinations with small tweaks. I'm willing to try (retry?) yours for science's sake and post the result. It's hard to find the motivation to document every attempt when fatigue enters play after hours.

Edit: I have to say, that's a fine piece of code there
 

Mu0n

Well-known member
Nope, it's the curse that keeps on giving. I'm still on the version that worked before I went to bed, before I fiddle with FillRect again.

I'm trying to boot it with a 800kb dsk under mini-vMac, no issues with System 6.0.3.

On a hardware mac though, the same .dsk with FloppyEmu (or copied on a real physical diskette is the same), I get ID=02
1659190777525.png

which is supposed to be this:



  • ID=02 Address Error
    The Motorola 68000 microprocessor can access memory in increments of one byte (8 bits), one word (16 bits), or one long word (32 bits). The microprocessor can access a byte of information at an odd or even memory address. But it must access a word or long word at an even memory address. So, when the microprocessor attempts to read or write a word or long word at an odd address, you see this error. Since that's a 50/50 proposition when running random code, this one shows up quite often.

maybe it doesn't like where I start to fill those 0x00's myself, but it's weird that the emulator wouldn't stumble upon the same place in the code.
 

Mu0n

Well-known member
Found it!

FillRect works again (magically, can't explain it)
My anti-pop code had an offset written like 36/4, which puts it at an odd number of characters offset (9), changing it to 32/4 made it even again, satisfying the alignment when playing the sound data.
 

cheesestraws

Well-known member
but it's weird that the emulator wouldn't stumble upon the same place in the code.

it's pretty usual that emulators are more forgiving than the actual hardware in some ways and stricter in others: the concerns of hardware and software are different. Especially emulators by smaller people and one team, they'll tend to concentrate on fixing inaccuracies that people are likely to notice. Being less strict about aligned accesses is a reasonable corner to cut :)
 

Crutch

Well-known member
Oh yeah that ShowINITIcon code is nice. I remember wondering for years how INITs know where to put their icon before I saw that code the first time (they use the lomem “ApplScratch” global I think, which was put there originally for Microsoft to store a flag indicating someone had already inserted a master disk circa 1984, if I recall).

I don’t think it’s strictly necessary for them to restore A5 at the end of an INIT (I think the OS restores all the registers when you’re done) but I might be wrong. It would be easy to check.
 

Phipli

Well-known member
Nice code... but how many companies got it wrong back in the day. What would you call them? "Second row dropouts"?
 

ymk

Well-known member
Not sure if this applies here:

Preserve all microprocessor registers other than A0–A3 and D0–D3. Most compilers
for high-level languages automatically generate code that does this.

From IM: Processes 1-13 "Task Guidelines".
 

cheesestraws

Well-known member
Not sure if this applies here:

Pretty sure that only applies for interrupt service tasks. Running an INIT isn't a "task" in that sense, it's just running a blob of code. Nor do patched traps count as interrupts, which is a bit irritating, because you're kind of responsible for using the same calling convention as the trap you're patching, there's no "one size fits all".
 

Mu0n

Well-known member
Here's the video about it:

thanks again everyone, it would have been 5x more painful without your help to get to the finish line.

 

MrFahrenheit

Well-known member
Well done! You could pair this with a HyperCard stack that runs on startup, and replace the Finder with the HyperCard app so that it immediately goes into the stack on boot, and have a pseudo Windows 95 installation procedure, reboot, and Windows 95 desktop.
 

Mu0n

Well-known member
Well done! You could pair this with a HyperCard stack that runs on startup, and replace the Finder with the HyperCard app so that it immediately goes into the stack on boot, and have a pseudo Windows 95 installation procedure, reboot, and Windows 95 desktop.
That would be the deep end for me, but it's a very, very cool and dangerous idea. It just don't fit in a 800kb disk though, I had less than 50kb free on my disk here.
 
Top