@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!