Closed G4DDS closed 1 month ago
Hi, you can add TAP files be either dragging the TAP file from its file folder to the partition you have selected or using the "Add File(s)" button on the bottom when your viewing a partition. (Add them as code files)
I didnt realise +3e supported TAP files, I will have to try that. I know it sort of supports z80 and SNA files.
Alas, it seems the version i have (which i think is the latest, V1.43) doesn't support it. So is this an unofficial modifcation of the +3E roms?
I have just managed to add the file as you suggested (using add a code file) - it's strange because I could have sworn I had tried that. Incidentally, I noticed a minor typo - when viewing partition details, the first column is mis-spelt as "Fileame" (missing 'n').
The modified ROMs with the TAP support are available here https://octocom.speccy.org/workbench_en.html and I am unsure who did these. I will have to re-burn my EPROMs at some point to test this feature.
One thing I was wondering, currently I am using Win32DiskImager to image my SD card, I then use this image with your program and make the necessary updates before re-burning the updated image back to my SD card. For a change which takes a couple of minutes to perform using your program, the reading and writing takes almost an hour in total (on a 16GB SD card), is there a way your program can read and write directly to the SD card?
Thanks for that. I have corrected the spelling. I really need to move all of that out to a separate class so i can do multiple language support. I shall take those roms and take a look. Would be interested if they work with my Harlequin board.
As for using it directly on an SD card, For Windows I really don't know. On Linux, you can just fire it up on the command line and specify the device, as sudo java -jar HDDFileEditor-linux-x86_64.jar /dev/sdxxx
I assume you would have to find the disk device number, Possibly using
Get-PhysicalDisk | Select -Prop DeviceId,FriendlyName,SerialNumber
in an administrator powershell, then firing up the program from the commandline, eg
Java -jar HDDFileEditor-win-86_64.jar \Device\Harddiskx
where x is the device number.
I think i will have to experiment. Which alas means getting Windows working again. Ho hum :)
Should possibly add "properly support raw device access" to the todo list as well.
Ok, apparently it doesnt work like that on Windows. I cant currently suggest anything, but will look at it next week when i get home
Apparently to get it to work, i will have to switch to the NIO classes as normal filestreams try to use flags that aren't compatible with raw windows devices, EG,
pathname = "\\.\PhysicalDrive0"; Path diskRoot = ( new File( pathname ) ).toPath(); FileChannel fc = FileChannel.open( diskRoot, StandardOpenOption.READ, StandardOpenOption.WRITE ); ByteBuffer bb = ByteBuffer.allocate( 4096 ); fc.position( 4096 ); fc.read( bb ); fc.position( 4096 ); fc.write( bb ); fc.close();
This may be worth doing anyway as the NIO classes seems to be a better way of doing low-level file access. I will work on this, but it may be a while.
Thanks for looking into this. Just out of interest, do you have a DivMMC?
I have been trying to load a TAP (transferred using your program), but when I enter the command SPECTRUM "name.tap" it just crashes after a couple of seconds of SD accesses. However, whilst I was checking that I had burned the correct EEPROMs, I discovered that the dvmen3e original and mod files appear to the same in both zips:
This looks very strange. I am going to send an e-mail to the address on the Workbench +3e page to see what they reckon.
I'm still not sure about the ROMs (see above) but I have had another thought why the TAP file may be crashing. When you add the TAP file it gives it a (start) address of 32768, is this correct? I wonder if its crashing because the TAP file is being loaded at the wrong address.
Hi, i dont have a DivMMC, i use the simple 8-bit interface.
I would be surprised of the address of the TAP file had anything to do with anything, as TAP is a continer, and any data loaded from it would rely on the headers and loaders within the tap file itself. It may be worth trying adding it as headerless using the "Add file(s)" button and then "Select CPM file" to see if that makes a difference.
There are a few ways i could think of implementing TAP support in the +3E roms, but most of these would only work on 48K games, as there is a good chance any 128k game would overwrite the Dos variables in page 7 or the hard disk buffers at the start of page 1.
They would also need to use the loader in the 48k Rom, which is what would be patched.
While this is true of a lot of TAP files, its not all, for instance, a lot of the Players games use their own custom loader, but as they load at the same speed as the Rom, so will fit in a TAP files. (Tap files are only good for standard loading speed and simple loader styles, which is why TZX is preferred these days. (the chance of a ROM based solution for TZX is minimal) )
[removed as it doesnt seem to work, use file below]
Try this and see if it works. Its a copy of Decathlon which has been hacked to use the Rom loader. (please tell me when your done, as i should probably delete this after you are finished)
Regards Graham.
Ok, I have done my own testing, and found out you need to add the tap file as a headerless (CPM) file. (Also , the example file above doesnt quite work properly for some reason)
Thinking about it, it does make sense that it needs a headerless file, as the basic header for speccy files will only work up to 64K, and adding larger files as code files would mess this up and probably cause hilarious consequences for block counts et al.
I have added another TODO to deal with this.
Ok, try these files, they work for me. Dont forget to add them as CPM files. (If you unzip them to a folder, you can just use "Select CPM file" and add them all in one go)
It looks like then you need to
Spectrum "file.tap" load "t:" load ""
Or use the octocom desktop
Thanks for the guidance. I added those files and just tried to load THRUST, but it crashes as before. My setup fails at the SPECTRUM command (so I don't even get to the LOAD commands) where it seems to try and load the game with a garbled thrust loading screen appearing before it freezes.
I have been looking at the TAP modified ROMs supplied for the other interfaces and comparing them with their original non-TAP ROMs and I am convinced that the DivMMC "modified" ROMs are just the originals renamed and do not have any TAP loading facilities. I have been trying to contact Garry Lancaster and the Octocom people but have had no luck so far.
Good luck. I can confirm that the 8-bit IDE ones work subject to the limitations above.
Meanwhile, i will get back to you once i have tried to deal with the raw disk issue (If its possible on Windows under Java).
It also seems I introduced a bug in file detection (it seems if it cant identify a file, it treats it as a microdrive file, ho hum). Another one for the list...
Hi, i have had to give up on Raw devices in Windows. it seems that Java just doesn't support it at the moment. Raw devices will be available read-only when i do the release, but will throw an error if you dry to drop a file on it. Annoyingly, it seems to work fine on Linux.
I have also noticed Drag and drop isnt working as well. I think its time for me to stort the issue list out properly.
Cant yet fix fully. If i find a way of writing to raw divices using Windows i will revisit this.
I noticed on this video https://www.youtube.com/watch?v=hRkE5swAVx8 that it is possible to load .TAP files directly using the modified +3e ROMs.
I tried to import a .TAP file into a partition but it just imports all the files directly so you are left with the BASIC, CODE, etc. files from inside the TAP.
Would it be possible to add an option to just import the whole TAP file itself so it just appears as a single file/entry in the partition so that it could be loaded as shown in the video?