The Sinclair QL Forum

M68008 wrote: Wed Aug 13, 2025 11:39 pm

dilwyn wrote: Wed Aug 13, 2025 9:47 pm Do you also recognise HEX$(12648430,24) ?

No, had to try it
Reminds me of the 0xbaadf00d value sometimes used in old (32 bit!) projects for uninitialized pointers.

BAADF00D = cauliflower

dilwyn wrote: Thu Aug 14, 2025 7:55 am

M68008 wrote: Wed Aug 13, 2025 11:39 pm

dilwyn wrote: Wed Aug 13, 2025 9:47 pm Do you also recognise HEX$(12648430,24) ?

No, had to try it
Reminds me of the 0xbaadf00d value sometimes used in old (32 bit!) projects for uninitialized pointers.

BAADF00D = cauliflower

DEADBEEF <> BAADF00D !

M68008 wrote: Wed Aug 13, 2025 11:39 pm No, had to try it
Reminds me of the 0xbaadf00d value sometimes used in old (32 bit!) projects for uninitialized pointers.

I was trying to have Q-emuLator attach to my laptops COM port. I have a USB to serial device and have my Simulant WiFi modem hooked up to that (COM1 with 8N1 at 2400 baud). If I use a simple Windows terminal program, I can access my Simulant WiFi modem just fine. But with a terminal program within Q-emuLator, it seems to either give part garbage (i.e. it recognizes some letters but not others, so when I type AT it it echos back AD) or occasionally, if I hit enter a bunch of times I start seeing AT and OK and also the Simulant menu saying it connected to my local WiFi. So it seems to be out of sync (buffering?). Curious if there is some specific setting I need to configure the COM port to before attaching Q-emuLator to it.

bwinkel67 wrote: Thu Aug 14, 2025 1:17 pm I was trying to have Q-emuLator attach to my laptops COM port. I have a USB to serial device and have my Simulant WiFi modem hooked up to that (COM1 with 8N1 at 2400 baud). If I use a simple Windows terminal program, I can access my Simulant WiFi modem just fine. But with a terminal program within Q-emuLator, it seems to either give part garbage (i.e. it recognizes some letters but not others, so when I type AT it it echos back AD) or occasionally, if I hit enter a bunch of times I start seeing AT and OK and also the Simulant menu saying it connected to my local WiFi. So it seems to be out of sync (buffering?). Curious if there is some specific setting I need to configure the COM port to before attaching Q-emuLator to it.

What serial adapter do you have? From memory, there is no buffering in Q-emuLator serial driver, but it could be somewhere else (e.g. if you use INPUT instead of INKEY$(0), it will wait for the line feed character).
I wonder if the corruption is on transmission or reception.

I’m not doing it in BASIC. It’s a terminal program I wrote in early 90s that I’ve used recently with the Simulant modem on my actual QL with no issue. I can try qlterm but suspect the same behavior.

I’m using a brandless USB-to-serial converter I’ve had forever, but Windows has no trouble recognizing it, and it doesn’t need a driver. It works with a bunch of Windows terminal programs so I was hoping I could get it to work via a QL emulator and saw yours supported COM port mappings.

M68008 wrote: Thu Aug 14, 2025 7:55 pm What serial adapter do you have? From memory, there is no buffering in Q-emuLator serial driver, but it could be somewhere else (e.g. if you use INPUT instead of INKEY$(0), it will wait for the line feed character).
I wonder if the corruption is on transmission or reception.

So I got it to work, sort of. Basically, even with hardware flow control it loses characters. If you set it to 300 bauds it works pretty well. That should be fine for testing purposes.

Below are the settings of my generic USB-2-Serial converter. The key seems to be setting the buffer to 1 byte. If I have at at 2 or bigger, it starts substituting characters, i.e. at 1 byte if I type "a" and "t" it accepts it as "at", but at 2 bytes or higher if I type "a" and "t" it sees it as "ad" -- and many other characters are substituted as well, like for "ate1" it sees "adeA" so it gets some characters correct and some wrong.

bwinkel67 wrote: Fri Aug 15, 2025 9:50 am Below are the settings of my generic USB-2-Serial converter. The key seems to be setting the buffer to 1 byte. If I have at at 2 or bigger, it starts substituting characters, i.e. at 1 byte if I type "a" and "t" it accepts it as "at", but at 2 bytes or higher if I type "a" and "t" it sees it as "ad" -- and many other characters are substituted as well, like for "ate1" it sees "adeA" so it gets some characters correct and some wrong.

Does it have an option to use the software settings (through the standard COM calls) instead of overriding them?

EDIT: never mind, I found many drivers have similar UI. They should still respond to software changes (e.g. BAUD command on QL side), although I've seen some of them not liking those calls.

M68008 wrote: Fri Aug 15, 2025 6:12 pm Does it have an option to use the software settings (through the standard COM calls) instead of overriding them?

EDIT: never mind, I found many drivers have similar UI. They should still respond to software changes (e.g. BAUD command on QL side), although I've seen some of them not liking those calls.

Yup, it does change settings with software commands on the QL side. For instance, I can set the BAUD rate on both the modem (via atb300) and then the baud rate of the port via a software call to match up. The configuration on the COM port is only the initial setting.

[Edit: I think if you look at varies USB-2-Serial converters they would have the same UI because it comes from Windows and not the manufacturer (i.e. there was no software disk that came mine). One oddity, that might be tripping you up is that I'm doing this on my hobby laptop which I run Windows 7 on and not 10/11. Not sure if the UI has been updated on the latest version of Windows, but there is no reason to suspect the older Windows would be flawed since we are talking about old technology.]

Ok, a rudimentary terminal program has been added. You simple hit F3 (or Ctrl-M) and it gives you a brief menu explaining the commands you have and then takes you to the terminal program. I modeled it after ClearTerminal on Windows. You basically have an output window and an input line.

Again, Ctrl-M (or F3) to switch from browser to terminal program:

• Ctrl-X: this gets you into the command mode where, what you type in, is sent to the modem
• Ctrl-B: set baud rate by typing in a number (default is 2400)
• Ctrl-P: set port by typing in the string (default is ser1ir)
• Ctrl-S: since Ctrl-C is used in QDOS to switch running programs, I use Ctrl-S (for stop) to send the break key
• ESC: takes you back to browsing window (just the way you left it)

I need to test it out on a real QL. On QemuLator it struggles with the serial/modem connection. It won't let me set the baud rate to match the modem (is it the com port?). I can set it on the modem (via atb) and then locally, but once that's been done nothing works again. The way I got around this is that I used a Windows terminal program (CearTeriminal) and set the Simlant WiFi modem to 300 baud (i.e. atb300), then started QemuLator and Mimir and once I hit Ctrl-M to get into the modem, I then hit Ctrl-B and change the baud rate to 300 and it works.



[Edit: so now I need to automate the command on the telnet server to fetch me webpages. The automation will basically be Mimir constructing commands with lynx (i.e. lynx -dump bbc.com), sending it over the modem to the telnet server, and capturing its output locally (likely to a RAM disk) so I can then load it into the browser part of Mimir.]

Success! I was able to tie it all together and it was simpler than I thought. My page parsing function takes in a file pointer and assumes the file has been opened and then just parses what it finds. So, instead I just sent it a file pointer pointing to the serial port after executing a lynx -dump command of the URL and it also parses it.

The one issue is, no EOF, but I know when I'm done parsing as I've hit my last references, so I added that check. Since serial communication can be buggy, I also allow for escaping a page load via ESC, where it shows what it loaded.

I was able to load a page successfully via HTTP, though it still has the lunx -dump command appearing as the first line. I need to figure out a way to get rid of that. This was all done using QemuLator's interface with the serial port connected to my Simulant WiFi modem at 300 baud with no flow control. I'm hoping on actual hardware it will behave better with faster baud rate.

Still, it's a working prototype and kind of cool to be able to type a URL and get it to start loading. Very buggy if the modem connection is not robust, but still fun for where it is. I didn't think I'd get this far by the end of the summer. I guess I thought I had to create a system where I save a webpage to file on ram disk and then reload it, but this is quicker. The prototype has lots of limitations and can only read small webpages for now, but read them it can.

I'll create a video sometime next month to demo it working. For now, if you have a WiFi modem and access to a telent server you can give it a try. For telnet, I recommend sdf.org which gives you free access to your own UNIX account with different ways to access it. But this is how the SlipKnot browser worked back in 1995 on Windows 95, though it didn't parse dump files, instead using HTML.