Print

[AlexTheCat123]

According to http://sigmasevensystems.com/xpf_xenix.html, Xenix does some weird stuff when determining the size of your hard disk. Despite the fact that it asks you for the size of the drive when running hdinit, it just seems to ignore this and automatically assumes that you're using a 5MB drive if you have a Lisa 2/5 and a 10MB drive on a Lisa 2/10. If you try to use a 5MB drive on a 2/10 or a 10MB drive on a 2/5, it throws errors and won't install correctly.

Since Xenix uses the I/O board ROM ID to determine what kind of system you have, would it be possible to change the ID of the 2/5 ROM to 88 and have my 2/5 work with a 10MB hard drive? I would just try this myself, but I can't find my EEPROM programmer right now.

[stepleton]

Hmm, I don't know... The boot ROM also cares about what kind of disk you have to a certain extent --- it contains a routine to check what kind of Lisa you have, and this entails the kind of disk you have, too. See SETTYPE defined at $1198 in the source code.

I'm not sure whether the DISKROM address that this routine checks ($FCC031) is the location of the I/O ROM ID or if it's some other byte.

I also don't know how Xenix checks to see what kind of Lisa you're using, but one possibility is that it checks the copy of the I/O ROM ID that the boot ROM puts in location $2A1. If it does, you could just try putting $88 in that byte via Service Mode and see if you can fool Xenix that way.

[Lisa2]

I have never tested this, but according to Ray's LisaFAQ:
"Using an EPROM programmer, you can read the stock EPROM and burn a new one, changing the ID byte (at offset $1141) from A8 to, for example, $89 . This will make Xenix think the machine is a 2/10, and you can use a 10 MB drive on the built-in parallel port"
See here:
https://lisafaq.sunder.net/lisafaq-sw-xen_about.html

[AlexTheCat123]

So I tried changing the ID at $2A1 to 88, but unfortunately that didn't work. The good news is that changing the value at $FCC031 to 88 worked perfectly and let me install onto a 10MB drive just fine!

After installing everything, I was curious about whether Xenix only assumes your drive size based on the ROM ID during the installation or if it does it each time it boots even after the installation is complete. So I booted into the OS without changing the ID to 88 and it kinda worked, but there was some weird behavior and occasional crashing. So it seems that you have to set the ID to 88 every time you boot into Xenix 

I might try to patch the Xenix boot floppy at some point to make it think that the ID is always 88, but I'm pretty busy with some bug fixing for the ArduinoFile as well as some Lisa PCB designs, so it could be a while before I get around to it!

[rayarachelian]

After installing everything, I was curious about whether Xenix only assumes your drive size based on the ROM ID during the installation or if it does it each time it boots even after the installation is complete. So I booted into the OS without changing the ID to 88 and it kinda worked, but there was some weird behavior and occasional crashing. So it seems that you have to set the ID to 88 every time you boot into Xenix 

Something to keep in mind is that the VIA timers are different between 2/5 and 2/10 - this might be causing the instability.

Here's the 3 places in the Xenix kernel where the IO ROM version is accessed. So possibly only one of these is involved in drive sizing code and you might be able to just patch that one. Would need to trace around further to see if the copied value is then accessed by some other code, etc.

Code: [Select]

1/00023aa6 (0 0/0/0) : 0839 0007 00fc c031        : .9.....1 :  106 : BTST.B     #$07,$00fcc031  SRC:clk:0000000041d2aa6f +20 clks
src/lisa/cpu_board/memory.c:lisa_rb_io:3535:@00fcc031| 22:04:07.9 1104325231
src/lisa/cpu_board/memory.c:getflopramaddr:1456: floppy_ram (fdir=0 wait=0 timer:-1) 00fcc031::(88) | 22:04:07.9 1104325231
src/lisa/cpu_board/memory.c:getflopramaddr:1486:rom version| 22:04:07.9 1104325231
src/lisa/cpu_board/memory.c:lisa_rb_Oxc000_flopmem:1700:floppy read byte value: 88 @ 00fcc031 pc:00023aa6| 22:04:07.9 1104325231
src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 88 'I' from @1/00fcc031 (@00fcc031) using 24-io| 22:04:07.9 1104325231
D 0:00000000 1:00000030 2:00000000 3:0000003c 4:0000ffff 5:00000000 6:00000080 7:00000001 .S..... imsk:7 pnd:3 (0/0/normal cx:1)SRC:
A 0:0002634e 1:00159094 2:00020409 3:00024cd6 4:000257c8 5:000257c8 6:00027314 7:00027308 SP:00000000 PC:00023aae SRC:
--                                                             
cpu68k.c:cpu68k_ipc:554:dt_AbsL @ 00023b4a target:00fcc031 opcode:0839| 22:04:07.9 1104325349
1/00023b46 (0 0/0/0) : 0839 0007 00fc c031        : .9.....1 :  106 : BTST.B     #$07,$00fcc031  SRC:clk:0000000041d2aae5 +20 clks
src/lisa/cpu_board/memory.c:lisa_rb_io:3535:@00fcc031| 22:04:07.9 1104325349
src/lisa/cpu_board/memory.c:getflopramaddr:1456: floppy_ram (fdir=0 wait=0 timer:-1) 00fcc031::(88) | 22:04:07.9 1104325349
src/lisa/cpu_board/memory.c:getflopramaddr:1486:rom version| 22:04:07.9 1104325349
src/lisa/cpu_board/memory.c:lisa_rb_Oxc000_flopmem:1700:floppy read byte value: 88 @ 00fcc031 pc:00023b46| 22:04:07.9 1104325349
src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 88 'I' from @1/00fcc031 (@00fcc031) using 24-io| 22:04:07.9 1104325349
D 0:0002634e 1:00000030 2:00000000 3:0000003c 4:0000ffff 5:00000000 6:00000080 7:00000001 .S..... imsk:7 pnd:3 (0/0/normal cx:1)SRC:
A 0:0002634e 1:00159094 2:00020409 3:00024cd6 4:000257c8 5:000257c8 6:00027314 7:00027308 SP:00000000 PC:00023b4e SRC:
--                                                         
1/000012dc (0 0/0/0) : 13f9 00fc c031 0001 206d   : .....1...m :  294 : MOVE.B     $00fcc031,$0001206d  SRC:clk:0000000046dc9a85 +28 clks
src/lisa/cpu_board/memory.c:lisa_rb_io:3535:@00fcc031| 22:06:10.5 1188862597
src/lisa/cpu_board/memory.c:getflopramaddr:1456: floppy_ram (fdir=0 wait=0 timer:-1) 00fcc031::(88) | 22:06:10.5 1188862597
src/lisa/cpu_board/memory.c:getflopramaddr:1486:rom version| 22:06:10.5 1188862597
src/lisa/cpu_board/memory.c:lisa_rb_Oxc000_flopmem:1700:floppy read byte value: 88 @ 00fcc031 pc:000012dc| 22:06:10.5 1188862597
src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 88 'I' from @1/00fcc031 (@00fcc031) using 24-io| 22:06:10.5 1188862597
src/lisa/cpu_board/memory.c:dmem68k_store_byte:484::::::WRITE BYTE 88 'I' to @1/0001206d using 17-ram| 22:06:10.5 1188862597
D 0:00000000 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:00000000 7:30000000 .S..n.. imsk:5 pnd:3 (0/0/normal cx:1)SRC:


Following up on the above hits - I'm guessing 0x2a is stored in address 1d35c as some sort of timing parameter value for I/O ROM 88, not sure what the value here would be for A8 as that path was not taken, so not part of the tracelog, but it's good to know this location for future use, so if that's true, we shouldn't modify this code path (starting with the BTST #7 at 1/000012e6 )

Code: [Select]

1/00001316 (0 0/0/0) : 23fc 0000 002a 0001 d35c   : .......... :  414 : MOVE.L     #$0000002a,$0001d35c  SRC:clk:0000000046dc9af7 +28 clks

This path starting here calls a printf, so likely this is the kernel reporting on the I/O ROM:

Code: [Select]

1/000010d4 (0 0/0/0) : 0839 0007 0001 206d        : .9.....m :  106 : BTST.B     #$07,$0001206d  SRC:clk:0000000046f490cf +20 clks
src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 88 'I' from @1/0001206d (@0001206d) using 17-ram| 22:06:13.0 1190432975
D 0:00000000 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000010dc SRC:

1/000010dc (0 0/0/0) : 6744                       : gD       : 1054 : BEQ.B      $00001122  SRC:clk:0000000046f490e3 +8 clks
D 0:00000000 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000010de SRC:

1/000010de (0 0/0/0) : 1039 0001 206d             : .9...m   :  287 : MOVE.B     $0001206d,D0  SRC:clk:0000000046f490ef +16 clks
src/lisa/cpu_board/memory.c:dmem68k_fetch_byte:406::::::READ BYTE 88 'I' from @1/0001206d (@0001206d) using 17-ram| 22:06:13.0 1190433007
D 0:00000088 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000010e4 SRC:

cpu68k.c:cpu68k_ipc:622:dt_ImmL @ 000010e6 target:000000e0 opcode:0280| 22:06:13.0 1190433023
1/000010e4 (0 0/0/0) : 0280 0000 00e0             : ......   :   42 : AND.L      #$000000e0,D0  SRC:clk:0000000046f490ff +16 clks
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000010ea SRC:

cpu68k.c:cpu68k_ipc:622:dt_ImmL @ 000010ec target:00000080 opcode:0c80| 22:06:13.0 1190433039
1/000010ea (0 0/0/0) : 0c80 0000 0080             : ......   :  176 : CMP.L      #$00000080,D0  SRC:clk:0000000046f4910f +12 clks
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .Sz.... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000010f0 SRC:

1/000010f0 (0 0/0/0) : 6700 00c4                  : g...     : 1038 : BEQ.W      $000011b6  SRC:clk:0000000046f4911b +8 clks
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .Sz.... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000011b6 SRC:

1/000011b6 (0 0/0/0) : 2d7c 0001 1000 fff6        : ........ :  411 : MOVE.L     #$00011000,$fff6(A6)  SRC:clk:0000000046f49125 +24 clks
src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00011000 ' BQ ' to @1/00f007da  using 17-ram| 22:06:13.0 1190433061
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:000011be SRC:

1/000011be (0 0/0/0) : 6000 ff50                  : ...P     : 1032 : BRA.W      $00001110  SRC:clk:0000000046f4913d +8 clks
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007d0 SP:00000000 PC:00001110 SRC:
cpu68k.c:cpu68k_ipc:622:dt_ImmL @ 00001116 target:00011021 opcode:2f3c| 22:06:13.0 1190433095
cpu68k.c:cpu68k_ipc:554:dt_AbsL @ 0000111c target:00005ec2 opcode:4eb9| 22:06:13.0 1190433095
1/00001110 (0 0/0/0) : 2f2e fff6                  : ....     :  362 : MOVE.L     $fff6(A6),-(A7)  SRC:clk:0000000046f49147 +24 clks
src/lisa/cpu_board/memory.c:dmem68k_fetch_long:458::::::READ LONG 00011000 ' BQ ' from @1/00f007da (@00f007da) using 17-ram| 22:06:13.0 1190433095
src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00011000 ' BQ ' to @1/00f007cc  using 17-ram| 22:06:13.0 1190433095
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007cc SP:00000000 PC:00001114 SRC:

1/00001114 (0 0/0/0) : 2f3c 0001 1021             : ......   :  410 : MOVE.L     #$00011021,-(A7)  SRC:clk:0000000046f4915f +20 clks
src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00011021 ' BQ!' to @1/00f007c8  using 17-ram| 22:06:13.0 1190433119
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007c8 SP:00000000 PC:0000111a SRC:

1/0000111a (0 0/0/0) : 4eb9 0000 5ec2             : N.....   :  756 : JSR.L      $00005ec2 PRINTF?  SRC:clk:0000000046f49173 +20 clks
src/lisa/cpu_board/memory.c:dmem68k_store_long:531::::::WRITE LONG 00001120 '  R ' to @1/00f007c4  using 17-ram| 22:06:13.0 1190433139
D 0:00000080 1:00002500 2:00000400 3:0001e800 4:0000ffff 5:00000000 6:000004f3 7:300004f4 .S..... imsk:5 pnd:3 (0/0/normal cx:1)SRC:
A 0:00011845 1:00000000 2:00f5fea4 3:000201d0 4:0002026c 5:00fcc001 6:00f007e4 7:00f007c4 SP:00000000 PC:00005ec2 SRC:
[code]

So likely it's elsewhere it checks for the disk size, possibly in the mkfs/hdinit command as well - or only there?

UniPlus has partition tables for different drives hardcoded in the kernel was playing with that some months ago along a similar path. Not sure if Xenix does the same or not and whether the ProFile driver baked into the Xenix kernel also checks the IO ROM version, but doesn't appear to in this tracelog, but possibly I had turned it on too late, or off too early and missed it.

Hopefully the above captures will help in the future with something.