1 (edited by Luzie 2017-09-16 22:25:49)

Topic: Someone can do a .LOADBIN command for me?

Hi,

can anyone do a .LOADBIN command for me?

I need something which can LOAD in binary into desired memory-regions.

Should load in any file(type) from memory-card and optional with a Len to truncate loaded Bytes.

esxDOS +3 command
LOAD *"filename.scr"CODE 16384,6912
can already do this and e.g. loads first 6912 Bytes from a file (which can .txt, .scr or .xxx)
into screen-memory. If file is longer, it truncates loading of the Bytes > 6912.

The .LOADBIN should be used for showing screenshots in the new NMI.SYS-Handler described here:
http://board.esxdos.org/viewtopic.php?pid=367#p367
http://board.esxdos.org/viewtopic.php?id=94

2 (edited by Alcoholics Anonymous 2017-09-17 03:39:10)

Re: Someone can do a .LOADBIN command for me?

esxDOS +3 command
LOAD *"filename.scr"CODE 16384,6912

Luzie this operates on a tap file container.  Are you looking for something that extracts from files inside tap containers or for something that extracts from actual files on disk?

For actual files, what about something more general like a .EXTRACT?

.extract input_filename [+offset] len [-f] [-o output_filename] [-m address]
extract len bytes at offset from input file

+offset (optional), default is 0
start extraction at "offset bytes", example "+16384"

-f (optional), overwrite output file without asking if it exists
use in combination with -o

-o outname (optional), copy extracted bytes to another file
if file exists, ask to overwrite or append

-m address (optional), copy extracted bytes to memory address
may clobber basic and cause crash on return

-o and -m can both be present

If neither -o or -m, print a hexdump on screen.


Your specific case of copying a screen$ out of a file at offset 0 (maybe it's an sna?):

.extract game.sna 6912 -m 16384

3 (edited by Luzie 2017-09-17 09:52:46)

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

esxDOS +3 command
LOAD *"filename.scr"CODE 16384,6912

Luzie this operates on a tap file container.  Are you looking for something that extracts from files inside tap containers or for something that extracts from actual files on disk?

For actual files, what about something more general like a .EXTRACT?
...
Your specific case of copying a screen$ out of a file at offset 0 (maybe it's an sna?):

.extract game.sna 6912 -m 16384

Hi Alcoholics Anonymous,

I haven´t noticed on my tests with

esxDOS +3 command
LOAD *"filename.scr"CODE 16384,6912

that this treats the input file as a .TAP-container. So you mean loading this .SCR-File leaves out some "Header-Bytes"?

If it is so,  a DOT-command .EXTRACT as you described, will be a flexible utility where we can skip loading of those .TAP-Header-Bytes with the offset-Parameter.

.EXTRACT will be very welcome. Can you program such a thing?

Regards,

Luzie

4

Re: Someone can do a .LOADBIN command for me?

Luzie wrote:

I haven´t noticed on my tests with

esxDOS +3 command
LOAD *"filename.scr"CODE 16384,6912

that this treats the input file as a .TAP-container. So you mean loading this .SCR-File leaves out some "Header-Bytes"?

Maybe I am wrong about that and LOAD* can go straight to disk if a tap file is not mounted first.  In any case, there is a different use-case which would work within container files like .tap - you would probably want to say "extract these bytes from this file inside this tap" - so an extension of this tool or another one could probably be done to allow that more easily.  You can always extract from a .tap file but finding the offset to the particular save you want in there is not straightforward.

.EXTRACT will be very welcome. Can you program such a thing?

Yes I can do it fairly quickly.  It gives me something to test the c compiler with smile

5

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

Maybe I am wrong about that and LOAD* can go straight to disk if a tap file is not mounted first.

LOAD/SAVE * will always work on active drive (they never access the mounted .tap files). The files created by the SAVE command have a +3DOS header.

6 (edited by Alcoholics Anonymous 2017-09-19 04:13:32)

Re: Someone can do a .LOADBIN command for me?

I had some time this evening so here it is in the extract directory:
https://drive.google.com/file/d/0B6XhJJ … sp=sharing

Extract bytes from a file :-

.extract file [+off][-off][len]
 [-f] [-o outfile] [-a outfile]
 [-p byte] [-m address]

input:
  file = input filename
  +off = byte offset from start
  -off = byte offset from end
   len = length in bytes

output:
  -f = overwrite permitted
  -p = pad if input < len
  -o = write to output file
  -a = append to output file
  -m = copy to memory address

no -o,-a,-m generates hexdump

For input,

Specify the input file, optionally the initial byte offset into the file (- = from the end of the file) and optionally the length in bytes (default is to the end of the file)

For output,

-a outfile to append to an existing file *****
-o outfile to create a new file
-f to allow overwriting an existing file with -o
-m address to send bytes to the memory address
(padding is disabled atm)

If there is no -a,-o,-m then a hexdump is done instead.
All numbers can be hex, decimal or octal.

Examples:

;; load screen$ from an sna
.extract game.sna +27 6912 -m 0x4000

;; have a look at the sna header in a hexdump
.extract game.sna 27

;; copy the last 100 bytes to a file
.extract readme.txt -100 -o tail.txt

;; see a hexdump
.extract somebin.bin

****  I cannot test append because the emulators do not fully emulate esxdos.
Because I can only test on emulators, you should do some testing of your own to make sure things work.


Jim Bagley posted that there is a bug in esxdos that does not allow seeks to occur unless a previous read or write has happened.  So int he code I am doing things like this:

esxdos_f_read(fout, buffer, 1);   // reported bug: esxdos cannot seek unless r/w has occurred first
esxdos_f_seek(fout, st.size, ESXDOS_SEEK_SET);

so that a file is opened, 1 byte is read, and then the seek to wanted position happens.

7

Re: Someone can do a .LOADBIN command for me?

lordcoxis wrote:

LOAD/SAVE * will always work on active drive (they never access the mounted .tap files). The files created by the SAVE command have a +3DOS header.

Ok I think I've got it now.  If a tape is mounted, then a plain LOAD/SAVE goes to the .tap file but if there is no tape mounted, then LOAD/SAVE goes to tape?

8

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

Ok I think I've got it now.  If a tape is mounted, then a plain LOAD/SAVE goes to the .tap file but if there is no tape mounted, then LOAD/SAVE goes to tape?

Yes, but there are individual save/load slots - so you can load from real tape and save to .tap for instance.

9 (edited by Luzie 2017-10-04 19:17:01)

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

****  I cannot test append because the emulators do not fully emulate esxdos.
Because I can only test on emulators, you should do some testing of your own to make sure things work.

Thank you very much for your work. I need some additional information:
1) Which esxDOS version do you use? 0.85 or 0.86? I use e.g. 0.86Beta4 (=latest version here from this forum).
2) Which emulators do you use to test?
3) Which emulated machine do you try (128k or 48k Spectrum or TBBLUE?)

Yet my short tests give these results:
A) Emu SpecEmu with divIDE and esxDOS 0.86B4 (Speccy 48k or 128k) => .EXTRACT (without parameters) crashes/resets Spectrum
B) Hardware divMMC and esxDOS 0.86B4 (Speccy 48k) => .EXTRACT (without params) crashes/resets Spectrum
C) Emu ZEsarUX with divMMC and esxDOS 0.85 (Speccy 48k or 128k) => .EXTRACT shows help and when
e.g. tried: ".EXTRACT LAYOUT.SCR 6144 -m 16384" seems to work, but I have to try further.
One problem I discovered: If I run e.g. ".EXTRACT 1234" and file 1234 don´t exist, .EXTRACT displays "5: Can´t open input file 1234, 0:1" and then .EXTRACT crashes/resets Spectrum or on other tries it directly crashes/resets Spectrum.

Maybe an memory-issue? (You know about max 7k mem limitation for DOT-commands ?)

Could you please add display of a version number in Help-Text of .extract?

Update: I see in the C source of .EXTRACT that you maybe compile to "Spectrum Next" (+zxn)?, so I think you test with Emu ZEsarUX  and MMC esxDOS 0.86-Image which is included in ZEsarUX? Here (as I´ve yet tested) .EXTRACT seem to run fine without Spectrum-Resets.

Could you eventually make a smaller version .VIEWSCR which just loads in first (max.) 6912 Bytes from a given filename (all extensions/formats) into Screenmemory from 16384 (without offset)? This can be used as addon for new NMI-Handler for viewing Screens: http://board.esxdos.org/viewtopic.php?id=94
--> Update: New NMI.SYS-Author seems to have implemented a View-Screen himself, so this is not needed anymore (only if you like).

Regards,

Luzie

10

Re: Someone can do a .LOADBIN command for me?

Thanks for testing Luzie.

I don't get any crashes under emulation.  I'm running the latest released ZEsarUX binary on windows emulating TBBlue.  It looks to be esxdos 0.8.6-divmmc.

I think it's very likely this is a memory size issue.  The binary comes to 7419 bytes - I know about the limit but I'm not sure where it is exactly so I keep pushing until it doesn't work under emulation.  I haven't tried to reduce the size yet so I'll try that and we can see if that works.

For nmi.sys, it's probably better if he does the view screen as he's done.  As a separate utility, extract will be much more useful and will have viewscr behaviour as a subset.

11 (edited by Alcoholics Anonymous 2017-09-25 14:00:10)

Re: Someone can do a .LOADBIN command for me?

Hi Luzie,

I got around to updating the zip.  Look inside the extract folder:
https://drive.google.com/file/d/0B6XhJJ … sp=sharing

The readme:

Copy EXTRACT to BIN directory on sd card

At the basic prompt ".extract" will print help.

Read information under input and output to
understand how data is gathered from the input
file and written to the output file.

If there is no output file specified and there
is no destination memory address specified,
a hexdump will be printed to screen.  You
can specify -m and either -o or -a at the same
time.  -f allows existing files to be overwritten
when combined with -o.  An unspecified len for
the input will normally imply "to the end of file".

EXAMPLES:

1. Display stored screen from an sna file:

.extract knight.sna +27 6912 -m 0x4000

2. Have a look at the sna header as a hexdump:

.extract knight.sna 27

3. Copy the last 1024 bytes of a file to another file:

.extract knight.sna -1024 -o knight.bin

Again:

.extract knight.sna -1024 -o knight.bin

should fail.

This allows overwrite and should succeed:

.extract knight.sna -1024 -f -o knight.bin

4. Append file to another one.

.extract knight.sna -a foo.bin

Again:

.extract knight.sna -a foo.bin

should result in foo.bin being twice the size of knight.sna

A zx-next specific version will be added soon that adds a "-ml" option to load into the next's 208 8k pages.

12

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

Hi Luzie,

I got around to updating the zip.  Look inside the extract folder:
https://drive.google.com/file/d/0B6XhJJ … sp=sharing

Hi, thank you very much! I´ll test this .EXTRACT v1.0 and write back with the results I get.

13 (edited by Luzie 2017-10-04 19:16:31)

Re: Someone can do a .LOADBIN command for me?

Sorry, had not yet found time to test .EXTRACT v1.0 further / on real hardware.

But maybe we can focus to look at this problem:

Luzie wrote:

One problem I discovered: If I run e.g. ".EXTRACT 1234" and file 1234 don´t exist, .EXTRACT displays "5: Can´t open input file 1234, 0:1" and then .EXTRACT crashes/resets Spectrum or on other tries it directly crashes/resets Spectrum.

which I get under ZEsarUX with divMMC esxDOS 0.8.5, Spectrum 48k?

14

Re: Someone can do a .LOADBIN command for me?

Luzie wrote:
Luzie wrote:

One problem I discovered: If I run e.g. ".EXTRACT 1234" and file 1234 don´t exist, .EXTRACT displays "5: Can´t open input file 1234, 0:1" and then .EXTRACT crashes/resets Spectrum or on other tries it directly crashes/resets Spectrum.

which I get under ZEsarUX with divMMC esxDOS 0.8.5, Spectrum 48k?

Unfortunately I can't seem to persuade zesarux to emulate divmmc on a 48k spectrum.  I'll have to keep trying.
Does the crash still occur?  I think all problems were related to binary size and that's been reduced now.

15 (edited by Luzie 2017-10-21 19:11:53)

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:
Luzie wrote:
Luzie wrote:

One problem I discovered: If I run e.g. ".EXTRACT 1234" and file 1234 don´t exist, .EXTRACT displays "5: Can´t open input file 1234, 0:1" and then .EXTRACT crashes/resets Spectrum or on other tries it directly crashes/resets Spectrum.

which I get under ZEsarUX with divMMC esxDOS 0.8.5, Spectrum 48k?

Unfortunately I can't seem to persuade zesarux to emulate divmmc on a 48k spectrum.  I'll have to keep trying.
Does the crash still occur?  I think all problems were related to binary size and that's been reduced now.

Now I found some minutes to test on real hardware:

divIDE Interface, esxDOS 0.8.5, Spectrum 128k (Toastrack): Crash still occurs as described above (if file to open is missing)
divIDE Interface, esxDOS 0.8.5, Spectrum 128k +2 (Grey): Crash still occurs as described above (if file to open is missing)

divMMC Interface, esxDOS 0.8.6B4, Spectrum 128k (Toastrack): Crashes/Resets Spectrum directly after sending .EXTRACT
divMMC Interface, esxDOS 0.8.6B4, Spectrum 128k +2 (Grey): Crashes/Resets Spectrum directly after sending .EXTRACT

16 (edited by Alcoholics Anonymous 2017-10-24 12:39:11)

Re: Someone can do a .LOADBIN command for me?

Thanks Luzie.  I found something:  I am calling $1601 in the rom to make sure channel 2 is open for printing but that is not supported in the esxdos rom.  I thought it was ok because it was working in emulation.

So I've done a quick rebuild without that to see if it works:
https://drive.google.com/file/d/0B6XhJJ … sp=sharing

Go to the extract subdirectory and use the plain "EXTRACT" file.  This is a zx next compile so stay away from the -ml option which loads into the extra memory of the next.

17 (edited by Luzie 2017-10-24 16:28:49)

Re: Someone can do a .LOADBIN command for me?

Alcoholics Anonymous wrote:

Thanks Luzie.  I found something:  I am calling $1601 in the rom to make sure channel 2 is open for printing but that is not supported in the esxdos rom.  I thought it was ok because it was working in emulation.

So I've done a quick rebuild without that to see if it works:
https://drive.google.com/file/d/0B6XhJJ … sp=sharing

Go to the extract subdirectory and use the plain "EXTRACT" file.  This is a zx next compile so stay away from the -ml option which loads into the extra memory of the next.

I tried all version from the download:
23.10.2017  20:37             6.922 EXTRACT
25.09.2017  14:54             6.510 EXTRACT-ZX       -> I renamed this to: EXZX
25.09.2017  14:54             6.901 EXTRACT-ZXN     -> I renamed this to: EXZXN
24.10.2017  06:40             6.947 EXTRACT2

Results on real hardware:

.EXTRACT & .EXTRACT2 (both show "extract v1.0 zx-next z88dk.org"):
divMMC Interface, esxDOS 0.8.6B4, Spectrum 128k +2 (Grey): Seems to work OK!
=========================================================
.EXZX & .EXZXN: (First shows "extract v1.0 spectrum z88dk.org", second shows: "extract v1.0 zx-next z88dk.org"):
divMMC Interface, esxDOS 0.8.6B4, Spectrum 128k +2 (Grey): Crashes/Resets Spectrum directly after sending .EXTRACT

.EXTRACT & .EXTRACT2 (both show "extract v1.0 zx-next z88dk.org"):
and
.EXZX & .EXZXN: (First shows "extract v1.0 spectrum z88dk.org", second shows: "extract v1.0 zx-next z88dk.org"):
all four EXTRACT-versions on divIDE Interface, esxDOS 0.8.5, Spectrum 128k +2 (Grey):
=============================================================
Crash still occurs as described above (if file to open is missing show File-Open-Error, next press of ENTER resets Spectrum)

Please update version number with each change, this will be lots easier to handle :-)

18

Re: Someone can do a .LOADBIN command for me?

Thanks Luzie.  "EXTRACT" and "EXTRACT2" are the only ones updated to remove the rom call and it seems they now work - the others will still have the same problems.  "EXTRACT2" is only different in that it also prints the error message to screen instead of relying on esxdos to print it in the lower part because this is being used on the Next for testing where the error messages are not currently printed by the system.

I'll have to update all the dot commands I've written and I think I will make one more pass to improve them at the same time.

.EXTRACT & .EXTRACT2 (both show "extract v1.0 zx-next z88dk.org"):
and
.EXZX & .EXZXN: (First shows "extract v1.0 spectrum z88dk.org", second shows: "extract v1.0 zx-next z88dk.org"):
all four EXTRACT-versions on divIDE Interface, esxDOS 0.8.5, Spectrum 128k +2 (Grey):
=============================================================
Crash still occurs as described above (if file to open is missing show File-Open-Error, next press of ENTER resets Spectrum)

So the crash still occurs with EXTRACT but only with esxdos 0.8.5?  There must be an api difference from 0.8.6 - the notes I have are for the latter I think.