NuY

Got my membership pack from Abbuc today, and that is a tasty membership number. Anyone got other significant numbers? Off the top of my head, 11, 12, 65, 80, 130, 410, 810, 800, 400, 551 are the obvious ones.

I typed all of these myself, verified with GIR where available, and typed the docs from the mags. Had a couple of the tapes when I was a kid, but no disks. Edit: there were disks available, but I wanted to make my own compilations - it's possible (without looking) that these compilations might contain some of the disk bonus programs.

Glad you like the menu, took me a while to get it how I like it all those years ago! IIRC, pressing Control + letter gives you the docs from the mag.

This kind of goes back to what I said about Green Beret though - as it was a port (presumably from the C64 version) it mostly inherited the inherent qualities that the source version had, which in this case was excellent gameplay in the first place. I don't perceive much difference in the controls of HoH between the two versions at all, and of course the C64 graphics were taken straight from the Spectrum original anyway. It's hard to see how it could have been improved significantly given the time frame. Looking at its isometric peers of the time the only one that springs to mind is Chimera, which looks nice but is incredibly chunky and lacks details in the building blocks, where HoH has the pixel count of a GR.8 screen at the cost of being monochrome.

First 10 were great, just orderd 11-14+tshirt! One question though - shipping to the UK is a bit steep for some of the items. I was interested in the Basic ten-liners book at €7.50, but shipping for this alone was €10 as its 0.5kg. Are there any other carrier options available?

I wouldn't necessarily have had a problem with Green Beret's graphics when I bought it for £2.99 back in the day, if the controls and gameplay had been tighter as Mr Mclaneinc says. The C64 version has better graphics sure, but it also has a fluid jumping action (compared to diagonal up and diagonal down with no arc on A8). The speed at which enemies appear and move on both versions is too severe, but exacerbated on A8 by the fact that when you jump you're locked in and the collision detection for the knife attack is shonky. Surprisingly, I find the Spectrum version has the "best" gameplay feel for me. Noone loves monochrome graphics, but the speed of enemies and your character ("responsiveness") are spot on. C64 version nails the presentation but gameplay fails for being far too punishing. Is there scope for improving the A8 version? Not talking about graphics, even if they were the same as they are now, it would be great to play it with a bit more care in the jumping, enemy spawning and collision detection.

Slightly delayed response... Thanks muchly for having a look at this, I finally have some time to get back to Atari stuff next week, been a busy couple of months. Should be able to report back Monday or Tuesday I reckon

Looking for some opinions chaps. I'm in the market for a new Flashback and fancied gathering some opinions on which model I should go for. Desires: 1. Paddles 2. Wireless joysticks 3. SD card slot 4. Easy "hackability" So of course wireless joysticks limits my choice to 8G or 9G, and paddles limits to 8GD. 8GD is available in UK at a fairly reasonable price, 9G, well, isn't, but is importable from Amazon without too much fuss. Paddles aren't a deal breaker but they would be nice to have. SD card versus "hackability" - well, SD card is obviously much easier (I already have a Legends 2018 and Megadrive 2018), but I don't know how involved the modding of an 8 is. Things I'm not sure of: are the wireless joysticks from 8 & 9 pairable with any other device at all? Are they bluetooth for example? How is the emulation on 8 compared to 9? Paddles - same question as above for the Blast ones, can they be paired with anything but the dongle? Finally, X is out of the equation - the thing looks great but wired joysticks for me is a deal breaker. Ta

Fractional MB: Yes, I agree certainly for the initialisation screen - the rarity of removeable storage with capacity under 1GB must be vanishingly rare these days; integer MB displays would certainly sufficient for me. Until such time SDFS can handle > 32MB, fractional display is probably better in that context. Resizing partitions: Thanks, I'll give that a try then Name: I was bored of typing out "SDX cartridge image with SIDE support" to refer to the image The fact SIDELoader has no capability of writing to disk completely escaped me to be honest I agree all functionality should be available across all platforms that are supported by SIDELoader notwithstanding U1MB or lack thereof. From my perspective, the IDE emulation is more important than the loader, but the loader is an extension of AVG, if you like. There will be times when XEXs don't work in AVG and vice versa, so having the best of both worlds is a definite advantage. There's the audio streamer as well, of course (which name escapes for the minute..) From a wider perspective, I guess it also means tmp doesn't have to reinvent the wheel for support for a certain feature, if it is already present in SIDE or its loader. FDISK: Ultimately I guess you will want to squash the bug we discussed, but as a temporary measure, how about disabling the sanity checking during parsing of the size fields, and checking the total of both fields doesn't exceed the device capacity at the point of pressing Return? Not sure if the maths for this would still be the same as you're using currently In addition, a minor suggestion: If one selects FAT16 as the type, there shouldn't be any need to have this larger than 4095MB in the sizing options, as FAT16 can't be any higher than 4GB anyway. If you need any FDISK testing, let me know - I'll probably be fiddling with this SD card for a couple of weeks yet anyway

Channeling your inner Bill G eh! It's interesting that it only happens for a certain total range. I fiddled with the numbers in both fields again, and in short, entering numbers above 8192 in both works fine. As a potential workaround, if I create both partitions at 8192mb and then resize the FAT partition using Windows to 4095mb, would the APT partition still be visible, in theory? I recall reading in one of your posts or possibly in the userguide that messing with partitions after the APT one could destroy data, but I don't know if FAT and APT have to be contiguous. While I have the user guide open, could you clarify something on the FAT access side of things? On page 16 referring to ATRMOUNT, the guide states that this command is designed for U1MB, and goes on to say that IDEPlus users should use their proprietary tools to mount ATRs. My question is if ATRMOUNT would work under SDXSIDE (good name eh) if an ATR was copied to an SDFS partition? Lastly and unrelated, going back several posts ago when we were discussing the OSS carts embeded in the SDX image, you mentioned the inability to save config for SIDEloader due to their being no NVRAM to save it to. As a suggestion/feature request, would it be possible for SIDELoader/SIDEcfg to save its configuration to a file directly on the SD card? The theory being that the program would try to read NVRAM first (succeeding on a real SIDE cart, failing on an AVG cart), and as a fallback, look for a file on the FAT partition of the card, say in the root?

Aye, using diskpart on Windows reports it as being 59gb, but that's rounding off of course, not to mention that these days 1gb is 1000mb rather than 1024mb (don't get me started :)) The set up is what I'm having some issues with. I'm running Windows 7 so I've been through a painful day or so trying to find ways of using more than one partition useable by Windows, and failed. Until such time I upgrade to W10 I decided on having the card set up with a 4gb (4095mb) FAT16 partition and the same for APT for OCD reasons (!). The current issues I'm having revolve around AVG not refreshing the card slot after boot, meaning I have to manipulate the card in Windows to have a FAT partition on to which I can slap the SDX car file on, so that I can boot to SDX and repartition on the Atari. This necessitates creating a FAT partition through FDISK of course. The current issue is that when using FDISK from the SDX car file, there's some strange behaviour when entering digits in the size fields. Even with auto-fill deselected the behaviour persists. Steps to replicate: - Open FDISK, select initialise from menu, confirm warnings about MBR being destroyed, this brings us to the partition screen - Tab to auto fill box and deselect with space - Tab to FAT size field, type in any number above 3560, press tab again - FAT size field reverts back to the full size of the card (in this case 60904) - Type any number above 3560 in APT field and press tab, APT field reverts back to full size of card Interestingly, if I enter 8192 in both fields or numbers above this (I haven't tried all numbers ;)) the fields both stay as they should be. Naturally to work around this I can use numbers below 2000 or so (certain other combinations of numbers in the two fields seem to behave similarly to the above description). The preference would be to have the FAT16 partition as large as possible however, as I tend to use the old card as a scratch disk for non-Atari related stuff. Edit: FDISK version is 4.67

So just some quick updates on my latest shenanigans (hopefully tmp and FJC will like some of these tinkerings): 1. I bought a 64gb SDXC card because it was cheap, and am pleased to report it works fine in AVGCart (with caveats, noted below) 2. You probably already knew this FJC, but FDISK that is on the SDXSIDE car image recognises said card and its capacity correctly (something like 60992MB) 3. After updating the AVGCart with a test firmware from tmp, running CAR from SDXSIDE car image works correctly, and launches SIDE loader Re the 64gb card, it's a Sandisk UHS-I Class 10 SDXC card (full size, not micro). Had some interesting behaviour from AVG on first using it. I didn't bother with any initialisation on the card before it went in AVG, so on booting, I got the usual grey AVG screen with "reading directory" message, which hung the machine, and pressing Reset just brought up the same thing again. I then powered off the Atari and slotted in my existing working SD card, powered up, and just got a black screen. Power cycle and same result. 64gb card in AVG, same result. I was quite concerned I'd blown something up, so disconnected AVG and booted up Atari fine. AVGCart back in and power up with old SD card in, and black screen again; but on pressing Reset the SD directory comes up. Power cycled again, and behaviour repeated - Boot to black screen, press Reset and directory appears. I can't explain that one Moving on, after (eventually) finding a utility to format FAT32 under Windows > 32gb, I copied the contents of my old SD card to the new 64gb one, slotted it in AVG and Atari booted first time into the cart menu. A few test car files and fiddling with SDX seem to work okay. Got some current logistical challenges on prepping the SD card for use with SDXSIDE as AVG doesn't (yet) have two SD card sockets...

The only one I can find similar to this is: ba Break on memory access From this link: http://seriouscomputerist.atariverse.com/media/rtf/Altirra - Debugger Commands.rtf

Aha, brilliant! I suppose this takes us back to my original question 4 then, around getting to the SIDE loader from SDX prompt (by typing CAR). I'll await the results of tmp's testing on that one. I've never done anything with regard to manipulating cartridge images - do you have any recommendations on software to use to move the blocks of data around in the image file? (Windows or A8)

Heh, I was just in the middle of typing a reply to the effect of "How does AVG remember which OSS cart selected when booting from two different CAR files"! Your reply makes perfect sense in the context of a real SIDE cart of course. I had wondered if somehow a writeback to the CAR file was occurring behind the scenes when running the SIDE config utility. In that case then, as AVG (afaik) has no concept of passthrough carts (currently ;)) would the following idea work? Take your existing "SDX with SIDE support" car file and bake in one OSS language? Or indeed, any language cart (MS Basic, TBXL...?), such that the end result would be the ability to boot from say "SDX with SIDE support and M65 built in" and get to M65 by typing CAR. I'm not averse to having several SDX car files, each with a different language on - maybe there could be an ability to "roll-your-own" SDX SIDE language car file? Just thinking off the top of my head here. On a completely unrelated note, is there possibility of including the SDX MAN pages on the car files for future releases? I appreciate having the online help files when I'm fiddling with commands I have no clue how to use Thanks again, and I hope I'm providing you with more esoteric ideas Absolutely no rush on my side, appreciate the support you've always given.