Is it possible to overclock a 6502 to 100GHz

[jmthompson]

Hmm, would nanobots be susceptible to an EMP, or are they too small? I am envisioning a sealed (Faraday cage) chamber that patients could be put into and hit with an EMP to fry any existing nanobots.

[ttlworks]

Maybe yes, but the nanobots (and their batteries) still would stay inside the body.
But maybe we are thinking just too much in technical terms.



Tyrophagus casei, a highly compact/functional design. Males are 450..550µm in size, females 500..700µm.
The cheese mite sure is a beauty (it even got a monument).

Back in the dark ages, before chemical conservation of food had been invented, it wasn't technically possible to separate the cheese from the mites.
The solution then was to put a piece of cheese plus something more tasty than the cheese into a box of cheese mites.
The mites then gratefully gave the cheese a fancy antiseptic coating.
There is a story, that the cheese sometimes still was eatable after more than 30 years.
Those who don't believe me could buy their mite cheese here.


Isolating/defusing a tumor by encapsulating it in the digestive end product of microscopic arachnids,
just don't forget to give them something more tasty than the patient.
Since no two tumors of the same type are identical, maybe the mite sensors would have to be tuned to the biochemistry of the individual patient,
but maybe this could be automated.
Choosing and genetically modifying a specific type of mites to make them able to do the job is left as a homework assignment for the advanced biologist.

Hey, it's just a theory, don't know if this would work at all.

[EvilSandwich]

Okay okay okay. Can I just say that topics like this are why I adore hobby forums like this?

I'm of the same mindset as most people here. I first ask myself, "B-but why tho?" And then my baser nerd instincts kick in and I'm like, "But I kinda wanna see it done anyway. Just because I wanna see if you can." lol

[ttlworks]

Ja, sometimes when trying to solve a technical problem, you have to think "outside the box" and to go with what's available.

Without forums like this, our brains eventually would dry out.

[barrym95838]

EvilSandwich wrote:

... I first ask myself, "B-but why tho?" And then my baser nerd instincts kick in and I'm like, "But I kinda wanna see it done anyway. Just because I wanna see if you can." lol

I just want to legitimately say that I lost a game of Asteroids in 0.03 seconds.

[GARTHWILSON]

dwight wrote:

They seem to be a number of misconceptions on what reducing dimensions of size buys you. With each reduction, there is always some trade off where one of the physical laws of physics becomes the dominant limiter. Before 120 nm it was the capacitance of the transistors to the die. From there to about 40 nm it was the low gain of the P-channel transistors. From the P-channel were fixed by the fin-fets. At around 10 to 7 nm the problem is becoming the internal resistance of the interconnecting wires and even fin-fet has lost its shine. 14-10 nm is about the limit of practical I/O drive. Real world interconnect wires are about 100 ohms impedance. Even with voltage reduction, noise limits it are becoming more difficult to deal with I/O.
It seems that around 5GHz is about the lower limit of practical silicon use. Going below 10 nm doesn't help that. The thought of even a 10 gHz 6502 at 14 nm doesn't make sense. Remember, the Intel processors are not doing everything in a single cycle like the 6502 is. These processors that are doing this level are there because they use pipelining and speculative execution ( causing side band security leaks ). Having the processor fetch, decode, execute and store data like the 6502 does within one or two clock cycles at even 5 gHz doesn't even sound practical. There are too many limiting cases.
Dwight

A friend who has worked in IC design sent me this link to a .pdf about how die feature size affects speed. It's rather math-intensive, but there's a lot to be gleaned there even without going into that level of math, with the prose and graphs. They're going into the range of 25-100GHz. https://psec.uchicago.edu/workshops/fas ... ndence.pdf

[BillG]

drogon wrote:

However if you want fast, then there is a software emulation of the 6502 that runs at a shade under 300Mhz, complete with 64K RAM that runs inside a 1Ghz Raspberry Pi Zero - this would obviously be much faster in a Piv4, or even a modern x86 system. could you get to 1GHz with a 3-4Ghz x86 type system?

I have read that in several places.

What software benchmark was being run to make that measurement? A simple loop or something more representative of real programs?

[Chromatix]

I think it was running something in a BASIC interpreter, so a long way from trivial.

[BigEd]

Indeed, PiTubeDirect is widely used in the Acorn community, where there's a BBC Basic benchmark called CLOCKSP, which uses the usual tactic of looping over various types of computation: integer, real, string, subroutine call and return, log and trig functions. It's purely computational: doesn't measure I/O or graphics. The final thing it does is report the speed as compared to a BBC Micro at 2MHz.

It might be worth noting that PiTubeDirect, when running at full speed, is making no attempt to run at a calibrated speed. Various opcodes will surely run at different speeds, and so loops without much of an instruction mix will have their own average, which might be faster or slower than the benchmark result.

PiTubeDirect can also run in a paced mode, for a moderately accurate 3MHz and 4MHz, for historical compatibility. The paced mode works up to some maximum, which might be about 20MHz, but I don't have the actual figure. (There's a lot more machinery in pacing single instructions, but even so I don't think it accounts for page crossing.)

Edit: RPi4 seems to run the 6502 emulation at 370MHz or so. But most people use a Pi 0.

[BillG]

BigEd wrote:

Indeed, PiTubeDirect is widely used in the Acorn community, where there's a BBC Basic benchmark called CLOCKSP, which uses the usual tactic of looping over various types of computation: integer, real, string, subroutine call and return, log and trig functions. It's purely computational: doesn't measure I/O or graphics. The final thing it does is report the speed as compared to a BBC Micro at 2MHz.

Thanks.

Now I see. It is written in highly optimized ARM assembly language. The ARM instruction set has conditional execution for potentially less need for branching.

The reason I asked about the benchmark is that a simple loop would not exercise many of the emulated instructions, meaning few cache misses.

Any idea what the fastest 6502 emulation on an x86 host currently is?

[BigEd]

beebjit will be very impressive, I'm sure! (10GHz equivalent reported here)

[BillG]

BigEd wrote:

beebjit will be very impressive, I'm sure! (10GHz equivalent reported here)

Very impressive indeed.

I should have qualified my question.

What is the fastest 6502 simulation on an x86 platform which does not use dynamic recompilation?

[BigEd]

I'd reach for Ian Piumarta's lib6502 in that case.
https://www.piumarta.com/software/lib6502/