Ultimate 1MB, Incognito, 1088XEL/XLD and SIDE/SIDE2 Firmware Version 3 Released

[flashjazzcat]

4 hours ago, Kyle22 said:

What if the Vogons want to build a Hyper Space Bypass?

Is your code safe?

If that happens, it hardly matters, and hosting source on GitHub will hardly help.

 

Labouring the point will not make any difference, regardless of whether you're happy with my backup strategy or not.

[ivop]

Backup strategy seems fine as fine as I can tell by your statements. Ofcourse I'd rather see your stance reversed on Open Source software, but so be it. It's your choice. But I'm glad I finally asked, so everybody knows your position.

 

[ivop]

Hmm, wanted to edit a typo and it suddenly became a new post?

Discard this post....

Edited January 14, 2020 by ivop

[+mytek]

It's different when you start with the notion that something is to be Open Source, but as FJC stated his BIOS never has been, so its not like he reversed his stance. On the other hand pretty much everything I do in the Atari world is Open Source, but even I've been known to reverse this decision in a rare instance (i.e., 1088XLD gerbers). Although even with that project, I did do a public release of the schematics and the firmware for the PIC chips it requires. So in a sense I guess that would be the guts of the project, and with that information one could go off and recreate the PCB easy enough.

 

The fact that FJC doesn't charge the individual for his hard work on the BIOS, and simply requests a donation, is quite a gift in my book. Does he maintain control of the BIOS? Yes, and who better then him I say. In my personal opinion, I sincerely doubt that going Open Source would have made any really change for the better, and might have even crippled it. As for back-up, each and everyone of us that downloads the BIOS at least serves as a back-up for the end product. And who needs source when that product is so close to perfection .

 

[ivop]

I know it wasn't open in the first place, and I don't want to turn this into a debate, or worse. I just wanted to know what FJC's stance was on perhaps opening up his project(s). Thinking about people like @dmsc, @phaeron, @ilmenit, @JAC! et cetera, that could surely contribute to a project like this and improve performance. But not without source code.

 

@mytek I am 100% with you about open source. I understand you make (or try to make back ) some money with the 1088XLD boards (and hence not shared the gerbers). But everything else is out in the open, and I really appreciate that!

 

[flashjazzcat]

21 minutes ago, ivop said:

that could surely contribute to a project like this and improve performance

Ah... so there is an ulterior motive.  Having spent four years improving performance, I have to ask where do you feel it might be lacking? I'm sure if any of the listed personalities felt like writing something which performed better, they'd be better off starting from scratch... which is precisely what I did.

Edited January 14, 2020 by flashjazzcat
typo

[+mytek]

14 minutes ago, ivop said:

@mytek I am 100% with you about open source. I understand you make (or try to make back ) some money with the 1088XLD boards (and hence not shared the gerbers). But everything else is out in the open, and I really appreciate that!

I make zero $$$ from my projects. Only others that build and sell my designs make anything, without any percentage going to me. And this is by my choice .

 

To date, everything I've created has been to the tune of nearly $4,500 out of my pocket. Good thing I like doing this stuff .

 

[ivop]

@mytek Sorry, I didn't mean to imply you make any money or profit. That's what I meant with "or try to make back ", because I know you have invested a whole lotta money to make this possible.

 

@flashjazzcat Sorry, no ulterior motive. Please don't take the word "performance" too literally. I just meant contribute and improve things or add things. Look what happened to the various incarnations of the SDrive firmware. Well, something like that.  But, it's your code and your call to make. And, I won't judge for that. You have surely written a lot of code to be proud of, and I surely appreciate that.

 

 

 

 

 

[flashjazzcat]

9 minutes ago, ivop said:

Sorry, no ulterior motive.

No worries man.

[+mytek]

Ivo no need to apologize to me, because I didn't take any offence to what you were saying. But I did feel that I needed to set the record straight. Don't want anyone thinking I've made money off of any of this . I also don't push this stuff on anyone, nor wish to take responsibility if it doesn't work the way they wanted (although I do try to fix problems if they appear). It's just my way of motivating myself to complete things by broadcasting it to the world.

 

[Marius]

Hi FJC,

 

Tonight I bricked my 800XL-U1MB with uFlash. I was wondering what could cause this? 

 

Any chance btw. that APFS will be supported one day in your loader?

 

And last but not least:

I heard some rumors that you are working on some kind of a malware detector for the SIDE loader. Any chance you could support some kind of blacklist... I might want to protect myself and family members for running certain programs by accident, or is your UI intelligent enough to detect the rotten apples on its own?

 

Thanks

M.

[flashjazzcat]

1 minute ago, Marius said:

Tonight I bricked my 800XL-U1MB with uFlash. I was wondering what could cause this? 

Hmmm... Check UFLASH version is less than seven years old. Once that's done, ensure your power supply has steady 5V output and sufficient amps. If using latest firmware and solid power supply, proceed to then use random UFLASH versions until things happen to right themselves without explanation.

6 minutes ago, Marius said:

Any chance btw. that APFS will be supported one day in your loader?

Sure! Hoping to add NTFS and ext3 support too, although I only have a dozen or so bytes free. Hopefully it will be enough!

7 minutes ago, Marius said:

Any chance you could support some kind of blacklist... I might want to protect myself and family members for running certain programs by accident, or is your UI intelligent enough to detect the rotten apples on its own?

This is on the to-do list as well, but my main priority is to add more icons to the user interface in order to distract the user from slow loading. Sadly I have very low standards.

[jamm]

4 minutes ago, flashjazzcat said:

Sure! Hoping to add NTFS and ext3 support too, although I only have a dozen or so bytes free. Hopefully it will be enough!

[Mark loves Stella]

On 2/3/2020 at 5:01 PM, Marius said:

Hi FJC,

 

Tonight I bricked my 800XL-U1MB with uFlash. I was wondering what could cause this? 

 

Any chance btw. that APFS will be supported one day in your loader?

 

And last but not least:

I heard some rumors that you are working on some kind of a malware detector for the SIDE loader. Any chance you could support some kind of blacklist... I might want to protect myself and family members for running certain programs by accident, or is your UI intelligent enough to detect the rotten apples on its own?

 

Thanks

M.

I bricked one of my 2 U1MBs a while ago. I wonder if Lotharek would consider offering an order option for just the pre-flashed MFP chips. 

[flashjazzcat]

6 hours ago, Mark loves Stella said:

I wonder if Lotharek would consider offering an order option for just the pre-flashed MFP chips

Considering he'd have to pay me a licence and would no doubt charge the same again for his own time, you might as well buy a TL866 EPROM programmer from China.

Edited February 5, 2020 by flashjazzcat

[Roydea6]

On 1/13/2020 at 10:46 AM, flashjazzcat said:

Updates coming for:

 

U1MB (including 1088XEL/XLD)

Incognito (including COLLEEN.SYS driver)

SIDE/SIDE2 (loader and SIDE.SYS driver)

MYIDE/MYIDE2 (MYIDE.SYS and MYIDE2.SYS drivers)

 

Plus updated APT tools (FDISK, etc) and (at last) new APT ROM for the old IDEa interface.

 

Bumping this thread in the hope of seeing the APT tools and drivers.

 

[flashjazzcat]

26 minutes ago, Roydea6 said:

umping this thread in the hope of seeing the APT tools and drivers.

Your bump is well-timed, Roy. There is a deluge of stuff about to be released (finally... I know I've been saying this for months).

[flashjazzcat]

Little update on things. I am in the process of putting together all the release packages, and ought to get everything done this weekend. I solved an interesting long-term mystery yesterday, however, while testing a MicroSD/CF adapter that Lotharek kindly sent over with some other stuff. This is the same adapter/MicroSD card combo he sells on his website, and I thought it would be useful to test it since I only had adapters for full-sized SD cards.

 

Anyway: a while ago I fixed a bug which only showed up with SD/CF adapters. Specifically, the ATA spec states that newly issued commands cancel out any pending transactions. Which is to say, if you issue a sector read and only read half the buffer, the next issued command will cause the pending data in the buffer to be lost, and everything will proceed as normal. A while ago, it became apparent that this is not the case when using SD adapters. Having delved into SPI SD drivers, I do know that one cannot just abandon the data stream at a whim, and the SD/CF adapters appear to have the same limitation.

 

The loader treats the actual ATA data register as a kind of sector buffer instead of allocating a buffer from system RAM on the Atari. This makes everything faster and allows the XEX loader itself to consume only 750 bytes of RAM. It's important that when we abandon a sector read part way through, however, that we purge the data buffer. This is a "don't care" with real CF cards if another command is issued immediately afterwards, but if not, the effect is cosmetic: i.e. the HDD activity light remains stuck on. Of course this flushing of the data buffer happens all over the loader, but it was missed in one crucial case, namely when the default directory was not the root. When the loader boots up to a subdirectory (via the 'Recall folder' feature), it has to follow the path back to the root so that it can display said path on the screen. There was a missing 'flush buffer' call there which caused a NAK error with SD adapters (whereas with CF cards, the HDD light simply remained stuck on). The same bug was observable when a long directory (>250 filenames) was split into segments.

 

In any case: having fixed these issues some months ago, I yesterday observed the same problem when re-entering the loader after running an XEX which didn't reach the end of file (at which point, the loader flushes the data buffer). Perhaps it was a multi-stage load, but the demo left the HDD LED lit when it started running. When I started the loader again, I got a NAK error, despite the fact the first thing the loader does when it starts is to fully reset the card.

 

Well, it turns out that even a card reset does not flush the buffer with SD/CF adapters. If there is pending data, it MUST be manually read out of the data register before further commands can be issued. So I have made a last-minute change to the loader and the PBI BIOS to account for this, and it completely fixes the issue.

Edited March 21, 2020 by flashjazzcat
typos

[jamm]

Nicely deduced, my dear fjc

 

[_The Doctor__]

interesting, I think this behavior bears further discussion with the DLT (SpartaX) crew and also with the SD cartridge devs we have on the forums. It nails the whole this just ran for me and now it doesn't scenario where you are forced to power off ( thereby clearing everything ) to run something again when a warm or cold start of the Atari (or even the device) does not clear it surprisingly as the card itself has to be told what to do, buffer drained, or power cycled. Power cycled to the Atari if the device is powered by the Atari (cartridges) or the actual device does. So long as that buffer has power it stays until flushed as you described or lack of power clears it. In an effort not to lose anything it's hold on that partial data is in the way.

Edited March 21, 2020 by _The Doctor__

[flashjazzcat]

1 hour ago, _The Doctor__ said:

I think this behavior bears further discussion with the DLT (SpartaX) crew and also with the SD cartridge devs we have on the forums.

This is a low-level device driver issue, and all the drivers which ship with SDX either target serial IO (SIO.SYS, PCLINK.SYS, etc) or are completely hardware abstracted (i.e. when an SIO request is intercepted by a PBI device). The SIDE.SYS driver for SDX is written by me (and it occurs to me that it will require the same fix, so I now know what I'm doing on Sunday afternoon). I can't really see any sense in which quirks of SD/CF adapters will have any bearing on any perceived intermittent issues in SpartaDOS X which require power cycling.

 

Even the now prevalent SD multi-carts completely abstract the SD storage media used to launch cartridge images, etc, from the hosted software. So: if SDX is launched from - say - the UNO Cart and SDX experiences some issue which requires a restart, it's either a bug in SDX which has nothing to do with the UNO Cart, or it's a bug in the UNO Cart which has nothing to do with the authors of SDX.

 

[_The Doctor__]

thumbs up on the side driver fix :)

[flashjazzcat]

The testing scenario for SIDE.SYS was a little contrived but nevertheless showed that CF/SD adapters caused an issue. I booted SDX from SIDE2, typed 'CAR' to start the loader, ran the demo, observed the HDD LED stuck on, pressed the cart reset button, pressed system reset, SDX booted again, and the SIDE driver failed to report the card model. With the patch in place, there was no problem. I guess you could trip this situation simply by abandoning any XEX load mid-way through via system reset.

 

Remember: unless you use SD/CF adapters, this whole thing is a non-issue.

[Donald Dennis]

On 3/21/2020 at 3:26 PM, flashjazzcat said:

This is a low-level device driver issue, and all the drivers which ship with SDX either target serial IO (SIO.SYS, PCLINK.SYS, etc) or are completely hardware abstracted (i.e. when an SIO request is intercepted by a PBI device). The SIDE.SYS driver for SDX is written by me (and it occurs to me that it will require the same fix, so I now know what I'm doing on Sunday afternoon). I can't really see any sense in which quirks of SD/CF adapters will have any bearing on any perceived intermittent issues in SpartaDOS X which require power cycling.

 

Even the now prevalent SD multi-carts completely abstract the SD storage media used to launch cartridge images, etc, from the hosted software. So: if SDX is launched from - say - the UNO Cart and SDX experiences some issue which requires a restart, it's either a bug in SDX which has nothing to do with the UNO Cart, or it's a bug in the UNO Cart which has nothing to do with the authors of SDX.

 

   Hi Jon, Hope you're well and congratulations on getting the move completed. Wanted to chime in on this thread and share an experience/issue I happened upon many months ago and what ended up resolving it with a very desired result.

   I had the Side 3 cartridge You and Lotharek assisted me in un-bricking functioning perfectly normal. It did so for a few months, and it suddenly decided to stop loading files of any type. Well I'd since procured a couple of other Side 3 cartridges and an AVG cartridge for good measure and just tossed the troublesome one in one of my parts/junk boxes where it languished for a number of months.As it happens, I had very little to do in the way of necessary tasks this past weekend and decided to have another look at it. On que, it wouldn't load any files. I then however, remove the SD card and was able to manipulate the menu settings, set date and time etc. I made the natural deduction that the cartridge was functioning on some level so there had to be something very minor

   A day or two passed by and while trying to fall to sleep, I got a flash of brilliance (Sometimes I get lucky that way). So in an effort to conclude this tale, there was no getting to sleep with this bouncing around in my head so I got dressed, made my way out to my "laboratory" and sprayed out the actual SD card slot with Deox.

   As I live and breathe, that simple act cured the problem and returned the cartridge to full service. Upon considering this, I began piecing together that I'd been seeing similar issues with the other Side 3 cartridges but intermittently. So, the other Side 3's and the AVG cartridge for good measure promptly received the same treatment. All the sporadic hang ups and such as that vanished. I couldn't have been happier is I'd won a lottery. Rookie error but I'm glad it turned out how it did.

                                                                                       Don

[woj]

Is it only me or some misunderstanding of what the option should actually do, or is it a bug in the firmware that the "Boot" option for "BIOS logo" does not really do what it is supposed to? I mean, with this option on, I only get the bios splash screen on power up, or on some reboots triggered by the U1MB itself, never ever on any other reboot, for example when saying "cold" in SDX. In essence, I feel that there is no difference between "Power On" and "Boot" options here?