Jump to content
IGNORED

HSIO issue with Fujinet-PC on Raspberry Pi


apc

Recommended Posts

It looks like the 52400bps does not work on. Whenever the speed is set to 52400 (pokey divisor 10) there are only errors received on FN-PC end. The result is bouncing speed between 19200 and 52400 with lot of checksum errors.

@E474 is FN CONFIG loading fine with other pokey divisor values, e.g 8, 6, 0 ?

 

Link to comment
Share on other sites

Hi @apc

  

   I tried all the speeds from divisor 16 to 0, but only 16 booted the original (grey background) config program without errors. I've attached all the output files below. For each speed, I changed the HSIO divisor in the web page, reset the FujiNet-PC, quit FujiNet-PC, restarted FujiNet-PC, and then powered up the 800XL, logging the output using tee.

 

  As a side test, I switched the OS in my SysCheck 2 from Stock 800XL to Stock 800XL+Hias's HSIO patch, and tried booting a MyDos ATR with atariserver, and got it working at divisor 0. I was surprised this worked, as previously I hadn't been able to go so fast (IIRC), though I am now using the CTS line via the P5 header.  I don't know how sustained my divisor 0 I/O will be, as I thought it was necessary to remove a couple of capacitors (a quick Google gave this result: https://www.pcbway.com/project/shareproject/ATARI_XL_XE_SIO2SD_Interface_PCB_AVR_software_v_3_X.html), but I'm leaving them in for the moment.

 

   I then tried booting the config program using divisor 6 and divisor 8 with the Stock 800XL+Hias's HSIO patch in my SysCHeck 2, but this was just the same as with just the Stock 800XL OS (I didn't attach the logs for these two boots).

 

   Also Hias was helping me with something else a bit earlier, and he said you're welcome to look at his high speed (GPL 2 or higher) code:

 

Quote

the relevant serial interfacing code is in UserspaceSIOWrapper https://github.com/HiassofT/AtariSIO/blob/master/tools/UserspaceSIOWrapper.cpp

 

 

Please let me know if I can help with any more testing - I'm very pleased to be able to use the FujiNet software at divisor 16, if higher speed divisors can be supported that's even better!

 

 

boot_config_div_00.txt boot_config_div_01.txt boot_config_div_02.txt boot_config_div_03.txt boot_config_div_04.txt boot_config_div_05.txt boot_config_div_06.txt boot_config_div_07.txt boot_config_div_08.txt boot_config_div_09.txt boot_config_div_10.txt boot_config_div_16.txt

  • Thanks 1
Link to comment
Share on other sites

hmm, only the HSIO settings which worked on your RPi with FN-PC was "16: 38400 (x2)" which is "standard" UART speed...

I have no RPi. With FN-PC could you please try another standard UART speed "8: 57600 (x3)" (not custom "8: 58Kb")?

 

It looks the problem could be with some serial port device setting which is needed to make custom speeds working with RPI embeded UART.

I will check the code from Matthias if I can get the idea. @HiassofT do you remember was any specific setting needed for RPi UART?

 

Jan

 

  • Like 1
Link to comment
Share on other sites

Hi @apc,

 

   I didn't know the 3 SIO2PC settings were different to the Pokey divisor settings, so I tested all three of the SIO2PC settings (x2,x3,x6) - log files are attached below. To be honest I am still not clear on the difference between the "SIO2PC" settings and "POKEY Divisor" settings in the drop down list, which is why I originally just tested the "POKEY Divisor" settings.

 

   When I tested, both x2 and x3 booted OK, but x6 gave me 1 "Boot Error", then the grey loading screen and logo, the progress bar went to completion, but the config program didn't start up (grey screen stayed grey). I tried booting at x6 twice, but both times the config booted up with the same problems.

 

   The Raspberry Pi has 2 UARTS, I used /dev/ttyAMA0 - I had to change the #define for SIO_PROBE_DEV1 in fujinet-pc/lib/hardware/fnUART.cpp to use this one (it is the main onboard UART):

 

pi@retropiekodi2:~/fujinet-pc/lib/hardware $ grep tty *
fnUART.cpp://#define SIO_PROBE_DEV1  "/dev/ttyUSB0"
fnUART.cpp:#define SIO_PROBE_DEV1  "/dev/ttyAMA0"
fnUART.cpp:#define SIO_PROBE_DEV2  "/dev/ttyS0"

 

This was the only change I made to the sources, as the first time I started fujinet-pc it looped complaining about being unable to detect a UART, and I didn't know you could specify a UART device in the webpage. 

 

I guess if it is booting (at certain speeds), this must be the correct UART.

I set it up to use CTS on the P5 header by following https://github.com/HiassofT/AtariSIO/blob/master/README.RPi

This worked all the way down to divisor 0 when running atariserver, so I'm confident the hardware (Raspberry Pi Model 1 B, revision 2) is good.

 

It looks like I have a faster working speed now (x3), but unfortunately setting it to x3 wouldn't let me boot the alpha_load disk. Even so, x3 for general FujiNet IO is still faster than before!

 

Not sure if I can set up remote ssh access to the Raspberry Pi for you, I get broadband via mobile data, and the telco uses Carrier Grade NAT, but I might be able to sidestep that using port forwarding on one of my VPN provider's servers (though I haven't tried this with this telco/setup). I probably should test this out first.

 

Thanks again!

 

boot_config_x2.txt boot_config_x3.txt boot_config_x6.txt

  • Thanks 1
Link to comment
Share on other sites

@apc The RPi UART (/dev/ttyAMA0, the miniuart ttyS0 is better avoided) is pretty straight forward to use and works very well.

 

For non-standard speeds I use the termios2 ioctls - linux supports these for ages (but IIRC glibc still doesn't include the definitions so you have to provide them locally - see Termios2.h) and let the kernel drivers choose the right settings (possibly fractional divisors etc) to configure the desired baudrate.

 

The old, often used approach with TIOCSSERIAL / custom_divisor is better to be avoided, too.

 

so long,

 

Hias

  • Thanks 1
Link to comment
Share on other sites

@E474 thank you for testing x3 speed! This confirmed the issue is with setting custom UART speed - the code for standard and custom speed differs. Now I know where to look at.

 

The x6 speed never worked for me. I guess the reason is the difference between standard UART 115200 speed and the speed Atari expects at POKEY divisor 1 (111860) is too large to work. Custom UART speed is needed for divisor 1. I will remove 115200 from settings completely.

 

Link to comment
Share on other sites

Hi @apc,

 

   I forgot to mention the RPi is running quite an old version of Raspbian (it's based on Debian 9=Stretch), I can upgrade to BUSTER=10 or BULLSEYE=11), but would prefer to keep it "as is" if at all possible, as I have other bits of the system nicely set up.

 

  Also (my bad), I thought all divisor settings were equal, so didn't appreciate that, for example, pokey divisor 8 could mean two different speeds. 

 

   Glad to hear the bug has been narrowed down!

Link to comment
Share on other sites

1 hour ago, E474 said:

I thought all divisor settings were equal, so didn't appreciate that, for example, pokey divisor 8 could mean two different speeds.

Speed at Atari end is controlled by POKEY and used divisor - you are right, speed is fixed for given divisor (well, small diff PAL vs NTSC).

On PC end, serial port must be configured to the same or close to the same speed as Atari side. This can be done in two ways depending on serial port / UART capabilities.

 

Old UARTs in PCs allowed to switch only to some predefined "standard" speeds, like 9600, 19200, 38400, 57600, 115200. With newer hardware it is possible to control UART similar to Atari, base UART speed with custom divisor.

 

Thus to match e.g. Atari serial port setup with POKEY divisor 8, on PC end one can use (a) standard speed 57600 or (b) with newer UART to setup "custom" speed better matching speed at Atari side, around 59400 in this case. That explains two options for some POKEY divisor values.

 

With nowadays hardware it should not be problem to use (b) ... if properly programmed ;-) let me try to fix it

Link to comment
Share on other sites

correct, old rs232 etc and their uarts had predefined speed standards based on their clocks and their were some drivers/software to allow for higher speed choices added later reusing the lower speed selection choices in software to remap to higher speed in the selection table... some later serial ports were more define-able, USB ports are almost always more capable in that area, depending on drivers etc...

looking at whats available for the pc and RPi's there has got to be a method to drive the ports close enough to the correct speed to get the job done, just as it's done with other drivers and software... maybe it's possible to get the old Pi to use different firmware or driver/ or port configuration/ choice to get the job done....

 

if you can get the speeds on the Pi using other software, it's proving it's capable... maybe stripping the code from those other software/drivers and getting a look at it will allow rolling you own solution, or simple get yanked from the one and with some modification be added to the other...

 

If I've understood what as said, that is.

Edited by _The Doctor__
Link to comment
Share on other sites

OK, thanks for the explanations. I guess you can get different rates at the same divisor because the 8-bit can handle slightly faster or slower rates, but not substantially faster or slower rates. But the coding to get these slightly different rates on the non-8 bit side might be quite different due to using either standard or non-standard transfer rates.

 

Also, the Pokey divisor rates are actually (for the most part) non-standard rates, so using non-standard rates on the non-Atari side is required to match all the possible Pokey divisor rates.

 

I think I get it now.

Link to comment
Share on other sites

I pushed an updated code into github repo. Now the custom baud rate is setup via Linux IOCTL call (like in atariserver).

@E474 you can try a build:

# get the source code
git clone https://github.com/FujiNetWIFI/fujinet-pc.git
# switch branch
cd fujinet-pc
git checkout fix-custom-uart-speed
# enter build directory
cd build
# prepare build
cmake .. -DCMAKE_BUILD_TYPE:STRING=Debug
# run build
cmake --build .

 

 

  • Like 1
Link to comment
Share on other sites

Hi @apc,

 

   I think everything is working correctly, though I did find a few situations where there might still be some issues.  See all the attached txt files for details.

 

   I tested all the speeds using a Stock 800XL OS (on a SysCheck 2 card), and booted the config program fine, and then booted through to booting a MyDos ATR (holding OPTION in the config program). They all seemed to work correctly. Also, this is with the new config program (purple background). The 800XL still has the stock capacitors on the motherboard (AFAIK), though actually I haven't checked, come to think of it.

 

   I then tested all the speeds on a Stock 800XL that had been patched with Hias's high speed code (on a SysCheck 2 card), and had some problems at divisors 6 and 5. I booted several times at these speeds, and got inconsistent behaviors. Generally the first boot might stutter, then get to the MyDos menu, but if I tried to boot again at the same speed, it would dump me in the OS Self Test after "Setting up RAMDISK". If I set the FujiNet divisor back to 16, or disabled, it would boot fine at this (lower) speed, and then fine at 06 or 05. Not sure what is going on here.

 

   Also, I noticed that if I booted all the way to MyDos, then powered off, sometimes the FujiNet-PC wouldn't display:

> Timeout waiting for data after CMD pin asserted

at higher speeds (for example, in  hias_patched_xl_boot_mydos_hsio_04.txt, right at the end of the file). After booting to MyDos, I always powered down the 8-bit, at most speeds I would get the Timeout message, but not at all of the higher speeds.

 

Also, I realized at the end of all the testing, that I hadn't actually tested writing to an ATR, so I tested copying D1:DOS.SYS,D1:DOS.BK2 using an 800XL patched OS running at divisor 0, and it worked fine (this is the 00_rw.txt file). I'm guessing this is the toughest test, though I will try and test at the other speeds, and with the Stock OS, just to be certain.  However, I don't know if there is any high speed SIO writes to the FujiNet-PC itself, so maybe writing via high speed SIO has already happened?

 

Also, I had to change the cmake_minimum_required version to 3.7.2 in CMakeLists.txt:

 

pi@retropiekodi2:~/fujinet-pc $ more CMakeLists.txt 
# fujinet-platfromio
# cmake_minimum_required(VERSION 3.16.0)
# include($ENV{IDF_PATH}/tools/cmake/project.cmake)
# project(FujiNet_idf)


# fujinet-pc
cmake_minimum_required(VERSION 3.7.2)
project(fujinet-pc VERSION 0.1.0)

as I am still on a Debian 9 based Raspbian:

pi@retropiekodi2:~/fujinet-pc $ more /etc/debian_version 
9.13

 

Another, completely unrelated, thing I noticed was that I would get prompted for connecting to a WiFi network every single time, even though I was already online via an ethernet cable, and my RPi 1 doesn't have a USB WiFi adapter plugged in. Maybe this can be changed to a general check to see if an IP address has been assigned to the FujiNet, and if so, the prompt for a WiFi network to connect to can be skipped (paging @tschak909 )?

 

Also, when I first booted up the FujiNet-PC, I tried to set slot 1 to an SD card, but typed in "sd" (in lower case), then when I tried to change it to upper case, I had error messages saying it couldn't mount the slot (or similar type message). I just set slot 2 to SD, and carried on without problems by using this slot for the MyDos ATR, but didn't pursue this any further as it looked like a rabbit hole with regard to testing HSIO booting.

 

I also noticed that booting MyDos via FujiNet-PC and atariserver did sound a little different (in terms of the pitch of the I/O beeps at the same divisor), but I'm not entirely sure of this, so will also try testing this a bit more extensively (hopefully tonight).

 

This definitely looks like a fixed bug, though I'm not sure what the problems at divisor 6 and 5 mean. Also, turning off the I/O sound during config loading does make it harder to pick up on loading problems, would it be possible to have the regular I/O sounds if -DCMAKE_BUILD_TYPE:STRING=Debug is defined?

 

Many thanks for getting the code up and running, and tagging @HiassofT in case Hias has any insights on the test results!

 

hias_patched_xl_boot_mydos_hsio_00.txt hias_patched_xl_boot_mydos_hsio_00_2.txt hias_patched_xl_boot_mydos_hsio_00_rw.txt hias_patched_xl_boot_mydos_hsio_01.txt hias_patched_xl_boot_mydos_hsio_02.txt hias_patched_xl_boot_mydos_hsio_03.txt hias_patched_xl_boot_mydos_hsio_04.txt hias_patched_xl_boot_mydos_hsio_05.txt hias_patched_xl_boot_mydos_hsio_05_02.txt hias_patched_xl_boot_mydos_hsio_05_03.txt hias_patched_xl_boot_mydos_hsio_06.txt hias_patched_xl_boot_mydos_hsio_06_02.txt hias_patched_xl_boot_mydos_hsio_06_03.txt hias_patched_xl_boot_mydos_hsio_07.txt hias_patched_xl_boot_mydos_hsio_08.txt hias_patched_xl_boot_mydos_hsio_09.txt hias_patched_xl_boot_mydos_hsio_10.txt hias_patched_xl_boot_mydos_hsio_16.txt hias_patched_xl_boot_mydos_hsio_disabled.txt stock_xl_boot_mydos_hsio_00.txt stock_xl_boot_mydos_hsio_01.txt stock_xl_boot_mydos_hsio_02.txt stock_xl_boot_mydos_hsio_03.txt stock_xl_boot_mydos_hsio_04.txt stock_xl_boot_mydos_hsio_05.txt stock_xl_boot_mydos_hsio_06.txt stock_xl_boot_mydos_hsio_07.txt stock_xl_boot_mydos_hsio_08.txt stock_xl_boot_mydos_hsio_09.txt stock_xl_boot_mydos_hsio_10.txt stock_xl_boot_mydos_hsio_16.txt stock_xl_boot_mydos_hsio_disabled.txt

Link to comment
Share on other sites

Thanks for extensive testing and great feedback ? (just, how can I download all the log files in one shot?)

I'm glad the issue was addressed. Thank you @HiassofT for help!

 

1 hour ago, E474 said:

Also, I had to change the cmake_minimum_required version to 3.7.2 in CMakeLists.txt

I changed this already in fujinet-pc branch, this will appear with next push on github, but there will be more changes. That's the reason you had to change cmake in this fix branch. So next time it will be there ;-)

 

1 hour ago, E474 said:

Another, completely unrelated, thing I noticed was that I would get prompted for connecting to a WiFi network every single time, even though I was already online via an ethernet cable

That's weird. Hardware FujiNet is expecting to find a WiFi. On FujiNet-PC "fake" WiFi is presented. Just select it and enter any password (empty is ok). Once selected this is saved in fnconfig.ini and you shouldn't be asked to select/connect anymore. Could you please check fnconfig.ini file? There should be section like this:

[WiFi]
SSID=Dummy Cafe
passphrase=

another wip small change is to ship FN-PC with pre-populated fnconfig.ini, with wifi and some host slots already filled in. This should make first steps less confusing. (I will miss "Welcome to #FujiNet!" first time screen ;-) )

 

2 hours ago, E474 said:

Also, turning off the I/O sound during config loading does make it harder to pick up on loading problems, would it be possible to have the regular I/O sounds if -DCMAKE_BUILD_TYPE:STRING=Debug is defined?

not by this, this is used to build fujinet-pc, I/O sound is turned off by CONFIG loader: https://github.com/a8jan/fujinet-config-loader

I think I can add something like pressing Shift key at start of boot would keep SIO sound enabled, for troubleshooting and be-be-beep fans

 

-Jan

  • Like 3
Link to comment
Share on other sites

Hi @apc,

 

   Please find attached a zip file of all the logs.

 

   I never set the WiFi password/SSID when I was testing earlier today, I'll try setting up a "fake" password for the "Dummy Cafe" and see how that goes (I'm assuming it should work as advertised though).

 

   Pre-populating the host list sounds like a good idea, I was going to suggest this too, but I see it's already heading into the build.

 

   One thing I was wondering about was displaying the date/time in the config program (I already got the ApeTime protocol to work via SIO on FujiNet-PC), and it's a simple way to show the FujiNet-PC is  online/has an IP address assigned.

 

   I will do some more testing once I do the SIO capacitor mod, just to see if that makes any difference.

 

   Thanks again!

boot_logs.zip

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...