[sebhc] HDOS 2 boot problem identified.

[Dave Dunfield]

Hi Steven,

>Boy, you got a wierd one here!   It did exactly the same for me using the 
>2.0 distribution disk (maybe thats what you were using).
>
>This isn't sensing behavior - that occurs before the first console I/O.  The 
>sensing process is not only to detect baud rate (only on the 8250), but to 
>determine which port your console is connected to (it could be either on the 
>8251 at 370 or the 8250 at 350).   If an 8250 is present, it would display 
>SPACE on the led's and wait for you to hit spaces on your console.  I'm 
>guessing you don't currently emulate the 8250 so it went past that to the 
>"action?" prompt.
>
>I don't recall ever having any tech inquiries regarding this particular 
>hangup on real H8's.  But I do know that the console gets re-initialized at 
>that point, because on my real H8 I have to manually turn on RTS then for my 
>serial connection to continue talking to it (proper RTS management was 
>obviously overlooked in the driver).
>
>So, just a guess at this point .. but take a look at how your emulation 
>handles re-initialzation of the chip after it's been in use.  Particularly 
>in regard to interrupt handling.

I have identified the problem - the HDOS 2 driver in high memory uses a software
timeout based on the CPU speed while looking for sector holes - on a moderately
fast PC, this loop breaks, and times out before sector holes are found. If you
hit F9 while the boot is hung, you can step through the code and see where it
is using BC as a timer while looking for the hold detect bit.

Lots of console interrupts apparently slow it down enough that it sometimes
passes the test - I think when the buffer is full, they are sitting in a
polling loop while timing the beep - this takes a lot of time away from the
hole detect loop - and it becomes slow enough not to time out.

As a quick test, I implemented a manual setting for the CPU throttle, which
allows me to set the speed of the emulated CPU - with it slowed down, HDOS 2
boots just fine!

So - looks like I will have to implement the auto-calibration function to
set the CPU speed when the emulator starts.

Btw, my original implementation would not have broken in this case, since most of the
disk timing is based on instruction cycles - however I had to specifically slow down the
arrival of the next sector, because the H17 ROM "skip sector" function uses the PAM-8
500hz interrupt to time the holes - That one is basd on real-time in the emulator,
because otherwise all the PAM-8 function run way to fast!

Regards,
Dave-- 
dave04a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Vintage computing equipment collector.
                http://www.parse.com/~ddunfield/museum/index.html

--
Delivered by the SEBHC Mailing List