Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ralphb

Members
 View Profile  See their activity

  • Content Count

    828

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by ralphb

  3. Posted · Edited by ralphb

    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

    • Like 1

  4. Posted

    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

  7. Posted

    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.

  8. Posted · Edited by ralphb

    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.

  13. Posted

    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.

  16. Posted

    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?

  18. Posted

    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.

    • Like 8

  19. Posted

    Maybe there could be away to replace all 3 TI Console GROMS with and easy plug in 24K device to emulate the TI OS and TI Basic or other alternative versions?

     

    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.

    • Like 6

  20. Posted

    After reading the final doc on the FG99, it's bit of a disappointment to me, as it is not a replacement for my MG 80K GramKraker. Most all of my software development requires alternate TIOS (G0) and TI Basic (G1&2). I use Tony Knerr's HSGPL GROM 0, and Grom's 1&2 enhancements by Rich Gilbertson with fixes to the EA CALLs for Basic (allows use of these CALLs from BASIC programs running in GRAMs 3 - 7) by Tursi.

     

    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).

  23. Posted

    Looking at my test cases, I found a remark that G* would not work with the RAG assembler, so I checked again:

     

    post-35214-0-15290600-1502626875.png

     

    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.

     

  25. Posted

    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?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...