reading a file with basic from a t64 file:
each 192nd byte is lost when reading from Basic (tested with gtk 3.10, pet 8032, VIC20, C64)
also with vice 2.4 (pet 8032)
reproduce:
Attach an empty d64 file to cbm 8032
10 open1,8,4,"testseq,seq,write"
20 fori=1to1000
30 print#1,"this is a test #"+str$(i)
40 next
50 close1
detach d64
Copy it to t64 with a tool of your choice.
Attach t64 in pet 8032, VIC20, C64:
and print only if status is not 0:
10 open1,1,0,"testseq"
15 i=0
20 input#1,a$:i=i+1
25 ifst=64thenprinta$
27 if i=198 then end
30 goto20
Output:
s is a test # 1
thi is a test # 11
this is a test 20
this isa test # 30
this is a test # 39this is a test # 40
this is a tst # 49
thi is a test # 59
this is a test 68
this isa test # 78
this is a test # 87this is a test # 88
this is a tst # 97
this is a test # 06
this is a test # 115this is a test # 116
ths is a test # 125
this s a test # 134
this is test # 143
this is a tst # 152
this is a test# 161
this is a test # 70
this is a test # 179this is a test # 180
ths is a test # 189
this s a test # 198
counting bytes, display if status not 0:
10 open1,1,0,"testseq"
15 i=0
20 get#1,a$:i=i+1
25 ifst=64thenprinta$,i
30 goto20
run
s 1
i 191
382
s 573
9 764
t 955
i 1146
1337
s 1528
7 1719
t 1910
2101
5 2292
h 2483
2674
2865
t 3056
t 3247
3438
9 3629
Regarding my documentation st=64 is end of file on input.
would you tell what tool you have been using to create that t64? And attach the exact same one you are using to reproduce the problem?
Since loading stuff (as in programs) from t64 works just fine, i have my doubts with anything not working there
I used DirMaster, but i know it has some nonsense trailing bytes and the export of DirMaster can give the wrong file with tailing additional characters. But extracting the file with the tape command of c1541 gets the correct original.
But I think if this is a problem then at the end of the file and not in the middle.
Do you gave an alternative tool which Ican try?
Last edit: Anselm D 2026-11-05
Another way:
extract file from d64 with c1541:
c1541 -attach test.d64 -read testseq,s
rename the file testseq to testseq.prg
Use
t64emp096.zip
T.E.M.P
T64 Extraction and Manipulation Program
Version 0.96 JUL 2009 by MCbx
to add it to a t64
Does the t64 distinguish between seq and prg?
Moving the seqfile form d64 to t64 in dirmaster, is shown as prg. DirMaster does not allow to change it.
But changing seq in prg in d64 and move it to t64 (also only shown as prg) an saved is giving different t64.
Byte 41 is different
for seq it is 1
for prg it is 2
Does vice distinguish?
I remember fixing a bunch of t64 related things, but those were all related to PRG files IIRC. Are SEQ files really handled differently on tape? ie is there a difference besides the actual file type indicator? (On disk its the same thing, just different directory entry)
In vice both are shown as prg. I will try to extract with c1541 and tape command.
Thats not the point - the question is if they are really handled differently on tape
ie, if you do the above using ,p,w and ,p,r instead, does it work the same?
as far as i know
s,r
s,r
p,r
p,w
is only used for disk access. It does not work for tapes.
For tape the third parameter of the open command, the "secondary address" is used to access a (real) tape.
0: read file
1: write file + end-of-file-markeron CLOSE
2: write file + eof + end of tape marker on CLOSE
As far as i know, vice can not write to t64 with open command.
So in the 1st step I am only use DirMaster to create two t64, one with seq flag and one with prg.
2.
a) change file type in d64 from seq to prg
b) Drag and drop the prg file from d64 to t64. Save t64
I tested both with the following program:
I can not see any differences on vic20 and c64, but for 8032:
T64-Files, d64 and Screenshots are attached.
bzw i think also the first 3rd three bytes are lost.
This one is a t64 file created by TEMP v0.69
extract file from d64 with c1541:
c1541 -attach testseq.d64 -read testseq,s
rename the file testseq to testseq.prg
Use
t64emp096.zip
T.E.M.P
T64 Extraction and Manipulation Program
Version 0.96 JUL 2009 by MCbx
It behaves like the seq version from DirMaster.
Last edit: Anselm D 7 days ago
Another way to create the prg and seq variants in DirMaster is to rename the file extracted by c1541. Add the extensions .prg / seq and drag and drop them to an empty t64 file in DirMaster.
Last edit: Anselm D 7 days ago
This one is from droid v0.5
for pet8032 it behaves like the prg version of DirMaster
Additional information regarding the prg-DirMaster version.
The different output is only in the first run. Stopping it and running it again it behaves like the seq version.
Doing a "reset machine CPU" and it runs in the same ways as in the first run.
Regarding cbm 8032:
"Kernal traps for Device #1 (required for t64)"
is grey and deactivated. I am not able to activate it. For C64 and VIC20 it is not grey,
I can only activate it in this way: attach a tape image with autostart. Afterwards
"Kernal traps for Device #1 (required for t64)" is activated and t64 can be used.
Typically i an doing a "reset machine CPU" and then start with the tests.
In the error condition i am getting status 64 (0x40):
Question:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/tags/v3.10/vice/src/tape/tape.c#l388
is len the length of a buffer or the length of the file?
Have you considered using proper TAP files instead T64? They are much better supported by VICE. T64 is just a legacy format from the earliest days of C64 emulation and the support for it in VICE is very minimal.
Have you considered using proper TAP files instead T64?
They are much better supported by VICE.
T64 is just a legacy format from the earliest days of C64 emulation and the support for it in VICE is very minimal.
The advantages of t64
light weighted, fast, small, extract is supported by c1541 tape command
contra: tap is large, slow, no support in c1541
pro: can deal with fast loader, copy protection (not really important)
I tested tap. I am able to write and to read seq files. I tried to extract with
tape64 V1.2 (c) 07/09/1999 by Andreas Matthies
this works for a small file but not for my example files:
Output:
Results of processing:
Input: testtape64seq.tap Type: TAP-File
Version : 1
Speed of tape: 1.0
Output: (None)
C2N-Triggers : 1533358
Programs loadable: 0
Programs with load error: 7
Last program didn't finish before end of input file
You are saying T64 support is minimal, the support mentioned in the VICE documention seems to be fine:
Vice Documentation:
“The legacy T64 format is supported partially, and it has several drawbacks. (see section 17.2 The T64 tape image format) It is only supported read-only, and the cassette is automatically rewound when you reach its end. Most importantly T64 support is only available via virtual device traps, which have to be enabled in the options. (The emulator will temporarily enable it when autostarting programs from these containers.)”
“The T64 File Structure was developed by Miha Peternel for use in the C64S emulator. Since the format has various drawbacks (see further below), we recommend to use other formats (D64, TAP, P00 - depending on the usecase). “
Notes ( I think this are the mentioned draw backs?):
So it is read only, 1,2, 5 are okay
3 is good
So from the perspective of the documentation the limitations of t64 are okay.
I am trying to understand the difficulties. I the source code I can see:
I understand this is terrible, I started vice with debug options I don’t see a warning. So I hope this means the t64 is not one of the corrupted.
Is think the main problem is or was, there are no official specs for T64, only implementations?
The idea itself seems to be nice, so why are there no further developments but a legacy declaration?
"Kernal traps for Device #1 (required for t64)"
Can you please give me some explanation. Is this some kind of API hook?
For each ROM version you are trapping the tape ROM routines? Take the data from t64 and inject it to the RAM Addresses and then return back to ROM execution?
Seems to be a hell of work and this can only be provided by known and provided ROMs from VICE?
I think t64 is still widely used but mainly for stored programs and not seq files.
I can understand if you do not like to fix it.
But i would like to know, are my tests and my conclusion that there are bugs correct?
Only for your interest:
This does not influence the results of the test i made before!
I did some tests with tap and read access. I was astonished tape read and disk read is different according the status variable and zero byte eof marker
From the book "Programming the PET/CBM (Raeto West"):
page 69/get:
page 238:
page 240:
for further studying:
Compute! Magazine Issue 042 : Free Download, Borrow, and Streaming : Internet Archive
https://archive.org/details/1983-11-compute-magazine/page/238/mode/1up
64 Explorer:
https://www.atarimagazines.com/compute/issue41/64_EXPLORER.php