[sebhc] Emulator fix

[Mark Garlanger]

Latest update:

  I've tried several things:
1) defining a new UART. Duplicated almost all the code/places that
the existing ' m_ConsoleUART' class has.
Result -> I get output that has dropped many characters. I can still
somewhat make out the words, but it appears the computer is writing
the next charater before the UART sends out the first one.  It doesn't
seem to accept any characters.


2) Using the existing UART. I.e. mapping the addresses 372 ->350
and 373 -> 351.
Result: First attempt didn't have the dropped characters on the output,
but now is showing dropped characters like above. Not sure if it's
a code change I made (I tried to get back to the original, but it's still
dropping the characters).  On pressing a key, the emulator makes
a continuous repeating beep. Doesn't respond to the reset button or
even the 'X' Windows close button. I have to get Windows task
manager up and kill the task (and get the 'Application not responding'
error dialog). This seems to be directly related to the
Bus::SetInterruptRequests
method. If the original ConsoleUART or my new 'CassConsoleUART' is
initialized for a interrupt:
m_bINT30 = m_ConsoleUART.InterruptSignal();

They both will cause the emulator to just beep and not respond to any
other inputs.  (Some text did continue to be displayed to the H19 but
I couldn't decipher what it was writing.)  And if I comment out that line
using the original ConsoleUART all input appears to be ignored ( just
like it behaved with using a new UART).

I'll try some other combinations and see if I can get any more hints by
using the Logic Analyzer.

            Mark

----- Original Message ----- 
From: "Mark Garlanger" <garlangr at verizon.net>
To: <sebhc at sebhc.org>
Sent: Sunday, May 02, 2004 1:06 PM
Subject: Re: [sebhc] Emulator fix


>
> Steven writes:
>
>
> > Mark says:
> > >The emulator was first complaining about write attempts to that
address.
> >
> > It was probably setting up the word size, parity, etc. on the status
port.
> >
> > >In the read code...both addresses would just return 0.
> >
> > The status port should probably always return TxRDY to prevent hanging
in
> an
> > output routine.  My mod returns that and TxE together to simulate an
empty
> > buffer.
> >
> > >it didn't halt it but it didn't seem to do anything after that.
> >
> > I'm guessing this tape software does not support the 4-port serial card
> > (with the 8250's), which is apparently how the emulator handles the H19
> > connection.  That's what I meant by adding code to support simulation of
> the
> > terminal connected on the H8-5 serial port as well.  This particular
tape
> > software probably won't do anything interesting until that is set up.
> >
>
> Any chance the 8250 is a superset of the 8251 or close enough to
> pretend to be a 8250?
> It appears the current 8250, for the console, has 8 port (350-357),
> since the 8251 only has two address, 372 & 373. Can I create a second
> UART object and map the first port to 372 and the second port to 373?
> If I remember correctly the first port on the 8250 is the data port and
the
> second is the status, and that appears to be what 372 and 373 is looking
> for.
>
>
> > >Making the changes you proposed
> > >below to the port read code didn't seem to change the end result
> >
> > It was only intended to keep the CPU from halting on input attempts from
> > other unsimulated ports.
> >
> > >I would really like to get the H17 supported, so I can try with disk
> images
> > >instead of tapes.
> >
> > That would be really cool.  I might also consider working on that too,
> once
> > I can do a build.  Looks like Dave Wallace was intending to add that -
has
> > anyone been in touch with him recently?  He hasn't answered email I sent
> him
> > weeks ago.
> >
>
> I just sent him email on Friday, and haven't heard anything yet.
>
> --
> Delivered by the SEBHC Mailing List

--
Delivered by the SEBHC Mailing List