Yesterday, while using OSDK, I faced up a very little challenge.
On one hand I had my welcome picture, alone on a tap file(colored via euphoric since pictconv failed with the -f1 switch, and then saved via Euphoric). Let's say I called it picture.tap
On the other hand I had my Introduction program : it is written in Basic in a text file (thus to be built with OSDK), this same program is suppose to load the picture.
Thus on the K7 Tap file, I needed two files in this order :
1) intro.bas
2) picture.s
What I missed a lot was a tool to put in the same tap file what I obtained in two separate tap files (the intro.bas in the intro.tap built with the osdk), and the picture.s in the picture.tap built with Euphoric (with CSAVE)
I did my small tool in Delphi in order to concatenate the two tap files. It is working, but...
This kind of tool could be very usefull in the OSDK
Here are my questions ?
I have concatenated my two files without removing any tep header or tap trailer, is it correct ?
I did not put any "silence" between my two files : should I put one ? If yes, how many byte length should it be ? Is it made of 0 values or some others ?
thanks for help
New tool needed:Tap File splitter/concat & k7 questions
Yes it's correct. A multi-part TAP file is nothing but concatenated TAP files. So the headers have to be there! (the synchro must be at least 3 bytes of value #16, and 1 byte value #24, then the usual header with start, end addresses, program name and so on...)I have concatenated my two files without removing any tep header or tap trailer, is it correct ?
I suspect no tool was made because with MS-DOS, for instance, all you have to do to concatenate files is:
Code: Select all
copy /b file1.tap + file2.tap +... + filexx.tap bigfile.tap
NoI did not put any "silence" between my two files : should I put one ?
Thank you very much Symoon
@DBUG
The problem with lines of DATA in a program is that, you will fill the memory of the ORIC twice : once for the lines of DATA, once for the screen.
therefore, I prefer to fill in the memory from a file of the the tape rather
than from extra lines of code.
Of course, for the intro part of my program, this is not a big deal since the BASIC do not represent a lot of memory consumption, but I prefer to take some good habits.
@DBUG
The problem with lines of DATA in a program is that, you will fill the memory of the ORIC twice : once for the lines of DATA, once for the screen.
therefore, I prefer to fill in the memory from a file of the the tape rather
than from extra lines of code.
Of course, for the intro part of my program, this is not a big deal since the BASIC do not represent a lot of memory consumption, but I prefer to take some good habits.
Something which could be nice, is probably to get a BASIC version of the file depacker. Or perhaps an easy to use, relocatable version of the assembly code routine.
In average pictures compressed with filepack are about 50% the original size, this can be I guess interesting for people using BASIC
Something like that:
In average pictures compressed with filepack are about 50% the original size, this can be I guess interesting for people using BASIC
Something like that:
Code: Select all
10 DOKE #2xx+0,Adress of the picture
20 DOKE #2xx+2,#A000 ' Or anywhere else
30 CALL #400 ' Or anywhere else the routine was installed