Wrathchild

STAC

If you are only targeting XL/XE architecture and utilising the memory under the OS then you can handle the reset via the $FFFC vector. So you'd need to swap to a SOFT/OS or maybe providing your own minimal OS.

Perhaps utilise CASINI (2) and set bit 1 of BOOT (9)

Feel free to PM me. For reset handling on AtariMax, one of the best ways is to have the cart setting and INI/RUN vectors in every bank, that transfers control back to the main bank. I appreciate that can break continuing of data crossing banks but is managable.

Also the SST29SF040 should work, I believe you can get away with their 020 or 010 too. I have a handful of SST29F010 but you can seem to get them for love nor money these days... great thing about them was the sector size is 128 bytes so you can effectively remap DOS operations onto it

Wouldn't dismiss the compression, I know @popmilo has had good gains with his recent work and could give some advice.

128KB cart (AM29F010) has 8x16K sectors and the 1024KB cart (AM29F040x2) has 8x64K sectors on each chip.

The AtariMax workbook software can autolaunch an entry in the list

Thanks, have just seen that in the code. Yes, hence the iterative human interaction. An additional example of that would be the marking of immediate values as being of a given type, i.e. not just 'value' of LDA #$A8 or LDA #168 (another possible command line option to output as decimal instead of default hex?). This permits linking the value to a label such that code can then be output as: LDX #>MY_VBI, LDY #<MY_VBI (or LDX #MY_VBI / 256, LDY #MY_VBI & 255)

Disassembling is an iterative process... I'd recommend the following: Store the target specific labels sets in a way (e.g. an indexed array) that permits the user to choose the target. By all means set A8 as the default but probably 'none' would be fine as a target too and maybe use the exomizer '-t' values for different targets, e.g. A8 = 168 Certain H/W registers on the A8 are dual purpose and have different labels so maybe facilitate that as you know if the instruction is a read or write. Provide the user the ability to import their own labels. These override any target specific labels. However this is more complex that initially looks as you need to support more than just a single byte type. If you look at existing disassemblers then these will allow memory bytes, words (hi/lo, lo/hi), byte arrays, word arrays, arrays of lo-bytes & high-bytes etc. So effectively the user should be able to take the output from the first disassembly and review/revise the labels in order to then re-run the disassembler feeding in the new information to get new output to review (rinse and repeat).

Compiles fine under Cygwin

[misread]

The majority of titles falling into that category I would think have already been converted

if not requiring disk swapping or save capability then you could try placing the image in an AtariMax Workbook image and and create a cartridge image from that which you then load on the ultimate cart

Would depend on how the emulation handles things like cart-headers and context switching between 5200 & A400/800/XL/XE. i.e. is it up to the user to know which platform to select or will it automatically change. For example, if you were running in 5200 mode and then wanted to launch an ATR/XEX would the emu auto-switch to the last used non-5200 profile, and conversely if you picked a 5200 cart image would it switch to 5200 mode with/without asking the user?

didn't the disk versions have graphics though?

Don't think that works on a 48K system [Edit] Oh, ok, have read it emulates XL too

The Seven Cities of Gold seems an odd one as had disk-flipping, building new maps to a map disk and so would be interesting how they'd streamline that for the user?

Oh yes, love that it had no instructions! 😆 It probably took a couple of months overall seeing as you needed to work out who needs what and find a route where you don't run out of time, well designed game. Shame we didn't get part 2.

Pretty sure when I first beat this there was a bug that meant this wasn't shown... could have been the tape version... I not going to check 🤣

There was a 10502PC cable but later SIO2PC AtariMax interfaces contained both features (including Prosystem). So you can hook up a 1050 drive to a PC (via serial or USB cable) and read and write ATR/PRO images.

Its sat waiting for the cart to be unplugged (assuming an XL system monitoring TRIG3). All it does is copy the cartridge content to lower memory and then transfers control, continuing once pulled. So instead here's an XEX that does the same. universal-ram-copy.xex

Is this the same discussion as in the A8PicoCart thread? Conclusion was basically that its mostly a 'nostalgia' thing and not really necessary as the cart seems to just copy a loader into RAM then disables the cart. So the XEX in the post effectively does the same thing as the cart lines remain unused?

It uses an 8Mbit/1MByte cartridge but runs on 64K machines.