Diagnostica di Matteo (Matteo & Team): Skidata

Skidata: Errore V80 - Internal Clock Drift - Diagnosi e Soluzioni

#Skidata #V80:InternalClockDrift

🔍 Rapporto Completo: https://www.soscassa.org/skidata/article/skidata-errore-v80-internal-clock-drift

@haitchfive Hard to say as I am developing a minimalist Z80 assembler in Z80 (#v80), I’m used to avoiding luxury, but of all the assemblers I’ve used (about a dozen) none have handled banking windows well

Oh great, NOW this gets some attention right as I’m ripping out the custom mnemonics for standard ones :P Too much for users to mind-map on top of learning #eZ80 when I add it. I will say though that even if you don’t use #v80, the source code is the most heavily commented and described assembly you will likely ever see. If you want to know how to write a real CP/M and/or #Z80 application, look no further.

#retrocomputing #retrodev

Attempting a rewrite of my 8-bit multi-platform, multi-ISA, assembler's instruction parser. #v80 uses a static tree for mapping instructions into opcodes (2nd image) which is very fast and efficient but hairy to write.

The new approach (1st image), uses an alphabetical list of instructions with a byte to state how many chars of the previous entry are re-used since alphabetically, the left-most chars repeat the most.

There's no guarantee this will even save space (#Z80 ISA is currently 4KB, #MOS6502 is about 1.7KB) and it will likely be slower as more lines will need to be skipped vs. a char-by-char branching approach, but it may help for very large ISAs, the size of which can balloon drastically with lots of shared prefixes, something I'm worried about with adding #eZ80 support. The alternative is adding 'macro' characters for shared-prefixes, but that bloats the native code that needs to be ported between architectures.

#asm #retrocomputing

#v80 is uniquely architected as an assembler in that ISAs are easily swapped and ported. A static data table maps instructions to opcodes which can be re-used as-is on other architectures. Less than 128 bytes of code are unique to supporting the #Z80 ISA, just 20 bytes for #MOS6502

Is assembling #MOS6502 code on #Z80 considered sacrilege, or does that only apply when it's the other way around? #v80 #programming #retrocomputing

I don't know how many of you out there regularly write both #Z80 and #MOS6502 and have to juggle the two different syntaxes; my multi-platform, multi-ISA assembler #v80 uses a custom syntax designed for parsing speed and simplicity, and in some way unifies instruction syntax between Zilog & MOS ISAs.

v80’s syntax, for example uses "*" for a memory dereference, so that `ld.HL* $nnnn` = Zilog `ld HL, [$nnnn]` (v80 can use optional brackets for clearer intent here) and because instructions can't be split between parameters, `ld*$.HL $nnnn` is used for `ld [$nnnn], HL`.

For 6502 syntax I'm wondering what the best choice is, either `adc*$.x $nnnn` for MOS `adc $nnnn, x` or should I go with `adc.x* $nnnn` for something simpler but not as consistent with Z80 syntax?

I feel like a madman -- my #z80 assembler, #v80, assembles itself! This is it doing so on an #Amstrad #PCW emulator, a #z80 CP/M machine from 1985. It's not optimised for speed on original hardware -- over 50% of the runtime will be just echoing text (thanks, CP/M) and I'm surprised by the amount of heap data needed in the end, but we are talking 335 KB of source code (8KB binary), and I can look into that

https://github.com/kroc/v80

#asm #retrocomputing

#v80 is exactly the kind of assembler I was looking for only a year ago and now it exists and that's wonderful! https://github.com/Kroc/v80

Unless federation isn't working on my instance, not a single person other than me has tooted about #v80 which is kind of sad :(

#v80 v0.1.3 released! https://codeberg.org/Kroc/v80/releases/tag/v0.1.3

- Binary (`%`), *decimal*, and character (`'`) literals
- Local labels (`_`)
- Fill keyword (`.f`)

v80 should now feel a lot closer to most other #z80 assemblers. Syntax highlighting is available in #vscode

#asm #retrocomputing

I'm adding local labels to #v80, should I change the label syntax?

There is now a #v80 #vscode extension: https://marketplace.visualstudio.com/items?itemName=KrocCamen.vscode-v80

#v80 is released! I spent six months writing a #z80 assembler... in z80! https://codeberg.org/Kroc/v80

Why? Because I see too much 8-bit software on GitHub that requires a PC toolchain to build -- if a computer can't produce and deploy its own software then it's not a computer, it's an appliance!

These 8-bit machines should be *used*. What joy is there in retro or modern 8-bit hardware if you sit at your PC developing all day and deploying to it like so much throw-away web-scale infrastructure?

But nobody should give up PC-based development either, so I made v80 runnable on PC too, allowing for build automation but never removing the ability to reproduce the software on real 8-bit hardware.

Please, if your 8-bit software project can't be built on an 8-bit system, consider what you can do to change that. You don't have to use v80, but the idea should stick with you. Today's Windows XP is tomorrow's Windows 10. Your build system won't stop being a moving target you can't control.

I am having a very, very bad mental-health day and I don't know if I'll be able to put together a blog post for #v80 even though I worked on it so hard for six months. I don't know how to sum up why I'm even doing this and I don't believe my message is going to carry anywhere. I know that we must reevaluate dependence on PC tools (themselves bound to an endlessly moving target) for 8-bit software, but you can't magically convince others of that.

#v80 is functionally complete. Release will be coming this week. For Windows, everything is already in the repo, including binaries to build it, but I just need to put together a readme.txt tailored for what a user would need when using v80 to develop #z80 software.

335KB of heavily commented assembly code produces an 8 KB binary. I wrote it from scratch; it took six months. https://github.com/Kroc/v80

#asm #programming #retrocomputers

@gvv My terminology here is likely entirely wrong; by binary, I mean "not code", which how most other assemblers parse Z80's mass of complex instructions. The tree is defined here: https://github.com/Kroc/v80/blob/main/src/z80.wla and the instruction parser that walks it is here: https://github.com/Kroc/v80/blob/main/src/asm.wla#L994-L1119

#v80 minimises #z80 specific code to just 123 bytes :)

Implemented conditionals in 94 bytes of code :)

#v80 #z80 #asm #programming

90% done with my #z80 assembler, #v80. The last feature is conditionals (i.e. conditional assembly if-statements) and finish up the read me. Supporting all z80 opcodes was a slog but it's still less than 4KB of code + a 4KB static binary tree that routes instructions to opcodes