Autism should not be treated as a single condition
#HackerNews #Autism #Awareness #Autism #Spectrum #Neurodiversity #Mental #Health #Research #Insights
#Tag
Autism should not be treated as a single condition
#HackerNews #Autism #Awareness #Autism #Spectrum #Neurodiversity #Mental #Health #Research #Insights
@raymierussell
You've done some great work handling text! You're right that and'ing and or'ing on display memory is slow.
I have a routine that renders the text offscreen, then copies the buffer to screen using the stack very fast.
Very rough and off the top of my memory:
LD SP, <screen memory>
LD HL, <offscreen buffer>
LD BC, <byte count>
LOOP:
LD DE,(HL)
PUSH DE
INC HL
INC HL
DEC BC
JP NZ, LOOP
So you only AND and OR the head and the tail of the string on screen, and only in the cases that's needed.
Another optimisation is to keep two pointers, one for each of the two characters you have to print next, each pointer pointing to the start of the character bits in the font table. So after fetching pixel bits, you only and and or between registers, and you only EX pointers, also swapping fast.
That being said, a rough consensus of sorts seems to have formed among enthusiasts about the most plausible model that's to be expected:
Internal SD likely holds system / OS / firmware stuff
External SD likely handles games, data, user storage
Internal SD is probably not removable via standard user access
Backing up internal without opening is uncertain / possibly non-trivial
Other conjectures about system updates over WiFI and other work modes have been theorised, but seem to be considered less plausible by most.
#ZXSpectrum #speccy #Spectrum #ZXSpectrumNext #SpectrumNext #retrocomputing
@raymierussell
You've done some great work handling text! You're right that and'ing and or'ing on display memory is slow.
I have a routine that renders the text offscreen, then copies the buffer to screen using the stack very fast.
Very rough and off the top of my memory:
LD SP, <screen memory>
LD HL, <offscreen buffer>
LD BC, <byte count>
LOOP:
LD DE,(HL)
PUSH DE
INC HL
INC HL
DEC BC
JP NZ, LOOP
So you only AND and OR the head and the tail of the string on screen, and only in the cases that's needed.
Another optimisation is to keep two pointers, one for each of the two characters you have to print next, each pointer pointing to the start of the character bits in the font table. So after fetching pixel bits, you only and and or between registers, and you only EX pointers, also swapping fast.
Font 6x6, that yields a matrix of 42 columns and 32 rows on the Spectrum's 256x192 resolution.
On a tiny LCD screen I have of 240x135, I should get 40 columns by 22 rows. That's compatible enough textwise.
That being said, a rough consensus of sorts seems to have formed among enthusiasts about the most plausible model that's to be expected:
Internal SD likely holds system / OS / firmware stuff
External SD likely handles games, data, user storage
Internal SD is probably not removable via standard user access
Backing up internal without opening is uncertain / possibly non-trivial
Other conjectures about system updates over WiFI and other work modes have been theorised, but seem to be considered less plausible by most.
#ZXSpectrum #speccy #Spectrum #ZXSpectrumNext #SpectrumNext #retrocomputing
Even though it's a one-off, unofficial, and artisanally built, at least one ZX Spectrum Next laptop does exist.
https://www.dorchester3d.com/printing/blog/2020/11/zx-spectrum-next-laptop-version-2
I think this is a very good idea.
#ZXSpectrum #Speccy #Spectrum #retrocomputing #SpectrumNext #retrocomputing #ZXSpectrumNext
I don't have survivalist inclinations, but I entertained the thought for a moment. Consider it sci-fi.
What if all semiconductor and computer production stopped today, indefinitely?
#permacomputing #retrocomputing #ZXSpectrum #Speccy #Spectrum #z80
The ZX Spectrum Analyser is a powerful tool that allows ZX Spectrum games to be analysed, disassembled, and annotated, to discover how they work.
https://colourclash.co.uk/spectrum-analyser/
It's a seriously cool tool with lots of ideas to borrow from, I also see many ideas I had over the years have already been implemented, so I take that as validation, and it helps me identify what works and what doesn't without even having to write any code.
Docs (PDF)
https://colourclash.co.uk/SpectrumAnalyserInstructions.pdf
Alpha download:
https://colourclash.co.uk/SpectrumAnalyser.zip
Video guide:
https://www.youtube.com/watch?v=QY6pZehr8uc
As I understand it, all "stretch goals" have been unlocked, including the ZX81 core, the Amstrad CPC core, Doomdarks, and Monty Mole.
Olifiers corrected a previous message he sent where he had said we'd be getting a CPC 464 core. That was incorrect, it's a CPC 6128, "with good prospects of becoming more" in Henrique's own words.
*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***
This test loads the ZX Spectrum 128 ROMs (0 and 1) and run that machine's initialisation process. Then it shows a statistical analysis of the instruction coverage that's been executed during rom initialisation. (total percentage of different opcodes executed for each instruction group)
The second big test implements traps as barebones CP/M shims, loads ZEXDOC.COM and runs its extensive stress test (this can be long).
Work is ongoing to support ZEXALL.COM as well, an even more stringent version of zexdoc that also tests undocumented registers and quirks of the Z80, one of the hardest tests known. This will be next, after I'm certain that this passes all ZEXDOC tests without a hitch. So far so good!
#zen80 #emulator#ZXSpectrum#Speccy#Spectrum #golang #foss #z80
*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***
This test loads the ZX Spectrum 128 ROMs (0 and 1) and run that machine's initialisation process. Then it shows a statistical analysis of the instruction coverage that's been executed during rom initialisation. (total percentage of different opcodes executed for each instruction group)
The second big test implements traps as barebones CP/M shims, loads ZEXDOC.COM and runs its extensive stress test (this can be long).
Work is ongoing to support ZEXALL.COM as well, an even more stringent version of zexdoc that also tests undocumented registers and quirks of the Z80, one of the hardest tests known. This will be next, after I'm certain that this passes all ZEXDOC tests without a hitch. So far so good!
#zen80 #emulator#ZXSpectrum#Speccy#Spectrum #golang #foss #z80
A space for Bonfire maintainers and contributors to communicate