General Category > LisaList2
Is there any way to use a BLU disk image of a Widget drive with an emulator?
rayarachelian:
Hi @drybones99, some better news, I tweaked the tool a bit more and now both tags and data is a lot better, I'm able to run the "dir" command in Lisafsh tool and it's also able to recognize the MDDF, likely this is now working, though I don't have time today to test this in LisaEm due to work obligations.
I'll test this later and if all is good and I manage to fix other bugs I'll push the code to github, and cut a binary release as well.
I've uploaded the converted, xz compressed image to the thread here: https://68kmla.org/forums/index.php?/topic/59047-is-there-any-way-to-use-a-blu-widget-disk-image-with-an-emulator/&do=findComment&comment=631222
rayarachelian:
To add a bit more to this thread, it does seem that BLU has a slightly different tag format for Widget drives.
I have been able to update blu-to-dc42 so it works fine with ProFiles and was even able to boot LisaEm from a BLU image made of one my Profile drives.
The reason blu-to-dc42 wasn't working was because I started working with a BLU image made from a Widget, as I was attempting to add multi-sector read/write support to LisaEm to fully emulate the Widget specific protocol.
(As an aside, Widgets also emulate ProFiles which is why they're compatible, but LOS knows the difference and will use a Widget fully with the version 2 protocol if the ffffff block returns that version. Simply naming a drive "Widget-10" is insufficient - the protocol version must be changed to signify that multi block transfers are available.)
About a year back Tom Stepleton sent me a Widget image whose tags were off my two bytes when compared to a Profile image.
The only 2/10 machine that I have that has a Widget was behaving very weirdly with an early Floppy Emu, I don't recall if it's version B or A but it has an SD slot rather than an SDHC slot. I can look it up next time I turn it on. It's possible it needs a firmware update, but it was behaving very weirdly and I didn't know whether the Widget was bad or the floppy emu wasn't working, because when I tried to install LOS to that Widget by using the floppy emu, it would always fail during the copy.
However, BLU v0.9 boots up just fine and I was able to read images of the Widget over Xmodem and they transferred just fine. So that was puzzling as the drive works fine in BLU, but not in the LOS installer.
On a whim, last night I restored that weird image I got from Tom with the tags in the wrong place. And I was able to boot the Lisa 2/10 just fine off the Widget. This confirms the image wasn't damaged in the transfer and that the FILE ID tag is indeed supposed to be off by two bytes in the BLU format for Widgets. (And also there's an issue with the floppy emu.)
The floppyemu works just fine with two of my 2/5 machines, so that likely indicates some slight incompatibility with the 2/10. It does seem to boot the installer fine off of Disk 1, but when it tries to copy files to the Widget it fails either on disk 1, 2 or 3. I never got further than that. Likely the floppy boot loader works fine with floppy emu, but once the LOS kernel loads it behaves slightly differently than the floppyemu expects.
The next push of the blu-to-dc42 tool should work for both ProFiles and Widgets, though you wouldn't be able to boot off converted images originating from Widget drives since the boot blocks (and possibly loader) is different. (I would suggest adding them as a 2nd hard drive via a 2-port expansion slot in LisaEm if you need to access their files.)
I'm not 100% sure right now that I've correctly fixed the tags in the blu-to-dc42 when dealing with Widgets yet. I'll need to experiment some more, but likely by then I'll sort this out fully.
There may be a way to copy the boot block+loader blocks off a Profile, I'm not sure, I've not tested that. If that works, I might write a tool for that. I do plan to add Widget support to LisaEm in future releases, but that's a far lower priority right now so it won't be in 1.2.7.
So from this experiment, I infer that:
1. the specific Floppy emu version + firmware has issues on 2/10's (or at least it does on mine, so maybe I/O board issues, but it does work with a real floppy drive) and, more importantly,
2. BLU does deal with Widgets differently.
It's possible, but highly unlikely that Widgets use tags differently than ProFiles, as looking at the ROM source code it expects that the boot AA AA signature is always in tag bytes 4,5.
Edit: So I've used NeoWidEx to read the boot block off the Widget and I notice that indeed bytes 4,5 of the tag bytes are AA AA as expected, so this is confirmed as a BLU feature/bug. :)
I don't see anything in the PROREAD ROM call that behaves differently if the drive is a Widget or a ProFile.
The only mention of Widget in the ROM source is a change to the timeouts, but that affects all drives.
--- Code: ---0000| 0000 0004 FILEID .EQU 4 ; OFFSET TO FILEID
0000| 0000 AAAA BOOTPAT .EQU $AAAA ;FILEID FOR BOOT PATTERN
...
1ECE| ;-----------------------------------------------------------------------------
1ECE| ; Routine to boot from Profile hard disk attached to parallel port
1ECE| ; Sets up input parameters and then calls READ routine. If no error
1ECE| ; on return (carry not set), a jump to the loaded boot code is done.
1ECE| ;-----------------------------------------------------------------------------
1ECE|
1ECE| PROBOOT
...
1ED0| 227C 0001 FFEC MOVE.L #HDRBUFR,A1 ; set up ptr to save header
1ED6| 247C 0002 0000 MOVE.L #HDRBUFR+20,A2 ; ptr for data
...
1EEE| ; Now verify header and if OK, jump to startup program
1EEE|
1EEE| 3029 0004 MOVE FILEID(A1),D0 ; get file id
1EF2| 0C40 AAAA CMP #BOOTPAT,D0 ; is it a boot block?
1EF6| 6704 BEQ.S PBOOT ; continue if OK
1EF8| 7054 MOVEQ #BADHDR,D0 ; else set error code
1EFA| 6014 BRA.S HDSKERR ; and exit
...
--- End code ---
sigma7:
--- Quote ---I don't see anything in the PROREAD ROM call that behaves differently if the drive is a Widget or a ProFile.
--- End quote ---
The ROMs load the boot block of the Widget in ProFile fashion, ie. assuming 20 tag bytes then 512 data bytes.
Thereafter the RAM based code treats the Widget blocks as having 512 data bytes followed by 20 tag bytes.
Consequently, the boot block code in the ProFile is different from the Widget.
rayarachelian:
--- Quote from: sigma7 on June 24, 2020, 12:24:34 am ---
--- Quote ---I don't see anything in the PROREAD ROM call that behaves differently if the drive is a Widget or a ProFile.
--- End quote ---
The ROMs load the boot block of the Widget in ProFile fashion, ie. assuming 20 tag bytes then 512 data bytes.
Thereafter the RAM based code treats the Widget blocks as having 512 data bytes followed by 20 tag bytes.
Consequently, the boot block code in the ProFile is different from the Widget.
--- End quote ---
Oh, I see, I didn't realize that this was what was going on with the Widget images, thank you.
I saw something unexpected at the hexdump level tag wise with BLU images, but then somehow downloading a BLU image and then uploading it back always worked. Somehow I saw the tag bytes as being off by two bytes - that is AAAA happening at offset 0x512+2 rather than 0x512+4, but really it's in a totally different location after block zero.
So in reality BLU is treating the blocks as singular 532 byte blocks and doesn't care where the tags are, but it's only because dc42 separates them into two different streams that there are issues.
I'll modify the code to pick up tags differently between block 0 and the rest instead. I was offsetting the tags by two and inserting zeros at the front which is incorrect.
Thanks James.
sigma7:
--- Quote ---So in reality BLU is treating the blocks as singular 532 byte blocks and doesn't care where the tags are, but it's only because dc42 separates them into two different streams that there are issues.
--- End quote ---
Sorry no, BLU does know (or thinks it knows) where the tags are.
If you directly access the parallel port to read data from a ProFile, for each block you'll find the first 20 bytes are tags followed by 512 bytes data, with the blocks interleaved.
If you do the same with a Widget using the ProFile compatible commands (dunno about the Widget specific commands), for each block you'll find the first 512 bytes are data followed by 20 bytes of tags, with the blocks not interleaved (ie. interleaving is typically done transparently at the drive level).
However (IIRC), when BLU reads/writes hard disk images, it:
* deinterleaves/reinterleaves blocks when the device is a ProFile
* puts/expects tags at the end in each 532 bytes of the image (ie. re-orders tags and data when a ProFile is involved)The consequence of this is (supposed to be) that the image file always has the blocks in the OS level order, and the tags are always in the same place.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version