No DLI possible at all during Disk i/o?

[Irgendwer]

I wonder however, why in all "faster" examples the "PHA" isn't replaced by "STA zp"

?

[Creature XL]

?

 

In some posts people wanted to save cycles in the DLI.

When you use "STA zp" and "LDA zp" you save one cycle.

And when you do not use the stack the routine isn't re-entrant and therefore you can as well save the A-register in the ZP as well.

Must say, we had a Christmas-party yesterday, so I am not at 100% of my thinking. that's why I added ":)"

[Bryan]

I posted this one-chip NMI fix a while back. Maybe I should make a board for it. Too bad NMI doesn't come out the PBI or it might have been possible to make this an external mod. If NMI is an OC pin, then the mod can modified to not require a pin to be lifted (that is, the input and output can be connect together). Who would be interested in a mod that connects with only 3 wires and fixes the NMI bug? It could be switchable for testing/compatibility purposes (although it should cause no compatibility problems).

 

http://atariage.com/forums/topic/148595-how-can-pokey-irq-timers-mess-up-nmi-timing/?p=1822388

[Rybags]

I remember all that...

Problem is, eliminating it on your own machine can mean you inadvertantly can create stuff that breaks on everyone elses.

Of course the switch off option would be most handy.

 

Personally, I think I'd just live with the bug - ensures that you put workarounds into the stuff you create.

[Bryan]

Yeah, but if you're writing games for 256K+ RAM and dual Pokeys, why not also throw in support for a mod a cheap and simple as this?

[bugbiter]

Hi Guys, it's working quite well,

 

I've got a headline with a permanent slow colour cycling effect. The colour is set during an immediate user VBI so that it should always run even when critic is on.

At the end of the line the black and white text colors are reset with a DLI.

 

For safety, the DLI is called in two seperate Antic lines.

 

It runs well during loading but I see occasional black flicker in the colour line, meaning the VBI is not executed once in a while during disk access. What can I do there?

 

Here some pics and part of the source:

 

 

; Display List 0 - Headline with text and progress bar

;

Dlist0

; Headline and dli call to restore black background

.byte 112,48,66+128

.word HeadlineDat

; 3 blank lines, second dli call for safety

.byte 48+128

; 24 lines Gr.0 (scr0)

.byte 66

lms0 .word 0

.byte 2,2,2,2,2,2,2,2,2,2,2

.byte 2,2,2,2,2,2,2,2,2,2,2,2

; 3 blank lines

.byte 48

; progress bar - 2 lines Gr.7

.byte 75

.word Pbline

.byte 75

.word pbline

; jump command

.byte 65

.word Dlist0

;

;---------------------------------------

; Display List Interrupt puts text and text background colour back to black

DLI0

PHA

lda #8

STA wsync

STA 53271

lda #0

sta 53272

pla

rti

;

;----------------------------------------

; User Immediate VBI sets text and

; text background color for headline

; (color cycling effect)

IVBI

LDA 20

lsr a

lsr a

lsr a

and #31

tax

;

lda col1,x

;

STA 709

STA 53271

;

lda col2,x

;

sta 710

STA 53272

;

JMP $e45F

[flashjazzcat]

Invoking the DLI twice is a pretty cool idea. Honestly, though, this issue (of keeping a colour change steady during serial IO) caused me so many headaches in one project that I abandoned the idea altogether and replaced the different coloured lines with something else which didn't require a colour change while IO was happening.

 

The trouble with "brute forcing" the NMI by implementing multiple interrupts is that you might end up upsetting the IO, which is rather undesirable. For instance, the IO progress bar which replaced the DLI coloured text was also NMI driven (VBL), and this causes serial transmission problems at higher baud rates (often, the transfer will just stall half way though, and need to be aborted with the Break key). And yet another problem is a DOS such as SDX which - at high baud rates - has an NMI threshold which means the DLI interrupt bit will be cleared during IO anyway, meaning your interrupt has no hope of running.

 

Unless an reliable workaround is found, I'd just turn the colour off during IO. I think there's a fair chance you'll get terrible flickering with certain DOSes, no matter what you do.

[Rybags]

Preventing NMIs being inhibited by SIO is even worse than for Timers since the timing can be indeterminate and the root source is external.

 

For the VBI, you could use similar method to the DLI up top, ie have a DLI down bottom that pre-empts the VBI.

 

Last possible scanline Antic displays on is the one immediately before the VBI occurs anyway so it won't upset timing.

 

The trick with both methods though is to inhibit the second source of the NMI within your DLI/VBI routine so that it doesn't occur.

In this case, easist method would be to modify the Display List entry to prevent second DLI.

For the VBI, simply disabling it in NMIEN for a short time would be sufficient.

 

Of course you then want everything back to double-trigger again. Easiest way would be to do that at the end of your Immediate VBlank. Sufficient time should elapse such that the VBI trigger point has passed - incrementing RTCLOK, putting the DLIs back to defaults and doing a few other instructions should see to that.

Edited December 22, 2013 by Rybags

[flashjazzcat]

It seemed to me that when DOS decided to inhibit DLIs during IO, it was doing do with good reason. For the sake of an entirely cosmetic colour change, it may be a case of diminishing returns.

[flashjazzcat]

Anyway, could you not just use five players spread across the top line to achieve the same effect without all this hassle? Given my time again, it's what I'd do. Even if the colour rotation skipped, you'd get solid colour.

Edited December 22, 2013 by flashjazzcat

[Rybags]

Problem with the PMG colour overlay is that there's that big memory cost unless you plug the graphics direct (which needs DLIs anyway and kinda defeating the purpose in this context).

 

If memory serves, it's the 400/800 OS only that disables DLIs in SIO - doesn't the XL OS leave them alone?

 

My view is that DLIs during SIO is fine so long as you provide some method to disable them.

There should be no problem if they're done right except with the very fast IO rates.

[flashjazzcat]

Memory cost and TD Line alignment were the two things which discouraged me from using PMGs as it happens. But I didn't imagine RAM would be at such a premium here (mine was a 32KB application already bursting RAM at the seams). I'd tend not to make any assumptions about whether NMIs will remain active when DOS is involved. SDX's SIO routine will disable NMIs at a certain threshold. If the objective is to make an application which is reasonably guaranteed to work at optimal IO speeds, the NMI is purely cosmetic, and there's a bit of spare RAM, I'd go for PMGs, or just do away with the eye candy during IO.

Edited December 22, 2013 by flashjazzcat

[pfeuh]

Hello,

 

As far as I remember, the SIO speed is 19200b/s, that means 1920 bytes per second (10 bits per byte, in fact 8 real bits, a start and a stop) let's say 1920 serial interrupts per second, less than an interrupt every 500µs... I think you can spend some time into DLI, it's not the critical point.

 

Regards,

 

Pfeuh

Edited January 20, 2014 by pfeuh

[flashjazzcat]

I thought the problem wasn't so much the total amount of time per second spent servicing the NMI, but the inability of the IRQ to be ready for the next incoming byte if the CPU's preoccupied with a long NMI. And the bytes don't hang around for long.

[Rybags]

From my own experience dealing with it (not exactly a lot) - it seems like the problem is likely way in excess of what I'd expected.

I've not closely looked at the code path in a while but maybe it's just longer than I think from when the SERIN IRQ triggers until the byte is actually read.

 

Also, the OS gets it's knickers in a knot easily when there's certain SIO error types - it's almost as if it starts doing the retries too soon and the drive just ignores them and you get stuck in a situation of waiting for timeouts to occur.

[flashjazzcat]

I'd be interested exploring the upper limits of what's possible in terms of concurrent NMIs and serial IO. Perhaps Hias might have some input? In any case, I will at some point require a complete high-speed SIO library for the GUI, and any help will be appreciated.

[Rybags]

Possibly the threshold is lower than we think, e.g. maybe overrun is possible once the 8th data bit commences rather than when the stop bit is received.

Controlled experimentation would be needed, ie some setup where we could launch a byte from an external source at a near cycle-exact time.

 

Or maybe Avery has already worked it all out for us and it's already documented (?)

[Creature XL]

Hello,

 

As far as I remember, the SIO speed is 19200b/s, that means 1920 bytes per second (10 bits per byte, in fact 8 real bits, a start and a stop) let's say 1920 serial interrupts per second, less than an interrupt every 500µs... I think you can spend some time into DLI, it's not the critical point.

 

Regards,

 

Pfeuh

 

The days of 19200b/s are long gone

My nice (animated) loading screen for "MJO" worked fantastic with normal speed. But everyone uses Ultra-Hi-Speed or PBI-devices and stuff like that.

So coding for 19200 will get you nowhere these days

Edited January 21, 2014 by Creature XL

[pfeuh]

 

But everyone uses Ultra-Hi-Speed or PBI-devices and stuff like that.

 

Except me... I use a real ATARI 800 XL and a pySIO of my own. 19200b/s, like the real one I used in the 80's.If somebody can provide me some specification, I would be very happy to boost it.

[Heaven/TQA]

well... coding demos I would like to have ever coded a so called trackmo which means custom SIO loader. Means I need to release a "HD ready" version (same happens to Atari ST demos which are able to be installed on hard disc).

[Rybags]

ST doesn't suffer the same fate though - even floppy I/O can be setup to be almost entirely run through the DMA controller, it's almost set and forget.

 

Another problem with high-speed SIO is that it was never intended at the start, so there is next to no support via the OS.

[pfeuh]

Another problem with high-speed SIO is that it was never intended at the start, so there is next to no support via the OS.

Do you mean that if you want to use high speed, you have to load first a piece of code at regular speed to change the baudrate and reinit the bootload process?

[Rybags]

You need custom SIO routines which have to occupy RAM (disregarding some OS variants or ROM-based Doses where Ram use can be minimal).

 

The boot process isn't really a big problem, typically you just have the first several sectors at normal which will typically contain some turbo SIO stuff.

 

You can't just set a bitrate that the OS will subsequently use - every time a SIO operation is initiated via the OS, the Pokey registers are setup to operate at 19.2k mode.

[HiassofT]

Possibly the threshold is lower than we think, e.g. maybe overrun is possible once the 8th data bit commences rather than when the stop bit is received.

IIRC overrun worked as expected (if you keep in mind that most docs have the SKSTAT definition wrong and swapped keyboard and serial overrun bits - siospecs.pdf has the correct definition). But there's another issue, due to the way you have to acknowledge a received byte you may miss a received byte:

 

To acknowledge a received byte you first have to disable the receive IRQ and then enable it again (via IRQEN). If a byte is received between disabling and re-enabling the receive IRQ, you miss it. You'd need an atomic acknowledge operation for this to work correctly (modern UARTs do this acknowledging automatically when you read the serial input register).

 

But, at the end of the day, it doesn't really matter if you detected an overrun or lost a byte - the SIO operation fails anyways.

 

As for timing requirements: they are very tight. Don't expect that there's time for any NMI or IRQ (they might have been disabled anyways) during SIO. Not only "real serial" SIO, but also when accessing PBI devices - the PBI handler might do anything if it needs to.

 

So you have to decide for yourself: do you want to have some pretty splash screen displayed while loading, or do you want that loading your game/application/whatever actually succeeds. I'd go for the latter

 

so long,

 

Hias