FujiConvert 0.1

[flashjazzcat]

17 minutes ago, Faicuai said:

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

It turns out that you think they are. I don't generally speaking run the machine with the display turned off. You do. Most people don't.

[Faicuai]

1 minute ago, flashjazzcat said:

I don't generally speaking run the machine with the display turned off. You do.

In #1 reason shown before, yes (and when XEP80-II comes around, it will be more so).

 

For #2 reason, however, it is turns out the only way to get the truth. And that's good enough.

[Level42]

5 hours ago, Level42 said:

 

Well, just for the sake of finding out (and of course, fun while doing so) if, and which SD cards are faster on the A8, I decided to order them all. Thankfully Dutch law allows me to return the one's I don't want to keep for a full refund.

 

I didn't go fur the REALLY fast cards (300MB/s) though.....they were to steep in price anyway to be considered IMHO. (Like a few hundred euro).

They should arrive tomorrow.

Edited July 20, 2021 by Level42

[flashjazzcat]

Truth is, ANTIC DMA is enabled 90 per cent of the time when I use my HDD for copying, loading, etc. That will probably be typical of many users until they are issued with mandatory XEP80-IIs.

 

Please measure throughput as you see fit, anyway, but DMA-off results are of little interest to me since I spent the past ten years benchmarking HDDs in a context which best reflects typical usage. RWTEST is little more than a sanity check most of the time, anyway, since buffer transfer is completely determinate and the command latency between one card and the next rarely accounts for more than a ten per cent variation, which - again - is all but unnoticeable in real-world contexts.

[flashjazzcat]

6 minutes ago, Level42 said:

I decided to order them all

That's real commitment.

 

[Faicuai]

2 minutes ago, flashjazzcat said:

Please measure throughput as you see fit, anyway

Will happily and joyfully do so! 

 

Pedal-to-the-metal.  ??

[flashjazzcat]

Ensure a 20MHz 65C816 is used where possible as well, in that case, in order to alleviate the other arbitrary restriction (1.79MHz CPU speed). I can then attain 90KB/s reads with DMA enabled (when the accelerated system chooses to work, of course), and 120KB/s or more with the IO code situated in fast RAM. I suppose these might as well be considered meaningful averages.

 

[Faicuai]

49 minutes ago, flashjazzcat said:

I suppose these might as well be considered meaningful averages.

Indeed... if / when it works, of course. ?

[_The Doctor__]

Antic on and off can be used to greatly reduce loading times and when decompressing / compressing items... ANTIC off was also the only way to get full throughput BBS'ing on the 8 bit back in the day...  you would find ANTIC was off 90% of the time for the BBS, as it greatly reduced waits for the user to pull screen as well as making uploads and downloads as fast as possible, it also allowed for qwk packets to be sent fast and effectively... so it all depends on what you are using and serving from your Atari. It also made the arc/unarc function that served documents on the BBS extremely faster. This also lent itself well to SDX and it's compression/decompression utils that have it built in. This is extremely important to some of us, especially in the communications world...

Edited July 20, 2021 by _The Doctor__

[Faicuai]

59 minutes ago, _The Doctor__ said:

This also lent itself well to SDX and it's compression/decompression utils that have it built in. This is extremely important to some of us,

Absolutely!

 

ARC'ing / un-ARC'ing SDX toolkit files we later find useful, creating / moving / copying multiple files + directories, performing large-scale integrity operations like CLX, attributes-controlled back-up operations (including large files) from one localized portion of an HD (APT-bound) to another HD (because you have multiple machines and their HDs are different), loading your favorite Basic or Assembler interpreters / compilers for small projects, using "LESS" command to open and load that large FastBasic help.txt file into 1MB  extended memory-expansion, securing integrity and down-the-last-bit of SIO-interface performance at lowest divisors, and on, and on...

 

But hey!, let's just stick to loading kiddie Pogo-Joe with DMA always on, and forget altogether about PDM-player... ?

 

 

Yeah, right...

[flashjazzcat]

Is the implication that a minority group has been offended by the suggestion that they are in the minority, or what? Anyone vaguely familiar with the machine architecture already knows that ANTIC DMA steals a measurable number of CPU cycles.

Edited July 20, 2021 by flashjazzcat
typo

[_The Doctor__]

Wasn't aware I or anyone else was a minority group member or was offended... it is possible to be in a majority group bubble and still be a minority across the globe though. Not sure what purpose that serves... nor the purpose of the post it's responding to.

 

Hopefully it all gets sorted out and everything works optimally across all usage vectors. Looks to be another AA day. Let's do something, anything but another stroll down the current lane of this and that. This actually needs to be another thread as it's more-so about the hardware or firmware it's on rather than fujiconvert.

Edited July 20, 2021 by _The Doctor__

[flashjazzcat]

I suggested that DMA-on represents the most common usage scenario, and the usual two members turn up in a timely fashion to expound the virtues of DMA-off. This is a perfect example of a canonically accurate generalisation garnering the typical Internet reaction.

[_The Doctor__]

42 minutes ago, flashjazzcat said:

I suggested that DMA-on represents the most common usage scenario, and the usual two members turn up in a timely fashion to expound the virtues of DMA-off. This is a perfect example of a canonically accurate generalisation garnering the typical Internet reaction.

Get real. It was simply an explanation why I and others use it in that fashion... I'll stand by my posts... you can reduce your statements as suggestions for posturing and position and then bolster what you eventually decide with your usual flair, but that's not intellectually honest imho. It's simply a fact that those in the BBS world use it. Those in the SpartaDOS / SDX world do as well. It certainly has many other applications and uses to varying degrees. It's understandable that not everyone does, but to attempt to ridicule and argue with those that do seems petty and serves no purpose.

2 hours ago, _The Doctor__ said:

Antic on and off can be used to greatly reduce loading times and when decompressing / compressing items... ANTIC off was also the only way to get full throughput BBS'ing on the 8 bit back in the day...  you would find ANTIC was off 90% of the time for the BBS, as it greatly reduced waits for the user to pull screen as well as making uploads and downloads as fast as possible, it also allowed for qwk packets to be sent fast and effectively... so it all depends on what you are using and serving from your Atari. It also made the arc/unarc function that served documents on the BBS extremely faster. This also lent itself well to SDX and it's compression/decompression utils that have it built in. This is extremely important to some of us, especially in the communications world...

51 minutes ago, _The Doctor__ said:

Wasn't aware I or anyone else was a minority group member or was offended... it is possible to be in a majority group bubble and still be a minority across the globe though. Not sure what purpose that serves... nor the purpose of the post it's responding to.

 

Hopefully it all gets sorted out and everything works optimally across all usage vectors. Looks to be another AA day. Let's do something, anything but another stroll down the current lane of this and that. This actually needs to be another thread as it's more-so about the hardware or firmware it's on rather than fujiconvert.

It may be some odd configuration as well but since it's only two people with the problem... just like saying it's only two people who use the screen off... (yeah right) for compression/decompression/BBS and other uses... we can just be flip/off hand/belittle/group and dispose of it all. Just call it an edge case and write it off as not being valid. OR we can at least let people know where we are coming from, explain what's observed and try to help the few with an issue... who knows it might solve something not obvious in other areas. This all still needs to be in another thread though...

[Faicuai]

2 hours ago, flashjazzcat said:

minority group has been offended by the suggestion that they are in the minority, or what?

Not at all.

 

In fact, for those here who are really paying close attention to detail, it turns out that this thread directly relates PDM's encoder (and player). And in "rare" turn of events, it turns out that current PDM player can only run fully because DMA is... OFF (!!!) That in turns means (n the context of this thread, which is the only thing that matters) that *every* *single* PDM user here relies on having DMA=off to listen to their favorite soundtracks, which (by definition) makes us all an absolute majority (again, in the context of this thread).

 

So now we can return back on topic, knowing how important (and relevant) is to understand how the platform executes CPU-dominant I/O operations with DMA=off (rendering any argument against such basic concept completely irrelevant), and without mentioning that final output's signal-to-noise ratio does improve a bit when 6502 is left (mostly) in command of the bus.

 

Now, if you will excuse me, I an working hard trying to improve the quality of my recent A-ha and Van Halen conversions, which are pretty challenging... ??

 

 

[Mazzspeed]

DMA on is a real world representation of actual throughput. I don't load software with DMA off and I don't really care for the old, flawed, XEP80 - So if you want to know your throughput in a real world scenario, DMA should be enabled.

 

I posted results with DMA off simply because the user in question wanted to know absolute maximum speeds possible (but in no way practical) from various SD cards, it's that simple. Furthermore, ~65B/sec is nothing to sneer at regarding an ancient 8bit machine, I'm in no rush and the real world difference is negligible.

 

As stated in another thread, it's like two identical cars in a race: One at full kerb weight from factory, one stripped out for a reduction in weight but hardly practical just so they can win some pointless race for bragging rights.

[Faicuai]

2 minutes ago, Mazzspeed said:

DMA on is a real world representation of actual throughput.

For sure.

 

And equally so is the opposite. Otherwise, we would be relegating this whole thread (and the user experience derived from it) as imaginary.

 

There is no argument, no concept, no proposition, no possible rationale that would get us around this simple reality.

 

Now, back to rooting out some puzzling noise on my recent A-ha conversions... ??

[Mazzspeed]

1 minute ago, Faicuai said:

For sure.

 

And equally so is the opposite. Otherwise, we would be relegating this whole thread (and the user experience derived from it) as imaginary.

 

There is no argument, no concept, no proposition, no possible rationale that would get us around this simple reality.

 

Now, back to rooting out some puzzling noise on my recent A-ha conversions... ??

At the end of the day, it's an architectural downside of the A8's DMA implementation. Everything is a compromise.

 

[Faicuai]

1 hour ago, Mazzspeed said:

At the end of the day, it's an architectural downside of the A8's DMA implementation.

It would certainly be so if the system was stuck with a GPU-dominant bus-control profile... but it is not.

 

At the end of the day, it is up to the developer's choice, when/if viable (which is precisely what made this whole thread and PDM player possible, in essence). 

 

And for that, all the credit goes to where it is due: the programmers, and the platform, of course.

 

Can't still believe the sound that can be pulled out of a 1979 Pokey. F-amazing!

 

??

 

 

[Mazzspeed]

28 minutes ago, Faicuai said:

It would certainly be so if the system was stuck with a GPU-dominant bus-control profile... but it is not.

We've been over this, I'm not going over it again. ANTIC is a bus hog, it's that simple. If you run a hardware 80 column adapter, great - However most don't.

 

DMA on is the realistic throughput in terms of storage bandwidth, which in itself is impressive, unless you're trying to achieve bragging rights.

[_The Doctor__]

no more so than the VIC chip in the c64 hogging the bus and being super inflexible about it as well. The C64 1MHz clock is divided into the first 500ns for the VIC and the second 500ns for the CPU thereabouts with the cpu pushing the addresses and the vic chip handling multiplexing those addresses for the most part as well as the need of adding between that the time to release the bus and then accessing the bus again there are a few 100's of ns where the bus is not used at all but we are still dealing with other issues ...as it's actually about 260 ns and lets not forget the VIC chip multiplexes those addresses internally and you can't affect that timing, and you can't pull the chip off the bus either. On top of this VIC chip is refreshing memory 5 times a scan line. So it's not like there is some sort of magical free lunch in this machine either... I can point out more of these issues but it's rather academic. This is only some of what is remember about the working with the machine. It is what it is...

Edited July 21, 2021 by _The Doctor__

[Mazzspeed]

19 minutes ago, _The Doctor__ said:

no more so than the VIC chip in the c64 hogging the bus and being super inflexible about it as well. The C64 1MHz clock is divided into the first 500ns for the VIC and the second 500ns for the CPU thereabouts with the cpu pushing the addresses and the vic chip handling multiplexing those addresses for the most part add as well as adding between that the time to release the bus and the then accessing the bus again there are a few 100's of ns where the bus is not used at all but it's dealing with other issues ...as it's actually about 260 ns and lets not forget the VIC chip multiplexes those addresses internally and you can't affect that timing, and you can't pull it off the bus. On top of this VIC chip is refreshing memory 5 times a scan line. So it's not like there is some sort of magical free lunch in this machine either... I can point out more of these issues but it's rather academic. This is only some of what I remember about the working with the machine. It is what it is...

We've been over it in another thread.

 

The C64 runs an interleaved bus with the VIC-II only taking bus priority when needed by halting the 6510 using the AEC pin, which is a vastly more efficient design than ANTIC hogging the bus whenever screen access is needed of varying degrees depending on screen mode used. The results highlighted running the benchmark used in the other thread showed a performance difference of about 2% with the C64 screen blanked vs the C64 screen enabled vs about 30% difference regarding the A8 in the same scenario's. The VIC-II is bus master in relation to the C64's design.

 

Essentially, clock for clock, the C64 is the vastly more efficient design using the bus of the Apple II combined with the DMA principles of the A8 only when needed. This isn't even taking into consideration the VIC-II's independent color memory.

 

Remember: You were the one that brought the C64 into this discussion.

Edited July 21, 2021 by Mazzspeed

[_The Doctor__]

No you did again, it was in response to your comment. But if you must describe parts of a pinto and then claim you weren't talking about a pinto so be it. Also it seems you need a refresher course on the 64 to some degree as I might as well. I will agree that it is a deficiency on my part to know what thread you are identifying the machine by name or not and weather one thread is a continuation of that discussion or not. I can't keep your conversations straight across the threads but your theme is always about the 64 so I'm confident it really doesn't matter much.

Edited July 21, 2021 by _The Doctor__

[Mazzspeed]

2 minutes ago, _The Doctor__ said:

No you did again, it was in response to your comment. But if you must describe parts of a pinto and then claim you weren't talking about a pinto so be it. Also it seems you need a refresher course on the 64 to some degree as I might as well.

I never mentioned the Commodore 64. If you believe I was somehow implying some context to the C64, that's your problem, not mine.

Edited July 21, 2021 by Mazzspeed

[_The Doctor__]

Okay but you keep going on about everything the Ford Pinto does and then claim your not talking about the pinto... since you didn't say pinto. Whatever you say wink wink nudge nudge.

Edited July 21, 2021 by _The Doctor__