aotta Posted July 12 Share Posted July 12 5 minutes ago, Gary from OPA said: Cpuclk and gromclk are outputs on the 9918 so it shouldn't effect it's non-usage on the Colecovision. Thank you @Gary from OPA, so Pico9918 doesn't need an external clock, that's what i hadn't understood. And, since i want to use it as tms9929 replacement, the different pinout shouldn't be a problem too! 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 12 Share Posted July 12 (edited) One small gotcha - while the TI's CPU and VDP clocks are not synchronized, the Coleco and many other systems are. This could cause timing-critical apps to misbehave on those platforms if they assume they are in lockstep with the VDP. (I'd expect rather few, though, maybe some of the tighter MSX demos ). I don't think it's something I would worry about. I mention it cause I want to see the results if it's true. Edited July 12 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 12 Author Share Posted July 12 1 hour ago, aotta said: Thank you @Gary from OPA, so Pico9918 doesn't need an external clock, that's what i hadn't understood. And, since i want to use it as tms9929 replacement, the different pinout shouldn't be a problem too! Confirmed. He doesn't need an external clock. The Ti-99 uses the GROMCLK signal. Some other systems use the CPUCLK, others don't use any. They are both "jumpered" if for whatever reason you want them completely isolated from the host. The PICO9918 also doesn't need working VRAM. He just needs data lines, read, write, mode and interrupt. Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 12 Author Share Posted July 12 1 hour ago, Tursi said: One small gotcha - while the TI's CPU and VDP clocks are not synchronized, the Coleco and many other systems are. This could cause timing-critical apps to misbehave on those platforms if they assume they are in lockstep with the VDP. (I'd expect rather few, though, maybe some of the tighter MSX demos ). I don't think it's something I would worry about. I mention it cause I want to see the results if it's true. Definitely agree it would be possible to write software to take advantage of this. I think the only issue could be for timing-critical changes during a scanline, which would be cool to see. 1 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 13 Share Posted July 13 On 7/7/2024 at 9:09 AM, JasonACT said: The Pico @250MHz has the ability run TMS9900 instructions at 2MIPS average, peaking at 4MIPS for a JMP $ loop. This is with GCC12.3 and -Os (-O2 was slower, GCC10.3 was much slower with either optimisation). Attached is an ARM Thumb assembler (for Pico-Arduino) TMS9900 simulator that @250MHz does 6MIPS for the NOP loop, and 3MIPS average. @PeteE This contains a dump of your CPU Test program - let me know if that's not OK and I'll remove the archive. Various tests/results, disabling some of the debug code which can slow it down... Spoiler OP_COMP_B... //B NOT_VIDEO ... run9900 (mem, 0x6026, 0x8300, buf); Starting ALL TESTS OK! cnt = 2983507 cnt = 2994788 cnt = 2994841 *********************************** OP_COMP_B... B NOT_VIDEO ... run9900 (mem, 0x6026, 0x8300, buf); Starting cnt = 3007635 cnt = 3018304 cnt = 3018614 *********************************** OP_COMP_B... B NOT_VIDEO ... run9900 (mem, 0x0000, 0x8300, buf); Starting cnt = 1747169 cnt = 1753535 cnt = 1753615 This seems slow, because every JMP returns to the loop.. ..See the next use case without returning to loop *********************************** I_JMP: //MOVS R1,#0xFE //SXTB R1,R1 //CMP R0,R1 // Does this jump to itself? //BNE I_JMP_g //BL ret9900 // Then quit the emulation I_JMP_g: ... OP_COMP_B... B NOT_VIDEO ... run9900 (mem, 0x0000, 0x8300, buf); Starting cnt = 6344628 cnt = 6367260 cnt = 6367567 *********************************** Removing the instruction counter: start: //ADR R0,instscnt //LDR R1,[R0,#0] //ADDS R1,#1 //STR R1,[R0,#0] Should provide a bit of a kick in performance too. TMS9900A.zip 4 Quote Link to comment Share on other sites More sharing options...
PeteE Posted July 13 Share Posted July 13 6 hours ago, JasonACT said: @PeteE This contains a dump of your CPU Test program - let me know if that's not OK and I'll remove the archive. That's okay with me, no worries. 1 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 14 Share Posted July 14 13 hours ago, PeteE said: That's okay with me, no worries. Cool, thanks Pete. I spent the day cleaning up the code, using the ARM's features a bit better, and in-lined the few calls being made... Starting ALL TESTS OK! cnt = 3339603 cnt = 3351589 cnt = 3351614 cnt = 3351584 So +10% TMS9900A.zip 4 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 14 Author Share Posted July 14 (edited) Looks good, @JasonACT Just wondering - what is the end condition? As in what causes run9900() to return? Edit: NM found it was a jump to self that triggers it. Also, would be nice to have a way to map the ram to various locations, though I understand that would add significant overhead. Edited July 15 by visrealm 1 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 15 Author Share Posted July 15 (edited) They were so close. Edit: Now it's back at Adelaide Airport... where it was last Thursday. I hope they're not flying it back to China Edited July 15 by visrealm 2 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 15 Share Posted July 15 17 hours ago, visrealm said: Also, would be nice to have a way to map the ram to various locations, though I understand that would add significant overhead. Could you use a struct to put all the pico C things that are to be shared in the right place & top it off with RAM up to the 64KB limit that the GPU can see? MAP: 18KB (F18A style) 2KB VDP Registers 44KB (fill) and pass the single pointer from the start, to the GPU routine? And use 2 pointers for your own code, the Low RAM and the Registers? I took a look at the F18A register list today, and was wondering how much the Pico could reasonably do? Maybe @Asmusr has thoughts on what's important (I recall a comment about more GPU memory - which this does)? I have no idea what else is important though. 2 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 15 Author Share Posted July 15 11 minutes ago, JasonACT said: Could you use a struct to put all the pico C things that are to be shared in the right place & top it off with RAM up to the 64KB limit that the GPU can see? For performance, that would probably be the best bet. I'd have to change my TMS9918 library to accommodate being told where things are. 12 minutes ago, JasonACT said: I took a look at the F18A register list today, and was wondering how much the Pico could reasonably do? It could do all of it. But how much at one time (in one scanline)... not sure. Given the current VRAM restrictions, software is limited in what it can do at one time as well though... I'm not too worried about it at this stage. Just something to try out in the future. 2 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 15 Share Posted July 15 21 minutes ago, visrealm said: For performance, that would probably be the best bet. Yeah, agreed, sadly. 38 minutes ago, visrealm said: Given the current VRAM restrictions, software is limited in what it can do at one time as well though... With 44KB contiguous code space and 2KB stack space, and direct access to 16KB VDP RAM... GCC could compile some awesome games for it, even without any other F18A features being implemented. The poor old '99 TMS9900 left doing just mediocre tasks though I have mixed feeling about it. Then there's the extra/modified F18A instructions, I can help implement them, but I kind of like the workspace pointer working like it should instead of being fixed. So more mixed feelings. Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 15 Share Posted July 15 (edited) I'm about 1/3rd through a final walkthrough of the code and there's a bug in one of the few untested instructions... I_BLWP: LDRB R0,[R5,#0] // R5=SRCE shouldn't be load register byte, but should instead be load register halfword... I_BLWP: LDRH R0,[R5,#0] // R5=SRCE 3 hours ago, JasonACT said: but I kind of like the workspace pointer working like it should Hmmm. Yes. EDIT: Looks like I'm missing adding the R8 memory offset too for that instruction, something extra to do then. Attached, what I think should work - and fixes a bunch of TODOs, BLWP and RTWP (all except the +2 ones - which I don't really care about). TMS9900A.zip Edited July 15 by JasonACT 3 1 Quote Link to comment Share on other sites More sharing options...
aotta Posted July 17 Share Posted July 17 (edited) First tests of pcb 0.3 with Colecovision (in this case, a Secam version): Ok with VGA output and with RGBtoHDMI (using C-sync): but since now the C-sync seems not working with scart output.. i'll do some more tests. But, the Pico9918 logo in the bottom-left corner, stays there forever?? i thought it was only a sort of "splash" screen Thanks again to @visrealm for sharing this great project!! Edited July 17 by aotta 7 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted July 17 Share Posted July 17 On 7/14/2024 at 8:53 PM, visrealm said: Now it's back at Adelaide Airport... Wow, I thought only the US postal service was this incompetent. 3 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 18 Author Share Posted July 18 (edited) 14 hours ago, aotta said: First tests of pcb 0.3 with Colecovision (in this case, a Secam version): Ok with VGA output and with RGBtoHDMI (using C-sync): but since now the C-sync seems not working with scart output.. i'll do some more tests. But, the Pico9918 logo in the bottom-left corner, stays there forever?? i thought it was only a sort of "splash" screen Thanks again to @visrealm for sharing this great project!! Fantastic! So glad it's working for you and it's awesome to see it working on something different Awesome! The PICO9918 splash will be more splash-like in the next firmware version. In other news, my component order finally arrived after its "Tour Down Under". I've assembled a v0.4 board and it's showing signs of life, but still not fully functioning. BOOTSEL is working when I plug it into my PC, I can drag and drop my firmware image onto it. That's a great start. However it doesn't run. So, to narrow things down, I've done a "no-flash" build which copies the image directly into the RP2040 SRAM and that works! So it seems the board is mostly functioning, but I have a problem with the flash. I'll have to do some digging to work out what's going wrong, but at least the board does work (in ram mode). It's a start. And given this is my first custom RP2040 board, I'm pleased it is somewhat usable already. Edited July 18 by visrealm 8 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 18 Share Posted July 18 Don't get me started on external serial memory chips not behaving like they should. Anyway, that's very positive news, thanks for the update! I've implemented most of the extra F18A GPU instructions now (all, except the SPI Flash ones, which I don't think add anything useful here). I had to break out of the assembler and back to C for the complex part of the PIX instruction (XOP) but if it ends up being too slow, I may try to convert it. Attached. My final words on this.. Having read the documentation more closely, I feel there's a lost opportunity in the memory map of the F18A being spread out like it is. But it is what it is, and can probably have two modes to make it better (original vs compressed register spaces). Keep up the good work TMS9900A.zip 5 1 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 19 Author Share Posted July 19 (edited) 19 hours ago, JasonACT said: I've implemented most of the extra F18A GPU instructions now (all, except the SPI Flash ones, which I don't think add anything useful here). I had to break out of the assembler and back to C for the complex part of the PIX instruction (XOP) but if it ends up being too slow, I may try to convert it. Thanks, Jason. Appreciated. I'll look further into this in the next week or so. Once I hit some hardware roadblocks, I'll go back to looking at software. 19 hours ago, JasonACT said: Don't get me started on external serial memory chips not behaving like they should. I hit up Digikey for some Winbond flash chips in the same footprint. Hopefully I have better luck with them. Edited July 19 by visrealm 2 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 19 Share Posted July 19 (edited) 5 hours ago, visrealm said: I hit up Digikey for some Winbond flash chips in the same footprint. Hopefully I have better luck with them. The Arduino-Pico package has boot2 files for 7 different flash memory chips (since Earle supports many different boards) - most have div2 and div4 versions (a couple only work at the slower div4 speed though). Have you looked at the specs. for the chips you bought? Something just may need to be tweaked? Edit: If you happen to have the same chip as one he supports, you could try out a simple test sketch. Edited July 19 by JasonACT 3 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 20 Author Share Posted July 20 I'm currently using a IS25LP016. It should be compatible with the IS25LP080 boot2 driver, but doesn't seem to work. Possibly something else awry with the pcb. Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 20 Share Posted July 20 2 hours ago, visrealm said: I'm currently using a IS25LP016. It should be compatible with the IS25LP080 boot2 driver, but doesn't seem to work. Possibly something else awry with the pcb. Someone says they do work, maybe only at div4 speed though: https://forums.raspberrypi.com/viewtopic.php?t=335788 Earle also made a code fix last year: https://github.com/raspberrypi/pico-sdk/pull/1430/commits/e40417acaeaec80069c8e1ed3a6473ce870458d9 Though the "text" vs ".text" change doesn't appear to be applied at present - maybe try adding a "." to your file? (And yes, I'm confused. No, wait - it's only in the develop branch.) 1 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 20 Author Share Posted July 20 29 minutes ago, JasonACT said: Someone says they do work, maybe only at div4 speed though: https://forums.raspberrypi.com/viewtopic.php?t=335788 Earle also made a code fix last year: https://github.com/raspberrypi/pico-sdk/pull/1430/commits/e40417acaeaec80069c8e1ed3a6473ce870458d9 Though the "text" vs ".text" change doesn't appear to be applied at present - maybe try adding a "." to your file? (And yes, I'm confused. No, wait - it's only in the develop branch.) I had tried most of the things there already - I was trying to set those -D values in the CMakeFiles.txt. I had applied the patch manually. That post you linked included a link to Custom board - code not executing - Raspberry Pi Forums which also suggested setting PICO_XOSC_STARTUP_DELAY_MULTIPLIER to 64. It's working now! That's awesome. Thanks for the pointers. I think, going forward, I'll stick to the Winbond Flash chips to reduce headaches for anyone wanting to build their own firmware. 3 Quote Link to comment Share on other sites More sharing options...
visrealm Posted July 20 Author Share Posted July 20 (edited) Well. Here it is! PICO9918 v0.4 finally working. Apologies in advance for the vertical video Works great! Got the blinkenlights. Much lower profile than v0.3. Big thanks to @JasonACT for helping with the flash issue. Appreciated, mate. @aotta you'll notice the PICO9918 version splash is much splashier here Edited July 20 by visrealm 2 1 Quote Link to comment Share on other sites More sharing options...
JasonACT Posted July 20 Share Posted July 20 19 minutes ago, visrealm said: Much lower profile than v0.3. Very nice. Congrats 1 1 Quote Link to comment Share on other sites More sharing options...
Gary from OPA Posted July 20 Share Posted July 20 29 minutes ago, visrealm said: Well. Here it is! PICO9918 v0.4 finally working. Apologies in advance for the vertical video Works great! Got the blinkenlights. Much lower profile than v0.3. Big thanks to @JasonACT for helping with the flash issue. Appreciated, mate. @aotta you'll notice the PICO9918 version splash is much splashier here Great news... Looking forward at some point to get one of these 0.4 babies to try out in Canada. 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.