TAP files
DuLac
wrote:
> I personally favour using solely .tap for loading and saving, as under
> Windows this will make no difference and under Unix lower case filenames
> and extensions in particular are the standard. The worst case is that
> .TAP files will need renaming to .tap
Hum... Had no idea that there was some TAPs in lower case.
Having no idea how the loading is implemented, may I suggest the
upper, or lower case, conversion of the extension when reading the
files? That would solve that minor problem and ease xACE usage.
> Therefore I think that as long as xAce is loading .tap files which
> contain just one file, <...>
"IS" loading .TAPs with one file?!?
All files I tried to load contain just one file. I've checked with
ACE32.
Anyway I tried my own vida_32x24 and the 5 TAPs from the first Cantab
demo tape. None was loaded.
Is it possible that WHEN building a single file TAP, AND '81' has
several taps loaded, some unexpected difference appears in the new
one
file TAP, like the preparation of a new block.
I found bizarre that, not checking the checksum, I was still unable
to
load any of the files I tried. One file TAPs.
I'll try a different TAP, one where '81' most likely didn't face the
chance of having a second file available.
Any suggestion of a TAP to try?
'later.
DuLac
Tried OTHELLO, and loaded correctly, only a problem with GET PIECES.
So there are '81' TAPs of ONE file that do load and others that do
not.
Apparently the reason may be the availability of other TAPs when '81'
constructs one. To be more specific, when a TAPE has several programs
and these were present... THEN we find ONE file TAPS that do not load.
I believe this glitch may be the result of a preparation for a new
file in the same TAP, and xACE finding that behavior unexpected. But
while checksum disregarding is helpful when READING... the difference
in the 81'TAP is not accepted.
At least we now know of such a glitch.
Cheers.
Lawrence Woodman
DuLac wrote:
> Tried OTHELLO, and loaded correctly, only a problem with GET PIECES.
> So there are '81' TAPs of ONE file that do load and others that do
> not.
>
OTHELLO is a good example of a .TAP file containing multiple files. The
first file in the .TAP file is called 'othello', the second file is
called 'pieces'. When you type GET PIECES, this is actually doing a
binary load of a file called 'pieces'.
> Apparently the reason may be the availability of other TAPs when '81'
> constructs one. To be more specific, when a TAPE has several programs
> and these were present... THEN we find ONE file TAPS that do not load.
>
I'm not sure what you mean there, but think I have answered it above.
> I believe this glitch may be the result of a preparation for a new
> file in the same TAP, and xACE finding that behavior unexpected. But
> while checksum disregarding is helpful when READING... the difference
> in the 81'TAP is not accepted.
>
I agree that the .TAP files need to have a checksum when saving so that
we can develop on xAce and pass our creations around so that others can
enjoy them.
bfn
Lorry
--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com
DuLac
LUNAR is NOT loaded even being a ONE file .TAP
On May 30, 1:21 pm, Lawrence Woodman wrote:
> OTHELLO is a good example of a .TAP file containing multiple files.
> The first file in the .TAP file is called 'othello', the second file is
> called 'pieces'. When you type GET PIECES, this is actually
> doing a binary load of a file called 'pieces'.
- OTHELLO is a ONE file, with a second chunk in binary
(81 has available only ONE code chunk, the other is binary)
- LUNAR does NOT load, other taps were available when created.
- VIDA_32x24 is a ONE file made with other TAPs present (so you can
guess the result by now)
This is the behavior, in short:
IF a TAPE has ONE program BUT several were available...
But IF the second file is binary
THEN (and if the above does not apply) there is only ONE code file,
and xACE loads it.
I believe this glitch may be the result of a preparation for a new
file in the same TAP, and xACE finding that behavior unexpected.
final
TAP so that xACE does not read it.
The funny thing is that if a second file is binary the TAP is half
readable. The main code is read but not the second binary chunk.
This is what is happening and may be a clue when examining the
process in both systems. I would advise a copy of the 81 code as
the fastest way to get things working.
Were in the xACE code is the read/write translations?
I do no "C" but can read a little.
Maybe I could help finding the reason for that consistent behavior.
'later.
DuLac
From it the conclusion is:
81 has a glitch and xACE is to rigid to deal with it
What is needed by now:
- Correct the glich in 81 code when transplanting... or
- make xACE more flexible.
My advice to ease present coding:
- Copy the 81 code and check it.
- Eliminate the glitch so it is not passed to future tools
Would like to check both xACE and 81 code on LOAD/SAVE
Could you please tell in what lines it resides?
Maybe I could help by finding the rationale involved.
BTW-The position in 81's code, if you know, would also be
helpful. A comparison will ease finding the problem, and
solve the checksum problem.
Cheers.
Lawrence Woodman
I have joined your two emails together to ease things.
DuLac wrote:
> OTHELLO is Loaded, even having a 2nd file
> LUNAR is NOT loaded even being a ONE file .TAP
>
> On May 30, 1:21 pm, Lawrence Woodman wrote:
>
>> OTHELLO is a good example of a .TAP file containing multiple files.
>> The first file in the .TAP file is called 'othello', the second file is
>> called 'pieces'. When you type GET PIECES, this is actually
>> doing a binary load of a file called 'pieces'.
>>
>
> The difference between the two is:
> - OTHELLO is a ONE file, with a second chunk in binary
> (81 has available only ONE code chunk, the other is binary)
> - LUNAR does NOT load, other taps were available when created.
> - VIDA_32x24 is a ONE file made with other TAPs present (so you can
> guess the result by now)
>
It's strange that LUNAR won't load, it loads fine on my system. Is this
the one mentioned on the Compatibility page of the wiki, that comes from
the Ace Demonstration Tape? Have you made the filename lowercase?
> This is the behavior, in short:
> IF a TAPE has ONE program BUT several were available...
> THEN we find ONE file TAPS that do not load.
> ...and...
> But IF the second file is binary
> THEN (and if the above does not apply) there is only ONE code file,
> and xACE loads it.
>
>
> I believe this glitch may be the result of a preparation for a new
> file in the same TAP, and xACE finding that behavior unexpected.
> When '81' creates a file, the presence of other files alters the
> final
> TAP so that xACE does not read it.
> The funny thing is that if a second file is binary the TAP is half
> readable. The main code is read but not the second binary chunk.
>
> This is what is happening and may be a clue when examining the
> process in both systems. I would advise a copy of the 81 code as
> the fastest way to get things working.
>
> Were in the xACE code is the read/write translations?
> I do no "C" but can read a little.
> Maybe I could help finding the reason for that consistent behavior.
>
Have a look at the save_p() and load_p() functions in xmain.c I just
have, and I'm guessing that this code pretty much came out of the
original emulator code that Edward forked. There is plenty of room for
problems here. But what it all comes down to is the load/save model is
confused and is trying to be a half-way house between using named files
on the OS and allowing multiple files on one .TAP file. Still it should
achieve the first without any problems apart from the lack of checksum.
When xAce was developed there was no dominate format, so the method
chosen had a lot going for it, in effect turning the TAPE access of the
ace from a sequential system to a random access system. The only
problem with it is that things moved to a different model that xAce is
only half compatible with.
> BTW-The position in 81's code, if you know, would also be helpful. A
comparison will ease finding the problem, and solve the checksum problem.
I haven't had a chance to look at 81's code, but still think it is more
of a problem with xAce *load/save model* not *code*. Essentially on 81,
you would attach a .TAP file to the emulator. Then all subsequent loads
and bloads would be from that .TAP file. Whereas on xAce each load and
bload is looking for that file on the OS. In actual fact you can
technically load a program from the .TAP file even though the .TAP file
is called a different name. e.g. If I rename LUNAR.TAP to harry.tap
then from xace type 'load harry' It will actually load the lunar program
contained therein. So when I type 'lunar' everything works fine.
If you don't get lunar loading, could you copy and paste what is output
to the console, so I can try and work out what is happening.
I'm going to be out of contact for a few days, so will continue looking
at this when I get back.
DuLac
I wake up today with an idea that could be useful.
This was after last night searching, finding and becoming disappointed
with 81's sight. It is very nice code, but very nice only at code
level.
It was a glimpse look, and so I could not put my word on it, but
seemed with too much inter-relations. More than I could stand
while not knowing the full picture. And the full picture is huge.
The wake up idea (with several possible branches:
1 - Having a pointer to the TAP file, separate from the xACE.
2 - 3 options:
a) selecting a TAPE as argument (fast but limited)
b) altering that pointer externally (fast and allows changing)
ex: copy name.tap to "xacetape.tap" (needs a multitasking OS)
c) altering that pointer internally (can use the present hot-keys)
??: interrupt emulation to ask new TAPE name
---
> Have a look at the save_p() and load_p() functions in xmain.c
> But what it all comes down to is the load/save model is confused
> and is trying to be a half-way house between using named files
> on the OS and allowing multiple files on one .TAP file.
Also noticed ACE32 uses a strange strategy to allow reading of
several files. It becomes fixed to the first name used as being
the one of the TAP in use.
As a result it does not allow TAPE changing.
Except by externally loading a new TAPE followed by a reset.
---
> Essentially on 81, you would attach a .TAP file to the emulator.
> Then all subsequent loads and bloads would be from that .TAP file.
> Whereas on xAce each load and bload is looking for that file on the OS.
The only way to get it is changing the TAP name to get the following.
I have use that by having a copy of othello.tap as pieces.tap
The result was crashing xACE. To find why, I checked GET
and noticed that, beside being a 2nd chunk, a BLOAD was used.
Not sure what of the 2 is the main reason for the crash.
---
> If you don't get lunar loading, could you copy and paste what is output
> to the console, so I can try and work out what is happening.
a situation that was out of sight. The names were in Caps!
Those testings were a loss of time and effort, specially mine.
Now that the situation is clear... I'll check code again when
possible.
'later.
Lawrence Woodman
DuLac wrote:
> Everything is clear now.
>
> I wake up today with an idea that could be useful.
> This was after last night searching, finding and becoming disappointed
> with 81's sight. It is very nice code, but very nice only at code
> level.
>
> It was a glimpse look, and so I could not put my word on it, but
> seemed with too much inter-relations. More than I could stand
> while not knowing the full picture. And the full picture is huge.
>
> The wake up idea (with several possible branches:
> 1 - Having a pointer to the TAP file, separate from the xACE.
> 2 - 3 options:
> a) selecting a TAPE as argument (fast but limited)
> b) altering that pointer externally (fast and allows changing)
> ex: copy name.tap to "xacetape.tap" (needs a multitasking OS)
> c) altering that pointer internally (can use the present hot-keys)
> ??: interrupt emulation to ask new TAPE name
>
I think that we should be able to change the TAPE name connected to xAce
through either a hot-key or once/if we have a GUI via that. For the
moment though I think that the current state of the repo should be
released as a minor release so that people no longer need to patch xAce
to get it to work on 32bpp displays. Once that has been released then
we can get on and fix these other problems. What do yo think?
Steve
>>I think that we should be able to change the TAPE name connected to xAce
>>through either a hot-key or once/if we have a GUI via that. For the
>>moment though I think that the current state of the repo should be
>>released as a minor release so that people no longer need to patch xAce
>>to get it to work on 32bpp displays. Once that has been released then
>>we can get on and fix these other problems. What do yo think?
Yes, I would go with that.
In the main xace window, the title bar just says 'xAce' should we add a
version number?
(I presume X11 code library's creates the GUI window? Can any one point me
to some information/site
that show you how to use x11 GUI windows? I would like to create the 'Hello
World' in a window.
So I can try and understand how xace writes to the GUI window. I just
interested in how the xace C code
integrates with X11 ! - better start a new subject or mail me direct thanks)
Steve.
Lawrence Woodman
>>> I think that we should be able to change the TAPE name connected to xAce
>>> through either a hot-key or once/if we have a GUI via that. For the
>>> moment though I think that the current state of the repo should be
>>> released as a minor release so that people no longer need to patch xAce
>>> to get it to work on 32bpp displays. Once that has been released then
>>> we can get on and fix these other problems. What do yo think?
>>>
>
> Yes, I would go with that.
>
>
on that and then will release.
> In the main xace window, the title bar just says 'xAce' should we add a
> version number?
>
>
It would be non-standard to have the version number there at the
moment. It is output to the console and once we have a GUI it could be
output via an 'About' menu option.
> (I presume X11 code library's creates the GUI window? Can any one point me
> to some information/site
> that show you how to use x11 GUI windows? I would like to create the 'Hello
> World' in a window.
> So I can try and understand how xace writes to the GUI window. I just
> interested in how the xace C code
> integrates with X11 ! - better start a new subject or mail me direct thanks)
>
>
I don't really know of any x11 tutorials off hand. I have just come
across this one: http://www.unix-manuals.com/tutorials/xlib/xlib.html
which you may find useful. It may be interesting to play around with
X11, but as far as xAce is concerned, I would really like to move away
from being so reliant on X.
DuLac
On Jun 6, 7:29 am, Lawrence Woodman <lwood...@vlifesystems.com> wrote:
> I think that we should be able to change the TAPE name connected to xAce
> through either a hot-key or once/if we have a GUI via that.
> For the moment though I think that the current state of the repo should be
> released as a minor release so that people no longer need to patch xAce
> to get it to work on 32bpp displays.
> Once that has been released then we can get on and fix these other problems.
> What do yo think?
usefulness.
All other things can wait, but not that one.
One thing is respecting the standard with all it implies...
For now xACE is a useful beta. Within the standard will be the final
v0.5
At least this is as I see it.
'later,
DuLac
Lawrence Woodman
DuLac wrote:
> Lorry,
>
> On Jun 6, 7:29 am, Lawrence Woodman <lwood...@vlifesystems.com> wrote:
>
>> I think that we should be able to change the TAPE name connected to xAce
>> through either a hot-key or once/if we have a GUI via that.
>> For the moment though I think that the current state of the repo should be
>> released as a minor release so that people no longer need to patch xAce
>> to get it to work on 32bpp displays.
>> Once that has been released then we can get on and fix these other problems.
>> What do yo think?
>>
>
> I think the checksum problem is paramount to compatibility and thus
> usefulness.
> All other things can wait, but not that one.
>
I agree on the importance of the checksum problem, but it is only one of
many problems that break the de-facto standard, such as the multiple
files in a file problem. As a compromise I intend to release the
current version as v0.4.1. Then once the checksum is fixed and a few
other problems, release as v0.4.2. This keeps things simpler, stabler
and immediately fixes the display problem that has put people off of
xAce for quite some time, while all the time maintaining development
momentum.