[fasmg] SDK for KR580VM80A (Intel 8080) and Apogee BK-01

Index > Non-x86 architectures > [fasmg] SDK for KR580VM80A (Intel 8080) and Apogee BK-01

Author

Thread

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 04 May 2026, 20:30

Hi all,

I've been working on an emulator for the Apogee BK-01, a Soviet home computer based on the KR580VM80A (100% Intel 8080 clone). I used to write programs for it with sjasmplus, but eventually decided to switch to fasmg, which led me to put together a small SDK.

It consists of two files: kr580vm80a.inc, which implements the full KR580VM80A instruction set as CALM instructions, and apogee.inc, which provides an rka format macro, a str macro for encoding strings in the Apogee BK-01 charset, and hardware definitions covering the memory map, I/O registers, monitor ROM entry points, keyboard and display codes, etc.

It's been great working with fasmg, the macro system is remarkably flexible, and I plan to keep learning and maintaining this. Since there are plenty of more experienced people here, I'd be glad if anyone feels like having a look and pointing out anything that could be done more cleanly.

A couple of minor things I'm uncertain about: the rka format is currently implemented as a regular macro, and I did consider rewriting it with CALM, but given that Apogee programs are tiny, it might just be optimisation for its own sake. The str macro was originally called dba with "a" for Apogee, but I renamed it because the suffix felt somewhat misleading. That said, str is arguably too generic, if anyone has thoughts on a better name, I'd be curious to hear them. Not critical for practical use, but it's been nagging at me semantically.

https://github.com/coignard/apogee-sdk

René Coignard

04 May 2026, 20:30

bitRAKE

Joined: 21 Jul 2003
Posts: 4467
Location: vpcmpistri

bitRAKE 05 May 2026, 00:23

coignard wrote:

optimization for its own sake

Code:

iterate <name,  opcode>,\
        RLC,    00000111b,\
        RRC,    00001111b,\
        RAL,    00010111b,\
        RAR,    00011111b,\
        CMA,    00101111b,\
        CMC,    00111111b,\
        STC,    00110111b,\
        DAA,    00100111b,\
        NOP,    00000000b,\
        HLT,    01110110b,\
        EI,     11111011b,\
        DI,     11110011b,\
        XCHG,   11101011b,\
        XTHL,   11100011b,\
        SPHL,   11111001b,\
        PCHL,   11101001b,\
        RET,    11001001b,\
        RNZ,    11000000b,\
        RZ,     11001000b,\
        RNC,    11010000b,\
        RC,     11011000b,\
        RPO,    11100000b,\
        RPE,    11101000b,\
        RP,     11110000b,\
        RM,     11111000b

        calminstruction name?
                emit 1, opcode
        end calminstruction
end iterate

... this form is seen throughout x86-2.inc, and I kind of prefer having the implementation and instruction table in one place. Yet, this is just a style - nothing wrong with your linearized implementation. It would collapse most of the macro nesting in this case, and remove the abstractions from the symbol-space (i.e. make_noarg).

Do you intend:

Code:

struc str? args&
    label . : byte
    db args ; not "str args"?
end struc

... to have the alternate encoding?

_________________
¯\(°_o)/¯ AI may [not] have aided with the above reply.

05 May 2026, 00:23

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 05:59

Hi.

bitRAKE wrote:

Do you intend:
Code:
struc str? args&
    label . : byte
    db args ; not "str args"?
end struc    
... to have the alternate encoding?

Yes, it should indeed be str rather than db there, I'm surprised I forgot to update that part of the code. Fixed. Thanks for pointing that out.

Regarding iterate: I think it will genuinely be more readable than what I currently have. Many thanks for the suggestion. I'll sort that out a bit later and move away from the make_ macros.

05 May 2026, 05:59

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 08:15

Applied it, looks much cleaner now. Thank you. Ended up not using iterate for LXI since it would be the only entry in the table, so it sits alongside MOV, MVI and RST as a standalone calminstruction instead.

Also moved DS out of kr580vm80a.inc into a new compat.inc.

René Coignard

05 May 2026, 08:15

bitRAKE

Joined: 21 Jul 2003
Posts: 4467
Location: vpcmpistri

bitRAKE 05 May 2026, 08:28

I can't stress reading through x86-2.inc enough - well thought out patterns.

I noticed some VT commands in the source - maybe, if that is very common, your string support could be named VT?? Could even extend it beyond strings to process inline commands and control signals - a small DSL to ease use.

05 May 2026, 08:28

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 08:54

bitRAKE wrote:

I can't stress reading through x86-2.inc enough - well thought out patterns.

Yes, I went through that file after your initial message, it should be very useful going forward. Thank you.

bitRAKE wrote:

I noticed some VT commands in the source - maybe, if that is very common, your string support could be named VT?? Could even extend it beyond strings to process inline commands and control signals - a small DSL to ease use.

I might be misunderstanding you, but str has nothing to do with the VT57 DMA controller. What do you mean by VT in this context? The macro idea itself is interesting though, and I have been thinking about it. apogee.inc is going to see a lot of rework anyway since I am currently going through the original Apogee BK-01 documentation and its micron assembler, which I managed to find in good quality, so I think at some point I will get to that too. Not all at once though :-)

René Coignard

05 May 2026, 08:54

bitRAKE

Joined: 21 Jul 2003
Posts: 4467
Location: vpcmpistri

bitRAKE 05 May 2026, 10:27

Oh, I was thinking virtual terminal commands for VT - something completely different.

Many assembly programmers use a prefix of "_" on static string resources - which lead to me using "_A" and "_W" for different types of strings. Perhaps something like that would align with your work or existing syntax.

05 May 2026, 10:27

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 16:01

One more thing I have been thinking about is undocumented behaviour, specifically MOV M, M, whose opcode happens to coincide with HLT. In practice it is almost certainly a typo, and it could make for a frustrating debugging session. I considered adding a guard along the lines of something like

Code:

check d <> 6 | s <> 6
jno   error

so that attempting to assemble it would produce a custom incorrect argument error. I have not applied this yet, though, partly because I am not fully satisfied with the De Morgan form, it feels like there should be a more readable way.

René Coignard

05 May 2026, 16:01

bitRAKE

Joined: 21 Jul 2003
Posts: 4467
Location: vpcmpistri

bitRAKE 05 May 2026, 19:12

Use LOAD to check the byte post EMIT?

05 May 2026, 19:12

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 19:32

Checking the emitted byte against 76h was my first instinct too, but I am not sure it is actually an improvement. It is just a magic constant with no obvious origin, and anyone reading the macro later would have to work backwards to understand why that particular value is forbidden. A comment could paper over it, but what I would really prefer is something that makes the reasoning self-evident from the logic alone: MOV encodes as 01 ddd sss, M encodes as 110, so MOV M, M becomes 01 110 110 = 76h = HLT. That chain of reasoning is what I want visible in the source, not just the conclusion. Not sure how to get there cleanly yet.

René Coignard

05 May 2026, 19:32

bitRAKE

Joined: 21 Jul 2003
Posts: 4467
Location: vpcmpistri

bitRAKE 05 May 2026, 19:41

The error could be explicit, "unexpected HLT form, MOV M,M". Even if it were buried in layers of macros it would provide descent signal to the user.

05 May 2026, 19:41

coignard

Joined: 04 May 2026
Posts: 7
Location: Germany

coignard 05 May 2026, 20:41

In the end I settled on

Code:

check   d eq M & s eq M
jyes    use_hlt

and the full MOV calminstruction looks like this:

Code:

calminstruction MOV? args&
    local   dst, src, d, s
    match   dst=,src, args
    jno     error
    compute d, dst
    check   d eq d element 1 & d metadata 1 relativeto reg8
    jno     error
    compute s, src
    check   s eq s element 1 & s metadata 1 relativeto reg8
    jno     error
    check   d eq M & s eq M
    jyes    use_hlt
    compute d, d metadata 1 - reg8
    compute s, s metadata 1 - reg8
    emit    1, 01000000b or (d shl 3) or s
    exit
error:
    err     'incorrect argument'
use_hlt:
    err     'this encodes as HLT; use HLT instead'
end calminstruction

05 May 2026, 20:41

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum