U1MB, Incognito, SIDE2, SIDE3, 1088XEL/XLD Firmware 4.0 Released

[Faicuai]

3 hours ago, flashjazzcat said:

I'm not sure this has happened before on the A8 without an MCU and fatfs doing all the work

Very nice!! A tall order, indeed, and especially doing so without resorting to a "prosthetic" prescription... ??

[Mazzspeed]

9 hours ago, Faicuai said:

Very nice!! A tall order, indeed, and especially doing so without resorting to a "prosthetic" prescription... ??

 

vs

 

 

Yeah...I'm not seeing the connection.

[flashjazzcat]

30 minutes ago, Mazzspeed said:

I'm not seeing the connection.

Well, a prosthetic leg prevents the wearer from directly contacting the road, just as an MCU running a complete FAT filesystem driver which performs IO tasks on a proxy basis completely abstracts said file system from the Atari itself.

[Mazzspeed]

43 minutes ago, flashjazzcat said:

Well, a prosthetic leg prevents the wearer from directly contacting the road, just as an MCU running a complete FAT filesystem driver which performs IO tasks on a proxy basis completely abstracts said file system from the Atari itself.

Lol!

 

Very good FJC.

[Faicuai]

7 hours ago, flashjazzcat said:

an MCU running a complete FAT filesystem driver which performs IO tasks on a proxy basis completely abstracts said file system from the Atari itself.

So, for (total) clarity, are we celebrating (a) the abstracted model, or (b) winning the iron-man on bare-foot?

[flashjazzcat]

I purchased a SanDisk 'Ultra' 64GB SD card for the express purpose of checking for problems on my own working setup (an U1MB/VBXE/PokeyMAX 3 600XL with the original 74LS08 IC, powered by a Lotharek 'Meanwell' 3A switch mode PSU), and everything works (XEX loading, CAR loading via DMA, PDM playback now that the endian-ness bug is fixed). Any problems encountered elsewhere which might conceivably be ameliorated by modifications to the host machine, firmware, FPGA code or power supply cannot be ascribed to the capacity of the card, at least.

[flashjazzcat]

I noticed that SDXC cards (>32GB) weren't correctly labelled as such in the loader's Device menu. Version 0.44 fixes this cosmetic issue:

 

https://atari8.co.uk/firmware/side3/

 

Update for SDTEST (now called SDINFO):

 

sdinfo.xex

 

Changes:

• Reports serial number as a 32-bit unsigned decimal integer
• Offers to test additional hot-swapped cards and manages the card removal flag properly to facilitate this

[flashjazzcat]

Experimental SIDE3 loader now allows XEX files to write to FAT16 and FAT32 volumes via the CIO. This video shows UFLASH dumping the U1MB ROM and then flashing it back.

 

 

These are the resulting files:

 

 

As you can see, the files are time/date stamped courtesy of the SIDE3's RTC. There's a long way to go before this is in any way fit for release (aside from the vast amount of testing required, I need to implement an 'internal' version of the same driver now so that the loader itself can write to the FAT, the CIO file system handler loaded with XEX files being a completely self-contained module), but it shows that everything I have in mind (INI files, file management functions, etc) will eventually be accomplished.

Edited July 31, 2021 by flashjazzcat

[Jacques]

2 hours ago, flashjazzcat said:

As you can see, the files are time/date stamped courtesy of the SIDE3's RTC.

Does it mean SIDE3 RTC issue under SDX is fixed? Or is it courtesy if U1MB's RTC maybe?

[flashjazzcat]

11 minutes ago, Jacques said:

Does it mean SIDE3 RTC issue under SDX is fixed?

No - I heard nothing back about this yet. But the loader uses its own RTC driver and manages the clock totally independently of SDX. I have noticed no problems there at all. It would not make any sense to use the U1MB RTC, since there's no guarantee U1MB will even be present in the machine.

Edited July 31, 2021 by flashjazzcat

[Xuel]

@flashjazzcat It looks like the new SIDE loaders (v0.43) don't initialize the second POKEY when playing .PDS files so the right channel is effectively only 4-bit resolution instead of 8-bit since the oscillators are never started.

[flashjazzcat]

8 hours ago, Xuel said:

It looks like the new SIDE loaders (v0.43) don't initialize the second POKEY when playing .PDS files so the right channel is effectively only 4-bit resolution instead of 8-bit since the oscillators are never started.

Correct - good spot. I completely forgot to initilialise the second POKEY when I first implemented stereo playback.

 

Fixed. Try this (v.0.45):

 

s3loader.xex

 

 

[Level42]

On 7/30/2021 at 3:31 PM, flashjazzcat said:

I purchased a SanDisk 'Ultra' 64GB SD card for the express purpose of checking for problems on my own working setup (an U1MB/VBXE/PokeyMAX 3 600XL with the original 74LS08 IC, powered by a Lotharek 'Meanwell' 3A switch mode PSU), and everything works (XEX loading, CAR loading via DMA, PDM playback now that the endian-ness bug is fixed). Any problems encountered elsewhere which might conceivably be ameliorated by modifications to the host machine, firmware, FPGA code or power supply cannot be ascribed to the capacity of the card, at least.

How did you format the card ?

Edited August 2, 2021 by Level42

[flashjazzcat]

5 minutes ago, Level42 said:

How did you format the card ?

Straight out of the packaging into the SD card slot of my 2015 Macbook (Big Sur OS); Disk Utility, Erase, MBR, FAT32.

Edited August 2, 2021 by flashjazzcat

[Level42]

Well that's weird. 

 

The only difference regarding formatting is that my SD card slot in my 2009 iMac is a lot older but I don't see that can have any influence.

I'm also still on OSX HighSierra because BigSur doesn't support my old Mac. But again, I don't see Disk Utility be/act any different.

I put back in the original 74LS08, no change.

I removed AntiX and installed PAL and NTSC ANTICs directly into the original motherboard socket and tried....no change.

Now there is "just" U1MB, Stereo Pokey (both Lotharek) and Sophia1. (and....OK....the power supply)....

I'll see if I can remove Sophia and put the GTIA back into it's original socket...
 

[flashjazzcat]

I don't find it weird that I experienced no issues, since this is exactly what I expected, having already tested the 64GB FAT32 formatted ISO you were kind enough to send over last week. That would ostensibly rule out file system driver problems purely related to volume size and FAT quirks. I think looking at the hardware revision of the SD card slot or even the OS revision of the machine which formatted the card is probably grasping at straws at this point.

 

Focusing on the computer or SIDE3 cartridge itself would seem a sensible way to proceed, as would trying a modern power supply (and we cannot discount power related issues until you do this).

 

I'm not especially surprised that 74F08 isn't making much difference here, either, since it seems this 'fix' primarily addresses two catastrophic failures: the complete invisibility of the SIDE3 cartridge to the system, or the plunging of the system into blackness when attempting to start the loader. If there is a case where 74F08 specifically cured SD card IO issues, I can't recall it at the moment (maybe Herb's 1200XL, but that machine appears to still have problems with SIDE3 anyway).

[Level42]

Lot's of sensible stuff there...

Need to find an old video cable to remove my Sophia to rule that one out. I seem to remember some others with Sophia 1 having some issues ?

Not sure though !

I don't plan on removing anything else. I think it's well established that U1MB and StereoPokey isn't causing any issues.

Just for the sake of it, I just "copied over" only the game files one more time (instead of formatting the 64GB card, and separately from that I formatted from the command line but I didn't expect this to do anything else than Disk Utititly does.

I'm still not even slightly convinced that a PSU could have any influence on this particular behaviour (the pattern is way to rigid) BUT, I will get out the oscilloscope and see how healthy my original Atari one is. I also have a few other Atari PSU's to try.

[flashjazzcat]

FAT32 file with long name created by SIDE3 loader after several hours of single-stepping and debugging:

 

[_The Doctor__]

29 minutes ago, flashjazzcat said:

FAT32 file with long name created by SIDE3 loader after several hours of single-stepping and debugging:

 

FJC has done a thing! and it's a good thing! Thanks FJC!

[Gryfon]

@flashjazzcat An update following your suggestion to send my 800XL to @candle .  He's confirmed:

- It works with his PSU

- "for some reason it doesn't work without any cartridge with setup you've set - XEGS OS is to blame - for some reason - FJC assures me that it should work, but all i get is black screen". 

I replied that I also get similar results (for example being able to access SDX) when XEG OS is not the selected OS.

And that was the last I heard from him which was a month ago.  I don't suppose he's been in contact with you about this firmware update?
I gave him my email address,  but alas frequently don't receive emails to it unless I've white-listed the sender first, so my only means of communication with Candle has been AtariAge messaging.

[flashjazzcat]

He did tell me that someone had sent a machine in and that he was studying it, and I've asked him if this revealed anything interesting but so far nothing, as far as I know. I've linked him to your post just now, however.

[+DrVenkman]

On 8/2/2021 at 8:41 AM, flashjazzcat said:

(maybe Herb's 1200XL, but that machine appears to still have problems with SIDE3 anyway).

Based on last weekend's experiments, I can say that is true, though so far as I can tell, the only problems are the visual glitches that occur on specific individual characters when the machine is cold. When it warms up for an hour or so, those disappear entirely. 

 

And in no instance is the machine unstable at all either, which seems odd. I can load CAR images, boot into SDX, access the CAR images and mounted ATRs or the APT hard disk partitions without any trouble. Appears to be entirely a visual thing. Not sure if it's an RF issue (no shielding on my machine, of course), a cable capacitance issue (using stock cables, folded rather than cutting them down to length), or an ANTIC that's starting to act up. No clue. If I had a space NTSC ANTIC sitting loose, I'd swap it and see. 

 

But it is DEFINITELY only present with SIDE3 inserted in the computer.

[Level42]

12 hours ago, DrVenkman said:

Based on last weekend's experiments, I can say that is true, though so far as I can tell, the only problems are the visual glitches that occur on specific individual characters when the machine is cold. When it warms up for an hour or so, those disappear entirely. 

 

And in no instance is the machine unstable at all either, which seems odd. I can load CAR images, boot into SDX, access the CAR images and mounted ATRs or the APT hard disk partitions without any trouble. Appears to be entirely a visual thing. Not sure if it's an RF issue (no shielding on my machine, of course), a cable capacitance issue (using stock cables, folded rather than cutting them down to length), or an ANTIC that's starting to act up. No clue. If I had a space NTSC ANTIC sitting loose, I'd swap it and see. 

 

But it is DEFINITELY only present with SIDE3 inserted in the computer.

Swap it from your 1088….

 

Folding any cables is a bad idea. You create a coil.

 

No shielding has never caused any issues for me.

 

Maybe the issue is a electrolytic cap problem. In the machine, or the power supply.

 

I plan on replacing the ones in my 600XL. I measure them (ESR and C) about every year and they are still fine (Atari used quality parts in Warner days) but it won’t hurt for my main driver to put in some fresh Nichicons or Panasonic’s, 105 degr. and low ESR.

 

Edited August 7, 2021 by Level42

[Gryfon]

On 8/6/2021 at 7:05 PM, flashjazzcat said:

He did tell me that someone had sent a machine in and that he was studying it, and I've asked him if this revealed anything interesting but so far nothing, as far as I know. I've linked him to your post just now, however.

Keep meaning to update this: had a message from Candle:

 

“…issue seems to be related with side3 memory timing - no matter if there is ls08, als08, ahct08, f08 chip installed, doesn't matter what cpu is running, or antic chip

side3 cartridge was also excluded - i can use any of what i have and the result is always the same

if something is not using this memory - like side3.sys or side3 pbi driver - there is no issue - sparta dos works as it should”

[flashjazzcat]

So the fact it doesn't work has been professionally confirmed, at least.

 

CIO FAT driver is almost done, exhaustive testing notwithstanding. Three file channels, read/write FAT12/16/32 support, relative POINT/NOTE, burst IO, subdirectories and get current path/CHDIR XIO commands supported.

 

I finally re-implemented BASIC auto-load today and am now able to play with files via the interpreter, which makes testing easier. Screenshots just show loading/saving of programs in Altirra BASIC, a directory listing and CHDIR via XIO (it would be very cool if interpreters would issue standard SDX-compatible XIO commands for CHDIR and such, but I understand space constraints often prevent this).