Jump to content

jedimatt42

+AtariAge Subscriber
  • Content Count

    2,978
  • Joined

  • Last visited

  • Days Won

    3

jedimatt42 last won the day on May 7 2017

jedimatt42 had the most liked content!

Community Reputation

3,318 Excellent

2 Followers

About jedimatt42

  • Rank
    River Patroller
  • Birthday 05/15/1973

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Beaverton, OR
  • Interests
    Programming, old and new.
    The world of Arduino.
    My TI.
  • Currently Playing
    Mousing around on my TI-99/4A

Recent Profile Visitors

16,551 profile views
  1. When you feel better, the direct link posted at the top of this thread has the entire video, so no need to record them. You can select to play the live chat back as well.
  2. Yep, it goes black, so reading the datasheet, that is most likely what happened. I didn't explore this morning In Force Command, I have a color command... so I can just type COLOR 15 and all my text becomes white again All as designed... my intention is to use before the screen is setup, so everything will be healed and the VDP type will be held.
  3. My plan is to rewrite my TELNET as an extension of Force Command. Existing TELNET client will stand as is, as delivered with TIPI - it isn't for BBS'ing, it is for TIPI management. I'm totally unaware of MyTERM and PORT. I'm not a BBS'er, so I haven't explored terminal emulators that exist on 4A and 4A adjacent platforms. I'd be more interested in supporting the color attributes for programs I write as extensions of ForceCommand. Force Command's API supports sending ANSI codes to the display, but presently, color is ignored for 40x24 mode, and the F18A is utilized for 80x30 mode. I managed to get mame setup as a EVPC 4A. So I can test... but I can't read a status register to save my life... (spoiler, I figured it out by explaining it to you all) I have C code that reproduces the algorithm @InsaneMultitasker suggested. Worked great. But trying to implement @mizapf suggesting, which I like as it doesn't write, and just seems simpler... But this code, generated from gcc just isn't doing it: detect_vdp ; wrong port number --- li r2, >8C00 ; load up VDPWA port li r2, >8C02 ; load up VDPWA port li r4, >48F ; select status register 0x04 movb r4, *r2 ; -- push the 0x04 to VDP swpb r4 movb r4, *r2 ; -- push the 0x8F (write to register 15) to VDP movb @>8802, r1 ; Read from status register port li r3, >8F ; select status register 0x00 to restore prior state movb r3, *r2 ; -- push 0x00 to VDP swpb r3 movb r3, *r2 ; -- push write to register 15 to VDP srl r1, 8 ; convert the byte in top of r1 to an int for C. b *r11 On the evpc, I get 0x0084, on the normal 4A I get 0x009F both in mame. I'm in 40 column mode already, so there are no sprites.. I would have expected the 4A to return nothing greater than 0x1F. And as was said, the 9938 should have returned 0xFF or 0xFE limi 0 is the state of affairs, and garbage ends up on the display.. so I feel like I'm using the wrong port to write to the register... 00ops, yep, that is it... Ok, now I get 0xFE on the EVPC, but on the 4A, I can't read what I get cause the screen gets turned off... Probably not a problem if I detect prior to setting up the screen. Oh, well... now I'm late for the day job... at least there is no commute. Thanks!
  4. Or better yet, google the original 9938 context: https://www.msx.org/forum/development/msx-development/properly-detection-msx-vdp-type [email protected]
  5. I don't need smooth horizontal scrolling, so I don't need to know 9958 vs 9938... - and I already detect F18A, so just detect for that first... use best mode if detected... then detect Yamaha, use that if detected, or fall back on 9918. The yamaha chips will set a status bit if there is a 9th sprite on the same line as 8 others. A 9918 will set that bit at the 5th sprite. Probably have to wait for vertical blank interrupt to know that the VDP has observed the situation.
  6. I'll add @BeeryMiller, I would like to support 8838 80 column mode. I do test in Mame and classic99 often enough that it would be nice... I don't know off hand how to detect 9938/58 - I do recall some chatter in the F18A threads about it though... - I assume I could use the 9th instead of 5th sprite limit to detect.
  7. We got these details... recently. I've changed my mind, and Sunday is back on for the regularly scheduled Zoom from my point of view. There is never too much TI time.
  8. My intention is that it degrade gracefully when optional hardware is absent.
  9. Seems like a lot of hours for one weekend to me. But for those of you with the password, the resource is there.
  10. Ok, I finally found when the date was shared with us... So to be specific, no Zoom call this weekend. Although I am not going to stop you if you do. Reads like if you are attending the Faire, you should know that time frame already, as you will have had private email exchanges.
  11. When ever we know when the Chicago virtual Faire will actually be, my intention is to _not_ have the weekly Zoom call that weekend. ( assuming it is a weekend still )
  12. Paid members get the big 'Subscriber' logo over their left column joystick ranking.. I'm sure in context, people can tell he is talking about the tomy tutor keyboard pcb, instead of the 99/4A USB keyboard adapter.
  13. I created a couple issues about this in the github repo... silence... The readme is worthless. I'm pretty sure most of what is in there has nothing to do with what is actually available on the MiSTer implementation. I enjoy the MiSTer for platforms where my retro hardware isn't as good as the FPGA version... not the case with my 4A.
×
×
  • Create New...