|
|
Joined: Jan 2016
Posts: 76 Likes: 5
Member
|
Member
Joined: Jan 2016
Posts: 76 Likes: 5 |
So why doesn't the -speed actually speed up the floppy access speed? It seems super slow (much slower than real hardware) w/o -speed and just a little slow with a -speed 10 on the command line. Is this a case of a driver that needs to be tuned, or is there something more systemic in MESS that needs to be addressed?
It also looks like Venix is only seeing 10MB of the 48MB drive (ST-251-1) I've setup, even after partitioning with WUTIL, so I'll have to get to the bottom of that. I think I've seen this on semi-real hardware as well.
And when I boot off the hard drive for Venix after installing, I get a watchdog timer triggering and garbage on the screen. I know there's a stack overflow issue for automatic booting, but this was booting off with the 'W' command. Or is that the issue?
The good news is I can boot Venix 2.0 off floppies, do the install and generally mess around with it, though in a restricted environment. It's going much better than I'd thought it might.
I'll try the BSW enhancements to see if that helps or not.
|
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
|
Senior Member
Joined: Apr 2012
Posts: 193 |
So why doesn't the -speed actually speed up the floppy access speed? Good question. I am open to suggestions. The new floppy code is at least accurate, timing wise (same cannot be said from the WD2010/1010 hard disk controller code i cobbled together). And when I boot off the hard drive for Venix after installing, I get a watchdog timer triggering and garbage on the screen. I know there's a stack overflow issue for automatic booting, but this was booting off with the 'W' command. Or is that the issue? Correct, both 'W' and auto-boot are affected. It is the same bug. A CPU crash (watchdog event) occurs @ the 3rd stage of the boot loader. Unfortunately i cannot find the cause. Also, the third stage pulls tricks i can't fully grasp as a 6502 guy.  In short: the Z80 thinks it boots from floppy, when data is piped from hard disk sectors instead. The 808x does something, the WD1010 does something, and somehow too many IRQs fire...so the 808x finally stalls.The loader binary is hidden in one of the WUTIL.? files of the distribution archive - if someone wants to take a look.
Crazyc? WUTIL comes with an extended boot loader much more capable than DEC's. Unfortunately, even the latest version (i think it was 3.2) crashes in our emulation. Just like DEC's limited, old one The 3.0 or 3.1 archive came with Turbo Pascal source. I have it somewhere.
Last edited by Bavarese; 04/28/17 09:23 PM.
|
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
|
Senior Member
Joined: Apr 2012
Posts: 193 |
PREBOOT.ASM and SECBOOT.ASM contain commented assembler source. One oddity i remember is that at least 1 geometry value (heads) inherited a wrong value (zero) from one of the earlier boot stages... Source filesBinaries
Last edited by Bavarese; 04/29/17 01:51 AM.
|
|
|
|
|
Joined: Jan 2016
Posts: 76 Likes: 5
Member
|
|
Member
Joined: Jan 2016
Posts: 76 Likes: 5 |
Yea, I have that file. I'll have to take a closer look. Sadly, most zip files from that era give me errors like:
x $README.1ST: Unsupported ZIP compression method (imploded)
when I try to decompress them on modern hardware...
|
|
|
|
|
Joined: Jan 2016
Posts: 76 Likes: 5
Member
|
|
Member
Joined: Jan 2016
Posts: 76 Likes: 5 |
Looking at the source, it looks like it includes the Z80 boot code from the MS-DOS diskette (first two tracks). ZFLIP may well be in play, even though we don't need the floppy code to boot from the hard disk, the boot loader appears to put it in place and the rest of the OS depends on it... executing the wrong code during this because ZFLIP is wonky would definitely cause weird behavior, including stack overflow. 8088 processors really hate 8080/z80 code
|
|
|
|
|
Joined: Jan 2016
Posts: 76 Likes: 5
Member
|
|
Member
Joined: Jan 2016
Posts: 76 Likes: 5 |
In going through my floppy collection, I've found an alternate copy of Windows. The one that's normally available has issues, I'm told, with VAXmate files being mixed in and gumming up the works. These files are different, and on a set of disks that said "Windows 1.03" on them with a letter saying it is OK to upload them to BBSes dated in 1988. So I thought I'd pass them along to see if they are helpful fleshing out the graphics card at all. Since I think they are kosher to redistribute, I've put them up at github at https://github.com/bsdimp/rainbow100.git for all to enjoy. I have no clue how to install them or anything like that.
|
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
|
Senior Member
Joined: Apr 2012
Posts: 193 |
Thanks for taking a look. Just for the record, an emulation of the DEC mouse protocol will be needed before we can give Windows 1 a try. Back in 2012, i compiled some info here. I personally never got a graphics card, nor a DEC mouse - so i can't tell which of the serial ports was occupied. As these mice were usable together with other workstations, working on them might be of some interest to others.
Last edited by Bavarese; 05/01/17 11:41 PM.
|
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
|
Senior Member
Joined: Apr 2012
Posts: 193 |
Good news: i unblocked the 'auto boot' feature available within SET UP (see latest pull request). The bad thing: i discovered a weird one-off bug in WUTIL 3.2. It appears that the primary boot loader (located in PREBOOT.LDX) has an unexplained offset of 1 byte. This is either a bug in a 27+ year old, widely used hard disk tool nobody noticed - or an emulation bug. PREBOOT.ASM is assembled with a NOP - which is vital, but eaten away by the BIOS (explanation in part 2 below). And the FAR call afterwards does add another +1 offset (call 0000:1001 in disassembly, which results in a botched stack pointer save right after START):
mov [1170],sp 89 26 70 11
is executed instead of
mov CS:[1170],sp 2E 89 26 70 11
(= correct statement) It is unclear why real machines do not crash. Unfortunately i have no working machine left. When i add an extra $90 (NOP) byte at the start of PREBOOT.LDX it suddenly works. Hey, it even boots CP/M :-) So it would be very nice if someone (perhaps a 8086 expert) could give me a pointer in the right direction :-) Robert or Warner, can you please test my bug fixed / 1 byte longer PREBOOT (complete with Wutil 3.2) on a real machine? https://www.dropbox.com/s/s5eitbyy409yrzu/MODDED_WUTIL_V3.2.ZIP?dl=0From listing: https://www.dropbox.com/s/hjdslxjdv6726gt/PREBOOT.ASM?dl=0
SECBOOT SEGMENT AT SECSEG
ORG 0
ASSUME CS:SECBOOT
SBFRST DB ?
SBSTART PROC FAR
NOP
SBSTART ENDP
SECBOOT ENDS
CODE SEGMENT
ORG 1000H
ASSUME CS:CODE, DS:NOTHING, ES:NOTHING, SS:NOTHING
START: NOP ;This NOP must be here for ROM boot [ <--- EATEN AWAY BY BIOS, see code before / at F48C0 ]
MOV WORD PTR CS:SAVESP,SP ;Save SP contents at entry time
Full source for boot loaders: https://www.dropbox.com/s/mvdjtupnbfb2bsq/WUTIL_3.x_SRC.zip?dl=0----------------------------------------------------------------------------------------- From BIOS source: https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DISASSEMBLY_23-022e5-00Use 'bpset F48C0' to see the far call in action.
seg000:08A0 in al, 60h
seg000:08A2 cmp al, 90h ; 'É' ; First byte is $90 (NOP) ?
seg000:08A4 jnz short NON_SYSTEM__loc_8CD ;
seg000:08A4 ;
seg000:08A6 mov cx, 200h ; 512 bytes
seg000:08A9 mov di, 1000h
seg000:08AC
seg000:08AC GET_BYTES__loc_8AC: ; CODE XREF: sub_84+82Bj
seg000:08AC in al, 60h ; WD1010 input port (8 bit data)
seg000:08AE stosb
seg000:08AF loop GET_BYTES__loc_8AC ;
seg000:08AF ;
seg000:08B1 in al, 67h
seg000:08B3 mov ax, 0EE00h
seg000:08B6 mov ds, ax
seg000:08B8 assume ds:nothing
seg000:08B8 mov ax, sp
seg000:08BA sub ax, 4
seg000:08BD mov ds:1FF7h, ax
seg000:08C0 call far ptr loc_FFF+2 ; BOOT STRAP FROM HARD DISK [ translates to 9A 01 10 00 00 ]
Last edited by Bavarese; 07/07/17 07:51 PM.
|
|
|
|
|
Joined: Jan 2012
Posts: 891 Likes: 17
Senior Member
|
|
Senior Member
Joined: Jan 2012
Posts: 891 Likes: 17 |
I don't get the problem there. The BIOS disassembly shows a call to 0000:1001 and the source for the bootloader has "ORG 1000H" which means it should be loaded at 0000:1000. Since the first instruction of the bootloader is NOP then the CS: override should be at 0000:1001 which is correct. Your description suggests that it's loaded at 0xfff or the cpu is branching to 0x1002.
|
|
|
|
|
Joined: Apr 2012
Posts: 193
Senior Member
|
|
Senior Member
Joined: Apr 2012
Posts: 193 |
It turned out to be a bug in WUTIL 3.2. The boot loader is one byte too short. $90 NOP must be present twice. One byte is discarded by the BIOS, see :08a0. Now i have Windows 1.0.3 running, and i would like to use a microsoft serial mouse (which seems supported in 1.0.3). I added
MCFG_DEVICE_MODIFY("rs232_a")
MCFG_SLOT_DEFAULT_OPTION("null_modem")
MCFG_SLOT_OPTION_ADD("microsoft_mouse", MSFT_SERIAL_MOUSE)
MCFG_SLOT_OPTION_ADD("mousesys_mouse", MSYSTEM_SERIAL_MOUSE)
Do i have to add additional code? Guess i have to wire some signals. There aren't that many samples in our repository (the PC JR uses another UART)... (WineMine ported to Windows 1.x by Nathan Lineback) https://www.dropbox.com/s/0isjzpfwlbddpaj/MS_Windows_1.0X_1985_SCREENSHOT_WineMine.png?dl=0
Last edited by Bavarese; 07/13/17 05:41 PM.
|
|
|
|
2 members (Kale, 1 invisible),
233
guests, and
1
robot. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Forums9
Topics9,320
Posts121,923
Members5,074
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
