#Tag
https://spectra.video/w/qvxsFMhciScC1T2py3eFvB
going live for a bit, working on the text editor that is supposed to ship with the suite of tools with the people's permacomputer model 1.
#permacomputing #retrocomputing #tinybasic #6502 #z80 #livecoding #peertube #retro #emacs #retrogames #texteditor #programming
https://spectra.video/w/qvxsFMhciScC1T2py3eFvB
going live for a bit, working on the text editor that is supposed to ship with the suite of tools with the people's permacomputer model 1.
#permacomputing #retrocomputing #tinybasic #6502 #z80 #livecoding #peertube #retro #emacs #retrogames #texteditor #programming
Keeping track of progress of the Z80 Noveau FPGA-based project. Now with sprites!
Details of the sprite logic in the Z80 Nouveau VDP finite state machine Verilog modules.
This provides an implementation of a TI9118-compatible graphic display.
@ John's Basement
@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.
Keeping track of progress of the Z80 Noveau FPGA-based project. Now with sprites!
Details of the sprite logic in the Z80 Nouveau VDP finite state machine Verilog modules.
This provides an implementation of a TI9118-compatible graphic display.
@ John's Basement
@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.
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
Great #z80/6502 asm development philosophy article I stumbled onto by accident.
Great #z80/6502 asm development philosophy article I stumbled onto by accident.
Does anyone have a favorite portable computer / device based around the 6502 microprocessor?
The #z80 was used in everything from TI graphing calculators to (in modified form) the GameBoy. Where are the 6502 portables? #retrocomputing
I have now written a #z80 machine code monitor for the #MailStation. The command set is very influenced by WozMon, but unlike #Woz I haven't managed to fit it in 256 bytes (yet...)
So now, in the strictest sense of the word, I have a #repl on this thing!
(While there was already a built-in hex editor, it was not suited to interactive use. A reboot was necessary to test changes, and it was restricted to writing dataflash, which has a limited number of write cycles.)
Incongruously for a #z80 powered device, the #MailStation is heavily GUI based. There isn't a putc function, or even a fixed-width font, in the firmware. Instead, a windowing toolkit and a selection of widgets are provided, and loadable apps are expected to be event-driven. Each app supplies a main event handler function responding to incoming signals such as init, draw, and keydown. Apps don't take over the whole system as typical on single tasking retrocomputers. While the Mailstation doesn't do true multitasking, (or even #HP200LX-like switching between paused apps!), the event-driven software architecture is helpful for battery life, as the CPU can spend most of its time halted waiting for interrupts.
I have now written a #z80 machine code monitor for the #MailStation. The command set is very influenced by WozMon, but unlike #Woz I haven't managed to fit it in 256 bytes (yet...)
So now, in the strictest sense of the word, I have a #repl on this thing!
(While there was already a built-in hex editor, it was not suited to interactive use. A reboot was necessary to test changes, and it was restricted to writing dataflash, which has a limited number of write cycles.)
Incongruously for a #z80 powered device, the #MailStation is heavily GUI based. There isn't a putc function, or even a fixed-width font, in the firmware. Instead, a windowing toolkit and a selection of widgets are provided, and loadable apps are expected to be event-driven. Each app supplies a main event handler function responding to incoming signals such as init, draw, and keydown. Apps don't take over the whole system as typical on single tasking retrocomputers. While the Mailstation doesn't do true multitasking, (or even #HP200LX-like switching between paused apps!), the event-driven software architecture is helpful for battery life, as the CPU can spend most of its time halted waiting for interrupts.
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
This is handy for studying ROMs and binary only programs: a Z80 disassembler that tries to identify string data and labels.
@hisdeedsaredust yeah, I hear you. I'm kind of weird in that I keep some way out of date technical books because of what they meant to me at the time. But they take up valuable space, and are basically useless except as mementos.
*** 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
