Re: BASIC for the CBM-II/8088

From: Michał Pleban <lists_at_michau.name>
Date: Tue, 24 Jul 2018 01:06:12 +0200
Message-ID: <5B565F64.80406@michau.name>
Mia Magnusson wrote:

> My impression is that the DOS network software can do whatever API
> translations necessary and then redirect the actual call to the 6509
> Kernal. The main problem is probably the lack of seek() which must be
> emulated and will cause problems when writing. But just being able to
> read/write files sequentially might be a nice thing to have.

Yes, that'a generaaly how it works.

> I'm not sure but I think that this "redirector" thing needs different
> code for each DOS version though :(

Unfortunately, you are correct.

> Did you+Ruud order enough boards for you to have a board in your B and
> P at the same time?

I ordered three PCBs but soldered only one. It is already seriously
hacked with a SD card interface and a GAL injected in the middle of the
address bus to emulate the vide memory. This early in development it
doesn't make much sense to make lots of hardware.

We do have, however, three original 8088 boards between us.

> Oh, missed that. To be honest I'm not sure how refresh works when using
> a coprocessor. There are some synchronisation stuff that seems to be
> disabled by _BUSY2_...

The standard memory refresh is disabled by BUSY2 signal. The new refresh
mechmisn involves sending the P2REFREQ signal to the 8088 board, to
which it responds with P2REFGNT when it's ready to give up memory
control. Then the 8088 is halted, if  it tries ot access memory (but may
safely run the code in the ROM IIRC).

> But you could do the transfer and after the 6509 is finished check if
> the 8088 is in sync, if not redo the transfer. Or wait for the next
> refresh and start directly after that. A bit hard, probably not worth
> the effort, but still.

Looks definitely overly complicated to me...

> Yeah, it's always the best idea to start with the simpler but slower
> solution.

After some tests, I decide to disable screen refresh in the interrupt.
Main reason - the 50 Hz interrupt is too flaky. It must be disabled when
calling any IPC function, therefore, for example, when reading a floppy
disk sector there is no interrupt for a long time. Worse still, tight
loops calling IPC functions, will cause the interrupt to almost never
fire. A classic example - DOS prompt calling INT 16 repeatedly to see if
there is a character pressed.

So for now, I am calling screen refresh in these situations:

* Periodically in INT 16 functions 00 and 01, when the application os
polling for a keypress.

* Int INT 10 function 0E when a newline character is being printed.

These two conditions produce suprisingly swift and reliable screen
refresh in all situations that I encountered so far. Specifically, I
fired Turbo Pascal 3 and it works :-) Norton Commander, however, throws
strange and random errors which I am now trying to debug.

Regards,
Michau.
Received on 2018-07-24 02:00:04

Archive generated by hypermail 2.2.0.