SIDE 3 preorder

[Mr Robot]

1 minute ago, ZuluGula said:

So it's all Johns fault

#HotTake

[candle]

sure, whatever

 

[+Stephen]

3 hours ago, ZuluGula said:

So it's all Johns fault

Shit dude - had an awful week at work, and you still made me chuckle.  I owe you a beer.

[leech]

5 hours ago, flashjazzcat said:

The SIDE3 was intended to fit the 1200XL using the shell in which it currently ships. The reason it doesn't is because shit happens.

 

Shit does indeed happen, even to the best of us!  Ha, sounds like we need a SIDE3: Thin edition, because the 1200xl doesn't like the fatties.

[leech]

5 hours ago, MrFish said:

 

The current Atariage serial number list stands at 472 unique 1200XL's. The 1200XL is an extremely popular model among enthusiasts. Giving that many enthusiasts are not involved with the forums here, I'd venture to guess there are at least twice that number of machines which haven't had their serial number submitted here. The other thing is, Bob1200XL has only submitted 7 serials numbers himself, and we all know he has several hundred stashed away at his place. 

 

Note: My statement about the number of 1200XL's is not meant to side (pun) with anyone here regarding the cartridge size discussions. Personally, I think it's perfectly understandable that some cartridges will not end up fitting in 1200XL's or 400's / 800's. I think most hardware developers do their best to accommodate as many machines as possible (as it's it their best interest to do so); but various factors may ultimately dictate that those tougher cases (pun) don't make the cut.

 

This number tracks (double 472 unique serials) as I own 2 1200xls, but haven't put my second one on there yet.  ?  Still my favorite model overall of the 8bit line.

[KPeter]

Jon, Is there something new about SIDE3 update? On your webpage the red notification is still there.

DLT guys did not answered on any my e-mails, inquiries. So, probably no progress on SDX449e,

 

Peter

[flashjazzcat]

I will link any updates here as usual. The next SIDE3 loader update is ambitious and should be well worth the wait, but requires a lot of work. Asking for updates won't make it happen any faster.

 

I guess the same is true of SDX.

[tsom]

Just got my SIDE3 cart. Any hints or tips to get the SD card ready? I’ve got a 64gb card loaded, I think it’s formatted exFat (which may be the problem?) and nothing I copied to it shows up. I keep seeing references to “copy to the FAT partition...”. Should I partition the SD card somehow?

 

I also want to make sure it’s up to date. It’s showing version: 0.19

 

thanks!

[mimo]

Google flashjazzcat's YouTube guide on how to set up your card for side2

[flashjazzcat]

39 minutes ago, tsom said:

I think it’s formatted exFat (which may be the problem?)

It is the problem. Format it FAT32.

40 minutes ago, tsom said:

I also want to make sure it’s up to date. It’s showing version: 0.19

You're up to date.

[cornchip]

34 minutes ago, flashjazzcat said:

It is the problem. Format it FAT32.

You're up to date.

 Is there an official SD card formatting utility for the Side3 that is complete with directories/partitions and necessary files?

[flashjazzcat]

2 minutes ago, cornchip said:

Is there an official SD card formatting utility for the Side3 that is complete with directories/partitions and necessary files?

Windows' Disk Management Console or right-click, select 'Format'. Linux and macOS have similar facilities.

 

[tsom]

1 hour ago, flashjazzcat said:

It is the problem. Format it FAT32.

You're up to date.

Thanks. I did reformat it as FAT (this on macOS - I had ExFAT and FAT as options) and that made files show up. To see cartridges or ROMS they need to be .ROM or .CAR. I've lots of files that are .BIN - assuming I can rename to .ROM?

[ivop]

On 11/18/2020 at 11:05 PM, Mr Robot said:

if a flashcart is being used with a 400/800, it's pretty tricky to use the buttons on said cart. 

Yeah, we need remote controls! IR is not going to work though, with the lid closed

Edited November 21, 2020 by ivop

[ivop]

On 11/18/2020 at 11:42 PM, candle said:

i do not see any point in using micro-sd card if device is big enough

durability of this connector type is already limited due the size of features it uses, and i need to keep in mind that this sd card will be removed and reinserted countless times during its use

And this. Micro-SD adapters are easy to get by. You put them in your device once, and then (re)insert your micro-SD until the adapter is worn out and then you use a new one

[Mr Robot]

31 minutes ago, tsom said:

assuming I can rename to .ROM?

Yes you can, but it would be best to convert to CAR. A CAR file is a BIN file with a 16 byte header that tells the multicart (and emulators) what type of cartridge the BIN is from.

 

Edited November 21, 2020 by Mr Robot
I'm an eejit

[flashjazzcat]

32 minutes ago, tsom said:

I've lots of files that are .BIN - assuming I can rename to .ROM?

Sure! But I'll add BIN as a recognized type if you want, then you won't have to rename them. I'll add this to the next update, but - as Mr Robot points out - CAR files are much more convenient since the loader won't have to keep asking you what the cart type is (which happens with ROM, BIN, or anything else which lacks metadata at the top of the file).

 

 

[Mr Robot]

Ultimate Cart tries to guess, it doesn't do a bad job for most carts.

[flashjazzcat]

1 hour ago, Mr Robot said:

Ultimate Cart tries to guess, it doesn't do a bad job for most carts.

The SIDE3 loader tries to guess as well, but it currently does so purely on the basis of the first matching ROM size in the emulation table. If the assumption is correct, you can hit RETURN to confirm and the cartridge will mount. If it is not, you can choose the correct type from the list. To do anything more sophisticated requires analysis of the file contents; for example, scanning for potential references to certain locations in CCTL. The Ultimate Cart - like any other cartridge which has an MCU capable of running a complete implementation of Elm Chan's fatfs library or similar - is capable of parallel processing, and thus can very quickly perform the necessary analysis of the file content. The Ultimate Cart's menu simply sends the name of the ROM file the user selected and that is the end of the matter as far as the Atari is concerned.

 

SIDE3's loader - once the user has hit RETURN on a ROM file - has to use the 6502 to trawl the emulation list and create a sub-list of potentially matching cartridge types based on the file size. Once the user picks the cartridge type, data is then loaded into the cart's SRAM using DMA. When the loader is capable of performing analysis of the actual file content, it will have to do so using the power of the 6502 alone, and this will introduce a small but noticeable delay between pressing RETURN and the cartridge actually being mounted (or - if the type cannot be identified - a list of potential matches being presented). Certainly we can load - say - the first 8K of data and look for any signature bytes, but simply inspecting 8K of data against a table of signature addresses will take a measurable amount of time.

 

So: while it is certain that the SIDE3 loader will eventually be able to better guess the banking scheme of an anonymous ROM, one should be careful not to make assumptions when comparing two devices which take a wholly different approach to accomplishing the same task. With devices like SIDE2, SIDE3, etc, the 6502 performs the lion's share of the legwork, including IO, file system management, etc. Ultimate, UNO and AVG take a completely different approach, where the boot menu and the MCU firmware exchange messages. To read a FAT directory, the loader says 'give me this directory', and the MCU simply presents a buffer of filenames. To mount a cartridge, the loader tells the MCU 'mount this ROM file as a cartridge, using your best guess as to the banking scheme', and a second later the cartridge is loaded. The loader running on the Atari is completely abstracted from low-level IO, file systems, and cartridge RAM management. I was involved in both the Ultimate Cart and the UNO cart, and the source code for the loaders is very modest indeed.

 

My personal penchant is for the SIDE2/3 way of doing things, since I find it more fun to interface directly with file systems and low-level IO (IDE, SD cards, etc) using 6502 assembly language. But this approach requires a lot more work on the Atari side to create a full-featured and responsive user experience. The assembly language source code for the SIDE3 loader is currently ~18,000 lines long, and set to increase as FAT writes are implemented.

 

Of course the user need not care one way or another how things are done as long as the usability is good. Inexpensive MCU-based devices like the UNO Cart (as amply demonstrated by Wrathchild) are incredibly powerful and can perform all kinds of impressive parallel-processing jobs many times faster than the Atari itself. AVG has recently put its parallel processing capabilities to work by providing a variation on the PCLink protocol, allowing a fairly simple SDX driver to implement R/W access to a FAT-formatted SD card. If I were more biased towards C and ARM development, I might prefer those solutions, but since I am endlessly fascinated by what the 6502 can accomplish near the bare metal (driving SPI devices, etc), Candle's approach to things continues to offer the most interesting challenges.

Edited November 21, 2020 by flashjazzcat

[ivop]

34 minutes ago, flashjazzcat said:

...

TL;DR version:

 

1. Ultimate Cart and Uno Cart have a modern Micro Controller on board that does most of the work. Mostly programmed in C and/or ARM assembly.

 

2. SIDE2 and 3 have a direct connection to the storage media and do most things natively on the Atari. Mostly programmed in 6502 assembly. (ignoring the FPGA part )

 

FJC and Candle like 2 because it is more challenging and closer to the Atari DIY tinkering spirit.

 

Edited November 21, 2020 by ivop

[Mr Robot]

I honestly thought the Uno/Ultimate just did what what SIDE3 is doing, just picking the most common cart type for that size of ROM!

 

[tsom]

6 hours ago, Mr Robot said:

Yes you can, but it would be best to convert to CAR. A CAR file is a BIN file with a 16 byte header that tells the multicart (and emulators) what type of cartridge the BIN is from.

 

And of course, the obvious follow up-how does one do that?

 

  I did have to try different cart types to get some to work. I also have a .car file (synassembler.car) that doesn’t quite work-just shows a blank green screen.

 

thanks!

[+MrFish]

47 minutes ago, tsom said:

I did have to try different cart types to get some to work. I also have a .car file (synassembler.car) that doesn’t quite work-just shows a blank green screen.

 

That SynAssembler cart file is most likely the 400/800 version, which requires OS-B in order to run. There is an XL/XE version too.

 

[flashjazzcat]

9 hours ago, Mr Robot said:

I honestly thought the Uno/Ultimate just did what what SIDE3 is doing, just picking the most common cart type for that size of ROM!

I don't know about Ultimate, but UNO just assumes the XEGS type of the corresponding size. I can't see this being much use when the ROM in question is not an XEGS cart, but you implied that it is pretty successful. Perhaps most of your ROM files are XEGS carts.

Edited November 22, 2020 by flashjazzcat

[flashjazzcat]

7 hours ago, tsom said:

And of course, the obvious follow up-how does one do that?

Altirra can convert them (or at least save the mounted ROM as a CAR file), but some human intervention may be required since Altirra also has to guess as to the banking scheme based on size and heuristic analysis.

8 hours ago, tsom said:

I did have to try different cart types to get some to work. I also have a .car file (synassembler.car) that doesn’t quite work-just shows a blank green screen.

Do you want to send me a ZIP of your ROM/BIN files and the Synassembler CAR file? The assembler - IIRC - is just a basic 8K ROM with no banking at all, so should not present any issues.