#v80 — Public Fediverse posts

@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

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

#z80 bros, your opinion on my z80 assembler's syntax please; #v80 doesn't use standard Zilog syntax to make it significantly simpler (and faster) to parse, but if I want to create a Notepad++ language definition I don't have the flexibility there to differentiate registers (`add.b`) and keywords (`.b ...`)

Please have a look at v80's syntax (https://github.com/Kroc/v80/blob/main/README.md) and tell me what you think. Could keywords start with something other than "."? (which could be reserved for private labels in the future). Should constants be ALL_CAPS instead of using a `#` sigil? I could allow separation of instructions and registers with spaces by letting the parser read 1 space in the instruction name as being any-number of spaces but using dots means multiple instructions on one line are easier to read and there's less typing and formatting overall

#asm #retrocomputing #programming

I AM ASKING YOU TO STOP USING PC-ONLY COMPILERS TO MAKE 8-BIT SOFTWARE. IF YOU DO THIS YOU ARE BAD AND YOU SHOULD FEEL BAD (/s). But there are no easy solutions right now and I’m trying to get the ball rolling by bootstrapping an assembler. Right now #v80 requires a C89 assembler, WLA-DX, so I’m a hypocrite but you have to use the system to destroy the system and v80 will assemble itself soon enough

Guys, that's a #Z80 #cpm binary executing in the terminal on the right there. The incredible NTVCM is a program that runs your CP/M binaries right in the terminal like any other *nix program; https://github.com/davidly/ntvcm

It is necessary to grasp the full import of this -- software for 8-bit systems can be assembled on PC as part of any other build-script, makefile, GitHub Action, Docker, or whatever, but still retain the ability to build the software ON REAL 8-BIT HARDWARE.

This is my Z80 assembler #v80 (https://github.com/Kroc/v80), written in Z80, running in #VSCode producing a test binary. In the future it'll assemble itself, and then the possibilities are limitless

#asm #retrocomputing #retroprogramming

Printing numbers in decimal is a nightmare on any CPU, especially 8-bit ones. In some places I need leading spaces, and others not, but I didn't want to write two version of the same decimal routine to handle this logic. I came up with this rather nifty frontispiece that can print the required leading spaces without actually calculating the decimal number ahead of time:

#z80 #v80 #asm #retroprogramming

What if the output of my #z80 assembler whilst assembling was... a symbol file?

Now the stdout of assembling a program produces the symbol file of that program, that you could include in another program, giving at least some semblance of linking.

I'm doing this to avoid command-line parameters. #v80 has two. The input file name, and optional output file name. That's all, and all there ever will be.

But what if you want to pre-define symbols from the command line when assembling?

You create a file with the symbols you want and include the main source file, e.g.

```
#debug 1 ; enable debugging
.i "source.v80"
```

Now you have a finite number of configurations, not an infinite possible number of command-lines parameters.

#asm #retroprogramming #cpm

Despite this #z80 code doing a neat math trick I'm going to drop it here because I don't think I'll be using it after all :(

Here, we're parsing an expression; `@paren` is jumped to with the ASCII code for either "(" or ")" in A. We twiddle the bits and +/-1 to a counter based on the parenthesis used but without any branches!

#v80 #asm #retroprogramming

I wanted to share this bit of #z80 code because I love how the error-check in the fist line causes an instruction to be skipped on the third. There are two separate entry points `@const` and `@hex` depending on data type, but both need to share a common tail / epilogue (`@num`). The hex type is wedged between the two and becomes invisible to the first due to the expected return state of the constant check (must be non-zero)

#v80 #asm #retroprogramming

But Kroc, #v80 doesn’t even have a linker or macros, it can’t replace Z88DK &c.!

v80 has a fixed level of complexity. Its goals are portability and cross-assembly; one day it will be Finished™️ rather than expanding forever. v80 is what you use to write a better assembler; macros, linker and all; or a C-compiler, whilst maintaining portability and the ability to bootstrap itself on new platforms.

Why not just use existing CP/M assemblers &| C-compilers from the past, eh, Kroc??

Because #v80 is more than that. Only 3KB is actual code. The other 3.7.KB is a static binary tree to map #z80 CPU mnemonics to opcodes. What if we replaced this static table with one for... 6502 instructions?

Now we can assemble 6502 code on a Z80. Why would you even want to do that? Because you could use v80 to assemble a 6502 port of itself (v65?), even assembling z80 code on a 6502... and now you can bootstrap any code on any system using just 8-bit code runnable on 8-bit hardware using the same assembler syntax [but different CPU mnemonics], all whilst never giving up PC+GitHub but making it possible for anyone to develop 100% on retro hardware (if they choose) that can't hope to run Git and LLVM. Imagine being _productive_ on 8-bit hardware!

If a computer can’t compile and deploy its own software then it’s an appliance and not a general purpose computer.

I see too much 8-bit software on GitHub require a PC tool chain (and God-forbid, LLVM) and this is bad because the 8-bit system can no longer speak for itself; the software may as well be proprietary for all that can be modified on the target.

8-Bit software *must* be buildable on 8-bit hardware… but nobody should be required to abandon their PC or their GitHub workflow.

#v80 is the first, tiny step in solving this: A portable assembler and syntax that can assemble software on original hardware, but also on PC (and GitHub and Docker, or whatever) — currently via #RunCPM that runs #z80 #cpm executables in your terminal. (Please could someone make a #C version of v80 so that extra step is removed)

Think about it — software written for 8-bit systems that can be assembled as easily on PC as current tool chains but doesn’t exclude doing so on real hardware too!

A working #Z80 assembler in 6.7KB. I'm not release-ready yet, but I'm getting there. The source code is extremely well commented so if you want to learn Z80 assembly and/or CP/M, start reading: https://github.com/Kroc/v80

#v80 #asm #cpm #amstrad #pcw

Just checking my #z80 assembler would run on real hardware...

You won't find better commented, tighter, assembly code than this. #v80 has been meticulously crafted with every routine sweated over for compactness, simplicity and elegance with a view to understandability.

https://github.com/Kroc/v80

#amstrad #pcw #cpm #retrocomputing #retroprogramming