Wednesday, September 23
Daily News Stuff 22 September 2020
UghBrowsers Proxy Servers Edition
Disclaimer: Fucking Elasticsearch. 28,000 records total. 4.5GHz CPU. 128GB RAM. Seven second search times.
Ugh
Tech News
- There's another update out for Chrome already. Does it fix anything? It does not.
Bah. I'll test a workaround for this mess after I post the news stuff.
Update: The problem was ENTIRELY DIFFERENT TO WHAT I THOUGHT IT WAS AND NOT A BROWSER ISSUE AT ALL.
Also, fixed.
Basically, Caddy (the proxy server we use) failed to automatically renew some of our SSL certificates. Don't know why exactly, except that it's been running for several months without a restart.
We've been running it for a couple of years at my day job without this happening, but we push config changes every couple of weeks so it never runs that long without a reload.
Common JavaScript files for mee.nu live on a shared domain and are always loaded over HTTPS. That stopped working a couple of days ago. I'm kind of impressed by how few things broke.
- Arm has announced two new server cores. (AnandTech)
The N2 - codename Perseus - offers a 40% IPC improvement over the N1 core that Amazon is using in its Graviton 2 server platform.
That's quite a lot. That performance will also be coming to the A79 or whatever they choose to call their next mobile core. N2 is due out next year.
The V1 on the other hand is their new performance core. Yes, the 40% IPC improvement over their current best offering is now their mid-range core.
V1 - codename Zeus - promises 50% better IPC than N1 at the same clock speed, plus better clock speeds, and double the floating-point performance of the N2. Arm estimate overall V1 will be around 20% faster than N2. And it's available to license today.
This is the core used by the SiPearl Rhea that I mentioned previously.
The V1 is a maximum-performance damn-the-power-consumption design and will not be coming to mobile devices, but it's what Arm needs if they are to compete with AMD in the server space.
Serve the Home has more.
- Microsoft is buying Bethesda. (Thurrott.com)
Makers of the bad Fallout games.
It's a shame Microsoft wasn't in the mood when Bioware was on the market.
- Planet K2-315b has a surface temperature of around 180C (350C) and is "likely not habitable". (CNet)
It also orbits its star, EPIC 249631677, in just 3.14 days.
EPIC 249631677 - let's call it Ted - is 57 parsecs from Earth and not exactly suitable for daytrips anyway.
- Memory price trends, 1957-2020. (JCM)
Interesting to note that early on, vacuum tubes were cheaper than transistors. I'm guessing though that even in the 50s transistors were a lot more reliable.
- Okay, since I have that weird comment thing fixed, time to think about game programming on the Imagine.
Let's take Civilisation - not the popular game, that's spelled with a Z.
The Pangea tileset that inspired this is 16x16, perfect for the Imagine's tilemap mode. Load the tiles into RAM once, create a map - a 100x80 world map is just 8k - use sprites for the units, and we're good to go.
Except... Not so fast. Look at this example.
We don't just have the background tiles. The background tiles are overlaid by terrain and vegetation, rivers, roads, and railroads. Rivers over terrain can be overlaid by road and railroad bridges. Resources and resource icons overlay terrain and vegetation. Water is animated. And over all that there's a rather literal fog of war for unexplored territory.
Handling all that would require a separate 32-colour full-resolution overlay playfield, and the original Imagine 1000 can't quite manage that; it runs out of clock cycles to access everything.
So instead it has to be done in pixel mode, and that eats 64k of RAM on top of all the tiles and sprites that need to be loaded.
There's a reason Civilization - the one with the Z - didn't come out in 1983.
Looking at the tileset, all the animations for all the units combined are only 40k. But with 64k assigned to the pixel map, we only have 192k for all the tiles, sprites, code, and data combined. In virtual 1983, 40k is a lot.
This is where we say things like "combat animations require the optional 128k RAM expansion cartridge ($89.95)".
- Ram Packs for Everyone!
Figured out a two-chip solution that makes the Imagine about eleventeen times better.
So, the design has three main chips: The CPU, the DSP, which we're going to completely ignore, and the video controller.
There's 128k of system RAM - called shared RAM for reasons we'll get to in a moment - and 128k of video RAM.
The video controller has two full buses, and can directly access both video RAM and system RAM. It was ostensibly designed as a standalone controller for graphics terminals, needing just a suitable UART and ROMs for the code and fonts; one bus for video data and the other bus for everything else.
It can also use both memory buses for video data. This lets the Imagine display two playfields at 480x270 in 32 colours, at the cost of absolutely squashing CPU performance.
While scanning through 1980s Toshiba component databooks looking for memory timing information, I noted in passing that there was a standard 74LS part for a 10-bit three-state bus transceiver.* Caught my attention because I was looking up stuff for a fantasy 10-bit computer.
Now, what happens if we take two of those chips, and put them on the data and address buses, so that on one side is the video controller and the two built-in memory banks, and on the other side is everything else?
Well, if you don't have a RAM cartridge, not much. The CPU is now free to access ROM on cycles when the video controller is accessing shared RAM, but that's a minor win because the built-in Basic is a compiler anyway.
If you do have a RAM cartridge, though, that means the CPU can run at full speed even while the video controller is using all the bandwidth of both internal memory buses. Instead of just giving you 128k of system RAM, it doubles the graphics capabilities of the system. We can even do a tweak and split sprites across the buses so that they can each be 20 pixels wide instead of just 10.
With a later 256k or 512k RAM cartridge things get even better.
So yes, those two chips go in.
* The original part was a 74LS861, I think; that's the modern equivalent.
Apropos of Nothing
Disclaimer: Fucking Elasticsearch. 28,000 records total. 4.5GHz CPU. 128GB RAM. Seven second search times.
Posted by: Pixy Misa at
12:08 AM
| Comments (6)
| Add Comment
| Trackbacks (Suck)
Post contains 1108 words, total size 9 kb.
1
Not Google's fault, this time. The proxy server failed to renew the Let's Encrypt certificate for the domain mee.nu loads its Javascript from.
It's impressive though how well things kept working with the critical Javascript files missing.
It's impressive though how well things kept working with the critical Javascript files missing.
Posted by: Pixy Misa at Wednesday, September 23 2020 12:26 AM (PiXy!)
2
"Don't know why exactly, except that it's been running for several months without a restart."
Remember when bragging about how long your computer could stay online without rebooting was a good thing?
Remember when bragging about how long your computer could stay online without rebooting was a good thing?
Posted by: Rick C at Wednesday, September 23 2020 01:09 AM (eqaFC)
3
I sent you an email about an unrelated technical issue.
Posted by: Physics Geek at Wednesday, September 23 2020 02:07 AM (huQJB)
4
Hey, we've had Caddy cert-renewal problems too! If you figure them out, it would be great to hear how.
Posted by: Jay at Wednesday, September 23 2020 02:11 AM (mrlXS)
5
Physics Geek - will check on that.
Jay - I'm still runny Caddy 1, so there's absolutely no support on it now.
Jay - I'm still runny Caddy 1, so there's absolutely no support on it now.
Posted by: Pixy Misa at Wednesday, September 23 2020 02:38 AM (PiXy!)
6
Glad that issue got fixed.
Posted by: Mauser at Wednesday, September 23 2020 02:24 PM (Ix1l6)
58kb generated in CPU 0.0164, elapsed 0.1088 seconds.
58 queries taking 0.0975 seconds, 353 records returned.
Powered by Minx 1.1.6c-pink.
58 queries taking 0.0975 seconds, 353 records returned.
Powered by Minx 1.1.6c-pink.