jedimatt42

I'm 47 now, so my average age since I've been here (starting in 2015) is 44.5 ( 42 + 43 + 44 + 45 + 46 + 47 ) ------------------------------- 6

I'm used to starting with WinCUPL... I managed to desolder one of the TI chips from the board... man those are tight against the PCB... resorted to hot air after the de-soldering tool wasn't good enough... Sadly I only have one socket on hand... but I did find a stock pile of ATF16V8... JED2EQN sounds interesting... gonna have to take a look at that. ( except you need a retro computer to run it )

Have the people saying 'yes' actually looked at the cost and effort of building one of these? The PCB is the cheap part. and effort.. 3d printed parts, paint, finishing. if you don't have a 3d printer, people charge a ton to do that for you cause it is amazingly fiddly... can fail 90% through a 2 day print. finding appropriate key-caps, time for relabeling key-caps cause you can't find appropriate ones. cost of the key-caps, switches... And then the part where there is almost no reason to use more than a handful of keys on the keyboard... Just saying, as this thread is extremely light on substance. But... if you are Tomy Tutoring, you have disposable income. So.. whatever... Some substance... at JCLPCB.com, I paid about $25 dollars for a set of 5 pcbs. And about $30 to ship them DHL. It is basically the same price for a reorder of 10 pcbs. The manufacturing details: Gerber file: TutorKeyboard_Y2 Build Time: 2-3 days Layers: 2 Dimension: 297 mm* 127 mm PCB Qty: 5 Different Design: 1 Delivery Fomat: Single PCB PCB Thickness: 1.6 Impedance: PCB Color: Green Surface Finish: HASL(with lead) Copper Weight: 1 Gold Fingers: No ( Yep, with lead. You can pay more to be poison free )

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.

I might need the humor explained to me...

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.

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!

Or better yet, google the original 9938 context: https://www.msx.org/forum/development/msx-development/properly-detection-msx-vdp-type [email protected]

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.

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.

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.

My intention is that it degrade gracefully when optional hardware is absent.

Seems like a lot of hours for one weekend to me. But for those of you with the password, the resource is there.

| \-----------------------\ | v

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.

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 )

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.

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.

The qwerty parts should line up, but they don't. Inverting doesn't help. And there is a Pin 3 N/C on the coco keyboard that is a show stopper.

surely there exists the keyboard matrix diagram for the tutor, and the keyboard matrix diagram for a coco, and the 2 photos to build a mapping between them. A simple paper exercise should be able to answer the question. This is the matrix for the US Tutor: https://docs.google.com/spreadsheets/d/13M2gNuDQY2LgcgtXt4RwmUT4cyrAZYNVGBDHmFdoqfs/edit?usp=sharing Idk if the coco matrix varies from machine to machine:

Yep, it is subjective. My experience involved learning to design a keyboard matrix pcb, and mapping out the existing - I am resistant to sharing my judgement of ease as most of the retro community thinks what I do is too much work. Follow the link I posted and you can judge for yourself.

You have to build it. IDK, is that "a lot of work" ? I know of 1 other person who has built one. And I gave my pcbs away. If you just want to throw money at a broken keyboard problem, I saw last week that a vendor in Japan has new mylars for the rubber keyboard. I did not bookmark that so you would have to Google it.

I think internet safety guidelines suggest you should never post ahead of time that you will be 'out of town' - LOL... Hopefully your ears didn't burn too hot, as we talked briefly about you in reference to the upswing in interest for SAMS.

':' is a perfectly legal linux file name character... never seen a linux system rename anything automatically. TIPI will populate the name in the TIFILES header, but never consumes it. I don't think the DSK on gameshelf should be modified. The game works fine with that disk image, if a regular floppy controller is available. It even works from TIPI if a regular floppy controller is available to error correctly. It comes to a design decision in TIPI that is incompatible with this software's expectations of original hardware. This is the first problem with this decision that the community has reported. I could probably set a config flag in TIPI to respond differently for systems that have no other storage devices, but it would have to be manually set. I will keep an eye on the value of that.

In addition, I have a few other homebrew PCBs : https://www.jedimatt42.com/tomy.html all passive though: a replacement keyboard, a dual SMS to Tomy joystick adapter.