exxos's Atari, Amiga & retro forum

Well I've decided to put the H4's into a useable configuration and put the lid on at least one. The issue was the 27c400 adaptor was extremely high causing it not to play nice with the other adaptors. So I put together another of @cmorley 's adaptor using low profile pins. It now fits underneath the IDE board instead of towering over it.

Been working on the second H4, the one where netusbee didn't work. So I moved the clock chip to this board from H4 #1 and the netusbee still didn't work. I did expect this result so I went to remove the clock chip and put it back in H4 #1. A interesting thing happened when I removed the chip... the socket came out with the chip..!! guess it would have helped if I soldered it in. Anyway after a little solder the netusbee now works in both H4's. So the only machine the bee doesn't work in is the mega4. Need to take a look at that machine.

Also I made an adaptor for the H4 to mount the gotek low over the video chip elimating the cable totally. Since I never put the lid on the H4 I wanted the gotek mounted firmly over the h4 following Exxos's city planner planner rules that state a mb requires plenty of high rise daughter cards.
Even though it positioned the gotek exactly where I wanted it there was a very good side effect. When I made the board I made all ground pins into a ground plain so I didn't need to route those pins. In normal operation the H4 had some noticeable vertical bars that were noticable. When I used the adaptor with the ground plain it elimated 70% - %80% of the video interference so now its almost a perfect display. So were getting close to wrapping the H4's up.

I've been forced to re-evaluate the bee. Its working great on all machines except the mega so I'm going to take a look there. The latest uiptool for the bee supports ftp so that's a good, the wireless mouse works great and the usb storage works with the usb sticks generated on the lightning cards. So now my money is on an issue with the mega4 instead of the bee.
Still using jumpers for the DMA fix on H4 #2, when I build the adapter for H4 #1 I lost the little inverter chips so I had to order more.

Those little inverter chips are stupidly small, just hope I can find mine as I need to build up my proper adapter boards rather than the Frankensteined proto board one I have now.

rubber_jonnie wrote: ↑Sat Sep 05, 2020 5:02 pm Those little inverter chips are stupidly small, just hope I can find mine as I need to build up my proper adapter boards rather than the Frankensteined proto board one I have now.

Well mine arrived today while I was playing with the clock on my 2'nd H4. You appear to have spent a lot of time with this chip and software so I thought I'd ask you a few questions concerning the device. Why does it take to programs to set the system clock? In addition while using TOS 2.06 it works as expected. However when using EmuTOS the date changes to 1990. Do you have an idea what's up with that. Also when using the FMCII_9C app to set the clock it gives me a lot "Day not Valid for Month". Its my guess the clock chip is locked up and that's the softwares response to that condition. @rubber_jonnie if you have any insights to these software anomalies please advise.

I'll get back to you on that when I'm not on my mobile.

Still on mobile @PaulJ, have a look at my docs here: https://www.exxosforum.co.uk/atari/last/RTC/index.htm

There are some funnies when setting and its in the docs.

As for Emutos, it was never tested so I can't say how it would behave.

@PaulJ Also you need the fgmc_9F software as on the attached image, just remove txt from the end.

rubber_jonnie wrote: ↑Thu Sep 10, 2020 9:42 pm @PaulJ Also you need the fgmc_9F software as on the attached image, just remove txt from the end.

Thats what I was using and can get it set correctly but I wouldn't call the software polished. I really don't need a clock but I was getting sick of directories with unusable dates without the clock getting set to something reasonable. Its odd that a good date with 2.06 is 1990 on EmuTOS.

PaulJ wrote: ↑Fri Sep 11, 2020 12:43 am

rubber_jonnie wrote: ↑Thu Sep 10, 2020 9:42 pm @PaulJ Also you need the fgmc_9F software as on the attached image, just remove txt from the end.

Thats what I was using and can get it set correctly but I wouldn't call the software polished. I really don't need a clock but I was getting sick of directories with unusable dates without the clock getting set to something reasonable. Its odd that a good date with 2.06 is 1990 on EmuTOS.

If I get a chance I will have a play with EmuTOS, I just don't have an STFM/H4 with it on ROM right now, only a Mega. I need to make a new image of TOS 2.06/EmuTOS 1.00 so I can have a look.

I suspect that because in order to get past the year 2000 in TOS there is a degree of kludgery going on, that may have been fixed in EmuTOS and it's getting confused. In EmuTOS, have you tried with and without the various components in the Auto folder?

@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.