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.