06 March 2021, 14:12 | #81 | ||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
(And you probably don't want to close the door to an ST implementation.) I believe it would be simpler to use the trap interface instead. On 80x86 you would use some unused INT, on 68000 some available TRAP. |
||||||||
06 March 2021, 14:17 | #82 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
Quote:
Quote:
Quote:
Note that AmigaOs does NOT execute code from the RDB (the MBR lookalike of Amiga). Thus, there is no classical boot sector in the PC sense on harddisks. |
|||
06 March 2021, 14:48 | #83 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Amiga executables get the command length in d0 and the command buffer in a0.
I would like to pass SysBase (normally 4) in another register, e.g. d1. Obviously only d1-aware executables will actually switch to that new base address. I can make PDPCLIB-based programs d1-aware. For PDPCLIB-based programs to still work on standard AmigaOS, I cannot expect d1 to be set. It is a random value. I was thinking that what I could do is see if d0 is more than 2 GiB. If it is above 2 GiB, then I will do two things: 1. Subtract 2 GiB from d0 2. Set SysBase to d1 Otherwise, SysBase will be set to 4. That would give me the flexibility to run PDOS under AmigaOS and load and handle d1-aware Amiga executables (within PDOS). Does that sound feasible? Thanks. Paul. |
06 March 2021, 15:04 | #84 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Thanks. Paul. |
|
06 March 2021, 15:18 | #85 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
Quote:
Quote:
No, it sounds you need to learn a lot more about the Tripos legacy of AmigaOs. Starting an executable in an AmigaDos compatible way is a bit more involved, and I would always recommend going through the dos.library for it since it is aware of all the magic. |
||
06 March 2021, 15:25 | #86 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Does this "VM" facility actually exist on the 68000? It sounds like something that would need a more modern processor.
|
06 March 2021, 15:29 | #87 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,570
|
Quote:
Quote:
Why would you want that? Wouldn't it be easier to define at compile-time that you are creating a PDOS-only executable? If you want PDOS to run under AmigaOS (which your last postings seem to imply) you could implement PDOS as another shared library (pdos.library), which is opened by the executable's startup code. A similar solution already exists for POSIX functions under AmigaOS (ixemul.library). EDIT: Reading Thomas' reply I probably didn't understand what you want... never mind. Last edited by phx; 06 March 2021 at 15:32. Reason: Hm? |
||
06 March 2021, 15:35 | #88 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,570
|
Meynaf has probably more Atari exprience than me, but I seem to remember that the hardware mirrors the (first?) 8 bytes of the ROM at address 0, so the CPU find its reset vector there when switched on. So you cannot write to it.
|
06 March 2021, 15:50 | #89 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
As discussed, the Atari BIOS is accessed via trap #13.
Would it have been just as good to access the BIOS functions via a fixed address in memory (similar to SysBase) or is there an advantage to doing a trap? What's the underlying philosophy here? Thanks. Paul. |
06 March 2021, 15:55 | #90 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
There is more to it. Atari, unlike Amiga, does check the function codes for some memory regions, and chances are that the lower addresses are not writable (nor readable) for user function codes. At least the ST hardware was not user-visible, a bus error would result in any attempt to access them from user level.
|
06 March 2021, 15:57 | #91 | |||||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||
06 March 2021, 15:58 | #92 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
The advantage of the trap is that it transfers the CPU to supervisor space, and thus the operating system code is run in supervisor space. From an Os design point of view, this makes a lot of sense as it may enable the Os to access protected resources, or run CPU instructions for maintaining the CPU itself. </br> </br> The Amiga did not work like that, everything was user code, except for a small part of the exec scheduler, and even user code could request to execute small functions in supervisor code. </br> </br> If you ask me, this was a very bad design decision at AmigaOs side and isolation between user code and supervisor code should have been done more carefully.
|
06 March 2021, 16:00 | #93 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
|
|
06 March 2021, 16:02 | #94 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
"VM" is here meant in a figurative sense, not in the literal sense. No, the 68000 itself does not have the ability to isolate a VM properly (unlike its later follow-up processors). But that doesn't mean that something close to a virtualization isn't possible. As long as the caller of your (emulated) VM goes through a trap to receive services from an "operating system", it does not matter whether the service function that receives the trap is actually implementing an Os, or calls into the regular host operating system to receive services from there.
|
06 March 2021, 16:13 | #95 |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
What about if the SysBase-like BIOS functions simply did that trap themselves, to any trap number the BIOS-writer would like? Wouldn't this provide a more flexible solution, especially for environments where traps are unavailable for some reason?
|
06 March 2021, 16:22 | #96 | ||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
Quote:
The hardware itself is made this way, software doesn't control it. Quote:
Quote:
Quote:
Yes everything could run at system level but even though you could then read address 4, you still wouldn't be able to write it. |
||||
06 March 2021, 16:58 | #97 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Wouldn't this be a universal solution for all computers? Or at least, future ones? |
|
06 March 2021, 17:08 | #98 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,459
|
Quote:
|
|
06 March 2021, 17:44 | #99 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,110
|
For me PDOS on Amiga has two ways. First like Amix, second like EmuTOS.
|
06 March 2021, 18:04 | #100 | ||||||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
||||||
Currently Active Users Viewing This Thread: 3 (0 members and 3 guests) | |
Thread Tools | |
|
|