ASM has hit just about the right level of pain - what next?

[paulca]

So the retro Z80 DIY project is in full flight with GPIO, LCD screen etc.  Another PCB is in the works with period PIO, CTC and DART.

ASM coding is "ok" right now, I write some test code to get some hardware working and test a few different modes etc.  Then I collect up all the scattered routines and put them into a "xx_driver.asm".  As it progresses each new test application uses library routines used and tested by the last one.  It's still "tiny" < 1000 lines of ASM.

But it's getting to the point where I can't hide in "Level 1 ASM" code with registers and a little stack.  I need to start with isolating functions, parameters, return values and stop relying on my register file as my main  state.  Its just too damn hard tracking register use, register mutation and register restore once you put mode 2 (or any!) interrupts into play.  I still can't even decide if sub-routines should be responsible for restoring state or not.  To me it seems as though sub-routines storing and restoring state "just in case" the parent was using it is wasteful ... is the parent wasn't.  Should a "blocking delay" function which uses the accumulator "PUSH/POP AF" for example.  I mean if the parent is using A or F and is relying on it, then sure.  But is it not better that the caller assumes the callee will corrupt the register file and take its own measures?

Load A, B, D, E
Call something
Reload A, B, D, E again
Call something
Reload A, B, D, E again

etc.

I need C.  Badly.  I know I am about to tie myself in knots in ASM, so I need to start prioritising getting a C compiler in the toolchain.

I opened the can of worms with Chat GPT and regretted it.  It's probably not going to help much.    It offered me "sdcc".  I checked it out, compiled hello-world.c and checked the files produced.

To my horror it was dumping everying at 0x0000 and up, code, constants, everything.  All over the page 0 RST/ISR blocks and all over my 0x100-0x2000 ROM code area.

Actually that wasn't the horror, the horror was noting there were nearly 40 different segments declared in the map file.  I tried the "easy options" like "--code-loc" and "--data-loc" but that only moved the "main" segments to those addresses, the other 32 of them remained at 0x0000 and up.

So like all these toolkits and retro application suites, the probably started out to be what I wanted, but have had so many features and so much opinion added to them over the years that they are no longer "DIY Homebrew hardware" compatible.  They are far more suited to "Insert Retro Kit Product w/ full CP/M support" build and run projects.

I need something far more low level.  Far simpler.  I need a compiler that doesn't have 35 different ways to store variables but has just 3 or 4.  The "classics", .bss, .text etc.  Although it is my choice if I choose that nomeclature or not.

I thought I was on to a winner when I noticed the "ASM" output it produced was "tamable" by changing just the labels that contained anything in the symbol file it might produce working code if I just lifted the 16 bytes of ASM in question, the addresses might just line up.

My assembler doesn't like that format though.  So I need to find, setup and use an ASM that does, then use a linker to merge the two objects into a ROM image with "dd".

I am using sjasmplus for Z80 ASM.  It's not "GNU ASM" compatible.  That's fine.  I looked at the GNU route and recoiled away.  If you want opinionated ... GNU.  Nothing is simple.  If you want to go the "GNU Stack" route, it involves the full GNU devel stack, configure, automake, autoconf, gcc, ld and so on and so forth.  It will produce "elf" outputs and your "boot.asm" will need to OBEY all that that entails if you want "ELF" binaries from a GNU C compiler to run.  Including any parts of the memory mapping which it dictates and are too annoying to change.  This "IS" the stack used by many MCUs today.  Just a bit too complex from where I am right now.

I don't think I want to go that far.  Not with this project.  It's perfume on a pig.

I want to explore how it may have been done in the early days.  Before you even got to the likes of CPM and BASIC.  I realise both where mostly written in ASM, but C was around.  I want the simple view from necessity to solve the problems I presently face.  The next step not the 1990s solutions, the 1970s solutions.

I envision a blunt simple C compiler than turns C code into Z80 ASM.  When I declare a "const" it can go in "rom_data".  If I declare a variable it can put it in "ram_data".  If it has an initial value a two stage will be required.  Someway to load "ram_data" from "rom_data" initial values at "user land boot".

I don't need 48 different segments and full C99 compliance.  I just want to make writing some code easier.  Just simple things.  A managed call structure which handles pass by register, pass by stack or pass by memory pointer.  Maintains CPU state between nested calls.  Auto 16bit indirect load and store so I don't have to write the ASM for them.  Just the basics

What are my best options?

Right now I am exploring z88dk which is another huge z80 dev kit project, but it attracted me as it has a "Homebrew hardware how-to" near the top of it's docs, which on a quick scan suggests it supports much simpler memory models and configurations like mine.  Down side is... after an hour, I still hadn't been able to download it, install all the tools required to build it.... solutions which are larger than the project its self are hard to swallow.

[paulca]

A complication presented by "my model" is that I am targetting the MCU model.  In circuit writable NOR Flash ROM.

So for example:

.org 0x2000
user_main:

Is in ROM.

This alone makes my memory map incompatible with most Z80 systems where ROM boots the board, user loads program to RAM, ROM jumps to user code.

The output of sdcc makes sense as 0000 will be mapped by the boot ROM via vectors to where it actually got loaded, at 0x8000 maybe.

EDIT: While I ponder this I'm off to see if I can get the GPIO driver to "bit bang SPI".  Maybe I can get it to talk to the outside world before I make room on the breadboard for the DART and UART.  Actually bit banging UART might be easier if it wasn't for the tight timing (I have no timer support yet).

[paulca]

As for where I am right now...  this is my last test application. It tests displaying 8 and 16 bit values on the LCD.

Code: [Select]

user_main:
        ; Init PIO Port B as output (Mode 0)
        LD A, PIO_COM_MODE_0        ; Control word: Mode 0, all bits output       
        OUT (PIO_COM_PORTB), A     ; Device 1001 - Command + Port B
        LD A, 0x55
        OUT (PIO_DATA_PORTB), A
        ; Point the correct ISR vector to our ISR
        LD A,PIO_PORTA_ISR_VCT
        LD DE, port_isr
        CALL InstallISRVector
        IM 2
        EI
        ; Setup port A for interrupts
        CALL init_port_a

        CALL lcd_init

        LD HL,str_title
        CALL lcd_print_string
       
        CALL lcd_line_two

        LD HL,str_author
        CALL lcd_print_string

        LD BC,0x8FFF
        CALL delay_blocking       

        LD D, 0x00 ; Value
        LD B, 0xFF ; counter
.count:       
        CALL lcd_clear_screen_and_home
        LD HL,str_t8b
        CALL lcd_print_string
        CALL lcd_print_hex_prefix

        LD A, D   
        CALL lcd_print_hex8 
        LD A, D  ; shouldnt need to

        CALL lcd_line_two
       
        PUSH BC
        CALL lcd_print_hex_prefix
        LD C, D
        LD B, D
        CALL lcd_print_hex16
       
        LD BC,0x3FFF
        CALL delay_blocking
        POP BC

        ; DJNZ .count
        JR .count

port_isr:
        IN A,(PIO_DATA_PORTA)
        AND 1
        CP 1
        JR NZ,.decr
        INC D
        JR .end
.decr:
        IN A,(PIO_DATA_PORTA)
        AND 2
        CP 2
        JR NZ,.end
        DEC D
.end:
        EI
        RETI


Two buttons on port A.  Press one it increments, press the other it decrements.  Press both and it probably crashes.

[tggzzz]

I need C.  Badly.  I know I am about to tie myself in knots in ASM, so I need to start prioritising getting a C compiler in the toolchain.

Writing C for the Z80 is possible; I was doing it c1984.

You should look at Forth; it is a halfway house between machine code and C, and is efficient w.r.t. space and time. It has an inbuilt REPL, so the "compiler" is on the board and you just use your PC to feed source code to it.

[bingo600]

Have a look here

Maybe mostly CPM based but ...
http://www.z80.eu/c-compiler.html


I did some Z80 CPM w. "The Amsterdam Compiler Kit" , some 30+ yers ago
https://tack.sourceforge.net/

Else i's expect sdcc is up for the task (embedded)
https://sdcc.sourceforge.net/


I have no idea about this one, but seems embedded'able too.
https://github.com/z88dk/z88dk
https://stackoverflow.com/questions/78253893/compiler-for-z80-cpu

[brucehoult]

I think SDCC is your best bet.

You can tell it where to put the code and data with a linker script or just on the command line:

Code: [Select]

sdcc -mz80 --no-std-crt0 -Wl-b_CODE=0x0000 -Wl-b_DATA=0x8000 -Wl-b_BSS=0x9000 -o output.ihx main.c crt0.rel

As for calling conventions ... these early 8 bit micros -- and the 8086 for that matter -- didn't have any defined calling convention, it was every man for himself.

People tended to just make up whatever seemed to work best for each individual function, and then documented that:

memcpy(dst, src, size): DE=dst, HL=src, BC=size, clobbers A

With so few registers probably the only sensible thing, if you want a standard ABI, is to assume that everything not explicitly used for args/return is clobbered. Especially on 8080/z80 where it takes so few bytes of code to push/pop register pairs that you want to preserve just before/after calling a function, with args in registers, but accessing things in the middle of the stack is quite costly (e.g. ld hl,0xnnnn;add hl.sp;ld a,(hl))

[iMo]

I do understand the magic temptation of many today's (younger) makers and hackers to play with the old tech like 8080/8085/8051/8088/Z80/6502/6809/68k etc. (like let us do the "retro stuff" on it) because I worked with all those chip in 80ties, BUT on the other hand I also can clearly see that the life is too short..   
I had a period several years back when I participated on a retroBSD projects, or when I built myself the PDP8 and PDP11 on an FPGA, but it was always about latest MIPS32 and FPGA, so at least the time spent with playing with some new technology gadgets.
I burned a lot of time with Forth as well during last 15y - but always running on the "new technology" - like pic18/24/dspic33/pic32/atmegaXX/stm32/FPGA..
Fazit - I would never ever consider that old tech today. Nothing new could be expected out of it - no new products could be made out of it, nothing new to learn when working with it, zero added value, just "the right level of pain"..
 

[nctnico]

I'd go for SDCC when I would need to target an 8 bit like the Z80. IIRC I used SDCC for the 68HC11 or 8051 about a quarter of a century ago.

[paulca]

I ain't young. in fact I hold a similar vintage to the Z80 itself.

Back in 1982 when I insisted on reading the book on Z80 programming my Uncle left lying around, he bought me "Assembly Language for beginners".

On a retro computing YouTube channel, someone surfaced with that book.  All kinds of neurons spanning decades fired.

"You think you know how computers work?  Prove it.  Start back there, make one, they way they did."

It is scoped though.  "An arduino like MCU device".  I evened started calling it "Z80-MCU-3232"So CPU, RAM, Incircuit flashable ROM, GPIO with interrupts, Timers, 2x(U)ARTs, possibly an SIO for SPI/I2C in hardware.  Maybe a period 8bit resistor ladder ADC and PWM from the SIO?

Anyway on that front I'm 50% there.

[paulca]

I'd go for SDCC when I would need to target an 8 bit like the Z80. IIRC I used SDCC for the 68HC11 or 8051 about a quarter of a century ago.

Seems it gets the recommendations. 

I just need to tame it then and work out how it's initialisers work etc.

If I can get it part the way there I don't mind hacking binaries together with DD.

The only reason I haven't properly partitioned the flash rom is that I'm lazy.

[tggzzz]

I ain't young. in fact I hold a similar vintage to the Z80 itself.

That is young.

Understand the simplicity of Forth implementations, and you will see Forth is closer to assembler than C, is very simple to understand and implement, and memory efficient, and faster than BASIC.

IMHO it is ideal for noodling around, peeking and poking, building software from the bottom up. If you are building a Z80 system from scratch, that is probably what you are intending to do.
https://hackaday.com/2017/01/27/forth-the-hackers-language/

[paulca]

BTW:
I did manage to get SPI output today.  Only 'H' ... I can work on the other characters later.

Apparently 6.7kHz clock speed with a 49.2% duty cycle.

That's not bad.  Depending on what is receiving and how it feels, I can be more slopy with the duty cycle and double that speed maybe.  (Master clock is 1.843Mhz)

The target for SPI is A DS3231 RTC chip so it can be a clock

EDIT:
Assembler is fun   You know that was almost easier than setting up an STM32 to do the same!

[paulca]

IMHO it is ideal for noodling around, peeking and poking, building software from the bottom up. If you are building a Z80 system from scratch, that is probably what you are intending to do.
https://hackaday.com/2017/01/27/forth-the-hackers-language/

They had me with this....

Forth is what you’d get if Python slept with Assembly Language

Speaking of python, I tried to make my ROM flasher faster by sending it blocks of 2048 hex characters instead of 2 at a time.

While I realise without concurrency (double buffers/ping pong etc.) it only scrubs the surface of the overheads.

What I didn't expect was, as I made the blocks larger and larger, it slowed the overall process down.

My little "thread heart beat" LED told me all I needed to know.

Python was taking longer to generate a block of HEX than the Flash ROM was taking to program it.

[tggzzz]

They had me with this....

Forth is what you’d get if Python slept with Assembly Language

That's an amusing snark, but unfair on Forth. It was designed for (by today's standards) miniscule systems. Hence it has to be simple - much simpler than an assembler or compiler

I'm not a big fan of python, but will use it for small simple applications iff useful libraries are available.

Forth is better close to the silicon; theres bugger all underneath it. At runtime it is simply an array of function pointers called one after another. Any function you define is itself just a list of function pointers.

LISP is arguably simpler, but only if you ignore the heap and GC!

[Analog Kid]

Just a comment from the peanut gallery here:

I don't think you need to jump to C.
You can do anything you need to do in assembly language: you're just running into its common limitations, primarily the small set of registers.

My suggestion: come up with a scheme for parameter passing and variable storage using your registers, one that works for the specific app you're working on, and stick to it. That way you'll have an orthogonal method that you don't have to scratch your head and second-guess every time you need to call a subroutine or handle an interrupt.

I've never programmed the Z80 but I do have an itch to do so before departing this life: it just seems like such a nice little machine, an unsung hero of the microprocessor world. Especially that interrupt-handling mechanism where all those registers get swapped: quite kewl.

[nctnico]

Well, having done quite a bit of Z80 assembly back in the day (I even build a frequency counter driven by a self designed Z80 processor board at some point), one of my regrets is not to have switched to C back then. C makes life so much easier. Who cares about the registers. Let the compiler deal with it. Especially with decent and free compilers (like SDCC) available nowadays.

[tggzzz]

The Z80 is not a nice machine; it is vile compared to a 6809 or similar, for many reasons.

To give you an idea, look at the instruction map for a 680x: orthogonal, complete (mostly!). Now look at the Z80 equivalent: incomplete, sparse, messy.

Try, for example to use a Z80 index register to point to a strict representative noting a node in a linked list, where the link to the next node starts at addresses 0x2 in the struct. Now try to move the index register to point to the next node; it is surprisingly messy and slow. Much better to forget the IX register and just use the 8080 registers!

Try to do i/o to an i/o address/port defined at runtime.

The Z80 looked good to naive hardware engineers who thought, for example, it was neat to be able to print a string with a single instruction!

[Analog Kid]

So then I wonder why the OP chose the Z80 to program if it's as bad as you say it is.
Apparently they weren't forced into that decision at gunpoint.

I still wanna program it ... all of those deficiencies you point out are just challenges to be overcome. That's the fun of it.

[nctnico]

Try to do i/o to an i/o address/port defined at runtime.

I think you got the wrong processor in mind. Z80 allows to load input/output from the I/O space using the C register as the index.

And getting the address of the next element of a linked list pointed to by IX into IX is not difficult. Something like:
LD B, (IX+2)
LD C, (IX+3)
PUSH BC
POP IX

I don't see how this is messy. Remember is it an 8 bit machine. PS: I didn't check big / little endian address order.

[tggzzz]

Try to do i/o to an i/o address/port defined at runtime.

I think you got the wrong processor in mind. Z80 allows to load input/output from the I/O space using the C register as the index.

Just looked at my Mostek Z80 manual, which I haven't used in 40 years, and it seems you are... right.

So what happened? Not sure, but possibly the Whitesmiths compiler wasn't up to that or was using an 8080 subset. I definitely remember seeing the in/out instruction being constructed on the stack, and then executed. Oh well.

[nctnico]

Some of the older compilers where really crappy. A long time ago I spend money on a 8051 C compiler (IIRC sold / made by Dave Dunfield) which was utter crap. Even back then SDCC produced much better code.

[tggzzz]

One of the attractions of the Whitesmiths compiler to more experienced people in my company was that it targetted many processors and could run on a PDP11. I suspect there weren't many of those c1983.

Your index register linked list chaining looks about right. Five instructions including surplus moves through the stack. Given everyone was.raving a about the improvements in the Z80, I was horrified when I first worked that one out.

The earlier 6800 did it in one instruction: LDX loaded both bytes from successive memory locations, and it could use indexed mode with an offset. The mnemonic would have been something like
 LDX 2,X
Bit nicer in all respects than the Z80
 LD B, (IX+2)
 LD C, (IX+3)
 PUSH BC
 POP IX

And the 6809 was even nicer

[brucehoult]

I've never programmed the Z80 but I do have an itch to do so before departing this life: it just seems like such a nice little machine, an unsung hero of the microprocessor world. Especially that interrupt-handling mechanism where all those registers get swapped: quite kewl.

The problem is there is no way to know which register set is active. And while some systems may reserve one set for interrupt handlers, you can equally well find examples of application code using both sets -- the fastest 32 bit mul/div and soft float routines use both sets, as do many graphics routines. You can't do that and use them for fast interrupts too -- and interrupts are usually so infrequent that it's much more important to make normal application code as fast as possible. Adding a buffer/queue to fast I/O devices is usually the better way to go.

Also of course ex af,af', ex de,hl, and exx (swaps bc, de, hl with their shadows) don't actually copy any data, they just toggle flip-flops on one or more inputs of XORs on different register address lines.

[Analog Kid]

Yes, I'm sure I'd have a pretty steep learning curve to start programming that chip.

So is there really no way to know which set of shadow registers is active? No tricky way of reading/writing those registers to determine which? That would certainly be a problem ...

[Benta]

@paulca, if you want to go really retro in this, you need to port CP/M as operating system, and use PL/M-80 as programming language. A crosscomplier is available: PLMX.

Cheers.