z88dk forums

I can only say I have some control of the NMI interrupt when in slow or HRG mode, now.
Perhaps it could be overloaded with extra functionalities (with an hw detection at the beginning) or read some flag not to conflict with the IM2 code.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Forgot to point out one thing :   the intention of the IM2 handler is to handle periodic interrupts and to chain custom routines to the standard ones.. in the ZX81 case the best thing to do is to bind to NMI.

But the NMI calls the "user routine" (normally display) 50 or 60 times per second. That is not "real time" and too slow to catch characters coming from a serial port.
(BTW: Wilf Rigter did something similar in his NOVA program: a "user routine" can be called after each display generation 50 or 60 timer per second)

Is it right, that HRG does not need any INT? Then  during HRG mode the Z80 could be switched to IM2 to respond immediate to serial or network interrupts. Okay, that would disturb the HRG display, but in that case I would accept it.

Siggi



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Is it right, that HRG does not need any INT?

I think so

But could an enabled interrupt result in mayor problems during HRG?

If INT is used for a serial port, it needs always to be enabled. But normally the INT is disabled in the Zeddy. If is is enabled, the Z80 would not only be interrupted by the serial port, but also by bit 6 = 0 of the R-register (A6 is connected - maybe in future via a diode - to INT!).

Okay, the serial-interrupt routine could detect that unintended interrupt and set R to another value (e. g. FF) to avoid further non-serial interrupts. But could this confuse the HRG routine for a longer time?

But if the HRG itself needs R to generate the diplay, it will interrupt itself when bit 6 of R is set to 0
So maybe then additional hardware (a latch) to disable the "A6-interrupt" might be necessary

Siggi



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Last edited by siggi (2007-11-14 08:42:35)

Are we talking true hi-res here?  If so I understand that the connection between A6 and INT is cut so that interrupts caused by R do not occur.

No. My first idea was to have a wired OR for the internal A6-INT and an external INT (decouped via 2 GE-diodes). We need the A6-INT as default for standard display.

However in true hi-res, IR is used during the refresh cycle to fetch display bytes so any IM2 interrupt during this time will truly mess things up.  For one, the horizontal timing will be messed up by a detour to an IM2 routine while the display is drawn.

So we have to disable the internal A6-INT (2 diodes are not enough, we would need also a latch to "gate" the A6-INT). I would accept the external INT (from a SIO) there not to loose characters ..

Secondly the I register needs to point at bit patterns and not at an IM2 lookup table during this time.

So my first idea: saving I (used by IM2) by the display routine, setting it to new values (during display) and restoring at (for later IM2s) would not be sufficient: the IM2 must also be disabled during that phase :-(

But if you disable maskable interrupts while the actual display is drawn, maybe you can run an IM2 routine the rest of the time (vsync, top and bottom borders).  Your serial hardware will just have to hold its breath for that time (192*64us = 12.3ms).  How big is your serial hw buffer?

Currently the baudrate is 9600, so we receive a character per ms. The SIO can hold 4 characters, so that is too long. And if possible, I would like to uses higher baudrates ...

And what about flow control?

That would help to avoid buffer-overrun. But using XON/XOFF, whe may not loose those caracters (otherwise the communication would "hang"). So only hw-handshake may be used, but the SIO does that not automatically (need to be done by software). And that would cut down the effective speed (so forget 9600, when you have breaks for 12 ms = 12 characters).

I imagine that drawing the display, constant NMI ints every 64us when the display is not drawn, collecting chars from serial hw, etc doesn't leave a lot of time left to print stuff to the screen so there may be a practical limit as to how fast a zx81 in slow mode could receive data anyway?

Fred Nachbaur wrote a nice terminal program ZXTERM80 (using Wilf's HRG to offer up to 80 characters per line), which makes serial i/o and display simultanously. That was made for mailboxes using 300 or 600 baud .....

My thougts were to have a (small) display for debug and error messages, but the serial (or network) traffic should  have priority.
Meanwhile I thinks, that IM2 makes only sense during FAST mode. So the main application (web-server) could be interrupted to collect characters, so that the IP traffic is not dissturbed by too slow polling of the SIO. Or maybe a solution like Wilf's NOVA (a reduced screen with e. g. 3 lines would waste much less time for display) would help.

Siggi



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/