The 16K memory block is connect to the TMS9918 video chip and is accessed by port read/write. The TI-99 out of the box only has 256 bytes of RAM memory on the 16 bit buss.
UNIX99 uses an after market card with 1Mbyte of RAM on an 8bit external buss used for peripherals. This card replaces the old 32K RAM card made by TI in the 1980s.
Sure. But the emitted chemicals strengthen/weaken specific neurons in our neural nets.
If there were analogous electronic nets in the bot, with analogous electrical/data stimulii, wouldn't the bot "feel" like it had emotions?
Not saying it's like that now, but it should be possible to "emulate" emotions. ??
Our nets seem to believe we have emotions. :-)
Probably worth mentioning that writing a big project in Forth is more like creating an OOP framework.(if you are disciplined)
The end result of that is one doesn't write the program in "Forth" per se but in the domain specific language you create for the job. This is how Forth gets more productive than pure assembly language if the team documents things well and follows the prescribed system.
Forth is a compiler but what it "compiles" is not standard. The implementor decides what they need.
Forth can compile pointers to native code that are the VM's instructions, called direct threading.
Forth can compile pointers to pointers to native code VM instructions, called indirect threading.
Forth can compile byte code like OpenFirmware/OpenBoot.
And modern systems compile optimized native code (VFX Forth, SwiftForth) but still remain fully interactive at the console.
We have one solid example of cancer caused by members of the HPV family. The disease can be transmitted via body fluids and/or contact. So there's that.
My laymans take:
Cancer is a disease of the DNA of a cell.
Viruses survive by altering cellular DNA.
It begs the question: How many other viruses cause cancer?
It also seems clear to me that the virus may not be the sole cause since not everybody gets cancer so it is a multi-variable problem.
Virus + X = cancer
This will be harder to nail down but with modern data tools we should be able to get there.
Makes me wonder:
Is the cancer "industry" searching for causes or just after-the-fact treatment?
Makes me wonder: Is the cancer "industry" searching for causes or just after-the-fact treatment?
Why brag that you are uninformed?
Some of the more successful interventions for cancer are preventative (for example removing polyps during colonoscopies) and genetic counseling is common.
There are other examples of oncoviruses including: Epstein-Barr virus and Human herpes virus 8 (Kaposi's Sarcoma).
Makes me wonder: Is the cancer "industry" searching for causes or just after-the-fact treatment?
There are billions of dollars spent on this problem through huge DNA/RNA/Epigenomics/Chromatin Accessibility sequencing initiatives. There is also a huge amount of model system work such as mouse models.
Viruses are just another "mutagen". No different from UV causing DNA damage in your skin cells, other than the mechanism in which it occurs. The cause for cancer is well-known and, in hindisght, obvious, which is mutation.
The challenge though is mutations can happen in a plethora of ways and their effect is highly dependent on which gene is mutated. There is also the tissue context, e.g. inflammation, spatial structure, etc., that can setup a background for increased mutation. That is why targeted therapies are often the most effective, because they target the general causative feature of a given tumour subtype, the problem is not every protein can be targeted now and each tumour, even within the same subtype has their own unique mutational profile due to the stochasticity of the way mutations occur over repeated rounds of cell division.
And back to viruses, yes they cause cancer because they can mutate DNA. But it's pretty clear, most of the viral "enriched" cancer types are generally in places where transmission is commonplace, e.g. reproductive organs or head/neck.
Why stop there? Perhaps we must recurse our conspiracy theories one level more: what if the faction of the cancer industry that wants after the fact treatment is propagating theories like yours so that they can make the cancer industry seem like all frauds and stop research until proven otherwise. Then they’ll be able to sell their current methods even longer.
Hmm, a disturbing and dangerous thought. But what does that mean for my comment? Who is paying me? What do they want? Will the lizard men of Hippocrates command the subtle ghasts of Papilla to inflict deep and lasting injury to our very souls?
People who need to hit their revenue numbers make allocations decisions.
That's not a conspiracy. It's what people have to do to keep their jobs in industry. And those decisions affect what gets the resources.
And yes I know that outcomes after detection have improved, but the HPV vaccine shows an alternative that to me deserves more resources.
I am simply frustrated by 60 years of research and lots of dead friends and family. If that's a crime get the tar and feathers while I strip down to my shorts.
An engineer at RCA in New Jersey told me that at the first(early) NTSC color demo the interference was corrected by hand tweaking the color sub-carrier oscillator from which vertical and horizontal intervals were derived and the final result was what we got.
The interference was caused when the spectrum of the color sub-carrier over-lapped the spectrum of the horizontal interval in the broadcast signal.
Tweaking the frequencies allowed the two spectra to interleave in the frequency domain.
Our station had an art department that used a hot press to create text boards that were set on an easel that had a camera pointed at it. By using a black background with white text you could merge the text camera with a camera in the studio and "super-imposed the text into the video feed.
"And if you tell the kids that today, they won't believe it!"
I was on a course at Sony in San Mateo in the 1980s and they had a 36" prototype television in the corner. We all asked for it to be turned on. We were told by the instructor that he was not allowed to turn it on because the 40,000V anode voltage generated too many X-rays at the front of the picture tube.
The "R exp" is subroutine call (which saves return address to register B00), and I believe "J Bjk" is the subroutine return.
The Cray-1 didn't have a hardware stack, so subroutine call is basically just jump there and back, using a register for the return address rather than pushing/popping it to/from the stack.
Another oddity of the instruction set that stands out (since I'm in process of defining a VM ISA for a hobby project) is that the branch instructions test a register (A0 or S0) rather than look at status flags. In a modern CPU a conditional branch, if (x < y), is implemented by compare then branch where the compare instruction sets flags as if it had done a subtraction, but doesn't actually modify the accumulator. In the Cray this is evidentially done by doing an actual subtraction, leaving the result in A0, then branching by looking at the value of A0 (vs looking at flags set by CMP).
I recall when reading TAOCP that Knuth's MIX assembly supported subroutines by requiring the caller to modify the RET call to it's own address (obviously not re-entrant!). This sort of thing was common when Knuth started in the early 60's, may have still been around by the time of the Cray.
This Cray version isn't so bad - it just requires that if the callee itself calls other subroutines, then it has to save/restore this B00 return address register. You could still support re-entrant routines with this as long as you saved/restored the return address to a software stack rather than a fixed location, but I wonder if Cray compilers typically supported that?
Apparently the reason for using a register vs stack for return address was because memory access (stack) was so much slower.
I'm kinda tempted to use this for the VM I'm designing, which will run on the 6502 8-bit micro. The 6502 doesn't have any 16-bit operations, so pushing and popping using a software defined 16-bit stack pointer is slow, and saving return address to zero page would certainly be faster. It'd mean that rather than always pushing/popping the SP, you only do it in the callee if needed. It's an interesting idea!
Cray's design for Control Data before starting his own company was interesting. You were required to start each subroutine with a jump instruction, and the subroutine call instruction would modify the memory at that location to a jump back to the caller. To return from a subroutine you would just branch back to its beginning.
The following quote gives some sense of how "manual" this was:
> "On execution of the return jump instruction (007), register Boo is set to the next instruction parcel address (P) and a branch to an address specified by ijkm occurs. Upon receiving control, the called routine will conventionally save (Boo) so that the Boo register will be free for the called routine to initiate return jumps of its own. When a called routine wishes to return to its caller, it restores the saved address and executes a 005 instruction. This instruction, which is a branch to (Bjk), causes the address saved in Bjk to be entered into P as the address of the next instruction parcel to be executed."
Details were up to the compiler that produced the machine code.
Essentially, the B00 register is a Top Of (Return) Stack or TOS register. It’s great for leaf routines.
You have to push it to your preferred stack before the next operation. You do the cycle-counting to decide if it’s a good ISA for your implementation, or not.
Obviously, ISAs with a JSR that pushes to stack are always using an extra ALU cycle for the SP math, then a memory write.
Doing it with a (maybe costless) register transfer followed by (only sometimes) a stack PUSH can work out to the same number of cycles.
With improvements in memory speed or CPU speed, that decision can flip.
Consider that in this era, your ALU also had the job of incrementing the PC during an idle pipeline stage (maybe the instruction decode). Doing a SP increment for a PUSH might compete with that, so separating the two might make the pipeline more uniform. I don’t know any of the Cray ISAs so this is just a guess.
Internally Forth can be direct threaded code, indirect threaded code, byte code, sub-routine calls or optimized native code.