6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Jun 04, 2024 2:27 pm

All times are UTC




Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Mon Dec 02, 2019 7:14 pm 
Offline

Joined: Sat Dec 30, 2017 3:19 pm
Posts: 116
Location: Detroit, Michigan, USA
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 03, 2019 7:34 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1395
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.

Image

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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 05, 2019 6:03 pm 
Offline

Joined: Sun Oct 13, 2019 6:20 am
Posts: 36
Location: Pennsylvania, USA
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 06, 2019 6:35 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1395
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. :)


Top
 Profile  
Reply with quote  
PostPosted: Sat Dec 07, 2019 12:51 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1933
Location: Sacramento, CA, USA
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. :shock:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 10, 2020 9:07 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8453
Location: Southern California
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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jul 10, 2020 10:11 pm 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 693
Location: North Tejas
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 1:18 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
I think it was running something in a BASIC interpreter, so a long way from trivial.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 9:12 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10822
Location: England
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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 1:28 pm 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 693
Location: North Tejas
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 2:29 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10822
Location: England
beebjit will be very impressive, I'm sure! (10GHz equivalent reported here)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 3:47 pm 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 693
Location: North Tejas
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Jul 11, 2020 3:50 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10822
Location: England
I'd reach for Ian Piumarta's lib6502 in that case.
https://www.piumarta.com/software/lib6502/


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: