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

@edsu I jumped on HTML 4 as soon as possible and used to use James Clark’s nsgmls to make sure everything was validated, so I would trip over as few rendering quirks as possible. I also have some #retrocomputing books that will stay with me (some pictured). The ZX Spectrum was my first computer, Foley and Van Dam was comprehensive, writing a #PostScript interpreter on Apollo workstations was my final year project, and I still love the #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 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

alcinnz
alcinnz boosted

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

Paolo Amoroso
Luca Sironi
Your friendly 'net denizen
Paolo Amoroso and 2 others boosted

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

A 22" LCD monitor on a desk, with four rectangular windows with different background and foreground colors. Four windows is not useful for CP/M! But it lets me thoroughly test windowing, and having four working windows, for the four running tasks ("seats" in MP/M parlance). The magic keyboard key that, here, selects active window, will select which task gets the keyboard, allowing you to run four CP/M programs at once.
A 22" LCD monitor on a desk, with four rectangular windows with different background and foreground colors. Four windows is not useful for CP/M! But it lets me thoroughly test windowing, and having four working windows, for the four running tasks ("seats" in MP/M parlance). The magic keyboard key that, here, selects active window, will select which task gets the keyboard, allowing you to run four CP/M programs at once.

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

A 22" LCD monitor on a desk, with four rectangular windows with different background and foreground colors. Four windows is not useful for CP/M! But it lets me thoroughly test windowing, and having four working windows, for the four running tasks ("seats" in MP/M parlance). The magic keyboard key that, here, selects active window, will select which task gets the keyboard, allowing you to run four CP/M programs at once.
A 22" LCD monitor on a desk, with four rectangular windows with different background and foreground colors. Four windows is not useful for CP/M! But it lets me thoroughly test windowing, and having four working windows, for the four running tasks ("seats" in MP/M parlance). The magic keyboard key that, here, selects active window, will select which task gets the keyboard, allowing you to run four CP/M programs at once.
vruz
vruz boosted

Retro Computing Nostalgia meet Open Source Software and Hardware with AgonLight and Neo6502, the incredible evolution of modern Retro computer projects https://olimex.wordpress.com/2025/07/23/retro-computing-nostalgia-meet-open-source-software-and-hardware/ #z80 #w65c02 #retrocomputing #retrogaming #pascal #cpm #forth #basic #cc65

Retro Computing Nostalgia meet Open Source Software and Hardware with AgonLight and Neo6502, the incredible evolution of modern Retro computer projects https://olimex.wordpress.com/2025/07/23/retro-computing-nostalgia-meet-open-source-software-and-hardware/ #z80 #w65c02 #retrocomputing #retrogaming #pascal #cpm #forth #basic #cc65