aotta

Ca va sans dire.... it works!! Thank you as always!

Thank you @nanochess, now it's clear to me that vpoking at $2xxx addresses change the whole character color, not the color of character at screen "+X" position! So, i suppose that for having a single word hilighted within a text, i had to define a second char set and use it when needed, right? maybe i'll have to NOT the charset in different position as you ORred the char for bolding font in your example. About SC-3000 joystick, you're right again: i made a rough patch adding this code before using "count1": c=cont1 while c=0 wait asm di asm ld a,$92 asm out ($df),a asm ld a,7 asm out ($de),a asm in a,($dc) asm ld ($a000),a asm in a,($dd) asm ld ($a001),a asm ld a,$92 asm out ($df),a c=cont1 print at 32*23+20,c WEND Strangely, it works with keys "1,Q,A,Z,"Jap" and "," (the Row 0 in keyboard matrix) even i set 7 (the joystick row) in $de command as suggested in SC-3000 manual. But for sure i missed something, i'll continue testing. Thank you again for your work and your support!

I know i'd learn how to use the VRAM tables, but it's first time i'm programming a Sega console (thanks to CVBasic) and i'm lost in trying to highligth (change color reversing it) a text line in mode 0... Is it possible to have a "PRINT AT nn COLOR" like in Intybasic, or something similar? I'm getting crazy VPOKing around $2000 with no success 😅 And, just as note, CONT commands don't work on SEGA SC-3000 (may be because he use keyboard key to duplicate joystick command, so use some different coding?)

Yes, it fixed and now WAIT works fine on my real Sega HW! Thank you again for all your work! 🙏

i tested a SG-1000, a SC-3000 and a MarkIII

I'm doing my first (very basic) tests with CVbasic for Sega SG-1000, it works fine with emulator but i found an issue when using the rom code on a real hardware: the "wait" command (i think translated with HALT cpu code) hangs the console and freeze. I don't know if is it a bug or i missed something....

Thank you @YannAros for the pictures, very different M/B from others Inty, i hope to find someday one of these fast SECAM to play with!

SECAM console seems a bit faster than other console (it seems they use a 4mhz quartz instead of the 7.158Mhz div 2) and even RTO for SECAM had to use a longer delay (about +30%) as found by zx81zx81 on his github repository. I have no SECAM console to test, but i guess that adding a 30% "nops" in the #define delWR and #define delRD in first line of PiRTO.ino code, it should do the job. If you see only some ".bin" files, the file listing routine it's interrupted by some reading error, and most probable is a long filename or some strange char in filenames. Check also hidden files, i skip some system folders used by windows and Mac, but there aren't many check, it's easyer to put clean files in the SD than consuming RAM for testing and avoiding weird uploads! I also suggest using DriveSort or other sorter utility for having an ordered list in PiRTO, since the program doesn't sort filenames.

Yes it's very simple if you have the Pico board already installed on Arduino IDE, and if not you'll find a lot of tuts on internet for it. From pictures, it seems the pins hole on some of the sdcard module are a bit burnt, i don't know if the traces are still ok, and it's impossible to check it since the board is reversed after soldering. You can also check if you have 5v and gnd on break-out modules at first, in my first version i used 3v3 for powering modules and i got the 4 led flashes.

When buying from aliexpress, it's good practice to test item before soldering. I don't think you broke all 4 breackout module, but they could be all DOA. Have you isolated sdcard pins from PICO bottom board? i used some tape for safe, if pins are too long they could short with Pico board. Are the board soldered in correct way (like picture in my github)? Please post a picture of your work, it could be useful for finding if something wrong in assembling. One of my Italian friend has same issue, i suggested him to check sdcard module with Arduino IDE example "SD->CardInfo", changing the SPI pins with the ones used by PiRTO: const int _MISO = 16; // AKA SPI RX const int _MOSI = 19; // AKA SPI TX const int _CS = 17; const int _SCK = 18; If also CardInfo doesn't recognize the card, something is not working!

I used M2,5x16mm screws, and heated a little them with iron soldering tip for an easy screwing

From a quick look at the code, the name should be within 54 chars without suffix, and not greater than 59 chars. But names' matrix is also used to show menu on Inty's screen (with some memcpy() command that should be reviewed), and names on Intellivision's menu must be shorter than 20 chars. But, above all, i'm not interested in supporting long filenames (i hate PD and HB names with tons of ((())) with years, authors, notes and so on! 😁) and continue suggesting to rename the filename in a shorter and clearly way

It's not because the special char, but due to too long name. When the filename lenght overflow the array lenght, it stop reading directory. Just avoid too long name, remove intellivision lives and enjoy the game!

i use RGBtoHDMI too for "perfect pixel" HDMI video for my Intellivisions (and other dozens of retro systems). Only 6 wires to solder on back of STIC IC

Ah, good old time! 😂

Interesting! i realized just now there's the C17 capacitor on Inty II that might "vary" the clock freq, and it could be reasons why i get some different behaviour from different consoles! (i also discovered just now reading the Inty II service manual about not to use ferrous adjustment tools on RF modulator's core, that's why i have no more video from it! 😁)

@Crash7 i don't want reopen the discussion about your RTO, but i apologize didn't remind you already tested it with an Inty II. Well, RTO and PiRTO definitely work on Inty II, if your doesn't that may be for several reasons (and DOA products happens for new and featured goods too). I didn't write "not for use with SVA" because i don't know if it so. All DIY projects are with no guarantee for default. Noone on Github remind users to not use while having a bath or or soaking them in coffee, since they aren't commercial products but projects by enthusiasts for enthusiasts.. I do not have to convince anyone to buy my RTO, it is a gift I have given to the Intellivision community, and I have had the accolades from those who have the expertise and intellectual honesty to admit the usefulness of my work. 5-11under produced a small batch of RTOs for those who were unable to do it themselves or did not have a friend who could solder some boards. Given how much a teensy4.1 costs, I don't think he bought himself a Ferrari with the earnings, and that he was making a DIY project (albeit slightly modified) he made that clear right away. I imagine he tested the RTOs before shipping them (but I'll leave him to confirm) so I don't see what other blame to place on him. All we have seen @5-11under's video with his working PiRTO on an intyII, i could suggest him to stop this silly RTOwar and that he could think on a special discount for @Crash7 for it?

Well, RTO and PiRTO are GI Rom emulator, and they works fine in all Intellivisions i and my friends tested them. But, it use computed delays to emulate the CPU BAR/ADAR/DW etcs cycles, that are different depending on the console CPU clocks, and so by the Quartzs that are used on the consoles. Since NTSC, PAL and Secam consoles use differents Quartz oscyllators, the timing its a little different from console to console. RTO use the much faster Teensy 4.1 MPU, so it works fine in both my NTSC and PAL consoles, but a French friends had to change the delay for its Secam one. With the slower RP2040 used by the PICO, i had to write different code with different delays for having working PiRTO for my INTYs II NTSC and my PAL Intys. So, there aren't compatibility issues, but the code in bot RTO and PiRTO may have to be adjusted for each kind of console. I don't have any 2609 NTSC console, so i can't test it, but there is no theoretical or logic reason why it should be different from others NTSC machines, if it use the same quartz clock. Same considerations value for Sears SVA consoles. RTP and PiRTO are free multicard that everyone has a bit of HW and SW knowlege could assembly himself, and since now i got dozens of positive and gracefully feedbacks from guys all over the world (well, most are from Italy and EU). The only non working RTOs I heard were NON working RTOs (bad PICO, bad 74lvc245 ICs, bad soldering). So, i don't know if the xxRTO work on all intellivisions of the world. But i was thinking about the Donkey Kong and Carnival carts that don't work on Inty II consoles, but noone spent so many time in asking Coleco to publish videos of the game working!

@Crash7: two weeks ago i bought on ebay a second NTSC Inty II for 27$, for testing my PiRTO: why don't you buy a true Intellivision too, instead of getting angry because the RTO doesn't work with your Super Video Arcade?

The videos are about 4 different Intellivisions... but... Who need help? 😂

@Crash7, RTO and PiRTO works for dozens of user with Inty I & II in NTSC, PAL & Secam tv systems. It's a DIY homebrew project (even if 5-11under sold a little batch of his variant of the RTO) and it seems not to work with SSVA and SPS later version of Intellivision, as you learnt yourself in the worste way. If one day i'll have on my hands a SSVA or a SPS i'm sure i could find a solution, but they seems quite rare, almost here in Europe. 5-11under offered you the refund, afaik, so i think it will be more interesting for all talking here about new PiRTO and stopping the children's squarrel about the video.

No it's the final 1.0 version, but may be considered an experimental project since the Pico is far slower and less reliable than Teensy used in original RTO, so different delays are needed for Pal, Ntsc (and Secam i presume, but not tested yet) and fine tuning in timing seems necessary for some others console too. It's a DIY project for a 25$ intellivision multicart, that was the goal of the porting to Pi Pico project, and I'm afraid it's not possible to squeeze more from that cheap board. Minor fixes may follow, and source is open source, so anyone may improve the project!

Yes, the same i soldered too and sent to trash!! 😂