General Category > LisaList2
Is there any way to use a BLU disk image of a Widget drive with an emulator?
patrick:
Neither ProFile nor Widget distinguish between tags and data. They just take 532 bytes in consecutive order and store them as one block. Data transfer inside the drive is controlled by a DMA counter. Any meaning behind these bytes comes from the OS. I have no idea why Apple reversed the order for Widget, but there is definitely no technical reason.
Same applies to IDEfile, but here you can store up to 1024 bytes in a block (two IDE sectors).
sigma7:
--- Quote ---Any meaning behind these bytes comes from the OS. I have no idea why Apple reversed the order for Widget
--- End quote ---
I suspect the reason was intended to be performance: calculating a checksum to be put in the tags can be done concurrently while bytes are written when the tags come last, but requires an extra scan of the block prior to writing when the tags come first.
... but that's a guess.
rayarachelian:
So here's why it was confusing.
Hex dump of a profile via blu:
--- Code: ---00000000 50 52 4f 46 49 4c 45 20 20 20 20 20 20 00 00 00 |PROFILE ...|
00000010 03 98 00 26 00 02 14 20 00 00 ff ff ff ff ff ff |...&... ........|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
...
000001c0 fd fa 00 00 00 00 00 00 00 00 db 6d db 00 50 52 |...........m..PR|
000001d0 4f 46 49 4c 45 20 20 20 20 20 ff ff ff ff ff ff |OFILE ......|
000001e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
000001f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000200 4c 69 73 61 20 48 44 20 49 6d 67 20 42 4c 55 56 |Lisa HD Img BLUV|
00000210 30 2e 39 30]4e fa 00 16 aa aa 08 50 22 4a 2c f8 |0.90N......P"J,.| <- start of sector after the bracket at 0x214
00000220 28 76 00 1e 00 00 00 00 00 00 00 00 20 38 02 a8 |(v.......... 8..|
...
000003f0 6a 08 10 10 66 04 10 bc 00 02 41 fa fe 18 d0 fc |j...f.....A.....|
00000400 00 0e 31 d0 02 10 42 a7 42 a7 42 a7 41 fa fe 06 |..1...B.B.B.A...|
00000410 d0 fc 00 08]00 00 00 21 aa aa 82 00 ff ff ff 56 |.......!.......V| <- sector 0 ends at 0x413, tags start at 0x414
00000420 00 00 ff ff ff ff ff ff] 81 a4 00 01 00 03 00 03 |................| < tags end at bracket 0x427, sector 1 starts.
00000430 00 00 00 5f 00 01 ff 00 00 00 00 00 00 00 00 00 |..._............|
--- End code ---
But here's the Widget.
--- Code: ---00000000 57 69 64 67 65 74 2d 31 30 20 20 20 20 00 01 00 |Widget-10 ...|
00000010 1a 43 00 4c 00 02 14 02 02 02 13 00 00 4c 00 00 |.C.L.........L..|
00000020 00 00 00 00 00 01 80 80 00 00 00 00 00 00 00 00 |................|
...
00000200 4c 69 73 61 20 48 44 20 49 6d 67 20 42 4c 55 56 |Lisa HD Img BLUV|
00000210 30 2e 39 30]4e fa 00 16 aa aa 08 50 22 4a 2d 0c |0.90N......P"J-.| <- sector starts at 0x214 same as ProFile
00000220 28 76 00 1e 00 00 00 00 4e fa 00 16 aa aa 08 50 |(v......N......P|
...
000003f0 02 07 0c 01 06 0b 20 7c 00 00 01 b3 22 7c 00 fc |...... |...."|..|
00000400 c0 31 10 11 6a 08 10 10 66 04 10 bc 00 02 41 fa |.1..j...f.....A.|
00000410 fe 18 d0 fc]00 00 aa aa 82 00 ff ff ff 00 00 00 |................| < sector ends at 0x413 tags start at 414 but aa,aa is now in the wrong place
00000420 ff ff ff ff ff ff 21 2f 00 00 00 84 00 00 80 85 |......!/........|
--- End code ---
So this is what I was seeing and getting confused by. But yeah, if I flip the sector start and tags around then, it makes more sense. And fun thing here. That's a hack. The tags now start at the right place. But that 4efa is a jmp:
https://onlinedisassembler.com/odaweb/ provides this disassembly for the tag!
The first opcode is a JMP to the start of the sector, that's how and why this stupid thing works. Wow. I mean, why.
--- Code: ---.data :00000000 1600fa4e jmp %pc@(0x00000018)
.data :00000004 aaaa .short 0xaaaa # required AA,AA tags
.data :00000006 4a225008 bchg #74,%a0@
.data :0000000a 0c2d movel %a4,%fp@-
--- End code ---
But beyond that, it's still the case that tags for Widget BLU images, but not sectors are shifted two bytes to the left, where the fileid is at bytes 2,3 rather than 4,5 in the tags, so I have to shift them over.
Replacing the boot sector and boot loader with those from a ProFile results in 10726 (boot device not found) when booting, so more is needed to getting booting. I think there's some file somewhere that controls the boot process, and possibly it's different between widgets and profiles. I've seen this before when I've tried to move a ProFile from the motherboard parallel port to a dual parallel card and tried to boot off it, or perhaps it's got a different device path.
I guess a hint to this is that the Preferences panel has a list of device drivers and devices.
Edit: so I extracted both the source profile and the modified widget and found these files are different, gotta be one of these:
--- Code: ---Binary files CIBTNDATA.bin and ../widget-test.d/CIBTNDATA.bin differ # has to do with printers
Binary files DWBTNDATA.bin and ../widget-test.d/DWBTNDATA.bin differ # has to do with printers
Binary files FONT.HEUR.bin and ../widget-test.d/FONT.HEUR.bin differ # fonts I presume
Binary files INTRINSIC.LIB.bin and ../widget-test.d/INTRINSIC.LIB.bin differ # not sure why
Binary files LCORBGLIB.OBJ.bin and ../widget-test.d/LCORBGLIB.OBJ.bin differ
Binary files PARBTNDATA.bin and ../widget-test.d/PARBTNDATA.bin differ # seems to be about device connections - maybe this one
Binary files shell.Office_System.bin and ../widget-test.d/shell.Office_System.bin differ # not sure why
Binary files SYS2LIB.OBJ.bin and ../widget-test.d/SYS2LIB.OBJ.bin differ
--- End code ---
Though some of these might be false positives - Running strings against them, I see shell.Office_System has a slightly different version, one is 3.1 the other 3.0, so that might be another issue here.
sigma7:
--- Quote ---it's still the case that tags for Widget BLU images, but not sectors are shifted two bytes to the left
--- End quote ---
I suppose that could be a BLU bug :-\ but funny it would take this long to show up.
However, block 0 is special, so don't use it as a template.
When writing a boot block to a Widget using a Widget driver, one sets the first part of the data field (to pretend) to be the tags the ROM would expect from a ProFile, as block 0 will be loaded using ProFile code. The block 0 Tag field will be loaded as the last 20 bytes of the data field, so if the boot code was more than 492 bytes, the excess code would need to be put in the Tag field before writing to the Widget. If the code is not more than 492 bytes, then the Tag field might contain garbage.
--- Quote ---The first opcode is a JMP to the start of the sector... why
--- End quote ---
My guess is that the boot ROM was developed before the ProFile format/tag arrangement was finalized, and someone decided that execution might as well start at the first byte loaded from the disk, then inertia prevented any changes. Or perhaps it was left as an easter egg to annoy Ray.
--- Quote ---when I've tried to move a ProFile from the motherboard parallel port to a dual parallel card and tried to boot
--- End quote ---
I believe (aka imagine) that:
* most environments' boot blocks will only work with the built-in port
* in MacWorks Plus 1.x, Chuck added a boot block version that would work from a dual parallel card*; however it was not interchangeable with the internal port boot block (the version installed depended on where the drive was attached; it is possible this was slot dependent as well)
* in MacWorks Plus II, an attempt was made to have boot blocks that work from dual parallel cards and internal ports, but it was still device dependent (ProFile/Widget)
* in BLU, an attempt was made to have boot blocks that work from dual parallel cards and internal ports, and be device independent (ProFile/Widget)*It is possible that the boot block for the dual parallel card predated Chuck and was originally written for MacWorks XL
rayarachelian:
--- Quote from: sigma7 on July 08, 2020, 04:41:30 pm ---
--- Quote ---The first opcode is a JMP to the start of the sector... why
--- End quote ---
My guess is that the boot ROM was developed before the ProFile format/tag arrangement was finalized, and someone decided that execution might as well start at the first byte loaded from the disk, then inertia prevented any changes. Or perhaps it was left as an easter egg to annoy Ray.
--- End quote ---
Yeah, so, that was a rhetorical why. :)
The technical why of the JMP opcode is obvious, they why of why swap the location of the tags is more of the question. Most likely it was Macintosh related since Mac OS didn't use the tags*, and there was a push to move to the XL, and doing so would avoid reading an extra 20 bytes per block, ending the transfer a little bit early, thus you can get a 4% speedup and if the Lisa runs at 5MHz, but the Mac runs at 8MHz because it uses a better memory vs display interleave (and possibly faster DRAM), then yeah, you'll want any increase in access you can get.
* it's possible the very early versions of the early Mac OS did use tags, but they were planning on removing the need for them and this drove the decision to move the tags to the end.
What's really interesting to me is that if you've ever really seen a Mac 128 in action, you'll realize how insanely slow it was vs a Lisa. This isn't because of the CPU speed, but rather because of the lack of memory and lack of a hard drive. The Lisa had a huge advantage over the 128, 512k, and 512KE. Only when the Plus with it's 1MB of RAM and SCSI port was released could the Mac really compete against the Lisa.
The early Mac 128 was a complete shit show of floppy swapping, even for normal operations, and those drives were very very slow. You'd need at least a second external floppy to make use of the 128 without a having to swap 5-10x each time you did anything interesting. The 512K could potentially use the HD20, but that hard drive was introduced on September 17, 1985, quite a bit after the April 29, 1985 discontinuation of the Mac XL.
Because of this, a Lisa with a ProFile or Widget was far more advantageous than the highest end Mac available. At least until the Plus with an external SCSI drive. And getting a 4% speedup in disk access would certainly help. It's certainly funny to call the Lisa a speed demon, but a Mac XL 2/10, when compared to the Mac 128, even with the addition of an external floppy drive, it certainly is a lot more like a "Maserati for the Mind", than the Mac could possibly be.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version