Uzenet

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Uzenet

Post by ry755 »

Wow! Now I really need to get an ESP-12f for my Uzebox :mrgreen:
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

uze6666 wrote: Sat Sep 08, 2018 7:08 am In no time I had a barebone telnet terminal. Was so easy and fun to code!
Now that is damn exciting, nice work :mrgreen: With that in place and a spare Linux box to telnet to, you more or less have a complete Linux shell on Uzebox. Lynx text based web browser comes to mind, and I had tested that it can actually(somewhat) work on these very forums!
User avatar
Jubatian
Posts: 1562
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzenet

Post by Jubatian »

uze6666 wrote: Sat Sep 08, 2018 7:08 am80 columns works ok on the Uzebox but even on my Commodore monitor, it get hard to read. I've looked at Jubatian mode 40 and its clearly the best thing for a Uzebox BBS/board/telnet site iHMO. So if you guys know of some active 40 columns telnet site for commodore machines or other ones, let me know. I'm totally working on a full Ansi color terminal for the uzebox.
Here's one I just found: CottonWood BBS, and here a list to try: Commodore BBS Outpost, seems like there are some places to try for that 40 columns!

If you aimed at Commodore 64 or Plus 4, I would suggest Mode 41 instead. The text mode of these machines have a fixed background color, only foreground attributes are available, so you can save 1K of RAM (the C64 / Plus4 text modes are 80x25, 1000 bytes).
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

I don't mind the extra ram since the telnet program won't need that much ram by itself. And I want foreground and background attributes.

Without looking at the code, the one thing I wonder is how hard it would be to add vertical scrolling (on a tile row basis). Scrolling the console windows is otherwise very expensive when you need to copy the whole vram to scroll by one row. I noticed I lost characters from the uart buffer when scrolling a whole page of text. I had to implement vertical scrolling in mode 9 to solve the issue.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

Been a while since I looked at the high-res modes. Been a while since I played with SPI vram for that matter, but it seems to me it would be possible to have SPI sourced vram with a code tiles approach to still hit 80 columns. Scrolling should be extremely fast if that is possible, but might be a different foreground/background approach needed there.
User avatar
Jubatian
Posts: 1562
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzenet

Post by Jubatian »

uze6666 wrote: Mon Sep 10, 2018 4:58 pmWithout looking at the code, the one thing I wonder is how hard it would be to add vertical scrolling (on a tile row basis). Scrolling the console windows is otherwise very expensive when you need to copy the whole vram to scroll by one row. I noticed I lost characters from the uart buffer when scrolling a whole page of text. I had to implement vertical scrolling in mode 9 to solve the issue.
I don't really understand this. For the UART to work at all, you need a buffer capable to hold characters incoming during at least about 200 scanlines (the video frame in which you can't process them anyhow). Scrolling 3K of data (text, foreground and background if you used Mode 40) takes some 15K cycles, maybe 20K if you didn't care a lot about optimizing, that, assuming the kernel with the inline mixer, would be some 15 scanlines at most. It really shouldn't tip over that type of code unless something somewhere was really off.

Considering 115200 baud, using the usual 1 start bit + 1 stop bit + no parity transmission, during one frame, you can get up to 192 characters. That demands a 256 byte receive buffer no matter how you approached it (assuming the code has to prepare to the usage of the full bandwidth), 128 bytes is just not enough (or would be only enough with well-crafted code if the screen was only about 175 lines tall), and it has to be a power of 2. Reading and processing the UART FIFO in every frame with a 256 byte buffer is necessarily enough even if the point of processing within the VBlank kept fluctuating between the beginning and the end of it.

Scrolling (a beginning line in VRAM / ARAM, however that would cut a noticable number of available HSync cycles) may be added to the Mode 40/41/42 group later, but it shouldn't really be crucial here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

Yes I have a 256 bytes uart buffer for all the reasons you mentioned. And no I did not do all those calculations, just noticed I was loosing characters when scrolling (moving 2K) on the stock mode 9 (80x28). I admit the scrolling routine was in C, so perhaps I would not have the problem if it was in assembler. Just seems more optimal to have scrolling instead of recopying the whole+attributes for mode 40. Specially when parsing those ansi escape codes for very colorful screens. I'll see if I get issues when moving to mode 40.
User avatar
Jubatian
Posts: 1562
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzenet

Post by Jubatian »

uze6666 wrote: Mon Sep 10, 2018 10:08 pm Yes I have a 256 bytes uart buffer for all the reasons you mentioned. And no I did not do all those calculations, just noticed I was loosing characters when scrolling (moving 2K) on the stock mode 9 (80x28). I admit the scrolling routine was in C, so perhaps I would not have the problem if it was in assembler. Just seems more optimal to have scrolling instead of recopying the whole+attributes for mode 40. Specially when parsing those ansi escape codes for very colorful screens. I'll see if I get issues when moving to mode 40.
You may look out for whether you are missing a complete frame occasionally, it could happen, and then you will definitely lose stuff. Also when doing the scrolling, use memcpy() or memmove(), which gives reasonably good code (likely not as good as an unrolled loop, but definitely the best otherwise), the point is you can really not fail too bad with these as the compiler can't mess up on them.

Also you may take a look at Mode 42: typically the 8 bit machines had 16 colors at most, and Mode 42 provides FG + BG attributes with 16 colors, so only one attribute byte used per character. Less memory used and of course faster to scroll as well.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzenet

Post by D3thAdd3r »

I experienced similar for the wifi setup. When requesting a list of access points(where I currently am, there are lots), I would sometimes lose data in a relatively tight loop writing strings to vram, calculating strength symbols, sorting, etc. 57600 was the easiest fix and not really a compromise on useability.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzenet

Post by uze6666 »

Ok, Thanks for the tips. I'll check memcpy and mode 42. I think 16 colors for BG and FG will be enough.

For the speed, I had issues too before and reverted back to 57600. But lately, besides that scrolling issue, I never lost a single char. I think all the kernel optimization by Jubatian probably helps. :P Btw, the latest AT firmware include a command so specify what attributes are returned when scanning networks. So much less data to parse.
Post Reply