Wrathchild

Confusion comes from me using the phrase 'two tone' I guess, a better way to think of it would be 'tone' , 'no tone'. You are thinking in terms of the SIO code, i.e. the cassette is sending a 128K block a byte at a time serially... so is still a binary transfer. If you ignore this and just say "start cassette motor" and monitor the bit that identifies a 'mark' then you can have your own Manchester decoder routine detect the changes, i.e. sync the clock and then check for the high/low or low/high transitions and make bytes out of them. Obviously a loader is more simpler that a saver, and I don't think that a saving routine on the A8 itself would be optimal - e.g. due to the overheads of preparing the data - the resulting clock rate would be larger. So it maybe better to have a faster machine produce the file (e.g. as a wav) and then record it to tape. Regards, Mark

Way back I studied the loader used on the C64 tape version of Impossible Mission. IIRC this uses a two tone form of (what I think is called) 'Manchester' encoding. As the atari drives permit you to do this (e.g. the 'marks' placed on the data tracks against audio that the code detects to move onto the next screen) then I thought something similar would be possible, but I never attempted to writing a 'save' routine in order to be able to test a loader. Might be worth digging up that stuff. Also, and mentioned above, someone had told me that the tape unit would perform some kind of operation on the 'sound' when reading and so this could render any attempts as such an encoding method useless.

Also, I believe the Atari++ PC-cable-drive support is only available under Linux and not Windows. The new 1.44 release is out and is worth getting: http://www.math.tu-berlin.de/~thor/atari++/ Mark FYI: I've also submitted a patch to support 8Mb (1MB) FlashCarts rather than just the 1Mb (128KB) ones. If anyone wants the compiled exe (VC6) then let me know.

You can manage that, simply poke the required values into the routine during the VBI, then the DLI doesn't have to do so much work. Regards, Mark

I do recall having played "Galactic Chase" from cassette which loaded fairly quickly on a stock 1010. It just seemed that the bit rate had been ramped up and because the O/S compensates for the baud/bit rate, it loaded OK.

Hi, Some 27c128 eeproms arrived from the US and so, with luck, this Wednesday I'll be blowing one with the MyIDE 4 ROM and having it put inside an XL. I've used the older disk based replacement (software) rom - and so I'm looking to see if this allows me to run 64K titles from HD and handles multi-part loaders on disk images to load properly. Piccies of my XL can be found on: http://www.atariage.com/forums/index.php?s...pic=46316&st=25 Regards, Mark

Which demos have good examples of visualizing pokey output? I like the simple WinAmp sdtyle vertical (coloured) bars with the high points holding up for a while before dropping down again. Thanks, Mark

Why the giving JBJ a hard time? The site has been up for a while and mentioned before in the AA forums? http://www.jetbootjack.com/JBJ_oldgamesindex.html Regards, Mark P.S. Never had any fame - though in another life may have written a better version 'Kick Off' for the A8.

Try this for slightly better generated code, the use of statics removes the overhead of using the CC65's stack to hold the variables and hence call functions to maintain them. #define poke(addr,val) (*(unsigned char*) (addr) = (val)) #define pokew(addr,val) (*(unsigned*) (addr) = (val)) #define peek(addr) (*(unsigned char*) (addr)) #define peekw(addr) (*(unsigned*) (addr)) int main (void) { static unsigned char n = 0; static unsigned char *x; x = (unsigned char *)peekw(0x58); n=0; do { x[n] = n; } while (n != 0); while(peek(0xD01F)!=6) { // Wait START } n=0; do { *(x+n) = 0; } while (n != 0); while(peek(0xD01F)!=6) { // Wait START } } Note too the difference in the loops in the of accessing memory. This mirrors what your asm application was doing - your 'C' file was using a larger range of addresses you wanted to fill/clear and so the comparison wasn't really a fair one. Regards, Mark

Looks like the two 27c128 chips were knackered. I'll have to find some more.

From what I've seen in the original C64 code, the data is already 4 bit volume only that decompresses as it goes into a smaller working buffer. I think the data itself was only around the 16KB size and the playback code between 1&2K.

Certainly the Mega and Flash cart boards are a lot tidier. I'll try and find some links to photos of the insides. A summary of the swapping models I gave can be found here: http://www.atariage.com/forums/index.php?showtopic=69425

I disagree, I think the AtariAge board houses the most capable bunch of developers on the A8 platforms (other than the Polish/Czech language boards - who also contribute here regularly). Where else would you look? comp.sys.atari.8bit and atari.org aren't contributed to much by programmers. From my perspective the A8 developers just appear to be busy with their own lives at the moment and hence little development is getting done. Most of us are in our 30s and the younger coders seem fewer on the ground. I feel a little that the 'retro' side of programming for the 2600 looks a little more attractive to newcomers than them wanted to learn how to fully push an A8. Also, if you wanted to try the A8, then you'd also consider 7800, Lynx or maybe Jaguar programming, so we would lose out on new recuits. This doesn't mean to say that we don't help out when we can though Regards, Mark

I'm doing a 27c128 tonight so I'll confirm the details for you via PM. Which version of the programmer software do you use? I tend to use Willem097g. [edit] the eproms both hadn't erased the first couple of bytes so they'll be on cook again and I'll try Wednesday night.

Certainly a switchable XEGS model board would fill the void. [email protected]/AtariMax already has the flashcarts, and SunMark do the MegaCart - both have different swap models from the XEGS. If a board could do all three, e.g. using Am29f010 then that would be something! Supporting the Am29f040 would be good too. Regards, Mark

Thanks, that Spanish site gives good information. Indeed, the 27c010 chips have 32 pins, wheras an HT23c010 can be got in a 28 pin package with an A16 line. As the bank switching on the XEGS board is handled through the chip latching on the data lines, you'll see the solder point so the board can optionally handle 64K or 128K ROMS. Nir Dary has made a switchable XEGS cart by adding some extra hardware. This works by using the high bit of the latch to completely disable the ROM so that the RAM underneath is made available. Also, as the 7 data bits of the latch can be utilised to select any 8K bank from the cart - chips up to 1MB can be used. The aim is that I have 3 spare Fight Night carts and so want to build and put my own EPROMs onto them. Regards, Mark

Do you know what the Sharp chips on the XE SUPER CART boards are? e.g. the Fight Night one I have is marked C300058-085A but gives no indication what it is - I'm guessing a 23010 or 23512? I have an Enhanced Willem programmer but I don't think you can blow these using it, just 27Cxxx chips? Thanks, Mark

I have mixed feelings about my advanced willem programmer. Its been behaving OK for 27 series EPROMs, e.g. writing a new OS chip for the 800XL. I've also programmed a PIC 16C84 on it. My gripe comes with the AM29F support - whilst I've been able to do an Am29F040 in the PLCC32 slot, I cannot get the Am29F010 to work at all. This may be just down to some dodgy solder point on the circuit, but with these boards it isn't always clear as to which selections/settings to be used for a given micro. I've tried for help on the boards but in the end gave up and used a FlashCart to write the chips instead. Regards, Mark

From what I recall, the decoding of the AR data is starts with a base 'seed' value. The I/O routines start decoding the data and the content of the sector gets checksum'd and the seed updated and used in the decoding of the next sector etc. From what I've seen in AR, details of the various files used are held in an area of memory, e.g. start side/sector/length, and so developing a small program to unencode these from the ATR images isn't beyond doing. I'm yet to delve into the Dungeon as I'd got to the stage of identifying where the I/O routines were but haven't fully disassembled them to the same level of the City. Once done I can then hook in the replacement 'get sector from cart instead' routines and continue from there. However, there are subtle differences between the I/O routines of the two games that might throw up some surprises, but from what Dan Pinal has said the I/O in the Dungeon is a little simpler than that of City. Regards, Mark

Hi, The XL problem is down to the ROM game using Page 3 memory to hold some game data, so typically it blats the data to zeros. As this involves the GINTLK register at $3FA, the next time a VBI occurs the system thinks that the ROM has been pulled and so goes into an endless loop in the O/S. Doesn't look like a simple one to fix I'm afraid. Regards, Mark

There was some discussion of this on the thread: http://www.atariage.com/forums/index.php?s...ic=32830&st=25# Have you tried the ROM under non XL/XE emulation? If not, PM me an image and I'll take a look Regards, Mark

That's one of the two I mentioned . The other is: AtariMania Cassette dumps

Just a word of thanks to those people turning the old tape games (especially all those UK games/US Gold imports etc) into CAS files, e.g. those found at AtariMania and the CAS Archive. Keep up the good work! Regards Mark

Found this under http://chiptunes.back2roots.org/ym in whittaker,_david.zip Example YM player: http://sourceforge.net/projects/sc68 or http://leonard.oxg.free.fr/stsound.html blood_money_ym.zip

I just downloaded the Blood Money Amiga mod files and they're nothing like the ST tune, more sample based, I guess I prefer the ST version.