| mntmn | forcie: yeah there was a bug or weird behavior | 00:35 |
|---|---|---|
| mntmn | forcie: i use FastIPrefs and that seems to hide the menu bar when backdrop is on | 00:37 |
| mntmn | really weird | 00:37 |
| mntmn | (because i needed a substitute for iprefs, maybe there's another one) | 00:37 |
| forcie | oh | 00:41 |
| forcie | it is fascinating how almost anything can be replaced | 00:42 |
| mntmn | yes | 00:49 |
| mntmn | i will do a writeup tomorrow | 00:49 |
| mntmn | and some alpha testing zip archive or disk image | 00:49 |
| mntmn | of course it's hard to say if all the lhas i used are legit and don't themselves contain warezzz | 00:50 |
| mntmn | (everything is from aminet) | 00:50 |
| - RobDangerous (QUIT: Ping timeout: 256 seconds) (~Thunderbi@p200300ec8f3e1c0079e4f9f2376e6b93.dip0.t-ipconnect.de) | 01:05 | |
| + RobDangerous (~Thunderbi@p200300ec8f3e1c00946d7ef7cfdde9d0.dip0.t-ipconnect.de) | 07:27 | |
| - RobDangerous (QUIT: Quit: RobDangerous) (~Thunderbi@p200300ec8f3e1c00946d7ef7cfdde9d0.dip0.t-ipconnect.de) | 07:34 | |
| + RobDangerous (~Thunderbi@p200300ec8f3e1c00946d7ef7cfdde9d0.dip0.t-ipconnect.de) | 07:34 | |
| mntmn | soo i should probably release my ZZombie OS thing | 15:31 |
| _Bnu | No, it is too dangerous... | 15:42 |
| _Bnu | ACTION dies of danger | 15:42 |
| mntmn | uh oh | 15:46 |
| mntmn | i am writing the readm | 15:46 |
| mntmn | e | 15:46 |
| _Bnu | Can we expense the writing of the readme... | 16:19 |
| _Bnu | Also mntmn, Claude and I were considering going to Berlin sometimes in September and break into your office, naturally without asking you if it's okay to visit at that time... | 16:20 |
| mntmn | oh wow ok | 16:20 |
| mntmn | do it, just not in the first week!! | 16:21 |
| _Bnu | Is that when they carpet bomb the city and rebuild it to keep things fresh... | 16:21 |
| Claude | that's on 31th December | 16:34 |
| mntmn | mhm | 16:47 |
| mntmn | here's my writeup https://github.com/mntmn/ZZombie | 16:47 |
| mntmn | but i haven't put in any actual files from packages yet because i still have to think about the correct approach | 16:47 |
| mntmn | feedback appreciated! | 16:48 |
| _Bnu | Download files to hard drive and upload to the cloud. | 16:57 |
| mntmn | maybe i don't even need to redistribute any packages, i could do a build script instead... | 16:59 |
| _Bnu | Why is there no CD32 version... this operating system is the worst. | 17:01 |
| mntmn | ;_: | 17:04 |
| apolkosnik[m] | Script on the pc to download and build the package blob? | 17:06 |
| mntmn | yeah | 17:06 |
| mntmn | for example. i'm not sure if it's ok to distribute files that are extracted from the archives | 17:06 |
| mntmn | at least not in all cases | 17:06 |
| apolkosnik[m] | Yeah, also aminet has a flag for tings not to distribute on aminet CDs | 17:09 |
| _Bnu | I hope that includes ports of open source things with no source code available, lol. | 17:10 |
| _Bnu | Because those things can seriously go die in a fire. | 17:10 |
| mntmn | lol | 17:13 |
| mntmn | where can i see the flag?? | 17:13 |
| _Bnu | :aminet_flag: | 17:25 |
| mntmn | :D | 17:25 |
| mntmn | maybe i should rather take a two-step approach. first make the bare minimum and then some kind of script that can download more stuffz... perhaps on the amiga itself | 17:28 |
| apolkosnik[m] | 👍 | 17:30 |
| mntmn | what is even the license of amiga lha | 17:38 |
| mntmn | hmm "Permissive license" https://en.wikipedia.org/wiki/LHA_(file_format) | 17:39 |
| mntmn | setpatch is a trap, has a file README.first where it says it's not freely distributable | 17:43 |
| mntmn | in the trash it goes | 17:43 |
| mntmn | Redit has no license ;_: | 17:44 |
| mntmn | ah, the source code has a readme that says binaries cannot be distributed | 17:47 |
| mntmn | lol. | 17:47 |
| mntmn | why ;_; | 17:47 |
| forcie | can't have nice things on amiga | 17:49 |
| _Bnu | I am not freely distributable. | 17:52 |
| mntmn | need a new text editor then. i will see if vim can be stripped down perhaps | 17:55 |
| _Bnu | I don't think SetPatch is actually necessary, though. | 17:57 |
| _Bnu | At least it never runs on my WB 3.1 install. | 17:57 |
| mntmn | yep, goes in the trash | 17:59 |
| mntmn | https://aminet.net/package/comm/net/AmiTCP-bin-30b2 | 17:59 |
| mntmn | so this says GNU | 17:59 |
| mntmn | but then i read that later they charged for it? | 17:59 |
| mntmn | without releasing source maybe? :3 | 17:59 |
| mntmn | amitcp 3 sources are available. | 18:02 |
| mntmn | ok minimal version 1 https://github.com/mntmn/ZZombie/tree/main/disk | 18:12 |
| mntmn | bleeding edge fw1.9a z3 firmware with usb autoboot (not tested without usb stick!) http://dump.mntmn.com/BOOT.bin-z3-1.9a-20210805 | 18:17 |
| mntmn | now tested without usb stick... seems to work ok | 18:19 |
| mntmn | fails kinda gracefully | 18:19 |
| mntmn | now trying to preinstall AmiTCP into this thang... | 18:24 |
| Claude | a modern TCP stack for Amiga would be a thing | 18:27 |
| Claude | something like : https://www.oryx-embedded.com/products/CycloneTCP | 18:28 |
| mntmn | mhm | 18:32 |
| mntmn | > At some point during the installation, you will be prompted to change the root password. This will not work, so just close the window and continue with the installation | 18:32 |
| mntmn | (AmiTCP) | 18:32 |
| _Bnu | Not working, as intended. | 18:33 |
| mntmn | hehe | 18:35 |
| mntmn | is there a smol aminet browser/downloader tool? probably ftp? :3 | 18:50 |
| _Bnu | wget aminet.net -r | 18:55 |
| mntmn | hehe | 18:59 |
| mntmn | hmm Path something add doesn't persist | 19:02 |
| mntmn | is that normal? | 19:02 |
| mntmn | like, it doesn't persist across shells | 19:02 |
| mntmn | probably normal? | 19:02 |
| mntmn | ah that's what S:Shell-Startup is for | 19:09 |
| mntmn | the amitcp installer is fantastically broken :D | 19:19 |
| _Bnu | S:Shell-Startup is only used when the Amiga is connected to a 4k120 TV. | 19:19 |
| _Bnu | I wonder if anyone is selling recapped CD32s on eBby... | 19:21 |
| _Bnu | Yes, for 700 Euro. ('A`) | 19:21 |
| mntmn | ok amitcp works | 19:22 |
| _Bnu | https://www.ebay.com/itm/324738769349?hash=item4b9bf061c5:g:k14AAOSwOQlhCWIt It does come with a really nice looking controller, though... | 19:22 |
| mntmn | lol @ 700 | 19:22 |
| - xet7 (QUIT: Remote host closed the connection) (~xet7@user/xet7) | 19:23 | |
| + xet7 (~xet7@user/xet7) | 19:23 | |
| mntmn | amitcp is cool, only the installer is nonsensical | 19:24 |
| mntmn | also, vim is cool | 19:24 |
| mntmn | cool cool | 19:24 |
| _Bnu | I do want a working CD32 suitable for the SX32 Pro, but not so much that I'd pay 700 Euro for it, haha. | 19:26 |
| mntmn | lel | 19:26 |
| mntmn | also interdazzling http://aminet.net/package/comm/tcp/sana2-tftpclient | 19:27 |
| _Bnu | Maybe Claude can recap it using your laser cutter if I bring it to Berlin... and then we can play Pinball Fantasies... | 19:44 |
| RobDangerous | I have an additional CD32 that still worked last I tried. The expansion port cover is missing which makes it especially well suited for an SX32 Pro. Haven't recapped it yet but I can do that, check it and send it to you. | 19:46 |
| mntmn | _Bnu: sounds good to me | 19:48 |
| _Bnu | RobDangerous: Oh, I can pay you for it no problem. Just maybe not 700 Euro, haha. | 19:49 |
| RobDangerous | Pay me with... | 19:49 |
| RobDangerous | that 50Hz lock for the ZZ9000. | 19:49 |
| mntmn | haha | 19:50 |
| RobDangerous | Plus shipping costs. | 19:50 |
| _Bnu | I mean, I can do that, but that feels like I'm ripping you off... I'd literally just be trying different values until it's at 49.92-ish Hz, haha. | 19:50 |
| pasik | speaking of that.. how difficult would be to implement dynamic pixelclock aka 'sync to vsync' | 19:51 |
| RobDangerous | Let's do it this way - I'll recap it next month and see if it still works. If it does we'll discuss what we both think would be fair. | 19:51 |
| pasik | like ossc does it.. | 19:51 |
| RobDangerous | That's what we were talking about. | 19:51 |
| RobDangerous | I think. | 19:52 |
| _Bnu | I don't think it's actually possible to do that. Are you talking about the RTG modes? | 19:53 |
| pasik | talking of native amiga modes here | 19:53 |
| pasik | not rtg | 19:54 |
| _Bnu | Ah... in that case it'd be outside my area of knowledge, sorry. I have to withdraw my offer to fix the refresh rates for PAL/NTSC in that case. | 19:55 |
| pasik | so getting scrollers in demos and games being 100% smooth, running at the exactly same refresh rate than original amiga video mode.. | 19:55 |
| _Bnu | I only know how to configure the output using the Xilinx clock wizard. | 19:55 |
| pasik | ok | 19:55 |
| pasik | there's probably separate code path for the native amiga modes / scandoubler, right ? | 19:56 |
| _Bnu | Yes, but the output video mode and VDMA is set up in the same way for both. | 19:56 |
| pasik | ok | 19:56 |
| pasik | hmm | 19:56 |
| _Bnu | mntmn would be the one to know if there's some way to hook up the native Amiga sync as sync for the video output. | 19:57 |
| _Bnu | I'm not a hardware person, sorry. :D | 19:57 |
| mntmn | might be doable, but a bit of a more involved research project | 19:57 |
| mntmn | basically the 7mhz clock we use for sampling the image has to be used as an input for the clock wiz0rd | 19:58 |
| mntmn | instead of the fpga system clock | 19:58 |
| pasik | ok | 19:59 |
| pasik | maybe i should read the code in question | 19:59 |
| _Bnu | But yeah, the best I would be able to do is the old ~49.92/59.81Hz output, which did repeat one frame every few minutes or something. I can't really do anything about it, so don't attempt to compensate me for something that fancy, lolb. | 20:01 |
| _Bnu | I would still love to buy a recapped CD32 though, if you want to sell it... | 20:01 |
| pasik | :) | 20:02 |
| mntmn | what's the simplest adf mounting tool? | 20:03 |
| mntmn | ImageMount? | 20:03 |
| RobDangerous | Let's do it like I said, independently of the ZZ9000 things. That 49.92 thing would already be a very nice improvement though. | 20:03 |
| mntmn | interdazzling. i'm downloading SnoopDos.lha to USB stick with wget, but get corrupt data error on extracting it... | 20:09 |
| _Bnu | Yeah I mean, I was going to do it anyway, but I can't accept a CD32 for doing it. I'd feel way too bad about it. :D | 20:09 |
| mntmn | downloading + extracting on RAM: works, so we still have corruption when usb+network are used together | 20:09 |
| _Bnu | mntmn: The little memory addresses for ETH frames, maybe? | 20:10 |
| _Bnu | Though I think I stuck those at the end of ZYNQ onboard RAM... | 20:10 |
| mntmn | i will take a look at the differences between the ok and broken .lha | 20:11 |
| mntmn | mntmn@mntmn-i9:/mnt$ md5sum SnoopDos.lha | 20:12 |
| mntmn | bf4223f96bd5365f3bca9c85f44020e3 SnoopDos.lha | 20:12 |
| mntmn | mntmn@mntmn-i9:/mnt$ md5sum SnoopDos-good.lha | 20:12 |
| mntmn | 9ee3b5a2affc98cde004dc09d295de4d SnoopDos-good.lha | 20:12 |
| mntmn | they have the same size though | 20:12 |
| _Bnu | de4d | 20:13 |
| mntmn | hmmm http://dump.mntmn.com/screenshot-2021-08-05-20-16-08.png | 20:16 |
| mntmn | problem starts at exactly 0x4000 into the file | 20:17 |
| mntmn | and at exactly 0x8000 it starts to be normal again | 20:18 |
| mntmn | so there is one wrong chunk in the file from 0x4000-0x7fff | 20:19 |
| pasik | 0x4000 should be enough for everyone! | 20:19 |
| mntmn | umm this looks like the block is from something Miami related, which is not currently on that disk http://dump.mntmn.com/screenshot-2021-08-05-20-20-09.png | 20:21 |
| mntmn | no wait. that is in the ~good~ file | 20:21 |
| mntmn | ah. looks like good and bad file are intermixed | 20:22 |
| mntmn | good is bad and bad is good. | 20:22 |
| _Bnu | Bad is bad. | 20:34 |
| _Bnu | Of course the good one is bad, it is de4d. :( | 20:34 |
| mntmn | :( | 20:35 |
| mntmn | true | 20:36 |
| mntmn | i copied md5sum onto the system. | 20:36 |
| mntmn | it calculates the same sums on the files at least... | 20:37 |
| mntmn | lol | 20:37 |
| _Bnu | Ah, and you're sure it's not the cache flush messing with things at random? | 20:38 |
| mntmn | _Bnu: well, i'm trying to track that down! | 20:39 |
| mntmn | _Bnu: http://dump.mntmn.com/screenshot-2021-08-05-20-38-34.png | 20:39 |
| mntmn | oink boink | 20:39 |
| mntmn | copied the same file 10 times... but then it was not the same anymore... | 20:39 |
| mntmn | ahaha | 20:40 |
| mntmn | nightmarish corruption when writing things http://dump.mntmn.com/screenshot-2021-08-05-20-40-13.png | 20:40 |
| mntmn | reading seems consistent | 20:40 |
| mntmn | copies 9 and 10 are ok | 20:41 |
| mntmn | now i will check if this also happens without network cable plögged in | 20:42 |
| mntmn | _Bnu: you always said that the arm cache flushing does this, right? how did you track it down? just by disabling that? | 20:42 |
| _Bnu | Yeah, just commenting them out. | 20:43 |
| mntmn | i can confirm it is unrelated to network | 20:44 |
| mntmn | i have to say that i'm not using RTG | 20:45 |
| _Bnu | It renders RTG almost unusable since VDMA can't use the cache coherency thing, but it's testable in native modes. | 20:45 |
| _Bnu | Yeah I wasn't using RTG when testing it with ZZ9000USBStorage.device or anything. | 20:45 |
| mntmn | ok | 20:45 |
| _Bnu | Because, well... you can't really use RTG without the cache flush. | 20:46 |
| _Bnu | Can hardly see anything on the screen, haha. | 20:46 |
| mntmn | i have some shocking news for you though | 20:47 |
| mntmn | problem is gone if i boot with amiga cpu caches disabled | 20:47 |
| mntmn | (this is 68030) | 20:47 |
| mntmn | http://dump.mntmn.com/screenshot-2021-08-05-20-47-20.png | 20:47 |
| mntmn | the 68030's cache is only 256 byte though | 20:48 |
| _Bnu | Did you forget a volatile somewhere when reading the same memory address over and over... | 20:48 |
| _Bnu | Or writing... | 20:49 |
| mntmn | lets see | 20:49 |
| mntmn | if i remember correctly the 68030 cache fuxx with zorro timing somehow | 20:49 |
| mntmn | and we also had some graphics glitches with it that i forgot | 20:49 |
| _Bnu | Well, I can't speak for 68030 obviously. | 20:49 |
| _Bnu | But I didn't disable caches on my 68060 or anything like that, I only commented out the old Xil_CacheFlurshBlob. | 20:50 |
| mntmn | yeah, i mean that's maybe a different problem | 20:50 |
| mntmn | because that's on the arm side and my problem here is on the 68k/zorro side | 20:50 |
| mntmn | maybe there are 2 problemz | 20:50 |
| mntmn | i need zztop... | 20:51 |
| _Bnu | I need Zoro... | 20:52 |
| mntmn | HiZoro | 20:53 |
| mntmn | bus test without 030 cache says 0 errors | 20:54 |
| mntmn | with cache also 0 errors. | 20:55 |
| mntmn | i also tested rtg yesterday and that looked fine | 20:56 |
| mntmn | hmm | 20:57 |
| mntmn | memcpy(registers-0xd0+0xa000, data+offset+(j<<SD_SECTOR_SHIFT), 512); | 20:57 |
| mntmn | (in the amiga driver) | 20:58 |
| mntmn | registers is just a void*, not volatile | 20:58 |
| mntmn | but not sure how memcpy is handled in terms of 68k cache anyway... maybe 256 bytes are not committed before writing sometimes | 20:58 |
| mntmn | i would expect the filesystem to be a lot more corrupted though | 20:59 |
| mntmn | http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node01F0.html | 21:00 |
| _Bnu | It's a GCC thing, with VBCC basically everything* is volatile. | 21:02 |
| _Bnu | (Most of the time.) | 21:02 |
| _Bnu | But if you do repeated reads or writes from/to the same memory address with GCC, you need to guard it with a volatile. | 21:02 |
| mntmn | there's also http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node01EF.html | 21:03 |
| _Bnu | Those things are super mega slow, and you never want to use them, haha. | 21:05 |
| _Bnu | If you want to invalidate the cache, the fastest way is the dummy read from the RTG driver. | 21:05 |
| mntmn | well, i don't care about speed right now, first i want to figure out what's going on | 21:06 |
| _Bnu | The dummy read should work, if it's really the 030 cache messing with you. | 21:07 |
| mntmn | yeah but i already put CacheFlushU in there to test | 21:07 |
| _Bnu | It'll make things slightly slower, but nowhere near as slow as calling those cache flush opcodes. | 21:07 |
| mntmn | ok so 1 of 10 files is now still wrong, and copy nr 1 is exactly the same md5 that i got on an earlier try | 21:07 |
| mntmn | so it recreated exactly the same error as before... | 21:08 |
| mntmn | i guess it's maybe not directly 68k cache related but that just changes the speed of things | 21:10 |
| _Bnu | Ah yeah, the more accesses you do (the faster you go), the more likely it is to go wrong sooner. | 21:14 |
| _Bnu | It's only when you need to access something through the ARM side. That was why the new vsync register thing was added. | 21:14 |
| mntmn | well humm | 21:17 |
| mntmn | the whole bufsel mechanism for writing is a bit wonky | 21:17 |
| mntmn | selecting the write buffer happens through arm | 21:17 |
| mntmn | but the actual writing happens through dma | 21:17 |
| _Bnu | Yeah, but a write to or read from any ARM register has the potential to get lost. | 21:19 |
| _Bnu | Even the DMARTG command writes get lost sometimes. | 21:20 |
| _Bnu | I even had it happen while I was running P96Speed, it lost one copyrect for SizeWindow or something and ended up with just an empty rectangle, haha. | 21:20 |
| pasik | it sounds like lossless firmware is needed! | 21:21 |
| mntmn | are you sure they get lost or are they just in the wrong order? | 21:21 |
| mntmn | because i could imagine a race between the axi and the zorro state machine | 21:21 |
| _Bnu | I'm pretty sure they get lost and/or blobbed. | 21:21 |
| mntmn | or that the axi bus is delayed | 21:21 |
| _Bnu | Because when I was trying to use an ARM register for the vsync, it would sometimes just return 0x00 or 0xFF. | 21:21 |
| mntmn | like, arm -> axi -> fpga can be delayed and take longer than expected | 21:21 |
| mntmn | hm | 21:22 |
| _Bnu | And when playing games in ScummVM, you can sometimes see how it fails to draw a "strip" of the background in for instance Full Throttle. | 21:22 |
| _Bnu | It's because the DMA_ACC command doesn't make it through to the ARM side at all, like it gets deleted by the cache flush somehow. | 21:23 |
| _Bnu | I unfortunately can't give any reasonable steps to reproduce it, other than hammer some ARM register that returns an ever increasing value or something? | 21:24 |
| mntmn | mhm yeah... i am now logging the bufsels | 21:24 |
| _Bnu | 256-bit integer check. | 21:25 |
| mntmn | on the arm side | 21:25 |
| mntmn | most of the time amiga makes smol writes so bufsel is 0 | 21:25 |
| mntmn | but not when writing bigger files, then bufsel increases a lot | 21:26 |
| _Bnu | To 650,000 :O | 21:29 |
| mntmn | 31 seems to be the max... | 21:29 |
| _Bnu | Maybe depends on the number of buffers set for the device? | 21:30 |
| _Bnu | Partition, even. | 21:30 |
| mntmn | maybe we need to sync to the axi state machine in the zorro state machine... | 21:30 |
| mntmn | no, the amiga doesn't know about these buffers per se | 21:30 |
| mntmn | it just says how many blocks it wants to wriet. | 21:30 |
| mntmn | write. | 21:30 |
| mntmn | raed and wriet | 21:31 |
| mntmn | this is how it looks like when doing 1 copy http://dump.mntmn.com/screenshot-2021-08-05-21-31-34.png | 21:32 |
| mntmn | (i put a newline when the bufsel is 0) | 21:32 |
| mntmn | obviously these printfs fix the problem... | 21:33 |
| mntmn | (unfortunately they really do) | 21:37 |
| mntmn | _Bnu: lol http://dump.mntmn.com/screenshot-2021-08-05-21-38-34.png | 21:38 |
| mntmn | i'm trying some synchronization between the isr routine and the main loop's write section... | 21:50 |
| mntmn | ok that might have fixed it | 21:52 |
| mntmn | at least all my files are ok now | 21:52 |
| mntmn | i've made it so that the isr with its cache flush cannot disturb stuff in the register write section anymore | 21:53 |
| mntmn | by using 2 global lock variables | 21:53 |
| mntmn | hopefully rtg still works ;3 | 21:56 |
| _Bnu | Dogs! Dogs! Dogs! | 21:58 |
| _Bnu | And yeah, printfs are really slow both on the ZZ9000 and the Amiga side, haha. | 21:59 |
| _Bnu | Retargetable Dogs. | 22:00 |
| _Bnu | I keep forgetting to turn off my new TV... | 22:00 |
| _Bnu | And then I'm like. | 22:00 |
| _Bnu | "What's that on the TV..." | 22:00 |
| mntmn | radio on the tv | 22:00 |
| _Bnu | https://cdn.discordapp.com/attachments/789807768554831902/872932221529505822/20210805_220044.jpg And it's the anti burn-in screen. | 22:01 |
| _Bnu | (It animates.) | 22:01 |
| mntmn | oh, i've seen this before... | 22:03 |
| mntmn | i downloaded ALynx with wget on ZZombie and it was functional | 22:03 |
| mntmn | but it doesn't want to show http://de.aminet.net/aminet/ ... | 22:07 |
| _Bnu | Atari Lynx. | 22:14 |
| - stepan (QUIT: Ping timeout: 272 seconds) (sid147049@id-147049.tinside.irccloud.com) | 22:16 | |
| mntmn | hehe | 22:21 |
| mntmn | aweb is really fast on 030 | 22:21 |
| _Bnu | It's the only browser I can ever really be bothered to use, haha. | 22:22 |
| _Bnu | I tried iBrowser or whatever it was called, and it was so insanely slow. | 22:22 |
| mntmn | IBrowse! | 22:24 |
| RobDangerous | There's a CD32 on that picture. Is that broken? | 22:26 |
| _Bnu | Yeah. Black screen, unstable sync. | 22:27 |
| _Bnu | Worked fine two or three weeks ago, was going to meme it up and connect it to the TV earlier today. | 22:28 |
| _Bnu | That's when I found out that it had died... | 22:28 |
| RobDangerous | Oh. When I send you mine, can you send me yours? | 22:28 |
| _Bnu | Oh, yeah, that's no problem. | 22:29 |
| _Bnu | We can trade CD32s...! | 22:29 |
| RobDangerous | Cool. I'll tell you how things went when I got to recapping mine. Maybe we can just get all the things fixed. | 22:29 |
| _Bnu | One thing, though. This one has some slightly dysfunctional mod installed that adds a Mega Drive 2 connector where the RF output used to be. | 22:31 |
| _Bnu | So... the RF output on it can't be used... | 22:31 |
| RobDangerous | Ah, RGB mod. Can have a look at that, too. Those are simple in principle. | 22:31 |
| _Bnu | But you can get RGB video if you have a Mega Drive 2 RGB SCART cable, even without a backplane, haha. | 22:31 |
| _Bnu | It doesn't sync on some monitors, but I don't know exactly why. | 22:32 |
| + stepan (sid147049@tinside.irccloud.com) | 22:32 | |
| RobDangerous | Might just be a cap. Otherwise I probably can't fix it, I don't even have an oscilloscope. | 22:33 |
| RobDangerous | So when I can't fix it I'll just forward it to Berlin. | 22:34 |
| mntmn | i... might have found a replacement for ScreenMode prefs... which is ModePro | 22:35 |
| mntmn | modepro doesn't seem to work with the workbench, but why | 22:40 |
| _Bnu | I think Workbench operates almost entirely on that one file uhhh... | 22:41 |
| _Bnu | Wherever it is... | 22:41 |
| _Bnu | ScreenMode.prefs or something. | 22:43 |
| mntmn | yep | 22:48 |
| mntmn | komisch | 22:52 |
| mntmn | interesting bug http://dump.mntmn.com/screenshot-2021-08-05-23-01-24.png | 23:01 |
| mntmn | haha this is fastiprefs/screenmode bug... | 23:02 |
| mntmn | the screen is tiny, like 640x256 and inside of a 800x600 mode | 23:02 |
| mntmn | those replacement screenmode prefs set the size to 0/0 :D | 23:03 |
| mntmn | ok panning is not yet fully functional in my version... | 23:04 |
| forcie | there is also MUIScreenMode | 23:06 |
| forcie | http://aminet.net/package/util/wb/MUIScrMode1_5 | 23:07 |
| _Bnu | Why do you hate panning so much... | 23:09 |
| mntmn | forcie: i know, but it requires MUI... | 23:11 |
| forcie | you already polluted the system with ClassAct crap :D | 23:11 |
| mntmn | forcie: the DisplayMode thing is fine, i just needed to set those width/height things to Default | 23:11 |
| mntmn | forcie: ;___; | 23:11 |
| mntmn | CrapAct | 23:11 |
| mntmn | now i need a better font | 23:12 |
| mntmn | lel http://aminet.net/package/text/font/ReplaceTopaz | 23:13 |
| _Bnu | I still like Topaz, for some reason... | 23:14 |
| mntmn | yes me too, but | 23:15 |
| mntmn | with RTG it looks fuxxed | 23:15 |
| mntmn | there was a double height version somewhere | 23:15 |
| mntmn | http://eab.abime.net/showthread.php?t=76310 | 23:15 |
| _Bnu | Aren't the Amiga fonts just single plane bitmaps, haha. | 23:17 |
| _Bnu | Should be easy to edit. | 23:17 |
| mntmn | yep | 23:37 |
| mntmn | rtg+reading big programs from usb = fail http://dump.mntmn.com/screenshot-2021-08-05-23-36-51.png | 23:37 |
| mntmn | (wget is like 1.4MB or something) | 23:38 |
| _Bnu | RTG is evil confirmed. | 23:39 |
| _Bnu | Maybe delete RTG and replace it with Minesweeper. | 23:39 |
| mntmn | yeah no my locking did not fix things http://dump.mntmn.com/screenshot-2021-08-05-23-40-18.png | 23:40 |
| mntmn | there must be more thorough debuggings... | 23:41 |
| _Bnu | Yeah I mean, I think the only solution would be to get rid of the cache flush somehow. | 23:41 |
| _Bnu | But it would require some really advanced ACP wrangling. | 23:42 |
| mntmn | no, no and no! | 23:42 |
| mntmn | i still want to understand it really in detail first | 23:43 |
| mntmn | i mean, i believe that it is related | 23:43 |
| mntmn | but i want to understand what exactly goes wrong behind the scenes | 23:43 |
| _Bnu | Good... | 23:44 |
| mntmn | one of the grand unsolved mysteries... | 23:45 |
| _Bnu | Yeah but I mean, I would be more interested in fixing the problem rather than figuring out how/why it happens and that it probably can't be fixed other than by not using it, haha. | 23:47 |
| mntmn | i think it is time for feierabend. so this all extreme messing with usb and fake workbench at least brought me back to this bug | 23:47 |
| _Bnu | Because it's like, how would you be able to tell that an ARM register read or write is about to happen so a cache flush doesn't happen at that moment? | 23:47 |
| mntmn | that's fair, but not understanding it is nagging me too much | 23:47 |
| mntmn | like, it's a bad feeling | 23:47 |
| mntmn | an itch unscratched | 23:47 |
| mntmn | i already excluded that | 23:48 |
| mntmn | unless my exclusion doesn't work | 23:48 |
| mntmn | but so far i did it only for writes, not reads | 23:48 |
| mntmn | i made 2 global vars, one do_not_disturb and one isr_running | 23:48 |
| _Bnu | Needs at least six more CPU core. | 23:49 |
| mntmn | when a write is pending, do_not_disturb is set, and isr_running is checked in a loop for being 0 | 23:49 |
| mntmn | and the isr function (that does the cache flush) first checks if do_not_disturb is set | 23:50 |
| mntmn | and sets isr_running... | 23:50 |
| mntmn | so the interrupt handler looks like this: | 23:52 |
| mntmn | void isr0 (void *dummy) { | 23:52 |
| mntmn | if (do_not_disturb) return; | 23:52 |
| mntmn | isr_running = 1; | 23:52 |
| mntmn | ... | 23:52 |
| mntmn | (cache flush and evil things) | 23:52 |
| mntmn | ... | 23:52 |
| mntmn | isr_running = 0; | 23:52 |
| mntmn | } | 23:52 |
| mntmn | and in the main loop we have | 23:52 |
| mntmn | if (writereq) { | 23:52 |
| mntmn | do_not_disturb = 1; | 23:52 |
| mntmn | while (isr_running) { | 23:52 |
| mntmn | // idle until ISR is complete | 23:52 |
| mntmn | } | 23:52 |
| mntmn | and do_not_disturb is cleared at the end... | 23:52 |
| mntmn | so theoretically a cache flush should never interrupt this block | 23:53 |
| _Bnu | Ah yeah, in my experience that doesn't quite work. I tried to do something like that for the IPL thread on the PiStorm. | 23:54 |
| _Bnu | But sometimes it would try to read the little identifier thing (isr_running in this case) just as it was being set, and that made it read back 0 even if it was being set to 1. | 23:54 |
| _Bnu | But hm. Can the other thing really be running if it's in isr0? | 23:55 |
| mntmn | pistorm uses multiple cores or only one? | 23:55 |
| mntmn | no, it cannot | 23:55 |
| mntmn | i think setting the variable cannot be interrupted because it's 1 instruction | 23:55 |
| mntmn | and there can't be half an instruction... | 23:55 |
| _Bnu | But the interrupt shouldn't really be related, since this cache flush thing interfered even when it wasn't in the interrupt handler. | 23:56 |
| _Bnu | And instead was in the somewhat faulty increasing counter block. | 23:56 |
| mntmn | aha. | 23:56 |
| mntmn | then the mechanism is different. what do you think fails? mntzorro_write? | 23:57 |
| _Bnu | Yeah, the first time shanshe and I ran into it was way before the screen split stuff was a thing. | 23:57 |
| _Bnu | I think it's some AXI communication stuff that gets wiped out or just doesn't happen while the cache flush is running. | 23:58 |
| mntmn | i think the only axi communication happens through mntzorro_read and _write | 23:58 |
| mntmn | or, is triggered by it... | 23:58 |
| _Bnu | Yeah, for DMA it's not a problem. | 23:59 |
| _Bnu | Only for the stuff that has to go through the ARM. | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
