[C Programming] Cursed INIT making

[Crutch]

(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]

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]

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):

Force32/ShowInitIcon.c at main · cheesestraws/Force32

Force 32-bit addressing on for PRAM batteryless old Macs - cheesestraws/Force32

github.com

 

[Mu0n]

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]

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


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]

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]

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]

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.

 

[cheesestraws]

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.

It does, if I'm reading this right.

 

[Crutch]

Yup that’s it right there! Nice.

 

[cheesestraws]

I've always restored A5 just because I feel grotty if I don't, but this is just cargo culting...

 

[Phipli]

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

 

[ymk]

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]

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]

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.

 

[cheesestraws]

That's extremely silly, in all the best ways. Well done.

 

[MrFahrenheit]

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 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.

 

[Mu0n]

Today, I released a 2nd cursed boot disk.

watch what happens -

if you want to try what I coded as the INIT that I used, go here: https://macintoshgarden.org/apps/init-fakes-a-ms-dos-33-startup

 

[Mu0n]

3rd annual Cursed Boot Disk 03 released!

I pushed the enveloppe by loading quite a few gfx art assets into a Handle to a bunch of Sprites that I coded some 16 years ago. The code still held up, but the Draw routines had to be slightly modified to take into account the special quickdraw environment forced upon me during INIT time. Some sounds as well, so I'm not sure if I was nearing the limit or not, but it all worked out in the end.