Hi! So, tested your small script and it doesn't seem like there are any graphical chars but a lot of "blanks": [image: 223 to 255.jpg]
I have loaded the program to see that it "works" but I have not yet tested transferring data using TELCOM once it is loaded. I'll give that a shot tomorrow. I have not had much success going past 9600 BAUD's though for larger files (stuff gets dropped). But I'll test tomorrow with the Norwegian telecom enabled and let you know how it goes :) I would expect that the graphical chars between 223 and 255 are used in games from back then? If so, they will look a bit bad on this Norwegian variant ;) On Mon, Apr 6, 2026 at 7:27 PM B 9 <[email protected]> wrote: > Thanks, Rune. That keyboard helps a lot, particularly for attempting to > type in Virtual T with a US keyboard! > I had forgotten that Code+1 was â (“a circumflex”) because the pixels > looked like a ring to my tired eyes. > > Am I correct that the Norwegian M100 does not have the graphic characters > from 224 to 254? Please try: > > for t=223 to 255: ?chr$(t);: next > > On a typical TRS-80 Model 100, that will show some block graphics and line > drawing characters. > > Also, have you had a chance to try out the TELCOM program? At high speeds > does it ever reverse the characters it receives? I’m guessing it does not > as the handlers from INSTAL.BA disable interrupts first thing. (I think > John's hypothesis of interrupts getting interrupted seems like the only > explanation for the backwards writing I'm seeing in Virtual T.) > > —b9 > > On Mon, Apr 6, 2026 at 8:02 AM John R. Hogerhuis <[email protected]> wrote: > >> Ah I hadn't thought that it was the tx rx hooks. That's different you're >> right that would mean escaping or remapping characters for another system. >> >> And as to reversing characters in sure no one ever wanted that. An >> interesting bug to find. >> >> My first guess would be the hook is being re-entered. It doesn't do what >> it needs to do fast enough and the next character comes before finished >> processing the first one. So the callback gets entered again. I guess the >> code is re entrant enough that all the characters get processed but later >> characters pop out in the stream before earlier ones. >> >> The routine could be optimized to work faster and keep up and/ or >> interrupts could be masked so it doesn't get reentered. But if that is >> necessary it will not keep up, characters will get dropped if flow control >> doesn't slow things down. >> >> -- John. >> >> On Mon, Apr 6, 2026, 2:18 AM B 9 <[email protected]> wrote: >> >>> On Sun, Apr 5, 2026 at 8:43 PM John R. Hogerhuis <[email protected]> >>> wrote: >>> >>>> Apoligies if I misunderstand your question... in an interrupt handler >>>> you have to preserve any register you modify including flags... then not >>>> only must the stack be balanced to RET back to a interrupted routine, you >>>> also have to restore flags and registers before you return from interrupt. >>>> >>> >>> Thank you. I think I get it now. I had been wondering why the code was >>> pushing and popping PSW repeatedly inside a loop. Fundamentally, I hadn't >>> thought about the implications of every the Intel 8085 being so limited >>> that every comparison has to go through the A register. >>> >>> Now my biggest question has to do with the "Open handler". >>> >>> The handler implies that accented characters in file names are not >>>> allowed or need to be mapped? >>> >>> >>> That's what I was thinking, but I didn't see how it could possibly work. >>> I just tried using the Norwegian ROM in Virtual T and was quite surprised >>> to see that it translates characters bidirectionally. I get how the Rx >>> Handler works, but it seems what I was calling the "Open handler" is >>> actually a Tx handler as it is somehow translating text I type into TELCOM >>> before it gets sent over the serial port. I must have been mistaken >>> connecting the vector at FB0A to RST 7 + 18h (the Open statement). But I >>> don't don't see anything else in the ROM that jumps to the address at FB0A. >>> >>> I think my next step will be using Virtual T to investigate it, but I'm >>> running into something very peculiar. When I have the Norwegian RS232 hooks >>> installed, any text sent rapidly to the Virtual Modell 100's serial port is >>> getting reversed! >>> >>> [image: !sdrow sesrever reldnah 232SR naigewroN] >>> >>> I thought the problem might be that I was using a FIFO (mknod p) as the >>> "serial device", but it happens even when I use Virtual T's builtin >>> NADSbox. The problem only occurs when the Norwegian RS232 handler is >>> enabled. >>> >>> —b9 >>> >>> >>> >>> >>> -- mvh, Rune Devik
