MaPa Posted April 15, 2014 Share Posted April 15, 2014 I have a problem with detecting keys on 5200 controller in 5200 mode. How should it work? Is POKEY working normally in 5200? The last key still pressed bit in $e80f (in 5200 mode) doesn't work (works for me as I think it should in Atari800Win or Atari800 2.2.0). Should pressed key fire IRQ continuously? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 15, 2014 Share Posted April 15, 2014 I can't seem to get the Ultimate 1MB ROM to map back in after deactivating it and banking in Sic! cart flash ROM. I write $80 to D5E0 to turn off Ultimate, write to the Sic flash control registers to get the flash ROM ID, then write $40 to D500 to turn off Sic. But subsequently writing to bits 0-5 of D5E0 doesn't bank Ultimate back in. Haven't tested on real hardware yet, although debugging outside the emulator doesn't appeal much. Am I doing something wrong? Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 16, 2014 Share Posted April 16, 2014 I have a problem with detecting keys on 5200 controller in 5200 mode. How should it work? Is POKEY working normally in 5200? The last key still pressed bit in $e80f (in 5200 mode) doesn't work (works for me as I think it should in Atari800Win or Atari800 2.2.0). Should pressed key fire IRQ continuously? I don't believe the behavior you are expecting or seeing in Atari800 is correct. See this thread for a programmer's actual experience on real hardware: http://atariage.com/forums/topic/3280-atari-5200-keypad-repeat-fix-success/?p=31907 POKEY works the same on the 5200 as on the 800, but the keyboard is hooked up very differently. It's hooked up such that each key on the keypad corresponds to four different keys to POKEY -- for instance, $00/01/20/21. This is why debounce (SKCTL bit 2) must be disabled to read the keypad and why bit 2 of SKSTAT doesn't work as expected either. The effect of this is that POKEY only reports a held key as being down for two scanlines and will report it again along with an IRQ every 32 scanlines. I've never heard an explanation for why the keypad was hooked up in this screwy manner. Quote Link to comment Share on other sites More sharing options...
Kr0tki Posted April 16, 2014 Share Posted April 16, 2014 I've never heard an explanation for why the keypad was hooked up in this screwy manner. I believe it was a deliberate attempt to support rollover. With this weird wiring, simultaneous presses of more than one key (not all combinations) can be correctly recognised by software. In a typical busy gameplay scenario, it might have been seen as a benefit. Quote Link to comment Share on other sites More sharing options...
Keatah Posted April 16, 2014 Share Posted April 16, 2014 (edited) Mind if I stick my head in here and interrupt with a feature request? The ability to (copy from registry) and write an ini file for portable use. I have a couple of nice configurations I swap back and forth between by clicking on my own specialconfig.reg file. This has the effect of swapping in a new set of parameters into the registry. I save a configuration I labored over by opening regedit and exporting the set of keys to a .reg file. It works well. But is not easily transported to other machines where I can't (or shouldn't) be writing to the registry. Does that make sense? By the way, nicely done, I've been following this project for years now and it keeps getting better and better. Much like fine wine. <- A little ass-kissing never hurt, eh? Edited April 16, 2014 by Keatah Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 16, 2014 Share Posted April 16, 2014 I can't seem to get the Ultimate 1MB ROM to map back in after deactivating it and banking in Sic! cart flash ROM. I write $80 to D5E0 to turn off Ultimate, write to the Sic flash control registers to get the flash ROM ID, then write $40 to D500 to turn off Sic. But subsequently writing to bits 0-5 of D5E0 doesn't bank Ultimate back in. Haven't tested on real hardware yet, although debugging outside the emulator doesn't appeal much. Am I doing something wrong? Tried a trivial test but couldn't reproduce. Does the .map command show the U1MB cart layer turning back on, or is one of the cartridge layers still active in the $A000-BFFF window? Mind if I stick my head in here and interrupt with a feature request? The ability to (copy from registry) and write an ini file for portable use. I have a couple of nice configurations I swap back and forth between by clicking on my own specialconfig.reg file. This has the effect of swapping in a new set of parameters into the registry. I save a configuration I labored over by opening regedit and exporting the set of keys to a .reg file. It works well. But is not easily transported to other machines where I can't (or shouldn't) be writing to the registry. Does that make sense? By the way, nicely done, I've been following this project for years now and it keeps getting better and better. Much like fine wine. <- A little ass-kissing never hurt, eh? Well, I suppose that could work... but is there a reason you don't use Altirra's portable mode instead? Create Altirra.ini or launch it with /portable once, and it'll use the INI to begin with. Quote Link to comment Share on other sites More sharing options...
Keatah Posted April 16, 2014 Share Posted April 16, 2014 (edited) Well, I suppose that could work... but is there a reason you don't use Altirra's portable mode instead? Create Altirra.ini or launch it with /portable once, and it'll use the INI to begin with. To answer why I'm not using the /portable mode directly, it's just because I have a large number of .REG files, and they'd need to be converted over manually. Otherwise the /portable mode would be just about perfect. I'd have a little batch file that copies into "altirra.ini" the desired configuration from a collection of previously made .ini files. I can use (and understand) the /portable option. Altirra creates a blank-default ini starting up an XL NTSC 320K instance. I would like for it to somehow create an ini file based on what I already have in the registry, with the controller & palette & machine settings and all that. I have a bunch of profiles in xxxxxxx.REG files that I would need to manually transfer (and convert values of) to a series ini file(s). That means going through each and every setting. I suppose I could do a little at a time in between my other emulator setup activities. I can also use "regedit /s AltirraConfiguration1.REG" as part of a batch file to pre-load one of my existing setups prior to running the emulator. Edited April 16, 2014 by Keatah Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2014 Share Posted April 16, 2014 Tried a trivial test but couldn't reproduce. Does the .map command show the U1MB cart layer turning back on, or is one of the cartridge layers still active in the $A000-BFFF window? Thanks Avery - I hadn't used the .map command before but I won't be without it from now on. The map showed that Ultimate 1MB flash control was "ARW" (I assume Active, Read, Write) during the problem phase, even though JEDEC_Reset had previously been issued. I laboriously traced this to the wrong value being written to the base register ($A0 instead of $00) immediately following #JEDEC_CMD_ID being written to $B555. This was my own fault, following experiments with Sic!. For some reason writing $A0 instead of $0 messes things up such that a JEDEC reset does not pull the chip back out of its flash state. Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 17, 2014 Share Posted April 17, 2014 The A in ARW in the .map output actually means ANTIC read. Not sure what you mean by the base register... if it's the bank register, than yeah, that would mess things up as it would swap out the flash chip window entirely, and then the $F0 byte wouldn't reach it to knock the chip out of autoselect. However, if this happens, none of the flash layers should be enabled. There are also a couple of logging channels that are specific to flash chip operation. The flash channel (lfe flash) will reflect flash chip operations, and the flash write channel (lfe flashwr) will show every write that the emulated flash chip sees, including the full address. This will show pretty quickly if the flash chip is seeing the writes you think it is. Might be a flash sequence emulation issue, though... the chip mfrs aren't always great about fully documenting their state machines. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 17, 2014 Share Posted April 17, 2014 Yes - banking register. Thanks for the explanation - the logging facility is excellent. I simply never knew how to switch these channels on before, so I was basically not using the time-saving functions available. I see they're described in the help, though. Gotta start using this stuff. The flash emulation is marvellous as it stands: it's hard to believe this stuff can be run in simulation, avoiding strings of failed flashed on real hardware. Thanks again. Quote Link to comment Share on other sites More sharing options...
serj Posted April 18, 2014 Share Posted April 18, 2014 (edited) Avery, this cartridge for 5200, do not work on altirra. http://atariage.com/forums/topic/224086-gebelli-compilation-cart/?do=findComment&comment=2970330 Edited April 18, 2014 by serj Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted April 18, 2014 Author Share Posted April 18, 2014 Serj, I don't think its meant to 'work', I believe its just a splash screen (what the page says), there's no actual game as such.. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 19, 2014 Share Posted April 19, 2014 Are all the empty cartridges it's possible to attach flashable? The AtariMax 1Mbit/8Mbit SDX flashers can't get a manufacturer ID off the chip. No problem if flashing isn't implemented with these (I'd hardly expect every cart type to be flashable), but was just curious whether it was supposed to work or not (AtariMax carts seem to have some extra flash control enable registers). Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 19, 2014 Share Posted April 19, 2014 The empty cartridges are flashable, yes. (There wouldn't be a point, otherwise.) The 4.46 flasher disks work, at least -- what version are you trying? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 20, 2014 Share Posted April 20, 2014 OK - that's what I thought. I'll have to try the 4.46 flasher again. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 20, 2014 Share Posted April 20, 2014 The empty cartridges are flashable, yes. (There wouldn't be a point, otherwise.) The 4.46 flasher disks work, at least -- what version are you trying? Updated from Altirra 2.50 Test 27 to Test 35 and MaxFlash carts are now detected. Couldn't get flashing working with the older version. Anyway: non-issue now. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 20, 2014 Share Posted April 20, 2014 (edited) No output from the flash logging channels when programming MaxFlash carts. Also, MF flashing can't be enabled when Ultimate 1MB is present, although I haven't checked yet whether this reflects the situation with actual hardware. Edited April 20, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 21, 2014 Share Posted April 21, 2014 Found an issue with the MaxFlash code that cause the flash write layer to sometimes drop out when U1MB was enabled... this should be a bit more reliable: http://www.virtualdub.org/beta/Altirra-2.50-test36.zip http://www.virtualdub.org/beta/Altirra-2.50-test36-src.zip Also adds more flash chip options for U1MB (U1MB must be disabled and re-enabled to take effect). I did notice a weird issue with U1MB, which is that the U1MB BIOS init also causes the MaxFlash cartridge to turn itself off. This is a consequence of the U1MB config registers aliasing against the cartridge bank register. I don't have a real MaxFlash cartridge to test against, but all the docs I have and the SIDE1 conflict issue point to this being a real issue. Makes me wonder whether the CPLD could be reprogrammed to avoid activating /CCTL until config lock. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 21, 2014 Share Posted April 21, 2014 Very cool - thanks Avery. I didn't want to harp on about these issues too much (since I didn't know if it was simply me doing things wrong or expecting too much), but now you mention it I did experience the "drop outs" you're talking about. The flasher would detect the cart once (immediately after mounting the empty cartridge), but never again thereafter. The extra chip options for Ultimate are hugely appreciated. I can confirm the issue with Ultimate 1MB, which (at the moment) is making me wonder if MaxFlash cart support is worth adding at all to my flashing tool until something can be sorted out. Your confirming the problem is helpful, since I had previously assumed that there was some bus load issue preventing me from flashing MaxFlash carts on Ultimate equipped machines. However, I've now verified in software (on real hardware) that's it's impossible to put a MaxFlash 1Mbit cart into a flash state on an Ultimate-equipped machine. The carts do work, however, if pre-flashed: I can boot SDX 4.46 from a MaxFlash 1Mb cart with Ultimate SDX turned off. Just no flashing, unfortunately. Sic!, meanwhile, can be nicely managed alongside Ultimate, with both devices individually flashable. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 21, 2014 Share Posted April 21, 2014 Still no activity from the flash logging channel when using the AtariMax SDX flasher. Quote Link to comment Share on other sites More sharing options...
phaeron Posted April 22, 2014 Share Posted April 22, 2014 Haven't moved over the MaxFlash cart emulation to use the unified flash code -- won't get logging until that happens. What you describe is odd, because it's the opposite of what the logic equations indicate should happen: booting should be affected and flashing should not be affected. Unless there's a newer CPLD program, all writes to the CCTL region ($D5xx) should go through except for $D500-D5BF when PBI RAM is enabled, and there are no write gates on the $A000-BFFF region. I don't see why an AtariMax cart would act differently than SIC! or SIDE in this situation. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 22, 2014 Share Posted April 22, 2014 No problem regarding logging: I seem to have things working now. I was actually using different flashing code for MaxFlash carts, but I've managed to write something generic now that I've figured out what's going on. Looking at the Altirra flash emulation source code really helped clarify the various flash states. I'm not best placed to speculate on Ultimate's logic behaviour, but I have emailed Candle about it. We'll have to wait and see what he says. SDX 4.46 definitely works on a MaxFlash 128Mbit with Ultimate installed. Weird. Anyway: I've got code successfully flashing emulated AtariMax carts here, so this seems a sensible place to start further testing on real hardware. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 22, 2014 Share Posted April 22, 2014 Did some more tests and the MaxFlash 1Mbit/Ultimate conflict appears not to exist after all. I don't know if failed flashes were down to improperly seated carts or marginal software or whatever, but both my own flasher and Tucker's will now program a MaxFlash 1Mbit cart on my Ultimate-equipped 1200XL. I'll keep an eye out for issues, however, if you suspect there should be one on real harware. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 25, 2014 Share Posted April 25, 2014 (edited) Can't seem to remember how to set up a MyIDE+Flash (128KB). If I select MyIDE 1 in the hard disk dialogue, then attach an empty 1Mbit Flash cartridge (MyIDE Banking), Tucker's bootable MyIDE 1 flasher sees a 4Mbit (?) cart, tries to erase it, and fails. I'm just trying to verify the actual banking registers for MyIDE+Flash and MyIDE II. They're said to be extensively documented over at AtariMax, but I can't find any information at all. I know the MyIDE II uses $D508 and appears to use bits 7 and 5 as a software unlock (?)... Edited April 25, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted April 25, 2014 Share Posted April 25, 2014 FILE>Attach Special Cartridge>YOUR CHOICE. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.