ACE2B PAL question

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
Don't Panic. Please wash hands.
  • Is there anyway to get the ACE2B to prefer PAL at startup with an A2000 NTSC?


    I have cleared J102, and I have the newer Indivision ECS V2 that doesn't require Denise to be installed. When I try the two mouse button hold at startup and set the boot to start in PAL Enhanced the system manages to find its way back to NSTC. I have been using The Black Lotus EON demo to test, when is starts up in NSTC is gets all glitchy which its been doing.

    Thanks,

  • Is there anyway to get the ACE2B to prefer PAL at startup with an A2000 NTSC?

    Ony by exchanging the Aganus chip for a PAL version. We will most likely add this as a software setting to the ACA2000, but even the prototype of that is not due for another few months.


    I have cleared J102,

    That does not have an influence on ACE2b. The 2M Agnus chip does not have a PAL/NTSC pin at all.


    When I try the two mouse button hold at startup and set the boot to start in PAL Enhanced the system manages to find its way back to NSTC.

    I don't know for sure if the PAL setting remains if you click on "boot" in that menu. We do have a bootblock-routine that switches to PAL, but I don't even know what the status is on that one. Timm wrote that a while back, but I'm pretty sure it was never released, and I can't even say why. Anyway, maybe Timm can elaborate on what the routine does - maybe it helps getting this unfinished work out the door.

  • We have such a bootblock, but we somehow lost interest in it. I don't have NTSC hardware to test with. You find it attached. Please report back if it works for you. It's supposed to be installed on one disk. Boot with this disk to switch to PAL. Then remove the disk, then insert the disk that you actually wish to boot. It's supposed to continue booting with the second disk in PAL mode.

  • Timm, didn't you want to publish the "devicetool"?


    The easiest method would of course be to pad the file to be 901120 bytes - then write with an ADF-write utility.

  • There are numerous tools to install this, one would be bb20 from Aminet.


    Jens: We did not have a "case" yet for publishing devicetool. It has no GUI, but instead numerous options to destroy your media, various bugs, and incomplete documentation.

  • We have such a bootblock, but we somehow lost interest in it. I don't have NTSC hardware to test with. You find it attached. Please report back if it works for you. It's supposed to be installed on one disk. Boot with this disk to switch to PAL. Then remove the disk, then insert the disk that you actually wish to boot. It's supposed to continue booting with the second disk in PAL mode.

    Thanks. I can report the following:


    On my A500 with the stock 68000, Kickstart 1.3, ACE2 and Indivision ECS V2, using a Gotek, switchboot.adf works with some games (Pinball Fantasies, Lemmings), but not with others (Bubble Bobble, Another World) where it gurus before booting the game. It continues to boot, but in NTSC mode.


    With the Vampire V2+, nothing I tried could make it work - doing it after a power-cycle or Ctrl+A+A, booting from Gotek or CF card after switchboot, doing the two-finger salute and selecting PAL mode from the boot menu (of Coffin R58). Sometimes it gurus, sometimes it doesn't, but each time the machine reverts back to NTSC after switchboot sets it to PAL.


    Is it possible to package this as a program that can be run from startup-sequence?

  • Is it possible to package this as a program that can be run from startup-sequence?

    THis would mean to change the screen mode after it has already openes (at least on Kick 1.3), which is much more than just hacking a few registers. While the routine itself can easily converted into an executable, it will most likely just fail if run that late after system startup.


    The beauty of the bootblock is that it's executed so early in the system startup. It's the ideal place for such a hack - I don't think it makes sense to try and move it to a less suitable place, rather than finding out *why* it crashes.


    The Vampire stuff will be impossible to debug for us, as we don't have any Vampire card, and also we're not so keen on debugging other people's hardware. I've expressed criticism before about the (non-)testing procedures that Vampire uses, and I believe it's not required to go into more detail. The amount of complexity that Vampire adds to such a problem is in a truly bad relation to the problem itself. The easiest thing they could do is to just flip the PAL/NTSC bit on read/write to the respective register, as that's really easy to do if you have full control over the CPU.

  • The Vampire stuff will be impossible to debug for us, as we don't have any Vampire card, and also we're not so keen on debugging other people's hardware. I've expressed criticism before about the (non-)testing procedures that Vampire uses, and I believe it's not required to go into more detail. The amount of complexity that Vampire adds to such a problem is in a truly bad relation to the problem itself. The easiest thing they could do is to just flip the PAL/NTSC bit on read/write to the respective register, as that's really easy to do if you have full control over the CPU.

    Thanks for the reply, Jens.


    Of course I don't expect you to debug the Vampire, you have enough of your own hardware to take care of :)


    In the meantime I found plenty of mode switchers on aminet, I'll give them a try. Some of them seem to be more complex than a one-liner, but I'm not very hopeful.


    I could also try to file a feature request with the Apollo Team, since it does seem to be an easy thing to implement. In order to be as specific as possible, could you please tell me the name of the respective register?


    If all else fails I can always use my ACA500plus for the PAL games, for me it's an easy switch since I have the Vampire plugged to the Amiga externally through the Lazarus CPU relocator board. However, for people without the luxury of having a Lazarus and/or ACA500plus such a fix could be pretty useful.

  • We'll look into the bootblock approach again, as there seems to be more we can do. After all, the software approach works fine for all ACA500plus customers, and since a boot block can be put "in front of" a trackloading game/demo (by swapping disks), my vote goes towards debugging that instead of going to a commandline version that has much more limited use (no chance with track loaders).


    Since Vampire is a whole new platform, I don't consider it "Amiga" at all. Granted, it's really fast, but not 68k (even though it runs a good share of 68k software). So please spare me more Vampire reports here - I'd like to focus on Amiga, C64 and other fun stuff.

  • Here's a bootblock that I hope works better and fixes more titles.

    It shouldn't crash anymore, and it should also coerce the system a bit more into PAL.

  • Here's a bootblock that I hope works better and fixes more titles.

    It shouldn't crash anymore, and it should also coerce the system a bit more into PAL.

    So this is an *.img file. Is it possible to write this to a floppy using ADF blitzer? I use ADF blitzer for writing ADFs to floppy.

  • Oh yes, of course. Sorry. I'm always using .img and .adf synonymously. (It's just a raw device image, containing the disk's payload data, so it's even debatable if 'Amiga disk format' is really a 'format'.)