Which to buy: Side3 vs AVG Cart?

[Faicuai]

As an owner of 800 / 800XLs, Ultimate/SD cart, Side 1, Side2, U1MB, Incognito (with true PBI storage), all I can say is that the AVG cart (setting aside SDX / HD combo)  will run on my entire fleet, plug-and-play. And that is SOLID plus.

 

Maybe not a "beautiful" or refined UI, but highly functional, a more inclusive design, and going as far as still workable on the 400/800 (like The!Cart and Ultimate/SD). And that is truly respectable.

 

If it could run SDX while accessing its own storage as HD (which not everybody needs), I would purchase it immediately.

 

Kudos!

[tmp]

42 minutes ago, Faicuai said:

If it could run SDX while accessing its own storage as HD

It can run SDX with access to SD card (via SIDE2 emulation, SIDE.SYS driver) or it can act as a storage device for U1MB (via "PBI BIOS")

 

[Faicuai]

32 minutes ago, tmp said:

It can run SDX with access to SD card (via SIDE2 emulation, SIDE.SYS driver) or it can act as a storage device for U1MB (via "PBI BIOS")

 

So you mean that, with today's AVG firmware, it allows booting SDX from it, and using its SD card as hard-drive for SDX?

 

Do you have a quick video or demo?

 

 

 

[flashjazzcat]

He means it works exactly like SIDE2 when in SIDE2 emulation mode. So you can watch a video about SIDE2 with or without U1MB and that's how it works. You'll have no RTC or NVRAM in stand alone mode, but that's about it.

[Mazzspeed]

7 hours ago, Faicuai said:

Anybody can do that, and to multiple degrees (Relying on external processing HW to get one or many tasks accomplished in lieu of the host system). 

 

The opposite, however, is much harder, as it requires more innate processing and architectural assets. The Atari platform can and will do it, and we truly appreciate it (thus a much higher figure of merit, for both the host HW and the supporting HW and SW developers).

 

There absolutely no such thing as an "aging 6502" when, it fact, it has already aged and gone old for 40+ years, now. It is how far can we go with it what makes us it really appreciate it, even when it already has gone old and obsolete.

 

 

No they can't, not like the way the C64 does it using Ultimax mode and the DMA functionality of the cartridge port, which is using architectural assets built into the machine. You're largely clueless. Furthermore, the 6502 is an ageing design, you've reached it's limit regarding data transfer, I don't think there's much more to gain bit banging the CPU alone using a formatted drive.

 

Both the AVG cart and the 1541 UII+ are still using the CPU for data transfer from the virtual drive via the IEC/SIO port.

 

Now, lets stick to Atari discussion.

Edited May 18, 2021 by Mazzspeed

[Faicuai]

6 hours ago, tmp said:

It can run SDX with access to SD card (via SIDE2 emulation, SIDE.SYS driver)

Is this what you refer to?

 

Or is that a different / new feature, not related to SIDE emulation?

 

[Faicuai]

1 hour ago, Mazzspeed said:

No they can't, not like the way the C64 does it using Ultimax mode and the DMA functionality of the cartridge port, which is using architectural assets built into the machine. You're largely clueless.

Pfft!

 

I recently re-flashed my Ultimate/SD cart. with a custom Veronica co-processor emulation core (65816), just to play with it for a while with Veronica Basic (another one of Avery's "gone-where-no-man-has-gone" undertaking)... all of this while plugged on the left-cart port, while booting directly from internal PBI-hosted SIDE storage... and having the PBI bus interface free for anything else.

 

(And all this on real Atari host, of course, and never really having to constantly bring out-of-context depictions of foreign HW that has nothing to do with what is being discussed here, nor it runs on our machines ).

 

Having said that, AVG cart seems to share some of the architectural concepts that Ultimate/SD is based upon. Sounds like tons of potential still on the table with this cart (which I have overlooked for long...  but not anymore).

 

 

 

 

 

[Mazzspeed]

25 minutes ago, Faicuai said:

Pfft!

 

I recently re-flashed my Ultimate/SD cart. with a custom Veronica co-processor emulation core (65816), just to play with it for a while with Veronica Basic (another one of Avery's "gone-where-no-man-has-gone" undertaking)... all of this while plugged on the left-cart port, while booting directly from internal PBI-hosted SIDE storage... and having the PBI bus interface free for anything else.

 

(And all this on real Atari host, of course, and never really having to constantly bring out-of-context depictions of foreign HW that has nothing to do with what is being discussed here, nor it runs on our machines ).

 

Having said that, AVG cart seems to share some of the architectural concepts that Ultimate/SD is based upon. Sounds like tons of potential still on the table with this cart (which I have overlooked for long...  but not anymore).

 

 

 

 

 

Good for you. I'd highlight just how wrong your reply is in relation to your assumptions regarding that other platform, but as stated earlier, this isn't the place.

Edited May 18, 2021 by Mazzspeed

[Level42]

11 hours ago, CharlieChaplin said:

 

Well,

 

I do not own a SIDE-3 cart, but afaik most (all?) A8 bootdisk programs that use their own (custom) SIO routines (and absolutely rely on SIO) will not work with SIDE-3. You want names? Hmmm, there are only a few programs (that I have heard) that use custom SIO loading, e.g.:

 

- Alternate Reality (The City, The Dungeon; unsure if one or both; CAR versions available, but afaik not fully working yet)

- Seven Cities of Gold (Electronic Arts)

- one or two Lucasfilm games (most likely Koronis Rift or Eidolon or both; luckily available in CAR format)

- a few demos (a bootdisk demo from Copy Service Stuttgart, some polish bootdisk demos)

- maybe the Big Demo by HTT? (original version worked alright with 1050 drives, but not on the XF551; HTT made a patch available and after I used it, the patched version would work on the XF but not on the 1050 anymore; curious if it works on other/3rd party drives, from harddisks, from carts, etc.)

- programs that were (are) coded intentionally (on purpose) not to work with U1MB by XXL, in case you are using SIDE-3 together with U1MB

 

For me it is hard to tell (notice), since I am using real floppy drives, SIO2PC, AVG with SIO cable and SIO2SD and I do not own a U1MB. If the mentioned programs are ultra important for you or not, you have to decide yourself.

 

Thanks for answering that question. None of these games are ones that I play often and I see even some of those are available in different format than ATR.

For any software written to deliberately screw owners of U1MB and SIDE cartridges; how pathetic can a person be ? And I’m not interested in running any software from people like that.

 

I”m going with SIDE3. The AVG used to be a lot cheaper than SIDE3 but not anymore. Including the SIO cable there’s only a 20 euro price difference now so that can’t be a reason for choosing one over the other anymore.

 

I’m used to and really like FJC’s U1MB firmware and interface and find the AVG’s interface too bare bones for me.

 

[Mazzspeed]

1 minute ago, Level42 said:

Thanks for answering that question. None of these games are ones that I play often and I see even some of those are available in different format than ATR.

For any software written to deliberately screw owners of U1MB and SIDE cartridges; how pathetic can a person be ? And I’m not interested in running any software from people like that.

 

I”m going with SIDE3. The AVG used to be a lot cheaper than SIDE3 but not anymore. Including the SIO cable there’s only a 20 euro price difference now so that can’t be a reason for choosing one over the other anymore.

 

I’m used to and really like FJC’s U1MB firmware and interface and find the AVG’s interface too bare bones for me.

 

I haven't found an ATR that won't run off SIDE3 yet, however I believe a select few titles are hard coded to use the default floppy on the SIO port. If such titles are important, as stated, it's not hard to make an SIO2USB lead (or buy one ready made, they're quite affordable) and use RespeQt.

 

Perhaps these select few titles have now been patched? I'm honestly not sure.

[Level42]

5 hours ago, Mazzspeed said:

I haven't found an ATR that won't run off SIDE3 yet, however I believe a select few titles are hard coded to use the default floppy on the SIO port. If such titles are important, as stated, it's not hard to make an SIO2USB lead (or buy one ready made, they're quite affordable) and use RespeQt.

 

Perhaps these select few titles have now been patched? I'm honestly not sure.

Yeah I got a SIO2USB connector from Lotharek and also an SdriveMax so in those extremely few cases I can use those. Just paid for the SIDE3, can’t wait !

[flashjazzcat]

12 hours ago, Mazzspeed said:

No they can't, not like the way the C64 does it using Ultimax mode and the DMA functionality of the cartridge port, which is using architectural assets built into the machine. You're largely clueless. Furthermore, the 6502 is an ageing design, you've reached it's limit regarding data transfer, I don't think there's much more to gain bit banging the CPU alone using a formatted drive.

Interesting. I know little about the C64 architecture but if there are native DMA capabilities which work with on-board RAM, that's pretty cool. An Atari cart can only map to $8000-$BFFF and $D5xx, so can map its own ROM/RAM there and DMA anything it likes to those addresses (which is exactly what SIDE3 does). But a PBI device can quite easily override all the base RAM on the machine and DMA to the entire system memory space (thereby allowing 1.7Mbps data transfers). SALLY at stock speed cannot even copy RAM from one place to another at much more than 64KB/s or so, so obviously if you want to go faster than that, DMA to external RAM is the way to go.

12 hours ago, Mazzspeed said:

Both the AVG cart and the 1541 UII+ are still using the CPU for data transfer from the virtual drive via the IEC/SIO port.

The AVG cart's MCU is presumably responsible for loading cartridge ROM images; if the 6502 were doing this, things would be rather slow. SIDE3 uses the DMA engine to load carts at much the same speed (~1.7MB/s). It's obvious that CPU-bound tasks are a bottleneck regardless of whether or not a message-passing API is implemented with an external MCU. The advantage of the MCU design (UNO, Ultimate, AVG) is that the 6502-side software is greatly simplified, with file system tasks handled by the MCU using (potentially) off-the-shelf libraries like FATFS. None of this necessarily translates into noticeable performance or functionality gains, though (although tmp - once he noticed his search facility was broken on large data sets - fixed it such that performance is beyond the reach of any 6502-bound solution), since the CPU is still funnelling data. But of course it does allow stuff like a complete SIO server running on the cart.

[Mazzspeed]

1 hour ago, flashjazzcat said:

Interesting. I know little about the C64 architecture but if there are native DMA capabilities which work with on-board RAM, that's pretty cool. An Atari cart can only map to $8000-$BFFF and $D5xx, so can map its own ROM/RAM there and DMA anything it likes to those addresses (which is exactly what SIDE3 does). But a PBI device can quite easily override all the base RAM on the machine and DMA to the entire system memory space (thereby allowing 1.7Mbps data transfers). SALLY at stock speed cannot even copy RAM from one place to another at much more than 64KB/s or so, so obviously if you want to go faster than that, DMA to external RAM is the way to go.

That's exactly how it works FJC, essentially it takes (from memory) two cycles to set up the DMA transfer and halt the 6510 using the DMA pin on the cartridge port. Once the DMA controller has bus priority it can transfer data at the theoretical rate of one byte per clock cycle, so the entire memory could be updated at 1MB per second - Stupidly fast for an old nugget of a retro machine and no screen blanking is needed.

 

Then there's Ultimax mode. Using Ultimax mode you can halt the 6510 using the DMA pin, from there the cartridge can take over the C64's kernel ROM area including interrupt handlers and take full bus priority as the full bus is available at the cartridge port. Furthermore, once the cart has bus priority, it gains full access to the C64's I/O device area in memory - So the cart has full control of program execution, memory and I/O!

 

I can also mount two cartridges within a cartridge and maintain control of kernel ROM as well as having dual cycle accurate emulated 1541's (via the IEC connection) with loadable custom ROM's and dual 16MB REU's.

 

What that means is that I can start a demo running, drop into the 1541 UII+'s menu, change some settings and mount another D64 image, press the button on the 1541 again and resume exactly where I left off in the demo like nothing has happened! Effectively, you have a degree of simplistic multitasking and you don't need to reset to access the loader, you just freeze the system, make changes and drop back into your running application exactly where you left off. Furthermore, in my experience the process is faultless, it never crashes either when freezing or resuming.

 

All these features are integral to the design of the C64, left over from Commodore's Ultimax machine and vastly underutilized in the past. No internal modification to the base machine is needed.

 

Here's an example of just how fast DMA loading is, this is a custom cart, but I have shown examples of the process on the 1541 UII+ in the past:

 

 

And 50fps video with audio:

 

 

1 hour ago, flashjazzcat said:

The AVG cart's MCU is presumably responsible for loading cartridge ROM images; if the 6502 were doing this, things would be rather slow. SIDE3 uses the DMA engine to load carts at much the same speed (~1.7MB/s). It's obvious that CPU-bound tasks are a bottleneck regardless of whether or not a message-passing API is implemented with an external MCU. The advantage of the MCU design (UNO, Ultimate, AVG) is that the 6502-side software is greatly simplified, with file system tasks handled by the MCU using (potentially) off-the-shelf libraries like FATFS. None of this necessarily translates into noticeable performance or functionality gains, though (although tmp - once he noticed his search facility was broken on large data sets - fixed it such that performance is beyond the reach of any 6502-bound solution), since the CPU is still funnelling data. But of course it does allow stuff like a complete SIO server running on the cart.

Wouldn't the SIO server running via the SIO port be seen as a virtual floppy drive and bound by the same restrictions RespeQt would encounter?

Edited May 19, 2021 by Mazzspeed

[tmp]

15 hours ago, Faicuai said:

Is this what you refer to?

 

Or is that a different / new feature, not related to SIDE emulation?

 

no, SIDE2 emulation is an old functionality that's been there for years

 

you can run a special cart image (s2sdx3.car), which will emulate SIDE2 including ROM containing SDX, that will boot SDX and will also emulate necessary stuff in CCTL so SIDE.SYS driver included in that car file will able to access SD card as if it was CF card inserted in SIDE2, that's useful for use with stock machine

 

the other option is to enable "light" SIDE2 mode where only CCTL stuff is enabled (via SHIFT-S in AVGCART menu or cart button held on power on or auto side mode where it automatically drops into that mode on power on), this can be used with U1MB where U1MB will detect the SD card as HDD and from there you can use it anywhere where it would work with U1MB+SIDE2 setup

[Faicuai]

1 hour ago, tmp said:

will boot SDX and will also emulate necessary stuff in CCTL so SIDE.SYS driver included in that car file will able to access SD card as if it was CF card inserted in SIDE2, that's useful for use with stock machine

Perfect, exactly what I was considering.

 

Now, when inserting AVG cart and cold-booting on left-cart port, does it maps fully on $8000-$BFFF region? Or, asked differently, if I have a right-cart plugged on $8000-$9FFF, would AVG claim first that address space (thus rendering the right-cart inoperable)?

 

I ask because Ultimate/SD had this problem, and it was later corrected. Today it works perfectly.

[flashjazzcat]

3 hours ago, Mazzspeed said:

That's exactly how it works FJC, essentially it takes (from memory) two cycles to set up the DMA transfer and halt the 6510 using the DMA pin on the cartridge port. Once the DMA controller has bus priority it can transfer data at the theoretical rate of one byte per clock cycle, so the entire memory could be updated at 1MB per second - Stupidly fast for an old nugget of a retro machine and no screen blanking is needed.

Most interesting. One important difference between this and SIDE3's DMA engine is that SIDE3 doesn't halt the CPU. It uses the first part of the bus cycle to complete a read/write operation. The CPU and the DMA engine have coinstantaneous access to the same memory (albeit not the computer's on-board memory; this distinction will not matter with a PBI implementation which can supplant all the RAM on the host machine).

 

The first iteration of the PDM player I recently added to the SIDE3 loader exploited this by DMAing data into a FIFO buffer while the CPU simultaneously fed it to POKEY. As it happened, though, DMA was total overkill for that application so I reverted to the CPU doing everything using just a 256 byte buffer and interleaved PDM data. DMA will surely be useful for video playback, though.

 

Thanks for the synopsis of this and Ultimax mode, though, and the video links. Most impressive. I guess it's not surprising that a design a little younger than the A8 boasts such nice facilities.

3 hours ago, Mazzspeed said:

Wouldn't the SIO server running via the SIO port be seen as a virtual floppy drive and bound by the same restrictions RespeQt would encounter?

Yeah - totally. I mean only that it's possible to do just what you describe.

Edited May 19, 2021 by flashjazzcat

[Faicuai]

23 minutes ago, flashjazzcat said:

Thanks for the synopsis of this and Ultimax mode, though, and the video links. Most impressive.

FYI, on the video comments, the author states that external CPU / processor is used. Even comments questioning the definition of what a real "C64"... ?

 

In any case, the use of external processor makes total sense because [REU + glue controller] are just a "conduit" or buffer. Something else is needed to come up with those frames, from larger storage, and load / encode them on REU in a way that [after DMA transaction] local GFX chip can decode, without mentioning audio-decoding, and all within very specific timing constraints.

 

We can look at what The!Cart does with video playback, and just from the L-cart port.

 

Nice to know that AVG-Cart allows grouping video-files encoded for Avery player... That's really nice!

[flashjazzcat]

Well, it all looks pretty. I gather the majority of users don't give much of a shit how something is accomplished, as long as it works.

[Faicuai]

35 minutes ago, flashjazzcat said:

majority of users don't give much of a shit how something is accomplished, as long as it works.

 

Yeah, productivity is hardly questioned. That is the obvious part.

 

However, that does not change (a single bit) of what is (truly) happening. Some folks out there don't mind living in Alice-in-Wonderland, while others do question it. Plain and simple.

 

This won't change either, no matter how many FPGAs, auxiliary processors and supporting electronics we chose to stuff or plug into our 40+ years old HW.

 

 

[tmp]

4 hours ago, Faicuai said:

Now, when inserting AVG cart and cold-booting on left-cart port, does it maps fully on $8000-$BFFF region? Or, asked differently, if I have a right-cart plugged on $8000-$9FFF, would AVG claim first that address space (thus rendering the right-cart inoperable)?

 

I ask because Ultimate/SD had this problem, and it was later corrected. Today it works perfectly.

i vaguely remember reading something about, some oddity with s4(?) signal on 800 or something like that, frankly i have no idea since i don't own 800 and nobody complained so either it does work or (more likely) nobody cared (to report)

in the latter case it should be easy to fix should someone report the issue and could test the potential fix

 

[Faicuai]

1 hour ago, tmp said:

it should be easy to fix should someone report the issue and could test the potential fix

NICE !!

 

Exactly what I expected to hear. Placing order now.

[Mazzspeed]

6 hours ago, Faicuai said:

FYI, on the video comments, the author states that external CPU / processor is used. Even comments questioning the definition of what a real "C64"...

We've been over this. The DMA controller in the official Commodore REU is effectively an external processor, ANTIC is effectively an external processor, the 1541 runs a 6502, the SFD1001 runs two 6502's. If you're trying to imply that the C64 is somehow 'accelerated', this is not the case.

 

Rather than use FPGA, the board is made using an ARM processor as a DMA controller, one ARM core is solely dedicated to bus synchronization with the GPIO headers barely having the bandwidth to perform the task, thus allowing the ARM processor to handle such duties. In the future the designer of the board would like to add Super CPU support, but hasn't as yet.

 

Another benefit of DMA is coding. The coder can create programs using a cross compiling assembler on PC or by utilizing one of the dedicated packages available under the PC platform for the C64, they can test the program on the PC using VICE. Assuming the software runs well under VICE, if the programmer wants to try the software on a real C64 they just dump the program from their PC, over the network, directly into the C64's memory using CodeNet and they can test the software on a real C64 with no external media involved whatsoever. All of this is supported by the 1541 UII+.

 

TLDR; In all of those video's above, the ARM processor is simply handling DMA control no different to an official Commodore REU. Your implication that the Commodore is somehow accelerated is untrue.

Edited May 19, 2021 by Mazzspeed

[Mazzspeed]

3 hours ago, Faicuai said:

 

Yeah, productivity is hardly questioned. That is the obvious part.

 

However, that does not change (a single bit) of what is (truly) happening. Some folks out there don't mind living in Alice-in-Wonderland, while others do question it. Plain and simple.

 

This won't change either, no matter how many FPGAs, auxiliary processors and supporting electronics we chose to stuff or plug into our 40+ years old HW.

 

 

 

Once again, you've got it all wrong based on assumptions - What you need to do is polish up on your comprehension skills, as you seem to struggle with reading posts. I outlined the operation perfectly in my post to FJC and it's all part of the C64's design. The device is not accelerated, there is simply a DMA controller taking bus priority.

 

Edited May 19, 2021 by Mazzspeed

[Faicuai]

18 minutes ago, Mazzspeed said:

Rather than use FPGA, the board is made using an ARM processor as a DMA controller, one ARM core is solely dedicated to bus synchronization

?? Have fun!

 

And don't worry about my reading comprehension, as I am placing an order for one AVG cart... on a thread that talks about the AVG cart, as well.... 

 

??

[Mazzspeed]

4 minutes ago, Faicuai said:

?? Have fun!

 

And don't worry about my reading comprehension, as I am placing an order for one AVG cart... on a thread that talks about the AVG cart, as well.... 

 

??

Oh my God.

 

You're still struggling with comprehension. I rest my case. I guess ANTIC is cheating as it's not bit bashing the CPU!

 

I was replying to FJC in relation to C64 discussion, I'm not interested in discussing such things with someone as shamelessly ignorant as yourself. One person I respect, the other I definitely do not.

Edited May 19, 2021 by Mazzspeed