[HN Gopher] "PET-Globe" Demo
___________________________________________________________________
"PET-Globe" Demo
Author : masswerk
Score : 19 points
Date : 2025-01-08 22:44 UTC (3 days ago)
(HTM) web link (www.masswerk.at)
(TXT) w3m dump (www.masswerk.at)
| memalign wrote:
| Reminds me of:
|
| https://aem1k.com/world/
| rezmason wrote:
| 96x32 pixels? A kindred spirit!
|
| I'm using WebGL to emulate a unique Casio LCD that hue-shifts
| pixels into the right color, and its display is 95x32 and
| typically its bit depth is two. (The hardware is 96x32, I'm
| honestly not sure where the last column went)
|
| https://rezmason.github.io/birefringence-lcd (Epilepsy Warning!
| WIP; arrow keys to change screen image)
|
| Before long I'll want to display more interesting things on it;
| OP, can I try to credit your project and port it to JavaScript
| for my LCD emulator?
| aorist wrote:
| In case anyone else is a fan of these unsual old displays, you
| might enjoy Posy's passionate videos which are a unique
| combination of curiosity, macro/slowmo shots and humor.
| Especially relevant is this one which is about what seems to be
| a very similar (but different sized) red/green/blue Casio
| CSF-7950 LCD: https://www.youtube.com/watch?v=jLew3Dd3IBA
| rezmason wrote:
| That's the one! That and:
| https://www.youtube.com/watch?v=quB60FmzHKQ&t=20s
|
| Thanks for linking, I'll be reaching out to and crediting
| Posy, once I'm closer to complete :D The onscreen graphics I
| currently have were laboriously extracted from the video
| above.
|
| https://github.com/Rezmason/birefringence-
| lcd/blob/main/asse...
|
| See also: https://www.youtube.com/watch?v=COCnckzHHLk&t=154s
|
| And the patent: https://patents.google.com/patent/US5745200A
| masswerk wrote:
| OP here:
|
| Feel free to use/to refer to it. I'm pretty sure, I'm not the
| first one to have come up with something like this. (My part in
| this is really in organizing the data and the related 6502 code
| for rendering, maybe the hot-one encoding for the lower 3 bits
| of the displacement offset to make this suitable for 8-bit
| processing.)
|
| See "Sphere Mapping" by Frederic Goset for further reference on
| compiling a static displacement map to render a spherical
| projection from a cylindrical one:
| http://fredericgoset.ovh/informatique/oldschool/en/spheremap...
|
| BTW, I'm now using 32 x 100 pixels (or rather, data points),
| which doesn't change much, other than adding a few bytes to the
| data stream for the world map (we're just adding 4 columns or
| 16 bytes to this).
| musicale wrote:
| > there is no way we could do this in BASIC
|
| If you had enough memory, a PRINT statement for each frame delta
| might work.
|
| Looking at the user/BASIC manual, it looks like strings can
| contain screen positioning characters as well as visible
| characters.
| masswerk wrote:
| BASIC is about 1000 times slower, so there's no way we could do
| this in realtime. Moreover, as mentioned in the article, the
| original PET 2001 suffers from bus conflicts when the CPU and
| the video circuitry access the video memory at the same time,
| because of slow SRAM, which is just the same speed as the CPU.
| To avoid this, the BASIC used by these earlier models prints
| only during the vertical blanking interval (V-BLANK), when
| video is off. This is only about a quarter of the duty cycle,
| where PRINT can actually happen, slowing this down to a
| fraction of what BASIC could theoretically achieve.
|
| Let's do some nerdy numbers: ;-)
|
| We may try rendering this to static slides and store them as
| strings in DATA statements. At 16 cols and 16 rows, this is 256
| bytes per frame and there are 100 of them (the current map
| width), which makes 25 KB. We'll also need memory for the
| overhead of this as BASIC lines, which is 2 bytes for the line
| number in binary, another two bytes for the link to the
| location of the next line in memory (a 16-bit pointer), 1 for
| the "DATA" token, and a zero-byte as the line delimiter (EOL),
| which makes 6 bytes per BASIC line. And we'll need another two
| bytes for the enclosing quotes per string, and one for a
| separating comma (if we put more then one string in a given
| line).
|
| Assuming we store 3 strings in a line (of max 80 characters),
| this makes a total of 533.3 x (6 + 3 x 18 + 2) = 33,064 bytes
| (or 32.29 KB), the memory requirement to store just the DATA
| lines. - So there's no way to fit this into a machine, which
| maxes out at 32K in its most luxurious memory configuration (or
| 16K for the original PET 2001).
___________________________________________________________________
(page generated 2025-01-11 23:01 UTC)