HOME AUTOMATION Posted March 16 Share Posted March 16 Assuming that they boot-up! Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 16 Share Posted March 16 This is getting ridiculous! By overnannying the uninformed users, there are more an for side effects like false alerts (Stella 6.7.1 is affected too). Which will only lead to everyone ignoring these repeated, unwarranted warnings eventually. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 16 Share Posted March 16 👦+😭+🐺 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 16 Share Posted March 16 9 hours ago, HOME AUTOMATION said: Assuming that they boot-up! Well at least the Win 11 machine did 1 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted March 16 Share Posted March 16 Normally you can safely ignore any report like this that ends in !ml It means it's been detected by "machine learning" alogthim, an early form of AI and is crap report and tons of people and authors of legit programs have complained for years to Microsoft about it and their answer is get extended digital signature verification or submit your false positive each time. 1 Quote Link to comment Share on other sites More sharing options...
+chue Posted March 16 Share Posted March 16 On 2/3/2024 at 6:35 PM, JasonACT said: I'm extremely reluctant to post this, I have not had circuit boards made from these files, so the files are completely "unverified". But here are the DipTrace and generated Gerber files with R4 moved and re-purposed from a 10K ohm pull-up to the 470 ohm current-limiter for the SD clock. I really hope the files have no issues. Finally got mine built yesterday, and now it's obsolete 🙂. I put the latest 266mhz 2MB firmware on it. The SAMS burn-in ran 3 times on one of my TIs, so this PCB works. I might bodge this particular build in the future for the 8MB SAMS upgrade, but am not in a hurry to do so. 4 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 16 Share Posted March 16 (edited) 56 minutes ago, Gary from OPA said: Normally you can safely ignore any report like this that ends in !ml It means it's been detected by "machine learning" alogthim, an early form of AI and is crap report and tons of people and authors of legit programs have complained for years to Microsoft about it and their answer is get extended digital signature verification or submit your false positive each time. Yea, it's just weird that it just started yesterday. I've been saving this information about the PI Pico for instance, placing all the webpages as html only, and the files that Jason has been providing into a folder naming his zip files in the order they've been showing up on each page. This is so that eventually I could upload it as a package for anyone to be able to go to the page for a particular file and see what speed Jason stated it would run at or do. The virus is still showing up even after deleting everything in the download folder and re-downloading the pages again. It's only doing it on Atariage pages too. As a side note, if I download these pages as a complete webpage, not HTML only, I don't get the virus hits, even when running Windows Defender on the download folder after downloading. Nada. Edited March 16 by RickyDean spelling, added content 1 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 16 Author Share Posted March 16 6 hours ago, chue said: Finally got mine built yesterday, and now it's obsolete 🙂. I put the latest 266mhz 2MB firmware on it. The SAMS burn-in ran 3 times on one of my TIs, so this PCB works. I might bodge this particular build in the future for the 8MB SAMS upgrade, but am not in a hurry to do so. Thanks for reporting back! There'll be no more changes to the new V3 board unless there's a problem, I promise. I'm also hoping there will be no more changes to the code running on CPU1 (the time sensitive one) so I can lock that in at 266MHz, which runs the PSRAM chip(s) at their max. rated speed of 133MHz. CPU0 code, which runs the speech, file-system, WiFi and everything else not directly related to the TI bus, may get fixes and/or enhancements. And yeah, I've only done the 8MB SAMS upgrade on one of mine, but nothing I've found needs more than 2MB (or 1MB, really). Hopefully that changes. 3 Quote Link to comment Share on other sites More sharing options...
+chue Posted March 16 Share Posted March 16 1 hour ago, JasonACT said: There'll be no more changes to the new V3 board unless there's a problem, I promise. I was of course just joking about having an obsolete board. Change is normal and expected, so don’t worry about it too much. Now I need to explore the features on the boards that I have. I’m super excited about it. Thanks again. 3 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 22 Author Share Posted March 22 They call this beige? OpenSCAD 3D model attached, bottom part "no support needed", top part needs support. Zfinal.zip 3 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 27 Author Share Posted March 27 (edited) In the other thread: "QI model schematics" I suggested a theory, and that's all it is, I don't want anyone breaking their QI model TI (I personally would try it, if I had one, but they are hard to come by where I am) of a mod that may make it work like an original model: Red X (2) is a cut, blue lines (1 + 8 ) are joins. Anyway, I thought to make a new DSR.ROM that can be edited for the one last QI difference I think there is, pull-ups on the 8 bit bus data lines, rather than pull-downs on an original. So here is an updated DSR.ROM version that also "more carefully" checks for an inserted cartridge - for the original TI. It checks for the >AA byte in all 5 cartridge GROMS now (the old version only checked for one @>6000) and it checks >100 words @>6000 ROM too, instead of just 4 words - for value >0000. The value >0000 is located at position @>50A & @>50B within the file - the idea being it can be hexedited to >FFFF should someone want to test a modified QI console. But I stress, this should not be tried on an unmodified QI console, because there will be clashes with the U32 74LS245 chip with my 74LVC245 data lines chip. Remember! This is all just theory! DSR.zip Edited March 27 by JasonACT I've changed the +1 blue join line, I think I had it going to the GROM ground pin before. 4 Quote Link to comment Share on other sites More sharing options...
+chue Posted March 27 Share Posted March 27 11 hours ago, JasonACT said: a mod that may make it work like an original model Just curious, can you explain a little more? Does the mod make the side port and the cartridge port behave like the original? Do you see any other potential behavior changes? 11 hours ago, JasonACT said: I don't want anyone breaking their QI model TI When I do this, I'd like to do it non-destructively. My thought was to socket both the resistor pack and U32. For connecting the blue lines in your image, I was planning on doing that with another socket, which could be removed when needed. That way I can have the non-QI behavior by removing the components and inserting this connector socket; or, if I need the QI behavior I can re-insert the original components. By doing this there is not a need to cut W7. Does my theory hold up? I am a little short on time at the moment, but hope to get to it in the 2nd half of April. Anyone else is certainly free to give it a try. Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 27 Author Share Posted March 27 (edited) 2 hours ago, chue said: Just curious, can you explain a little more? Does the mod make the side port and the cartridge port behave like the original? Do you see any other potential behavior changes? From looking at the QI schematics, the side port is all connected up in a similar way to an original. There's only a small difference with pull-ups/downs. The big difference is with the cartridge port, where the data lines now have a 74LS245 line driver chip that switches on for cartridge GROM+ROM access. There's also the missing CRU lines, but we all knew that. The extra line driver has the effect that there appears to always be a "totally full" cartridge inserted, even when one isn't. The theory of this mod is to put that back to how the original works, where the cartridge data lines are directly connected to the side port's. I can't think of anything else that would work differently if this mod is done. Regarding the pull-up / pull-down difference, you may be able to see that with MiniMem's EasyBug. Dump CPU @>4000 with no CRU device selected, I think you will see >FF on a QI and >00 on an original TI. 2 hours ago, chue said: Does my theory hold up? Yes it does. Quote For connecting the blue lines in your image, I was planning on doing that with another socket But only do the 8 data lines, of course, not the +1 chip enable blue line, since you are not cutting the W7 wire. Edited March 27 by JasonACT 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 27 Share Posted March 27 Sorry to interrupt but, if you're on a roll... Here's a little nut that could use cracking. 1 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 27 Author Share Posted March 27 2 hours ago, JasonACT said: Regarding the pull-up / pull-down difference, you may be able to see that with MiniMem's EasyBug. Dump CPU @>4000 with no CRU device selected, I think you will see >FF on a QI and >00 on an original TI. This has been confirmed, it was one of the issues getting the FG99 working on a QI model, a firmware update was needed there too. 2 hours ago, JasonACT said: Quote For connecting the blue lines in your image, I was planning on doing that with another socket But only do the 8 data lines, of course, not the +1 chip enable blue line, since you are not cutting the W7 wire. Just wanted to repeat a bit of my late edited post. 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 27 Share Posted March 27 @JasonACT @chue could put a couple of single pin tooled sockets in the motherboard where the wire is, then use a shunt to plug into those socket and make the circuit complete at a later date should the need arise. I do have a couple of non working QI motherboards, but don't currently know where they are. 2 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted March 27 Share Posted March 27 54 minutes ago, JasonACT said: This has been confirmed, it was one of the issues getting the FG99 working on a QI model, a firmware update was needed there too. Just wanted to repeat a bit of my late edited post. I do have a FinalGrom99 and fully QI v2.2 console. -- What was needed to be changed, just the pull-up resistors? - As I don't see the extra 245 chip causing issues if you just care about the cartridge port, not the sideport. -- Also any info on this firmware update? -- I guess it would add a dummy GROM header so that it would see the ROM Menu at >6000 since its not scanned on v2.2 - Or was this test only done on normal v2 (regular grom 0) QI motherboard? -- Any links to this info? -- Thanks. Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 28 Author Share Posted March 28 (edited) 17 minutes ago, Gary from OPA said: I do have a FinalGrom99 and fully QI v2.2 console. -- What was needed to be changed, just the pull-up resistors? - As I don't see the extra 245 chip causing issues if you just care about the cartridge port, not the sideport. -- Also any info on this firmware update? -- I guess it would add a dummy GROM header so that it would see the ROM Menu at >6000 since its not scanned on v2.2 - Or was this test only done on normal v2 (regular grom 0) QI motherboard? -- Any links to this info? -- Thanks. On 5/7/2022 at 1:38 PM, JJB said: I got it ... I traced the problem to this piece of TI assembler. It is part of the browse, sort and menu code the AVR loads at CPU memory >6000: wait: mov *r7+, r2 ; image ready? jne ready dec r4 jne wait jmp animate It reads a set of ROM addresses from >6000 and checks if any data is there. While FG99 is loading that part of memory with either the next folder contents or an image, it takes the cartridge offline. Any read from that part of memory will now return >0000 on the classic TI as the GROM port data bus is pulled low during reads. However, on the QI the GROM port data bus doesn't have separate pull up/down circuitry and returns >FFFF ? I simply changed the code to test for both >0000 and >FFFF and now both TI's! are running FG99 as it should. See the attached final updates for the AVR. Cheers, Jochen update.avr 17.39 kB · 28 downloads https://forums.atariage.com/topic/322211-modify-qi-console-for-finalgrom99-use/page/5/ Edited March 28 by JasonACT 2 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted March 28 Share Posted March 28 7 minutes ago, JasonACT said: https://forums.atariage.com/topic/322211-modify-qi-console-for-finalgrom99-use/page/5/ thanks i will have to take a look at that, i recently unboxed my v2.2 QI and set it up with my CRT and Myarc Mini-PEB, and running great except of course FG99 doesn't work. -- now have to see how i can update the AVR with the code. - but does that fix the fact ROM>6000 is not scanned unless the v2.2 OS sees a valid GROM header as well? Quote Link to comment Share on other sites More sharing options...
JasonACT Posted March 28 Author Share Posted March 28 Just now, Gary from OPA said: but does that fix the fact ROM>6000 is not scanned unless the v2.2 OS sees a valid GROM header as well? I don't have one to be able to say. I wouldn't have thought so. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 28 Share Posted March 28 When a console containing the FinalGROM 99, is turned on... The FinalGROM 99, starts-up from a GROM, header... "Press 2 for FinalGROM 99". From what I understand, the FinalGROM 99, populates its own menu, using a routine similar to the one used in pre-v2.2, consoles. I suppose that results in an empty TI, main menu, after QUITing. Quote The FinalGROM 99 supports ROM images, GROM images, and mixed images of up to 1 MB in size that use the write-to-ROM bank switching scheme. The cartridge does not require the Peripheral Expansion Box and runs on both PAL and NTSC consoles, including modified consoles with an F18A. It will also run on v2.2 consoles and enables those to run ROM-only programs. From: https://github.com/endlos99/finalgrom99 3 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted March 28 Share Posted March 28 10 minutes ago, HOME AUTOMATION said: When a console containing the FinalGROM 99, is turned on... The FinalGROM 99, starts-up from a GROM, header... "Press 2 for FinalGROM 99". From what I understand, the FinalGROM 99, populates its own menu, using a routine similar to the one used in pre-v2.2, consoles. I suppose that results in an empty TI, main menu, after QUITing. From: https://github.com/endlos99/finalgrom99 i guess even tho i bought my FG99 recently, from someone making them, it must be outdated firmware on AVR - as it doesn't do anything on my v2.2 QI console. - maybe it was only tested on v2.2 - non-QI originally. - oh'well, time to try the >FFFF fix and figure out how to update the AVR. -- Sorry, for dragging this thread off-topic. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 28 Share Posted March 28 Yes, we do have a bit of a sub-topic going. updates(Link) Quote Link to comment Share on other sites More sharing options...
wiloson Posted April 1 Share Posted April 1 I completed my first PPEB board today and it doesn't seem to be working 100%. When the pico boots up the LED blinks 4 times but the "call tipi" command gives an error. Without the SD card the LED only blinks 3 times so the it is reading something from the SD card. The Pico is not a clone and the micro SD card is a new FAT formatted premium 32GB verbatim card. The "call say" works so there must be good communication between the TI99/4A and the PPEB. I'm using the latest DSR and a later version of PPEB2_264. Any advice on what combination of software and DSR would work the best? thanks Quote Link to comment Share on other sites More sharing options...
RickyDean Posted April 1 Share Posted April 1 (edited) 22 minutes ago, wiloson said: I completed my first PPEB board today and it doesn't seem to be working 100%. When the pico boots up the LED blinks 4 times but the "call tipi" command gives an error. Without the SD card the LED only blinks 3 times so the it is reading something from the SD card. The Pico is not a clone and the micro SD card is a new FAT formatted premium 32GB verbatim card. The "call say" works so there must be good communication between the TI99/4A and the PPEB. I'm using the latest DSR and a later version of PPEB2_264. Any advice on what combination of software and DSR would work the best? thanks Does your Fat32 formatted SD card have the following structure on it? I think the important files are the ones highlighted. But these all would be in themain zip file you downloaded. Edited April 1 by RickyDean added content 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.