Yeah Isubclassing the handler to add hardware flow control would be useful.
I spent a little time on it but got distracted by some other shiny objects. -- John. On Tue, Jul 1, 2025, 6:13 PM Erik Keever <[email protected]> wrote: > Thanks for the replies guys! And, well, crap. I just reassembled it with > two inx sp's at the start and this time I didn't get a greyscale > kaleidoscope. Maybe there was some silent madness previously due to failed > builds quietly trashing memory? ¯\_(ツ)_/¯ I certainly can't say I'm > *angry* but... huh. > > Stephen - Yes, I have a full push/pop of state. I learned that ISRs have > to be side effect free the hard way. I thought of pop x, but then I can't > preserve state because pop has to overwrite something, no? > > John - Good to know if I were literally after count-the-cycles level > speed. Not quite that critical here luckily. > > Here's the ISR I wrote (my kingdom for even a few more characters for > labels!)... the mention of RTS probably gives away what I'm actually after > :P. In truth I could probably get everything I want by just using the F5FC > hook to monitor space remaining in the OS buffer but where's the fun in > that? > > rs_irqh: > ; prevent side effects! > inx sp > inx sp > push psw > push b > push d > push h > ; grab byte immediately > in C8h > call rsringw > ; get any errors > in D8h > ani 0Eh > sta rs_errs > ; set RTS to disable incoming if we are nearly full > lda ringhave > cpi rbufsiz-2 > jc rsihb > in BAh > ori 128 > out BAh > rsihb: > pop h > pop d > pop b > pop psw > ei ; done handling IRQ, and, > ret ; outey 5000! > > -- Erik > > On Tue, Jul 1, 2025 at 5:06 PM John R. Hogerhuis <[email protected]> wrote: > >> It's counterintuitive but if you want max serial port handling speed you >> should disable the interrupt and poll. >> >> -- John. >> >> >> On Tue, Jul 1, 2025, 3:37 PM Erik Keever <[email protected]> wrote: >> >>> Hi, >>> >>> I am working on an assembly program that involves the serial port hook >>> at F5FC. >>> >>> The current code I have works by setting a JMP there to my data-received >>> handler and then just returning. >>> >>> This is fine, but so far as I can tell from disassembling the ROM >>> handler at 6DAC, after I return, the whole rest of the ROM's handler >>> *also* runs. The program doesn't execute incorrectly since I've already >>> got the data but I'm not suffering through writing assembly because I enjoy >>> wasting lots of cycles. >>> >>> Now it seemed to me that since it gets to my code by >>> call 0034 due to IRQ >>> jmp 6DAC >>> call F5FC (immediately at 6DAC) >>> jmp $mycode, >>> I should be able to INX SP twice to "delete" the return-to-rom address >>> such that when I do RET it will return from the IRQ instead, thereby >>> sidelining the ROM code completely. >>> >>> Except if I do this I am pointedly reminded that the 8085 does not have >>> protected mode. And so my question: er... what exactly am I doing wrong >>> here? >>> >>> -- Erik >>> >>
