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

#ZXSpectrum#Spectrum#Speccy #retrocomputing #z80

This is handy for studying ROMs and binary only programs: a Z80 disassembler that tries to identify string data and labels.

https://github.com/cormacj/z80-smart-disassembler

#z80 #disassembler #assembly

zen80 update: improved tests

*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***

1. 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)

2. 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

zen80 update: improved tests

*** Apart from the already substantial unit tests, we now have two additional and rather stringent tests:***

1. 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)

2. 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

zen80 emulator UPDATE:

Published a detailed implementation status report and instruction set coverage for our Z80 emulator in Go.

https://github.com/ha1tch/zen80/blob/main/COVERAGE.md

All documented Z80 instructions work correctly. Most undocumented features implemented, with some known gaps: IXH/IXL register access, simplified I/O flags, and a few edge cases in block instructions.

The emulator runs most Z80 software perfectly - it's only software relying on obscure undocumented behaviours that might have issues.
Full instruction-by-instruction breakdown now in the repo, with every opcode mapped to its implementation function and realistic status markers.

#z80 #emulation #retrocomputing #golang #zen80

zen80 is a simple Z80 emulator written in Go.

https://github.com/ha1tch/zen80

It's a preview version and it still doesn't pass all the tests, but it's starting to show some promise.

This is not a ZX Spectrum emulator, this is Z80 only (although some source examples show how to use zen80 to implement a running system).

The older hardcoded Spectrum emulator that has optimised screen display will be frankensteined with open heart surgery once I have the new zen80 ready and passing all the tests.

#foss #z80 #retrocomputing

zen80 is a simple Z80 emulator written in Go.

https://github.com/ha1tch/zen80

It's a preview version and it still doesn't pass all the tests, but it's starting to show some promise.

This is not a ZX Spectrum emulator, this is Z80 only (although some source examples show how to use zen80 to implement a running system).

The older hardcoded Spectrum emulator that has optimised screen display will be frankensteined with open heart surgery once I have the new zen80 ready and passing all the tests.

#foss #z80 #retrocomputing

Wee! I wrote a window manager for MP/M, four windows in the screen, dynamically resizeable, while program(s) are running.

Windows are virtually 24x80 "Heath H19" compatible, up to 30 x 90, so cursor ("curses") format windows shrunk to smallest visible, if dragged full size, draw the off-screen portions. Programs can be writing to the screen while resizing, the "VGA device" does the work.

The bottom line of each command line interpreter, I call the "hotspot", is always visible in a window; portions of the window larger than the box are virtually present, just not displayed.

The Z80 running MP/M or CP/M sees the screen as IO ports; one to write data to, one to specify the window. Magic keyboard keys (Fkeys) switch windows (MP/M: assigns keyboard to task window), arrow keys drag the "cursor" to resize all four at once, another key "maximizes" current screen (make largest; make 24x80; make tiny).

Lol, the cursor decided to not display for the video, there' still bugs to shake out etc.

You can resize the VGA display (480x640 to 1024x768) with program(s) running, and everything does exactly what you would expect. Can't do that with Xorg! Not that that's useful, lol, but the window buffering came out super clean.

This is event driven/task loop programming taken all the way; none of this is interrupt driven, it's all non-blocking task loops. Average task loop time (running through all dozen main tasks) is 5 - 10 uS, worst case 55 or so mS (large screen scrolling). I may unwind scrolling and drop that to a millisec or so but there's no downside I can determine.

MP/M will have four tasks, four "seats". on window per, and 48K per user/task, four running at once (and only four). MP/M performance will be very nice. Got the XIOS written, soon to test it...

#CP/M #cpm #mpm#MP/M #retrocomputing #z80