ralphb

Not from me. The FinalGROM 99 is the successor to the FlashROM 99 and bests it in almost every aspect. Other than that, see my email.

According to Thierry: "As mentionned above, the five registers of the floppy disk controller map in the memory area >FFF0-FFFF. The addresses are different for read operations than for write operations".

I confirmed that the byte read is >606F. Thus, when the GROM sees address bytes >60, >6F, it does the prefetch, which means it does read >606F, and then increments the address to >6070. The fact that another address byte is written before the data is read doesn't seem to invalidate the prefetch buffer, so the old value is read. I guess it's logical, but also highly unexpected. Prefetch does indeed mean prefetch. EDIT: added conclusion

I'm currently studying the prefetch mechanism, so I thought I put this here. Although the prefetch should seem clear, I cannot make sense of this program: . li r8, addr movb *r8+, @grmwa nop movb *r8+, @grmwa nop movb *r8+, @grmwa nop movb @grmrd, r1 srl r1, 8 ; print hex value of r1 movb @grmra, r1 swpb r1 movb @grmra, r1 swpb 1 ; print hex value of r1 addr: byte >60, >6F, >20, >30 . Accompanied by this GROM . 00000000 aa 01 00 00 00 00 60 10 00 00 00 00 00 00 00 00 |......`.........| 00000010 00 00 60 1e 09 52 45 41 44 20 54 45 53 54 0f 70 |..`..READ TEST.p| 00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00001000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................| 00001010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................| 00001020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 00001030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 00001040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 00001050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 00001060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 00001070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 00001080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f |................| 00001090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f |................| 000010a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af |................| 000010b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf |................| 000010c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf |................| 000010d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df |................| 000010e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef |................| 000010f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ee |................| 00001100 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee |................| * 00002000. . the program prints >00FF and >7021, both in MESS and on real iron. When you examine the GROM dump, you'll see that there is absolutely no byte of value >FF in region >7xxx. Thus, the read must have been somewhere in >6xxx. Does this make sense, though? My current understanding is that the prefetch happens whenever two bytes are written, where this "counter"/flip flop is reset upon Data Read and Address Read. Thus, address >7021 is perfectly correct, but why is the Data Read so off? Could it use the last "good" address? readodd.zip

Thanks for your kind words, Casey!

I must admit that I accepted images as soon as they started and reacted to input. I often didn't even know what a program was supposed to do, especially for tools and applications. If there are updates with better versions, just post them here and I'll pick them up.

At this point, I would recommend my test programs, found in the ZIP but also here: https://github.com/endlos99/finalgrom99/tree/master/images/test Run addrtest, banktest, and gtest for about 5 minutes each and see if they work. If you cannot start them through the menu, put them on an otherwise empty SD card. If it crashes or shows an error immediately after the test program starts (i.e., before it cycles through all 128 banks or 5 GROMs), it might be your SD card. If it takes a while to err or crash, it's definitely not the SD card.

Does it work if you put a single image on the SD card and start with that? I could be that your case somehow twists or mangles the cart connector, so that you get a connection problem. Does the FG99 work without the case? EDIT: In general, SD card issues just cause blinking problems, but never crash the TI 99.

Alright, sorry for my impatience.

Thanks! I still see them here, though. Does this need some time?

Great, thanks!

In the TI 99/4A development forum (I haven't checked others), there a dozens of users "XXpeddal", who seem to like random posts. I have no idea what they're up to, but it does kind of irritate and spoil the forum. Ralph

You could create a file as.bat in your source folder, i.e., the folder that contains your assembly files: . @echo off rem adjust paths to match your downloaded files c:/development/xdt99/xas99.py -R %1.a99 -L %1.lst -S c:/development/xdt99/xdm99.py -X sssd test.dsk -a %1.obj -f disfix80 rem start MESS c:/emulators/mess64.exe ti99_4a -peb:slot8 hfdc -peb:slot8:hfdc:f1 525dd -peb:slot2 32kmem -cart C:/mytiroms/edasm.rpk -flop1 test.dsk . Then you just invoke with . as.bat myprogram . to assemble your file myprogram.a99 as E/A option #3, put the result on a disk, and start MESS and E/A with it. You only need to adjust the paths of your programs in the batch file once.

Back in the day, I wished I had POKEs for the TI 99. I mean, with POKEs, you could do ANYTHING!

Just for completeness, you can also use xdm99.py, like this: . xdm99.py -X sssd viper.dsk -a VIPER -t -9 . This creates a new SSSD disk and puts VIPER, which is in short TIFILES format, on it.

I wonder, though, how Microsoft came up with the weird CALL everything syntax. AFAIK, the TI 99 is the only MS BASIC that has CALLs. Maybe it's a logical consequence of GPL subroutines? Or maybe they wanted to allow for extensions (by cartridges) that felt native to the language?

Yes, here.

I've finally released a new version of the xdt99 suite. The biggest change is the inclusion of two disassemblers xda99 and xdg99 for machine code and GPL bytecode, resp. They support top-down disassembly as well as "run" disassembly that tries to follow the program flow and thus won't disassemble data segments. Additionally, xas99 has some new features: include filename in error message create a textual version of the binary using BYTEs include symbols in listing (option S of E/A) generate EQU file of used symbols Likewise, xga99 is moving ahead for feature parity with xas99: generates listing generate symbols (like xas99) Since the disassemblers are brand new and not so thoroughly tested as the assemblers yet, I'm happy to receive bug reports and feature requests. Download link here (don't download the source) Manual link here For the next release, I'm going to tackle my huge backlog and bug list, before I'll do a big refactoring after that.

I think it's possible to program the FG99 so that it can emulate GROMs 0-2 on a GROM-less system. For example, the FG99 could pull GR low right at the start and then do proper initialization afterwards. That way the TI 99 will be held as long as the FG99 isn't ready yet. But this is something to try in fall, when hardware season starts. Right now I'm busy with xdt99.

I tried supporting GROMs 0-2 for a GROM-less machine, but in the end the FG99 wouldn't start up fast enough before the TI would crash. I then shifted to using the FG99's GROMs 0-2 with a normal console, but (a) I didn't like the idea of overriding the built-in GROMs, and (b) having a GROM console only to override the GROMs seemed kind of pointless to me. System GROMs are simply out of scope (for now, anyway).

Thanks for your confirmation, Rich. It's weird that they didn't implement a documented feature, and I still don't know what actually happens when the G* MOVE is executed. Your workaround using [email protected](>83xx) is great, thanks!

You're right, page 3-7 does show indirect GROM addressing. Then why does my program not work, or can you post your working (from cartridge) program?

Looking at my test cases, I found a remark that G* would not work with the RAG assembler, so I checked again: Also, when you look at the address formats for [email protected]>xxxx and [email protected]>xxxx(@>xx), then the Ryte Data bytecode for G*>xxxx really sticks out as alien. I would conclude that G* is an invention of Ryte Data that was implemented in their assembler and in their simulator, but the TI GPL interpreter does not understand it.

Addendum: I did some further experimenting, and G*>8300 is not interpreted as *>8300 or @>8300!

Does that mean you're using the GPL simulator? Here's my BIN file assembled with Ryte Data, that works as a cartridge: gstarg.bin It shows only one "HI" instead of two in MESS, in Classic 99 (assuming I did it right) and with the FinalGROM 99. Can you post your file that is working?