Posts by robinsonb5

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.

    I've just pushed out an update which fixes an issue with loading config files, as well as some behind-the-scenes stuff. I did find an issue with the RTG support, and if you update the driver from the utils disk, you shouldn't see the stray lines of garbage pixels at the foot of the screen any more. I'm not sure whether it will have helped with the offset problem or not - so feedback would be appreciated.

    Oh, and I've confirmed that the MIDI ports are working on both V1 and V2 hardware when used with the V2 docking station.

    Thanks for the pictures - the scrambled data at the bottom prove that it's not the monitor. It looks like the video fetch is starting a few rows too early. I have seen that effect here before but annoyingly I can't currently make it happen!

    (The MIDI ports should already be supported - I'll double check them later today.)

    In my opinion, this must be a bug, because the test image is OK if I use 640x400x8 with the settings of 640x400x16. But as soon as I open a 640x400 picture in PPaint 7.3c, the error occurs. So the question is where the error is.

    Yes, there's definitely a (driver or hardware) bug which causes some screens to display too high up. I see it on the test screen, too though, not just in PPaint.

    Your monitor doesn't support 640x400, by the way, so it will always try to interpret that screenmode as 720x400. That could account for the left-shifting (though it shouldn't do - you should just get the ugly artifacts that happen when the monitor samples a scanline with a wildly incorrect pixel clock.)

    Is it getting shifted left with a blank area on the right, or is what's supposed to be on the left getting wrapped around to the right?

    Yes, both resolutions had exactly the same values as 640x400x16. Both gave a perfect test picture. In PPAint 7.3c, a 640x400 picture was then shifted. The menu bar was so high that it was no longer visible, but also shifted a bit to the left. It was as if the screen resolution was now 840x488 (see Settings) and not 640x400.

    OK I've just tried it here and I can reproduce it. I'm not sure, however, whether it's a driver bug or a problem with the monitor misdetecting the screenmode. My monitor's a Dell 2311H - with the settings you used for 640x400x16 my monitor reckons its looking at 720x400, and the image is shifted upwards slightly, and over to the left with a blank stripe at the right hand side. If I uncheck the vertical "SyncPolarity" checkmark, it now identifies the mode as 640x350 but it actually looks OK.

    Does unchecking the sync polarity box make any difference for you? And which monitor are you using?

    OK, I tried that. Although the test picture is without flaws, a 640x400 picture opened in PPaint is then displayed vertically shifted. Strange! I have therefore returned to the previous values.

    Yeah, very strange! You did change the pixel clock to match? Anyhow, if what you're using works, that's fine - hopefully I'll be able to address the other issues in due course.

    If you are really just working with an up-counter for the memory address, it's of course more complicated, as you need to introduce modulos for going from one line to the next, requiring a full-adder. The module doesn't have to implemented in a single cycle; if you have trouble meeting timing, you can always pipeline the calculation, as you have plenty of time during the blanking periods to count bit-by-bit instead of doing a full adder.

    I do just have a simple up-counter at the moment - though it is added to a base address so there is already an adder in the mix. For the initial version I did my utmost to keep the logic footprint as low as possible, so I'm actually re-using the AGA chipset's existing CRTC to create video framing, then simply filling a FIFO from SDRAM any time it's not full, and emptying the FIFO onto the screen any time the blanking signals are both inactive. It's arguably an overly simplistic solution, but it made very little difference to the core size, which was my main goal.

    If I still have spare logic elements after adding a couple of other features I'll look again at adding modulo support, but since the core already contains a scandoubler, routing the RTG through that is probably going to be the easiest solution, and will probably be smaller than dealing with resyncing the FIFO every scanline.

    Thanks Alastair for the technical background information. I don't know to what extent an FPGA is comparable to an emulator in this respect, but "amiberry" for the Raspberry Pi solved the problem quite well. Therefore I suspect that there could be a software solution.

    Without looking at it I can't be sure, but I'd imagine they put the Amiga's screen either on a texture and let the GPU scale it, or used a video overlay (if the GPU supports RGB overlays), again letting the PI's hardware deal with the scaling.

    Edit: I've just tried to create a 640x400 screenmode, and my monitor refuses to identify it as such - it's detected as either 720x400 or 640x350. The picture's there but the quality's poor because the monitor's expecting the wrong number of pixels. Your monitor might play nicer with this resolution than mine, though. Specs here:

    Watch out for sync polarity - this mode should have negative hsync, positive vsync.

    640x400 should be do-able (in a form that relatively modern monitors can tolerate) since it's a standard VGA resolution - the others might be trickier. 640x512 is easy enough to define, but being a non-standard mode, a modern LCD monitor will likely misidentify it and give poor results.

    The problem with 320x200 and 320x256 is that I don't currently have any kind of line doubling for the RTG output - it just spews out the contents of a flat framebuffer in strictly sequential order, so it's not capable of repeating lines.

    This means that, while you can define a 320x200 resolution, the refresh rate ends up being crazy fast and the monitor won't accept it.

    In the longer term I may be able to persuade the existing scandoubler into operating on RTG modes as well as Amiga modes, which would solve the problem.

    Thanks. Did a quick test with the new core. Super Off road will still crash back to workbench. As far as I understand, minimig core for other FPGAs also has issues with a few games. I will use your core more and report back any findings. I don't know much about P96 RTG and stuff like that. And I don't think I can use it with classic workbench anyway

    Super Off Road and the other Graftgold games require the CPU to be set to 68000 - that's the case with all TG68-based Minimig variants, and won't change unless someone (probably not me!) can figure out exactly what those games don't like about the TG68's 68020 implementation.

    As for P96, if WHDLoad is your main focus then it's not going to be of much interest to you, so don't worry about it. :)

    turrican9: Those illegal instruction -problems sound familiar. I tested whdload games a lot with TC64v1 some years ago. Eventually I got problematic games (at least these: Fire and ice, Gods, Rainbow islands, Paradroid 90, Super offroad, Uridium 2, Virocop) working, when choosing 68000. Similar settings but with 68010 or 68020alpha resulted always illegal instruction.

    Yes indeed, you're right - I've just tried Uridium 2 with 68000 mode and it works fine. It's a known problem upstream which affects most Graftgold games and their WHDLoad slaves.

    Thanks. Did you try Super Off Road whdload? When do you think we can try out the new core?

    I don't have that one, but it looks like the same problem, so probably the same cause. I'll aim to get the next beta out within the next few days.

    The Uridium2 problem happens here, too - so it's an incompatibility rather than a random bug, and not SD-card related - I'll see what I can figure out.

    Writing to ADFs is currently broken (the control CPU runs too fast and gets ahead of the FPGA, it seems.) As for the other problems, I've changed quite a lot behind the scenes, so there's probably no point bug-hunting until the next release is out, since some of them might have gone away already, or changed into different bugs by now.

    I'll be posting an update video soon to whet your appetite...!

    So I uploaded the image and PM-ed you a link. However, I have now re-formatted the SD card and tried to only put the Amiga HD image on it. And now minimig will write the config file just fine to it. Am currently copying over the C64 gamebase and the other stuff I had on it. So we will see if it still works fine after that. Something must have happened to the filesystem like you mentioned. Will report back

    That's great - I set it downloading before heading into work, so hopefully the file will be waiting for me on my return. I don't think the filesystem was corrupted - but there's likely to be a bug in the file creation / saving code in the Minimig core's OSD firmware which doesn't show up on "fresh" filesystems.

    I still cannot save to the config files I copied. do you know if an SD adapter with a micro SDHC card in it is compatible with the TC64 V2? And what about the SDXC cards?

    SDXC cards probably won't work - I haven't tested with those yet - and they certainly won't work while they're still ExFAT formatted. SDHC cards should be fine.

    Your problem with the config file is probably at the filesystem level rather than the physical storage level - if you can send me an image of the card at some point (or perhaps the first megabyte or two of the card, so I can see its file tables) I may be able to see what's going on. Were there already a lot of files in the card's root before you tried to write the config file?

    btw, is the minimig core picky about SD cards? Because I have two TC64 V2s and they each have a 16GB Sandisk SD card. They are slightly different versions Sandisk cards. I flashed my other chameleon with the same stuff and put the hdf file on it's SD card. For some reason it cannot create the config files when I try to save from the minimig menu. And I couldn't load the hdf image properly. Just told me it couldn't find one of the partitions. Strange. SD card is making savegames (updating) D64 images just fine. I tried the card from the other TC64 and it worked just fine in this TC64.

    Yes, it can be picky - and the code which creates config files isn't well tested. There are two different modes for HDF access - one assumes that the HDF contains a RigidDiskBlock just like a regular hard drive would, and the other mode creates a suitable RDB on the fly - it's possible that the second TC64 was using the wrong mode until you copied the config file from the other card.

    Tried the AGA core and kickstart 3.1 again. Managed to get into the minimig menu and changed the CPU to 020 Alpha. And now that setup works :)

    Glad to hear it's working. The "perfect" ROM for Minimig is actually the 3.1 A600 ROM because it works with all CPU settings, but still supports hard drive and AGA graphics!

    I shall have a look at defaults in future - you're right, 68000 / ECS is probably not the best default setting, even though the core's intended to be ECS and AGA, not AGA only.

    Real A500 keyboards aren't yet supported, but are on the "To Do" list.

    Thanks for the reports of non-working games - there are a couple of other compatibility issues that I'm aware of - but please let me know if you find any more.