 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PICO PETSCII
  Page 28 of 38   |
|||||
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
Hi folks, Thanks Phil, I believe the 150R is to protect the fire button on the Atari Joystick and ensure its pull-down works on GP14 even though that pin is also attached to 3v3. I do not believe any variants other than standard NES, SNES and Atari joysticks are catered for. Thanks Bill, I'm glad I didn't suggest it was "nonsense" then  . Though I still assert it isn't necessary, I've tested at least 4 different designs (well chassis, they all seem to be an indistinguishable epoxy blob inside) of clone NES controllers.Hi Martin, When the cheap clone you ordered arrives (and assuming it isn't really SNES) I'd appreciate a photo of the internals. I've been talking with @Mixtel90 about the possibility of a PCB that we can use to retrofit the cheap clones to be proper SNES compatibles, but we need to identify the best chassis to build upon. I have some ideas about that but was going to wait until things were more stable. Regarding the controller and keyboard code, I keep trying to kick that into shape, but you guys are releasing new version faster than I can keep up. If I can back seat drive, then for maintainability and to simplify the addition of future control schemes (e.g. SNES, Wii Classic, KEYDOWN and PS2 keyboard) I recommend you change the code to contain the following four functions: Function get_input$() get_input$ = get_inkey_input$() If get_input$ <> "" Then Exit Function If gamemite_flag% Then get_input$ = get_gamemite_input$() ElseIf nes_flag% Then get_input$ = get_nes_input$() EndIf End Function Function get_inkey_input$() ... End Function Function get_gamemite_input$() ... End Function Function get_nes_input$() ... End Function Where the latter three functions do all the necessary jiggery-pokery to return one of these strings: "up" "down" "left" "right" "fire_up" "fire_down" "fire_left" "fire_right" "search" "move" "map" "use" "toggle_weapon" "toggle_item" "cheat" "kill_all" "lure_robot" "music" "" - the empty string for no input All the client code should then be updated to use get_input$() and these strings so that it is self-documenting and no longer tied to any particular key combination or controller. If you want, then at a later date as an optimisation, these strings can be replaced by inline integer constants; but compared to other things going on those string comparisons are pretty cheap. Also I suggest separating an lcd_flag% from the gamemite_flag% with the former being used for making decisions regarding the display and the latter being used for decisions regarding the controller. YMMV, Tom Edited 2023-11-15 20:18 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9128 |
Any reason not to look at the Wii classic. Easy to interface (only two pins) with and if appropriate I could copy the CMM2 drivers into the PicoMite. Then any cards would just need a Wii edge connector like the CMM2 Edited 2023-11-15 19:45 by matherp |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
The only reason is, I don't have one here, so I can't build that in. (still waiting for my SNES Controller and, I think i have to Order another one with original plugg) . Just googled, you talk about something like this?  That would have even more controllers and buttons than we need for the game. It would certainly be a nice addition, but you don't know how many people actually use it or are willing to use it on the Pico. But if we can include the option in the selection of controllers, it makes the whole thing more flexible. Edited 2023-11-15 20:36 by Martin H. 'no comment |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
Hi Tom, I've already thought about ordering another clone with original connector. Then solder an addapter that connects the original socket to a DSUB plug for the Pico game board (exactly how the NES controller is connected). Then it would be open to everyone SNES controller with original connector. (Like they did it for the ATARI 800 Version). That sounds good, doesn't it The more you standardize it, the more It would be easier to adapt to other input devices. BUT without overengeneering the whole thing. Keep it simple as possible. The reason why we are releasing new version faster than you can keep up is, that this forum entry is what we communicate with during development, here come questions, improvements and some things are discarded. So it's still being developed and the communication is happening right here. You're right, of course, not everything that has LCD is a Game*Mite The detection won't stay that way, only at the moment I only have 2 versions to test here: Pico Mite VGA with Mixtel90s PicoGame VGA Board and the Game*Mite So look as the current state not as final, but more of a snapshot. For the LCD Guys (Lance, Kevin, you and me) it works at the Moment. I am grateful for any support. I borrowed parts the codes for NES from your PicoGame test program And from the GameMite programs  Cheers Martin Edited 2023-11-15 22:00 by Martin H. 'no comment |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 510 |
Hi Peter, Had a free few minutes, the new background blit works fine but it doesn't help with the tearing, presumably it is still not able to complete before the updated word is starting to be re-drawn, I think the only possible fix is what I did in the pet24cMod several posts back, but I've had no feed back for anyone who was complaining about screen tearing, so I don't know? Hopefully Harm will be able to make the change in his VGA and confirm that it is not having any bad side effects, in which case the world drawing code can stay in it's new location permanently and will be used by both VGA & LCD. Because the new Blit is happening in the background, I can't even tell if it's made a bit of an improvement, but I assume it will, as it's doing less work, unless the overhead of the extra parameters makes it overall less efficient? Presumably it will be at it's fastest if everything is on a byte boundry? Regards, Kevin. Edited 2023-11-15 22:24 by Bleep |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9128 |
It is probably possible to eliminate tearing by reading the current scanline and timing the merge accordingly. The problem with this is that it is display specific. I have had it working in the past on the ILI9341 but failed to get it to work on the ST7789_320. And, of course, it can work on displays that don't implement the MISO pin. I'll have a play with the ILI9341 and post a test version once working |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
I didn't complain... I tested the mod Version yesterday, for me this was perfectly acceptable, but I didn't really mind the slight offset when scrolling. IMHO, the best option for LCD would be to transmit as little as necessary, as the serial port is the bottleneck. There would still be the possibility to redraw only changed tiles, instead of copying the whole screen. The computation would cost a little more CPU, but it would require a lot less transfer. comparing two integer Arrays one holding the last 11x7 tileadresses and the other the new 11x7 tileadresses. The Array for the New Tiles can be filled in the Sub that refreshes the screen (SUB Writeworld_n , number is in tile_index(SPN) ). (Source addresses, not the tile numbers, as this does not change with animated tiles) only the Tile where the Player and other Sprites are placed should be refreshed by every frame (animation) By comparing the new Set with the Previous set, you get the info, if this Tile has changed and if so, copy the 24x24 block from framebuffer to Display. When done copy the new buffer to old. and go on with the Program. In the worst case (everything has changed) you have to transfer 11x7 tiles, but that's exactly the amount of data you're transferring at the moment anyway (only in 77 parts). Edited 2023-11-15 23:50 by Martin H. 'no comment |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4043 |
I wonder if this is one of those MMBasic optimisation cases where your initial reasoning (based on non-interpreted languages) lets you down because all the logic to "make it faster" has to be implemented in MMBasic whereas the brute force approach is faster because it's all compiled C. YMMV. Best wishes, Tom Edited 2023-11-16 00:00 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
but even compiled c doesn't get the serial port faster, and the process of copy data to lcd is still in C on 2nd CPU (if I understood correctly). The transfer of 24x 24 pixels (288 bytes) should easily manage the 2nd CPU and the display until the next copy command from Basic comes 'no comment |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9128 |
Sorry but this isn't the case, you don't want to waste any cpu cycles like that. Timings for an SPI ILI9341 on a GameMite at 252MHz are: timer=0:framebuffer merge 14:?timer 74.824 timer=0:blit merge 14,50,50,264,168:?timer 43.949 Given that all this takes place on the 2nd processor there is absolutely no advantage to trying to be clever with updates. The only issue is whether I can find a way of coordinating the update with the frame sync which would eliminate tearing. |
||||
javavi Senior Member  Joined: 01/10/2023 Location: UkrainePosts: 218 |
Incorrect operation of the NES joystick due to the incorrect order of parsing control data |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9128 |
Kevin or anyone else with a ILI9341 setup, please try this PicoMite.zip |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4247 |
Hi Kevin, Your change does not seem to have a negative side effect on VGA as far as I can see. As I understand you moved one section to a different location in the main loop. And that made the difference. It is hard for me to understand why, and I hope it is not very timing related since not all game play is in yet. But I am driven to make this work good for the LCD, so I will prototype this change in the comming pet24eMod.bas I sure hope you did not change more, that I missed. Since it is easy to make a mistake that kills the whole thing. When the testers agree this is the way to go, then that will be it. pet24eMod.zip pet24e.zip Regards, Volhout Edited 2023-11-16 01:56 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4247 |
Martin has pointed me to an update for the NES controller. Please check if I implemented it correctly in pet24e.bas -or- pet24eMod.bas Regards, Volhout Edited 2023-11-16 01:58 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
Hi javavi thank you for your objection not real, the Order i used is the order, the NES Controller shifts the Bits serial to the Data Port, so this is fix. But I can change the order, how I read the digital ports on the Game*Mite, because there the order depends on my query. so that both functions return the same output$ and"select case" gets equal values. Of course there is still room for optimization, it was important to me, at the first place, that it worked at all. 'no comment |
||||
| javavi Senior Member Joined: 01/10/2023 Location: UkrainePosts: 218 |
For the NES joystick to work correctly, I simply changed the sequence parsing order Or you need to change the bit scanning direction in the input procedure Select Case c$ Case "DOWN " : c2k$=Chr$(129)'down Case "UP " : c2k$=Chr$(128)'up Case "LEFT " : c2k$=Chr$(130)'left Case "RIGHT " : c2k$=Chr$(131)'right Case "BUT-A " : c2k$="m" 'A Case "BUT-B " : c2k$="z" 'B Case "START " : c2k$=" " 'Start Case "BUT-A BUT-B ": c2k$=Chr$(9) 'Tab Case "BUT-A DOWN " : c2k$="s" 'Fire Down Case "BUT-A UP " : c2k$="w" 'Fire Up Case "BUT-A LEFT " : c2k$="a" 'Fire Left Case "BUT-A RIGHT ": c2k$="d" 'Fire Right Case "BUT-B UP " : c2k$=Chr$(145)'F1 Case "BUT-B DOWN " : c2k$=Chr$(146)'F2 Case "SELECT " : c2k$=Chr$(27) 'ESC End Select Edited 2023-11-16 02:20 by javavi |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
Tested the pet24eMod on the Game*Mite The image when scrolling is, from my point of view, completely sufficient. I have nothing to complain  Edited 2023-11-16 02:28 by Martin H. 'no comment |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
Bit SNES NES 1 . B A 2 . Y B 3 . Select Select 4 . Start Start 5 . Up Up 6 . Down Down 7 . Left Left 8 . Right Right 9 . A 10. X 11. L 12. R I think. :) Edited 2023-11-16 02:31 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9128 |
Please could you try with the firmware just posted above - thanks |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1114 |
yes, i think that would work untested.. Function nes_input$() Local m$(7)=("BUT-A","BUT-B","SELECT","START","UP","DOWN","LEFT","RIGHT"),bit Pulse a_latch, pulse_len! out=0:cs$="" For i=0 To 7 If Not Pin(a_dat) Then out=out Or 2^i Pulse a_clk, pulse_len! Next For n=7 To 0 Step -1 bit=2^n:If out And bit Then Inc cs$,m$(n)+" " Next nes_input$=cs$ End Function should return the string the same output order as the Game*Mite. so that the double "Case" statements are obsolet. Will test it when Im back n the VGA Version. Right now I just have the LCD Game*Mite here and it doesn't use the NES Controller 'no comment |
||||
| Page 28 of 38 |
|||||
 Print this page |
