@Hammer

Quote:

Hammer wrote: @MEGA_RJ_MICAL I agree with most of your points.

I had absolutely no doubt that you would have agree with the mashup produced by a bot.

As well as I was absolutely sure that you wouldn't have spotted that those results were coming from a bot...
Quote:

68K CPU problem is on Motorola. For Xmas Q4 1992, Mac LC II had the full 68030 @ 16 MHz, but it wasn't competitive to PC's Am386DX-40 solution. Mac LC II is the best-selling Mac model for 1992. With 44,000 A1200 units available for Xmas Q4 1992 sale, the A1200 was largely missing in action in 1992. https://everymac.com/systems/apple/mac_lc/specs/mac_lc_ii.html Mac LC II's 68030-16 enables paged virtual memory. Apple responded with Macintosh LC III with 68030 @ 25 MHz in February 1993. Macintosh LC III+ with 68030 @ 33 MHz in October 1993. Macintosh LC 475 with 68LC040 @ 25 MHz in October 1993. October 1993 releases are important for the Xmas Q4 1993 sales period.

The problem wasn't Motorola (which, as I've tried to explain, had a very good product line), rather your continuous lack of understanding of the context and repeating the same things (which, obviously, don't change the situation).
Quote:

AmigaOS has 32-bit preemptive multitasking, but it can't be enforced since it lacks memory protection.

Can't be enforced WHAT? The Amiga OS preemptive multitasking works perfectly fine and as expected.
Quote:

Certain Linux advocates have redefined AmigaOS as cooperative due to unprotected preemptive multitasking.

Ignorants are everywhere, unfortunately. And certainly they can NOT redefine the literature to fit to their wishes.

To be more clear: preemptive/cooperative multitasking the processes/threads/tasks protection are two completely orthogonal and indepedant features.
Quote:

Hammer wrote: @MEGA_RJ_MICAL Are you supporting the 386 MMU standard NOT being important for establishing a large enough install base for a memory-protected/preemptive OS's mass deployment? Any "What If" about the Amiga platform is about Commodore's and Motorola's management direction, NOT at the retail end. Any "next gen" road map is BEFORE retail release.

Do you understand that you're asking an opinion to a troll whose the only purpose is to ridicule people for his only joy?

What technological knowledge about the topics did he show to convince you to desperately ask for his help?

In fact he still hasn't responded to your comment despite all the time that has passed, while he has been very quick to continue miserably trying to mock users in OTHER threads, with his usual Vulture-like manner.

The only good thing about his comment is that ChatGPT provided some benchmarks data showing the enormous burden the 80386 carries (and the 80286 as well) because of the implementation of C2-level protections, despite having implemented in hardware context-switching between processes (an implementation that 68k processors obviously lack, which have to operate everything by hand, and with DOUBLE the number of General Purpose registers).

But I guess you didn't notice this, despite the fact that in some cases it takes more than twice as long on Intel processors compared to Motorola equivalents, in extremely critical OS primitives.

And with that, it should once again the difference between one who is knowledgeable about deeply technical matters, and one who forges (!) his knowledge by Google searches (because if you had opened Intel's manuals for the 80286 and 80386 just once, you would have known the considerable difference in clock cycles regarding the execution of the aforementioned primitives dear to the OS, between execution in real mode and in protected mode).

Note: it supports what I've already summarized on my above post #5.

@agami

Quote:

Like I said, a bot.

Post some random CPU benchmarks from the past, calling it a useful answer and information.

@Hammer

Quote:

Are you supporting the 386 MMU standard NOT being important for establishing a large enough install base for a memory-protected/preemptive OS's mass deployment

Well, friend Hammer -

Short answer: no. I don’t buy the claim that the 386-class MMU “wasn’t
important� to reaching a big enough install base for mass-market, memory-
protected, preemptive OSes. In the IBM-PC ecosystem it was the hinge: it gave
OS designers a uniform, ubiquitous target with paging, privilege rings, and
virtual-8086 (V86) so they could ship protected, preemptive systems while still
running the mountain of DOS/BIOS baggage. Without that very specific feature
set becoming standard across clones, you don’t get OS/2 2.0’s strong DOS
virtualization, you don’t get Windows 3.x’s 386 Enhanced Mode, you don’t get
early Linux on commodity PCs, and you almost certainly delay the real mass
rollout of preemptive/protected consumer OSes. Kernel Documentation+3Bitsavers+
3KO Myung-Hun's Homepage+3

The core technical reasons (with cycle-level nits)1) What the 386 MMU
standardized (and why it mattered)

Paging + 32-bit flat addressing. The 386 took the 286’s segmented protected
mode and added hardware paging (two-level page directory/page table, 4 KiB
pages), a 32-bit linear address space, and CR3/CR2 machinery. That made UNIX-
style VM and copy-on-write practical on PCs. Crucially, reloading CR3 flushes
the page-translation cache (the on-chip TLB), so context switches imply a
predictable TLB cold-start cost the OS can reason about. MIT CSAIL PDOS

V86 mode (run many DOS VMs safely) and easy exit from protected mode (the 286
notoriously couldn’t switch back without a reset or triple fault). Those two
differences are precisely why 386-only OS releases (OS/2 2.0, Win3.x “386
Enhanced Mode�) could safely host DOS while keeping a protected preemptive
kernel. Wikipedia

Hardware task state machinery (TSS, task gates). Most modern kernels avoided
full hardware task switching for performance and control reasons, but the
existence of standardized privilege-transfer semantics (far gates, IRET
privilege changes, IO-permission bitmap in the TSS) made ring-transitions,
user/kernel isolation, and I/O mediation straightforward and consistent across
vendors. OSDev Wiki+1

Why this standardization mattered commercially: once the clone market converged
on “386-compatible,� OS vendors could assume exactly this paging model and
privilege behavior everywhere. That’s why IBM based OS/2 2.0’s VM model
explicitly on 386 features, why Windows 3.x’s “386 Enhanced Mode� exists at
all, and why Linus targeted the 386 for Linux 0.x/1.0: the features were
uniform and present on the machines people actually had. Bitsavers+2KO Myung-
Hun's Homepage+2

What OSes actually did with it (historical facts)

OS/2 2.0 (1992): depends on V86 + paging to create multiple isolated DOS boxes
and a flat 32-bit address model for native apps. That was explicitly a 386
design decision. Bitsavers

Windows 3.0/3.1 Enhanced Mode: runs on 386+ only; uses protected mode + V86 to
preemptively run DOS VMs while Windows apps cooperatively multitask, and adds
demand paging for Windows apps. KO Myung-Hun's Homepage+1

Windows NT 3.1 (1993): the x86 build’s baseline CPU was the 80386; NT’s design
presumes paging, rings, and a clean user/kernel split. Bitsavers

Linux: the earliest public kernels targeted the 386 and its paging model;
mainstream docs still point out Linux 1.0 was developed on the 386. gunkies.org+
1

These aren’t “nice to haves�—they’re the foundation that let mass-market OSes
keep compatibility and deliver isolation/preemption.

Micro-level performance realities (TLB, ring changes, copies, and the 386SX
penalty)

(a) TLB and page walks. On the 386, a TLB miss triggers a two-level page walk:
one read of the Page Directory Entry (PDE) and one read of the Page Table
Entry (PTE), then the eventual data fetch. Intel’s own diagrams show this, and
they explicitly call out that reloading CR3 flushes the translation cache (
TLB), guaranteeing a cluster of early misses after a context switch. OS
designers therefore minimized CR3 reloads and avoided hardware task-switches
that implied CR3 changes. ece-research.unm.edu+1

(b) 386SX bus effect. The 386SX is internally 32-bit but has a 16-bit external
data bus (and a 24-bit address bus). Every 32-bit PDE/PTE fetch becomes two bus
transfers, directly increasing TLB-miss penalties versus a 386DX/486 class
system with a 32-bit bus. That matters for VM-heavy workloads and makes the SX
feel “stickier� under context-switching. Digi-Key Media

(c) Ring transitions and returns. The 80386 manual gives concrete clocks for
IRET/IRETD:

IRET (same privilege): 22 cycles (pm=38 in protected mode table).

IRET to lower privilege (e.g., kernel→user): ~82 cycles.

IRETD into V86: ~60 cycles.Translate to wall-time: at 33 MHz that’s roughly
0.67 µs, 2.48 µs, and 1.82 µs, respectively—just for the return. Entry via INT
n adds more (descriptor lookup, flag push, etc.). This is why many kernels
favoured “fastpath� syscalls and avoided unnecessary privilege flips. MIT CSAIL
PDOS

(d) Bulk copies & paging pressure. The same manual gives REP-string timings;
e.g., REP MOVS m32,m32 costs 5 + 4·ECX cycles. Copying one 4 KiB page (
ECX=1024) bottoms out at ~4101 cycles → ≈124 µs @ 33 MHz (ideal, no wait states)
. That’s per page and doesn’t include page faults, TLB misses, or DMA
contention. Paging schemes that bounce pages frequently pay this tax
repeatedly; the 386’s lack of on-chip cache makes real-world times worse on
slow DRAM. MIT CSAIL PDOS

(e) Hardware task switching: why almost nobody kept it. Full TSS-based switches
reload all segment registers (forcing descriptor checks), potentially load a
new CR3 (TLB flush), and generally touch far more state than a minimal software
context switch. Empirical/folklore numbers put 386 hardware switches at ~300
cycles vs. a teensy software switch in the tens of cycles range—plus the TLB
fallout if CR3 changes. OS development communities have long documented
avoiding hardware task switching for these reasons. The important point here
isn’t the exact number; it’s that 386 made both models possible, and the
industry standardized on “paging + software CS� because it was faster and more
controllable. OSDev+1

Bottom line on micro-perf: the 386 MMU wasn’t just “there�—it came with
predictable costs (TLB flush on CR3, multi-read page walks, privilege-change
latencies) that OSes engineered around. That predictability across an ocean of
386-compatible machines let kernel writers build robust schedulers, VM systems,
and syscall paths with known trade-offs. MIT CSAIL PDOS

“But other CPUs had MMUs…� — correct, and that helps my point

Motorola’s 68k line had MMU options earlier (68020 + external 68851 PMMU;
integrated MMU in 68030/68040). That’s exactly why serious UNIXes ran well on
68k workstations and why A/UX or Linux/m68k require a PMMU (68020+68851 or
68030+). The difference is commercial ubiquity: the PC-clone world converged
hard on the 386 feature set, giving OS vendors a massive, uniform hardware
target; the 68k world was fragmented across external vs. on-die MMUs and
diverse platforms. Wikipedia+2Linux m68k+2

Context switch with address-space change (CR3 write) on a 386SX

Save regs (software) → small, tens of cycles.

MOV CR3, eax → TLB flushed (size unspecified by Intel, but it’s fully nuked).

First touches after switch: every distinct page incurs a two-level page walk;
on SX each 32-bit PDE/PTE costs two bus transfers. You feel this on task “cold
start,� then TLB warms up. This is exactly why many kernels cluster hot
scheduling domains and avoid needless address-space flips. MIT CSAIL PDOS+1

Kernel → user return after a system call that changed privilege

The manual’s own numbers: IRET to lesser privilege ~82 cycles, ≈2.48 µs @ 33
MHz (best-case). Add cache/memory realities and you’re safely in low single-
digit microseconds per syscall exit, which stacks up in IPC-heavy workloads.
MIT CSAIL PDOS

Page-in path for a 4 KiB fault (simplified)

Fault trap (IDT lookup, pushes) → service routine → disk I/O → page filled →
PTE updated → invalidation of old mapping not required on 386 (no global bit;
all TLB is already per-CR3), but if another CPU existed you’d shoot down; on
uniprocessor 386 it’s “just� ensuring coherence. The expensive bit in tight
loops isn’t the trap itself; it’s the ensuing memory traffic and the cold TLB. (
Global-page optimizations arrived much later.) MIT CSAIL PDOS

Copy-on-write fork storm

You pay REP-MOVS or page-copy costs repeatedly (≈124 µs/page @ 33 MHz
idealized), TLB churn on both parent/child, and if you’re on a 386SX your page-
walk penalties double on every TLB miss due to the 16-bit bus. None of this is
nice, but it’s deterministic, and that’s what enabled robust VM policies in
mainstream PC OSes. MIT CSAIL PDOS+1

“Preemptive OSes existed without an MMU (e.g., AmigaOS). So the 386 MMU wasn’t
essential.�

True: preemption ≠ protection. You can preempt without an MMU. But mass
deployment of a general-purpose desktop OS running untrusted third-party
binaries, multitasking legacy DOS apps, and surviving random drivers is
essentially impossible to make reliable without hardware-enforced isolation (
paged VM + privilege rings). The PC market exploded specifically on cheap,
uniform 386-class boxes; OS/2 2.0, Win3.x Enhanced Mode, NT, and Linux all
built on the 386 MMU model to deliver that isolation at scale—while still
letting people run DOS. That is precisely the “install-base enabling� story.
Kernel Documentation+3Bitsavers+3KO Myung-Hun's Homepage+3

I’m squarely not supporting the idea that the 386 MMU “wasn’t important.�
Technically and commercially, it was the keystone for mass-market, memory-
protected, preemptive OS deployment on PCs: it standardized the VM/privilege
model; it enabled safe DOS coexistence (V86); and it did so across a tidal wave
of commodity hardware, letting OS authors optimize around well-understood
costs (TLB flushes, page walks, privilege transitions). That combination—not
just “an MMU somewhere,� but the 386 MMU model landing everywhere—made the
difference. Kernel Documentation+4Wikipedia+4MIT CSAIL PDOS+4

Want proof?

Target: 80386DX @ 25–40 MHz and/or 80386SX @ similar clocks. Disable any
external cache if present (some late 386 boards have it).

OS: two setups:

Real-mode DOS for V86 and “INT/IRET� micro-loops, where we can still flip to
protected mode for MMU tests via a tiny stub.

Minimal 32-bit protected mode stub (flat, paging on/off as needed). You can do
this either “bare metal� or from DOS using a VCPI/DPMI extender you control.

Timer: use the 8254 PIT Channel 0 as a high-resolution clock proxy.

Program mode 2 (rate generator) at 1.193182 MHz / divisor; use a divisor = 1 (
not standard but supported on many clones) for the fastest tick, or divisor =
1193 for ~1 kHz.

Latch and read the counter around your critical section. A full PIT tick is ~
0.838 µs; with divisor = 1 you can resolve single-microsecond-ish events. (No
TSC on 386, so this is your best built-in choice.)

Interrupts: CLI around micro-sections—except the IRQ latency test. Re-enable (
STI) immediately after.

Statistics: run N=10000 iterations; record median, p25/p75, and min (for “best-
case� hardware path). Median dampens the odd SMI/ISA DMA blip.

Sanity: measure an empty harness (start/stop overhead) and subtract it.

Harness skeletonsDOS real-mode, PIT read/write helpers (MASM/TASM-style);

Quote:

; PIT ports PIT_CH0 EQU 40h PIT_CMD EQU 43h ; Init PIT ch0, mode 2, binary, lobyte/hibyte, counter 0 ; divisor in AX init_pit_ch0: push dx mov dx, PIT_CMD mov al, 00110100b ; ch0, lobyte/hibyte, mode 2, binary out dx, al mov dx, PIT_CH0 out dx, al ; lobyte mov al, ah out dx, al ; hibyte pop dx ret ; Latch and read ch0 (returns 16-bit count in AX) read_pit_ch0: push dx mov dx, PIT_CMD mov al, 00000000b ; latch ch0 out dx, al mov dx, PIT_CH0 in al, dx mov ah, al in al, dx xchg al, ah ; AX = count (hi:lo) pop dx ret ; begin timing call read_pit_ch0 mov bx, ax ; start ; ------- your code under test here ------- ; end timing call read_pit_ch0 sub bx, ax ; delta = start - end (counter counts down) ; store BX to buffer

Convert PIT counts to microseconds: µs ≈ (delta / 1.193182) if divisor=1; or
multiply by the divisor if you used one.

Experiments (what to measure and how)A) Baselines: INT/IRET, privilege changes,
V86 enter/exit

Goal: raw path length for typical control-transfer machinery.

Same-ring INT n → IRET loop

Real mode: hand-install a tiny IVT handler that just IRETs.

Time INT 0x66 + IRET.

Variant: push longer frames (simulate a few register saves) inside handler to
see stack traffic cost.

Protected-mode ring-change return cost

Enter 32-bit protected mode (no paging), set up IDT with gate to ring 0
handler; from ring 3, invoke it via INT n, return via IRETD.

Time just the return path by starting timer inside the handler right before
IRETD.

Record: IRETD same-ring vs. ring-lowering vs. V86 return (next item).

V86 entry/exit

From ring 0 protected mode, set up a TSS with EFLAGS.VM=1 and a V86 stack/CS:
IP. Use IRETD to enter V86, immediately do an INT (handled by the monitor) and
return to pmode.

Time: IRETD into V86 + minimal exit via monitor.

Report: entry, exit, and round-trip.

Why: This gives you hard microsecond timings for the exact mechanisms OSes use
for syscalls and DOS-box virtualization on 386.

B) MOV CR3,reg TLB flush + warm-up cost

Goal: quantify the penalty of an address-space switch and the ensuing page-
walks.

Setup

Paging ON, 4 KiB pages, identity map a kernel region and two user regions U1
and U2, each mapping a contiguous 256 KiB array (64 pages).

Build two page directories + tables: PD1/PT1 for U1; PD2/PT2 for U2.

Procedure

Touch (read) every page in U1 to warm TLB.

Start timer, MOV CR3, PD2_phys (TLB flush), then sequentially read the first
dword of each page in U2. Stop timer.

Repeat N times; also do the reverse (back to PD1).

Variants

386DX vs 386SX: same test; SX will pay 2 bus cycles per 32-bit PTE/PDE read—
expect larger deltas.

Stride: touch pages in random order to defeat simple prefetchers.

Present-but-not-accessed PTEs to observe A-bit setting path cost vs. completely
cold PTEs.

Output: microseconds per address-space switch plus warm-touch of K pages; fit
to T ≈ T_cr3 + K*(T_tlb_miss) to back-solve a per-miss cost.

C) Hardware task switch vs software context switch

Goal: show why everyone went “software.�

Hardware task switch

Build two TSS (TSS1, TSS2) with identical CR3 (no AS flip).

Use a task gate (CALL FAR via gate) from TSS1→TSS2; TSS2 immediately task-
switches back (via another task gate or IRET with NT flag semantics).

Time: round-trip task switch.

Software switch

In ring 0, write a tiny scheduler that saves/restores general regs +
ESP/EBP/ES/DS to per-task structs; do not change CR3.

Time the same number of “switches.�

CR3 change variants

Repeat both with different CR3 to expose combined TSS load + TLB flush cost.

Output: cycles/µs per switch (median). Expect hardware switch to be
dramatically slower, and the CR3 flip to dominate both.

D) REP MOVS* throughput for page-sized copies

Goal: practical floor on page copy cost—key for COW and paging I/O.

Setup

Two 4 KiB-aligned buffers in the same address space.

Zero-fault path (pre-touch both).

Procedure

Time cld / mov ecx,1024 / rep movsd (and movsw on SX to see 16-bit bus
implications).

Measure aligned and misaligned cases: dst aligned, src unaligned by 2–4 bytes;
vice-versa.

Variants

STOSD fill vs MOVSD copy.

MOVSD vs a hand-unrolled loop of MOV/MOV pairs (sometimes matters on weird
chipsets).

Output: µs per 4 KiB, best/median. Convert to MiB/s for intuition.

E) Page-fault service path (demand-zero)

Goal: isolate trap + minimal handler overhead.

Setup

Mark PTEs for a 64-page region not present.

Handler: on #PF, allocate a physical page from a pre-built pool, write PTE (
present|rw|user), then IRET.

Procedure

Time a loop that touches the first byte of each page exactly once (to incur one
fault per page).

Subtract a “no-fault� run that touches a second byte (already present) to
remove cache effects.

Variant

Simulate backing-store latency by inserting calibrated busy-wait (or real
floppy/IDE read) to separate trap cost from I/O.

Output: µs per fault (no I/O), and with synthetic I/O.

F) I/O privilege mediation: port-in with and without IOPL/IOPM

Goal: cost of safe I/O in protected mode (what VMs pay to emulate DOS).

Setup

Ring 3 code attempts in al,dx from some benign port (e.g., 0x61).

Case A: IOPLltan3 and IOPM bit denies; fault to ring 0, emulate read, return.

Case B: IOPM allows the port; no fault.

Case C: Ring 0 direct port read baseline.

Procedure

Time N reads for each case; compute per-op overhead.

Output: emulation overhead per I/O—useful for estimating DOS-VM device access
cost.

G) V86 DOS box: typical “small DOS program� round-trip

Goal: end-to-end cost that users actually feel.

Setup

Install a V86 monitor that intercepts INT 21h and BIOS INT calls.

Tiny DOS program in V86 calls INT 21h in a loop.

Procedure

Time M calls; report µs per call with/without I/O.

Output: latency budget for DOS services under a protected kernel.

Controlling variables (so DX vs SX differences are real)

Bus width: SX’s 16-bit data bus doubles external transactions for 32-bit
PDE/PTE and MOVSD. Expect higher TLB-miss and copy costs.

Clock: record exact MHz (you can compute it by calibrating the PIT against a
known delay loop).

Caches: 386 has no on-chip cache; if your motherboard has external cache, run
tests with it disabled and enabled to show effect on page walks and copies.

Memory wait states: log your chipset timings; they’ll influence absolute
numbers.

Prefetch: 386 has a tiny instruction prefetch queue; keep code blocks small and
aligned; don’t interleave data reads with code fetch more than necessary during
timing windows.

Data collection & reporting

For each experiment: report median, p25, p75, min (best-case).

Convert PIT counts → microseconds; then to cycles using measured CPU MHz (
cycles = µs × MHz).

Normalize deltas to isolate:

T(IRETD ring-lower) − T(IRET same-ring) → privilege-change premium.

T(CR3 + touch K pages) − T(touch K pages, warm) → “pure� CR3 + page-walk
overhead.

T(hw task switch) − T(sw switch) → hardware switch penalty.

Optional: emulator cross-checks (for repeatability)

Bochs: enable IPS and instrumentation to get instruction counts; you won’t get
board-level wait states, but you’ll confirm relative path lengths.

86Box/PCem: pick a period-correct board (386DX/SX), disable caches, and compare
with your real hardware medians.

Quick pseudo-C driver for DOS (Turbo C / Watcom C) to call asm stubsextern
unsigned read_pit_ch0(void);extern void init_pit_ch0(unsigned divisor);


Quote:

extern unsigned read_pit_ch0(void); extern void init_pit_ch0(unsigned divisor); /* asm labels for tests */ extern unsigned test_int_iret(void); /* returns delta ticks */ extern unsigned test_cr3_switch_touch(void); extern unsigned test_hw_task_switch(void); extern unsigned test_sw_task_switch(void); extern unsigned test_rep_movsd_4k(void); #define N 10000 static unsigned deltas[N]; void run(const char* name, unsigned (*fn)(void)) { unsigned i; for (i=0;iltanN;i++) deltas[i] = fn(); /* sort deltas[], compute median/p25/p75/min; print µs = ticks / 1.193182 */ } int main(void) { init_pit_ch0(1); run("INT+IRET same ring", test_int_iret); run("CR3 switch + 64 pages touch", test_cr3_switch_touch); run("HW task switch", test_hw_task_switch); run("SW task switch", test_sw_task_switch); run("REP MOVSD 4KiB", test_rep_movsd_4k); return 0; }

IRETD ring-lowering costs a few dozen cycles more than same-ring IRET; V86
enter/exit sits in between but closer to ring changes than same-ring.

CR3 reload + K page touches scales roughly linearly with K; SX shows a
noticeably worse slope due to 16-bit bus on PDE/PTE fetches.

Hardware task switch is substantially slower than the minimalist software
save/restore—especially once CR3 differs.

REP MOVSD 4 KiB takes on the order of low-hundreds of microseconds on a ~33 MHz
386DX in ideal conditions; SX degrades further, and misalignment hurts.

Demand-zero page faults (no I/O) are microsecond-scale overhead per fault; I/O
dominates once you add disk.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@OneTimer1

Quote:

OneTimer1 wrote: @agami Quote: Like I said, a bot. Post some random CPU benchmarks from the past, calling it a useful answer and information.

Realizing if SOMEthing (note the uppercase) is useful / information requires both understanding the context AND having a proper, adeguate (technical) knowledge about it.

Which is clearly not granted, even to some (supposed to be) technical people which are intervening in threads from time to time...

@OneTimer1

Quote:

OneTimer1 wrote: @agami Quote: Like I said, a bot. Post some random CPU benchmarks from the past, calling it a useful answer and information.

You must have an outdated view of a 'bot', as one being a simple posting agent pasting in random non-contextual text.

What @hammer is doing can be built with n8n and a LLM in 30 minutes.

_________________
All the way, with 68k

Quote:

agami wrote: You must have an outdated view of a 'bot', as one being a simple posting agent pasting in random non-contextual text. What @hammer is doing can be built with n8n and a LLM in 30 minutes.

Took █████ a couple hours to build F̸r̸i̸c̸o̸p̸a̸l̸!̸ a similar bot that was of course never ever put to use on this forum.



/m!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL

What matters is the management issue that directs technical implementation.

Cesare Di Mauro is stupid enough to support Motorola's management direction. Result matters.

I told Cesare Di Mauro about Windows 3.1/3.11 Enhanced Mode utilizing 386 PMMU, and he went on about not needing 386 PMMU. You can test disabled MMU 386 with PCx 2.1 demo emulator, which breaks EMM386 and Windows 3.1 Enhanced Mode.

There's a difference between an argument based on retail release and an argument based on product development before retail release.

The management issue with the "next gen" is in product development before retail release.

The 386 camp was repositioning the x86 PC install base for mass "next gen" 32-bit preemptive multi-tasking/32-bit memory protection/C2 data resource control OS deployment when 16-bit MS-DOS dominated the PC market. The 386 camp created its future based on the present development plans.

-----------------
NXP's PPC e5500's missing Altivec vs PPC e6500's Altivec is absurd. At least, Gunnar made AMMX standard for his AC68080.

Last edited by Hammer on 15-Sep-2025 at 06:14 AM.
Last edited by Hammer on 15-Sep-2025 at 06:07 AM.

_________________

@cdimauro

Quote:

The problem wasn't Motorola (which, as I've tried to explain, had a very good product line), rather your continuous lack of understanding of the context and repeating the same things (which, obviously, don't change the situation).

Wrong. It wasn't a price vs. performance competitive after the initial 68000 success. The debate is about Commodore's after the A500 business.

All mainstream post-16-bit game consoles have abandoned 68K and 65K CPU families.
Two mainstream game console vendors selected the MIPS CPU family.

https://segaretro.org/History_of_the_Sega_Saturn/Development
For Sega Saturn's development, the Motorola 68030 processor was evaluated and displaced by Hitachi SuperH2.

Why not 68EC040/68LC040/68040? 68030 was an indication of the CPU price range.

Sega's Mega Drive successor information leak started around 1991.

Commodore rejected Motorola's 88000 solution on the pricing issue for the Amiga CD3D game console project, which serves as A1200's ASIC components replacement.

You keep on injecting technical red herrings when management is the problem!

_________________

@Hammer

Quote:

Hammer wrote: @MEGA_RJ_MICAL What matters is the management issue that directs technical implementation.

You still don't get that he's trolling you using ChatGTP...
Quote:

Cesare Di Mauro is stupid enough

Well, well, well: you started again going personal with free offences. Guess what: it's the clear signal that you aren't able to sustain the discussion, and it's your way to gratify your violated ego. Go ahead and cry to your mommy.



This clarified, I leave it to other users to classify someone who lets himself be trolled briskly by posts that even a child could tell were AI bot-generated stuff.
Quote:

to support Motorola's management direction. Result matters.

What matter should be understanding the context, which is the most important thing (and that you clearly completely miss. AS USUAL, with you, since you're hopeless), and specifically that Motorola offered a rich portfolio of chips that should be only to the companies decide which ones to select for their own products.
Quote:

I told Cesare Di Mauro about Windows 3.1/3.11 Enhanced Mode utilizing 386 PMMU, and he went on about not needing 386 PMMU. You can test disabled MMU 386 with PCx 2.1 demo emulator, which breaks EMM386 and Windows 3.1 Enhanced Mode. There's a difference between an argument based on retail release and an argument based on product development before retail release. The management issue with the "next gen" is in product development before retail release. The 386 camp was repositioning the x86 PC install base for mass "next gen" 32-bit preemptive multi-tasking/32-bit memory protection/C2 data resource control OS deployment when 16-bit MS-DOS dominated the PC market. The 386 camp created its future based on the present development plans. ----------------- NXP's PPC e5500's missing Altivec vs PPC e6500's Altivec is absurd. At least, Gunnar made AMMX standard for his AC68080.

See above, plus:



I've already replied on the previous thread, added more other posts here, and specifically summarized everything on the previous post #5: that's enough for me, and I add nothing else because you're just a hamster which continously parrots the same things without having a clue of what he's talking about.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: The problem wasn't Motorola (which, as I've tried to explain, had a very good product line), rather your continuous lack of understanding of the context and repeating the same things (which, obviously, don't change the situation). Wrong. It wasn't a price vs. performance competitive after the initial 68000 success. The debate is about Commodore's after the A500 business.

This (part of the previous) discussion was only centered on the needs (included hardware) of the applications running on MAINSTREAM OSes. As it can be easily verified on the previous discussion (link provided on the first post).

However, and as usual, you forget / miss it, and you completely derail.

Hopeless...
Quote:

All mainstream post-16-bit game consoles have abandoned 68K and 65K CPU families. Two mainstream game console vendors selected the MIPS CPU family. https://segaretro.org/History_of_the_Sega_Saturn/Development For Sega Saturn's development, the Motorola 68030 processor was evaluated and displaced by Hitachi SuperH2. Why not 68EC040/68LC040/68040? 68030 was an indication of the CPU price range. Sega's Mega Drive successor information leak started around 1991. Commodore rejected Motorola's 88000 solution on the pricing issue for the Amiga CD3D game console project, which serves as A1200's ASIC components replacement.

I reveal you a secret: Amigas were NOT consoles, rather a FAMILY of personal computers. For which BACKWARD COMPATIBILITY was very important: which was NOT the case with consoles (UNTIL RECENTLY).
Quote:

You keep on injecting technical red herrings when management is the problem!

Brain is the problem, here. Because a decent brain is needed to recall the context of the discussion, and STAY ON TOPIC.

Which is clearly NOT your case, hopeless BOT!

@cdimauro

Quote:

This (part of the previous) discussion was only centered on the needs (included hardware) of the applications running on MAINSTREAM OSes. As it can be easily verified on the previous discussion (link provided on the first post).

Read https://amigaworld.net/modules/newbb/viewtopic.php?
mode=viewtopic&topic_id=45506&forum=2&start=0&viewmode=flat&order=0

ppcamiga1's debate is after the A500 business.


Quote:

I reveal you a secret: Amigas were NOT consoles, rather a FAMILY of personal computers.

Amiga's high integration without a partitioned graphics architecture is a game console.

I reveal you a secret: The Amiga followed Jay Miner's Atari game console's high system integration level and carried over into AAA e.g. Mary's DMA is highly dependent on Andrea's DMA controller role.

The incomplete Andrea means Mary's Paula improvement is a no-go. A modular PC can upgrade its sound solution at any time and at the modular add-on card level.

Amiga Hombre ditched the chipset timing backward compatibility requirement with the Amiga OCS/AGA. Amiga Hombre's $50 BOM cost parameters for CPU/GPU are influenced by CD3D consideration.

Both A1200 and CD32 have common cost parameters with baseline CPU selection and multimedia ASICs.

The modular Amiga plan was rejected by management.

I reveal you a secret: The "Personal Computer" refers to a family of desktop [b]microcomputers/[b] with 1st party Microsoft OS and X86 CPU! Your definition is like a johnny-come-lately.

The Amiga is just Amiga.
The Mac is just a Mac.

Quote:

For which BACKWARD COMPATIBILITY was very important: which was NOT the case with consoles (UNTIL RECENTLY).

Wrong. Sony's PS2 is backward compatible with PS1, and this is not recent.

Sony PS1 is the "games console king" after the 16-bit era game consoles.

While the fat PlayStation 3 had backward compatibility with the bundled PS2 SoC, the PowerPC-based PlayStation 3 was abnormal between MIPS-based PS1/PS2 and X86-64-based PS4/PS4Pro/PS5/PS5Pro.

Last edited by Hammer on 10-Nov-2025 at 05:09 AM.
Last edited by Hammer on 10-Nov-2025 at 05:07 AM.
Last edited by Hammer on 10-Nov-2025 at 05:02 AM.
Last edited by Hammer on 10-Nov-2025 at 04:56 AM.

_________________

@cdimauro

Quote:

You completely forgot the original context of the discussion, which was about MAINSTREAM/CONSUMER OSes.

Windows 3.1 Enhanced Mode requires a 386 PMMU, you fucking fool.

_________________

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: This (part of the previous) discussion was only centered on the needs (included hardware) of the applications running on MAINSTREAM OSes. As it can be easily verified on the previous discussion (link provided on the first post). Read https://amigaworld.net/modules/newbb/viewtopic.php? mode=viewtopic&topic_id=45506&forum=2&start=0&viewmode=flat&order=0 ppcamiga1's debate is after the A500 business.

1. I don't care, because I've already replied.
2. You're not even able to share a link...

Quote:

Quote: I reveal you a secret: Amigas were NOT consoles, rather a FAMILY of personal computers. Amiga's high integration without a partitioned graphics architecture is a game console. I reveal you a secret: The Amiga followed Jay Miner's Atari game console's high system integration level and carried over into AAA e.g. Mary's DMA is highly dependent on Andrea's DMA controller role. The incomplete Andrea means Mary's Paula improvement is a no-go. A modular PC can upgrade its sound solution at any time and at the modular add-on card level. Amiga Hombre ditched the chipset timing backward compatibility requirement with the Amiga OCS/AGA. Amiga Hombre's $50 BOM cost parameters for CPU/GPU are influenced by CD3D consideration. Both A1200 and CD32 have common cost parameters with baseline CPU selection and multimedia ASICs. The modular Amiga plan was rejected by management. I reveal you a secret: The "Personal Computer" refers to a family of desktop [b]microcomputers/[b] with 1st party Microsoft OS and X86 CPU! Your definition is like a johnny-come-lately. The Amiga is just Amiga. The Mac is just a Mac.

This part of discussion was about the CPU = PROCESSOR, and guess what you did? You completely derailed.

HOPELESS BOT!
Quote:

Quote: For which BACKWARD COMPATIBILITY was very important: which was NOT the case with consoles (UNTIL RECENTLY). Wrong. Sony's PS2 is backward compatible with PS1, and this is not recent. Sony PS1 is the "games console king" after the 16-bit era game consoles. While the fat PlayStation 3 had backward compatibility with the bundled PS2 SoC, the PowerPC-based PlayStation 3 was abnormal between MIPS-based PS1/PS2 and X86-64-based PS4/PS4Pro/PS5/PS5Pro.

PS2 = 2000. Amiga died on... rolling drum... 1994!

Contextualizing? Not an option for a BOT...
Quote:

Hammer wrote: @cdimauro Quote: You completely forgot the original context of the discussion, which was about MAINSTREAM/CONSUMER OSes. Windows 3.1 Enhanced Mode requires a 386 PMMU, you fucking fool.

And again you start with the same mantra after all discussions and clarifications, because it is what it is: you're a BOT which hopelessly repeat again, and again, and again the same things.

And since you're not able to continue the discussion, you go personal, insulting. You miss nothing!



BTW, you completely disappeared when other people exploited that you're acting effectively as a bot. Only since a while you came back, and trying to sell again your shit, like nothing happened in the past.

However, human beings are better than bots, because they... recall very well what happened. And the forum is a nice resource to show how completely ignorant and incapable of sustaining discussions you were.

You should have understood it very well after so many times that you got what you deserve, but evidently not only you're a joke of (step) mother Nature, but you're a masochist which likes to be beaten, and that's the reason why you come back here.

HOPELESS!

@MEGA_RJ_MICAL

Quote:

OS/2 2.0 (1992): depends on V86 + paging to create multiple isolated DOS boxes and a flat 32-bit address model for native apps. That was explicitly a 386 design decision. Bitsavers Windows 3.0/3.1 Enhanced Mode: runs on 386+ only; uses protected mode + V86 to preemptively run DOS VMs while Windows apps cooperatively multitask, and adds demand paging for Windows apps. KO Myung-Hun's Homepage+1

Windows 3.1 Enhanced Mode's virtual device drivers (VxDs) have memory protection, primarily through the Virtual Machine Manager (VMM), which provides services like memory management, event scheduling, and protected-mode execution for each virtual machine.
While there is protection, the system is not as robust as a modern OS like Windows NT.

Quote:

Windows NT 3.1 (1993): the x86 build’s baseline CPU was the 80386; NT’s design presumes paging, rings, and a clean user/kernel split. Bitsavers

Microsoft's earlier Windows NT 3.1 beta and Windows 3.1's Win32 releases were done strategically. They signal to the market that Microsoft, as an OS vendor, has a valid roadmap towards a memory-protected Windows future.

Microsoft released Windows NT 3.1 beta during COMDEX's October 1991.
https://betawiki.net/wiki/Windows_NT_3.1_October_1991_build

Without the Microsoft factor, other OS vendors on 386-based PC had a chance, such as SCO Open Desktop 1.0 (1990).


Quote:

Motorola’s 68k line had MMU options earlier (68020 + external 68851 PMMU; integrated MMU in 68030/68040). That’s exactly why serious UNIXes ran well on 68k workstations and why A/UX or Linux/m68k require a PMMU (68020+68851 or 68030+). The difference is commercial ubiquity: the PC-clone world converged hard on the 386 feature set, giving OS vendors a massive, uniform hardware target; the 68k world was fragmented across external vs. on-die MMUs and diverse platforms.

FYI, Apple's A/UX operating system required a floating-point unit (FPU) in the Mac computer, along with a paged memory management unit (PMMU), hence Macs with 68LC040 wouldn't be able to run A/UX. Macs with 68LC040 would need the full 68040 replacement.

Commodore wasted R&D on two custom PMMUs for 68000 and 68020. Commodore wasted R&D time on A2620 with C= PMMU and later MC68851 PMMU.

During the Amiga era, Commodore's Unix advocates had dreams of Unix everywhere, hence repeating the C900 debacle.

386's integrated PMMU was one up against Motorola's two-chip (68010 + 68451) combo.

68020's 68851 PMMU was late, and SUN-3 boxes with 68020 had a proprietary SUN MMU.

The full 32-bit 68K UNIX ecosystem was fragmented with system integrator vendor lock-in.

Clone 386 vendors made 386DX affordable e.g. 40 Mhz Am386DX for the price of 25 Mhz i386DX or 25 Mhz MC68030.

The popular GVP A530 (for A500) has 68EC030-40 while C= A4000/030 has 68EC030-25. There was a chicken vs egg problem with any potential NT-ed AmigaOS roadmap. Commodore ran the AmigaOS into a dead end since Herni Rubin was betting on AMIX (AT&T licensed Unix).

Since AT&T's licensed Unix wasn't cheap, Linux and Windows NT killed AT&T's licensed Unix business.

With A2500/UX and A3000/UX, Herni Rubin delivered AT&T's licensed Unix 68K workstations with TiGA's business high resolution with 256 color tick boxes as envisaged by the C900 advocates. Herni Rubin delivered what's required of him.

Quote:

Target: 80386DX @ 25–40 MHz and/or 80386SX @ similar clocks. Disable any external cache if present (some late 386 boards have it).

My Q4 1992 386DX33 PC had a cache on the motherboard.

Last edited by Hammer on 10-Nov-2025 at 07:02 AM.
Last edited by Hammer on 10-Nov-2025 at 06:44 AM.

_________________

@cdimauro
Quote:

I don't care, because I've already replied. 2. You're not even able to share a link...

I don't care, because you can't read.

Quote:

This part of discussion was about the CPU = PROCESSOR, and guess what you did? You completely derailed.

You posted link

Quote:

PS2 = 2000. Amiga died on... rolling drum... 1994!

PS2's product release in 2000 is NOT during PS2's design phase, Mario. This is Q4 2025, and there have been nearly 25 years since 2000.

You are either in the platform vendor's POV or the end consumer's POV. Pick one!

From Sony's POV, the PS2 was designed to be backward compatible with MIPS-based PS1.

Are you asserting PS2's PS1 backward compatibility design occurred at its product release window? Foolish Mario.

PPC-based PS3 was abnormal among MIPS-based PS1/PS2 and x86-64 based PS4/PS5/PS6.
That's one PS3 release vs PS1/PS2 and PS4/PS5, and including PS6.

Your mistake with dismissing "read my lips, no new chips" is based on ECS being new graphics chips from the end consumer's POV, not from the platform vendor's POV!

For mass production, the CPU selection for system integration occurs at the system design phase i.e. the platform vendor's POV.

Last edited by Hammer on 10-Nov-2025 at 06:32 AM.

_________________

@Hammer

Quote:

Hammer wrote: PS2's product release in 2000 is NOT during PS2's design phase, Mario. This is Q4 2025, and there have been nearly 25 years since 2000. You are either in the platform vendor's POV or the end consumer's POV. Pick one! From Sony's POV, the PS2 was designed to be backward compatible with MIPS-based PS1. Are you asserting PS2's PS1 backward compatibility design occurred at its product release window? Foolish Mario. PPC-based PS3 was abnormal among MIPS-based PS1/PS2 and x86-64 based PS4/PS5/PS6. That's one PS3 release vs PS1/PS2 and PS4/PS5, and including PS6. Your mistake with dismissing "read my lips, no new chips" is based on ECS being new graphics chips from the end consumer's POV, not from the platform vendor's POV! For mass production, the CPU selection for system integration occurs at the system design phase i.e. the platform vendor's POV.

You must consider Pros and Cons of the underlaying system Architecture:

1. RISC and Superscalar Processor Architecture

The IBM RS/6000 family was built upon IBM’s POWER and POWER2 RISC architectures, which later evolved into the PowerPC lineage. Unlike CISC-based processors of its era, the RS/6000’s RISC design implemented a reduced and highly optimized instruction set, allowing for shorter instruction execution cycles (often one instruction per clock cycle) and deeper instruction pipelining.

The RS/6000 employed superscalar execution, meaning multiple instructions could be issued and executed in parallel per cycle. Combined with dedicated floating-point units (FPUs), the RS/6000 achieved exceptional throughput for computation-intensive workloads such as numerical simulations and 3D transformations.

Performance advantages:

Typical instruction latency: 1–2 clock cycles for integer arithmetic, 3–4 for floating-point operations.

Instruction issue rate: Up to 3 instructions per cycle on dual-integer/FP pipelines.

Clock frequencies: Early RS/6000 models reached ~40–80 MHz, with later POWER2 processors exceeding 120 MHz while maintaining pipeline efficiency.

This architectural efficiency made the RS/6000 particularly effective in scientific and meteorological applications, where sustained floating-point throughput and deterministic timing are crucial for iterative simulation models.

2. Advanced Cache and Memory Hierarchy

The RS/6000 featured split instruction and data caches, typically 32 KB each, later expanded in POWER2 designs. The architecture employed non-blocking, write-back caches and burst-mode memory transfers through the IOCC (Input/Output Channel Controller), significantly reducing memory stall times.

Key advantages:

Cache hit latency: ~2 cycles for L1, 10–15 cycles for L2 in POWER2 models.

Sustained memory bandwidth: Optimized for large sequential reads/writes used in array-based modeling.

Balanced architecture: CPU, cache, and I/O subsystems were tuned to avoid data-path bottlenecks — a design IBM termed Balanced System Performance.

In meteorological modeling — for instance, global circulation models or regional weather simulations — such cache and memory efficiency reduced computational delays in large matrix and tensor operations, accelerating time-stepped numerical integration.

3. Micro Channel Architecture (MCA) Expansion Bus

The MCA bus, introduced by IBM as a 16/32-bit parallel bus, served as the RS/6000’s backbone for high-speed peripherals and graphics adapters.

Data throughput: up to 40 MB/s (synchronous burst mode).

Advanced DMA support: up to 15 concurrent channels with prioritized interrupt handling.

Streaming transfer modes: reduced I/O latency during continuous data acquisition (e.g., meteorological sensor input or satellite imagery).

Compared to ISA/EISA systems of the time, MCA provided superior bus arbitration, error correction, and I/O determinism, which were vital for real-time or near-real-time weather data assimilation systems.

4. Graphics and Visualization (IBM–Silicon Graphics Collaboration)

IBM collaborated with Silicon Graphics, Inc. (SGI) to integrate advanced 3D rendering technologies, including licensing of IRIS GL, the precursor to OpenGL.
This enabled IBM RS/6000 POWERstations to support SGI’s graphical APIs and hardware principles, making them fully capable of complex scientific visualization, including meteorological 3D models, atmospheric data plots, and geospatial renderings.

Combined benefits:

High floating-point density for rendering volumetric data sets (e.g., cloud formation modeling).

MCA bus throughput sufficient to sustain real-time frame updates for simulation visualization.

SGI API compatibility, allowing easy porting of visualization tools used in climatology and Earth sciences.

5. Impact on Weather and Climate Modeling

Weather and climate modeling are computationally dominated by:

Matrix and vector operations

Partial differential equation solvers

3D grid interpolation and FFT-based spectral transforms

The RS/6000’s RISC-based pipeline efficiency and large floating-point throughput provided the foundation for the first scalable UNIX-based weather simulation systems at national meteorological institutes.
Coupled with its low memory-access latency, predictable instruction timing, and high I/O bandwidth, the RS/6000 became a preferred platform for AIX-based numerical weather prediction (NWP) and climate model prototyping in the early 1990s.

Summary of Advantages
Feature Technical Benefit Relevance to Weather Modeling
RISC/Superscalar CPU One instruction per cycle, low latency Accelerates iterative forecast loops
Dual FPUs Parallel floating-point pipelines High throughput in numerical solvers
Split L1 Caches Reduced contention between code and data Stable simulation performance
MCA Bus High DMA and streaming I/O Real-time sensor data ingestion
SGI IRIS GL Integration Advanced 3D visualization Visual analysis of weather fields