mizapf

We have a working emulation of the GRAMKracker in MESS. I know this is not the real thing, but just in these cases where quite some money is involved you could find out whether you're ready to pay the price.

Well, and now it would be cool if we could integrate it somehow into this forum. BTW, the website is leafletjs.com.

Sure, this was what I had in mind. However, this was dropped when Yahoo decided to become different. The good thing was that we had this application inside the forum portal, while any other solution now involves some external service. Or something based on Google Maps.

:thumbsup: Looks good. :thumbsup:

The v9938 manual says: R0: 0 | DG | IE2 | IE1 | 0 | 0 | 1 | 0 R1: 0 | BL | IE0 | 0 | 0 | 0 | SI | MAG The 9938 does not have a 4/16K flag. But I guess it just ignores the flag. If you want to detect the v9938 you just have to read status register 4. Its contents can only be FF or FE. The 9928 has only one status register (so it ignores the status register pointer setting), and that register is highly unlikely to have that value (in particular when you don't have sprites on the screen). [Edit: Isn't "Return to Pirate's Isle" another example of a Graphics2 application? Just tried it with ti99_4ev, and it works.]

Ah, OK, got it. With the TMS9928 in SPLIT(2), there is a ok:0 with cursor, but not with the v9938. I tried it again; here is the new log: v9938: Write 20 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 70 to R#2 v9938: Write 0e to R#3 v9938: Write 39 to R#4 v9938: Write 86 to R#5 v9938: Write 38 to R#6 v9938: Write f7 to R#7 v9938: Write 00 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 02 to R#14 v9938: Write 20 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 00 to R#2 v9938: Write 01 to R#4 v9938: Write 06 to R#5 v9938: Write 00 to R#6 v9938: Write 08 to R#8 v9938: Write 02 to R#9 v9938: Write f7 to R#12 v9938: Write 00 to R#14 v9938: Write 60 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 00 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 60 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 30 to R#1 v9938: mode = TEXT 1 v9938: Write 01 to R#6 v9938: Write 4f to R#7 v9938: Write 70 to R#1 v9938: mode = TEXT 1 SPLIT v9938: Write 30 to R#1 v9938: mode = TEXT 1 v9938: Write 02 to R#0 v9938: mode = UNKNOWN v9938: Write 06 to R#2 v9938: Write 7f to R#3 v9938: Write 3f to R#4 v9938: Write 36 to R#5 v9938: Write 07 to R#6 v9938: Write fe to R#7 v9938: Write 60 to R#1 v9938: mode = GRAPHIC 2 TEXT: v9938: Write 30 to R#1 v9938: mode = UNKNOWN v9938: Write 00 to R#0 v9938: mode = TEXT 1 v9938: Write 00 to R#2 v9938: Write 0e to R#3 v9938: Write 01 to R#4 v9938: Write 06 to R#5 v9938: Write 01 to R#6 v9938: Write 4f to R#7 v9938: Write 70 to R#1 v9938: mode = TEXT 1

I tried it with the standard TI-99/4A in MESS, and when doing GRAPHICS2, I also get a gray screen with no contents. The v9938 implementation may have still have some issues, but the TMS9928 code is pretty well tested. I get this output from the 9938: (Starting Forth, typing GRAPHICS2, then blindly TEXT) v9938: Write 20 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 70 to R#2 v9938: Write 0e to R#3 v9938: Write 39 to R#4 v9938: Write 86 to R#5 v9938: Write 38 to R#6 v9938: Write f7 to R#7 v9938: Write 00 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 02 to R#14 v9938: Write 20 to R#1 v9938: mode = GRAPHIC 1 v9938: Write 00 to R#2 v9938: Write 01 to R#4 v9938: Write 06 to R#5 v9938: Write 00 to R#6 v9938: Write 08 to R#8 v9938: Write 02 to R#9 v9938: Write f7 to R#12 v9938: Write 00 to R#14 ... v9938: Write 30 to R#1 v9938: mode = TEXT 1 v9938: Write 02 to R#0 v9938: mode = UNKNOWN v9938: Write 06 to R#2 v9938: Write 7f to R#3 v9938: Write 3f to R#4 v9938: Write 36 to R#5 v9938: Write 07 to R#6 v9938: Write fe to R#7 v9938: Write 60 to R#1 v9938: mode = GRAPHIC 2 ... v9938: Write 30 to R#1 v9938: mode = UNKNOWN v9938: Write 00 to R#0 v9938: mode = TEXT 1 v9938: Write 00 to R#2 v9938: Write 0e to R#3 v9938: Write 01 to R#4 v9938: Write 06 to R#5 v9938: Write 01 to R#6 v9938: Write 4f to R#7 V9938: Read c4 from S#0 v9938: Write 70 to R#1 v9938: mode = TEXT 1

Lee, how far exactly do you get? I got inside FORTH and was able to type MENU, getting this list (Description ... Load block) and "Type <block> LOAD to load." I'm using ti99_4ev, and this is now running in 40 col mode.

On Yahoo there was a nice add-on application with a world map where you could place a pin on your location. Unfortunately, Yahoo decided to drop all applications some time ago when they were undergoing some restructuring.

You have Deutsche Telekom as provider? Interestingly, wget also fails on my vServer at the Strato hoster. When I start from my office computer in Nuremberg, I'm getting a connection. Whtech is the only address known to me that causes trouble, so it's not just a simple matter of configuration. Neither ftp nor http works. Has Telekom been blacklisted by a network carrier? wget ftp://ftp.whtech.com/ --2014-06-26 22:19:09-- ftp://ftp.whtech.com/ => '.listing' Resolving ftp.whtech.com (ftp.whtech.com)... 64.27.2.118 Connecting to ftp.whtech.com (ftp.whtech.com)|64.27.2.118|:21... failed: Connection timed out. Retrying. --2014-06-26 22:21:17-- ftp://ftp.whtech.com/ (try: 2) => '.listing' Connecting to ftp.whtech.com (ftp.whtech.com)|64.27.2.118|:21... ^C

Wow, that's cool ... when I start a VPN connection to my office, I can connect to WHTech. The VPN redirects my default route to my office computer, and via there it's working...

OK, ping may be blocked. Can you do a traceroute / tracepath (or tracert.exe)?

Nothing important right now, but I just wanted to point someone to our FTP server, and now I can't reach it. And the fact that you don't have problems but I don't get through for the last weeks (with some few successes) is somewhat unsettling. Do other people here (Germany, Europe) have the same problem? Try to ping WhTech.

Grmpff ... looks like a routing problem out there. Something within the responsibility of the network providers, so we cannot do anything about it. Depends how you approach the target network. So I'm now disconnected from WhTech. Splendid. ping ftp.whtech.com PING ftp.whtech.com (64.27.2.118) 56(84) bytes of data. ^C --- ftp.whtech.com ping statistics --- 79 packets transmitted, 0 received, 100% packet loss, time 78000ms

Oh, soccer GER-USA beginning in a few minutes ...

Trying to ping right now ... $ ping ftp.whtech.com PING ftp.whtech.com (64.27.2.118) 56(84) bytes of data. ^C --- ftp.whtech.com ping statistics --- 22 packets transmitted, 0 received, 100% packet loss, time 20999ms and tracepath /sbin/tracepath ftp.whtech.com ... 2: 217.0.119.41 16.944ms 3: 217.0.75.198 19.985ms asymm 5 4: f-ed5-i.F.DE.NET.DTAG.DE 17.615ms asymm 5 5: ffm-b12-link.telia.net 53.752ms 6: ffm-bb2-link.telia.net 17.869ms asymm 7 7: nyk-bb1-link.telia.net 105.273ms asymm 8 8: las-bb1-link.telia.net 179.130ms 9: las-bb1-link.telia.net 181.573ms asymm 8 10: juniperm160-02.lax01.calpop.com 184.144ms 11: no reply 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply ...

Anybody knows what's up with Whtech's FTP server? During the last weeks I had only few chances to get a connection. Right now I keep getting timeouts on connection setup. Wouldn't be a problem if it happened only few times, but this seems to continue. $ ftp ftp.whtech.com ftp: Can't connect to `64.27.2.118:21': Connection timed out ftp: Can't connect to `ftp.whtech.com:ftp' ftp>

Rich, I don't know Apple systems very well, but what about running MESS natively in OSX or whatever you're using? Can't get worse, I guess, and you don't have the Windows issues. Shutting down because of high load is a silly behavior of that system, unless you have a setting in the BIOS which limits the temperature of the CPU. Maybe that is the case? At least on weaker systems MESS is known to drive the load up to the top. My Core-i7 is running at about 30% load with MESS on one core. I know several MESS devs who are running it under OSX.

Strikingly reminds me of this old TV sketch from Loriot (Christmas with the Hoppenstedts). https://www.youtube.com/watch?v=xo55jk0HFWA If you don't understand German, just some points here, you'll get the rest. @0:00-1:21 Shop lady trying to find out whether Grandpa's grandchild is a boy or a girl. [Grandpa is Vicco von Bülow aka Loriot himself] @1:22: Grandpa: So do you have toys for good children or not? Clerk: Well, yes, there is a brand new toy here for kids aged 5 to 10. It is very well sought after lately: "We build a nuclear plant". Kids are having lots of fun, and their parents as well. Really something for the whole family. Here are the game instructions, and here are all the components to be put together: The reactor core, the uranium rods, cooling system, neutron accelerator, and the safety housing. Grandpa: And what's that? Clerk: These are trees, houses, and cows for the surroundings. Very nicely crafted. Grandpa: And can it really ... ufff ... explode? Clerk: Yes, sure, when you do a mistake, there'll be a small explosion. Of course, not really, it's for kids. But it makes "poof", and the cows tilt over, and the houses, and the trees. But there's always great cheers and lots of fun! Want to take it? Grandpa: Yes. ... @2:33: Grandpa: In former days there was more lametta (tinsel). [This has become a winged word in Germany.] @2:40-3:00: Mom and Dad trying to set up a plan how to proceed during that Christmas Evening. @5:37 Dad: Ah well, a tie Mom: Ain't that great! [gemütlich] @6:20 Mom: Will Dad now play the new game with you? Dad: "We build a nuclear plant" ... There are cows, and trees, and houses, and they all want a new nuclear plant. Mom: Oh why can't every day be Christmas? @7:00 Mom: May Mom have a look? Dad: If we did something wrong, it's supposed to do "poof". ...

Let me tidy up your line: C:\mess\mess64 ti99_4ev -peb:slot3 speech -peb:slot4 samsmem -peb:slot6 tirs232 -peb:slot8 hfdc -hard1 C:\mess\disks\hd1.hd -hard2 C:\mess\disks\hd2.hd -hard3 C:\mess\disks\hd3.hd -flop4 C:\mess\disks\rxbgplassm.dsk -gromport gkracker -cart C:\mess\carts\rxb_2012.rpk The EVPC is automatically mounted in peb:slot2.

Rich, it's quite simple: This is a fake output. You will always get a "DSK1", "HDS1", or "SCS1", depending on the format that TIImageTool detects. It is intended to look like the output in Geneve OS, but of course there is no reason for having DSK2 or WDS3 or the like.

Which disk image in your collection is the one which TIImageTool is unable to work with? Just to make sure - you closed your images in TIImageTool before you go into MESS? Because if you keep them open in TIImageTool and modify them inside MESS, you can corrupt their contents. TIImageTool does not check for concurrent changes.

Can you upload a copy of that disk image?

Well, it would, if there really were an issue with the emulation in MESS. Eventually, the GPL access will call the subprogram in the HFDC card, so that is the point where GSRLNK and DSRLNK will meet. My test program just goes the assembly path. One thing that can happen, as Tim said, is that we may have an unwanted value in 8352. I am not sure whether the PAD RAM is initialized on startup ...[wait] Ahh, yes, I got it! You can make good use of the MESS debugger at this point. Start on the command line using the "-debug" switch. Place a breakpoint at >4114 (input line at the bottom) like that bpset 4114 Type "go" to let the emulation go. Go into RXB, enter CALL SECTOR("WDS1.",1,1,"0") The execution will be suspended at the breakpoint. Go to the debug window, open a memory inspection window with CTRL-M. Check that the memory selection is "TMS9900 ':maincpu' program space memory". Type 8300 into the entry field on the left. Look at the second word in the line 8350. It is not zero. Go back to the debug window, type "go". You'll get the "file error". Enter CALL SECTOR again as above. The breakpoint is still there. Go to the memory window, click on the second word (it's 03C2 for me), type 0000 over it. Go back to the debug window, type "go" ... and you'll see that the SECTOR subprogram returns without error!

Oh my, took me some time to write this test program. I think I found all possible pitfalls* ... But it is working, at least in MESS. This program reads a sector specified in SECTOR from the first hard disk and displays the contents on the screen. DEF START REF DSRLNK,VMBR,VMBW WS BSS 32 BUF BSS 256 SECTOR DATA 0 PAB BYTE 1 BYTE >20 START LIMI 0 LWPI WS LI R0,>1000 LI R1,PAB LI R2,2 BLWP @VMBW MOV R0,@>8356 LI R0,>0101 MOV R0,@>834C LI R0,>1800 MOV R0,@>834E MOV @SECTOR,@>8350 CLR @>8352 BLWP @DSRLNK DATA 10 LI R0,>1800 LI R1,BUF LI R2,256 BLWP @VMBR CLR R0 BLWP @VMBW LIMI 2 JMP $ END*Pitfalls: You can do the following to make life harder: Forget to write a PAB at all Forget to put the pointer in 8356 Put the wrong pointer in 8356 Try to address the first drive as number 0 (manual says they start at 1)