Documentation?

[floooh]

Documentation?

[floooh]

...and this causes the .h file to be built, in the next make. There doesn't seem to be a date check.

The lc80-roms.h file will be rebuild when either the lc80-roms.yml file changes, or the ROM dump file pointed to by that YAML file (https://github.com/floooh/chips-test/blob/master/examples/roms/lc80-roms.yml).

The code-generation runs via this python script: https://github.com/floooh/chips-test/blob/master/fips-files/generators/dump.py, there should be a timestamp check happening there unless it's a bug, but I haven't noticed any strange behaviour (I'm using the same check for all code generation stuff, also in other fips projects).

Regarding behaviour of the RETI instruction: interrupts are disabled "automatically" during the interrupt acknowledge machine cycle in the CPU and before the interrupt service routine is entered. A RETI will not automatically enable interrupts though, that's up to the interrupt service routine. Usually this happens at the start (if the ISR can itself be interrupted), or at latest right before the RETI instruction (through an EI).

Here's a snippet from the RETI description in the Z80 manual:

However, both RETI and RETN will move the status of the IFF2 flag into IFF1 (this is only documented for the RETN instruction, but according to the "Undocumented Z80 Documented" PDF both RETI and RETN behave the same (see page 20 "Things affecting the interrupt flip-flops" here: https://github.com/floooh/emu-info/blob/master/z80/z80-documented.pdf

Cheers :)

[floooh]

Hi, there's a short embedding guide in the systems subdirectory: https://github.com/floooh/chips/tree/master/systems#embedding-guide

It's a bit outdated here and there, but all in all it should still be valid.

In general I want to put most of the detailed documentation into the headers themselves, most chip headers have this missing, but the CPU header docs are in pretty good shape, for instance here's how the Z80's interrupt handling works (a bit non-trivial because of the Z80's daisy chain protocol):

https://github.com/floooh/chips/blob/master/chips/z80.h#L228

Usually this protocol is implemented in the Z80 family chips, for the CTC this function is called:

chips/chips/z80ctc.h

Line 316 in 6cf1ac7

static inline uint64_t z80ctc_int(z80ctc_t* ctc, uint64_t pins) {

...when the CPU is in an interrupt acknowledge machine cycle (actually this block gets called in each M1 cycle, could be an instruction fetch, or an interrupt acknowledge machine cycle). This is because the interrupt controller must "snoop the bus" for a RETI instruction.

chips/systems/lc80.h

Lines 527 to 534 in 6cf1ac7

	/* interrupt daisychain priority is: CTC => User PIO => System PIO */
	Z80_DAISYCHAIN_BEGIN(pins)
	{
	pins = z80ctc_int(&sys->ctc, pins);
	pins = z80pio_int(&sys->pio_usr, pins);
	pins = z80pio_int(&sys->pio_sys, pins);
	}
	Z80_DAISYCHAIN_END(pins);

The LC80 operating system itself doesn't issue interrupts as far as I saw (only when programmed through user code), but you can step-debug through the Z9001 emulation (which uses CTC interrupts for its system clock), for instance you can set breakpoints in various functions of the CTC's interrupt protocol response routine here:

chips/chips/z80ctc.h

Line 316 in 6cf1ac7

static inline uint64_t z80ctc_int(z80ctc_t* ctc, uint64_t pins) {

Hope this helps! If you're stuck somewhere, just add more questions to this thread :)

[flypie]

Thanks that is great.
I ended up deleting doing a small mod allowing the ROM size to be smaller than the ROMs, deleting the lc80-roms.h file and replacing the lc80_2k.bin file and this causes the .h file to be built, in the next make. There doesn't seem to be a date check.
One thing I did notice was that if I just put a RETIin the interrupt handler, then the first interrupt would be handled but no others, I assume because they have been disabled. From what I can remember of real Z80s DI to be called to disable them.

IM2.zip

[flypie]

Faulty memory obviously.

I just checked and under the Visual Studio touch the bin files does not cause the h files to be built. I also did a build on Linux here is the log from the shell.

Untitled-1.txt