Jump to content
IGNORED

FujiConvert 0.1


Xuel

Recommended Posts

16 minutes ago, Level42 said:

Could OSX be doing something to the filenames ? Like an extra extension or so ?

I have seen OSX adding all sorts of "hidden" . (dot) files and directories on my USB stick without me asking for it (had to clean it up when I got home), but it did not touch or rename the original files.

 

Quote

Else it might be the SD card……

Possibly.

 

Quote

or my SIDE3 is partially defective ?

Or the combination of SIDE3 with that particular card is not working. Now which one of them is defective is hard to say.

 

10 minutes ago, flashjazzcat said:

Puzzling.

Thinking out loud, perhaps it's an exFAT thing?

 

@Level42 be sure it is really FAT32. If you know your way around the command line, use mkdosfs to format your SD card. Triple check whether you are formatting the right device ;)

Edited by ivop
Link to comment
Share on other sites

Hmmm, I'm pretty sure it's the SD card now.

 

Seriously, I have no modern/big SD cards in the house.... except for the one of the NAV in my car but I'm not going to fiddle with that one :)

 

Anyone, up for grabs was an "ancient" Kingston 1GB SD card (absolutely "standard").

I formatted it to the default Apple file system and then back to FAT (MBR) again to be sure it did it's work.

 

I copied a few games to it which all load fine.

 

Then I copied three songs and these were my results.....

 

https://youtu.be/7_yIVXfIzo0



(Not using this forum's built-in video upload anymore, it doesn't play on Safari under OSX nor on Safari or Firefox on iOS devices......I mean.... really ???) 

Link to comment
Share on other sites

Can't see the video since it's private (make it 'unlisted', ideally), but I might tactfully suggest buying a new 32GB Sandisk Ultra card if possible. Might seem ludicrously extravagant for an 8-bit Atari, but it's what shipped with my AVG cart and it works fantastically well in my SIDE3.

Link to comment
Share on other sites

So, it looks (amazingly) that this SD card gets JUST a bit further into the process then my 4GB Sandisk....(which I didn't expect). One file obviously produces exactly the same result, one results in a solid vertical bar (I could _just_ here the tiniest bit of noise before that appeared, not sure if the video caught it), and the third one actually shows some graphics and "hangs" with noise....

 

Link to comment
Share on other sites

3 minutes ago, flashjazzcat said:

Can't see the video since it's private (make it 'unlisted', ideally), but I might tactfully suggest buying a new 32GB Sandisk Ultra card if possible. Might seem ludicrously extravagant for an 8-bit Atari, but it's what shipped with my AVG cart and it works fantastically well in my SIDE3.

Didn't set it to private but to public....that's weird.

 

Yeah as I mentioned I already ordered a 64GB Sandisk Ultra SD. (Hope 64GB isn't too big ?).

I do say I have to protest about this all..... I mean, IMHO I only get the real experience with legacy original small old SD cards......



:D

Link to comment
Share on other sites

2 minutes ago, Level42 said:

Yeah as I mentioned I already ordered a 64GB Sandisk Ultra SD. (Hope 64GB isn't too big ?).

Sorry - I don't have instant recall of all acquired info at the moment. :) 64GB is fine, anyway.

 

I am not sure what it is about older cards, but the kludges required to get beyond 1GB in the pre-SDHC and XC days can result in some quirky behaviours. Oddly, it was often the same with SIDE/SIDE2 and old CF cards of lower capacities.

  • Like 1
Link to comment
Share on other sites

The player makes the bold assumption that the hardware works, BTW; it was such a task to actually issue SD card read requests using instructions interleaved with simultaneous playback from the sector buffer that there is little opportunity for error handling in this context. So I can only guess that the transaction f***ed up royally if you get a solid bar down the screen.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, flashjazzcat said:

The player makes the bold assumption that the hardware works, BTW; it was such a task to actually issue SD card read requests using instructions interleaved with simultaneous playback from the sector buffer that there is little opportunity for error handling in this context. So I can only guess that the transaction f***ed up royally if you get a solid bar down the screen.

Yeah I figured that the PDM playback routines loaded "while" playing back which is of course something completely different than loading a game file in one go while the machine is basically doing "nothing".

I'm quite sure the newer SD card will fix it. I thought it would be delivered tomorrow but now it looks like it will take a few days.... o well....

Link to comment
Share on other sites

51 minutes ago, Level42 said:

Yeah I figured that the PDM playback routines loaded "while" playing back which is of course something completely different than loading a game file in one go while the machine is basically doing "nothing".

I'm quite sure the newer SD card will fix it. I thought it would be delivered tomorrow but now it looks like it will take a few days.... o well....

might want to make sure your power supplies are beefy enough to do the job, It wouldn't be a great test if you don't swap power supply out with each computer either.

Link to comment
Share on other sites

Hello Andreas

 

11 hours ago, CharlieChaplin said:

Regarding stereo, I do have some old 60s music (e.g. The Mamas and the Papas "CD"), where one channel is music and background vocals and the other channel is main vocals. When I convert this to mono, both channels play the same - but ermmm, when I convert this to stereo both channels still (again) play the same. The separation like in the original recording does not seem to work or I am doing something wrong.

 

I convert everything to stereo.  I converted the song they use as the theme to the British TV series "Are you being served" to "ultimate cart" before I had an AVG cart.  During part of the song you can hear the sound coming from either the left or the right speaker just like it was intended way back when.

 

Sincerely

 

Mathy

 

Link to comment
Share on other sites

3 hours ago, _The Doctor__ said:

might want to make sure your power supplies are beefy enough to do the job, It wouldn't be a great test if you don't swap power supply out with each computer either.

I strictly only use original Atari power supplies. And not just for that original feeling.

I cannot see this to be the reason why PDM files aren’t working while everything else works.

Edited by Level42
Link to comment
Share on other sites

Out of interest: how much does the speed of the SD card influence loading times (f.i. Large ATRs) with SIDE3/U1MB  ?

 

I ran Numen as a way to time ATR loading and timed it from the starting the loading process from the intro menu (with the cat and clock). Both the Kingston and SanDisk performed exactly the same at 33 seconds.

 

Faster SD cards are only a few euros more than “slower” ones….would it be worth getting a really fast one ?

5C9E0E0E-2AB7-4E41-95C9-D5E7A6132F89.png

Edited by Level42
Link to comment
Share on other sites

43 minutes ago, Level42 said:

Out of interest: how much does the speed of the SD card influence loading times (f.i. Large ATRs) with SIDE3/U1MB  ?

 

I ran Numen as a way to time ATR loading and timed it from the starting the loading process from the intro menu (with the cat and clock). Both the Kingston and SanDisk performed exactly the same at 33 seconds.

 

Faster SD cards are only a few euros more than “slower” ones….would it be worth getting a really fast one ?

5C9E0E0E-2AB7-4E41-95C9-D5E7A6132F89.png

Honestly, I'm struggling to see the UHS ratings on those cards, I think the top two are UHS 3 and the bottom one is UHS 1?. In my experience UHS 1 equates to a read speed of around 88,000B/sec under RWTEST on the A8 via SIDE3. UHS 1 handles a minimum speed of 10MB/s, which is well above the speeds an A8 is capable of. Personally I don't think UHS 3 would make any difference.

 

However, I have found certain SD cards are sometimes 10,000B/sec faster in writes, with read times not changing at all.

  • Like 1
Link to comment
Share on other sites

No zoom option on your device ? (I can’t live without pinch and zoom on iOS and OSX ate the age of 53)….

 

It’s 170,150,120MB/s from top to bottom. Yeah the top 2 show a 3 inside the letter U and the bottom one 1.

 

Yeah I think in one of his videos Jon mentioned that the A8 is actually doing the work, not so much something on SIDE3. The cartridge port speed (= system speed) is probably the limiting factor so my guess is same as yours Mazzspeed…..

 

I also strongly doubt the built-in SD card reader of my old 2009 iMac will handle these cards at full speed…..in fact…..come to think of it, I hope it will support them at all ! Yikes…

 

 

Edited by Level42
Link to comment
Share on other sites

10 hours ago, Level42 said:

I strictly only use original Atari power supplies. And not just for that original feeling.

Be prepared to experiment with something more modern if problems persist.

1 hour ago, Level42 said:

Faster SD cards are only a few euros more than “slower” ones….would it be worth getting a really fast one ?

The only variable as far as the Atari is concerned is the delay between requesting a sector and the card confirming that the data is ready. The actual data buffer is read at a constant rate (as fast as the 6502C can possibly transfer it), so a 'slower' card is taking longer to prepare the data buffer for reading back. DMA on the SIDE3 is also constant rate (1.7MB/s). Modern devices will be DMA'ing data off the card at much higher speed and typically in large cluster-sized blocks (although the loader also reads full clusters via DMA when reading cart images). So: it's the 'seek latency' (buffer retrieval by the card's controller) which makes the difference with SIDE3.

53 minutes ago, Mazzspeed said:

In my experience UHS 1 equates to a read speed of around 88,000B/sec under RWTEST on the A8 via SIDE3.

I must say that HDD benchmarks obtained with ANTIC DMA disabled aren't very illustrative, and I can't compare them at all to the best case ~65KB/s reads I see on PAL systems with the screen enabled. But - as mentioned elsewhere - I have seen reads vary by as much as 10KB/s (so - 55KB/s to 65KB/s) depending on the card being used. This is entirely down to the aforementioned turnaround time between issuing a read request and being presented with a buffer full of data by the SD card controller. This is the only thing about the transaction which is indeterminate in terms of time.

44 minutes ago, Level42 said:

Yeah I think in one of his videos Jon mentioned that the A8 is actually doing the work, not so much something on SIDE3. The cartridge port speed (= system speed) is probably the limiting factor so my guess is same as yours Mazzspeed…

Atari bus speed limits the speed of data buffer transfer (DMA: 1.79MB/s, CPU: ~90KB/s minus ANTIC overhead and VBI). Faster SD card may have a shorter command response time, however, and this is what counts.

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

6 minutes ago, Mazzspeed said:

Ah, yes. I should have mentioned that my RWTEST results are with DMA disabled. Sorry, I forgot to mention that.

It's OK - there wasn't really any doubt about it, but it's useful to see DMA-enabled results from my point of view since I never test with DMA off. In any case, 65KB/s is the fastest I have observed on SIDE2 or SIDE3 with DMA enabled, and it looks like there's much more variation with SD cards than there is with CF cards (or SD/CF adapters for that matter).

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, flashjazzcat said:

I must say that HDD benchmarks obtained with ANTIC DMA disabled aren't very illustrative,

Much on the contrary, it turns out they are, for a couple of key reasons:

 

  1. If interacting with the system only takes place via "loader" or via OS-provided E: session (e.g Antic-dominant), DMA=off I/O won't be that much relevant there (unless loading many games that will de-crunch themselves with DMA=off). However, when doing mainly so via an 80-cols. session where DMA=off is a functional requirement (like XEP80 and upcoming XEP80-II with Avery's Ultra-drivers), the "world" surely looks different there, since all cpu-dominant I/O will see (on the screen) a significant speed boost.
  2. In the case of the 800/Incognito architecture, I can have its internal SIDE-based HD coexisting in the same SDX session with a SIDE2 or [AVG-on-SIDE-emulation] HD plugged into left-port (both HDs independently accessible). When operating with DMA=off, Incognito's own HD will repeatedly reach ~90 KB/sec. (SDX), while its AVG emulated counterpart tops out around 70-75 Kbytes (a difference that will not surface so clearly when operating with DMA=ON).

 

In summary, and based on the above context, testing with DMA=off turns out to be not just revealing, but the only way to test local HD-storage throughput to the maximum possible (cpu-dominant) limit of performance.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...