www.gryphel.com/c/mail/v9 - feedback

Gryphel Project Mail

Volume 9


To send mail to me, use the feedback form.

( - latest - )

permanent link

Sent: Thu Feb 14 07:37:11 2019

[previous message]

Hi Paul,

Yes, my MacII.ROM checksum is different -- 0x97221136. I didn't realize your disassembly would be specific to one ROM checksum, though that makes sense. Maybe fdisasm should warn if the checksum isn't what was expected?

The two occurrences of non-ASCII characters are appearing in P_Sony_RdData:

2E906  F1F5 F1F5      L6264:     Illegal
2E90A  F2F6 F2F6 F3F7            [... garbage ...].L (* + -$D090C07)
2E910  F3F7                      Illegal.L (* + -$D090C07)
2E982  6C00                      DC.W      $6C00           ; 'l '
2E984  F2E4 80C3 E248 L6271:     [... garbage ...].L (* + -$7F3C1DB6)
2E98A  55C6                      SCS.B     D6

Since that probably won't survive being submitted through this web form, the hex of the values on lines 2E90A and 2E984 is:

F6F2F600 00000F00 00000600 00000600 00000100 00000300 00000000 00000200
0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 44303930
43303729
E4F2E400 00000F00 00000400 00000400 00000100 00000300 00000000 00000200
0001E400 212F3E00 21397400 213ACC00 356DF200 02F00800 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00002E4C 20282A20 2B202D24 37463343
31444236 29

-Ryan


Thanks, I can now reproduce the issues. The garbage non-ASCII characters are due to a bug affecting disassembling floating point conditional long branches. I have a fix for this.

(Checksum 0x97221136 is actually a Mac IIx ROM, which works with Mac II emulation.)


permanent link

Sent: Wed Feb 13 20:13:47 2019

is possible add a option to increase or setup screen size?

[... email address ...]


Screen Size is a compile time option. You can use the Variations Service to compile a variation with the desired Screen Size.


permanent link

Sent: Tue Feb 12 06:57:36 2019

Hi Paul,

I was trying out fdisasm 1.2.6 on the Mac II ROM using fdmacii 0.2.2, and I noticed some output that doesn't look correct. For example resource MDEF 0 begins with the remark "; !! field doesn't fit" followed by assembly that doesn't make sense. In comparison, the MDEF 0 code disassembled from the Mac Plus ROM using fdplusv3 0.4.3 looks reasonable.

In the Mac II ROM disassembly, there are 134 occurrences of "; !! field doesn't fit" and also some occurrences of garbled (non-ASCII) output. The Mac Plus ROM disassembly has only one "; !! field doesn't fit" and no non-ASCII characters.

-Ryan


Thanks for the report. I have only been able to partially reproduce this. I get only 7 instances of “; !! field doesn't fit”. This turns out to happen in the most recent version of FDisasm if a label is in the middle of an instruction. In the Mac II ROM, some of these happen because there is a table in the ROM being indexed into after subtracting a constant. And currently, it looks, to FDisasm, like the start of table is shifted by that constant. My prefered solution is to create a mechanism to tell FDisasm about that constant, which will make the disassembly more clear than in previous versions.

By there is one case where an operand in the middle of an instruction is being referred to by other instructions. Ugh. I think I would prefer to put the label at the beginning of the instruction and have the referring instruction have a constant as above, so that Reasm won’t need to deal with labels in the middle of an instruction.

One possible explanation why you are seeing more of these warnings is that you are disassembling a different version of the Mac II ROM. The formatting information I provide is for the ROM with the checksum 0x9779D2C4. If your ROM isn’t very similar, it would get out of sync with the formatting information and there would be a lot more instances of this issue. But I’m still not sure how you would get non-ASCII output.

update - follow-up message


permanent link

Sent: Sat Feb 2 05:02:26 2019

no ROM image

Is this project active?

I see an executable without need for gcc. When I run './'Mini vMac' an emulated screen appears but the message above is the content.

m190202_045635_010.bin.tgz

and

minivmac-36.04-lx64.bin.tgz

produced similar results.

[... name ...]


To get started with Mini vMac, see the Getting started with Mini vMac page.

For the latest project news, see the Latest news section of the website main page.


permanent link

Sent: Wed Jan 30 07:21:54 2019

Hello, I noticed that at the top of the latest news page, the newest updates list the year as 2018 rather than 2019.


Thanks! I have made this correction.


permanent link

Sent: Wed Jan 30 04:04:40 2019

Hi there! I was looking for the Mac OS 9 (PPC) release of Mini vMac and couldn't find it anywhere.

I don't really expect it to still be supported, but I do remember it existing at one point, having used it a bunch to run older programs on my old G3 iBook.


Sorry, the version of GCC I’m now using, for a set of cross compilers, doesn’t support classic Mac OS. I would like to figure out how support classic Mac OS again eventually.


permanent link

Sent: Mon Jan 21 09:44:44 2019

I don't mean to bother, but it just seems that as I try, I don't see that Mini vMac works anymore with disk images... I tried many different ways to get the disk image to load, or "boot", but it does not function,... I have also tried the .dsk "disk1.dsk" option for it to automatically "mount", but it does not seem to respond.

Is there something that has occurred?


Do you mean that you have disk images that can be mounted with old versions of Mini vMac, but not current versions of Mini vMac? Or do you mean that you have a disk image that you can’t mount with any version of Mini vMac? In the latter case, probably the image got corrupted.


:
:
:

For earlier mail, see the mail index.

:
:
:


www.gryphel.com/c/mail/v9 - feedback
copyright (c) 2019 Paul C. Pratt