Aros/平臺/68k 支援/開發者/庫
庫/應用程式“自動”開啟在編譯時可用的庫。如果存在問題，最簡單的解決方法是將 graphics.library 的 AROS 版本降級到 39（在 graphics.conf 檔案中），以用於“frankenrom”。另一種選擇：在層中某處定義全域性 GfxBase 變數 - 這應該可以阻止“自動”工作，因此您需要手動開啟圖形。
- autoconfig（正在開發中，快速 RAM 擴充套件已經可以使用，自動引導 ROM 支援待開發。對於 UAE 硬碟測試非常重要）
- expansion.library 當前設定為 noautolib。這是因為非 Amiga 系統不需要擴充套件（自動配置）還是需要以其他方式初始化？
- utility.library 數學函式是一段糟糕的程式碼。雙返回值（D0 和 D1） - 必須保留 A0 和 A1。糟糕。太糟糕了。看起來這裡需要進行大量 ASM 工作才能用於 m68k。您是否檢查過 arch/.unmaintained/m68k-native/utility？只需要動態選擇 68020+ 和 68000/010 版本。
擺脫 rom 目錄，因為不同的架構可能會在 rom 中放置或多或少的模組。某些架構甚至可以配置將哪些模組放入 rom，具體取決於可用多少非易失性儲存空間。擁有 rom/ 目錄使 m68k 埠更容易，僅僅因為只需要支援 librom.a 最小 AROS C 庫，而不是完整的 AROS C。在 ABI V1 中，librom.a 不見了。arosstdc.library 中有一個庫，所有模組都可以使用它。它將作為第一個模組之一進行初始化。因此，IO 函式也移動到基於磁碟的模組 arosstdcdos.library。您如何處理 ctype.h 系列函式？我希望看到僅限 LANG=C 的精簡選項。
我認為應該為 TaggedOpenLibrary() 庫 ID 號定義定義。（但是在哪裡？它應該只由 rom 程式碼使用）。在 m68k-amiga 中這將非常有用，因為它使 rom 檔案略小（目前這裡和那裡有很多庫名稱字串）。UtilityBase = TaggedOpenLibrary(7); 看起來很醜陋..
workbench/libs/gallium：-Wall 清理。正在比較不同的列舉型別，編譯器不滿意。我查看了每種型別的列舉列表，它們看起來非常不同。在主 Mesa 儲存庫（workbench/libs/mesa/）的主幹中，程式碼也是如此。
對 genmodule 工具的以下更改將更好地支援可ROM化模組
我還有另一種解決方案，也用於 ABI V1 分支。唯一假設的是，我們在其中執行程式碼的庫的 LIBBASE 為 A6（在 i386 上，它在 *(%ebx) 中）。
* LIBBASESIZE:
- Would have space for an additional BPTR for the library's SegList
- Space for an additional N struct Library * slots after
the end of LIBBASETYPE, where N is the number of auto-opened libraries.
- These slots would hold the opened library handles for the
auto-opened libraries. But I don't like this change but won't veto it.
It can always be reverted when proper support for global variables is
implemented in ROM linking and the ROM bootstrap code.
To me write-only media and write-able global variables sounds mutually
exclusive. Well, actually *read*-only media and write-able global
variables sounds even more mutually exclusive ;-)
Please outline how it would work for an EEPROM or alike.
EEPROM Very easy. In your linker script you declare .bss and .data sections
in RAM, whereas .rodata and .text are in ROM. At startup, the Kickstart copy
the .data section stored somewhere in ROM into proper location in RAM and
zeroes the .bss section. And at the same time we could replace the ROMtag
scanner with a list of modules that is generated at link time; for example
using the AROS symbolsets. I thought "binary compatibility" goes both ways,
original rom modules work with Aros rom modules and vice versa..
IMHO this is the worst solution. Chip RAM is too valuable for that.
Either modules are going to be proper fully rommable or _everything_ can be
relocated to RAM by tiny relocator and expansion RAM configuration code in
ROM. Anyway, both solutions are bad ideas for basic A500/A1200 modes which will
kill my interest instantly.
* set_open_libraries():
- Would take LIBBASE as a parameter
- Would OpenLibary() to the post-LIBBASETYPE Library *slots
* set_close_libraries()
- Would take LIBBASE as a parameter
- Would CloseLibary() the post-LIBBASETYPE Library *slots
* An additional header would be '-include libname_libraries.h', that
would be autogenerated, and have lines like:
#define GM_SEGLIST_SLOT (BPTR(((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[0])
#define UtilityBase ((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[1]
#define GfxBase ((APTR *)(((IPTR)LIBBASE)+LIBBASESIZE))[2]
I tried to get rid of these
'#define libbase' hacks. This code assumes that LIBBASE is available
in all functions that call a function of an auto-opened library.
This assumption is false. If you see no other way out please only
implement when compiling the kobjs on m68k. I mean, genmodule could
supported two types of libraries (or just make a second genrommodule
for the sake of it). Whatever assumption is made, it would only apply
to code that is explicitly written/modified against that assumption...
...
對我來說，在乾淨的程式碼中沒有這些 #define 技巧的位置，它們改變了一些程式碼的語義（struct IntuitionBase *，指向 amiga 共享庫中函式的函式指標，...）。它與 ABI V1 中 C 庫的實現方式不相容。庫中基於棧的函式的存根程式碼需要全域性 libbase，而 #define 不會被注意到。ABI V1 中的 C 庫問題仍然存在。也許可以在 arch/m68k-native 樹中重新引入靜態 C 連結庫，允許我擁有在我看來是正確的且乾淨的 m68k 分支。
約束
(1) 不想將 BSS 放入（寶貴的）晶片 RAM (2) 一些機器有快速 RAM，一些機器沒有，因此我無法在*編譯時*確定將 .BSS 連結到哪裡。(3) 由於 (1) 和 (2)，.text 不能對 BSS 中的任何內容進行絕對引用 - 即 FooBase、BarBase 等。
“#define 技巧”允許我滿足所有約束條件，並且我計劃不將它們新增到原始碼本身 - 僅限 genmodule，並且僅在它針對只讀 ROM 時。
所有這些的最終結果是 genmodule 將以兩種（目標相關的）模式執行：.bss 模式用於磁碟可載入模組，以及 ROM 模組的 .rela.bss 模式。嗯... .rela.bss.... (/me 認為)
此外，我將能夠*刪除*程式碼庫中已經存在的大量“#define 技巧”，因為只有 genmodule 需要關心將庫控制代碼放置在何處。
替代方案。為 ROM 建立一個自定義連結指令碼，將所有 kobjs 與連結到晶片 RAM 的第一頁的 BSS 部分連結在一起。然後，引導程式碼需要將初始化值複製到此頁面。在以後的階段，在具有 MMU 的機器上，將 ROM 和 BSS 部分重新對映到快速 RAM。
在 _start.c 檔案中，您將擁有以下內容
const IPTR UtilityBase_offset = LIBBASESIZE+1*sizeof(APTR);
const IPTR GfxBase_offset = LIBBASESIZE+2*sizeof(APTR);
然後程式碼應該執行
#include <proto/utility_rel.h> #include <proto/gfx_rel.h> in case of #include <proto/utility.h> #include <proto/gfx.h>
gfx_rel.h 將 #include <inline/gfx_rel.h>
在 inline/gfx_rel.h 中，您將擁有以下內容
static inline void RectFill(...)
{
extern const IPTR GfxBase_offset;
struct GfxBase *GfxBase = (struct GfxBase *)((char *)(GET_A6)+GfxBase_offset);
AROS_LC5NR(void, RectFill, ...)
}
此最後一段程式碼無需內聯也可以用作靜態連結庫中的存根。連結庫將被稱為 libgfx_rel.a 等。
如果您檢視分支 branches/ABI_V1/trunk-genmodule_pob/AROS/tools/genmodule 中的儲存庫，您應該在那裡找到大部分基礎結構。只有 GET_A6 被稱為 GET_LIBBASE，並且在 aros/$cpu/cpu.h 中實現為內聯 asm（目前僅限 i386）。問題是，它無法在不破壞 i386/x86_64 中的 bin 相容性的情況下引入主幹，因為現在沒有為該目的分配暫存器。
這會將自動開啟的庫移動到 LibBase，移出 BSS，從而使構建可 ROM 化庫的過程變得更容易。無需對現有庫進行任何程式碼更改，也不需要更改任何 ABI。
我認為您需要將 LIBBASE 作為引數顯式傳遞給函式。您仍然可以執行此操作並將其放入 A6。唯一的怪癖是 .conf 檔案中未列出的回撥，例如，它希望獲取庫開啟的 libbases 的控制代碼。這是如何處理的？或者這些回撥應該在 .conf 中指定？ReadStruct/WriteStruct 是很好的例子。它們的回撥例程（在 Hook 結構中）可能希望與 LibBase 類和 DOSBase 進行通訊。
基本上，當前使用 libbases 的所有程式碼也應該提供使用 _offset 變數的替代程式碼。因此，在 ABI V1 分支中，現在為每個庫生成 libxxx.a 和 libxxx_rel.a 靜態連結庫。前者將為庫中的函式提供使用全域性 libbase 的存根，後者使用 _offset 的存根。如果您使用後者 lib 連結程式碼但未定義 _offset 變數，則會出現連結器錯誤。m68k ROM 模組需要連結 -lxxx_rel（或使用libs=xxx_rel）。
對於鉤子，我認為我們需要提供支援，以便在鉤子資料中儲存 A6/LIBBASE，並透過一個特殊的支援 HOOK 函式來恢復它。不知道這是否可行，以及是否會影響可以傳遞的引數數量。
對於我檢視的鉤子（datatypes.library），LibBase 已經在 Hook 的 h_Data 中了。所以我只是添加了
struct DataTypesBase *DataTypesBase = hook->h_Data;
在鉤子的開頭手動新增，一切正常。
（我有一個 datatypes.library 的補丁，它使它可 ROM 化，使用“#define hack”，將 LibBase 顯式地放在 LIBBASETYPE 中，並在庫的初始化時顯式地開啟它們，並按上述方式修改鉤子例程。
可以重新設計 BHFormat，使其在從 CLI 執行時不開啟 muimaster.library 嗎？系統可以提示插入不同的磁碟。可以包含 CLI 版本的格式化工具。可以重新設計 System/Format 以消除一些依賴項，或者至少與基本庫一起工作（我認為 iffparse 或 datatypes 不應該需要格式化，但它們是 muimaster.library 的子依賴項）。如何重新設計 BHFormat 以使其具有 ./configure 選項，以便僅使用 gadtools.library 而不是 MUI Master？無論如何，我必須在 ROM 中擁有 gadtools 用於 AmigaOS 3.x。
我應該努力將哪些庫製作成可 ROM 化的？
C/Shell - 是的！Shell 是一個不錯的選擇，因為它在原始的 Kickstart 中，並且在沒有啟動序列的情況下啟動，它允許你執行操作而無需訪問硬碟，這是一個不錯的候選物件。
Libs/arosc.library - 我想，由於 arosc.library 可能被各種程式和系統元件使用，因此將其放在 ROM 中以能夠從 shell 啟動各種應用程式會很有趣。
Libs/datatypes.library - 我認為這需要磁碟上的 datatypes，所以我不確定將其放在 ROM 中是否有很大幫助。擁有它很好，因為需要它的程式不會載入失敗，但是由於不會載入任何資料型別，所以我認為沒有必要。
Libs/muimaster.library - MUI 使用外部類，我不知道它是否允許在沒有外部類的情況下載入應用程式。如果可以，那麼它可能有用，但如果不行，則跳過它。有很多依賴項。
Libs/asl.library - 使用更新的 Shell 和自動完成功能，這可能會非常方便……
Libs/diskfont.library - 優先順序不高。如果你想從磁碟載入字型，你也可以將 diskfont.library 儲存在同一磁碟上。
Libs/gadtools.library - 這對於一些基本應用程式可能有用。我不記得它是否在預設的 Kickstart 中存在，如果不存在，那麼它的優先順序就不那麼高了。KS 3.0 似乎需要它在 ROM 中。以及 If、EndIf 和一些其他命令。
System/Format - 如果你有一個能夠訪問可寫介質的系統，那麼你將能夠訪問 ROM 外部的檔案。擁有它是一件好事，但恕我直言，“格式化”不是優先事項。
可 ROM 化 shell 命令的基本基礎設施。不過，似乎存在對齊問題，因為有時它可以正常工作（將“shellcommands”新增到 KRSRC），有時會掛起。有人可以審查我需要對 workbench/c/shellcommands/Shell 進行的“純”更改嗎？測試構建的 shell，它似乎可以執行簡單的任務。
起初，發現用 .bss 和 .data 自由的 Pure 風格程式設計有點困難，因為我來自一個有 MMU 的作業系統（Linux），在那裡共享的可執行頁面很容易，並且 -fPIC 編譯器實際上可以工作。但現在我真的很喜歡 Pure 風格，對於 AROS，我們應該更多地推廣這種風格和優勢。這裡有一些 Pure 最好的部分，僅供參考
所有 Pure 程式/庫都可以
- 將其 .text 段標記為只讀
- 連結到 ROM 中
- 可以有多個相同物件的執行，例如 Shell[1]、Shell[2]、Shell[3] 都共享相同的 .text 段
由於上述原因，對於低記憶體系統，Pure 絕對是一個勝利。在理想的世界裡，編譯器不支援 BSS 或資料段。所有這些 MMU 技巧等等都只是為了程式設計師的懶惰而提供的變通方法。不要讓我開始談論垃圾回收;-）是的，用 Pure 編碼工作量稍微大一些，但我認為這是值得的。我完全不同意。在我看來，編譯器和/或構建基礎設施應該使純程式能夠使用全域性變數、自動開啟庫等成為可能。那麼，這將需要一個“-fPIC Data”風格，對嗎？其中 .text 段可以連結到任何位置，並且有一個“任務全域性”（要麼是 struct Task 的成員，要麼是暫存器）指向任務的“私有” .bss/.data 區域。這實際上類似於 Amiga BCPL 的支援，並且 tc_GlobVec 指標將只是要使用的欄位，因為它本質上提供了相同的服務。但我不想成為為所有支援的 AROS 架構實現編譯器更改以實現此目的的人。我更傾向於使用一個暫存器來儲存全域性指標。它也將是用於 libbase 的相同暫存器，因為它具有類似的功能。在 i386 ABI V1 中，我為此使用了 %ebx；它是一個棧指標 *(%ebx) 是儲存基地址的地方。對於 m68k，將使用 A6。
-fPIC 在大多數架構下的 ELF 中希望使用“全域性偏移表”和位置無關程式碼（這會佔用另一個暫存器）。要製作“-fPIC-data” - 我不確定如何輕鬆地做到這一點。在 adtools 的 gcc 中有一個 --baserel 選項，但我對它的瞭解僅限於它存在。
另外，我認為在 ABI V1 分支中，基地址是為了使這成為可能。請儘量限制你轉換為這種 Pure 方式的程式碼。
連結器可以合併 ROM 中相同的字串嗎？我注意到 ROM 中充滿了 dos.library、intuition.library 等字串？（以及各種除錯字串）。這難道不是 exec.library 的 TaggedOpenLibrary() 的目的嗎？它接受一堆幻數併為該數字執行相應的 OpenLibrary("blah.library")。這將解決重複字串的問題。
僅在真正需要向後相容性時才手動開啟庫。不要為了好玩而這樣做。主要目標是使程式純淨。這意味著 - 它現在可以使用 C:Resident 駐留。該命令非常小，我認為這是一個好主意。它與程式大小無關。問題是儲存庫中的程式碼經常被程式設計師作為開始新專案的起點。這樣，不良習慣就會傳播開來。過去，我花費了大量時間來消除這些手動開啟庫的操作，這些操作通常充滿了錯誤，因為異常子句不在常見程式碼路徑中。每次看到這段程式碼被重新新增，我都會感到非常痛苦。在 ABI V1 中，我確實考慮實現一個編譯開關，允許建立無需執行任何操作即可包含的程式。
現在支援自動配置引導 ROM，UAE uaehf.device 正確初始化，但在初始化 dos.library 時崩潰。AROS dos.library 似乎是正常的自動初始化庫，但官方 ROM 的做法有所不同。好吧，實際上發生的事情是引導塊返回 D0（錯誤程式碼）和 A0（指向 Resident rt_Init 結構的指標），並且引導塊載入程式應該使用傳入的 rt_Init 呼叫 MakeLibrary()。（假設引導塊返回 D0==0，那麼它也返回了 A0 中的 Resident InitTable）。
所有自動引導硬碟的引導 ROM 程式碼在引導階段結束時執行以下操作
d0 = FindResident("dos.library");
move.l d0,a0
move.l RT_INIT(a0),a0
jsr (a0)
aros dos rt_init 包含初始化表，而不是程式碼 -> 崩潰。dos rt_init 程式碼“手動”初始化 dos.library。InitResident() 未用於此。（dos 很奇怪，即使在 BCPL 消失之後）。首先要做的是為 genmodule 新增一個選項，以便它能夠生成不依賴於 RTF_AUTOINIT 標誌的庫。其餘部分非常簡單。它不會損害其他埠。我為資源實現了反向操作（選項 resautoinit），它用於 battclock.resource。這很容易。可以使用現有的 genmodule 程式碼來處理資源。
如何在不破壞非 m68k 構建的情況下執行此操作？如何停用自動初始化並將初始化程式碼指標放入 rt_init 中？硬碟引導程式碼在自動引導 ROM 中包含最終的 jsr 或 jmp。它無法被修補。
軟盤引導程式碼確實在 A0 中返回 dos resident。這意味著它可以在不觸碰 dos 的情況下修復。
但沒有任何東西可以阻止軟盤引導塊也包含 jsr(a0)，它不會返回，它只是這樣設計以允許 strap 在啟動 dos 之前釋放臨時資源（引導塊緩衝區、trackdisk 等）。
請注意，用 AROS dos.library 替換 AOS dos.library 不會起作用，因為它在與檔案系統、啟動程序（如 Shell/CLI 東西）以及可能的其他東西互動方面存在很大的不相容性。
MorphOS dos.library 基於 AROS，但與 AOS 的相容性要高得多。你使用它會更有運氣。也就是說……除非你想使用其他 AROS 元件（如使用 FSA 資料包 API 的檔案系統），它們將不再起作用。
目前最新的問題是 NewAddTask() 簡單地錯誤地獲取或讀取啟動引數（啟動 PC 等）並由於錯誤的初始 PC 而崩潰。
初始 ROM 是否可以主要作為基於磁碟的模組的載入程式？我很樂意這樣做，但 afs.handler 依賴於 Intuition，Intuition 依賴於 Graphics、Layers，哎呀……這可能可以更改，以便 afs.handler 僅在處理程式想要顯示請求者時 Intuition 已載入的情況下開啟並使用 Intuition。它之前已經檢查了第一個 Intuition 螢幕是否已開啟。
workbench/libs/partition 是否應該在 rom/partition 中？是的，整個原始碼樹可能需要清理，並且之前在這個開發列表中討論過這個問題。它看起來像是你想要的一個元件，以便能夠從 m68k 上的硬碟啟動。它不是必需的，這是自動引導硬碟驅動程式的任務。（讀取分割槽表、新增分割槽、在 RDB 中新增可能的檔案系統）。當然，我們不需要用未來的 ROM 內建驅動程式來模擬這一點。在現有的埠中，它被 strap 模組用於掛載分割槽，因此它需要成為核心的一部分（或者更準確地說，由引導載入程式載入）。
啟動優先順序已儲存在分割槽表中。僅在 RDB 中儲存。它不會以任何方式儲存在 CD、USB 快閃記憶體等上。傳統上，未分割槽可移動介質（如 CD 和軟盤）的優先順序取決於其所在驅動器的分配優先順序。可引導 USB 快閃記憶體盤在 RDB 中使用 SFS，因此具有與內部硬碟相同的優先順序。MBR 分割槽不儲存優先順序，但無論如何也不建議將其用於可引導卷還有其他原因（例如，無法選擇自定義裝置名稱）。
所有現有的圖形 HIDD 似乎都包含不可 ROM 化的 attrbases 表。（可寫資料和 bss）。我們實際上在 m68k-amiga ROM 上有一個 BSS（討厭）。如果您只需要處理 BSS，我們就可以了。關於效能損失的說明/警告。如果在可 ROM 化程式碼中使用 Hidd 存根，則現在不會生成錯誤/警告，但當它們正在使用時，效能會急劇下降。它們不會只初始化一次 methodID，而是在每次使用這些存根時都會呼叫 oop.library/GetMethodID()。這不可能很快……；) 明白了。我需要找到一種（乾淨的）方法來為類中所有存根的區域分配記憶體()，以用於儲存它們的 MID。（僅供其他人瞭解，此減速僅會影響 m68k-amiga）。剛剛提交了對 Intuition、Hyperlayers 和 Graphics 的更改，消除了它們需要 .BSS 和 .DATA 段的需要。這對於將 AROS 放入 UAE 的兩種 ROM 分割方法是必需的。
是否有某種框架用於編譯和連結 ROM 內建駐留命令？（至少新增駐留和朋友似乎已實現。關於純二進位制檔案，請檢視 C:Dir，一些我從 MorphOS 反向移植的命令是純的。簡而言之，它們不使用啟動程式碼和任何全域性變數。這是事實的）。
大多數 KS2.0+ 可引導磁碟需要內建駐留命令，我猜引導 shell 也應該是一種駐留程式。workbench/c/shellcommands 中的程式可以整合到 shell 二進位制檔案中。檢視那裡的宏。它們在 shcommands_notembedded.h 中定義。還有一個檔案，shcommands_embedded.h。我不知道使用此功能需要什麼。看起來很久沒人嘗試過了。
檢視 AROS/workbench/c/shellcommands/ 下，您會找到使用 AROS/compiler/include/aros/shcommands_notembedded.h 中定義的一組宏的程式。
這些宏公開了一個介面，應在 shcommands_embedded.h 中重新實現該介面，以便生成可以嵌入 ROM 的程式。
截至目前，這些宏讓您可以毫不費力地生成可重入程式碼，除非您想按原樣將生成的的這些檔案嵌入 ROM 並對其使用 LoadSeg()（這可能是一個可行的選擇，具體取決於您的需求），否則請編寫這些宏的嵌入版本。
這些宏公開了一個介面，應在 shcommands_embedded.h 中重新實現該介面，以便生成可以嵌入 ROM 的程式。DOS/AddSegment() 也將非常有用。必須將 FindSegment() 掛接到 LDDaemon 以完成圖片……) 我將確保在 LDDaemon 中將 FindSegment() 的優先順序設定得*低於*磁碟上的可執行檔案，以便我們不會鎖定 ROM 版本。
Amiga IDE 支援也包含在我的“儘快實施”列表中。我是否需要在現有的 ata.device 中新增 #ifdef，還是需要做其他事情？（它似乎過於特定於 PC 硬體，而不是完全模組化的）。我會為 Amiga 建立一個單獨的模組。ata.device 是一個“敏感”；) 主題 - 它已經被嘗試改進的人多次破壞，並且在更改後似乎總是不夠的測試人員可用；)
大多數這些故障都是由於需要而發生的，因為舊程式碼嚴重受限/設計不佳 - 我個人認為它現在執行得非常好，因為幾乎沒有關於它無法執行的報告 - 如果有的話。唯一（恕我直言）仍然需要做的事情是更正初始探測程式碼，以便在找到帶有連線裝置的 pci 控制器的情況下，不要新增尚未與 ata 控制器關聯的舊埠。
我不確定 amiga 的內部 ide 實現有多麼不同 - 但我想可以將不同的部分（探測、直接程式設計晶片組）移動到單獨的檔案中，並且僅在您的特定構建中包含這些部分..例如 dma_amiga.c
我也不知道 elbox 快速 ata 等控制器的工作原理，但如果 AROS 能夠支援它們也很好（我還有 2 個，以及 2 箇中介 PCI 匯流排板）。
我檢查了 1.3 和 3.1 的 NKD 自動文件，在這兩種情況下，這些函式都被描述為返回 BOOL。請注意，AROS 旨在與 3.1 相容，而不是與 1.3 相容。如果需要此類更改，您可能需要將 dos 庫完全分離到 arch 樹中。
我還認為此更改可能會破壞現有埠的二進位制相容性（BOOL 為 2 位元組 AFK，而 LONG 為 4 位元組）。1.3 和 3.1 的 NDK 自動文件，在這兩種情況下，這些函式都被描述為返回 BOOL。請注意，AROS 旨在與 3.1 相容，而不是與 1.3 相容。如果需要此類更改，您可能需要將 dos 庫完全分離到 arch 樹中。
我該如何處理 dos.conf？Lock/Open（以及其他）不再是別名。（dos.conf 未提交）我認為最簡單的方法是在 rom/dos/ 中為別名函式建立存根檔案，然後您可以檢查不包含別名的 dos.conf。
DevCD NDK 2.0 和 3.1 dos_protos.h：
WB3.0 C:Assign 似乎執行以下操作：如果 (AssignLock(whatever, NULL) != DOSTRUE) 則列印“無法取消 >
測試 KS 3.1 CreateNewProc()：CreateNewProc() 的 NP_Arguments 標記不會新增“\n”。Input() 確實返回 NP_Arguments 引數流。RunCommand()：相同的結果。不新增“\n”，Input()+FGetC() 返回命令引數。存在細微差別：（可能是由於不同的輸入控制代碼）CreateNewProc() FGetC() 在引數流結束時返回 EOF。RunCommand() FGetC() 等待更多字元（在 CLI 中按回車鍵返回一個換行符）SystemTagList() 測試結果：它似乎執行所有操作（或者它是 shell 執行的？）命令和引數之間的所有空格（空格和製表符）都被吞併。尾隨空格不會被吞併。如果“\n”已存在於引數字串中 = 引數字串的結尾。如果引數字串中沒有“\n”= 在末尾新增一個。CreateNewProc() 的 NP_Arguments 標記不會新增“\n”。Input() 確實返回 NP_Arguments 引數流。此外，如果沒有在引數字串的末尾新增“\n”，RunCommand() FGets() 不會返回，直到按下回車鍵。
C:Run 執行此操作（也許其他操作也是？）
olddir = CurrentDir(toclone);
cis = Open("", FMF_READ);
CurrentDir(olddir);
這在 dos 資料包模式下無法工作。CurrentDir() 獲取並返回檔案鎖，Open 返回檔案控制代碼。
複製控制檯控制代碼（並且僅複製控制檯控制代碼）的 Dos 資料包方法是
old = SetConsoleTask(((struct FileHandle*)BADDR(toclone))->fh_Type);
cis = Open("*", MODE_OLDFILE);
SetConsoleTask(old);
我們需要複製控制檯控制代碼的特殊函式嗎？或者如何解決這種不相容性？（至少在每個人都切換到 dos 資料包之前）目前 AROS C:Run 掛起，WB2.x/3.x 版本工作。
dos.library/MatchNext 在完成時並不總是返回 ERROR_NO_MORE_ENTRIES。（“退出 for(;;) 迴圈 -> MakeResult”不會設定 ERROR_NO_MORE_ENTRIES）它使 WB3.x:C/Dir 困惑。如果目錄條目數為奇數，則“(null)”出現在最右列。沒關係。這不是 MatchNext 錯誤（它工作正常，我又一次失明瞭）它是 WB3.x:C/Dir 錯誤使用(?) VFPrintf (RawDoFmt)，期望 %s 帶有 NULL 指標（而不是指向空字串的指標）在輸出中不產生任何內容。KS 3.1 已確認，如果字串指標為 NULL，則 RawDoFmt 完全忽略 %s。它也不會嘗試訪問地址零（已透過 UAE 記憶體觀察點確認）
jsr %a6@(76 * -6) /* Exec/DoIO() */
已經多次注意到這一點。請使用命名常量而不是數字和註釋；這樣，編譯器可以檢查偏移量是否正確，並且人們知道您正在呼叫哪個函式。首先我必須說：gcc 680x0 彙編語法很糟糕。（至少對於 1980 年代開始使用匯編語言為 Amiga 編寫程式碼的人來說..）。對此表示抱歉，但我不知道（或不想知道，見上文）如何建立有效的常量。這是 Jason 的問題：D
GCC 68k 也自動理解 Motorola 68k 語法。您可以編寫 jsr -(76*6)(a6) 最佳情況是將 68k 彙編程式碼作為單獨的檔案編寫。GCC 彙編檢測用於小型 .s 或大型 .S，如果您的彙編檔案具有大型 .S（例如檔名為 myasm.S），則 C 定義預處理器也可以在彙編程式碼中使用。
#define offset -76 #ifdef ... jsr offset(a6) #endif
Open() FMF_x 引數在 m68k-amiga 下存在問題。（在 rom 模組和 aros 應用程式內部的許多地方使用）。它破壞了 SnoopDos，以及可能所有其他接管 dos/Open() 向量 的程式。
a) 完全刪除它們？（它們實際上真的被使用了嗎？）。選擇這個。據我所知，新模式從未在 Open() Autodoc 中記錄過。它們在文件中也有記錄，並且也經常使用。我的意思是“使用”是指“實際上執行與在資料包處理程式中僅轉換回 ACTION_FIND* 或在 afs.handler 的原始非 dos 資料包版本中大多數標誌被忽略不同的操作”。不介意擁有某種帶有新的更好/擴充套件模式標誌的 NewOpen()，但使用原始 Open() 以及完全不同且不相容的模式引數是不對的。
b) 新增一些包裝器，在呼叫 Open() 之前將 FMF_ 內容轉換為原始 MODE_xxxx 引數。（而不是將它們包裝在 Open() 內部，這就是它在 dos 資料包模式下當前的工作方式）
我的建議……
1) dos.library 應該沒有擴充套件，以便與 AmigaOS 3.1 達到二進位制級別相容（我多年前實現的該擴充套件也應該在二進位制上相容，但我沒有考慮到會 SetFunction() 一些 dos.library 函式並接管它們的程式。
2) 可以實現 arosdos.library，或一些 hidd，或其他一些實現擴充套件的東西。
方案如下
dos.library -----> packet wrapper ---\
\
> aros dos handler
/
arosdos.library ---------------------/
每個 aros dos 處理程式應該有一個數據包處理程式包裝器。如果 dos 處理程式僅基於資料包（來自 AmigaOS 的埠），那麼一個特定於 aros 的資料包.handler 將充當它的包裝器，我認為現在就是這樣。
現在刪除這些標誌的直接結果是，我們將失去 arosc.library（或 Staf 的修改中如何稱呼它）的功能，因為它們是在 dos.library 級別以系統範圍的方式實現的，例如檔案追加。管道檔案將不再工作（但它無論如何都需要重新設計，因為它非常過時並且實際上執行不佳）。
想法是做到“面向未來”，而不是固守舊的Amigados資料包處理器。但是，如果沒有一個明確的“新DOS”專案來推動發展，那麼唯一可行的選擇是：要麼保持現狀，嘗試找到與AROS方式和AmigaOS方式相容的方法，要麼直接採用AmigaOS方式。
這是正在使用的對映
#define FMF_MODE_OLDFILE (FMF_AMIGADOS | FMF_WRITE | FMF_READ) #define FMF_MODE_READWRITE (FMF_MODE_OLDFILE | FMF_CREATE) #define FMF_MODE_NEWFILE (FMF_MODE_READWRITE | FMF_LOCK | FMF_CLEAR)
如您所見，MODE_NEWFILE也會在檔案不存在時建立檔案，並在檔案存在時清空它，因此您不應在那種情況下使用它。對於所有情況，請改用MODE_OLDFILE。
如何處理從棧中分配FileInfoBlock結構體的AROS程式碼？這不能保證所需的LONG對齊（BPTR和m68k-amiga）。用AllocDosObject()替換它們？但這又增加了另一個記憶體分配測試和記憶體釋放呼叫，我認為它使簡單的程式碼變得太複雜和醜陋了。
新的宏從棧中分配+隱藏對齊技巧？（最好是也適用於其他DOS結構（如InfoData）的宏）。
像（來自c/dir.c）這樣的程式碼
UBYTE _fib[sizeof(struct FileInfoBlock) + 3]; struct FileInfoBlock *fib = (APTR) (((IPTR) _fib + 3) & ~3);
恕我直言，太醜了..
恕我直言，只需使用AllocDosObject()，因為分配。這真的是GCC的問題嗎？對於很多東西，從int和long都有對齊選項 - 而且FileInfoBlock以LONG開頭（-malign-int）。
無論如何，2.0之前引入的所有DOS結構都應該使用AllocVec()分配，因為這是BCPL的方式。
嘗試啟動Workbench 1.3 ADF。我能夠載入'Shell-Seg' Shell DOS程序，但它正在使用（幾乎不可能用谷歌搜尋到的）dos.library *BCPL*介面。
我認為提供從1.3 BCPL介面到庫介面的“thunk”並非不可能。這只是一件小事而已。
如果……我們能找到文件……
這是一個轉儲，我在其中用除錯呼叫替換了BCPL Action例程（儲存在暫存器A5中）的存根。即
BCPL_Action 600 (0x77f6c, 0x1f007, 0x1f018, 0x1f033)
D0 D1 D2 D3 D4
D0 = BCPL routine to call
D1..D4 arguments
[LoadSeg] Loading 'L:Shell-Seg'...
Try Function 00f93158
[ELF Loader] Not an ELF object
[InternalLoadSeg] FAILED loading 0001c8ee as an ELF object.
Try Function 00f92720
read_block(file=116974, buffer=00069e6a, size=4, func[0]=00059bb2)
buf=00069e6a, subsize = 4 (of 4)
HUNK_HEADER:
Hunk count: 1
First hunk: 0
Last hunk: 0
Hunk 0 size: 0x001ba8 bytes in ANY memory
HUNK_CODE(0): Length: 0x001ba8 bytes in ANY memory
HUNK_END
[InternalLoadSeg] Succeeded loading 0001c8ee as an AOS object.
[LoadSeg] segs = 0001c905
pr_GlobVec = 0007c660
BCPL_Action 600 (0x77f6c, 0x1f007, 0x1f018, 0x1f033)
BCPL_Action 608 (0x0, 0x1f007, 0x1f018, 0x1f033)
BCPL_Action 696 (0x303782bc, 0x3ef0b3, 0x1f018, 0x1f033)
BCPL_Action 700 (0x11215381, 0xf, 0x1f018, 0x1f033)
BCPL_Action 700 (0x14, 0xd6847a03, 0x11215381, 0x1f033)
BCPL_Action 700 (0x48e72022, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 712 (0x0, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 700 (0x48, 0xffffffff, 0x11215381, 0x1f033)
BCPL_Action 700 (0xc, 0xd6847a03, 0x11215381, 0x1f033)
BCPL_Action 708 (0x0, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0xe1898283, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x2, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x303782bd, 0xffffffff, 0x44854e04, 0xffffffff)
BCPL_Action 708 (0x0, 0xffffffff, 0x44854e04, 0xffffffff)
...
aminet.net上的'BCPL4Amiga.lha'檔案是*寶藏庫*
- 如何呼叫BCPL例程
- BCPL棧幀如何工作（eww！！！）
- D0/A1是什麼（它不是我所想的！）
- 幾乎所有pr_GlobVec AmigaDOS偏移量都做了什麼！
我認為我可以從這裡建立一個BCPL思維庫，沒問題！
如果我能新增此支援，它將使AROS m68k能夠執行所有Amiga 1.0-1.3 BCPL CLI命令！
在我等待Toni完成圖形驅動程式時，這將給我一些事情可做。
這個可能也有幫助。
實際上，在這種情況下，我相信Amiga Guru Book的印刷英文版本將是最好的資訊來源。
嗯，實際上C=團隊試圖從AOS中刪除所有BCPL內容，並明確地用C等效項替換了所有相關的CLI命令，這些命令透過DOSBase而不是GlobVec進行 - 如果我理解正確的話，在V37中只有4個BCPL處理程式在L：中保留。所有剩餘的GlobVec遺留程式碼都在dos.library之上重新實現 - 因此也避免了保留跳轉表本地副本的選項，該跳轉表具有針對跳轉向量的修改條目。
擁有一個全域性（或本地）的非基於庫的向量作為跳轉表，其中包含公共和私有資料條目、BSS以及程式不同模組的覆蓋載入能力，嗯，它可以被認為是兩者兼而有之：非常靈活或完全損壞;-）Guru Book“BCPL和全域性向量”的“第16章”以一句引言開頭：“如果你理解它，它就過時了。”
恕我直言，擁有所有基於C的標準CLI命令和來自V37及更高版本的FileSystem驅動程式比舊的BCPL內容更有用。
AOS 1.0-1.3程式碼/工具不會為“Frankenrom”提供任何缺失的功能。
當然，其他非OS BCPL程式碼的相容層可能有用 - 但再說一次，它可能只與特定硬體驅動程式相關，而這些驅動程式在UAE或大多數Amiga型號上都不可用。
基本上只是對於任何不瞭解V37且需要GlobVec而不是-1的內容。這值得額外的開銷嗎？
MorphOS如何（好）實現BCPL遺留程式碼？或者最多隻能獲得GlobVec -1？
我同意，但我未公開的目標之一是讓AROS M68K能夠執行Amiga Forever附帶的所有Workbench ADF。
此外，許多“雜誌磁碟”使用L:Shell-Seg。我現在將致力於僅支援來自AOS 1.3的L:Shell-Sig，因為這將為AROS m68k作為ROM替換帶來最大優勢。
BCPL thunk程式碼目前似乎沒有佔用太多程式碼空間，我將其放在arch/m68k-amiga/dos/中，因此它不會影響任何其他埠。
不要啟用32位快速RAM板，由於一些未知原因，如果啟用它，引導會掛起。這現在已修復。NIL處理程式中正常的指標到BCPL轉換錯誤，僅偶然起作用。（找到這個花了很長時間..）我想BCPL指標錯誤將是最常見的錯誤，因為沒有其他埠需要它們。也許可以新增一些BCPL指標除錯檢查宏？例如，在轉換為BCPL指標時檢查指標的最低兩位是否為零，並檢查BCPL指標是否指向預期的記憶體範圍？（如果轉換了兩次或丟失，它們幾乎總是指向不存在的RAM）
除了原始的Commodore BCPL WB 1.x程式和相關的軟體（如處理程式）之外，沒有其他程式。（除了Commodore之外，還有人擁有BCPL編譯器嗎？）它很可能沒有阻止非BCPL程式使用BCPL功能。問題是找到它們（可能是非常舊的PD磁碟系列？）
應該記住，BPTR在（所有？）其他埠上並不真正存在..
它是第一個透過diskfont.library/newfontcontensts.c開啟的檔案。不知道具體是哪一個，檔名是20。
+ ((BPTR*)BADDR(hunktab[last]))[0] = BNULL;
當分配hunktab時，這應該已經被清零了。但它似乎沒有清零，或者後來被覆蓋了。
我添加了一些額外的除錯訊息，例如KrnUnregisterModules，這裡有一個可能有所幫助的除錯日誌，您可以從地址中看出它是在64位機器上
[InternalLoadSeg] Succeeded loading 0000000040725b80 as an ELF object.
FixFonts Loading 20
Hunk count: 1
allocmem 0000000040725bb0 24
First hunk: 0
Last hunk: 0
Hunk 0 size: 0x001ff4 bytes in ANY memoryallocmem 000000004091d3b0 8192
@000000004091d3b4
HUNK_CODE(0): Length: 0x001ff4 bytes in ANY memory
HUNK_RELOC32:
Hunk #0:
HUNK_END
freemem 0000000040725bb0 24
[InternalLoadSeg] Succeeded loading 0000000040728240 as an AOS object.
[KRN] KrnUnregisterModule(0x0x4091d3b4)
[KRN] Next segment pointer 0x0x4091d3b4
[KRN] Next segment pointer 0x0x754eff7000
[KRN] Trap signal 11, SysBase 0x406455b8, KernelBase 0x40646600
[KRN] Process 0x4072d590 (FixFonts)
RSP=000000004094cf30 RBP=000000004094cf50 RIP=00000000404aac0c
RAX=000000754eff7000 RBX=00000000405202a8 RCX=00007f0e99a91770 RDX=0000000000000000
RDI=00007f0e99d36860 RSI=0000000000000000 RFLAGS=0000000000010246
R8 =00007f0e9a140700 R9 =00000000404dc320 R10=0000000000000000 R11=0000000000000246
R12=000000004071f9f0 R13=000000004071f910 R14=000000004072d6f8 R15=0000000000000000
許多AROS程式都有這個
AROS_UFH3(__startup static ULONG, _start,
AROS_UFHA(char *, argstr, A0),
AROS_UFHA(ULONG, argsize, D0),
AROS_UFHA(struct ExecBase *, sysbase, A6))
{
<stuff>
}
A6在m68k-amiga埠中不包含也不可能包含SysBase。它包含BCPL魔法（實際上大多數地址暫存器都包含未公開的BCPL內容），並且無法在執行時檢測正常程式和BCPL程式之間的區別。（有些程式可以先進行正常的C啟動，然後稍後執行BCPL內容..）是否有任何埠*沒有*使用者空間可以訪問的全域性SysBase？在m68k上，在程式啟動和庫初始化時獲取SysBase的唯一方法是透過絕對地址$4嗎？我認為應該有一種方法可以將SysBase傳遞給新程式或庫，而無需使用絕對地址。後者在託管平臺上尤其困難。作為最後的手段，我們可以在loadseg期間再次執行此操作，以便符號名稱SysBase透過載入程式獲得正確的值。不過，我更喜歡當前的解決方案。
初始化sysbase的loadseg方式？沒什麼。如果您檢視InternalLoadSeg_ELF，它已經處理了這種情況：rom/dos/internalloadseg_elf.c:第388-406行。因此，只有（a）HUNK架構（b）沒有全域性SysBase需要將SysBase傳遞給它們。我認為AROS下沒有任何這樣的架構。可執行檔案的錯誤剝離將使其無法使用。這與我們計劃將來切換到ELF可執行檔案而不是可重定位物件的事實相結合。我們仍然需要檔案中的重定位資訊。
不幸的是，Intuition和層存在其他m68k構建問題，導致gfx HIDD測試無法進行。OpenScreen()內部機制無法工作。它已經部分修復，但至少還有一個問題仍然存在。
更重要的問題是我似乎無法使滑鼠工作（軟體或硬體）。IntuitionBase->ActiveMonitor始終為NULL，intuition/misc.c僅在它不為NULL時設定滑鼠。呼叫了MySetPointerPos()，當我移動滑鼠時滑鼠座標會發生變化。看起來圖形子系統認為滑鼠與其他主機視窗共享。aoHidd_Gfx_IsWindowed設定為FALSE。
如果舊的modeid不可用，openworkbench()會選擇640x200解析度，但仍然使用原始儲存的顯示尺寸。
這會導致在某些RTG模式已被儲存（例如1024x768）但我們現在停用（或移除）RTG板的情況下出現視覺問題（以及巨大的晶片RAM使用量），結果是在普通640x200解析度下出現巨大的Superbitmap原生晶片組螢幕。這非常煩人。如果模式丟失，它應該回退到原始標稱尺寸和深度。
也許引導選單螢幕選擇和openworkbench螢幕模式選擇應該合併？兩者都需要類似的特殊程式碼來選擇最佳模式，尤其是在使用Amiga硬體（PAL/NTSC/RTG）時
Amiga埠使用以下“預設”模式
- 640x256（PAL）或x512（隔行掃描）
- 640x200（NTSC）或x400（隔行掃描）
以上模式使用兩個或四個平面。是的，引導選單沒問題，但問題是初始螢幕（Shell）的預設解析度和aros引導影像解析度。在NTSC機器上為640x200，在PAL機器上為640x256。（但如果晶片組支援PAL/NTSC更改，則會將PAL和NTSC模式都新增到模式資料庫中 = ECS Agnus或更新版本）AROS m68k還添加了早期Picasso96驅動程式“RTG”支援，這意味著解析度為640x480。並非所有RTG Picasso96驅動程式都支援類似PAL或NTSC的模式解析度。只有gfx驅動程式知道哪個是最佳“預設”模式，除非在通用程式碼中新增一些醜陋的檢查（例如當前引導螢幕解析度選擇所做的那樣）。
最後，初始螢幕必須僅為2平面，原因是頻寬和晶片記憶體使用量的原因，但AROS引導影像為16色，並假定畫素為正方形（=需要隔行掃描）
其他受支援的平臺可以使用更簡單的解決方案，因為它們都支援至少256色螢幕，並且沒有巨大的VRAM/Blitter頻寬瓶頸。
僅在開啟引導螢幕影像時才需要隔行掃描和4平面（以獲得正確的縱橫比）在OCS/ECS晶片組上，使用4平面高解析度引導選單或初始Shell速度太慢。
也許gfx hidd中的一些函式可以被詢問類似“給我x的modeid+深度的陣列”，其中x = 引導選單、引導影像或初始Shell螢幕？（請記住，如果為平面模式，則需要深度）
640x480x8（如果為RTG模式，則可能不支援640x400或640x512）
Intuition/monitorclass.c/SetPointerPos()在HIDD_Gfx_SetCursorPos()座標中包含熱點偏移量，如果滑鼠精靈解析度與螢幕解析度不同，則在Amiga晶片組上不起作用。（最常見的情況是低解析度精靈和高解析度螢幕）
熱點應該以精靈解析度畫素為單位，而不是以螢幕解析度畫素為單位。
例如，如果熱點為-3，螢幕為高解析度，精靈為低解析度：精靈向左移動-3個高解析度畫素，但它應該為-6個高解析度畫素或-3個低解析度畫素。（HIDD可以輕鬆自動轉換，SetCursorShape已經包含熱點偏移量資料）
如果刪除SetPointerPos()“考慮HotSpot”並由HIDD處理熱點偏移量，則amiga-m68k原生滑鼠定位將在所有解析度下正確工作。
HIDD座標是精靈的左上角。圖形驅動程式不知道熱點（除了託管的，但它只用於輸入報告）。精靈座標應該以精靈的解析度提供。只是以前沒有單獨的精靈解析度。
精靈形狀解析度 != 精靈定位解析度。精靈形狀獨立於定位（至少在 AGA 上，ECS 和更舊的版本有限制）請記住，AGA 機器上的精靈具有獨立於螢幕解析度的定位解析度。這意味著即使在 LoRes 螢幕上，精靈也以 HiRes（甚至 SuperHiRes）解析度移動。不過，必須設定一個標誌才能使這種情況發生。預設設定是在 LoRes 和 HiRes 螢幕上使用 LoRes 精靈，在 SuperHighRes 螢幕上使用 HiRes 精靈。不過，解析度是針對所有精靈全域性設定的。
通常，精靈具有低解析度畫素，但具有高解析度水平解析度。
-> 圖形驅動程式需要知道熱點偏移量。（或者它需要知道滑鼠指標解析度，以便可以新增正確的偏移量）。精靈中沒有“熱點”。它只是一個精靈。熱點是 Intuition 的東西。這是否意味著精靈位置應該以點陣圖的解析度指定？好吧，在“定位解析度”中。猜測定位解析度 == 螢幕解析度。因此，Intuition 可以調整偏移量。事實上，移動滑鼠指標實際上是 MoveSprite()。我僅為方便起見添加了 monitorclass 方法。新增這些方法到 monitorclass 中是為了從 ChangeExtSpriteA() 中移除熱點規範。以前，熱點規範是那裡的私有擴充套件。請參閱 SVN 歷史記錄。
除非 Intuition 知道精靈解析度，否則它無法做到，這就是問題所在。精靈位置始終以螢幕解析度表示，這不是問題。（硬體可能不支援，但這不是 Intuition 的問題）
是的，這是一種非常倒退的做法（移動滑鼠而不是移動熱點），但正確的修復需要更新 Intuition 以使其知道滑鼠解析度，至少我不想觸碰那些東西。此快速修復至少使 Amiga 本地模式可用（據我所知，沒有其他人使用硬體游標，因此這不會影響其他平臺）
以下是視覺解釋，因為我仍然不確定我之前的解釋是否過於混亂。
Lets say we have following lores sprite image (standard mode in AOS) 00X00000 00XX0000 00XXX000 00XXXX00 It has hotspot offset of (2,0) Now lets see how it looks on hires screen at (0,0) (without hotspot offset, wrong positioning) S000XX0000000000 0000XXXX00000000 0000XXXXXX000000 0000XXXXXXXX0000 (with 2,0 _hires_ pixel hotspot offset, still wrong positioning. This is what happened previously) 00S0XX0000000000 0000XXXX00000000 0000XXXXXX000000 0000XXXXXXXX0000 (with 2,0 _lores_ pixel hotspot offset, or 4 pixel hires, finally we have correct hotspot positioning) 0000SX0000000000 0000XXXX00000000 0000XXXXXX000000 0000XXXXXXXX0000 (S = hotspot)
在：workbench/libs/icon/./diskobjio.c 中，sdd_Stream 是指向檔案的 BPTR、指向緩衝區的指標，還是兩者兼而有之？sdd_Stream 來自哪裡？這些東西來自編譯器/arossupport 中的大端結構讀取/寫入支援。流的型別可以是任何型別，具體取決於掛鉤函式希望它是什麼型別（傳遞給 ReadStruct() 等函式）。
icon.library 使用 dostreamhook()（在 support.c 中），它需要流為 BPTR（檔案控制代碼）。support.c/ReadIcon_WB() 執行初始 ReadStruct()，將“檔案”引數（BPTR）作為流值傳遞。
只有當圖示的 Gadget->MutalExclude 設定了 (1 << 31) 時，圖示調整大小才會生效，因此所有舊圖示都應繼續逐畫素顯示。
ilbmtoicon 現在接受 --dpi x:y 引數（預設為 72:72，舊的 Macintosh 桌面出版解析度），允許您指定圖示的預設解析度（以每英寸點數表示）。
這被轉換為 Amiga 顯示解析度刻度，以便 icon.library 邏輯不需要進行任何單位轉換。
圖示縮放有點粗糙，但對於 C 程式碼來說速度很快。（如果有人為 CyberGfx/ScalePixelArray 實現 HIDD 掛鉤，可能會更快）。
點陣圖圖示使用 BitMapScale() 進行縮放，ARGB 圖示使用 Bresenham 重取樣器進行縮放（在向上縮放時需要擴充套件到平均畫素），因為 BitMapScale() 似乎會覆蓋 ARGB 點陣圖的“A”部分。
正如我在提交訊息中提到的，我需要向 IconControl 新增一個額外的標記，以幫助 Wanderer 控制圖示縮放。
我們還應該在 Prefs/ScreenMode 中新增一個覆蓋，以允許透過 MonitorSpec ratioh/ratiov 引數調整螢幕 DPI/DPC。據我瞭解，顯示寬度/高度比率定義（或影響）畫素寬度/高度比率。例如，如果單個畫素預設是正方形，則以與物理提供的解析度不同的解析度執行顯示可能會改變該縱橫比。
根據我在 AOS 3.9 上的測試，無論螢幕模式如何（即使 1280x200 NTSC 的 ratioh=16，ratiov=16），MonitorSpec 的 ratioh/ratiov 都不變（即始終為 RATIO_UNITY）。
因此，我相信這些引數不反映畫素大小，而是顯示器本身的大小。
至於 DRI 解析度，我相信我釋出的方程很好地近似了 AOS 的行為，並允許擴充套件到其他顯示格式（寬屏、縱向模式等）
MonitorSpec ratioh 和 ratiov 是定點分數，由 RATIO_FIXEDPART 和 RATIO_UNITY 宏定義。
#define RATIO_FIXEDPART 4 #define RATIO_UNITY (1 << RATIO_FIXEDPART)
它們是什麼的比率仍然有點神秘。也許是“此顯示器”與 1084S 的比率？
這有點關係。MonitorSpec 的 ratioh 和 ratiov 在 AOS 上始終顯示為 RATIO_UNITY (1.0)，因此我將讓 AROS 這樣計算 ratioh 和 ratiov
#define C_1084_HEIGHT 198 /* mm */
#define C_1084_WIDTH 264 /* mm */
if (GetMonitorEDIDSize(..,&MonitorEDIDWidthMM, &MonitorEDIDHeightMM)) {
ms->ratiow = ((MonitorEDIDWidthMM)<<RATIO_FIXEDPART)/264;
ms->ratioh = ((MonitorEDIDHeightMM)<<RATIO_FIXEDPART)/198;
} else {
ms->ratiow = RATIO_UNITY;
ms->ratioh = RATIO_UNITY;
}
符合 VESA EDID 規範的顯示器將根據 EDID 資訊設定 MonitorEDIDWidthMM 和 MonitorEDIDHeightMM，其他所有顯示器將假定為 4:3 13 英寸顯示器。
螢幕的 DrawInfo 'Resolution' 引數（以“刻度”為單位）將計算為
res.x = 44*320/screen_pixel_width res.y = 44*256/screen_pixel_height
（對於 Amiga NTSC 螢幕，res.y 會略有不同，對於 200 行，值為 56 而不是 52，但這應該不是什麼大問題）
有了這些資訊，應用程式就可以計算顯示器的 DPI，如下所示：
#define C_1084_WIDTH_FIN 0xa6 /* 10.4 " * 16 in hex */ #define C_1084_HEIGHT_FIN 0x7c /* 7.8 " * 16 in hex */ DPI.x = (screen_pixel_width << (RATIO_FIXEDPART * 2)) / (ms->ratioh * C_1084_WIDTH_FIN); DPI.y = (screen_pixel_height << (RATIO_FIXEDPART * 2)) / (ms->ratiov * C_1084_HEIGHT_FIN);
…然後，將有足夠的資訊根據螢幕的 DPI 和縱橫比動態調整圖示大小。
MonitorSpec：ratioh、ratiov - 1084S 的大小與當前顯示器之間的比率（較大的分數表示較大的顯示器，較小的分數表示較小的顯示器）
DrawInfo Resolution：由於這與滑鼠刻度有關，因此此計算與整體 DPI 成反比，而不是與顯示器中的畫素數量成反比，這樣更有意義。
因此，DrawInfo.Resolution 將計算為
res.x = (1280 * 11 * ratioh / pixel_width) >> RATIO_FIXEDPART res.y = (1024 * 11 * ratiov / pixel_height) >> RATIO_FIXEDPART
螢幕 DPI 可以直接從 DrawInfo Resolution 計算得出，如下所示：
#define C_1084_WIDTH_CIN 104 /* 10.4 " in centi-inches */ #define C_1084_HEIGHT_CIN 78 /* 7.8 " in centi-inches */ dpi.x = (11 * 1280 * 10) / C_1084_WIDTH_FIN / res.x dpi.y = (11 * 1024 * 10) / C_1084_HEIGHT_FIN / res.y
螢幕 DPC（每釐米點數）計算如下：
#define C_1084_WIDTH_MM 264 /* 10.4 " in mm */ #define C_1084_HEIGHT_MM 198 /* 7.8 " in mm */ dpc.x = 11 * 1280 * 10 / C_1084_WIDTH_MM / res.x dpc.y = 11 * 1024 * 10 / C_1084_HEIGHT_MM / res.y
據我瞭解，顯示寬度/高度比率定義（或影響）畫素寬度/高度比率。例如，如果單個畫素預設是正方形，則以與物理提供的解析度不同的解析度執行顯示可能會改變該縱橫比。
我認為，在解釋圖形/顯示器中的類似值時，ILBM BMHD 塊中的 xAspect/yAspect 欄位是相關的。
參見：http://amigan.1emu.net/reg/ILBM.txt
“縱橫比的典型值為寬度：高度 = 10：11（Amiga 320 x 200 顯示器）和 1：1（Macintosh*）。“
以及來自 EA 的 ilbm.h
"/* Aspect ratios: The proper fraction xAspect/yAspect represents the pixel * aspect ratio pixel_width/pixel_height. * * For the 4 Amiga display modes: * 320 x 200: 10/11 (these pixels are taller than they are wide) * 320 x 400: 20/11 * 640 x 200: 5/11 * 640 x 400: 10/11 */ #define x320x200Aspect 10L #define y320x200Aspect 11L #define x320x400Aspect 20L #define y320x400Aspect 11L #define x640x200Aspect 5L #define y640x200Aspect 11L #define x640x400Aspect 10L #define y640x400Aspect 11L"
http://www.steguy.bravehost.com/Amiga_Files/V39_Support_Issues.txt
"-------------------------- getaspect -------------------------------
bmhd->xAspect = 0; /* So we can tell when we've got it */
if(GfxBase->lib_Version >=36)
{
if(GetDisplayInfoData(NULL, (UBYTE *)&DI,
sizeof(struct DisplayInfo), DTAG_DISP, modeid))
{
bmhd->xAspect = DI.Resolution.x;
bmhd->yAspect = DI.Resolution.y;
}
}
/* If running under 1.3 or GetDisplayInfoData failed, use old method
* of guessing aspect ratio
*/
if(! bmhd->xAspect)
{
bmhd->xAspect = 44;
bmhd->yAspect =
((struct GfxBase *)GfxBase)->DisplayFlags & PAL ? 44 : 52;
if(modeid & HIRES) bmhd->xAspect = bmhd->xAspect >> 1;
if(modeid & LACE) bmhd->yAspect = bmhd->yAspect >> 1;
}"
還有一個有趣的評論
http://vlists.pepperfish.net/pipermail/netsurf-commits-netsurf-browser.org/2011-July/010011.html
"/* AmigaOS sees 4:3 modes as square in the DisplayInfo database, * so we correct 16:10 modes to square for widescreen displays. */ xres = (xres * 16) / 4; yres = (yres * 10) / 3;"
（這會覆蓋 DI.Resolution.x 和 DI.Resolution.y）
只有 fixed.font 還是所有字型都有同樣的問題？Amiga 字型實際上是不是 hunk 二進位制檔案？
所有 hunk 二進位制檔案都失敗還是隻有非 m68k 埠上的某些字型失敗？
啟用 internalloadseg_aos.c 除錯幷包含相關的日誌訊息，這可能有助於查詢問題（我仍然看不到任何錯誤：()）
以下是 FixFonts 中段錯誤之前的日誌
[DOS] DosInit: InitCode(RTF_AFTERDOS)
[DOSBoot] __dosboot_BootProcess: Booting from device 'EMU:'
Hunk count: 1
First hunk: 0
Last hunk: 0
Hunk 0 size: 0x0010d8 bytes in ANY memory @011d5064
HUNK_CODE(0): Length: 0x0010d8 bytes in ANY memory
HUNK_RELOC32:
Hunk #0:
HUNK_END
[KRN] Trap signal 11, SysBase 0xf522dc, KernelBase 0xf52f38
[KRN] Process 0x1025508 (FixFonts)
SP=011f0d30 FP=011f0d48 PC=b762e84e
R0=4eff7000 R1=00000000 R2=b7631b6c R3=00f531a4
R4=011f0dd7 R5=011f0dd7
BlkMaskBitMapRastPort() 修補程式對 pixbuf 進行動態分配
- 消除了對 pixbuf 訊號量的需求（提高併發性）
- 根據需要動態分配 pixbuf
- 將 NUMPIX 移動到 bltmaskbitmaprastport.c 檔案中，並對其進行記錄
- 現在，我們可以處理寬度 * sizeof(HIDDT_Pixel) 超過 NUMPIX 的源影像，只要我們有足夠的可用記憶體。
小評論：請建立圖形的私有記憶體池並使用輪詢記憶體分配函式，即 AllocPolled/FreePolled。非常頻繁地呼叫常規的非輪詢記憶體分配是導致效能下降的候選物件。AROS 應該獲得一個更好的記憶體分配器。如果您頻繁使用 C++ 程式所執行的 alloc/free，則當前的記憶體分配器會成為速度瓶頸。或者使用 arosc 進行 malloc 以獲得更好的記憶體處理程式？如果是這樣，Jason 執行的修補程式應該使用 malloc。修補程式中的記憶體分配可能太大而無法在池中工作。因此，即使使用了池記憶體，分配也大多會直接轉到非池記憶體的分配。
池非常適合大小相同的專案集合，但這裡的情況並非如此。
對於這種用法（可變大小，未知最大大小），池不是很有幫助。除非透過一些基準測試得到證明，否則這兩個語句都只是理論。就我個人而言，我認為記憶體池是可取的，如果不是為了速度，而是為了記憶體碎片或能夠使用一個 DeletePool 命令釋放一大堆已分配的記憶體。後者在我看來在清理過程中最實用。
目前無法在 AROS 庫中使用 malloc，因為它是在呼叫任務上下文中分配的。而 arosc malloc/free 只是使用記憶體池和 AllocPooled/FreePooled...
“NUMPIX”的最小尺寸是多少？預設值 (50000) 會導致在初始化 graphics.library 時分配 200000 位元組。對於僅由少數幾個函式使用的緩衝區來說，這有點多。這將為您提供 200x250 畫素的點陣圖，老實說，這並不多。也許您可以將實現更改為動態分配緩衝區？Root BitMap 類對幾個呼叫（BM__Hidd_BitMap__PutAlphaImage、BM__Hidd_BitMap__PutTemplate、BM__Hidd_BitMap__PutAlphaTemplate 等）執行此操作。或者，請為 m68k 進行 ifdef - 一般情況下減少此值將意味著更多的小型 VRAM->RAM 讀取例項，這可能會減慢操作速度。
在第 58 行寫入 Wanderer:Tools/Info 處有
#define USE_TEXTEDITOR 1
我想您可以嘗試在那裡使用 0
SYS:System/Wanderer/Tools/ExecuteStartup 缺少圖示。（在修訂版 34053 中刪除，不應該有替換嗎？）
沒有圖示 -> OpenWorkbenchObjectA() 會開啟一個 CLI 輸出視窗，因為 GetIconTags("ExecuteStartup") 返回 isDefaultIcon=TRUE。
只是想知道為什麼以前沒有人注意到這一點，除非隱藏控制檯視窗有其他原因。（僅使用 m68k-amiga 埠進行測試）
沒有圖示
20-901 [513 226x165]: [WBLIB] OpenWorkbenchObjectA: name = Wanderer:Tools/ExecuteStartup 20-905 [513 041x231]: [WBLIB] OpenWorkbenchObjectA: isDefaultIcon = 1 20-908 [513 060x281]: [WBLIB] OpenWorkbenchObjectA: it's a TOOL 20-912 [514 037x012]: [WBLIB] OpenWorkbenchObjectA: it's a CLI program 20-914 [514 008x061]: [Open] FH=1032b898 Process: 0x10100c08
“WANDERER:Wanderer”，視窗：0x00000000，名稱：“CON:////Output Window/CLOSE/AUTO/WAIT”，模式：1005
添加了圖示
10-571 [510 226x248]: [WBLIB] OpenWorkbenchObjectA: name = Wanderer:Tools/ExecuteStartup 10-576 [511 040x007]: [WBLIB] OpenWorkbenchObjectA: isDefaultIcon = 0 10-579 [511 220x055]: [WBLIB] OpenWorkbenchObjectA: it's a TOOL 10-581 [511 226x103]: [WBLIB] OpenWorkbenchObjectA: it's a WB program 10-585 [511 226x159]: [WBLIB] OpenWorkbenchObjectA: stack size: 32768 Bytes, priority 0 10-590 [511 226x231]: [WBLIB] WB_LaunchProgram: Success
檢視 workbench.library/wanderer 作為原始碼，並注意到 AppMenu 和 AppIcon 似乎還沒有完全實現。看起來 wbhandler.h 應該新增一個型別以在更新 AppIcon 後更新 AppMenu，並且庫程式碼應該在成功新增/刪除其列表更改後向註冊埠傳送更新 (AppIcon|AppMenu) 訊息以用於事件型別。是的，workbench.library 需要一些工作。'RegisterWorkbench()' 是 AROS 特定的改進，還是有 AOS 等效項？似乎是 AROS 特定的，舊的 AlohaWorkbench() 可以追溯到……嗯……很久以前，但它有意不記錄，因為其唯一目的是註冊……workbench，作為……workbench。附錄 C，第 2 頁……AlohaWorkbench() - 此例程允許 Workbench 工具將其存在和離開通知 Intuition。
AlohaWorkbench() - 在夏威夷語中，“aloha”既表示問候也表示告別。AlohaWorkbench() 例程允許 Workbench 程式通知 Intuition 它已變為活動狀態以及它正在關閉。
此例程使用兩種引數之一進行呼叫 - 指向已初始化的訊息埠的指標（表示 Workbench 處於活動狀態並且可以進行通訊），或 NULL 表示 Workbench 工具正在關閉。
當訊息埠處於活動狀態時，Intuition 將向其傳送 IntuiMessages。這些訊息的 Class 欄位將設定為 WBENCHMESSAGE。Code 欄位將等於 WBENCHOPEN 或 WBENCHCLOSE，具體取決於 Workbench 應用程式是否應開啟或關閉其視窗。Intuition 假設 Workbench 將遵守，因此一旦回覆了訊息，Intuition 就會繼續執行，並期望視窗已相應地開啟或關閉。
過程概要如下：
AlohaWorkbench(WBPort) WBPort - a pointer to an initialized MsgPort structure in which the special communications are to take place.
我不確定它是否是同一個函式，但 AmigaMail 或 DevCon 的一篇舊文章中寫了一些關於類似功能的支援內容（這些年我的紙質副本丟失了）。Dopus Magellan 可能是真正商業客戶端的最佳選擇。
理想情況下，人們應該能夠像在多螢幕 Workbench 程式中一樣執行多個 workbench.library 客戶端。
應用程式編寫者可能希望實現 Workbench 抽屜導航和檔案處理功能，以便在其自己的公共螢幕上使用，同時擁有其 AppWindows（不在 Workbench 螢幕上）以進行拖放，以代替檔案請求器。他們可能希望儘可能地使用 PROGDIR: 作為根視窗，並使用自己的抽屜視窗程式碼等效項，並且僅顯示其專案檔案或僅支援的剪貼畫檔案型別，方法是顯示實際的剪貼畫而不是圖示影像。
構建 mathffp.library。已修復，我忘記提交標頭檔案修改了..(順便問一下，誰能修復 lh_SysBase == NULL 問題？)。對 BPTR NULL 使用 BNULL。只需透過將其硬連結到絕對地址來新增對 ROM 中 .bss 的支援即可。不會發生這種情況。晶片 RAM 很寶貴，速度慢，並且是所有 Amiga 機型上唯一保證存在的 RAM。如果我硬連結了 .bss，我將不得不使用晶片 RAM，這將減少可用於 DMA 可定址點陣圖、軟盤磁軌和音訊的 RAM 量。在庫的控制代碼（如果可用則在 Fast RAM 中分配）中使用空間是一個更好的解決方案。然後，在庫基址中儲存方法 ID，並且不要使用存根（無論如何它們都不適用於沒有 .bss 的 ROM 程式碼） :-D
這再次是 m68k-amiga 特定的，它不能期望 FPU 但仍然需要支援浮點數。這意味著我們需要以“Amiga 方式”執行此操作並使用 mathieeedoubxxx 庫。（非 Amiga 方式將是捕獲 FPU 異常，這僅在模擬缺少的 040/060 fpu 函式時才允許：））
是否可以透過用呼叫 IEEDP 庫函式的存根替換 gcc math C 庫函式來正確執行此操作？（並將 lib 基址放在 aros_privdata 中）
IEEEDP 函式隨後使用軟體版本或數學函式的內聯彙編 fpu 版本（在開啟庫時用 FPU 函式替換 lib 向量）
數學庫有一些已知的與 m68k 相關的問題。
Cmp() 和 Tst() 函式記錄為返回正確的設定 68k 標誌，這在使用普通 C SetSR() 時是不可能的，SetSR() 設定程式碼，但最終複製到 D0 會重置所有標誌..(所有 math lib SetSR() 呼叫在 m68k C 程式碼中都是無用的)。
只有 FFP Cmp() 和 Tst() 具有彙編修復，其他 FFP 函式仍然至少返回錯誤的 N 標誌（FFP 符號位是第 7 位，而不是第 31 位），幸運的是 IEEE 符號位是第 31 位。我稍後會嘗試修復 IEEE Cmp() 和 Tst()，如果 Jason 仍然感興趣，他可以嘗試修復其他返回程式碼問題 :)
此外，Autodocs 略有不正確，例如 Cmp() 和 Tst() 被記錄為始終返回 V=0，這是不可能的，因為 V 標誌由 m68k CMP 設定/重置，並且 bgt 和其他分支命令需要它..(這些命令記錄為可用於數學庫！)
使用 -libm 連結應該可以解決此問題。如果它已使用 -libm 連結，那麼我不知道為什麼它不起作用。它尚未完成，因為這並不簡單，正確的 m68k Amiga 方式是將編譯器數學庫重定向到 LIBS: 中的數學庫（LIBS: 數學庫隨後使用軟體或 FPU，具體取決於硬體配置）。
在 LC_LIBDEFS_FILE 可以在覆蓋的 c 檔案中工作之前，是否需要執行某些操作？我嘗試覆蓋 mathieeedoubbas/mathieeedoubbas_init.c（作為 arch/m68k-all/mathieeedoubbas/ mathieeedoubbas_init.c）以支援 m68k FPU 函式。已經包含的 ieeedpbas_fpu.c 不能在 m68k-amiga 上使用，因為 AOS C 庫數學函式應該在內部呼叫數學庫函式，而不是相反。
/home/twilen/aros/arch/m68k-all/mathieeedoubbas/./mathieeedoubbas_init.c:11:10: error: #include expects "FILENAME" or <FILENAME>. This definition is handled by the %build_module macro but not by the %build_archspecific macro. It will need to be implemented in config/make.tmpl if needed.
糟糕，我忘記回覆 LC_LIBDEFS_FILE 實際上並不需要。我覆蓋了 if，因為我不想再新增另一個 idef _m68000，並且因為 m68k FPU 例程應該始終使用 FPU 指令，即使 m68k AROS 設定被編譯為與 68000 相容（這在今天是正確的）。初始化例程然後在執行時修補函式指標（如果檢測到 FPU）。
順便說一句，IEEE Div 和 Mul 軟體版本未實現，誰能實現這些？
68040 和 68060 沒有在硬體中實現舊 CPU 和 FPU 支援的所有指令（一些很少使用的指令和 FPU 指令，如 sin 和 cos）摩托羅拉分發了實現缺少指令的軟體模擬的彙編程式碼（包括原始碼），例如康柏和加速器製造商將其包含在 68040 或 68060.library 中。（我想每個人都知道這一點？）
摩托羅拉的模擬檔案附帶以下許可證，這與 AROS 相容嗎？應該是，例如它包含在 netbsd 中，但我想在它成為 m68k-all 的一部分之前得到確認。
- 08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)~
~
- 摩托羅拉微處理器與記憶體技術集團
- M68000 高效能微處理器部門
- M68060 軟體包生產釋出版
- M68060 軟體包版權所有 (C) 1993、1994、1995、1996 摩托羅拉
公司
- 版權所有。
- 該軟體按“原樣”提供，不提供任何擔保。
- 在適用法律允許的最大範圍內，
- 摩托羅拉否認所有明示或暗示的擔保，
- 包括對適銷性或適用於
- 特定目的的默示保證，以及任何與
- 軟體（包括其任何修改版本）
- 和任何附帶的書面材料相關的侵權擔保。
- 在適用法律允許的最大範圍內，
- 在任何情況下，摩托羅拉均不對任何損害負責
- （包括但不限於因業務利潤損失、
- 業務中斷、業務資訊丟失或其他
經濟損失）
- 因使用或無法使用軟體而產生。
- 摩托羅拉不對軟體的維護和支援
- 承擔任何責任。
- 特此授予您使用、修改和
分發
- 軟體的版權許可，只要此完整通知在任何修改和/或重新分發的版本中
- 保持不變，並且此類修改的
- 版本被明確標識為如此。
- 根據
任何
- 摩托羅拉公司的專利或商標，均未暗示、禁止反言或以其他方式授予任何許可證。
- 08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)08:22, 2011年5月5日 (UTC)~
%build_module 不支援 asmfiles。誰能更熟悉地新增支援？
我需要 asmfiles 支援來構建 040/060 缺少的指令模擬模組。它是 m68k 獨有的，沒有要覆蓋的內容，它需要 m68k 彙編。
我假設 r38541 和 r38542 是那些摩托羅拉程式碼，對吧？m68k-all/mathieeedoubbas 中的檔案呢？這是否也是摩托羅拉程式碼？實際上，這只是“普通的 68882 FPU”指令。託尼談論的是一個單獨的問題，即來自摩托羅拉的模擬程式碼，用於在 68040 和 68060 上支援部分實現的 FPU 指令（它們擁有大部分，但並非所有 68882 FPU）。
是的，一些很少使用的非 FPU 指令丟失了。它們也由模擬程式碼處理。
<snip> 未實現的整數指令是
64-bit divide 64-bit multiply movep cmp2 chk2 cas (w/ a misaligned effective address) cas2
</snip>
trunk/AROS/rom/devs/keyboard/keyboard.c trunk/AROS/rom/devs/keyboard/keyboard_intern.h
Lowlevel.library 不是 ROM 模組（它僅在 cd32 中是 ROM），並且還沒有 Amiga 硬體特定實現 = 必須支援磁碟上的原始版本。
如果沒有此 hack，您只會獲得隨機的記憶體損壞，這在 lowlevel.library 被清除時很難除錯（例如 whdload 在啟動時會執行此操作）
更好的問題是：原始的 keyboard.device 如何存活？也許它不使用或不需要 opener 特定的結構？是否存在任何可用於比較 AROS 與 OS3.1 結果的測試用例/測試應用程式？我假設 RKMs/Guru Book 中沒有關於此的內容，我們無法反彙編 KS 二進位制檔案以進行檢查。在 KS3.1 上的多個 OpenDevice("keyboard.device") 在 io_Unit 欄位中返回靜態值。（相對於 keyboard.device 基址的指標）。我想說不需要 opener 特定的 KBUnit 結構。（也許原始的 keyboard.device 僅在存在單個 opener 時才能正常工作？）。
原始的 m68k reqtools.library 小部件也存在一些問題，所有按鈕小部件都不可見，但單擊時它們確實可以工作（並且在單擊一次後它們甚至會永久可見）
這可能與此相關：Deluxe Paint 2 和 3（未測試其他版本，2 和 3 用於疊加測試）按鈕小部件具有類似的圖形故障。
按鈕文字/標籤在其被單擊一次後（或如果小部件最初被繪製為活動狀態）會永久不可見。
fid->fid_EdgesOnly 可能為 0。如果稍後繪製，則應為 1。
我想到了，frameiclass，對 AFA 進行了大量修改。我私下發送給你檔案，也許你看到了區別。
有時我會發布 AFA 與 AROS 程式碼存在的問題。我認為這兩個問題也可能是可能的。您是否檢查過 AROS 68k 中是否存在這些問題？
我的意思是 wb 3.9 中關於 Req 的文字顯示正確。
//RemoveClass(FindClass("itexticlass")); // wb 3.9 中的文字未寫入。 //BOOPSI_ITextIClass_Startup_lib(); ////// //RemoveClass(FindClass("frbuttonclass")); // 小部件框太大 //BOOPSI_FrButtonClass_Startup_lib();
但在最後的函式中，由於不知道要修復什麼，我停用了它們。
我非常確定 reqtools 使用標準的 intuition 小部件（它很長時間以來都與 1.3 相容），而不是 boopsi。reqtools 68k 呼叫此程式碼，也許您添加了一些除錯程式碼來檢視 fid->fid_EdgesOnly 是否為 0 或 1。我停用了 EdgesOnly 測試：對隱藏的按鈕小部件沒有影響。
IPTR FrameIClass__IM_DRAW(Class *cl, struct Image *im, struct impDraw *msg)
{
DEBUG_IFRAME(dprintf("dispatch_frameiclass: draw Width %ld Height %ld\n",im->Width,
im->Height));
//kprintf("%ld %ld\n",im->Width,im->Height);
return draw_frameiclass(cl, im, msg, im->Width, im->Height);
}
我注意到 RefreshBoolGadgetState() 在選擇狀態更改時被呼叫，並且在那個時候看起來沒問題，但此呼叫後的某些操作清除了標籤文字。也許您嘗試跳過 draw_frameiclass(cl, im, msg, im->Width, im->Height) 對隱藏的按鈕也沒有效果（當然，小部件開始看起來很奇怪）。我剛剛注意到是填充模式覆蓋了小部件，因為顯示非填充視窗的 gadtools 演示部分可以正常工作。
它沒有被很多軟體使用，如果文字沒有被覆蓋，你可以確定frameiclass中有一些問題。看起來所有Aros原生程式如果之前沒有人注意到的話，都會使用boopsi。
安裝指令碼不接受AROS的版本號。一條訊息指示使用Kick 3.1。那麼AROS wbversion 是否可能與AOS相容，並顯示AROS至少是Kick 3.1？
這裡失敗了
- 擁有KS3.1
(if (< #wbversion 40)
( (exit #msg-badkick (quiet))
))
如何設定#wbversion？這是什麼版本的Scalos，以及從哪裡可以下載？
- wbversion 透過檢視libs:version.library的版本來定義。
來自scalos的安裝指令碼
(set #wbversion (/ (getversion "Libs:version.library") 65536))
我認為AROS中沒有version.library。我想這解釋了失敗的原因。
它沒有任何函式，是嗎？M68k軟體肯定假設它存在。它沒有額外的函式，但可以正常刪除。
我用codesearch找到了這個
const char *amigaGetOSVersion(void)
{
static const char *osver[] = { "2.0","2.0x","2.1","3.0","3.1","3.2","3.3","3.4","3.5","3.9","3.9","3.9","3.9","3.9","4.0pre","4.0pre","4.0" };
int ver = SysBase->LibNode.lib_Version;
#ifndef __amigaos4__
if (ver >= 40 && ver < 50) { // Detect OS 3.5/3.9
struct Library *VersionBase;
if ((VersionBase = OpenLibrary("version.library",0))) {
ver = VersionBase->lib_Version;
CloseLibrary(VersionBase);
}
}
#endif
#ifdef __POWERUP__
if (FindResident("MorphOS") && ver > 45) ver = 45;
#endif
if (ver < 36) ver = 36;
else if (ver > 51) ver = 51;
return osver[ver-36];
}
看起來我們所要做的就是將lib_Version設定為40以用於OS3.1。
global.prefs與m68k-amiga不相容。它包含了導致m68k-amiga TextEditor mui類崩潰的小端資料。例如，當TextEditor請求MUIM_GetConfigItem / MUICFG_TextEditor_UndoSize時，十進位制數500將被讀取為F4010000。類已修復（阻止了初始化），prefs問題是不同的問題，目前唯一的解決方法是刪除prefs檔案。如果它*確實*支援跨平臺，所有資料都應該為大端（因為Classic AmigaOS是我們的最低公分母，並且大端更容易在十六進位制轉儲中用肉眼讀取！）
我看到其中一些地方IPTR被恢復為ULONG（可能在x86_64上不好？）。再次檢查上面該程式碼中新增的#ifdef __AROS__行。
我相信SDI_hook.h和SDI_compiler.h的更改是穩定的，並且可以回傳。我想建議我們在頂層workbench/libs/SDI中有一個包含AROS SDI標頭檔案的“主”版本，這些檔案安裝在:Development/Include/中。當前使用SDI的包應該選擇這些標頭檔案，而不是其本地包含檔案中的（可能已過時的）版本。當已經有編譯器/包含檔案時，這樣做對我來說沒有多大意義（從技術上講，它不是一個庫，所以workbench/libs不是放置它的位置）。AROS應該在其樹中只有一個版本的SDI（希望是最新的！），而不是四個或修復不同版本的副本。
在另一個方面，我無法弄清楚如何使SDI可變引數VA_*宏適用於使用非統一可變引數陣列的AROS架構。（特別是x86_64）。目前在AROS上，有以下幾種情況的非常複雜的宏（和輔助函式）
IPTR func(LONG dummy, Tag tag1, ...)
{
AROS_SLOWSTACKTAGS_PRE(tag1)
retval = funcA(dummy, AROS_SLOWSTACKTAGS_ARG(tag1));
AROS_SLOWSTACKTAGS_POST
}
以及
IPTR func(Class *cl, Object *obj, ULONG MethodID, ...)
{
AROS_SLOWSTACKMETHODS_PRE(MethodID)
retval = funcA(cl, obj, AROS_SLOWSTACKMETHODS_ARG(MethodID))
AROS_SLOWSTACKMETHODS_POST
}
Package-Startup從其父目錄執行。因此它將“system:extras/Zune/MCC_NList/Classes”新增到Libs
啟動序列的這一複雜部分讀取env:sys/packages中的所有變數。這些變數包含s/Package-Startup的路徑。
If EXISTS ENV:SYS/Packages
List ENV:SYS/Packages NOHEAD FILES TO T:P LFORMAT="If EXISTS
${SYS/Packages/%N}*NCD ${SYS/Packages/%N}*NIf EXISTS
S/Package-Startup*NExecute S/Package-Startup*NEndif*NEndif*N"
Execute T:P
Delete T:P QUIET
CD SYS:
EndIf
任何足夠無聊的人應該幫助修復contrib中的m68k編譯問題:) 你得到什麼編譯錯誤？也許你嘗試使用舊編譯器（最好關閉GCC中的最佳化器以避免程式損壞）和68k.cpu.h中的舊AROS 68k宏檔案來編譯contrib
我注意到Mason為GCC 4.5.0編寫的宏不適用於編譯AFA（使用GCC 3.4.0和GCC 4.5.0），只有舊的AROS宏和GCC 3.4.0可以正常工作。
但理論上，如果我更改libcall.h和cpu.h，它應該可以工作。
當使用選項-E編譯時，宏錯誤變得更加明顯，因此只執行預處理器部分並儲存ascii[檢查拼寫]檔案。這是傳送給Jason但未回覆的郵件
這個zune檔案或arossupport.c
當我使用舊的libbcall.h時，所有內容都可以工作。我已將其附加（目前命名為libbcall.h_，因為我使用了你的檔案）
這是amidevcpp的完整日誌輸出。
-E選項我用來獲取預處理器錯誤輸出。當我不用-E時，我只得到一個語法錯誤，它並不精確。奇怪的是，AROS可以工作。
Compiler: m68k-AmigaOS Building Makefile: "E:\amiga\AmiDevCpp\usr\local\amiga\Makefile.win" Executing make... mingw32-make.exe -f "E:\amiga\AmiDevCpp\usr\local\amiga\Makefile.win" all m68k-amigaos-gcc-3.4.0 -c afa_os/arossupport.c -o aros/WORKBE~1/libs/MUIMAS~4/arossupport.o -I"E:/amiga/AmiDevCpp/usr/local/amiga/m68k-amigaos/sys-include" -I"E:/amiga/AmiDevCpp/usr/local/amiga/m68k-amigaos/include" -I"afa_os/include" -I"arosinclude" -I"Aros/workbench/libs/muimaster" -I"Aros/workbench/libs/muimaster/classes" -I"Aros/workbench/classes/zune/aboutwindow" -m68020 -m68881 -D__AROS__ -fno-strict-aliasing -E -w -O2 afa_os/arossupport.c:18:43: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:18:43: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:23:42: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:23:42: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:172:21: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:180:44: macro "__AROS_LCA" requires 3 arguments, but only 1 given afa_os/arossupport.c:180:44: macro "__AROS_LCA" requires 3 arguments, but only 1 given ..... """""
在第18行，只是簡單地呼叫了它。
return MUI_NewObjectA(classname, &tag1);
但它也發生在LHA宏上。目前唯一可用的編譯器是最新的+Jason的A6 gcc暫存器補丁。（這肯定與可能的編譯器問題無關）
順便說一句，當也使用原生AmigaOS庫時，AROS mui或庫中也存在一些問題。Scout由於在呼叫DisposeRegion（或ClearRegion）時區域指標損壞而崩潰。（我試圖使用AmigaOS nlist，因為AROS版本無法編譯）區域指標指向一些奇怪的字串資料。除錯記憶體溢位/損壞很無聊..
我認為這裡的問題是sdi包含檔案認為自己是68k並使用68k編譯器語法。要檢視真正的問題，請使用編譯器選項-E併發布預處理器檔案，因為sdi使用瞭如此多的巢狀宏。
如果functionheader中-E的輸出顯示如下內容幷包含asm命令，則對於新編譯器來說是錯誤的。
funcname(char *args __asm("a0") )
> /home/twilen/AROS/contrib/bgui/examples/FieldList.h:150:21: error: too > many arguments to function 'SetFLAttr'
這是不同的。可能是SetFLAttr的原型錯誤。如果不是這裡，你也可以在makefile中設定編譯器選項-E時檢視，沒有宏的完整原始碼行是什麼。
> > btw, there is something wrong with either aros mui or libraries when > also using native amigaos libraries. Scout crashes due to corrupt > region pointer when calling DisposeRegion (or was it ClearRegion).
據我記得，AROS上zune MUI API的lib插槽使用方式不同。我為AFA修復了偏移量，但不知道有什麼不同。我傳送給你AFA muimaster.h定義的私有檔案，這裡的附件不起作用。
因為Amiga中所有OOP的東西都是由於黑盒概念，並且新增功能需要大量工作，所以實現是有限的，並且缺少許多功能。這也是MOS MUI4上的一個問題。
在MUI和boopsi圖片資料型別方面，使用它的開發人員開始進行hack並使用未公開的功能。
所以我建議在AROS 68k上，與AFA相同的方式進行操作。AROS MUI庫名為zune.library。所有AROS程式都編譯為在68k上使用zune.library。
這允許你透過使用MUI 68k獲得最佳相容性，並避免新功能無法新增到zune中，從而破壞某些程式。
使用者可以像在AFA中一樣使用zune啟動器來告訴程式它應該使用zune.library而不是muimaster.library
因為AFA已經存在很長時間了，所以只有大約70-80%的MUI 68k程式在zune上完美執行。它也不喜歡OO的東西，很難找到問題，所以多年來我一直放棄讓zune更相容。
對於AROS上的bgui，我目前沒有其他想法，因為問題來自AROS輸入裝置。我無法在AFA上測試。
librom.a庫現在具有舊樣式的“no %f/%g”printf系列，arosc.library具有浮點功能。因此，如果你想要%f，請使用“linklibs="arosc"”，而不是“linklibs="rom"”。如果有人意外地連結到它並使用“%f”格式，謹慎起見，最好讓“rom”版本打印出“???”。只有openurl.library的Prefs需要%f。
僅供參考：不允許將模組（庫、裝置等）與arosc.library連結——這是因為arosc.library在呼叫任務中儲存上下文。
TASK [arosc.library context] | | \ / module | | \ / arosc.library
因此，當任務死亡時，上下文也死亡，但模組已在該上下文中分配了記憶體。這就是為什麼模組需要與librom.a連結（即使它們不在ROM中）並且librom.a中缺少的C庫函式必須在模組中直接實現（例如，我必須對mesa.library執行此操作）。
“因此，如果你想要%f，請使用“linklibs="arosc"”，而不是“linklibs="rom"”不適用於它們。:) PS。用於顯式停用與arosc.library連結的模組構建的宏——這是有意的（這就是Kalamatee出現連結器錯誤的原因）
AOS下的RawDoFmt()列印什麼？它不是像只是剝離了'%'，即'f'嗎？
所有bgui.library小部件都可見（有些存在小的對齊錯誤），但無法使用滑鼠選擇或啟用它們。鍵盤快捷鍵有效（如果小部件設定了鍵盤快捷鍵）
bgui.library演示和FileMaster 3（“出於某種原因”，這是我的一個測試用例...）存在相同的BOOPSI問題。
它們處於正常的非按下狀態。而且不僅僅是按鈕小部件，所有bgui小部件型別都無法使用滑鼠選擇。
除了滑鼠選擇之外，其他所有內容都可以工作（或多或少）。例如，視窗開啟時選中的字串小部件的游標可見，甚至文字編輯也可以正常工作。
按下按鈕小部件的快捷鍵可以工作，並且小部件的文字標籤消失（這是錯誤的，它應該顯示按下狀態）在按下ESC的同時保持快捷鍵按下會取消按下事件，並且文字標籤重新出現。
因此，bgui小部件至少存在兩個不同的問題
- 滑鼠選擇。
- 按鈕小部件（可能是其他小部件，在滑鼠選擇工作之前無法真正測試）按下狀態渲染不正確。
我在AFA中激活了許多AROS函式和類進行測試（這會導致68k程式碼出現問題），但bgui addbuttons測試程式（我只將其用於測試）可以正常工作。因此，這些AROS函式中似乎沒有問題。
AFA上的buttonclass gmhittest與AROS上的相同，並且都可正常工作。
我還恢復了一些AFA程式碼的相容性增強功能。bgui仍然可以工作。我有時間時會在AROS 68k上測試。
如果它們無法點選會發生什麼，當你點選它時，是否沒有顯示按下狀態？
在這裡你可以看到哪些問題是由某些程式中的某些AROS函式引起的。通常情況下，我會停用所有這些已知存在錯誤的函式。
因此，如果你遇到這樣的問題，它可能有助於找到導致此問題的功能。
這是穩定的AROS程式碼，沒有已知的相容性錯誤
RemoveClass(FindClass("gadgetclass"));
BOOPSI_GadgetClass_Startup_lib();
RemoveClass(FindClass("sysiclass"));
BOOPSI_SysIClass_Startup_lib();
BOOPSI_TbiClass_Startup_lib();
RemoveClass(FindClass("buttongclass"));
BOOPSI_ButtonGClass_Startup_lib();
RemoveClass(FindClass("imageclass"));
BOOPSI_ImageClass_Startup_lib();
SETFUNC(DoGadgetMethodA,Intuition,IntuitionBase); // // editpad scrollbar after load full size
SETFUNC(RefreshGadgets,Intuition,IntuitionBase);
if (replacevisualprefs)
{
SETFUNC(AddGadget,Intuition,IntuitionBase);
SETFUNC(AddGList,Intuition,IntuitionBase);
}
SETFUNC(RemoveClass,Intuition,IntuitionBase);
SETFUNC(NextObject,Intuition,IntuitionBase);
SETFUNC(DisposeObject,Intuition,IntuitionBase);
SETFUNC(AddClass,Intuition,IntuitionBase);
SETFUNC(FreeClass,Intuition,IntuitionBase);
SETFUNC(MakeClass,Intuition,IntuitionBase);
SETFUNC(NewObjectA,Intuition,IntuitionBase);
SETFUNC(MakeClass,Intuition,IntuitionBase);
SETFUNC(SetGadgetAttrsA,Intuition,IntuitionBase);
SETFUNC(ObtainGIRPort,Intuition,IntuitionBase); // text is draw only on top of screen
SETFUNC(ReleaseGIRPort,Intuition,IntuitionBase);
SETFUNC(DrawImage,Intuition,IntuitionBase); //redraw errors on old icons on workbench
SETFUNC(DrawImageState,Intuition,IntuitionBase); //redraw errors on old icons on workbench
SETFUNC(ModifyIDCMP,Intuition,IntuitionBase); //immediate redraw when scroll not work(MUI)
RemoveClass(FindClass("icclass")); //kingcon scrollbar redraw not immediate.
BOOPSI_ICClass_Startup_lib();
RemoveClass(FindClass("rootclass"));
InitRootClass_lib();
RemoveClass(FindClass("groupgclass"));
BOOPSI_GroupGClass_Startup_lib();
RemoveClass(FindClass("modelclass"));
BOOPSI_ModelClass_Startup_lib();
RemoveClass(FindClass("itexticlass")); // text in WB 3.9 about is not written.
BOOPSI_ITextIClass_Startup_lib();
//////
RemoveClass(FindClass("frbuttonclass")); // gadget boxes are too large
BOOPSI_FrButtonClass_Startup_lib();
//
RemoveClass(FindClass("fillrectclass"));
BOOPSI_FillRectClass_Startup_lib();
WB3.1 Prefs/Palette顯然手動建立DrawInfo結構，導致sysiclass_aros.c中崩潰，因為它假設dri_Screen有效。
當在openscreen.c中設定dri_version = DRI_VERSION + 1，並且僅在sysiclass_aros.c中允許“新的”drawinfo版本時，首選項程式不再崩潰。
這個更改可以嗎？或者使用某種“擴充套件drawinfo”標誌而不是更改版本號更好？不幸的是，這將破壞與舊AROS程式的向後相容性。（如果找不到相容的解決方案，我會將其放在AROS_FLAVOUR_BINCOMPAT ifdef中）
首選項/調色盤停止崩潰並工作，除了顏色選擇器圓圈完全是黑色的，首先繪製所有顏色，完成後，它被黑色覆蓋。
WB3.1 首選項/調色盤呼叫AreaCircle（或AreaEllipse）兩次（用於在色輪周圍繪製窄黑色邊框），兩者具有相同的中心座標，一個具有少量畫素，更大的半徑，最後呼叫AreaEnd，它應該只填充窄區域邊框區域。AROS版本填充兩個圓圈，導致色輪完全變黑。（我不會碰這個）
顯然AreaEnd()始終使用類似光柵的區域填充。
AOS工作臺啟動的程式也具有NULL pr_CurrentDir。
例如，非常常見的SAS-C啟動程式碼（原始碼隨編譯器提供）在從WB啟動時執行以下操作
a0 = WB startup message move.l wa_Lock(a0),d1 callsys DupLock move.l d0,__curdir(A4) move.l d0,d1 callsys CurrentDir
不幸的是，在退出時，它不會恢復pr_CurrentDir，它只解鎖了__curdir(a4)。這意味著除了使用NULL pr_CurrentDir之外，沒有其他方法可以處理此問題。（目前它會導致雙重解鎖，至少UAE fs會忽略它而不會崩潰，其他情況不確定）。我現在已經確認了從WB啟動時的以下程序變數
pr_CurrentDir = NULL pr_HomeDir = set pr_CIS = NULL pr_COS = NULL pr_ConsoleTask = NULL pr_FileSystemTask = set
除錯此問題，發現Wanderer（或其他程式）在選擇執行後會呼叫ScreenToFront("wb screen")。似乎screendepth沒有檢查（至少沒有正確檢查）請求的螢幕是否已經在前面。呼叫跟蹤為：screendepth()->RethinkDisplay()->MrgCop()