Re: [Ql-Users] SMSQ/E 3.39
Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be able to do more research... Please remind me prior to the QL meeting so I bring the equipment and FPGA data. I might be able to get a second hand FPGA programmer for cheap, I'll let you know when I get it. As I wrote at several occasions, it turned out to make a difference on which operating system I had synthesized FPGA version 1.05. If synthesized under Windows 10, there was a stability problem that Martyn could reproduce. If synthesized under Windows XP, everything should be allright. Unfortunately, I never suspected such a problem with the FPGA toolchain, and it is now not traceable. Very unlucky. I've discussed this with Mark, his Q68 was not affected by this. Dilwyn Jones via Ql-Users wrote: Mind you, my Q68 has never been able to run Jan's Minerva port either. If the latest Minerva and/or returning to FPGA version 1.02 does not help, I would suspect an actual hardware problem and your Q68 should be replaced. I'm not sure whether the latest Minerva port will solve all problems. Mark and I managed to pinpoint some issues but so far we haven't been able to solve it completely. One point of interest remains the interrupt register at $18021. I know about the frame and external interrupt bits (3 and 4, respectively) which are emulated from a BBQL. The other bits are irrelevant to Minerva (in fact only bit 3 is checked for a frame interrupt call, else it treats it as external interrupt since early Q68s don't set bit 4). But does writing to this register have any effect? The only purpose would be to clear the respective interrupt by setting bit 3 or 4 (which Minerva does). Bits 0-2 and 5-7 were used for gap, IPC, and transmit interrupts respectively, which are irrelevant to the Q68 and should really be ignored. Minerva doesn't set these bits except when initialising the hardware. -- ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Wolfgang Lenerz via Ql-Users wrote: > In other words: SMSQE checks the version of hardware you have. If it > doesn't allow higher speed, SMSQ/E doesn't even try to use that - even > if it is configured to do so. Maybe statements like that have been misread. The FPGA knows nothing about the SD card. SMSQ/E can just find out, if the FPGA has the capability to generate a higher clock. But not if higher clock is actually allowed. A cards capability for higher clock - if it exists at all - is not checked and initialized by SMSQ/E in a theoretically correct way. And Wolfgang is really not to blame for that, as we were not even able to obtain the necessary documentation. So the higher clock speed is always simply outside the SD specs! Maybe hardware-wise, maybe software-wise, maybe both. We just "tried and it worked for some cards". >> A save feature to use is 16 bit access to SD cards introduced in FPGA >> version 1.02 and higher. SMSQ/E automatically detects this. > > In about the same way as for the higher speed... But unlike the higher clock speed, this is a safe feature! Tt never uses the SD card outside the specs. By the way, I regret that I did not make it 32 bits wide. All the best Peter ___ QL-Users Mailing List
[Ql-Users] SMSQ/E 3.39
Hi, Please remind me prior to the QL meeting so I bring the equipment and FPGA data. I can bring this as well, if needed. In any case, the fast SD card speed option of SMSQ/E is not an officially permitted way to access the cards. It should never ever be SMSQ/E default! It is a purely experimental feature used at own risk. I have warned about it all along. As I said, I never had a problem with it. Also I'm not aware of an "auto-slow" feature. If SMSQ/E is configured to "fast", and for some reason there is a timing problem, card access will fail. I never said the contrary. At the risk of repeating myself: If you have a version of the Q68 "Rom" THAT DOESN'T IMPLEMENT THE HIGHER SPEED, SMSQ/E will not try to use the higher speed. In other words: SMSQE checks the version of hardware you have. If it doesn't allow higher speed, SMSQ/E doesn't even try to use that - even if it is configured to do so. A save feature to use is 16 bit access to SD cards introduced in FPGA version 1.02 and higher. SMSQ/E automatically detects this. In about the same way as for the higher speed... Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
Hi I programmed last batch of Q68 with the updated version of FPGA code, which was given the code reference v1.05r I have not supplied any of Q68 with the problematic v1.05. If anyone has any problems or thinks they need a change in FPGA code, please contact me at: de...@q40.de to arrange a free change in FGPA code. With regards to the Fast or 40Mhz SD Card access, the limiting factor maybe due the quality of SD Card. I will have do some more research on the SD Card speeds. I'm the main in my personal use and tests, reports from other users, the 20Mhz works with the majority of SD Cards and I configure SMSQ/E with the Fast SD Card access to NO. If the Q68 can not reach the 3 Windows command line, then I would use SMSQmulator to mount the SD Card and Q68_SMSQ.WIN to a EIN drive and then configure the Q68 SMSQ/E to suit. This saves defragmentation of the FAT32 partition on the SD Card. I will update my Minetva4Q68 setup and see what I can find. --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E 3.39
I will try the latest Minerva4Q68 as soon as I get time. Dilwyn On Tue, Feb 20, 2024, 07:44 Peter Graf via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Jan Bredenbeek via Ql-Users wrote: > > > Oh well, if Peter Graf can upgrade my Q68 to v1.05 in May I might be > > able to do more research... > > Please remind me prior to the QL meeting so I bring the equipment and > FPGA data. > > As I wrote at several occasions, it turned out to make a difference on > which operating system I had synthesized FPGA version 1.05. If > synthesized under Windows 10, there was a stability problem that Martyn > could reproduce. If synthesized under Windows XP, everything should be > allright. Unfortunately, I never suspected such a problem with the FPGA > toolchain, and it is now not traceable. Very unlucky. > > In any case, the fast SD card speed option of SMSQ/E is not an > officially permitted way to access the cards. It should never ever be > SMSQ/E default! It is a purely experimental feature used at own risk. I > have warned about it all along. > > Also I'm not aware of an "auto-slow" feature. If SMSQ/E is configured to > "fast", and for some reason there is a timing problem, card access will > fail. > > A save feature to use is 16 bit access to SD cards introduced in FPGA > version 1.02 and higher. SMSQ/E automatically detects this. > > Dilwyn Jones via Ql-Users wrote: > > > Mind you, my Q68 has never been able to run Jan's Minerva port either. > > If the latest Minerva and/or returning to FPGA version 1.02 does not > help, I would suspect an actual hardware problem and your Q68 should be > replaced. > > All the best > Peter > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
