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

  1. Posted · Edited by ralphb

    Thanks for the suggestion, but unfortunately that didn't help.

     

    Looking at the BASIC line editor code (around G>2A4F) in TI Intern, I thought that >830d, which stores the repeat speed counter, might be the key (no pun intended) -- but nope, setting it to 0 before leaving doesn't do anything.

     

    I guess I'm messing with scratchpad RAM in a way I shouldn't ... Thierry states that key repetition is handled outside the SCAN routine. I'll try to reproduce it in an emulator and debug why this happens.

  3. Posted

    I have a self-written assembly routine that I execute from either BASIC (in different ways). The routine waits for a key press before terminating itself, like this:

    .

           li   r0, >05ff
       mov  r0, @>8374
       clr  r0
wait_key:
       movb r0, @gplst
       lwpi gplws             ; gpl r11 already saved
       bl   @scan
       lwpi ws
       movb @gplst, r1
       coc  @h_2000, r1       ; new key pressed?
       jne  wait_key

    .

    This works, but when I return to BASIC, the cursor starts auto-repeating spaces, and doesn't react to any key presses except for FCTN-=.
    Are there any flags/values I need to reset before returning?

  4. Posted · Edited by ralphb

    Yes, I wrote LIMI >8300 instead of LWPI >8300, but this sequence of LIMI 0 LWPI ws is so common I rarely look at it. :) The missing LWPI caused the test program and thus the DSRLNK to run at >83e0, which caused havoc with the actual >83e0 part. I took me several hours to find the bug.

     

    The spaces are fine, as xas99 is more tolerant than E/A.

     

    EDIT: clarification

  5. Posted

    • Did you rewrite DSRLNK and VMBW to work without context switch?
    • How does the linker find the lowercase symbols for both?

     

    Yes, my versions work with BL instead of BLWP, and symbols are case insensitive. The missing symbols like PAB_OPEN are just somewhere, so this is not the bug ...

  6. Posted

    Thanks for the offer again, I'd pick it up, but I made some progress by finding the bug in the test program. Do you notice something about this code? :P

    .

    start:
       limi 0
       limi >8300

test1:
       li   r0, >3000
       li   r1, pab_open
       li   r2, pab_open_end - pab_open
       bl   @vmbw
       mov  @c_3009, @>8356
       bl   @dsrlnk
       data 8
;      ...

    .

    After I fixed my test program, my DSRLNK is suddenly working. I shouldn't code for that long ...

  7. Posted

    They are nothing special. Each one is just a word (2 bytes) in RAM except for NAMSTO, which is the name buffer and 8 bytes long.

     

    OK, now it's working ... I used just a word for NAMSTO, so it got overwritten by the other variables and the device/file would not be found.

     

    Finally! A working DSRLNK. :)

    • Like 2

  9. Posted

    You could try a debug session in MAME to watch the register contents. Or send me your test program so I can check it.

     

    Ugh, I tried that, but lost patience. It starts alright for the first three or so loop iterations within the TIFC, but it's just one bad breakpoint and BOOM!

     

    I would never foist this on you. ;)

  11. Posted

    R13,R14,R15, in GPLWS ... copies FAC off to VDP ... That nop ... Do you mean sbz on your second to last line?

     

    Those are some good points, but the entire routine is running in User WS, with only the jump using GPL WS. You can see that I only modify R9 and R12.

     

    I didn't know about FAC restauration, but this does not cause my endless loop.

     

    The NOP is only temporary, but you're right about the sbo that should be a sbz.

     

    Unfortunately, all this doesn't really explain why my DSRLNK doesn't work. Does the peripheral need more data in the FAC area besides >8354 and >8356?

  12. Posted

    I've noticed that the static version of the DSRLNK provided by xdt99, which I cobbled together from Tim's version, doesn't work at all.

    .

    There is a comment in the above reference that says the MG DSRLNK cannot be used in cartridge space (ROM) because it is self-modifying. This is certainly true, but it can be modified to run in ROM with the addresses that get modified moved to RAM. For insight into how to do that, see the code for GPLLNK (from MG via Smart Programmer) in TurboForth source code in “Resources” at turboforth.net.

     

    My attempt to fix the MG DSRLNK wasn't really successful, and I also couldn't find your code. Which section has it?

     

    Despite all these versions, I also tried to write my own DSRLNK, but just for DSR ROM so far. The code to transfer execution to the peripheral looks like

    .

           ; found DSR entry
       li   r1, 1
       mov  r1, @>83e2        ; 1 in gpl r1
       mov  r3, @>8354        ; pointer to start of device name
       a    r3, r5
       mov  r5, @>8356        ; pointer to '.'
       mov  r12, @>83d0       ; copy of CRU address
       mov  *r6, @>83d2       ; next DSR chain entry
       mov  @2(r6), @>83f2    ; target address in gpl r9
       mov  r12, @>83f8       ; r12 in gpl r12
       lwpi >83e0
       bl   *r9
       nop
       lwpi >8300
       sbo  0
       rt

    .

    Unfortunately, when I run this, the TI gets stuck in an endless loop within [email protected]>04DE->05A0, which is GPL FMT?! Am I missing any values that are required for correct initialization?

     

  14. Posted

    About ten years ago, I signed up for the OmniScan SDK, which even required signing an NDA. My idea was to create a BASIC "language" that would run after the raw recognition to remove the most obvious errors.

     

    For each letter on the page, OmniScan creates a list of potential glyphs, together with their probabilities. In theory, you could select those glyphs with the highest probability that made sense according to a BASIC grammar. To distinguish variables, say A0$ from AO$, you'd need even more heuristics.

     

    All in all, this seemed too time-consuming to me, so it never went anywhere.

    • Like 2

  16. Posted

    Back on topic, Thierry does explain that MEMEN* might not go high between parts of two different instructions. His example is

    .

    LOOP MOV @>2000,R0
     JMP LOOP

    .

    where the writing of R0 and the fetching of the JMP opcode happens in the same MEMEN* cycle. :-o

     

    So it might be just as you said, Stuart. I certainly learned something today.

  17. Posted

    I'm running the XDT99 tool to create the object code and Classic99 with the XB27 cart. I used TIImage tool to create the disk image and I'm running Windows 10 :-o .

     

    Just for your information, you can also use xdt99 to create a disk image:

    .

    xdm99.py -X SSSD work.dsk -a yourfile.obj -f disfix80 -n YOURFILE/O

    .

    which means to create a SS/SD disk image (-X), add your file (-a) in DIS/FIX 80 format (-f) and given name (-n).

     

    But Classic99 doesn't use disks natively, so you can also use

    .

    xdm99.py -T yourfile.obj -9 --ti-names

    .

    which creates a so-called TIFILES file (-T) with reduced header (-9 for Classic99 or v9t9 emulators) and TI-compatible name (--ti-names).

     

    You could even put both commands into a batch file, so you won't have to type them each time you want to assemble.

    • Like 1

  20. Posted

    Here's the same segment with phi3 and the upper (MSB) four address lines. At least the signals seem consistent for each run.

     

    post-35214-0-27964400-1513091409_thumb.png

     

    Note that I'm sampling with 25 MHz, which implies that each signal transition (i.e., vertical line) could be off by 40 ns in each direction. Still, the WE* pulse is 340 ns wide and thus not a figment of the measurement. And looking at phi3, it seems that this is business as usual for the TI.

     

    The address of the write seems to be >8???. Could this be the result of an access by operand *Rn+, where registers are located in scratchpad RAM >83xx? Still, it's odd that it's in the same MEMEN* cycle.

     

  21. Posted

    Yes, phi3 was my initial thought as well, but I was kind of reluctant to (somewhat painfully) rewire my test harness. But I'll try it tonight.

     

    The first address read (A) is somewhere in >6000->6020 (hence the consecutive reading of two bytes). I have no idea what (B) reads (I cannot capture the entire address bus), but it looks like just one byte.

  22. Posted

    While testing a few things with the FinalGROM 99, I caught some strange-looking (to me) bus signals, which I recorded with my logic analyzer (attached to the side port, for simplicity).

     

    post-35214-0-51839100-1513022877_thumb.png

     

    Read cycle (A) is a read access to the FinalGROM's GPL header. You'll notice that the entire MEMEN* cycle is longer than 2 us, and that some short WE* burst precedes the actual read access (DBIN high for 2us). What the hell is that write doing there? Not every cart read access has this extra write ...

     

    But these short writes do seem fairly common. In cycle (B) I caught another write followed by a read, again to the same address (only LSB A0 is shown in the graph).

     

    Can someone explain to me what is happening here? I've heard of read-before-write, but not the other way around ...

     

  24. Posted

    I'm looking at Thierry's page on BASIC argument parsing, and it's atrocious :razz: (the mechanism, not the page). What I get is that I have to use various console routines XML >1x to parse BASIC, and that some routines won't work for Extended BASIC.

     

    Has anyone ever done this successfully and can provide further details?

     

    If I use those XML >1x routines, what are their input arguments, and their result values? What do I have to use for Extended BASIC instead, especially for the symbol table?

     

  25. Posted

    It's not a straight lookup, unless you want a lookup table with 65536 entries. Each instruction format has a particular opcode length associated, so you have to iterate over all formats and see if the word you have anded with the format's opcode length matches any opcode with that format.

     

    To see an implementation, see xda99.py in the xdt99 suite, search for "def decode".

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...