So far, the contains the following:
1) The Reset Vector: the first four bytes (where the checksum usually goes) are meant to be the initial value for the stack pointer; but since RAM is disabled so far (ROM overlay mode) it would be meaningless anyway. Then goes the code's starting address, I pointed it to 0x4000008 -- right after the vector. Despite being read from what would become RAM, it jumps to the usual ROM address range. I don't bother switching off the ROM overlay, though.
2) My code for displaying the picture; it was assembled by hand and wrote into the ROM with a hex editor (Hex Fiend). After some tweaking, I ended up using something crude like this:
Not sure which is the main screen buffer and which is the alternate buffer, so I wrote the picture data in both :b&w: In fact, the 16-bit offset in MOVE.L D1, (0x8000, A1) seems to be signed and working backwards from intended, thus I placed that 0x8000 offset into the base address (see 2nd opcode), otherwise it didn't work -- I don't know which buffer is shown at startup time, either :I
3) dougg3's code for sampled startup sound, but supressing the final return instruction because this wasn't called from anywhere
4) A STOP instruction -- supposedly halts the CPU and keeps it waiting for an interrupt... which would be catastrophic anyway, without any RAM/stack available xx(
5) The bitmap of my picture (512x342, 1-bit). I made it in CS5 after resizing/converting/dithering the original almost-as-sinister photo Saved it, inverted (the Mac's screen is substractive: "1" means black pixel) as Wireless Portable Bitmap which contains the raw data after a small header, easily edited off with Hex Fiend
6) The sound sample (this address hardwired into Doug's code) after the preceptive 4-byte header indicating the sample's length. Again took it from the original 8-bit 22kHz AIFF after stripping the header.
And that's all! The code is actually playing the sample (not just static) and for the proper length; but the distortion could be caused by the lack of further initialization, as said -- I presume Doug's code originally executed after a great deal of Apple's ROM code.
A weird thing, however, is that after 45 seconds or so it does play again the sample! And keeps doing so every after... :?:
1) The Reset Vector: the first four bytes (where the checksum usually goes) are meant to be the initial value for the stack pointer; but since RAM is disabled so far (ROM overlay mode) it would be meaningless anyway. Then goes the code's starting address, I pointed it to 0x4000008 -- right after the vector. Despite being read from what would become RAM, it jumps to the usual ROM address range. I don't bother switching off the ROM overlay, though.
2) My code for displaying the picture; it was assembled by hand and wrote into the ROM with a hex editor (Hex Fiend). After some tweaking, I ended up using something crude like this:
Code:
PutPic: LEA Picture, A0 ;the picture stored in ROM
LEA 0xFE008000, A1 ;address of the frame buffer
MOVE.W #0x1560, D0 ;number of long words on a screen
Loop: MOVE.L (A0)+, D1 ;loads a long word from the picture
MOVE.L D1, (0x8000, A1) ;writes on the alternate buffer
MOVE.L D1, (A1)+ ;writes on the main buffer, and avances to next long word
SUBQ.W #1, D0 ;one long word less to go
BNE.S Loop ;repeat until it's finished3) dougg3's code for sampled startup sound, but supressing the final return instruction because this wasn't called from anywhere
4) A STOP instruction -- supposedly halts the CPU and keeps it waiting for an interrupt... which would be catastrophic anyway, without any RAM/stack available xx(
5) The bitmap of my picture (512x342, 1-bit). I made it in CS5 after resizing/converting/dithering the original almost-as-sinister photo
Saved it, inverted (the Mac's screen is substractive: "1" means black pixel) as Wireless Portable Bitmap which contains the raw data after a small header, easily edited off with Hex Fiend6) The sound sample (this address hardwired into Doug's code) after the preceptive 4-byte header indicating the sample's length. Again took it from the original 8-bit 22kHz AIFF after stripping the header.
And that's all! The code is actually playing the sample (not just static) and for the proper length; but the distortion could be caused by the lack of further initialization, as said -- I presume Doug's code originally executed after a great deal of Apple's ROM code.
A weird thing, however, is that after 45 seconds or so it does play again the sample! And keeps doing so every after... :?: