Rybags

In theory some features could be showed off - . seperate colour for PF1 and PF2 in hires modes which isn't possibly on legacy hardware (VBXE also can do this) . lower bit available for PF colours in all modes for 256 instead of 128 colours (VBXE also can do this) . single colour-clock shift for GTIA modes (normally the paletted mode shifts 1 CC to the right, this allows different blended picture possibilities

My guess would be - the cart inits then copies the Dos into Ram. There's probably a little extra code that waits for the Rom to disappear then performs a warmstart. The system could also present Basic or not depending if Option was held on startup (some gymnastics needed there to hold 2 distant buttons while powering up the computer. Also the cartridge could probably act like a freezer button to give a coldstart on demand.

OK - so is it just a quick way of booting a Dos then? And release the button makes the Rom disappear? I guess there would be an emulation case for such a cart.

What is it, a write protect button? Such a thing isn't really relevant in emulation since you can just have a Rom image mounted as a cart which isn't usually writable anyway.

Nice assortment - I like the Xenon music cover there too.

The copy of MULE I have from the day was a hacked file but required Dos to be able to load. From memory the loader relied on grabbing the active sector # from an IOCB so wouldn't work with a menu loader. Likely this or another cracked version could be modified to work from a flashcart.

It was a playable 3D FPS years before anything comparable so groundbreaking and a killer app of it's era. The graphics - well, it's been hacked to run in 160x192 equivalent mode which can make it look prettier but doesn't improve the gameplay greatly. We do have to remember that this game was developed probably before the computers were even in the marketplace and the budget was a measly 8K Rom and targetted an 8K Ram system.

Did you check continuity from the relevant pins on the 4051s to the kb ribbon connector? Maybe ensure the resistances are in the same range? Swapping the 2 4051s is also a common diagnostic step but by the sounds of it you've eliminated them as the possible problem anyway. So to me probably leaves just the board and Pokey itself. Though if Pokey was at fault you'd probably expect more than just one row to be non responsive.

I did a little project some time back that I called ATRLoad - it allowed loading large programs entirely into Ram from a single file. I did Spelunker, though a single disk image to begin with, allows it to exist in a file and fit into Ram beyond 48K then quickly stream the level data instead of loading it as the game plays. Such a thing in theory could be done with some multi-disk games - I had the idea to use hotkeys to tell the handler to switch among loaded images. Ultimately though, doing that or multiple sides into one image or file can be a case by case project that can be fairly intensive. But looking at it from a convenience point of view, there's probably not a huge number of games that would benefit - the AR games for sure but ones where you just load then flip and forget, the effort might not be worth the end result.

As a guess I'd say "not many" for PIA. It's probably the second simplest of the 65xx interface chips after RIOT though that in itself might have more components thanks to it's internal SRAM. Likely later evolutions such as CIA would have a much higher count thanks to inclusions like timers and more complex interrupt processing.

CIO supports Get and Put Record and Basic also has the XIO command which can give some extended CIO functionality. You could do something such as INPUT #1,A$,B,C,D$ but you'd need to ensure that the file data is suitably formatted to be received in that way - each item would need to be terminated with the EOL / Return character $9B (and of course receiving numeric data as ASCII strings can waste space in a lot of cases)

A sector map would probably be easiest IMO. Depending on the situation you could just build it and keep in another file then load it in. If there's errors relating to file # mismatch then obviously the map is probably broken due to the file moving and it could be rebuilt in that case. Then you could have caching - keep a copy in memory of recently read records and/or frequently needed records. As for getting records and splitting into strings and variables - with an index in hand that becomes a lot easier - though potentially you might have issues with short records if the file is appended to ? Or do our Doses always ensure only the last record is the only possible short one? "Records" - I've got 2 contexts going there - records as in the 125 byte ones that Dos gives us, and the user defined ones containing your sets of variables.

None that I know of. We're at a bit of a disadvantage in that most of our Doses don't use a FAT, but have the sector chain information at the end of each data sector. That makes doing random access harder vs FAT where just a few sector reads can allow an index to quickly be built for an entire file (or disk) Some Doses (3.0 at least, for what that's worth) use NOTE/POINT not as absolute but as relative offsets from start of the file, which could make things a bit easier. NOTE/POINT in it's "absolute" form in itself is handy but there's no guarantee that e.g. a file starting at sector 100 will have it's 5th data sector at sector 104 - so the only way to know is to actually read the file and construct the index yourself.

JMP $E477 will coldstart. Only 3 bytes to add or patch. But you usually don't want to just do it without warning as you potentially just boot into the same situation again. Also, "Bootable Xex" - there's no such thing really aside from Autorun.sys which can be chained by a Dos.

Merry Christmas (with 11 minutes to go)

How about just whip up a quick program that puts stuff in certain known positions and use it for verification rather than relying on something you have little control over?

https://www.c64os.com/post/howdoes1541work Just found that - seems to be a good informative piece. If it's a properly formatted disk, it can just get the sector/track ID from the media. If that's not the case or if an error occurs, it just steps the head back 35 times. Fair enough that they omitted the index hole sensor - so do the early Atari drives. But omitting the track zero sensor borders on being a criminal act.

The 1541 doesn't have a track 0 sensor, that's why it can repeatedly bang the head sounding like it's destroying itself (which it is as it can send it out of alignment) Stargider II - I'm fairly sure I had Starglider on the ST but wasn't able to copy the second one. Though that was common, where Amiga was able to duplicate a large portion of it's library using software alone, the ST wasn't.

The problem we have - with Pole Position as a prime example, we can do a nice looking track rendering but it involves HScrol/LMS changes on each scanline. That then makes it somewhat unfriendly towards rendering softsprites. In theory a rendering engine could do softsprites with offset per line taking those things into consideration but it would cause a fair bit of slowdown. On an unaccelerated machine I think we have to set the sights realistically. What would be nice is something similar to Lotus Esprit Turbo Challenge with multiple detailed opposing cars and terrain that has dips and hills. But so far we've not really seen anything very impressive. IMO we're genuinly lacking good FPS perspective racing games that match mid-late 1980s competing systems.

C64 doesn't allow booting a disk. Atari needs the first sector as a minimum, the rest is optional. So in theory it should be reasonably easy to produce a dual format disk (I posted in that other thread also) But the economics might not be there, and flippy makes more sense. Dual format would mean you lose around half the capacity of the side. I have to wonder though if there were any Amiga/ST dual format disks. Likely they need the same sector to boot, but the ST also has the autorun feature, or you can just click/run from the GUI. Early Amiga can read ST/PC formatted disks with a fairly small addon program.

Can't say I've looked at the code for this game. Also, isn't there at least 2 versions - Which one are you concentrating on?

I don't quite get why you'd bridge those pads - PB5 and PB6. Normally on 130XE, bit 5 controls if Antic sees main or extended Ram. On some schemes >128K, it forms part of the extended bank selection. There doesn't seem any logical reason to force bits 5-6 to the same value.

Elektraglide - http://www.atarimania.com/game-atari-400-800-xl-xe-elektra-glide_1821.html

I might be wrong but get the feeling that there was a release of MULE as flippy. Chances are such releases were probably later issues and likely more common in the UK and Europe.

You increment LOC each time then add 40 to it before the end of the outer loop. You should only add 32 since it's already had 8 added to it in the inner loop.