Removing startup artifacts of "improved" ROM SE/30!!!

[zuiko21]

[Wow! It's been a long time since my last post... I've been crazy at work these weeks I hope to catch up soon!]

@onlyonemac: If memory serves, I tried every possible value for the register, including each combination of D0, D1 and D3 -- the volume did turn down making the sound quieter... but equally distorted :?: I'm afraid the distortion comes from some other place... BTW, D2 seemed to have no effect, but its value was changed anyway.

@Bunsen: Certainly. The big problem about an unexpected OS for these machines (or any old world Mac) is the firmware, which is expecting to boot from a well-formed MacOS... But writing the firmware (ROM) from the scratch, "nothing" would prevent it booting from anything else...

But please take that "nothing" with a grain of salt -- by no means would it be a trivial task and, if attempting to boot an already made OS in 68k code, it's unlikely that it was designed with support of this unexpected architecture in mind -- it was made for MacOS only, wasn't it? A whole brand new OS (and its apps!) from the scratch shouldn't have these limitations, but that would be a lot of work...

I'm sort-of developing an escalable, (almost) full-featured modular OS intended for a (newly designed) 6502 system; but with portability in mind, thus a 68k version of it could be highly feasible... and should fit nicely into one of those ROM-SIMMs

mode>

)

See you soon,

 

[dougg3]

Hey zuiko,

This sound thing is still bugging me. I don't know if you're still trying to figure it out, but I just wanted to go back through everything I know about the sound chip in case it's any help. I just looked at my disassembly. It looks like the stock startup chime initialization code does a few things differently depending on the version register of the ASC (at ASC+$800). My sound code ignores it completely and just assumes the IIci version of the sound chip, so that might be a problem.

It would be interesting to see what the version register returns on the SE/30. On the IIci, using MicroBug with the command "DM 50F14800", the first byte it prints back is $00--version 0.

If the SE/30 reads back a different version number in this register, that might be part of what's going on. Anyone feel like going into the debugger and typing that command on an SE/30? Then you can exit the debugger by typing "G".

Here are the initialization differences based on the ASC version:

1) The volume it loads into the volume register ($806) is a bit different: On version 0, it looks like the 3-bit volume is loaded into the upper 3 bits (5-7) of register $806. This also concides with what happens if I play around with the sound control panel and then dump the contents of it:

volume 0 --> $00

volume 1 --> $20

volume 2 --> $40

volume 3 --> $60

volume 4 --> $80

volume 5 --> $A0

volume 6 --> $C0

volume 7 --> $E0.

For a nonzero ASC version, it appears to put the volume into bits 2-4 of the same register (but they provide a different volume for that chip too -- not sure exactly why).

No idea what the difference is -- all of the startup chimes/error beeps have two volumes in the initialization code. One for ASC version 0, one for ASC with a nonzero version.

So...if the SE/30 has a different sound chip version, my code (which just puts $40 for a volume of 2 before playing the sampled chime) is initializing the volume incorrectly.

2) Another thing it does differently with different ASC versions is that it puts something different into register $802. For ASC version 0, it puts in $00. For ASC with a nonzero version, it puts in $01. My comments say this is telling the sound chip whether to use analog or PWM, but I don't know for sure.

3) The only other difference is it sets up the initial synthesizer waveform differently based on the ASC version. But since you're not using the synthesizer mode, this shouldn't matter.

So...I guess it would be awesome to get a dump of what register $800 contains on the SE/30's ASC. Extra credit if you change the sound in the sound control panel and dump the register contents each time you change the sound like I did in my list above. ;-)

 

[zuiko21]

OK, let's go! (I'm writing this on the SE/30, after checking what you said)

It would be interesting to see what the version register returns on the SE/30. On the IIci, using MicroBug with the command "DM 50F14800", the first byte it prints back is $00--version 0.

So does mine...

1) The volume it loads into the volume register ($806) is a bit different: On version 0, it looks like the 3-bit volume is loaded into the upper 3 bits (5-7) of register $806. This also concides with what happens if I play around with the sound control panel and then dump the contents of it:
volume 0 --> $00

volume 1 --> $20

volume 2 --> $40

volume 3 --> $60

volume 4 --> $80

volume 5 --> $A0

volume 6 --> $C0

volume 7 --> $E0.

These are exactly the values I read at $50F14806 if I change the volume setting via the usual control panel...

2) Another thing it does differently with different ASC versions is that it puts something different into register $802. For ASC version 0, it puts in $00. For ASC with a nonzero version, it puts in $01.

Well, here we are a difeference: mine reads $02. FWIW, at $50F14801 is $01.

So...I guess it would be awesome to get a dump of what register $800 contains on the SE/30's ASC. Extra credit if you change the sound in the sound control panel and dump the register contents each time you change the sound like I did in my list above.

Done ;-)

I haven't tried the custom ROM SIMM on the other compatible machines I have (IIx, IIsi, Quadra 700) although I don't think they would show any picture... but the sound should play OK, right? Should I try them too? Any other interesting test to do?

All the best,

 

[dougg3]

Hey Zuiko,

Thanks for running that test! So the SE/30 also has version 0 it seems. Nevermind about the differences I mentioned.

That's weird that $802 is reading back as 2. On my IIci, it reads back as $80. I'm not too concerned about what it reads back as in the Mac OS though--if the version register at $800 is reading as 0, then we know what code path it's going to take in the ROM. Also, your tests of the Sound control panel serve as a good confirmation.

I wonder if there's some kind of GPIO initialization that needs to be done in one of the VIA chips. I think GttMFH lays out what the registers do in each VIA. It's possible for a death chime to play very early in the boot process, so there can't be much left to initialize

The SIMM should work in all of those, but I don't know if the newer sound chips in the IIsi or Quadra 700 will be register-compatible. I would assume the IIsi will still be compatible, but I'm less sure about the Quadra. I'm thinking that the FIFO status registers act differently on the Quadra's sound chip. I guess there's only one way to find out...