Any type of file IO causes errors with submit.com about z88dk HOT 15 CLOSED

I vaguely remember that submit uses the same cp/m feature I've found in this exec() implementation.

https://github.com/z88dk/z88dk/blob/master/libsrc/target/cpm/cpm/execl.asm

At boot time the cp/m system looks at a specific memory zone to decide whether to execute a command or jump straight to the prompt.

from z88dk.

Wondering if this functionally is the same as https://github.com/agn453/HI-TECH-Z80-C/blob/master/cpm/EXECL.AS? As I mentioned above submit.com works fine for programs compiled with HTC 3.09.

from z88dk.

Digging around, we always do a CP/M 2.2 style exit of jp 0. Looking through at this: https://github.com/agn453/HI-TECH-Z80-C/blob/master/cpm/_EXIT.AS it looks like HTC detects CP/M 3 and exits differently.

And I think CP/M for the c128 is v3?

I don't think it fully explains why file operations triggers. it though.

from z88dk.

Correct, C128 is using CP/M Plus (3.0). I suspect I cannot be the only one running CP/M Plus? Or trying to use submit on my own code? In any event, it would make sense to detect CP/M version and exit accordingly?

This may also explain why CP/M 3 BDOS constants are not defined in cpm.h like https://github.com/agn453/HI-TECH-Z80-C/blob/master/dist/CPM.H (i.e. you are sticking with 2.2?). I doubt anyone is using CP/M 2.x on C128. I don't think they ever released one.

from z88dk.

Correct, C128 is using CP/M Plus (3.0). I suspect I cannot be the only one running CP/M Plus? Or trying to use submit on my own code? In any event, it would make sense to detect CP/M version and exit accordingly?

Outside of the Amstrad & ZX +3 machines, I've not seen it much. I suspect this is an artefact of both machine age and (more likely) the relative complexity of getting CP/M 3 up and running. Even modern machines such as the rc2014 and Agon Light use 2.2

Regardless, with proper detection there's no reason not to use features (beyond the testing effort).

However, although I'm flying a bit blind, I have pushed a change to exit in the same way as HTC. Hopefully that solves it, if not I'll setup a z80pack environment.

from z88dk.

Oh I get it, but even MyZ80 had CP/M plus (ZPM3). It was the modern CP/M back in the day, thus why it was only ported to the Amstrad PCW, the ZX Spectrum +3, the Commodore 128, MSX machines and the Radio Shack TRS-80 Model 4. Even if you just fix the exit points it will allow CP/M 3 targets to work properly. I don't mind testing as I have time. I'm trying to port over a rather complex API to Z88DK, so I'm sure I'll run into all kinds of stuff.

from z88dk.

OK, I tested this commit and it runs first command, you see the second command then it hangs.

from z88dk.

Ok. I guess that’s a slight improvement!

I‘ll sort out an emulator and debug.

One quick question - are you using -subtype=c128?

from z88dk.

Does the cpm target actually have a c128 subtype? The config file doesn't show it, if it does.

And the c128 target config file doesn't seem to have a cpm subtype either... so perhaps it is not so straightforward?

from z88dk.

I'm using +cpm https://github.com/sgjava/c3lz/blob/a887e8b703d535db12190f006f24176643ae9bef/scripts/build.sh#L30 and most things are working. The exceptions seem any type of file IO, BDOS calls and malloc combo then weird things can happen. Technically CP/M 3.0 supports CP/M 2.2 programs, so even if the cpm+ target generated CP/M 2.2 code it should work. In HTC 3.09 all these things worked, but like you said they also added some CP/M 3 specific code.

Be interesting to see if you can see the same behavior in emulator.

Cannot find definition for target -subtype=c128

from z88dk.

I forgot the golden rule.

The golden rule is "it's always the stack"

By default we don't change the stack pointer, so just use whatever we're given. It looks like for CP/M 3 we need to add this option -pragma-define:REGISTER_SP=-6 which will set the stack point to just below BDOS.

That seems to work for me in z80pack, so if it works for you I'll add it by default.

from z88dk.

Basically the same thing. With one program I have a linked lisk built using malloc. If I just use bdos calls to get dir it works fine. If I open file for rb and wb it corrupts the heap because it messes with the next and prev node pointers in the list. I even played around with setting #pragma output REGISTER_SP = 0xa000 knowing it should at least work until something is written there. With HTC the heap builds from the bottom of the program to the top of the TPA. I know the stack works backwards, but not sure of the default address.

from z88dk.

Okay, cool. I wasn't testing any file ops, just re-running "hello world" from a submit file.

However, I've just tried with your baseline.c and that runs through submit ok, as well as a modification that does a strdup before opening and reading the file - can you point me to the code of the offending program?

There's only so many ways to arrange the memory - both HTC and z88dk do/will do the same thing, sp = &bdos, heap = &_tail_bss. The AMALLOC macros just reserve a portion of the memory between those two points for the heap in z88dk.

from z88dk.

You are correct, I changed baseline.c https://github.com/sgjava/c3lz/blob/main/src/demo/baseline.c and it works with submit now. I doubt you can run https://github.com/sgjava/c3lz/blob/main/src/demo/convpcm.c since it does have C128 only code in it for timing. I'll make baseline.c to do the same thing and see where it breaks. Open a file for read and write.

from z88dk.

@suborb I believe you found the root cause submit.com lockup (SP). I have a test case for the file write hang. I'll open up a new issue for that, so this issue doesn't get confusing.

New issue #2503

from z88dk.