Does not boot on Pocket 8086

[rhaberkorn]

I was trying to install SvarDOS on my Pocket 8086 (NEC V30). Since it's notoriously hard to get it to boot from external media, I tried first to install in Virtual Box and then export the VDI image to a raw image and write that to the CF card. Unfortunately, the resulting image does not boot on a real machine.

I tried to reproduce the problem in 86Box, and although the setup is not 100% the same - it's obviously not the same BIOS - the boot hang can be reproduced:

I didn't yet manage to boot one of SvarDOS' floppies or CD-ROMs in 86Box.

Perhaps the SvarDOS installer detected a 386 system during installation and did something it wouldn't have done on a true 8086? It did format the drive as FAT32. But AFAIK it should still be supported even with an 8086?
Perhaps I will try to manually partition the drive.

[boeckmann]

@rhaberkorn thanks for reporting this issue! Can you please provide more detailed info about your 86box configuration (perferably screenshots), so I can try to reproduce the issue? I use 86box as my main testing environment, albeit with 486+ configurations (otherwise its too slow :) ). This usually works fine with the floppy images. So I think its a machine specific issue and not a general 86box issue.

At FreeDOS we previously had issues with transferring a QEMU image to the Pocket 386. If I remember correctly, this turned out to be an issue with the Pocket not supporting LBA, and the FAT32 volume boot code installed being LBA only. You may do a SYS C: /FORCE:CHS under QEMU (it installs the CHS volume boot code), and then try this image with the Pocket, or try if switching to FAT16 helps (FAT16 volume boot code supports both LBA and CHS). FAT16 is generally a good idea with the Pocket 8086. Should be faster...

[ecm-pushbx]

The FreeDOS FAT32 LBA code is 386+ code. So if it is chosen it won't boot on a NEC V30.

[rhaberkorn]

Yes, it was the FAT32 formatting. I manually formatted with FDISK and it runs fine now. It's quite nice to use. The documentation could need some help, though. I don't know whether you would like to keep this ticket open. Perhaps you shouldn't activate FAT32 support in FDISK if detecting an 8086.

Some misc. remarks, which don't belong here probably:

One thing I immediately noticed is that MEM is quite slow and doesn't show any of the config.sys drivers.

Also, I am still having trouble activating the UMBs. The device is supposed to have 128kb dedicated to UMBs available at D000-EFFF. In my previous tests I already determined that this memory is indeed readable and writeable. I was hoping that my problems miraculously go away when switching to DR-DOS. But turns out it behaves more or less like MS-DOS. With USE!UMBS, it lets me boot to the shell, but MEM shows no upper memory (in contrast to MS-DOS). Perhaps it's not expecting any upper memory without HIMEM/EMM386? Any 4DOS BEEP (or other use of the speaker) immediately hangs the machine. Other UMB providers like HIRAM or UMBDRVR load but the system will hang before even booting to the shell (be it 4DOS or the default one). I also tried setting HIDOS=ON as the equivalent of DOS=UMB. Any pointers on getting this to run would be very much appreciated.

PS: The USE!UMBS version in the repository is outdated. There is a v22 floating around which allows specifying memory regions on the command line.

[rhaberkorn]

but MEM shows no upper memory (in contrast to MS-DOS). Perhaps it's not expecting any upper memory without HIMEM/EMM386?

Okay, this sort of thing is supposed to be handled by DRHIMEM it seems. After using

DEVICE=C:\DRIVERS\DRHIMEM\HIMEM.SYS /CHIPSET=RAM /USE=D000-EFFF

MEM does show the correct amount of UMBs and I can load stuff into it. No HIDOS=ON required - I believe this would be for moving parts of the DR-DOS kernel into UMBs.
But the same phenomenon as on MS-DOS: Any beep and the system hangs (usually with the beep still playing).

[boeckmann]

Thanks for the informative comments.

Perhaps you shouldn't activate FAT32 support in FDISK if detecting an 8086.

I implemented in the installer a choice whether FAT32 should be used when creating the system partition, in case a user might want FAT16 for compatibility reasons or because its faster on slow machines. This might eventually make it into the binary.

One thing I immediately noticed is that MEM is quite slow and doesn't show any of the config.sys drivers.

Yes, under the EDR kernel its sadly slow. There is an issue for it in the kernel bug tracker. I did not find the exact reason yet and whether its also slow when running the FreeDOS kernel. It is the same MEM program used by FreeDOS. Do the drivers also not show when running MEM/D/P?

The USE!UMBS version in the repository is outdated. There is a v22 floating around which allows specifying memory regions on the command line.

Good to know, we will update that package!

No HIDOS=ON required - I believe this would be for moving parts of the DR-DOS kernel into UMBs.

Yes. And DOS=UMB inplicitly sets HIDOS=ON, like you wrote.

Any beep and the system hangs (usually with the beep still playing).

That's a rather interesting bug. Lets investigate that :)

[boeckmann]

That's a rather interesting bug. Lets investigate that :)

@rhaberkorn can you terminate the 4DOS BEEP command via CTRL+C?

And can you start the debugger DEBUG, and then do D 40:6C a few times to see if the 18Hz timer is working properly, means that the word at 40:6C increases by approx. 18 times a second?

This is the 4DOS 8 beep code. First guess is that the loop simply does not terminate. Then you should be able to terminate it via CTRL+C. If not, probably one of the interrupts involved does something strange ony the Book8086.

          entry     DosBeep,argframe,far

          argW      duration            ; length of time (in 1/18th increments)
          argW      freq                ; frequency (in Hz)

          push      bx
          sti
          xor       bx,bx		; clear result flag
          mov       ax, 040h		; point ES to ROM BIOS data area
          mov       es, ax
          mov       cx,freq
          cmp       cx,20		; anything less than 20 Hz creates
          jb        beep_get_time	;   a divide overflow

          mov       dx,012h
          mov       ax,034DCh
          div       cx
          push      ax
          mov       al, 10110110b	; select 8253
          out       43h, al
          jmp       $+2
          pop       ax
          out       42h, al		; low byte of divisor
          jmp       $+2
          xchg      ah, al
          out       42h, al		; high byte of divisor
          jmp       $+2

; Wait for desired duration by monitoring time-of-day 18 Hz clock
          in        al, 61h		; get current value of control bits
          jmp       $+2
          or        al, 3
          out       61h, al		; turn speaker on

beep_get_time:
          mov       dx, es:[06Ch]       ; save original tick count
beep_loop:
          sti		   	; because programs keep doing CLIs!!
          cmp       word ptr duration,1 ; if only waiting 1 tick, don't check
          je        no_char		;   for a key

          mov       ah,0Fh		; this silly kludge is to work around
          int       10h			;   a bug in the OS/2 2.0 DOS box

          mov       ah,01h		; check for ^C or ^BREAK
          int       16h
          jz        no_char
          or        ax,ax
          jz        beep_ctrlc		; ^BREAK waiting
          cmp       al,3		; ^C waiting?
          jne       no_char
beep_ctrlc:
          mov       bx,3
          jmp       short beep_off

no_char:
	xor	bx, bx		; force 0 return if we are done
          mov       ax, es:[06Ch]
          sub       ax, dx              ; get time elapsed
          cmp       ax,duration         ; now check duration
          jae       beep_off            ; loop if not there yet

          cmp       word ptr freq,20	; check if DELAY'ing
          jae       beep_loop
          mov       ax,1680h
          int       2Fh			; give up Win / OS/2 timeslice
          cmp       al,80h
          jne       beep_loop
          int       28h			; 2Fh 1680h not supported; call DOS idle
          jmp       short beep_loop

beep_off:
          cmp       cx,20
          jb        beep_bye

          in        al,61h
          jmp       $+2
          and       al,11111100b	; turn speaker off
          out       61h, al

beep_bye:
          mov       ax,bx
          pop       bx
          exit

[rhaberkorn]

Yes. And DOS=UMB inplicitly sets HIDOS=ON, like you wrote.

So does it make any sense to set DOS=UMB or is it just a synonym for HIDOS=ON?

That's a rather interesting bug. Lets investigate that :)

Great! I could use some help. My only hint is from the Pocket 8086 documentation which says

Upper Memory Blocks
Pocket8086 installs 128KB of memory in the D0000-EFFFF address segment and uses bit2 of IO port
060H as its switch flag. When it is written to 0, UMB is turned on (default). When it is written to 1, the
UMB is turned off.

That's rather suspicious. Port 60h should when written contain commands for the keyboard controller, isn't it? Why would you even want to disable the UMBs, what's the point in them not being there???
What if somebody sets port 60h as part of interacting with the speaker or keyboard? Although that should usually be port 61h AFAIK.

The keyboard controller is STC8G2K32S2-36I-LQFP48 which appears to lack an English datasheet. It's all Chinese. But looking at the schematics I also cannot see which line could possibly be responsible for disabling any external memory circuitry. I am not a microelectronics expert, though.

[rhaberkorn]

This is the 4DOS 8 beep code. First guess is that the loop simply does not terminate. Then you should be able to terminate it via CTRL+C. If not, probably one of the interrupts involved does something strange ony the Book8086.

No, you can't. And it's obviously something much simpler. I can provoke the hang just by writing into port 61h!

C:\>debug
-i 61
DD
-o 61 DF

Keeps beeping and hangs indefinitely!

This is compatible with the observation that literally any beep anywhere causes a hang - also the error beep or any game using the speaker.

[rhaberkorn]

And can you start the debugger DEBUG, and then do D 40:6C a few times to see if the 18Hz timer is working properly, means that the word at 40:6C increases by approx. 18 times a second?

Yes, it looks about right.

[boeckmann]

So does it make any sense to set DOS=UMB or is it just a synonym for HIDOS=ON?

Yes, as it does more than HIDOS alone. You also had to use HIBUFFERS, HIFILES, HISTACK etc. And interestingly none of these seem to link the upper memory chain via the initialize_dmd_upper call. Only DOS=UMB does that (or I am to stupid to see it). So I am wondering if these HI... calls even put anything into upper memory by themself (they should utilize the HMA though, if available). Will test this when time permits...

func_dos_umb:
;------------
; allocate Upper Memory Blocks and link them to the DMD chain
;
	mov	hidos,TRUE and 0FFh	; update hidos flag to be ON
	or	buffersIn,BUFFERS_IN_UMB; enable UMB usage for buffers
	or	filesIn,FILES_IN_UMB	; and files
	or	stacksIn,STACKS_IN_UMB	; and stacks
	or	lastdrvIn,LASTDRV_IN_UMB; and LDT
	call	initialise_dmd_upper	; build initial upper memory DMD
...

No, you can't. And it's obviously something much simpler. I can provoke the hang just by writing into port 61h!

Well that's bad. If it is a hardware thing this probably will be hard or impossible to mitigate by software without a means to intercept the port access. Does it hang on ANY value put into this port?

[rhaberkorn]

Does it hang on ANY value put into this port?

Interestingly it also hangs when I write 0xDD as well, so without the 2 LSBs being set.

[boeckmann]

Does it hang when you read the port value and write the same value back?

[rhaberkorn]

It is the same MEM program used by FreeDOS. Do the drivers also not show when running MEM/D/P?

Yes, I have for instance CH375286.SYS and NANSI.SYS loaded, which aren't showing up anywhere.

[rhaberkorn]

Does it hang when you read the port value and write the same value back?

Yes. Usually, I read 0xDD. I write back 0xDD and it hangs.

[boeckmann]

Pocket8086 installs 128KB of memory in the D0000-EFFFF address segment and uses bit2 of IO port
060H as its switch flag. When it is written to 0, UMB is turned on (default). When it is written to 1, the UMB is turned off.

This should be an error in the documenation.

This is a part from the CPLD logic, which controls the port access to 61h. Would be easier to decode if they had the code for it, so this could be simulated...

Its not that easy following and interpreting the traces in the .BMP, but PORTBW- and PORTBR- should be active when the port address is 000110xxx1. Have not followed yet where A1-A3 go. But in this part of the schematic they seem to be simply ignored. So this port would be mapped to 61,63..,6f.

PORTBW- and PORTBR- are made use in the following, and UMB_EN (bit 2) is NOT provided when the port is read. This should be really bad when performing a read-write cycle to this port.

Have not looked yet to EN_UMB in detail. You may try if writing D9 (clearing bit 2) also hangs the PC.