Posts by iljitsch

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.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    What OS version are you using? And what settings in the MK3 tool?


    This is what I have on a PAL A1200 running AmigaOS 3.1.4:


    DblPAL 32 (or 64) colors, 720x540 screenmode

    Overscan graphics position 0,0; size 720x540

    Overscan text position 0,0; size 720x540


    IndivisionAGAmk3 1.7 (using 20201014 firmware) "VGA" mode:

    Pixel clock: 123.75 MHz

    Horizontal: 1920, 88, 44, 148, Pos

    Vertical: 1080, 5, 5, 35, Pos


    Select: always

    Lines: min 567, max 605, current 591

    Test/adjust:

    Left: 105

    Top: 2

    Width: 960

    Height: 540

    Res.: SHires


    I usually use borderblank but for this that's not necessary as the borders on both sides are already black.


    This works just fine with no distortions at all and the mouse pointer can go to all edges of the screen.


    (I was actually having some trouble making a good NTSC mode earlier where I did get strange stuff on the right edge of the screen, and I've also seen the mouse pointer disappear when it gets close to the right side of the screen in at least one mode, so I do have some experience with weirdness in some situations.)

    Is anyone else running into the limitation for the number of screenmodes that you can set up? At 31 the "copy" option becomes unavailable until you remove at least one.


    31 sounds like a lot, except that 18 are predefined and can't be removed. So you can define no more than 13 yourself. And with the following Amiga screenmodes:


    PAL hires/lores

    PAL superhires

    NTSC hires/lores

    NTSC superhires

    DblPAL

    DblNTSC

    Multiscan Productivity

    Euro36

    Euro72

    Super72

    HD720 1280x720

    HIGHGFX 1024x768

    XTREME 1280x1024


    That's exactly 13 modes. Obviously very few people will be using all of those, but I do find it very useful to have two or three mappings for certain screenmodes, for instance a PAL for the workbench which uses maximum overscan and a PAL for games which keeps the normally used part of the screen in the middle.


    Obviously there must be a limit on how much the FPGA can handle, but perhaps it is possible to have a somewhat smaller number of active modes and a larger number of modes that are disabled, and thus don't need to take up capacity on the FPGA. That way, you could simply disable some of the built-in modes to have more room to create your own.

    (There's also a key for pixel perfect scaling if I remember correctly, was that the S?)


    Well, yes, the MK3 only looks at two things to apply a mapping: the number of lines and superhires yes/no. So if you use PAL for your Workbench as well as for your games, the same mapping will be applied and you'll have to use shift-control-tilde X (no mouse movement!) tilde to make a change.


    Another option would be to use a different screen mode for your Workbench. I've experimented with 960x540 PAL superhires as well as a modified Euro36 960x540 resolution. DblPAL (+/-676 x 540) is also a very good resolution for the Workbench.


    (This is all on 1920x1080 or 3840x2160 displays, where 960x540 or at least 540 lines is a good match to the display's resolution at exactly 2 x or 4 x.)

    I decided to open up the A3000 once again to get to the bottom of this. The good news: with the Budda in the first / lowest slot, it's autoconfigured on boot and the superkickstart can be loaded from a drive connected to the Buddha (a CF card in my case).


    I tried this with the SCSI drive disconnected, so I'm sure it works.


    So I put the Buddha in the lowest slot, then the X-Surf, followed by the ISDN Master and the Cybervision 64/3D. When booting under kickstart 36.0, now the first three cards are all recognized, only the CV64/3D is missing from the list. So it looks like the bootROM has an issue configuring the CV64/3D cards, as well as any cards that come later in the AutoConfig process.


    So I'd say: put the Buddha in the first slot whenever possible.


    Another thing to keep in mind: the bootROM will only automatically load the superkickstart from the wb_2.x: drive if that drive has the highest boot priority. If not, it will boot by itself, i.e., under kickstart 36.0.

    With these suggestions I had another try. I first renamed the wb_2.x: partition so the kickstart wouldn't load from there. Then when I turn on the computer, I get the options to load kickstart 2.x or 1.3 from floppy, the options to load it from the hard drive are grayed out.


    I then tried the hidden close button. But I guess it's hidden too well, I couldn't find it. After trying some things, I got a kickstart selection screen. Not sure how that happened, and I couldn't get it again later. This kickstart selection screen only gave me KS 36.0 as an option.


    (The system also tries to boot with this kickstart when clicking "cancel" on the load kickstart 2.x/1.3 from floppy/HDD screen.)


    With kickstart 36.0, the machine will not get very far booting, but far enough for me to run info, which only shows me the SCSI partition and DF0 + DF1.


    I can also run Sysinfo, which shows me the only board that is recognized is the ISDN Master. The Cybervision 64/3D, X-Surf and Buddha don't show up.


    Could this have something to do with the order in which the cards are placed? the ISDN Master is at the bottom, above it the CV64/3D, then the X-Surf and the Buddha at the top. Unless I'm mistaken, the CV card is the only Zorro III one, the others are all Zorro II.

    Ah, that sounds good. I'll do the same at some point, maybe when AmigaOS 3.2 comes out.


    The A3000 has four ROM slots, where were the original ROMs and where did you put the new ones?


    I also wonder if kickstart in ROM is slower than in RAM. For my A1260 accelerator card in my 1200 that is definitely the case so the card copies the ROMs to RAM upon boot by default.

    Oh, one more thing: it seems sometimes partitions on the CF card are recognized as existing, but not as bootable. I don't remember exactly when this happened, though.


    I mostly tried with a 128 MB card and an 8 GB one (with only partitions on the first 4 GB).

    This morning my Buddha arrived. Short version: it won't boot my superkickstart A3000. Longer version:


    I first used the tools on the Buddha DOM to install 3.1 on a CF card. That (of course) didn't let me boot my A3000 from the CF card.


    I disconnected the SCSI drive and used the Amiga 3000 WB 2.0 installer to install the system on a 128 MB CF card. That didn't work at first because the disk setup tools assume scsi.device. So I set up a wb2.x: (and a Work) partition manually. (When you set a tooltype scsci_device_name=buddhascsi.device the HDToolbox will let you do this. Or start it from the CLI/Shell with the device name as the argument.)


    The installer then did its thing no problem, but when rebooting, I got the kickstart selection screen with the HDD options unavailable. After loading kickstart from disk, I got the "insert workbench disk" screen. After loading WB 2.0, the volumes on the CF card didn't show up. So I assumed the A3000 boot ROMs as well as the 2.0 kickstart won't work with the Buddha.


    However, it turned out my CF card had two "custom" file systems on it. The first was probably version 44.6 of FFS, the second version 10.5 or 18.5 (sorry, my A3000's video is not very good... fortunately I have a CyberVision 64/3D) of some other file system. After removing those, WB 2.0 would recognize the partitions on the CF card.


    Also, as I've mentioned before, I have a rather weird setup where the A3000 loads the kickstart 2.0 from the HDD as a superkickstart, but then it loads the 3.0 kickstart. The kickstart 3.0 has no issue recognizing the partitions on the CF card.


    Then of course I applied Jens' suggestion to downgrade the Buddha firmware to a previous version that still uses the scsi.device name, but then the CF cards weren't recognized at all. So I reflashed to the latest version again.


    Conclusion: if I want this A3000 to boot from a CF card connected to the Buddha, I'll have to install kickstart 3.0 (or higher) ROMs.


    For now I'll just use the SCSI drive to load kickstart 3.0 and then boot from the CF card. But at some point I think I'll install new ROMs. (I need to find someone to do maintenance on my A3000's motherboard anyway, as it still has the original clock battery and the flickerfixer adjustment screw seems to be broken.) But right now the SCSI drive still works and after booting, I'll put it to sleep so it doesn't bother me with its noise.

    I was the one brining up the 540 line resolutions (exactly half of 1080p). So that's twice the regular PAL interlace vertical resolution of 512 lines plus a total border area (overscan) of 28 lines. Of course if you don't use interlace it's 256 x 4 plus some extra lines.


    In general, this works very well as games mostly stay close to the normal 256 lines. Back in the day, most people set up their CRT monitors to use only modest amounts of overscan, especially in PAL mode. (Overscan is the extra image area around the regular image size that extends below the edges of the screen. The Amiga lets you use the some of the area normally used for overscan to make the useful image area larger.)


    288 or 576 lines doesn't make much sense, as this shows much more image area than any regular CRT monitor would display. These numbers are just the maximum that can be encoded by digital video. Unless I'm mistaken, the Amiga's limit is also a few lines less than this.


    NTSC is a bit more difficult. One resolution that works reasonably well is 1440x900 / 2 or 4, so 400 + 50 lines for interlace or 200 + 25 without interlace. This is not pixel perfect but I find that my displays do a good job of artifact-free non-integer scaling.


    However, 1440x900 is a 16:10 resolution, so the pixels won't be square. Still, on the Amiga NTSC pixels are supposed to be 44:52, so if you display 1440x900 as 4:3 you get pretty close to the intended pixel aspect ratio. But I believe most games ignore all of this anyway, and it's not too important in practice. On an analog CRT the aspect ratio would have been off by a bit anyway.


    I've also been thinking of NTSC 216 x 5 = 1080p. This should be 1920 / 5 = 384 pixels horizontally (with square pixels) which might just about fill the screen without any black bars on the sides. But I haven't tried this yet.

    To save others from spending time trying to get this to work: I have done enough testing to safely say that connecting a CF-to-IDE adapter to the IDE ports of the original X-Surf doesn't work, in an Amiga 3000, at least.


    I have tried with both IDE ports on the X-Surf, two different CF-to-IDE adapters and six CF cards. None of them are recognized in anyway, for instance by HDToolbox.


    Note that the X-Surf IDE driver uses scsi.device, which the A3000's SCSI adapter also uses. But, the Commodore engineers were smart so the X-Surf IDE device is renamed to 2nd.scsi.device.


    I do see the activity lights on the adapters flash during boot and when HDToolbox scans the devices.


    When I connected an IDE harddisk, that worked just fine. So it's an issue with CF cards, not an issue with the hardware or drivers in general.


    I have a Buddha card on the way because I want to be able to boot from a solid state drive, so for me this is not an issue, I just thought I'd write this down just in case it's useful for someone else.

    My understanding is that you can either load the superkickstart from a partition named wb_2.x or a partition named wb_1.3


    Not sure if the system checks whether the kickstart on wb_2.x is actually version 2.x and on wb_1.3 is actually 1.3. So one option would be to make a kickstart 3.x superkickstart file and put in on a wb_1.3 partition and then see if you get the choice between 2.x and 1.3 in the boot screen with the two mouse buttons.


    Also see MakeSuperDisk.


    I'm considering changing the partition on the DOM to allow loading the superkickstart so I can exchange CF cards (when the computer is off) without impacting how the computer boots.


    I don't really remember how I transferred the data from my 1.8 GB HDD to a 4 GB CF card on my Amiga 1200, that was in 2012, I think. But the result was an exact copy with all the partitions and even the drive geometry in HDToolbox still looks like the HDD, with only 1.8 GB available. A tool like Unix dd should be able to do this, see dd.lzh.

    Hm, my German isn't so great but it looks like he's trying to boot a 3.1 superkickstart.


    I actually boot from the original 2.0 superkickstart and then soft-kick a 3.0 kickstart, which is of course not the most efficient way to operate. I've been thinking about making a wb_1.3: partition and then put a 3.x superkickstart there, keeping the 2.0 one in wb_2.x:. For some time now I've barely used the A3000 as the fan noise was so loud, but I replaced the fan yesterday so I expect to use the 3000 more from now on.


    I've sent in my order for the Buddha and did the bank transfer.

    In the documentation it says:


    Autoboot with Kickstart V1.3, 2.0 and 3.1


    However, I have an old Amiga 3000 that loads its kickstart from disk. I believe it uses a weird 1.4 beta ROM version for bootstrapping. On such a system, will the bootstrap ROM do AutoConfig properly so it can see the Buddha and boot from the DOM or another attached drive?


    This is important to me as I have a 25-year-old SCSI drive that I had to fix this week and will no doubt fail completely in the future, and at that point I want to have a solid state solution to boot the A3000.


    (I had no success connecting several different CF cards to my X-Surf using two IDE-to-CF adapters, by the way. HDToolbox discovers nothing on 2nd.scsi.device. But it makes sense for the original X-Surf to never have been tested with CF cards before it wend EOL, unlike the Buddha.)

    Another option would be to have separate settings for each monitor, so different settings are loaded when a different monitor is detected, with safe defaults for unknown monitors.

    Actually that shouldn't be too hard to script. The IndivisionAGAmk3 tool can already read the EDID and then it's just a matter of checking for one or more known monitor names and copying over a different settings file.


    However, what would be helpful here is if the tool could output the name of the monitor, that saves having a separate utility that parses the saved EDID file to find the monitor name.

    That was my first thought as well, but: if you but from a Workbench floppy, you can remove that no trouble. The computer asks you to put it back in when needed. (The Amiga was so much smarter than those modern computers.) Also, I had an issue with my HDD so I ran DiskSalv, and then effectively the boot volume has been removed. So I got periodic messages to please insert it.


    Not that it makes much sense to remove your boot device, so I don't plan on doing that.


    But more importantly, are there electrical or driver issues? Obviously CF cards are made to hot plug, but I doubt the IDE spec or the X-Surf/Buddha drivers were written with that in mind.

    I was looking for something else when I saw an IDE-to-CF adapter that goes into a slot on the back of the computer, so it's possible to insert and remove the CF card without opening up the computer.


    I ordered one, so now my question is: is it safe to insert or remove a CF card into a IDE-to-CF adapter when the computer is turned on?


    I currently have an original X-Surf card that I'm going to use with this adapter tomorrow as soon as the right power cable arrives, but I'm considering getting a Buddha card so I can boot from a CF card. So my question is for both of them, but I thought I'd just ask here in order to avoid posting the same thing in two places.

    I tested with all my displays. The Dell P2415Q (my normal display) doesn't have any problems, unless I'm mistaken the LG OLED TV is also fine as well as the old Philips 1280x1024 DVI monitor, which actually handles 1920x1080, which is way higher than its native resolution.


    The problems are with the DVI Dell H2312UM and HDMI HP Z27. Especially the latter is extremely picky. These two don't accept their own EDID 1920x1080@60 resolution, not under 1.5 nor 1.6, even though the timings are slightly different between the EDID data as read by thesetwo versions.


    As for detecting audio capability: over here it says that bit 6 at position $83 indicates "basic audio" support.


    I checked the EDID data from my five displays, and it turned out that the two DVI ones have all $FF bytes above $80:



    The HDMI ones (supporting audio) all have real looking data here and bit 6 at $83 is indeed set.



    (Yes, this hex editor was the best one I tried off of Aminet. :))


    I'd say a good approach for safety would be to have something you could run in your user-startup that checks the monitor's EDID info and disables audio if the bit is unset or the EDID info doesn't include this bit.


    Another option would be to have separate settings for each monitor, so different settings are loaded when a different monitor is detected, with safe defaults for unknown monitors.


    I have included a zip file with all the EDIDs.

    Files

    • EDIDs.zip

      (1.59 kB, downloaded 202 times, last: )