z88dk v1.99A Release Candidate

[Alcoholics Anonymous]

Download from:
http://nightly.z88dk.org/Releases/

The release candidate will be available for testing until December 23 when it will be replaced by an official release of v1.99A.

The download options are a binary win32 build, a binary mac osx build and a generic source tree for other platforms. Installation hints can be found here: http://www.z88dk.org/wiki/doku.php?id=temp:front#installation. Instructions for installing the MacOSX binary are missing so if a MacOSX user is able to submit those, it would be appreciated

z88dk has undergone some significant development in the past two years. The version number reflects this (v1.99) and anticipates a v2.0 when the development roadmap is completed.

WHAT'S NEW

Quite a lot and we don't have a complete list of changes yet.

In broad terms:

* [z80asm] Sections introduced for creating memory maps and compiling for bankswitched memory
* [z80asm] Modern operator syntax introduced
* [z80asm] PUBLIC, EXTERN, GLOBAL scoping keywords introduced to replace XDEF, XREF, XLIB, LIB, etc

* [sccz80] Numerous bugfixes

* [classic c library] New targets and new libraries which will be enumerated at official release

* [new c library] A new c library has been written from scratch in assembly language and currently contains more than 700 functions
* [new c library] Compatible with sdcc
* [new c library] Many unique libraries including zx7 (compression), adt (C++ STL containers), fzx (proportional fonts), BIFROST/NIRVANA/SP1 (zx), tritone music and bitfx sound effects for 1-bit audio devices.
* [new c library] Object oriented stdio allowing writing of sophisticated drivers using code inheritance from the library. Currently base classes implement serial character devices and terminal (console) devices.
* [new c library] Targets supported initially include cp/m, embedded (generic z80) and zx (zx spectrum). The built-in crts allow creation of terminal windows with assignable input source using fixed width or proportional fonts, output as ROM or RAM-resident programs.
* [new c library] The library and crts are highly configurable. Library build time options allow selection between fast and small library code and the crts can be configured at compile time by embedded pragmas in the C source code.

* [sdcc] sdcc is fully supported as alternate C compiler using the new C library.
* [sdcc] sdcc's output is improved by an additional 400 peephole rules supplied by z88dk
* [sdcc] sdcc's calls to its primitives are modified to use smaller and faster callee linkage

The combination sdcc+z88dk supplies a C compiler that behaves similarly to 32-bit C compilers. sdcc implements a large subset of C90/C95/C11 standards and the z88dk library completes the compliance. The only missing element is the disk i/o which is currently under development.

sccz80 will often create smaller code than sdcc particularly when longs and floats are in use.

Some benchmarks including Dhrystone 2.1 and Whetstone 1.2 comparing with some other commercial compilers:
http://www.z88dk.org/wiki/doku.php?id=temp:front#benchmarks

New documentation under construction:
http://www.z88dk.org/wiki/doku.php?id=temp:front

Collection of links describing how to compile with sdcc:
http://www.z88dk.org/wiki/doku.php?id=temp:front#compiling_with_sdcc

Example programs using the classic library:
z88dk/examples

Example programs using the new c library and sdcc:
z88dk/libsrc/_DEVELOPMENT/EXAMPLES

PURPOSE OF A RELEASE CANDIDATE

We are hoping to identify problems with installation and use before an official release. Particularly we are looking for problems with using the new elements in the release.

1. Try making the new c library.

cd z88dk/libsrc/_DEVELOPMENT
windows: "Winmake all" (10-15 mins to complete)
other: "make"

2. Try compiling your own programs and some of the examples.

Thanks to anyone who can find the time at this time of year to do a little testing.

[Sayman]

А я вот, хоть убейте, не понимаю, зачем использовать z88dk если он в итоге ссылается на sdcc? не лучше ли не городить огород, а сразу собирать в sdcc? если библиотека у z88dk столь крута, то перенести её на sdcc. В её внутренности не смотрел, но по названию понимаю (предполагаю), что sdcc_чего-то там_ix или _iy ведёт к употреблению регистра ix. а он в свою очередь жуткий тормоз. в чём оптимизация-то?

[Alcoholics Anonymous]

А я вот, хоть убейте, не понимаю, зачем использовать z88dk если он в итоге ссылается на sdcc? не лучше ли не городить огород, а сразу собирать в sdcc? если библиотека у z88dk столь крута, то перенести её на sdcc.

The library in z88dk is much larger and much more complete. The sdcc library is minimal, just enough for what is considered essential for embedded applications, and is missing quite a few things. But sdcc's library is written in C which makes it portable to all of sdcc's targets: the z80, z180, tls90, stm8, msp430, 8051 .... and this means sdcc can provide the same C library to all of its targets. sdcc is not interested in breaking this by importing libraries written for specific processors; doing so would mean different processors had different levels of C compliance, different corner case behaviours, and would require independent maintenance by people who were experts in those processors. This is something that we've talked about briefly with sdcc. Instead what what has happened in the past year is sdcc has been modified to accommodate z88dk and vice versa and this release is the first result of bringing the two projects closer together.

The z88dk library is also not confining itself to the C standard. There are libraries for music synthesis, proportional font printing, graphics, game engines, and so on. None of this would be accepted in sdcc. And finally, z88dk tries to directly support any z80 target by incorporating crts and tweaking library code for each target, allowing programs to be compiled without the user having to understand compiler details. How many times has someone asked for a crt to use to compile with sdcc? Some of those crts I have seen are incomplete because the people writing them are themselves not familiar with the compiler details. The problem is more complicated with z88dk because the libraries are more extensive. z88dk supports about 50 targets now (only three at the moment on the new / sdcc-compatible side); sdcc has no interest in directly supporting specific z80 machines.

So those are the reasons the two projects will not be merging. There is also another side to this: z88dk is now written to interface with any sort of compiler. At the moment that's sccz80 and sdcc but in the future maybe other C compilers or other language compilers could be interfaced to the z88dk libraries and its support for specific z80 targets.

You can look at some example C programs here:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/
None of these can be compiled using sdcc alone because of missing elements in its libraries but it can compile them when used in combination with z88dk.



В её внутренности не смотрел, но по названию понимаю (предполагаю), что sdcc_чего-то там_ix или _iy ведёт к употреблению регистра ix. а он в свою очередь жуткий тормоз. в чём оптимизация-то?


z88dk supports 50 different z80 machines. Some of those machines do not allow use of one or both index registers. So the library has been written to use one index register - IX. The assembler is able to swap IX and IY in output code so if the target is unable to use IX, the library code can be swapped to IY.

sdcc complicates things a little bit because it uses IX as frame pointer. On targets that have no restriction on IX/IY, sdcc can be given IX and the library can use IY (the sdcc_iy library). On other targets, sdcc and the library must share IX (the sdcc_ix library). What this means is if a particular library function uses IX, it must save IX for sdcc. That's extra code that must be inserted. Because the library passes parameters by register or using callee linkage, the extra code can spoil a clean interface between compiler and library and this leads to larger code in the output. So you always want to use sdcc_iy if you can.

I can give you one example in the qsort() function which uses IX as a function pointer.

sdcc_ix C interface:



_qsort_callee:

pop af
pop bc
pop hl
pop de
exx
pop bc
push af

l0_qsort_callee:

push bc
exx

ex (sp),ix

call asm_qsort

pop ix
ret


sdcc_iy C interface (the assembler will change ix to iy):



_qsort_callee:

pop af
pop bc
pop hl
pop de
pop ix
push af

jp asm_qsort


For the zx target:

* If the rom interrupt is enabled, code cannot use IY. In this case sdcc programs must be compiled with the sdcc_ix library (library uses IX) and --reserve-regs-iy so that sdcc does not use IY.
* If the rom interrupt is disabled, code can use IY so it's preferable to compile against sdcc_iy.

I'm not sure if I understood the rest correctly but if you are asking if sdcc's generated code is improved, the answer is yes. sdcc's output is improved between 5-10% in size and speed, depending on the program, by the peephole rules supplied with z88dk. These are something that may be incorporated into sdcc in the future. Aside from that, z88dk changes sdcc's calls to its primitives to use callee linkage rather than standard C linkage. This will also shave a few hundred bytes off large programs.

[Alcoholics Anonymous]

z88dk 1.99A has been released and is available at sourceforge for download.

Thanks to anyone who had a chance to do some testing. A few minor issues were found and corrected in the release.


CHANGES (brief)


z88dk 1.99A 23.Dec.2015
Major changes incorporated into z88dk. This is a transition release in anticipation of v2.0.

Two C compilers are supported (sccz80 - z88dk's native C compiler - and sdcc).
Two different C libraries are present (classic - the same library as pre 1.99A - and new).

Accordingly, there are now three different compile modes:

1. Compile with sccz80 and the classic C library. This is equivalent to pre-1.99A.
2. Compile with sccz80 and the new C library. Compile lines include "-clib=new".
3. Compile with sdcc and the new C library. Compile lines include "-clib=sdcc_ix" or "-clib=sdcc_iy".

[z80asm] Sections have been introduced for generating memory maps and compiling to bankswitched memory.
[z80asm] Modern logical operators have been adopted.
[z80asm] New scoping keywords PUBLIC, EXTERN and GLOBAL introduced.
[z80asm] Relocate files are generated for output binaries for patching assembled code to a new address at load time.
[sccz80] Numerous bugfixes.
[sdcc] SDCC is now fully supported as alternate C compiler for the new C library.
[sdcc] SDCC's generated code is improved by a large set of aggressive peephole rules (use -SO3 to enable).
[sdcc] SDCC's calls to its primitive functions are modified to use callee linkage.
[new c lib] New C library written in assembly language from scratch aiming for a subset of C11 compliance. Contains more than 700 functions currently.
[new c lib] Stdio made object-oriented so that drivers can inherit library code to implement features with a minimal amount of additional code.
[new c lib] Stdio base classes currently include serial character i/o and terminal i/o implementing windows and proportional fonts. Disk i/o is missing in this release.
[new c lib] Unique stdio implementation allows removal of high level buffers without affecting performance.
[new c lib] Many functions from GNU and POSIX are present beyond the C11 standard.
[new c lib] Many unique libraries including some C++ STL containers, data compression, obstacks, game libraries, sound, fzx proportional fonts, etc. The new C lib contains libraries not present in the classic C lib and vice versa. Over time the two libraries will homogenize.
[new c lib] CRTs are supplied for three initial targets: embedded (generic z80), cpm, zx (zx spectrum). Specialized crts allow immediate compilation without customization by the user.
[new c lib] The library and crts are highly configurable at library build time and at compile time. Options allow easy generation of binaries for ROM or RAM targets.
[tools] New tool ticks is a command line z80 emulator able to exactly measure execution time of a code block.
[tools] New tool dzx7 is a decompressor counterpart to zx7.
[tools] New tool zx7 is an optimal lz77/lzss data compressor with companion decompression subroutines in the z80 library.
[appmake] +rom added to manipulate raw binaries; options include code injection, extraction and conversion to intel hex format.

The new C library completes C standards compliance for sdcc and leads to much smaller and faster output binaries. sdcc's longlong type is not supported in this release.

Documentation is a work in progress.

Installation:
http://www.z88dk.org/wiki/doku.php?id=temp:front#installation

Overview, Classic C Library Information:
http://www.z88dk.org/wiki/doku.php

Overview, New C Library Description, SDCC compilation described:
http://www.z88dk.org/wiki/doku.php?id=temp:front

Some benchmarks:
http://www.z88dk.org/wiki/doku.php?id=temp:front#benchmarks

[Error404]

Hello! Is z88dk 1.99A able to compile entire FUZIX project (very capricious code)? Anybody tried? FUZIX-88dk working?

[Alcoholics Anonymous]

Hello! Is z88dk 1.99A able to compile entire FUZIX project (very capricious code)? Anybody tried? FUZIX-88dk working?

We have been looking at it but it will require some work to do. It's structured right now to use what library functions sdcc has and to supply everything sdcc is missing using C to keep it compatible with all its supported CPUs. If you just compile it as-is using z88dk the savings will only be around 5-8% or so and I think it will be closer to 5% because of the way the code is written.

z88dk's library is quite large and it's all written in assembler. Functions tend to be 3x smaller than the C equivalents that would be found in sdcc and fuzix. What you want to do is replace the sdcc library and some part of the fuzix C library with z88dk's library. For a lot of functions this is easy to do but FILEs and file descriptors are not implemented in the same way in z88dk and fuzix. Fuzix is taking a traditional unix approach whereas z88dk is doing something new in order to make things smaller. So when you get to functions from stdio and functions that deal with file descriptors, z88dk's library is not compatible. stdio happens to be where a significant amount of code savings can be found so you would want to rewrite some of z88dk's functions there to be compatible with fuzix.

z88dk is structured so that you can create libraries by picking and choosing what goes in there, as well as providing your own replacements for some things so we may try to do this at some point. But as I said it will take some work and it will change fuzix's structure. I'm not sure if Alan is interested in something like this (asm level processor-specific) so it may have to be a fork. I do think we may be able to shrink the kernel by up to 10k (that's speculation though!).

We are starting to document some of the inner-workings of the z88dk library now. It's a technical subject though. The creating-a-target (http://www.z88dk.org/wiki/doku.php?id=temp:front#creating_a_target) topic describes how the target library is composed and how the CRT is made. This continues into the device driver section (http://www.z88dk.org/wiki/doku.php?id=temp:front#device_drivers) (which has only just been started) that gives an indication of how stdio communicates with device drivers. This is quite different from fuzix where each stream has a putchar/getchar and each open file has a buffer in ram to speed up char-at-a-time i/o. z88dk's approach has been to eliminate those buffers because they aren't affordable in 64k.

[Alcoholics Anonymous]

z88dk's version of sdcc (zsdcc) has been patched to make the peepholer more accurate. This will improve code quality by some amount. You can update zsdcc (http://www.z88dk.org/wiki/doku.php?id=temp:front#sdcc1) in the usual way.

More details in this thread (http://www.z88dk.org/forum/viewtopic.php?id=9221). But not too many more :P

[Smalovsky]

Плохо что у z88dk нет графической оболочки.

[s_kosorev]

что такое графическая оболочка у компилятора?

[Alcoholics Anonymous]

Плохо что у z88dk нет графической оболочки.

I don't think a GUI or IDE helps anything. A compile line is normally one line and you can easily re-execute that by pressing up arrow and enter. If some files need to be processed, the steps can be put into a makefile or a batch file (http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/zx/demo_tritone/Winmake.bat?revision=1.3&view=markup) and that can be run instead. With sdcc in particular, if there are are many source files you may want to incrementally compile them using a makefile since sdcc can be very slow with optimization turned up.

Development tools are normally command line oriented. Some people have their favourite IDE tools like eclipse that they are free to use in conjunction with any command line oriented tool.

[Anykey]

Попытался скомпилировать тестовую прошивку.

#include <spectrum.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf ("Hello world!\n");
printf ("\nTHIS TEST ROM\n");
printf ("\n\n\nProgram end\n");
while (1){ };
}


Делаю: zcc +zx zloader.c -subtype=rom -lndos -create-app -ozloader.bin -lm

Компилятор выдает:
Error at file 'c:/z88dk//lib/spec_crt0.asm' line 481: syntax error
1 errors occurred during assembly
Key to filenames:
C:\Users\Sergey\AppData\Local\Temp\s670_.o = test.c
Error at file 'c:/z88dk//lib/spec_crt0.asm' line 481: syntax error
^ ---- IF !DEFINED_HAVESEED

Закоментировал в spec_crt0.asm
;IF !DEFINED_HAVESEED

После этого програмка откомпилировалась

Вставил полученную прошивку в ZXmak,
в первом знакоместе символы меняются,
но текст не выводит.


Что не так?

[Alcoholics Anonymous]

Hi Anykey,

Are you trying to create a binary destined for ROM?

The compile line you are using " zcc +zx zloader.c -subtype=rom -lndos -create-app -ozloader.bin -lm" is not using the new part of z88dk -- it is using the classic part of z88dk. The rom subtype is for making IF1 cartridges and will have ORG 0. It also may not work with some functionality because the classic library is not able to generate ROMs using certain parts of the library.


Especially if you are making a ROM, it is best to use the new c library in z88dk. It has been designed with generation of ROMs as one of its primary goals. I'd also suggest you get the latest nightly build instead of the version at sourceforge. z88dk is a very active project and there are quite a few changes since the last release. Of particular interest, if you are running on windows or mac osx, the nightly build comes with sdcc binaries that will allow you to compile using sdcc as well. z88dk's version of sdcc produces better code than sdcc does.

Details for installing z88dk can be found here:
http://www.z88dk.org/wiki/doku.php?id=temp:front#installation

There is a great deal of information on that page if you are comfortable with English. If I have understood you correctly and you want to create a ROM then of particular importance is this section that describes how code destined for ROM can be generated:
http://www.z88dk.org/wiki/doku.php?id=temp:front#crt_configuration


First I will show you how to compile a program destined for RAM using the new c library and sdcc. This is how most zx programs would be compiled:

zcc +zx -vn -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test

The output will be "test_CODE.bin" which is a binary that should be loaded at address 32768 and started with "RAND USR 32768". You will see below how the ORG can be changed. If you need to make a tap out of that, you can use appmake ("appmake +zx -b test_CODE.bin -o test.tap --org 32768 --blockname test").



Now I will show you how to make a ROM. You should use one of the CRTs designed for IF2 cartridges only because if you choose an ORG of 0, it will put the z80 restarts, im1 and nmi service routines in the correct places. If you choose an ORG that is not zero, those things will not be added.




#include <arch/zx.h>
#include <stdio.h>
#include <stdlib.h>

#pragma output CRT_ORG_CODE = 0
#pragma output CRT_ORG_DATA = 32768
#pragma output CRT_ORG_BSS = -1
#pragma output REGISTER_SP = 0


void main(void)
{
printf ("Hello world!\n");
printf ("\nTHIS TEST ROM\n");
printf ("\n\n\nProgram end\n");
while (1){ };
}



zcc +zx -vn -startup=32 -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test --list -m

"--list" will create asm files for each translated c file. "-m" will produce symbols. You can add "--opt-code-size" to make the output a little bit smaller; the code size will be significantly smaller if your program uses 64-bit integers. If you are not running the rom interrupt routine, use "clib=sdcc_iy" instead of "-clib=sdcc_ix --reserve-regs-iy" to reduce the program size further. To use sccz80 as compiler instead of sdcc, use "clib=new" instead of "-clib=sdcc_ix --reserve-regs-iy".

There will be three binary outputs: "test_CODE.bin", "test_DATA.bin" and "test_BSS.bin". The pragmas I put in the source code above choose some crt options. "CRT_ORG_CODE = 0" means code origin will be 0 (and the z80 restarts, im1, nmi will be included). "CRT_ORG_DATA = 32768" is where the initialized variables will be placed in RAM. "CRT_ORG_BSS = -1" means the zeroed variables will follow DATA in ram. To create the binary image, you must first compress the DATA section: "zx7 test_DATA.bin" and then append that to the code to generate the final binary: "copy /B test_CODE.bin+test_DATA.bin.zx7 test_OUT.bin" (windows). The final output "test_OUT.bin" is what should be loaded at address 0 and run from address 0. The crt will initialize the DATA section by decompressing its copy to address 32768 and it will then zero the BSS section before calling main.

"REGISTER_SP = 0" will cause the crt to set SP=0 so that the stack will grow downward from the top of memory. These values are the defaults for zx if2 cartridges.

One other thing: The heap will be initialized to occupy the space between the end of the BSS section and the bottom of the stack, giving the stack 512 bytes of space to grow. This behaviour and stack size can be changed with pragmas. In particular you can control the size of the heap with "#pragma output CLIB_MALLOC_HEAP_SIZE = 0". This zero value means don't create a heap but if you use a positive value > 14, a heap of that size will be created in the BSS section.

The zx if2 crts will restart the program on exit unless CRT_ENABLE_RESTART is set to 0.



I used "-startup=32" above. This chooses the 32-column driver for stdio. There are other choices "-startup=33" is the 32 column terminal with control codes. "-startup=36" is the 64 column terminal. "-startup=37" is the 64-column terminal with control codes. "-startup=40" is the fzx terminal with proportional fonts. "-startup=41" is the fzx terminal with control codes. "-startup=63" is no terminals.

You can also write your own crt to make windows on screen or change the behaviour on program exit.


z88dk's environment is quite sophisticated so there is a lot to know :) If you have questions, just ask. If you're wondering if you can do something the answer is yes you can :)

[Alcoholics Anonymous]

I will just quickly add that you can customize the library somewhat.

For the new c library, the library configuration for the zx is located in z88dk/libsrc/_DEVELOPMENT/target/zx/clib_cfg.asm (http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/target/zx/clib_cfg.asm?content-type=text%2Fplain). You can modify that to choose between fast library code or small library code.

In particular, you can opt out of individual printf and scanf converters. By default printf includes %duxonipsc,ld,lu,lx,lo,li,ln,lp and scanf includes %duxonipsc,ld,lu,lx,lo,li,ln,lp,[

If you don't need some of those converters, disabling them can reduce program size. If you need float or longlong converters, you will have to enable them.

Another thing you can do to reduce size is to get rid of the error strings by defining "defc __CLIB_OPT_ERROR = 0".

If you change this file you must rebuild the library by running "Winmake zx" (windows) or "make TARGET=zx" (non-windows) from the directory z88dk/libsrc/_DEVELOPMENT


The new C library's headers are beginning to be documented (http://www.z88dk.org/wiki/doku.php?id=temp:front#header_listing) but it is still very far from complete. You can also see available library functions by examining the headers directory (http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/include/_DEVELOPMENT/sdcc/).

[Anykey]

Hi Anykey,
Are you trying to create a binary destined for ROM?


Да, я пытался сделать ROM для Reverse-U16.
Искал, Си компилятор для Z80, а тут даже Speccy поддерживается.
Пока только начал разбираться ( В Си не очень силен ).

Еще вопрос, как к портам IO обращаться?
Можно ли как в PIC микроконтроллерах (или архитектуры разные)?

Можно ли произвольно задавать адрес и биты интерфейса SD-card?

[Alcoholics Anonymous]

Еще вопрос, как к портам IO обращаться?
Можно ли как в PIC микроконтроллерах (или архитектуры разные)?


sdcc calls i/o ports "special function registers". You can assign an sfr to each i/o port you need and then write or read from them as if they are regular variables:



__sfr __at 0x1f IO8; // 8-bit i/o port at 0x1f
__sfr __banked __at 0xfbfe IO16; // 16-bit i/o port at 0xfefe

void main(void)
{
volatile unsigned char a;

a = IO8; // read port IO8
IO8 = 100; // write port IO8

a = IO16; // read port IO16
IO16 = 200; // write port IO16
}


The translated asm "zcc +zx -vn -a -SO3 -clib=sdcc_iy --max-allocs-per-node200000 zzzz.c --c-code-in-asm"

(An issue was fixed today that affects this code; make sure you are running a nightly build from May 24 or later)



;zzzz.c:9: a = IO8; // read port IO8
in a,(_IO8)
ld (ix-1),a
;zzzz.c:10: IO8 = 100; // write port IO8
ld a,0x64
out (_IO8),a
;zzzz.c:12: a = IO16; // read port IO16
ld a,+((_IO16) / 256)
in a,(((_IO16) & 0xFF))
ld (ix-1),a
;zzzz.c:13: IO16 = 200; // write port IO16
ld a,0xc8
ld bc,_IO16
out (c),a


Unfortunately sdcc has a known bug when reading i/o ports into a global variable.

This:



__sfr __at 0x1f IO8; // 8-bit i/o port at 0x1f

volatile unsigned char a;

void main(void)
{
a = IO8; // read port IO8
}


Leads to a fatal compiler error. To read into a global variable you must read into a local first and then copy that local to the global.


You can also do port i/o through function calls, see z80.h (http://www.z88dk.org/wiki/doku.php?id=libnew:z80). All port i/o done through these function calls is 16-bit.



The z80 i/o space is 16-bits but usually the bottom 8-bits select a device and most devices operate decoding the bottom 8-bits only. However some devices will use the bottom 8 bits to identify themselves as i/o target and then the top 8 bits to select a particular register. The z80's 16-bit i/o instructions (inir, indr, otir, otdr) support that view.





Можно ли произвольно задавать адрес и биты интерфейса SD-card?

You can, but if you are making this for the zx you have to consider ports taken by the zx itself and its common peripherals. The basic zx spectrum has the ULA mapped to all even port addresses so you must avoid those for your device. Kempston joystick is at 0x1f, the sound chip at other address (0xbffd, 0xfffd) and the russian machines will have their own ports too. So you really have to try to pick i/o addresses that will not interfere with ones already used.

[Anykey]

You can, but if you are making this for the zx you have to consider ports taken by the zx itself and its common peripherals. The basic zx spectrum has the ULA mapped to all even port addresses so you must avoid those for your device. Kempston joystick is at 0x1f, the sound chip at other address (0xbffd, 0xfffd) and the russian machines will have their own ports too. So you really have to try to pick i/o addresses that will not interfere with ones already used.

Это я понимаю. Я про sdcard.h из библиотеки z88dk.
Как можно использовать эти функции, если у меня SD-card на другом порту?

[Alcoholics Anonymous]

Это я понимаю. Я про sdcard.h из библиотеки z88dk.
Как можно использовать эти функции, если у меня SD-card на другом порту?

Ah, now I understand. I did not port sdcard.h so I will have to ask how portable it is. It looks like the programmer is supposed to supply two functions that access the sd card hardware directly but there are a couple of places in the code that write that information into ram so there may be something else going on too. The other problem is sdcard.h is part of the classic c library and not the new c library and it's written such that ram variables are mixed with rom code so it will have to be redone for the new c library if it is to be used in a ROM environment. That's not hard to do and I don't mind doing it for you if it turns out to be suitable once I get some information from the other developers.

[Anykey]

Было бы здорово иметь возможность работы с SD card,
указав библиотеке к каким портам подключены MISO,MOSI,SCK и CS.
И использовать несколько функций, как проверка, инициализация,
получение информации о карте (File system, Size), чтение секторов,
каталога, файлов и запись.

[Alcoholics Anonymous]

Yes I agree you should be able to specify what ports are used and how and you should be able to instantiate more than one sd interface if there is more than one.

The code in the classic c lib is not completely ported yet. I believe the code came from OSCA and it was being modified to work with any i/o ports but after looking at it I think there is still a way to go to finish the job right.

If you want to play with it, I can rewrite it so that it is ROM friendly. If I have some time this weekend I may look more closely at it and dig up some sdcard ref materials.

[Alcoholics Anonymous]

Z88DK v1.99B Released at Sourceforge:
https://sourceforge.net/projects/z88dk/

It's been a year since the last release so it was time for another. This is another transitional release on the way to version 2.0 and hopefully we'll get there for the next one.

Some notes:

==========================
Z88DK - v1.99B 10 Jan 2017
==========================

Z88dk is a development kit for z80 computers that contains the tools and assembly language libraries necessary to develop code in either C or assembly language for z80-based machines.

Over 50 different z80 machines have CRTs in the toolkit, allowing C programs to be compiled for them out-of-the-box.

There are two C compilers supported (sccz80 and sdcc), two independent C libraries included (the classic and new), an assembler/linker/librarian (z80asm), and a data compression tool (zx7).

This is the second transition release in anticipation of v2.0.

Install Instructions:
https://www.z88dk.org/wiki/doku.php?id=temp:front#installation

Home Page:
https://www.z88dk.org/forum/
Includes link to the nightly builds.

Forum:
https://www.z88dk.org/forum/forums.php

Introduction to Compiling Using the Classic C Library:
https://www.z88dk.org/wiki/doku.php
Examples in z88dk/examples

Introduction to Compiling Using the New C Library:
https://www.z88dk.org/wiki/doku.php?id=temp:front
Examples in z88dk/libsrc/_DEVELOPMENT/EXAMPLES

Compiling for Generic z80 Embedded Systems Using the New C Library:
https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded


--8<----- list of changes below -----------------------


=======
PACKAGE
=======

* The win32 and osx packages are complete and now include the zsdcc & zsdcpp binaries. zsdcc is z88dk's customization of the sdcc compiler. Other users can compile zsdcc from source.

* A VS2015 solution file is now available in z88dk/win32 for building all z88dk binaries except zsdcc & zsdcpp. Instructions for building zsdcc & zsdcpp can be found in the install instructions link above.


========================
ZCC - Compiler Front End
========================

* M4 has been added as an optional macro pre-processor. Any filename ending with extension ".m4" will automatically be passed through M4 and its output written to the original source directory with the ".m4" extension stripped prior to further processing. The intention is to allow source files like "foo.c.m4", "foo.asm.m4", "foo.h.m4" and so on to be processed by M4 and then that result to be processed further according to the remaining file extension.

* In conjunction with the above, a collection of useful M4 macros has been started in "z88dk.m4" that can be included in any ".m4" file processed by zcc. Currently macros implementing for-loops and foreach-loops are defined.

* List files ending with extension ".lst" can be used to specify a list of source files for the current compile, one filename per line. The list file is specified on the compile line with prefix @ as in "@foo.lst". List files can contain any source files of any type understood by zcc and individual lines can be commented out with a leading semicolon. Paths of files listed in list files can be made relative to the list file itself (default) or relative to the directory where zcc was invoked (--listcwd). List files can list other list files, identified with leading '@'.

* zcc now processes all files it is given to the final output file type specified. For example, with "-E" specified, all listed .c files will be run through the C pre-processor individually and all output copied to the output directory. Previous to this, only the first file listed was processed unless a binary was being built.

* -v gives more information on what steps zcc takes to process each source file.

* -x now builds a library out of the source files listed.

* -c by itself will generate individual object files for each input source file. However, if -c is coupled with an output filename as in "-o name", a single consolidated object file will now be built instead of individual ones. The intention is to provide a means to generate identical code in separate compiles by allowing this single object file to be specified on different compile lines.

* Better error reporting for source files with unrecognized types.

* Better parsing for compile line pragmas; pragma integer parameters can now be in decimal, hexadecimal or octal.

* -pragma-include added to allow a list of compile time pragmas to be read from a file as in "-pragma-include:zpragma.inc". This way projects can consolidate pragmas in one location; this is especially important for the new c library which uses pragmas extensively to customize the crt.

* -pragma-export added, is similar to -pragma-define but the assembly label defined as a constant on the compile line is made public so that its value is visible across all source files.

* --list will generate ".lis" files for each source file in a compile to a binary. The ".lis" file is an assembly listing of source prior to input to the linker.

* --c-code-in-asm causes C code to be interspersed as comments in any generated assembly listing associated with C source files.

* ".s" files are now understood by zcc to be asz80-syntax assembly language source files. This allows sdcc project files written in assembly language to be assembled by z88dk. asz80 mnemonics are non-standard so zcc attempts to translate to standard zilog mnemonics before assembling. You can see the translation to standard zilog form by using "-a" on a compile line. This is still a work-in-progress feature.

* --no-crt allows compiles to proceed without using the library's supplied crt for a target. The first file listed on a compile line will stand in as the crt and will be responsible for initialization and setting up the memory map.

* Temporary files are always created in the temp directory. The option "-notemp" has been removed.

* Library and include search paths have been fixed to honour the order specified on the compile line. This allows the user to override library functions when desired.

* Source files are now processed from their original location so that includes can be properly resolved. Previously this was only done for .c files but this now applies to other file types.

* clang/llvm compilation is in an experimental state.

Known issues:

* Spaces in paths or filenames can be a problem.

* When --c-code-in-asm is active, unicode characters from .c source files appearing as comments in translated asm may cause the tools to crash.


==========================
SCCZ80 - Native C Compiler
==========================

* Correct floating point constant handling.

* New __SAVEFRAME__ function decorator to allow saving of ix during a function call.

* -standard-escape-chars to make \n and \r output standard character codes


========================================
ZSDCC - Customization of SDCC C Compiler
========================================

* Updated to SDCC 3.6.5 #9824.

* SDCC's native C pre-processor is now used so that line numbers corresponding to reported errors are accurate.

* Peephole-z80 fixed to accurately report registers affected by instructions, allowing accurate application of peephole rules.

* inSequence('stride' %1 %2 %3 ...) added as peephole rule qualifier to allow testing whether consecutive bytes in memory are being accessed.

* Peephole-z80 made aware of z88dk special functions which represent code inlined by the library.

* Approximately 300 new peephole rules added to the aggressive peephole set (-SO3).

* Peephole rules added to fix some known code generation bugs and to fix SDCC's critical sections for nmos processors.

* --opt-code-size now significantly reduces code size for programs using 32-bit longs, 64-bit longlongs and floats.

* chars have been made unsigned by default. Use --fsigned-char to change to signed.

* For loops can now declare variables in the initializer statement.

* An rodata section has been properly implemented so that all constant data generated by sdcc is assigned there.


=====================================
Z80ASM - Assembler, Linker, Librarian
=====================================

* Handle input files more predictably: link .o files; assemble any other extension; append a .asm or .o option to the file name to allow just the basename.

* Make a consolidated object file with -o and not -b: all the object modules are merged, the module local symbols are renamed <module>_<symbol>

* Link the library modules in the command line sequence (it was depth-first).

* Add directory of assembled file to the end the include path to allow includes relative to source location.

* Remove all generated files at start of assembly to remove files from previous runs.

* Remove deprecated directives: XREF and LIB (replaced by EXTERN), XDEF and XLIB (replaced by PUBLIC), OZ (keep CALL_OZ).

* Rename DEFL to DEFQ to reserve DEFL for macro variables; rename DS.L by DS.Q

* Constants for section sizes: prune empty sections, rename ASMHEAD, ASMTAIL and ASMSIZE to __head, __tail and __size respectively, rename ASM<HEAD|TAIL|SIZE>_<section_name> to __<section_name>_<head|tail|size>

* Environment variables no longer used: Z80_OZFILES, Z80_STDLIB

* Command line option -r, --origin: accept origin in decimal or hexadecimal with '0x' or '$' prefix

* Command line options: -i, -x: require a library name

* Command line options: remove -RCMX000, keep only --RCMX000

* Command line options: remove -plus, keep only --ti83plus

* Command line options: remove -IXIY and --swap-ix-iy, keep --IXIY

* Command line options: remove --sdcc, -nm, --no-map, -ng, --no-globaldef, -ns, --no-symtable, -nv, --no-verbose, -nl, --no-list, -nb, --no-make-bin, -nd, --no-date-stamp, -a, --make-updated-bin, -e, --asm-ext, -M, --obj-ext, -t

* Make symbol files, map files and reloc files optional; do not merge symbols in the list file; do not paginate and cross-reference symbols in list file; rename list file to file.lis (@file.lst is used as project list)

* Unify format used in map files, symbol files and global define files, output list of symbols only once.

* Include symbols computed at link time in the global define file.

* Simplify output of --verbose


================================================== =========
APPMAKE - Processes Output Binaries to Target Suitable Form
================================================== =========

* +rom can now generate binaries for ROM chips mapped into a specific address range.

* +sms now generates bankswitched .sms files as output.

* +zx now has option to generate headerless .tap files.

* Appmake now understands three compile models -- ram (destined for ram, no stored data section), rom (destined for rom, stored data section is a copy) and compressed rom (destined from rom, stored data section is compressed) -- and will form output files accordingly.


=================
CLASSIC C LIBRARY
=================

* SDCC can now be used to compile using the classic library.

* Rewritten and modular printf core, added (v)snprintf.

* Rewritten and modular scanf core.

* Ports are now section aware.

* Support for compressed data section model.

* Support for copied data section model.

* User overridable fputc_cons.

* New target: Microbee. Support for various GFX modes and 1 bit sound.

* New target: Robotron kc. Support for various GFX modes and 1 bit sound.

* New target: z1013. Support for various GFX modes and 1 bit sound.

* New target: z9001. Support for various GFX modes and 1 bit sound.

* CP/M Plus on Spectrum.

* CP/M extenstions forced to upper case.

* CP/M extensions improved on Aussie Byte, trs-80 and Epson PX.

* GFX Library: improved the vector rendering functions, now bigger pictures can be drawn and higher resolutions are supported. Various fixes.

* Custom text configuration (font, resolution) can be done at compile time for targets with ansi VT support on graphics display.


=============
NEW C LIBRARY
=============

* 64-bit integers are now fully supported in the library.

* The fprintf/fscanf cores can now have conversion specifiers individually enabled or disabled at compile time. This allows the printf/scanf cores to be tailored to the minimum size required.

* fprintf %aefg precision formatting corrected.

* Intrinsics have been introduced as a method to inline assembly code without disturbing optimization. This provides a means to insert assembly labels (whose addresses will appear in map files), simple assembly instructions such as "di" and "ei", and atomic loads/stores into C code without affecting the compiler's optimizer. See https://www.z88dk.org/wiki/doku.php?id=libnew:intrinsic

* The library has had a preserves_registers attribute attached to every function that informs sdcc which registers will not be affected by a library call and allows sdcc to generate better code around library calls.

* aplib added as another data decompression utility.

* setjmp/longjmp state increased to include the value of IY for sdcc compiles. This was necessary as sdcc sometimes requires the value of IY to be preserved at points in the program.

* New target: rc2014 (preliminary). This target is still being developed by rc2014 users.

* New target: Sega Master System. The target is able to automatically create bankswitched rom cartridges with signatures.

* ZX Spectrum target: interfaces to the bifrost and nirvana multicolour sprite engines added.

* The CRT startup code has been made more flexible, allowing a wide range of features to be selected via pragmas at compile time. See https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#crt_configurati on

[Alcoholics Anonymous]

Source code migration to github.

Following the 1.99B release we've migrated the source code from CVS to git. The new location for repositories is http://github.com/z88dk
Moving to git should increase visibility and make it easier for us to perform a long overdue restructuring of the code tree.

The only things we're now using on Sourceforge are:

* File releases
* Mailing lists