fichier TAP créé par osk qui bloque
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: fichier TAP créé par osk qui bloque
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
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
My Projects: Replic'Oric Project - StratoCumulus Project
Re: fichier TAP créé par osk qui bloque
Thanks - it's a classical.Godzil wrote:Anyway good spot Symoon, can't expect less from the Oric tape expert
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
Re: fichier TAP créé par osk qui bloque
@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.
---
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.
Re: fichier TAP créé par osk qui bloque
@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!
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!
Re: fichier TAP créé par osk qui bloque
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
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
Re: fichier TAP créé par osk qui bloque
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?
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?
Re: fichier TAP créé par osk qui bloque
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).
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).
Re: fichier TAP créé par osk qui bloque
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:
I don't know why
A zero length BASIC program is:
And a 1 byte (CSAVE "EMPTY",A#501,E#501):
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.
Code: Select all
20145 UUUUUUUUUUUUUUUUUUUUUUUUUUUU
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|
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..|
Re: fichier TAP créé par osk qui bloque
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.christian wrote: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:I don't know whyCode: Select all
20145 UUUUUUUUUUUUUUUUUUUUUUUUUUUU
Re: fichier TAP créé par osk qui bloque
Are you using the same Oricutron's build and OS? One never knows...
Re: fichier TAP créé par osk qui bloque
I made more tests.
Works fine:
But:
CLOAD, LIST => OK
RUN => ?SYNTAX ERROR IN 1152
LIST
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
Works fine:
Code: Select all
10 PRINT "TEST"
Code: Select all
10 A$="TEST"
RUN => ?SYNTAX ERROR IN 1152
LIST
Code: Select all
10 A$="TEST"
1152
21845 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
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
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: fichier TAP créé par osk qui bloque
I think that Oricutron is more accurate than Euphoric and the ROM just store one more byte with CSAVE..
My Projects: Replic'Oric Project - StratoCumulus Project
Re: fichier TAP créé par osk qui bloque
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:
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.