How to add support for tape images containing multiple files
Lawrence Woodman
The next problem that I think needs addressing in xAce is its lack of
support for tape images containing multiple files. I have been thinking
about how to do this, without having to repeat similar work as things
develop later on. Ideally it would be nice to be able to pop-up a
window when you would like to change which tape image is attached, but
it seems fairly pointless to work on this if the interface is going to
change dramatically later on. I therefore propose adding a command line
switch to attach a tape image. If the command line switch isn't used
then xAce will default to its previous behaviour of looking for single
tape files in the current working directory.
The command line switch will only be used as a stop gap, to increase
compatibility, until the new GUI is completed.
What do people think?
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
> The next problem that I think needs addressing in xAce is its lack of
> support for tape images containing multiple files. I have been thinking
> about how to do this, without having to repeat similar work as things
> develop later on.
I believe we already have examined the problem and possible solutions.
So they are already available, and you mentioned one.
But I'll remind the immediate solution presented:
The simplest solution, and universal, is to accept one file as THE
tape when starting.
If not defined, a standard name or a time-date ID.
Tape changes can be made, initially, by calling the current TAP name
routine.
F4 key was the one used on ACE32 to make that file attribution change.
Just close the present one and open the one with the new name.
More simple and direct... I cannot see how.
It really is annoying to keep confusing TAPE with FILEonTAPE.
As a fast way to read tapes... it is an acceptable hack.
But there's a time to surpass the temporary and get the real thing.
What remains to be defined is the behavior of the TAPE since it
becomes to be what the name implies.
There, we face 2 problems: The position ON the tape (on reading... and
on writing)
- On reading I would make it circular on reading, with temporary
indexes for the files inside.
- On writing I would (at first) just append a new file.
On writing that would create the chance of multiple identical File
names as it happens in a Tape.
No problem there, except on distinguish them, as they would be
appended instead of inserted.
Later I would enhance the system with an external editing tool to
erase files from a Tape.
No need to confuse a system. The Unix philosophy is there supporting
this solution.
It is closely related with the KISS rule. But the current trend is the
opposite.
(I had a teacher that used this technique to make students think he
was a genius)
Thank God xACE does not follow the current trend of confusing things
so they are hard to follow.
Helas!, This is a simple task, as long as we have a clear sight of
what and how we want to do it.
If we are at ease with the tool. It would be helpful to have the code
cleaned up and organized.
It would had become as trivial as the keys change I made to make xACE
more ergonomic.
There is nothing new on this portion of the universe, unfortunately.
Hope it helps,
DuLac.
Lawrence Woodman
>> The next problem that I think needs addressing in xAce is its lack of
>> support for tape images containing multiple files. I have been thinking
>> about how to do this, without having to repeat similar work as things
>> develop later on.
>>
> tape when starting.
> If not defined, a standard name or a time-date ID.
> Tape changes can be made, initially, by calling the current TAP name
> routine.
> F4 key was the one used on ACE32 to make that file attribution change.
>
> Just close the present one and open the one with the new name.
> More simple and direct... I cannot see how.
>
> It really is annoying to keep confusing TAPE with FILEonTAPE.
> As a fast way to read tapes... it is an acceptable hack.
> But there's a time to surpass the temporary and get the real thing.
>
> What remains to be defined is the behavior of the TAPE since it
> becomes to be what the name implies.
> There, we face 2 problems: The position ON the tape (on reading... and
> on writing)
> - On reading I would make it circular on reading, with temporary
> indexes for the files inside.
> - On writing I would (at first) just append a new file.
>
> On writing that would create the chance of multiple identical File
> names as it happens in a Tape.
> No problem there, except on distinguish them, as they would be
> appended instead of inserted.
>
The default attached .TAP image seems like a good idea, I propose using
default.tap as the default .tap file attached to the emulator on startup.
I have been thinking about multiple identical file names on a .tap
image. This would of course emulate a tape drive more closely, there
are two problems connected with this though:
i) We may need additional functionality to control the emulated
tape drive.
ii) Would a .TAP image with multiple identical file names be
compatible with the other emulators that use .TAP? Anybody got any idea?
For the moment I think it would be a good idea to restrict the .TAP
images to overwrite files with matching file names.
bfn
DuLac
[Real TAP files :: Multiple files]
> tape drive.
> ii) Would a .TAP image with multiple identical file names be
> compatible with the other emulators that use .TAP? Anybody got any idea?
I very much doubt that a TAP file has any internal structure to deal
with diferent files.
I doubt because a TAPE is just a sequence of FILES on tape.
There should be no need to ideas to solve problems that do not exist
yet, and hardly will.
The only problem is not really a problem... It is common sense in
beeing carefull in allowing easy reading.
I mean: A need to introduce a sensible gap between files so they can
be distinguished when reading.
And this should be, I guess, just a bunch of zeros. It all depends on
how the reading routine is done,
as those empty data must be ignored until the relevant data is
considered by the present routine.
There should be no trouble as until now, except readability.
This could be more helpful if the code was already cleaned and
organized.
I do not C, only read... and only if find what to read. Just a
reminder.
Maybe someone will be available to do the needed cleaning to let us
surpass the reading barrier.
Until then we are reduced to trivial stuff.
(Low readbility confuses the origin of the file/keyb input problem)
(I have a clue on the origin of the problem but cannot check it as the
code is.)
(And no: It it a hint, very hard to express in words, specially
without a check)
on the real code. So that problem will remain, to my dismay, until
code is organised)
> For the moment I think it would be a good idea to restrict the .TAP
> images to overwrite files with matching file names.
The simple way:
- Using arguments to the reading and to the writing TAPs... using -i
and -o... and -t for a common tape.
- writing by appending, erasing a file with an external tool.
- index to the current positions on both tapes (the IN and the OUT
ones, if not the same)
BTW, trivial does not mean not useful, but readability is needed to
allow more people to deal with the code.
I believe the code is actually simple, just obfuscated by patches.
Regaining the simplicity would allow easing changes and understanding
of it to a more broad assistance.
I certainly do not believe in obfuscated code, I believe it to be
helpful just in keeping it proprietary like.
That reduces chances and is good to no one. Not really.
Code should be readable when open-source. Always!
Or the point is missed.
DuLac.
P.S. Note:
I'm very much away from home, using ocasionally a borrowed PC, with no
passwords except GMail.
No tools, no nothing except a keyboard and a connection. And it feels
good to be free! Cheers.
Lawrence Woodman
> [Real TAP files :: Multiple files]
>
>> i) We may need additional functionality to control the emulated
>> tape drive.
>>
> Meanning...
>
multiple files with the same name on a tape image. E.g. what if I am
just before the first occurrence of "mydata", and want to load the
third occurrence of "mydata". I would have to forward past the second
occurrence. This would be a real pain and quite confusing.
>
>> ii) Would a .TAP image with multiple identical file names be
>> compatible with the other emulators that use .TAP? Anybody got any idea?
>>
>
> See the previous message.
> I very much doubt that a TAP file has any internal structure to deal
> with diferent files.
> I doubt because a TAPE is just a sequence of FILES on tape.
> There should be no need to ideas to solve problems that do not exist
> yet, and hardly will.
>
This problem definitely could exist. What if someone were to save a
tape image from xAce with multiple identical file names and then wanted
to load that tape image onto another emulator that doesn't have support
for multiple identical file names. That would lead to xAce's
compatibility moving further away from other emulators not closer.
> The only problem is not really a problem... It is common sense in
> beeing carefull in allowing easy reading.
> I mean: A need to introduce a sensible gap between files so they can
> be distinguished when reading.
> And this should be, I guess, just a bunch of zeros. It all depends on
> how the reading routine is done,
> as those empty data must be ignored until the relevant data is
> considered by the present routine.
> There should be no trouble as until now, except readability.
>
I'm not sure what you mean about adding a bunch of zeros, are you
proposing a new .TAP format? At the moment I intend to continue using
the header/data block system which specifies what is data and where
files separate easily.
> This could be more helpful if the code was already cleaned and
> organized.
> I do not C, only read... and only if find what to read. Just a
> reminder.
> Maybe someone will be available to do the needed cleaning to let us
> surpass the reading barrier.
> Until then we are reduced to trivial stuff.
>
> (Low readbility confuses the origin of the file/keyb input problem)
> (I have a clue on the origin of the problem but cannot check it as the
> code is.)
>
Which file/keyb problem are you referring to?
Marcos Cruz
> I therefore propose adding a command line
> switch to attach a tape image. If the command line switch isn't used
> then xAce will default to its previous behaviour of looking for single
> tape files in the current working directory.
>
> The command line switch will only be used as a stop gap, to increase
> compatibility, until the new GUI is completed.
I think it's a good solution. But I think there's an issue missing here: what
about tape recording when a tape image is attached?
I use the "fuse" ZX Spectrum emulator a lot. The way it manages tape recording
is a bit confusing for the beginner at first sight, but it's practical: when
the user opens a new TAP image as input, the emulator keeps an internal copy
as output tape, and adds at its end all files the user saves thereafter. The
emulator doesn't change the original input TAP image, and *only* saves the
output TAP image when the user decides (and optionally with a different name).
There's an useful option to *clear* the output TAP image at any moment, to
start with a blank tape. Of course the TAP image can be specified with a
command line switch.
I think it's a good solution.
A different approach for xAce could be to attach two TAP images: one for input
an another for output. The output image could be even a non-existent file.
Marcos
Marcos Cruz
> I have been thinking about multiple identical file names on a .tap
> image. This would of course emulate a tape drive more closely, there
> are two problems connected with this though:
>
> i) We may need additional functionality to control the emulated tape
> drive.
> ii) Would a .TAP image with multiple identical file names be
> compatible with the other emulators that use .TAP? Anybody got any idea?
I don't see any problem here, and I use ZX Spectrum emulators a lot: the
emulator reads the TAP input file as needed. The only difference with a real
tape is that the user doesn't have to play/pause/stop it! There's no problem
having several files with the same name on a TAP image. The user is supossed
to know what the TAP contains, the same way he was supposed to know what his
real tapes contained years ago. If he want to load a certain file, the
emulator will load the first one with the given name. Simply! That's the way
the real thing worked.
Really I see no problem at all about reading multiple files on a single TAP
image, whether with different names or not. The only real issue I see is
*output*, not input. In my last message I suggested two solutions about tape
output files.
> For the moment I think it would be a good idea to restrict the .TAP
> images to overwrite files with matching file names.
No need for that, I think. The problem vanishes when you consider tape input
and tape output apart! A TAP file contains a serial stream of files. If you
try to manage a TAP file as a disk drive, overwriting files, you make things
much more difficult to program. In fact we didn't worked that way with the
actual machines: we never overwritted files on our tapes! It would be quite
difficult indeed :) We simply used a different tape as output... or forwarded
to the end of the current tape. The way the "fuse" ZX Spectrum emulator
manages tapes reflects the way we worked with the actual computer and tapes,
and it's a simple and good solution.
Marcos
Marcos Cruz
> Rewind, fast forward, etc. This is the real problem with allowing
> multiple files with the same name on a tape image. E.g. what if I am
> just before the first occurrence of "mydata", and want to load the
> third occurrence of "mydata". I would have to forward past the second
> occurrence. This would be a real pain and quite confusing.
I see no problem, because the emulator keeps the current tape position. I
suggest three aproaches:
1) The simplest solution: If you want to load the third "mydata", you enter
LOAD RUBBISH :) as many times as needed, to pass the first two "mydata".
That's what we did with the actual machines.
2) The emulator can provide some shortkeys to rewind or forward, file by file,
the current input TAP image (and also to go right to the start or to the end).
No need to show the current position on the screen at the moment (though it
would by nice to add that feature in future versions, when the GUI will be
definitive).
3) The more comfortable solution: The emulator provides a tape manager
interface, to show the whole content of the current input TAP image (a kind of
detailed directory of the TAP) and move the current tape position on the list
of files, with the cursor keys or the mouse.
The three solutions can perfectly coexist.
DuLac wrote:
>> I very much doubt that a TAP file has any internal structure to deal
>> with diferent files.
>> I doubt because a TAPE is just a sequence of FILES on tape.
>> There should be no need to ideas to solve problems that do not exist
>> yet, and hardly will.
I completely agree. There's no real problem about multiple input files with
the same name.
> This problem definitely could exist. What if someone were to save a
> tape image from xAce with multiple identical file names and then wanted
> to load that tape image onto another emulator that doesn't have support
> for multiple identical file names. That would lead to xAce's
> compatibility moving further away from other emulators not closer.
No problem. I never heard of an emulator get confused because of several files
on a TAP with the same name. The first file whose name matches the LOAD
instruction is loaded, the same way a real tape.
> I'm not sure what you mean about adding a bunch of zeros, are you
> proposing a new .TAP format? At the moment I intend to continue using
> the header/data block system which specifies what is data and where
> files separate easily.
Maybe DuLac mentions that bunch of zeroes because he is not acquainted with
the TAP format, and he thinks a TAP image somehow "plays" in real time like a
real tape. But the thing doesnt't work that way. The emulator reads from the
TAP image what it needs, and it keeps the current "tape" position.
Marcos
DuLac
On Jul 30, 7:56 pm, Marcos Cruz <retgrupo...@alinome.net> wrote:
> Maybe DuLac mentions that bunch of zeroes because he is not acquainted with
> the TAP format, and he thinks a TAP image somehow "plays" in real time like a
> real tape. But the thing doesnt't work that way. The emulator reads from the
> TAP image what it needs, and it keeps the current "tape" position.
Having indexes or not is just a comodity.
I suppose the Tape-Control (back and forward) is irrelevant here if a
small
array of indexes (pointers to TAP positions is kept).
After all... a TAP file is NOT a .wav file to be processed.
Does this clears equivocations and promote simplicity?
Up to now everything has been trivial, having the TAP routines in
place,
there's no reason not to keep things simple if they, fundamentaly,
are
simple. Just not readable!
'later,
DuLac.
P.S. Small thought:
C should never had evolved from a variant of a macro-assembler,
K&R C was fine and relatively simple, the pré and post increments of
variables
still are an excelent idea to reduce pseudo-code size.
As a full blown Programming Language... it is a mess.
No wonder so many fancy tools do exist ... just "not to program".
Period!
DuLac
On Jul 30, 7:17 am, Lawrence Woodman <lwood...@vlifesystems.com>
> Rewind, fast forward, etc.
> This would be a real pain and quite confusing.
If you load a TAP or if you redefine one, the TAP creates the index.
This does not need to be implemented straight away.
Usually, good and simple solutions are evolutive.
> This problem definitely could exist. What if someone were to save a
> tape image from xAce with multiple identical file names and then wanted
> to load that tape image onto another emulator that doesn't have support
> for multiple identical file names.
If a program does that you suggest, I believe it to be a glitch of his
own.
A glitch, nomatter the good intentions of the implementator that would
just
getting out of reality creating it's own problems and happy with them.
> I'm not sure what you mean about adding a bunch of zeros, are you
> proposing a new .TAP format? At the moment I intend to continue using
> the header/data block system which specifies what is data and where
> files separate easily.
code involved. So I wonder if a gap between files would be usefull or
if such
gap would create problems. As refered, that would depend of
implementations
and that is an answer by itself. As a probable situation, I mean!
> Which file/keyb problem are you referring to?
It was what started all desire to clean the code and make it more
readable.
As is, the code, reasons are obfuscated. But that was already
expressed.
You see, I'm not interested in C. Just curious about the structure of
xace.
And that curiosity does not find it's goal, too boring to surpass...
so it
become a reason to ignore xace.
Working with C is, for me, a loss of time and also a turn-off.
It may be undertood as a matter of taste... but really there is more
to it than
such a simple explanation. But, to C or not to C... is a useless
subject. So...
later,
DuLac
Lawrence Woodman
> A TAP file should follow the real TAPE files, like in a real tape.
> If a program does that you suggest, I believe it to be a glitch of his
> own.
> A glitch, nomatter the good intentions of the implementator that would
> just
> getting out of reality creating it's own problems and happy with them.
>
I think that it is more important to emulate the real tape and worry
less about creating incompatibility with emulators which may effectively
have an implementation issue.
>> Which file/keyb problem are you referring to?
>>
>
> Feeding the keyboard from a file.
>
I had a feeling that you may have been referring to that. Their is no
mystery as to why it doesn't work, the code is incomplete. Edward must
have been working on it and decided to release before completing it,
hence the reason that it isn't even compiled in.
Lawrence Woodman
> El/Je/On 2010-07-30 08:17, Lawrence Woodman escribi� / skribis / wrote :
>
>
>> Rewind, fast forward, etc. This is the real problem with allowing
>> multiple files with the same name on a tape image. E.g. what if I am
>> just before the first occurrence of "mydata", and want to load the
>> third occurrence of "mydata". I would have to forward past the second
>> occurrence. This would be a real pain and quite confusing.
>>
>
> I see no problem, because the emulator keeps the current tape position. I
> suggest three aproaches:
>
> 1) The simplest solution: If you want to load the third "mydata", you enter
> LOAD RUBBISH :) as many times as needed, to pass the first two "mydata".
> That's what we did with the actual machines.
>
> 2) The emulator can provide some shortkeys to rewind or forward, file by file,
> the current input TAP image (and also to go right to the start or to the end).
> No need to show the current position on the screen at the moment (though it
> would by nice to add that feature in future versions, when the GUI will be
> definitive).
>
> 3) The more comfortable solution: The emulator provides a tape manager
> interface, to show the whole content of the current input TAP image (a kind of
> detailed directory of the TAP) and move the current tape position on the list
> of files, with the cursor keys or the mouse.
>
>
propose solution number 3. There will be key to bring up a tape manager
from which you can change the attached tape image and change the
position within that image. My main reluctance to going down this route
is that I wanted to sort out the GUI before I added to the interface.
But I can see now that this no sensible way of getting around this. So
will look at implementing the tape manager. Thanks for the suggestion.
Lawrence Woodman
I can see the benefit of the "fuse" system, but think for simplicity I
could do this as follows through the tape manager:
At any one time only one tape can be attached. When a user saves it
will save to the end of the tape. From the tape manager, the user can
delete a file and therefore keep saving without endlessly filling the
tape with variations of the same file.
bfn
Steve
There are very few Ace games / programs that have multiple blocks of code to
be loaded into the Ace from one tape.
Typical such games would load in game graphics data then the game body with
the exception of Black Island Adventure (BIA)
BIA once part one of the game is completed the user is prompted to "start
the tape" to load the next part which is a 16K block headless block of data.
BIA will do this with all three parts of the game. So the physical tape has
the first part ( header + data ) and three blocks of data.
It would be great if xAce could emulate the cassette system with multiple
files in a separate window .
Remember that a tap file is the "wrapper" for the header block and data
block, other blocks of information are also there.
Such as a comment blocks, informing you what program created the tap file.
A tap file mounted to the window, the length of the tap file would be the
index to the tap, in time.
Just like a real cassette recorder has a tape counter, the window with the
tap file loaded would start at 0 and progress in seconds.
You could fast forward to the next block be it a header, text comment or
data.
81 tap files have a comment block, then a header block + data block, then
the next header + data block...as so on.
Comment block can be inserted anywhere in the tap file, just as sound can be
recorded on to a tape.
If the Ace was instructed to load a file first reading the header then came
across a sound on a real tape is would just wait until
A data block was found, this is how the comment blocks are seen by 81 with
tap files.
If I had the skills I would start a new C project to create a GUI tape
window,
Which could list the contents of a tap file. Create buttons to stop/start
fast forward, pause a tap file running in time.
You could use the index counter as a place to insert a new recording. May be
you should see how 81's Borland C code on how Mike programed it?
BIA is key tap file program for multiple parts to a game get this to load
correctly and then any tap file will work be having ten blocks or one.
Can you instruct xAce to start load a file from start up? 81 can and it very
useful when passing file names when using the J.A.D.E system,
Would be nice to get this to work on a Linux box.
About the extension name, .tap or .TAP, you will find in the archive old
files have the .TAP extension and new ones have to .tap.
The archive aim to use .tap and they will be changed in time.
I have not read the rest of the messages, just reply to lorry first post,
as I'm away for the next 4 weeks, and Edwin is also away with his family
until the end of August.
Steve.
Marcos Cruz
> On Jul 30, 7:56�pm, Marcos Cruz <retgrupo...@alinome.net> wrote:
> > 1) The simplest solution: If you want to load the third "mydata", you enter
> > 2) The emulator can provide some shortkeys to rewind or forward, file by file,
> > 3) The more comfortable solution: The emulator provides a tape manager
> > The three solutions can perfectly coexist.
>
> Considering the actual interface, and to be kept as clean as
> possible,
> both for the user as for code maintenance, and the indexed nature of
> the TAP file... there's no reason to lose time with GUI considerations
> by using F5-F6-F7-F8 (usually a 4 FKeys block to command like the
> 4 control keys of a tape recorder - it is direct and intuitive).
I agree, solution #2 with function keys is good and enough, considering the
current interface, and the most important: it's much easier to implement. The
more complex tape manager can wait until the GUI is defined.
> But there is no need for "fast" keys... BUT 1st and last instead...
> or even a move by 2 indexes... could be an extra to the only moves
> that are useful...
Fast forward/rewind keys are not essential because usually there won't be many
files on one TAP image. Anyway they can be easily implemented with Shift+F6 and
Shift+F7; they could move by 2 files, or 4... or a configurable value.
Anyhow some feedback would be useful: the name of the current file header
pointed to (or "end of tape"), maybe with other details (e.g. file length).
With a GUI, the info could be shown on a status bar. Now it could be simply
printed on the console, after every press of the "tape keys".
Marcos
DuLac
> 2) The emulator can provide some shortkeys to rewind or forward, file by file,
with immediate results, following the common path (squeleton)
Considering the actual interface, and to be kept as clean as
Using the desired indexed nature of a file and present in
the TAP file... There's no reason to lose time with GUI
considerations (they are secondary).
Though there is no need to use fast keys, using F5-F6-F7-F8
also simplify implementation.
Actually, only keys to next and previous.
Keys to 1st and last are more apropriate than fast back/forward.
Maybe better if movin by 2 indexes... it doesn't matter.
Already existing routines need only adjustments (they work)
so they read one more file... Just index control expressed by
index += moves ; set_tap_pos(index)
'later,
DuLac.
Marcos Cruz
> At any one time only one tape can be attached. When a user saves it
> will save to the end of the tape.
I think that solution is less versatile, because it forces the user to remove
undesired files later, or to copy the original TAP before running xAce in
order to preserve it.
When input and output virtual tapes are not apart, it's harder to work with an
emulator (it's almost as hard as using one single tape with a real Ace or
Spectrum for both loading and saving). Tapes are used differently than disks,
because they are serial devices. When the user saves on tape, the usual reason
is to create a new tape or to append to a different tape, not to append to the
tape he's loading from.
The "fuse" emulator's approach let's the user to append any saving to the input
TAP, because any open input TAP is copied (in RAM) to the output TAP, so the
default contents of the output TAP are that of the input TAP. But it doesn't
forces to do so: the user can delete at any time all the contents of the output
file in order to use a blank tape as output. With a tape manager, any operation
could be done on the output TAP before saving it (e.g. reordering its files or
manipulating the file headers).
But if the system uses the same TAP for input and output as you suggest, the
user has less options than with the actual Jupiter Ace: no way to read from one
tape and insert a blank tape for saving.
> From the tape manager, the user can
> delete a file and therefore keep saving without endlessly filling the
> tape with variations of the same file.
A tape manager will be a very useful tool, but it's harder to develop than tape
keys, and somehow it will have to be modified when the GUI changes. As both
features are compatible, I think the simpler tape keys should be implemented
first.
Marcos
Lawrence Woodman
current filenumber, filename and size displayed on the console. Then
have keys to move the file pointer forward or backwards or to delete
last file. When saving it will always append, so it is up to the user
to delete the last file if they don't want multiple variations. There
would also be a key to change the attached tape image.
Lawrence Woodman
> El/Je/On 2010-07-31 07:09, Lawrence Woodman escribi� / skribis / wrote :
>
>
>> At any one time only one tape can be attached. When a user saves it
>> will save to the end of the tape.
>>
>
> I think that solution is less versatile, because it forces the user to remove
> undesired files later, or to copy the original TAP before running xAce in
> order to preserve it.
>
> When input and output virtual tapes are not apart, it's harder to work with an
> emulator (it's almost as hard as using one single tape with a real Ace or
> Spectrum for both loading and saving). Tapes are used differently than disks,
> because they are serial devices. When the user saves on tape, the usual reason
> is to create a new tape or to append to a different tape, not to append to the
> tape he's loading from.
>
> The "fuse" emulator's approach let's the user to append any saving to the input
> TAP, because any open input TAP is copied (in RAM) to the output TAP, so the
> default contents of the output TAP are that of the input TAP. But it doesn't
> forces to do so: the user can delete at any time all the contents of the output
> file in order to use a blank tape as output. With a tape manager, any operation
> could be done on the output TAP before saving it (e.g. reordering its files or
> manipulating the file headers).
>
> But if the system uses the same TAP for input and output as you suggest, the
> user has less options than with the actual Jupiter Ace: no way to read from one
> tape and insert a blank tape for saving.
>
command line when xAce is started as being just the first attached tape
image. After that the user would be free to press a key and change the
attached tape image. This would seem to me to be much more like using a
real tape. In particular I remember noting the counter on the tape
before each save and then if I wanted to save again, going back to that
point and recording over the last file. The fuse system seems great,
but without a proper tape manager, things would quickly get confusing.
This could be looked at more in the future.
Marcos Cruz
> I agree with you and was thinking of the tape image passed via the
> command line when xAce is started as being just the first attached tape
> image. After that the user would be free to press a key and change the
> attached tape image.
I think that is a good solution.
> This would seem to me to be much more like using a
> real tape.
You're right.
> In particular I remember noting the counter on the tape
> before each save and then if I wanted to save again, going back to that
> point and recording over the last file.
That makes me think something: You said saving will be done always at the end
of the current tape image, rigth? But what about simply truncating the tape
image at the current position? I think that would make things a little easier
for the user, and would seem even more similar to using a real tape.
Maybe that could be a config option in the future: to save at the end of the
TAP (more secure) or to save at its current position (more unsecure but more
realistic and comfortable).
Marcos
Lawrence Woodman
>> In particular I remember noting the counter on the tape
>> before each save and then if I wanted to save again, going back to that
>> point and recording over the last file.
>>
>
> That makes me think something: You said saving will be done always at the end
> of the current tape image, rigth? But what about simply truncating the tape
> image at the current position? I think that would make things a little easier
> for the user, and would seem even more similar to using a real tape.
>
> Maybe that could be a config option in the future: to save at the end of the
> TAP (more secure) or to save at its current position (more unsecure but more
> realistic and comfortable).
>
and better as the default behaviour.
Lawrence Woodman
> There are very few Ace games / programs that have multiple blocks of code to
> be loaded into the Ace from one tape.
>
> Typical such games would load in game graphics data then the game body with
> the exception of Black Island Adventure (BIA)
>
> BIA once part one of the game is completed the user is prompted to "start
> the tape" to load the next part which is a 16K block headless block of data.
> BIA will do this with all three parts of the game. So the physical tape has
> the first part ( header + data ) and three blocks of data.
>
the BIA file.
>
> It would be great if xAce could emulate the cassette system with multiple
> files in a separate window .
>
> Remember that a tap file is the "wrapper" for the header block and data
> block, other blocks of information are also there.
> Such as a comment blocks, informing you what program created the tap file.
>
I hadn't seen any comment blocks so far, so will look at how they are
identified.
> If I had the skills I would start a new C project to create a GUI tape
> window,
> Which could list the contents of a tap file. Create buttons to stop/start
> fast forward, pause a tap file running in time.
> You could use the index counter as a place to insert a new recording. May be
> you should see how 81's Borland C code on how Mike programed it?
>
A proper tape manager is certainly something that I want to add once a
GUI is added.
> Can you instruct xAce to start load a file from start up? 81 can and it very
> useful when passing file names when using the J.A.D.E system,
> Would be nice to get this to work on a Linux box.
>
Yes, as part of this current work to improve the compatibility of the
.TAP files I will be adding a command line option of load a file from
start up.
> About the extension name, .tap or .TAP, you will find in the archive old
> files have the .TAP extension and new ones have to .tap.
> The archive aim to use .tap and they will be changed in time.
>
Excellent. It keeps things simple for xAce and emulators on Unix
systems, without effecting windows systems.
bfn
Marcos Cruz
> Steve wrote:
>> BIA will do this with all three parts of the game. So the physical tape has
>> the first part ( header + data ) and three blocks of data.
>>
> I'm glad you pointed that out and will have to look at the structure of
> the BIA file.
TAP files of course can have data blocks without a preceding header block. I
think Ace Forth cannot save or load them (ZX Spectrum BASIC didn't), so those
tapes need their own machine code loader, that simply calls the proper ROM
routine with the missing header parameters. I suppose BIA is such a case,
isn't it?
>> Remember that a tap file is the "wrapper" for the header block and data
>> block, other blocks of information are also there.
>> Such as a comment blocks, informing you what program created the tap file.
>>
> I hadn't seen any comment blocks so far, so will look at how they are
> identified.
I never heard of comment blocks in the TAP format! Is it a more modern version
of the file format, improved with metadata, maybe for emulators?
> Yes, as part of this current work to improve the compatibility of the
> .TAP files I will be adding a command line option of load a file from
> start up.
Very useful. That will make it possible to run an Ace program from the command
line, from a bash script, from a desktop icon or from the system menu...
Marcos
Lawrence Woodman
> El/Je/On 2010-08-04 15:11, Lawrence Woodman escribi� / skribis / wrote :
>
>
>> Steve wrote:
>>
>>> BIA will do this with all three parts of the game. So the physical tape has
>>> the first part ( header + data ) and three blocks of data.
>>>
>>>
>> I'm glad you pointed that out and will have to look at the structure of
>> the BIA file.
>>
>
> TAP files of course can have data blocks without a preceding header block. I
> think Ace Forth cannot save or load them (ZX Spectrum BASIC didn't), so those
> tapes need their own machine code loader, that simply calls the proper ROM
> routine with the missing header parameters. I suppose BIA is such a case,
> isn't it?
>
save_p() functions.
>> Yes, as part of this current work to improve the compatibility of the
>> .TAP files I will be adding a command line option of load a file from
>> start up.
>>
>
> Very useful. That will make it possible to run an Ace program from the command
> line, from a bash script, from a desktop icon or from the system menu...
>
I'm also thinking that it would aid automated testing of the emulator.