fichier TAP créé par osk qui bloque

[Godzil]

Hu?

The Oric store the address in the reverse way (and in big endian ) ?

End then Start?

Funny

Anyway good spot Symoon, can't expect less from the Oric tape expert

[Symoon]

Anyway good spot Symoon, can't expect less from the Oric tape expert

Thanks - it's a classical.
The size of a program is: end address - start address + 1.

Guys, if not already done, before investigating Oricutron or Tap2dsk, check first the TAP conversion tool you are using

[christian]

@Symoon the file was created with Oricutron 1.1, same with Euphoric, as said in my previous post, not with some tools.

---

Le dump est celui d'un fichier généré par Oricutron 1.1, Euphoric génère le même, comme indiqué dans mon post et non avec un utilitaire quelconque.

[Symoon]

@Christian sorry I must have misread. So if the 55 is not what you call a "dummy byte" (that you added yourself), the file is correct.
Re-reading, now I understand you corrected the "bin2tap tool" you were taliking about, so it now calculates the end address correctly, avoiding to have to add a byte

As for the initial problem, the example file having vanished, I can't help there!

[christian]

You're right it's an issue with the bin2tap tool and the fact that Euphoric and Oricutron handles the EOF differently.

The 55 is still what I call a dummy byte in case of a BASIC program because it's behind the last null byte and so not part of the program.
I think the end address should be 50F and not 510, but it's the way Oric does...

So, to create a BASIC tape file identical to one created by CSAVE, a bas2tap tool must compute the end address as:
End address = Start address + program length +1 (and add a dummy byte at the end of the file)

But, a bin2tap can compute:
End address = Start address + program length -1

[Dbug]

The 55 is just what the memory is initialized with, the famous UUUUUUUUUUUUUUUUUUUUU when the data are corrupted.

I wish the ROM designed had chose START + LENGHT instead of this retarded END + START, would have made things so much easier.

Quiz: What are the values of START and END for a zero byte long program?

[Symoon]

Aaaah ok, got it now! You are refering at the Basic program length, I was only considering the memory area saved.
Strange indeed.

I just made a test and Csaved a basic program, removed the last byte and changed the end address: it loads fine in both Oricutron and Euphoric - and runs fine (which means, if I'm not mistaken again, that a tool can "only" save the real data and the correct end address, it works, would it be basic or not).

[christian]

I made the same test and the program run but if I do LIST after the RUN, the end of the program is something like:

Code: Select all

20145 UUUUUUUUUUUUUUUUUUUUUUUUUUUU

I don't know why

A zero length BASIC program is:

Code: Select all

00000000  16 16 16 16 24 ff ff 00  00 05 03 05 01 ff 56 49  |....$.........VI|
00000010  44 45 00 00 00 55                                 |DE...U|

And a 1 byte (CSAVE "EMPTY",A#501,E#501):

Code: Select all

00000000  16 16 16 16 24 ff ff 80  00 05 01 05 01 ff 45 4d  |....$.........EM|
00000010  50 54 59 00 00                                    |PTY..|

You can test with others start and end address like something in screen's ram to see that it can be loaded without any issue.

[Symoon]

I made the same test and the program run but if I do LIST after the RUN, the end of the program is something like:

Code: Select all

20145 UUUUUUUUUUUUUUUUUUUUUUUUUUUU

I don't know why

Strange, I made the test again (Cload, list, run, list), with Euphoric and Oricutron, both with ROM1.0 and ROM1.1 (so, four tests), and I had no problem.

[Chema]

Are you using the same Oricutron's build and OS? One never knows...

[christian]

I made more tests.

Works fine:

Code: Select all

10 PRINT "TEST"

But:

Code: Select all

10 A$="TEST"

CLOAD, LIST => OK
RUN => ?SYNTAX ERROR IN 1152
LIST

Code: Select all

10 A$="TEST"
1152
21845 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Oricutron 1.1 (Linux) with ROM 1.0 and ROM 1.1 (same with Euphoric build 1018 / Linux)

Reminder: with Euphoric the same program with end address 1 byte after the end of file and without the #55 at the end works fine but never end loading with Oricutron

[Godzil]

I think that Oricutron is more accurate than Euphoric and the ROM just store one more byte with CSAVE..

[Symoon]

Ok this was discussed on comp.sys.oric 4 years ago (ans 2 years ago on this forum about ORT files) - totally forgot that.
http://compgroups.net/comp.sys.oric/tru ... ap/2726390

In short, André M. found the solution:

For a BASIC CSAVE, the ROM routine (0xE7DB/0xE909) saves from where the text starts to where the variables start.

Thus every BASIC save has one extra byte of "junk" at the end (the first character of the name of the first variable, I think). But the save is still valid in that the header is followed by E + 1 - A bytes.