exxos's Atari, Amiga & retro forum

PaulJ wrote: 11 Sep 2020 19:21 @rubber_jonnie , it canbe made to work with 2.06 but the app is pretty bad. Most of the time when I try and set the date it complains about the day being invalid for the month. This a totally a bs error possibly caused by what I suspect is patch on top of path in the app. I did look at the chip and what is required to program it. Its actually bit banged so you need to shift the bits into the chip and re-assemble them when read out. Guess I'll let it run and see if holds time and date reliably and if so it will fall to the bottom of the priority task list. Also a thought is to use exxos's clock and a gal to decode the clock address. I have a working setup program for that chip which has a much more advanced interface that doesn't require bit banging.

The issue between 2.06 and EmuTOS is somewhat strange... one reads the time from the chip and makes the call to set the machine time which I would guess is the same between 2.06 and EmuTOS.. maybe EmuTOS wants to correct the date? Don't know. I haven't tried EmuTOS 1.00 yet. Thirty years off doesn't make a lot of sense.

Going back to my installation notes herehttps://www.exxosforum.co.uk/atari/last/ ... lation.pdf, I wrote:

"If FMCII.PRG or FMCII_9F.PRG say the clock is not running, or that you have the incorrect
number of days for the month, it usually indicates the clock has never been set. This might
be after a battery change. Set the date to something like 1/1/99, and the time to anything
other than what is shown when the software boots. Hit the set button, and it should take
this. Hit reread, and you should see the seconds increment. You can now set to the correct
time."

In the same notes I also say the battery must be present and good, or clock setting won't work, and may drive you insane.

Question? Did you load the DALLRTC.PRG file at boot from the auto folder under TOS 2.06? If the clock is unset, or you wish to change it, you cannot set it if this PRG is loaded first, as per my instructions:

"When using TOS 2.06, I encountered some odd behaviour when setting the clock as above. I found
it was first necessary to boot without loading DALLRTC.PRG, so you may as well boot with an empty
AUTO folder.
It was then necessary to use FMCII.PRG to set to the correct time, but a date below Y2K, such as 99
(1999).
From there, it was possible to use FMCII_9F.PRG to set a date of 116 (2016) successfully.
After that you can happily boot with DALLRTC.PRG and AUTOFMC.PRG in your AUTO folder.
Don’t forget, the DS1315 is Y2K compliant, so setting it isn’t really the issue with the right
combination of software, but reading the clock and passing the data through to TOS is where the
Y2K fix is needed in order for everything to behave correctly."

First you clean boot, then use FGMCII.PRG to set the clock to 1999. Then use FGMCII_9F.PRG to set to a current year, 118=2018, 119=2019, 120=2020 etc. Once done you can set the time/day/month too.

Once the clock is set in that manner the date/time will hold just fine and you can boot with DALLRTC.PRG and AUTOFGMC.PRG in the Auto folder and all will be fine. I tested up to TOS 1.62 and this process was only necessary when it came to 2.06.

It is a reverse engineered circuit from a ForgetMeClock II, so unfortunately we are in the situation of having the ghastly mess that is the clock setting software for that, unless somebody is able to write something new. This is the same case if you were using one of exxos RTC clock cards, which are based on the same design, and was what was built into the H4.

The Mega clocks are way better, based on a Ricoh chip if memory serves, and can be easily set from the control panel. My Mega STE is a little different in that it gets the time set by my CosmosEx :) That way I can bin off the battery and not worry about battery goo all over my nice pristine mainboard!

If I recall, and I might recall wrong as my hard disk isn't what it once was, the trick to getting around Y2K is to set the date in the past and then the DALLRTC.PRG adds something like 20 or 30 years years on to kludge the year into being correct.

Try loading DALLRTC.PRG and AUTOFGMC.PRG under EmuTOS if you haven't already tried, see what it reads back.

@rubber_jonnie , as you said you need to set the clock to like 99 first and then move to a current year. And dalrtc cannot be executed on boot if your going to set the clock. Unfortunately even following these dead chicken in the bag processes it doesn't always work. Looks like if the chip gets locked up and the app always says bad day for month which is an idiotic error for this condition. It appears once set the clock will continue to work but is an extremely flawed app. Never the less with some tinkering and multiple tries it will work. I haven't tried to resolve the 30 year difference EmuTOS and 2.06 which is my preferred TOS. I'll dick with the 30 year issue when I have EmuTOS 1.0 available for boot permanently. Rj do you have your H4 reading a consistent time with different TOS's?

After winning the H4 build competition the prize was said to be a flashy clock. Well it appears that board has been pushed out so I was offered a Phoenix Shifter instead which I jumped on. Initial attempts to run the board on a stack of sockets so the the HDMI connector would sit above the case were unsuccessful but promising. So I unsoldered the video connector and the mono circuitry to install the board as it was meant to be installed. WOW.. can't even describe how good the display is. As Icky said pictures do not do the display justice. Colors are vivid and absolutely no artifacts or interference. I have attached a few display pictures but they do not do the actual display justice. @Smonson , @Icky , and @exxos did a great job on this board. Its rare when ones expectations are exceeded to level. Great job guys.

I understand there are issues especially with demo's but I'd be willing to purchase additional units for my other machines. Anyway great job!!

:goodpost: :coolpics:

I want at least one...maybe 2 or three (to include the H5 at some point)...

:bravo: Its mostly overscan screens which are troublesome as they just can't scale to a HDMI resolution. Currently its set to fullscreen for the ST video modes.. So overscan stuff is simply offscreen. We can pump a higher HDMI resolution, but then standard resolutions end up being tiny.. so we need to figure that out, oh and why colosure doesn't run :lol: :roll:

This board is really impressive, for what I do its great. I'd buy at least 3 more if they were in the store. I did have a little foo paw.. when I went to rearrange the boards the wire that I had tapped off the $E00000 decode landed in the power supply and BRITAIN got a little toasty. Luckily the 1508 was the only fatality.

Well I continued to get harassed by the netusbee. I now discovered that one supply that is running at 4.93 volts. The other supply I was using the in the H4 was at 5.09 volts and with this supply everything works except uiptool which will not initialize. Put the other supply in and uip works. Have to check the mega to see if it will run uip with a supply set to < 5.0 volts.

I have a sneaking suspicion that the NetUSBee needs a voltage higher than 5 volts.

On my STE with the original PSU it works but it doesn’t with the Exxos PSU which has a far more accurate +5V output. Similarly it doesn’t work on my TT and that also has an accurate +5V supply.

stephen_usher wrote: 17 Sep 2020 07:30 I have a sneaking suspicion that the NetUSBee needs a voltage higher than 5 volts.

Thats backwards from what I've seen. The netusbee ethernet doesn't work until the voltage gets down to approx. 4.9 volts. All the other function, storage, mouse etc don't care. I suspect this is why it doesn't work in the mega with Exxos's power supply since it is almost dead on 5.0v's. They mega used to be my working machine but now with Phoenix video card its hard to get away from the H4. Hope Phoenix become available in the store soon. Its a rare situation when something exceeds expectations as this board has. I'd be will to purchase it as is since I'm not a demo person. What do they say perfection is the enemy of good enough. Anyhow they did a great job on this board.

So to get back on subject I'll have to try a power supply in the mega that is set to 4.85 to 4.9 volts. Wonder if all his rtl8019's were fallouts from some other product some where. I have have a bare netusbee bare board so maybe I'll build with a rtl8019 from mouser or a repuable source if that's possible. I have a number of usb to ethernet adaptors and none exhibit this behavior and they all have the same 8019 chip.

PaulJ wrote: 15 Sep 2020 23:15 After winning the H4 build competition the prize was said to be a flashy clock. Well it appears that board has been pushed out so I was offered a Phoenix Shifter instead which I jumped on. IMG_2592.jpg

Initial attempts to run the board on a stack of sockets so the the HDMI connector would sit above the case were unsuccessful but promising. So I unsoldered the video connector and the mono circuitry to install the board as it was meant to be installed. WOW.. can't even describe how good the display is. As Icky said pictures do not do the display justice. Colors are vivid and absolutely no artifacts or interference. I have attached a few display pictures but they do not do the actual display justice. @Smonson , @Icky , and @exxos did a great job on this board. Its rare when ones expectations are exceeded to level. Great job guys.

I understand there are issues especially with demo's but I'd be willing to purchase additional units for my other machines. Anyway great job!!

Looks great in terms of both picture and installation! :goodpost: