Looking for someone who can do PHP / JS

Peter wrote:

You can have a 20 core 2GHz CPU with 16GB RAM and it is still slower than what could have been achieved on a 4MHz Z80 40 years ago

I profoundly disagree. I have done a lot with the Z80, including an awful lot of asm and C.

You can make something pretty snappy on a Z80 if you hand-code it in assembler, or have a decent C compiler (the Z88DK C compiler is actually pretty good – the code performs well enough to write videogames with it). But it’ll be hand coded and ready compiled. It’ll also be low resolution and low bit depth.

For example, for your map, you’re asking your computer to just-in-time compile or interpret HTML5/CSS (which has become a de-facto user interface definition language), interpret or JIT compile some Javascript, and do other things like decompress, all while writing to a particular viewport on the display at 24 bits per pixel, and at least 25 frames per second for anything you can move around.

A 3.5 MHz Z80 can just about manage to do 25 frames per second on a 256×192 screen at just one bit per pixel. The memory bandwidth of a Z80 is also pretty low, simple serial protocols like I2C and SPI are generally much faster than the Z80’s parallel memory bandwidth. The fastest a Z80 can fill memory is about 364 kilobits per second (at 4MHz) using unrolled push instructions (if you need to copy memory, the throughput ends up being a bit less than half of this) which puts an upper limit on how quickly you can paint a memory mapped screen (and then on most Z80 systems, there’s memory contention on top of that as the video chip and CPU can’t access the processor at the same time).

Sure, a browser based interface is a lot less efficient and takes many more instructions to display. But on the other hand, what takes me a day to do as a browser-based UI would take around two or three weeks to do even in C on a Z80 based system, and the browser display is at 24 bits per pixel, on a full HD display, with full network access, and really it doesn’t need a 20 core CPU to run (a reasonably written HTML5/JS webpage renders quickly and is responsive on an old iPad or on a Raspberry Pi for instance). The browser based system will also run on nearly anything.

Peter wrote:

Why Youtube does this mixed-case thing I don’t know but presumably it works for them because nobody actually reads those URLs.

That part of the URL is the internal video number, which is internally in the system probably just a 64 bit integer. The string you see is probably just an encoding of that URL in something resembling (but not exactly) base64. Using both lower and upper case allows the encoding of the number to be a shorter string, and makes the URL shorter. With only lower case, you’d do something like base32, and you would need 13 characters instead of 11 :)

There is a very complete explanation of this at https://webapps.stackexchange.com/a/101153

It depends how you move it out, and whether you configured the camera capture to “high efficiency” or “most compatible”.

With “high efficiency”, the local storage is HEIC. I you use “share” then select an app (that does not explicitly advertise HEIC compatibility?), you get JPEG. If you use “save to files” you get HEIC.

Peter wrote:

Is anyone here familiar with JS to upload files using a browser?

I’ve done it once… AFAIU it is an HTML 5 feature that should work the same on different browsers. The tricky bit is that upload is asynchronous.

Calling the JS function readfile will open a dialog box and read a text file selected by the user.

I’m sure more experienced JS developers will cringe. :-)

<input type="file" id="infile" accept="text/*" style="display:none" onchange="readfile2()">

<script>
function readfile() {
  document.getElementById("infile").click();
};

function readfile2() {
  document.getElementById("infile").value = "";
  var file = document.getElementById("infile").files[0];
  if (file) {
      var reader = new FileReader();
      reader.onload = function (evt) {
         // Get here when upload complete. The contents of the file is in evt.target.result
      };
      reader.onerror = function (evt) {
        alert("An error ocurred reading the file");
      };
      reader.readAsText(file, "UTF-8");
   };
};
</script>