z88dk forums

The if tree that first splits it by above or below 0x80, then 0x40, then 0x20, and so on definitely gave a solid performance increase (3.25X). I'm writing an i4004 emulator and testing it under CP/M, DOS, and WIN32. Here are some performance benchmarks. 0.95 used switch, 0.96 uses the if array metho...

The cast only pushed it into a different method of check and jmp where it iterates a list of values and addresses to determine what to jump to. Is there a jump table capability for z80 and/or 8080 with the instructions available? I'm going to try a binary style if array to split the options down (8 ...

So casting the switch to an unsigned short will force a jump table then?

I've got an emulation project with a large switch for opcodes that is switching near 256 ways for an unsigned char. I build it both ways (z80) and (8080) and I noticed that it doesn't build a jump table and instead builds a long stream of: 240 04d6 cad709 jp z,i_42 ; 240 04d9 fe01 cp +(1% 256) 240 0...

Downloaded the latest nightly; it compiles great now. Thanks dom and stefano!

Is the nightly server down?

I've got 256 cases alright. The secondary switches within the first one aren't so big (maybe 6-7 cases), so maybe pushing 256 up to 512 would cover things well if that isn't detrimental. I only need 256 in the "parent" switch.

>i4004.c:427:21: error: Too many cases

Is there a way to make a switch work within a switch?

Well done dom!!!

I downloaded the 3 changed files and tested them and they work great - good work dom! Also, I tested both the CP/M player and SIMH running real CP/M with the -pragma-define:CPM_WRITE_EMPTY_RECORD=0 option and it ALSO works great and produces the same output files, so writing that empty record may no...

I see the changes at - looks great. Will try tomorrow when a new nightly goes up.
https://github.com/z88dk/z88dk/commit/d ... diff=split

Awesome; did you change what you expected to change? I'll download the nightly tonight (unless it is already up - let me know) and try it.

If I bypass using fseek(file, 0, SEEK_END) and ftell() to get the end of the file, but instead get the file size when opening it and then store it in a long variable that is updated anytime a write is done to expand it, this does solve the problem and CP/M produces the same output files. I say all t...

Here is a CP/M com file that produces 3 files. Here is a run using the CP/M player (not real CP/M 2.2) C:\1z88>del *.dat C:\1z88>cpm 1 starting pagetest pf1 construct CF_Construct fc9a CF_Open fc9a test.dat 1 CF_closefile fc9a CF_Open result CF_NOERROR open CF_NOERROR is opened 1 CF_GetFileLengthPag...

Sure thing: i build with: zcc +cpm -DAMALLOC -O3 %1 -m --opt-code-speed=inlineints unit1.c -o1.com #include <string.h> #include <alloc.h> #include <stdio.h> #include <cpm.h> unsigned char *buffer; int main(/*int argc, char* argv[]*/) { FILE *file; int i1; long l1; //starting printf("starting\n&...

I agree. It should only affect fseek if it is seeking from whence SEEK_END. I suppose the idea of keeping track of the length wouldn't work for shared file access (MP/M maybe?). I also misunderstood that fflush only flushes the C runtime buffers, it doesn't necessarily do a operating system level sy...

ALSO - I would also think that fflush needs to essentially do a BDOS close followed by an open operation to make sure that directory information is written to the disk.

Also, I don't envy the challenge that this has been dom - writing C runtime filesystem functions are much easier with an API that does the buffering and supports byte level operations such as MS-DOS. Add to that the nuance of text mode and binary mode and it is difficult because you are asking the C...

Hi dom! I've been doing my testing using a program called CP/M player which is great, but I've found a difference between it and real CP/M. Running the program under a more real CP/M emulator actually running CP/M code instead of virtualizing it shows an issue which is this: The computer file size B...

Thanks dom; I tried last night's build and 8080 fflush is fixed now!

Great work dom; fflush works beautifully now!

Can you also fix fflush for clib=8080 as well when you have time?

I tried the build from last night and no change in fflush behavior. Let me know if something changes on it and I'll retest.

It looks like the -pragma-define:CPM_WRITE_EMPTY_RECORD=0 does cause a problem. In the first writebytes, it writes 4 bytes at position 128 which should add another sector - but presumably it goes into the cache and isn't written to the file yet. This could be why when it tries to position to the end...

To use the pragma, I would do this, right?

zcc +cpm -pragma-define:CPM_WRITE_EMPTY_RECORD=0 -DAMALLOC -O3 %1 -m --opt-code-speed=inlineints cfile.c cstatefl.c unit1.c -o1.com

I think you've uncovered the behaviour of the CP/M cache that I put in a couple of years ago for you! Indeed; I was thinking the same thing! 1. I don't know why I did that initial write, maybe it was so that read+write files behave sensibly and that there actually is an soft EOF on disc for when th...