| - S0rin (QUIT: Ping timeout: 260 seconds) (~S0rin@user/s0rin) | 00:11 | |
| + S0rin (~S0rin@user/s0rin) | 00:16 | |
| - xet7 (QUIT: Quit: Leaving) (~xet7@user/xet7) | 04:33 | |
| + my_pc_is_amiga (~my_pc_is_@c-71-197-66-36.hsd1.ca.comcast.net) | 06:44 | |
| my_pc_is_amiga | @_Bnu and @mntmm -- I just sent a private email on an issue I've been seeing when switching between Amiga modes (flickerfixer) and RTG | 06:45 |
|---|---|---|
| my_pc_is_amiga | I'm actually seeing this on almost any program that I have tried (TypeSmith, PDraw, Organiser, DPaint) | 06:47 |
| _Bnu | Hi, yeah, I think trixster was having a similar issue, also on an NTSC Amiga. | 06:47 |
| my_pc_is_amiga | it is alternating between 800x600 and 720x480 | 06:47 |
| _Bnu | Yeah, I just read the email. | 06:48 |
| my_pc_is_amiga | ok cool... | 06:48 |
| _Bnu | No wait, tryphoncosinus. | 06:48 |
| my_pc_is_amiga | hopefully the video is not too bit .... | 06:48 |
| my_pc_is_amiga | *big | 06:48 |
| _Bnu | tryphoncosinus has a UART adapter coming to check the debug output, which should help diagnosing the problem a bit easier. | 06:49 |
| my_pc_is_amiga | the blackness that you see in the video is just fomr the monitor trying to switch | 06:49 |
| my_pc_is_amiga | cool | 06:49 |
| my_pc_is_amiga | I have seperately seen the RTG mouse pointer somehow overlayed on the Amiga screen. | 06:52 |
| my_pc_is_amiga | I'll have to see if I can send a screenshot of this -- kind of hard to explain | 06:52 |
| _Bnu | Yes, for some reason P96 changed the behavior of the hardware mouse cursor functions in some recent version. | 06:52 |
| _Bnu | And because you can't check the P96 version when initializing the driver, it's kind of hard to make it work quite properly on both old and new Picasso96. | 06:53 |
| my_pc_is_amiga | ah | 06:53 |
| _Bnu | It was changed for the multi monitor support thing that's on AmiNet, I forgot what it's called again. | 06:53 |
| _Bnu | CX something. | 06:53 |
| my_pc_is_amiga | oh yeah the CX commodity...yeah | 06:54 |
| _Bnu | Basically it lets you keep both RTG and native video enabled and move the mouse cursor between the screens seamlessly. | 06:54 |
| _Bnu | So on the ZZ9000 there's a bit of a... conflict there, if the scandoubler is connected. | 06:54 |
| my_pc_is_amiga | ok | 06:56 |
| my_pc_is_amiga | wonder if SOFTSPRITE could be used as workaround? | 06:56 |
| _Bnu | Maybe, but it'll tank RTG performance just like it used to. | 06:57 |
| my_pc_is_amiga | ok | 06:58 |
| my_pc_is_amiga | I guess I'm not too familiiar with the UART adapter...is this connected to the HDMI somehow? | 07:00 |
| my_pc_is_amiga | I do have a way to dump out serial debug from Amiga serial to like another computer.....not sure if that could help... | 07:01 |
| _Bnu | No, UART is serial. | 07:02 |
| _Bnu | And no, Amiga serial does not help. | 07:02 |
| _Bnu | It's the UART header on the ZZ9000 card itself. | 07:02 |
| my_pc_is_amiga | ah got it.... | 07:02 |
| my_pc_is_amiga | debug directly from ZZ9000 | 07:03 |
| - my_pc_is_amiga (QUIT: Quit: Client exiting) (~my_pc_is_@c-71-197-66-36.hsd1.ca.comcast.net) | 07:06 | |
| + xet7 (~xet7@user/xet7) | 11:49 | |
| _Bnu | mntmn: Would you happen to have some spare Z-TURN board left that I could borrow until... November or something? That is, unless you like only have one and you're planning on building a Z3660 and hacking away at it yourself, haha. | 15:21 |
| emiespo[m] | Read the GitHub page about the Z3660… it looks amazing with just one TREMENDOUS flaw: the need for a 68060. | 16:59 |
| apolkosnik[m] | LC060 won't cut it? | 17:02 |
| _Bnu | LC060 works fine, even at 100MHz if your chip can handle it. | 17:57 |
| _Bnu | It's not like requiring a 68030 or 68040 would make it any better to deal with, it'd just perform worse MIPS/cost. The cost of the rev 6 full 060s is a problem of course, if you want one of those. | 18:03 |
| mntmn | _Bnu: well i think that Z3660 design should be modified to use the zynq module like ZZ9000, and a little slot bracket PCB (maybe using the same slot bracket as zz9000) and some internal fpc (?) cables to carry out the signals | 18:07 |
| mntmn | _Bnu: i do have a z-turn from the original zz9000 prototype tho | 18:07 |
| _Bnu | Ah yeah, I know that. | 18:41 |
| _Bnu | But shanshe's sending me a Z3660 to mess around with, and I ordered a Z-TURN from Mouser, but it's not going to be arriving until mid-November or so. | 18:41 |
| _Bnu | And I doubt I could suddenly bring it up to use the ZYNQ module from the ZZ9000... | 18:41 |
| _Bnu | But it's okay, I'll just wait for Mauser. | 18:42 |
| shanshe | 060 rev 6 are hard to get now, but I'm happy to se that a LC rev4 can go up to 100 MHz with any trouble... and LC's are now between 40$ and 70$ | 18:50 |
| shanshe | *to see | 18:50 |
| mntmn | _Bnu: i think the mauser will be not much slower than me, mid november is in like 2 weeks? :3 also, intriguing that they have stock or will have stock | 19:18 |
| emiespo[m] | I was more thinking these boards should all ditch real 68000s and go for some ARM emulation, like the PiStorm. The LC060 will give some trouble, I have one and the system is not fully stable (besides, decoding pictures is terribly slow). | 19:37 |
| mntmn | well then the pistorm is already the solution | 19:40 |
| emiespo[m] | mntmn: true! But maybe an open source FPGA implementation of the 68030 could also be nice… or the Buffee (except that seems to cost way too much if compared to the PiS) | 19:41 |
| mntmn | yeah, but someone would need to invest _a lot_ of time in that. | 19:41 |
| + gdonner (~gdonner@c-98-253-93-116.hsd1.in.comcast.net) | 19:41 | |
| emiespo[m] | mntmn: I know, if it were easy, it would’ve done already. | 19:42 |
| gdonner | emiespo[m]: hmm; everything I've heard so far about the LC has been quite good--just needs the special 68LC060.,library | 19:42 |
| gdonner | YT channel author "Amiga Tests" was the one I heard that from | 19:43 |
| emiespo[m] | To add to the LC060 being bad IMHO, running a 68030 no-fpu executable at 100mhz is not the same thing as running a 68060 executable leveraging on pipelines and FPU… I noticed this with the SDK “single build” demo I made | 19:43 |
| gdonner | emiespo[m]: here's his original quote: "So far so good. I ran a quick test today and ADoom as well as three nice scene demos passed the test flawlessly. But this kind of test needs more time and more programs/games/demos." | 19:44 |
| emiespo[m] | Setting CPU=68030 will produce an exe that is many times slower that with CPU=68060… with this flag on, the rendering speed is closer to the ARM native (which makes me think that possibly the ARM code isn’t very optimised either 🤣) | 19:44 |
| emiespo[m] | gdonner: it will work ok with anything that doesn’t need a FPU | 19:45 |
| gdonner | right, but I assume anything that needs an FPU could (somehow?) be redirected to a software solution; might be a bit slower, but wouldn't crash? | 19:46 |
| emiespo[m] | Which is 97% of Amiga software anyway 😉 but in 2021 I’d like to have something better Amiga - wise. Many latest demo exploit the 68060 FPU and the fact that it can be pipelined to integer execution | 19:46 |
| gdonner | anyway, not much we can do about the CPU situation :-| at least the LCs are cheap | 19:46 |
| emiespo[m] | gdonner: yes, but not a bit slower, more like: unusably slower. MacOS has a soft fpu extension | 19:47 |
| emiespo[m] | gdonner: don’t get me wrong, I bought two of them myself | 19:47 |
| emiespo[m] | In case the TF360 ever sees the light of day 🤣 | 19:48 |
| gdonner | yeah; CS-Labs has my good rev. 6 and an LC, plus I bought an extra LC--they're going to start going dry soon too methinks | 19:48 |
| gdonner | now's the time to get them | 19:49 |
| emiespo[m] | But I am allowed to say that for a desktop Amiga there might be better options. Tbh IMO the Rev 1 68060 are still better that the LC | 19:49 |
| gdonner | oh sure--no arguments there; even the rev. 1 is rare though too | 19:49 |
| emiespo[m] | They might be slower for some games not requiring the FPU if the LC is double-clocked, but you can basically run everything with them | 19:50 |
| gdonner | AmigaOS auto-patches any bugs in any rev CPU, so no issues there | 19:50 |
| emiespo[m] | Well I bought one a few days ago for ~100€ | 19:50 |
| gdonner | oh wow; nice! | 19:50 |
| emiespo[m] | And guess what? It’s marked as LC 🤣 | 19:50 |
| gdonner | rev 1 marked as LC? | 19:50 |
| emiespo[m] | Except it’s fully working, and I stress-tested it with Quake for an hour | 19:50 |
| gdonner | woah; now that's a good 'mistake' to run into :) | 19:51 |
| emiespo[m] | gdonner: no I bought it as a full 060, the seller had it tested obviously. | 19:51 |
| gdonner | ah | 19:51 |
| emiespo[m] | The other 060 I have - from a CS-MKI that was lent me from a friend | 19:51 |
| emiespo[m] | Is actually marked as EC060 🤣🤣🤣 | 19:52 |
| gdonner | but still; the fact that some LCs might just be a rev 1 is encouraging | 19:52 |
| emiespo[m] | But again fully operational 🤷♂️ | 19:52 |
| gdonner | no 100 MHz overclock, but FPU :) | 19:52 |
| gdonner | sweet! | 19:52 |
| _Bnu | The only version of Quake that actually seems to use the FPU is ClickBoom Quake, though. | 19:53 |
| emiespo[m] | Well I guess Motorola just sold them as LC when they only had full CPUs in stock, possibly the price difference was still enough to justify the sale | 19:53 |
| gdonner | I think I'll buy another LC, as it will be a while before the Warp 4060 is out | 19:53 |
| _Bnu | At least for anything but by accident. | 19:53 |
| emiespo[m] | _Bnu: no, with the LC it crashes immediately. amiquake IIRC | 19:53 |
| _Bnu | Still. | 19:53 |
| gdonner | what 68060.library did you use? | 19:53 |
| emiespo[m] | Even if it just tries to access it for some computations… crash. | 19:54 |
| emiespo[m] | gdonner: I eventually stick to the MMU lib one, as it seems the most stable for me | 19:54 |
| gdonner | ah ok-there is SpeedGeeks LC lib too you could try | 19:54 |
| emiespo[m] | I also tried the “stripped down” version for the LC, but it won’t magically emulate a FPU | 19:54 |
| emiespo[m] | Well now I have the “full” LC mounted, and switching is not super safe… will skip until I have another board to put it on | 19:55 |
| gdonner | (for reference: https://eab.abime.net/showthread.php?t=101115) | 19:56 |
| gdonner | yeah, true | 19:56 |
| _Bnu | Either way, the Z3660 is on the CPU address bus. | 19:56 |
| _Bnu | You could implement an FPU in FPGA instead. | 19:56 |
| _Bnu | Or ARM software, I guess. | 19:56 |
| gdonner | might take some time though... | 19:56 |
| gdonner | I think SJ Leary wants to do a full rev 6 CPU in FPGA, but that'll take years, undoubtedly | 19:57 |
| gdonner | https://www.exxoshost.co.uk/forum/viewtopic.php?t=2444&start=30#top | 19:59 |
| gdonner | "None of my boards support 040. I have no interest in them. I'm going to move to developing an FPGA core for the TFx60s when the 060s completely dry up. This is why the TF1260 has a completely 3.3v socket and no 5v at all there." | 19:59 |
| _Bnu | The 040 as a physical processor is a very dead end, unless you find a use for the more modern somewhat stripped down derivatives. | 20:00 |
| _Bnu | Although the instruction set is very attractive, the chip itself runs too hot and can't clock very high at all. | 20:01 |
| _Bnu | For a usable 040, you should be looking at something like Emu68 + PiStorm. | 20:01 |
| emiespo[m] | gdonner: yeah but you see my point? Let’s say I want the top Amiga accelerator - the Warp 4060 - and a Rev 6… we’re heading to 800€. To get what? A 1994 CPU - maybe 1997 given the overclock… I’d rather divert some money to these other projects | 20:02 |
| gdonner | <emiespo[m]>: yeah, it all depends on what you want, and how much you're willing to pay | 20:02 |
| emiespo[m] | As I did donating to Buffee… but that was before they uncovered the price of the prototypes 🤣 | 20:02 |
| gdonner | there's really 'something for everyone' in development--I don't see that as a bad thing at all | 20:03 |
| gdonner | I appreciate all development work for the Amiga, even if I don't personally go with a particular direction | 20:04 |
| gdonner | none of it is Windows, and for that, I'm grateful :) | 20:04 |
| gdonner | _Bnu: quick question--is using a 68020-specific compile the same as a 68030-compile? | 20:05 |
| gdonner | (seeing as there are plenty more '020 compiles than '030 out there?) | 20:05 |
| _Bnu | It depends on the code. | 20:06 |
| _Bnu | Sometimes the 68020 and 68030 builds are identical, sometimes they're not. | 20:06 |
| gdonner | but should still be safe to use on an LC? | 20:06 |
| gdonner | or "test and see"? :) | 20:07 |
| _Bnu | Sure, any FPU calls are either done directly and require you to pass -f68882 or whatever it is to the compiler, and the others are done through libraries. | 20:07 |
| gdonner | good to know | 20:07 |
| _Bnu | And usually said libraries will detect if there's an FPU or not, but of course be slightly slower than unconditional direct calls. | 20:07 |
| gdonner | thanks! | 20:08 |
| emiespo[m] | _Bnu: I remember when I tried the integer version of Imagine versus the FPU one, right after buying a 68882 for my A3630 :-D I thought I had been scammed... it basically performed slightly worse | 20:11 |
| emiespo[m] | then I realised I was simply calling the math libraries, which in turn detected - and used! - the FPU | 20:11 |
| emiespo[m] | I == it | 20:12 |
| emiespo[m] | <gdonner> "there's really 'something for..." <- also true, but I believe that the PiStorm will eventually replace everything | 20:14 |
| gdonner | or pehaps "offer everything" :) | 20:16 |
| emiespo[m] | it's way cheaper, and gives you so much more... and the tremendous success it is having -- even being still basically a WIP -- says it all | 20:16 |
| apolkosnik[m] | The DSP on the Dave Haynie's prototype was supposedly able to pull off 10x FPU speedup | 20:16 |
| emiespo[m] | :-( that's why I am saying that sticking to a 68060 in 2021 is a bit of futile medical care... the Amiga team in 1993 was already thinking of abandoning the 68000 or adding some other coprocessors to it | 20:17 |
| gdonner | compatibility is key; time will tell | 20:18 |
| gdonner | there's certainly no lack of effort from plenty of people! | 20:19 |
| gdonner | just amazing | 20:19 |
| emiespo[m] | gdonner: what would really be good IMHO is a slow abandonment of the 68K architecture (not to mention PPC, and even Aros-Intel) in favour of the Arm one. | 20:19 |
| emiespo[m] | of course you'd have to keep an emulation layer somewhere, but isn't the same thing that MorphOS has been doing for 20 years? ;-) at some point maybe there could be an AROS version running on some more modern hardware, without the silly penalty of the emulation layer... you could still emulate AGA, or SAGA maybe :-) with a FPGA. | 20:22 |
| emiespo[m] | That's what the Vampire was also trying to do, although with their own ways. And Haynie definitely congratulated them for bringing some innovation to the Amiga architecture after a long time | 20:23 |
| emiespo[m] | which I believe is what he was trying to do with the Acutiator architecture + AAA in 1992 :-) | 20:24 |
| _Bnu | Yeah, but I mean... it's better to have something that exists than something that doesn't. | 20:30 |
| _Bnu | There will never* be an open source FPGA 68k implementation that outperforms a 100MHz 68060. There will surely be emulated CPUs that can outperform it at some point. | 20:31 |
| _Bnu | You could probably adapt a PiStorm32 to fit an actual 68060/040 socket as well, though that isn't the goal of the first version at the very least. | 20:37 |
| emiespo[m] | _Bnu: you mean strictly open-source right? as I believe the Vampire markets their 080 FPGA cpus as faster than a 100MHZ 060 :-) (and with a FPU) | 20:47 |
| _Bnu | I made absolutely sure to say open source FPGA 68k implementation for this very reason. | 20:56 |
| _Bnu | So that I wouldn't have to explain that yes, the Vampire FPGA core exists, and it is faster than a 100MHz 68060. | 20:56 |
| _Bnu | But now I had to do it anyway...! | 20:56 |
| _Bnu | So I should just have typed it all out to begin with. | 20:57 |
| mntmn | i do have 200MHz risc-v cores in my kintex-7 fpga but they are no CISC :3 | 20:57 |
| mntmn | so yeah it won't happen unless someone designs a good (hi perf) open 68060 core in a hdl | 20:58 |
| _Bnu | Yeah. You can of course have a "100MHz" 68060 implementation in FPGA, but then you'd better be sure that it performs on par or better than an actual 68060 per FPGA cycle. | 20:58 |
| mntmn | yeah | 20:58 |
| mntmn | it also depends on how much you want to spend on that fpga | 20:59 |
| mntmn | if you have money for virtex or something... | 20:59 |
| _Bnu | You've got TG68, but it doesn't even come close even for a basic 68000/partial 68020. | 20:59 |
| mntmn | does mister use tg68? | 21:00 |
| _Bnu | Yep. | 21:00 |
| mntmn | it's funny how complicated 68k is | 21:01 |
| mntmn | there's also ao68000 but it's apparently less efficient (needs more cycles on some instrs) than even original 68k | 21:01 |
| mntmn | i guess it won't happen because nobody will fund the poor sap who is supposed to write this fast 68k core | 21:03 |
| _Bnu | Yeah. | 21:03 |
| apolkosnik[m] | There's cycle accurate fx68 | 21:13 |
| apolkosnik[m] | That also got sucked into the atari core on MiSTer | 21:13 |
| apolkosnik[m] | TG68 got through the Toni Wilen's cputester, so it got quite a bit of bugs squished | 21:15 |
| apolkosnik[m] | TG68.C actually (that's the latest iteration hosted on github) | 21:16 |
| apolkosnik[m] | TG68K.C... I can't type today | 21:16 |
| apolkosnik[m] | MiSTer adds a bit of cache to that core, so it's the reason why it's a bit faster | 21:18 |
| apolkosnik[m] | It's not implemented as it should have been on 020 | 21:19 |
| mntmn | interesting | 21:22 |
| apolkosnik[m] | There's still a few things still missing on tg68, but it's not missing that much | 21:22 |
| mntmn | ah i did not realize that it is in active development https://github.com/TobiFlex/TG68K.C | 21:23 |
| mntmn | it can do 68020 so it can run p96 i guess ;) | 21:24 |
| apolkosnik[m] | Not really "active", at least not lately | 21:24 |
| mntmn | well a few months ago | 21:24 |
| mntmn | this year ;) | 21:24 |
| mntmn | i could try to plug it into my litex system at some point... | 21:24 |
| mntmn | on the kintex-7 | 21:25 |
| apolkosnik[m] | There's a list of what's missing at the top of one of the vhd files | 21:25 |
| mntmn | > -- 13.03.2020 TG bugfix extended addess mode - thanks Adam Polkosnik | 21:25 |
| mntmn | hey that's you! | 21:25 |
| apolkosnik[m] | It's been a while since I poked around there | 21:26 |
| apolkosnik[m] | 🤔 | 21:26 |
| apolkosnik[m] | My accomplishment was tracking down BFINS bug that made the Goraud Plasma in Nexus 7 demo look nasty | 21:28 |
| apolkosnik[m] | Next time I touch vhdl, I'll lea4n how to run simulations, rather than spend countless hours with HRTMon | 21:32 |
| mntmn | yeah this should def. be run in a simulation thing | 21:34 |
| mntmn | i haven't simulated vhdl yet though, only verilog | 21:34 |
| mntmn | with icarus | 21:34 |
| - gdonner (QUIT: ) (~gdonner@c-98-253-93-116.hsd1.in.comcast.net) | 22:07 | |
| _Bnu | There's RTG on the MiSTer MiniMig core, yeah. | 22:31 |
| _Bnu | But it's super slow. | 22:31 |
| _Bnu | (It's just a dumb framebuffer driver, so P96 is doing everything in software.) | 22:33 |
| mntmn | ah i was going to ask | 22:34 |
| apolkosnik[m] | I think it might have been loosely based on the code feom FPGAArcade | 22:39 |
| apolkosnik[m] | *from | 22:39 |
| apolkosnik[m] | After Mike open sourced it | 22:40 |
| _Bnu | Yes, which is in turn based on some other thing. | 22:43 |
| _Bnu | GBAwhatever? Unreadable assembler for no reason. | 22:44 |
| - tryphoncosinus (PART: !!unknown attribute: msg!!) (~lug@modemcable134.206-37-24.static.videotron.ca) | 22:49 | |
| emiespo[m] | wow this is fun. Or actually terrible, can't make my mind: https://www.youtube.com/watch?v=aWlfvcOOEQA&ab_channel=PTP | 23:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!