Z88dk: support for the DAI

[feilipu]

In a conversation with @zemikele, he raised the issue of the DAI machine, and whether it could be supported by z88dk?

• Description of the DAI.
• Scanned pages of disassembled ROM code : (pick all FW* files).
• The repair of Michel's "new" DAI.

He wrote for it in the day, and has a current project with it.

[suborb]

It's always going to be possible - especially since there's an emulator. The graphics display looks interesting.

I suspect the main trouble will be around figuring out the tape format.

And for real hardware I guess we could lift your AM9511 driver?

[feilipu]

Actually, the conversation started around using a Raspi as a DAI expansion, and as an Am9511A emulator, and converting the float formats, and using Microsoft PRL with 8080 code. So yes, the Am9511A was part of the background.

In a nutshell, this project - called DXM - consists of adding an extension card - plugged on the CPU bus - equipped with a dual ported SRAM (4 KiB and later 64 Kib) to exchange (both ways) requests / responses with a raspberry pi zero w, the later acting as a co-processor for many requests ranging from tape/disk IOs to internet access, low-level debugging, RAM extension, etc... and arithmetic processing !

@zemikele would be able to provide any background or reference. He knows the DAI very well.

[feilipu]

And for real hardware I guess we could lift your Am9511A driver?

I need to write the conversion routines to enable the Am9511A to look like IEEE-754 32-bit floating point to the outside world. It is pretty simple, just a few shifts and adding bias. And this might be the right push to get that done.

[feilipu]

8080 Limitations - Noting that there are now (to my knowledge) two floating point math libraries available for 8080.

There is the LLL code and now the DAI soft APU code, both of which use an IEEE-754 like 32-bit interface.

Another project, I feel.

[zemikele]

Hi everyone !

Greetings from Paris, France ! (in not quite the same time zone as Australia ! ;-)

Glad to join the z88dk community and find some interest here in this fantastic machine of the early 80's called the DAI (from "Data Applications International", a Belgian company later known as "Indata").

As @feilipu pointed out, I am embarked on a hobby project with some friends here to extend the DAI with a small PCB connected to the CPU bus (50 pins called the "X-bus"). That PCB will host a dual-ported static RAM chip (4 KiB initially), address decoding logic and a connector to a Raspberry Pi zero W.

The idea is to have the "raspi" serve as a "helping device" to restore the joy of using such a nice machine without all the burden of the days (slow / unreliable tape I/Os, limited storage, expensive peripherals, sub-optimal hard-wired keyboard, etc...) Last but not least, as a developer at heart, I wanted to speed-up the development cycle with modern debugging features. And with ASM code, my prime target, this is a must !

One of the concerns I had initially for posting here was that the DAI does not boast a Z80, but only a 2 MHz intel 8080A. And from the various tools - all including "z80" in their name - I was not too sure that the more limited 8080 instruction set was a "prime citizen" in the z88dk project.
Fortunately, @feilipu re-assured me and here I am !
( I also have a PCPI Z80 card (16 MHz 512 KiB) running on my Apple IIe and IIgs )

At the same time, from the industrial cards origin of the DAI company, the machine was fitted with all kinds of ICs and ports. I will post shortly a detailed description of the computer but I can already mention the presence of a 8253 interval timer, a 8255 PIO, a TMS5501 interrupt controller + timer, a nifty ZNA134 video chip, analog "paddle" (joystick) support and an optional Am9511 math co-processor.

That led to a set of extensive I/O ports - for the era - including a parallel port (part of the "DCE bus" allowing multiple peripherals on that single 24-bit I/O port), an RS-232 port, a clean and sharp video output (SCART RGB 50 Hz), stereo sound, cassette tapes, paddles, etc...

I will also detail in a later post the goals with the DXM project ("Deux eX Machina"), which in my opinion could fairly easily be used with other machines. Only the address decoding logic would require some adaptation, but easier with the use of a programmable GAL.

Voila ! Nice to meet you all, enthusiast people ! :-)
@zemikele

[feilipu]

Finished float32 to float am9511 conversion routines (finally).

[feilipu]

Possibly a next step would be to get the LLL floating point library (8080), into classic? Now that the float format (which inspired the Am9511 format) to IEEE-754 is clear, just need to work out how to hook it into classic.

Alternatively, or as well, a renentrant 16-bit floating point library for 8080 should be possible, since it doesn't generate the same register pressure that 32-bit or 40-bit floating point libraries would produce.

[suborb]

If I remember correctly, the LLL code is just the arithmetic primitives and a square root? So we'd need to build the rest of the library using C code - which since we've done it a couple of times already so shouldn't be too much of a hassle.

The main thing (and that is actually fairly minor) is adding support for the lll format into sccz80 - is that documented anywhere?

It might be worth taking a few of the integer routines to improve the 8080 library as well.

[feilipu]

The main thing (and that is actually fairly minor) is adding support for the lll format into sccz80 - is that documented anywhere?

If I'm not mistaken, the LLL format is the same as the Am9511 format (on page 2). Just a guess, but I'd say AMD followed their (LLL) guidance when designing the hardware APi. The format is documented here (on page 2). It is not totally clear from the document, but I was using the LLL input routine as a way to get floating point into the Am9511A a few years ago so I'm pretty sure they are the same.

These simple routines are all that is needed to go from IEEE-754 to Am9511 (or LLL) and back.

But, the DAI math routines are also written for 8080, and possibly they would be a better starting point. The DAI Float ROM listings also have (long) integer routines. The advantage from starting with DAI code would be that the software produces the same results as the hardware (Am9511), and that the library is much more complete. The disadvantage is that it is a bit of an unknown quantity (at least to me). I haven't found a definition of the DAI floating point format yet. I'll update this when I do.

DAI firmware listings (some).
FW_0C0-0CF.pdf
FW_1E0-1EF.pdf

Unrelated, but for a 16-bit 8080 floating point library, would the preferred binary api be de = bc operand de (de for single op), or would it be better to stick to hl = de operand hl (hl for single op)? Or, something else entirely?

[suborb]

Looking at some the routines and data, I think the DAI format is the same.

I've started to disassemble the original ROM using the labels from the document - I think it's easiest to treat it as a blob initially (same as we do for mbf32) - I guess a lot of the bridge code can be shared with an am9511 library.

For an assembler api, de and bc are much better operand registers than de,hl - it's almost inevitable that you're going to want to use (hl) at some point. The C api will have to be the usual one though.

Edit: I've added -fp-mode=am9511 to generate floats in the right format.

[suborb]

I'm wondering if we should add a -lfastmath_am9511 to speed things up for 8080 integer arithmetic (I think it was established that it's not faster for z80?) The am9511 routines should be in the machine library, which just leaves the routines in fast math looking like:

l_long_div:
      call  am9511_push_dehl
      call  am9511_execute
      defb  DDIV
      call  am9511_pop_dehl
      ret

It might be neat to add am9511 emulation to ticks (Takeda emulator has some code if needed), though given that ticks runs unregulated the timings would be "a little" off.

[feilipu]

Not sure it will be viable to generalise an Am9511 interface, as there are at least 3 ways to connect it to a Z80, each of which has software implications.

If the DAI Am9511 interface is well known, then that might be the best first answer, as it is a production machine. The YAZ180 Am9511 interface is custom, to say the least.

Probably the greatest short term good comes from reusing the DAI soft integer & float library for 8080, if it works. As it is 32-bits Am9511 like, it will probably be faster than genmath.

[suborb]

Ah, I just assumed most interfaces would be spinning for the ready flag and then writing the command/data either via IO or memory mapped hence we could have a simplified interaction.

Hopefully I'll get the DAI fp code working within the next couple of days.

Edit: Some bits are working, log10() looks slightly off. printing isn't working yet unfortunately.

[feilipu]

The Am9511 interface, as there are at least 3 ways to connect it to a Z80, each of which has software implications.

It is covered in the techdocs, but the Am9511 has a /PAUSE output that should be connected to the Z80 /WAIT input. The Am9511 will cause the Z80 to wait when it is asked to do anything, that it is not ready to do.

1. the simplest strategy is to simply write to the Am9511 as if it were ready, and then the Z80 will forced to wait until the APU is ready to proceed. Ok, if you're not trying to respond to interrupts or other events.
2. the only thing that the Am9511 will respond to (if it is not ready), is reading the status register. So the next simplest strategy is to poll the Am9511 to see if it is ready, before trying to write to it. Best to do this if you're slower than the APU.
3. the Am9511 can produce an interrupt when it is ready, so using interrupts is the most efficient method of using the APU, particularly when you're faster than it is.
4. there's also DMA as an option, described.

If the DAI Am9511 interface is well known, then that might be the best first answer, as it is a production machine. The YAZ180 Am9511 interface is custom, to say the least.

I'm not sure what the DAI assumes its interface is. Need to read up on that.

__EDIT__ Deleted off-topic YAZ180 stuff. The YAZ180 Am9511 API discussion can be read there.

[suborb]

This is an odd library, the timings are all over the place so I still can't say if it's quicker or slower than another library. For example sqrt() is not too far off math32 (so quicker than mbf32), but sin() is substantially slower than either of them.

On the whole, it looks like it broadly works though the n-body value is "15.946.." for both results, achieved in 1_529_xxx_xxx (so between math32 and mbf32) but something isn't quite right in the librarycompiler with that result. (0 was coming out as 0.5)

Spectral norm comes in at 7_378_xxx_xxx with the correct answer, so a bit slower than mbf32 but a lot faster than math32

Todo:

• [x] Header file
• [x] Error handling?
• [x] Naming (it's all over the place)
• [x] modf()
• [x] frexp()

[feilipu]

Well it is great that you've got the DAI maths package working within z88dk. Irrespective of whether it is fast or slow, it is a true 8080 maths solution so it relieves the issue that no maths library comes with 8080.

Maybe @zemikele knows the licencing situation for the DAI code? Probably should check that first, though.

[suborb]

Well, we do have one already - mbf32 - it's not part of the repo, but it's easy to build: https://github.com/z88dk/z88dk/blob/master/libsrc/math/mbf32/z80/math_mbf32.asm

If we can't establish a licence for the dai32 code then we'll have to do a similar thing for this library as well.

The main maths library gap we've got is for the gbz80 - not having a sign flag makes converting the 8080 ones a fairly delicate operation of inserting bit 7,a ; jp (n)z, about the place.

[suborb]

That was a nice little detour (I'll do the docs/benchmarks over the next few days).

Now, back to the machine and adding support for it. Adding support is probably not going to be that difficult once we know a way to get software onto the machine. It looks like tape is the best way: any idea of the format?

[feilipu]

@zemikele thoughts on the best way to get applications into the DAI?

I read there's a binary format, and there's a data format both off tape.
How does the system know where to load the binary data?

[feilipu]

There's some hints here in this toolkit for reading MSX files with the DAI.
And looking at the disassembly listings for file I/O from 0xD23D.

[feilipu]

Some updates from @zemikele

I have now clarified by talking to some friends in the DAI environment.

1) I have no idea regarding the current legal status of DAI ROM code.
I would think that it is now abandonware but I definitely have no certainty about it.
Neither do I know how to get in touch with those people who could confirm this...
I just know - because I contacted him - that the amazing work done by Jan Boerrigter with his book on commenting the DAI firmware can be freely shared. That's what you have already seen with the downloaded scans.

2) With regard to the tape I/Os on the DAI, all had already been described, albeit some important explanations only in French.
Bruno Vivien - one of those friends - has spent quite some time analyzing it a few years ago. You can see his findings here.

• Cassette Interface
• Format

He even made some programs to generate a .WAV file from a binary and vice versa.
I have myself some good knowledge on the topic and can assist in translating text from French to English and providing explanations.

Because obviously, DXM will eventually need to read and write binary files (to hard drive, SD card, network storage, etc...) all this from the I/O vectors located in RAM at address #02C5. The bold labels are the primitives used by BASIC I/O commands.

BASIC programs:     SAVE, LOAD
BASIC arrays / data:    SAVEA, LOADA
Utility / Monitor:  W(rite), R(ead)
Others:         (e.g. SPL macro assembler commands)

        Data/cassette switching vectors:

        Copy of ROM (#D7A4 - #D7CA) for cassette and RS232.
        Can be loaded with other I/O vectors.

02C5-EB IOVEC:  02C5    WOPEN:  C3 B8 D2    JMP :D2B8
        02C8    WBLK:   C3 Fl D2    JMP :D2F1
        02CB    WCLOSE: C3 27 D4    JMP :D427
        02CE    ROPEN:  C3 25 D3    JMP :D325
        02D1    RBLK:   C3 40 D3    JMP :D340
        02D4    RCLOSE: C3 45 D4    JMP :D445
        02D7    MBLK:   C3 A2 D3    JMP :D3A2
        02DA    RESET:  C9 00 00    RET
        02DD    DOUTC:  C9 00 00    RET
        02E0    DINC:   C3 B4 DD    JMP :DDB4
        02E3        C9 00 00    RET
        02E6    TAPSL:  24 24       Tape speed leader. 
        02E8    TAPSD:  24 3C       Tape speed data. 
        02EA    TAPST:  24 18       Tape speed trailer. 

Here's an edited OCR'd version of the first part of the commented firmware describing DAI memory map.

DAI Memory Map 5.1 v2

[suborb]

I've made a start on this. We're at the stage where (theoretically) console based programs should be able to run.

The catch is that I've only done the conversion to a .dai format - I still need to turn that into a .wav file so it can be loaded into mame. I think @zx70 has written enough routines that do this so I should be able to cobble something together.

Edit (again):

[suborb]

So, the feature list that's possible:

• [x] appmake creating a loadable file
• [x] Firmware screen output
• [x] Firmware keyboard reading
• [ ] Inkey keyboard
• [ ] Joystick/paddle support
• [ ] Generic console + modes
• [ ] Graphics
• [ ] One bit audio?

Looks like the video memory runs backwards from 0xbfff with 0xbfff being a mode marker, and 0xbffe being a colour flag. So top left hand corner of screen starts at 0xbffd.

[feilipu]

Feeling inspired by this whole Am9511A maths thing, I made an Am9511A Module for RC2014. So the DAI wouldn't feel lonely with its Am9511A. I'll try to build a generalised library for Am9511A maths, with follow up in #1543.

• [x] Am9511A library.
• [ ] Am9511A DAI glue.