|
Need a Pi-hole ?
Keep Calm and Carry On
|
|
|
|
|
|
[0,0] Racing engine for a MiniMoto
[0,1] Dual purpose: Egg painting drying rack; Garden spikes to prevent cats using your flower beds as a lavatory.
[1,0] Soap dish
[1,1] Anime doll decoration: Sora Kasugano | Yosuga no Sora Wiki | Fandom[^]
[2,0] Magnetic clip for holding measuring tape to wall (e.g. to measure round a corner)
[2,1] Cordless skipping rope.
[3,0] Mitre ruler: Miter Triangle Ruler[^]
[3,1] 3D FDM printer hotend nozzles (and not what I originally thought*)
Source: Google image search.
* "Screw in butt plugs for tight-assed families"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: [3,1] 3D FDM printer hotend nozzles (and not what I originally thought*)
You wrote some article on 3D Printing! Those were the only item I immediately recognised! 
|
|
|
|
|
You are the ABSOLUTE WINNER of the OFFICIAL NO-Prize[^]!!!!
Your prize will not be sent, to you in an orderly fashion, and will not arrive within 10 business days.
However, you are required by law to observe all the requirements, responsibilities and non-sense associated with the prize. 
|
|
|
|
|
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
#Worldle #522 2/6 (100%)
π©π©π¨β¬β¬β‘οΈ
π©π©π©π©π©π
https://worldle.teuteuf.fr
not too hard no need of map
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Previously I was saying you could setup your attack by sending a group of units G1 to the enemy camp and when they get caught in a fire they canβt respond to they should retreat to a safe distance. Then a new group of units G2 of different type should be sent to remove the enemy units posing a problem to G1. The disadvantage of this tactic is that the remedy units might not be available when the situation described above takes place. That means postponing the attack.
The solution I think is to think ahead. First you need to scout the area where the attack will take place. You start from your base all the way to the enemy camp along the path on which G1 will move. The enemy might have units deployed along the way. For example if your units are fragile against tanks you need a strip of land of 10 tiles (or whatever the attack radius of a tank is) to the right of the path and a strip of 10 tiles to the left of the path free of enemy tanks. If this condition is met you will know your units will be safe while they are traveling. If enemy tanks do exist along the path you can bring in tank counter measure units. Bringing TCM will follow the same rule: make sure the path is safe first if not bring in obstacle counter measure or see if there is another path to get safely to the target unit ( I think I should have started with the last one)
The advantage of the second approach is that the attack takes place all at once. G1 leaves your camp only when G2 is ready to clear the way.
|
|
|
|
|
A deaf or hard-of-hearing ferryman has a wife, two sons and a daughter. They fritter away all their money, and leave him to pay the bill when their credit runs out.
He sees the bailiff coming in the distance and decides to be clever and prepare his answers ahead of time. He reasons that the first thing the man will ask will be about what he is carving. He will say that it is an axe handle. He thinks that the other questions will be about the length of the axe handle, his ferry, his mare and the way to the cowshed.
However, the first thing the bailiff says is "Good day, fellow!" He replies "Axe handle!", thinking himself clever.
Next the bailiff asks how far it is to the inn. "Up to this knot!" he replies, pointing to the axe handle.
The bailiff shakes his head and stares at him.
"Where is your wife, man?" he says.
"I'm going to tar her," says the ferryman. "She's lying on the beach, cracked at both ends."
"Where is your daughter?"
"Oh, she's in the stable, big with foal," he says, still thinking himself clever.
The bailiff finally gets angry with him and shouts, "Go to the devil, fool that you are!"
"Oh, it's not far away, when you're over the hill, you're almost there," says the man.
"Good day, fellow!" "Axe handle!" - Wikipedia[^]
|
|
|
|
|
Maybe you had to be there?
|
|
|
|
|
Probably wouldn't help you much
|
|
|
|
|
That joke gives me a Vorgon poetry vibe:
Quote: Like jowling meated liverslime, Groop,
I implore thee, my foonting turlingdromes,
And hooptiously drangle me,
With crinkly bindlewurdles,mashurbitries.
Advertise here β minimum three posts per day are guaranteed.
|
|
|
|
|
Racing the beam is a way to put graphics on a screen without having any graphics memory. It was used in the 1970s when memory chips still had a tiny capacity and cost their weight in gold or more. The Atari VCS is a well known console that used this. It had only 128 bytes of RAM, the programs were on ROMs in the cartridges, so no room at all for any video buffer.
It is called 'racing the beam' because most of the time the processor is busy staying ahead of the electron beam of the CRT monitor and putting the graphics data that will be displayed next directly into the registers of the graphics chips just in time. Be to quick or too slow and you have only garbage on the screen. And such luxuries as actual gameplay had to wait until the graphics chip was done with the current frame and entered the vertical blank period before starting with the next frame.
Horrible fragile code and a nightmare to debug. Even proper debugging tools as we know them did not exist yet. But programmers who can deal with such old stuff are afraid of nothing.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Being an expert of the 'you have only garbage on the screen' part, I fear nothing. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Yes, in a variety of scenarios. On the Commodore 64, you could get an interrupt at a specific raster line, and one of the geniuses I worked with figured out that you could double the apparent sprites by interrupting halfway during the vertical rendering of the screen and switch the sprite bank pointers. Flip back during vertical refresh.
I also hand coded, counting 80286 instruction cycles, the assembly code necessary to flip a video digitizing board from "read" to "write". See, we had this multispectral camera with a spinning disk of 6 bandpass optical filters in front of the CCD sensor, where the rotation of the disk with the glass filters was sync'd to the vertical refresh rate of the CCD (the flip side of racing the beam). So, 1/60th second, you'd get a different image of a different filter, which was something of a visual mess when looking at different spectrum slices.
I figured out how to put the digitizer board into "read" mode for one field and "write" mode for the other 5, so you could get a stable image real time of a specific filter. All that had to be done during the vertical refresh period.
|
|
|
|
|
C64 raster interrupts were too much fun. You could change video modes, or increase the number of colors that could be displayed on the screen at one time using the raster interrupt. Way too much fun.
|
|
|
|
|
Never used it as such, heard about, used a similar system for RF units using a PIC. All the data was in an array that was picked off and broad cast, issue was the RF unit was too slow for the array pointer, so tricks had to be used to slow operation so that the pointer picked up the next value. I miss those days of looking at a scope and your code trying to figure why? I'm odd I miss those days. 
|
|
|
|
|
I've not done something quite as tricky as that, but I have resorted to similar tricks on an IBM CGA adapter.
The CGA adapter's memory was not double-ported, so writing to it as arbitrary times would interfere with the adapter's access to the memory, causing "snow" to appear on the screen. The BIOS got around this by updating the memory only during vertical refresh, but that was slow. It was discovered that you could just about write one byte to memory during the horizontal refresh, speeding up output considerably.
This had to be done while interrupts were disabled, so you wouldn't miss the window. Ensuring that no interrupts were missed during the screen update made this interesting...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Even dual ported video memory did not solve this problem entirely. There still had to be a hardware mutual exclusion logic to prevent conflicts. Some graphics chips, like the Motorola MC6847 were so nice to have a signal that tells when it's accessing video RAM and when it's not. That practically was all you needed for mutual exclusion. Letting a graphics chip trigger an interrupt upon entering the vertical blank was another option. This would automatically also eliminate the problem of any other interrupts since you already were in an interrupt routine.
But, of course, that also opens another can of worms anywhere where nested interrupts are allowed or things like non maskable interrupts are a thing.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Can you imagine if the interrupter gear that allow WWI aeroplanes to fire the machine guns through the propeller were controlled by such software? A missed interrupt and... BANG! There goes another propeller!!
- I would love to change the world, but they wonβt give me the source code.
|
|
|
|
|
Some things are better handled by hardware...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Memory lane.
Tektonix used to have 4010 and 4014 graphical display terminals using storage tubes as their display memory. They were like an electronic etch-a-sketch. Clear the screen then draw on it much like a line plotter. Used them a-lot in Grad school as terminal for mini-computer (rack mounted Data General Eclipse). Computer graphics was becoming a core course for computer science and math majors at the time. Anyway, point is that this was early days of graphical displays that did not require lots of expensive dedicated raster memory (those types of displays were very expensive and used mostly by CGI business (movies).
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Yes, but not a CRT: cardboard boxes going down a conveyor.
I used to design coding and marking equipment for batch coding goods and boxes of goods as they go down the conveyor. Limited processor (32MHz Z80) and even more limited RAM (32K), but 128 individual dots (35 picolitre per dot)to print in a single vertical slice, then a brief pause, and a second slice, and so on. Most companies get the signal from the photocell, and build a bitmap image to print. But that uses RAM I hadn't got, and takes time on a slow processor. So instead, I got the photocell signal, grabbed the date and time (could be part of the print) and started an timer interrupt. Each time the timer ticked, I generated a new slice and fired it out the jets then set up for the next one.
Basically deferred the processing from a lump at the start to a little bit each dot.
Worked brilliantly on boxes of product, but was just a fraction too slow to cope with high speed lines of individual products - it would reach the point where the processing took longer than the timer interval and the message would stretch across the product.
And I still see units that I designed and coded are working fine even today walking round the supermarket ... I recognise the font I used and it's slight imperfections! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
LOL I never knew it was called that but I race the beam in IoT. Of course now I have a coprocessor to help me.
RGB interface displays use 1 wire for each color bit. Those wires source bits out of RAM while the display scans up and down, left to right. You have to spit the bits at exactly the right time to get the display to show correctly.
I use a little feature in the ESP32 called GDMA to make it possible, but it takes the chasing away from the CPU. Basically you can connect 1 bit to a 1 wire - up to 16 at a time, and point to a memory buffer, and the GDMA processor at a frequency you give it, will read or write data to or from that buffer using those wires.
Aside from that, I've emulated racing the beam several times, building old school emulators, like Nintendo emulators.
Fun times!
Check out my IoT graphics library here:
https://honeythecodewitch/gfx
|
|
|
|
|
Not racing the beam as such, but spotting the beam, yes.
In around 1981 I built myself a UK101 kit computer; 6502 CPU, (originally) 4k memory and RF output to a monochrome television of 32 (originally 16) rows and 64 columns. Complete with full logic diagram. I'd made various mods to the system, but decided it would be cool to be able to "draw" directly on the screen. This in the days before mouse pointers, tablets, touch-screens etc. I knew the image on the CRT was a bright dot racing across the screen and figured if I had a light-sensitive diode, I could trigger a signal in response to the dot passing under it. That signal was connected to an interrupt and the interrupt processing code accessed what was effectively a hardware tick counter, that was synchronised to the clock for the video driver. Based on the value of that tick counter I could tell where the electron beam would be, and therefore I could calculate a character row and column.
So long as there were some pixels in the character, and a little adjustment to the TV brightness controls, it could detect the position of the light-sensitive diode pretty accurately. Fit the diode in the end of a "wand" and, hey presto, I could draw lines on the screen.
As you can see my grasp of it all was a little tenuous, but the excitement and joy when it actually worked was amazing... especially at the total cost of a few pennies and a couple of dozen lines of assembler code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
