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

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,006

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  2. Posted · Edited by Asmusr

    1 hour ago, GDMike said:

    CLS  LI R0, 0

              LI R1, >2000

    CL      BLWP @VMBW

              INC R0

              CI R0,768

              JLT CL

    VSMW is looping for you. All you need is: 

    CLR  R0
LI   R1,>2000
LI   R2,768
BLWP @VSMW

    The problem is there are many coding styles and ways to pass parameters in assembly. I even find it difficult to reuse my own routines from one game to the next. 

    • Like 1
    • Haha 1

  4. Posted

    32 minutes ago, jedimatt42 said:

    I have fixes for the PROGRAM save issue, and a few other things, and was trying to stream-line the sdcard image configuration to be more friendly to QEMU and to the user... but I cannot get beyond reset now..

     

    Are there un-pushed changes required? 

     

    I don't see anything pending in js99er-angular's branch for tipi vs master, or pete's tipi fork of tipi...

    Just a stupid mistake. Try now.

    • Like 1
    • Thanks 1

  5. Posted

    25 minutes ago, jedimatt42 said:

    I have fixes for the PROGRAM save issue, and a few other things, and was trying to stream-line the sdcard image configuration to be more friendly to QEMU and to the user... but I cannot get beyond reset now..

     

    Are there un-pushed changes required? 

     

    I don't see anything pending in js99er-angular's branch for tipi vs master, or pete's tipi fork of tipi...

    Looks like I broke the TIPI emulation. I will fix it later tonight.

  6. Posted

    3 minutes ago, Lee Stewart said:

     

    That certainly makes sense—just as long as nothing untoward happens when writing to nonexistent VDP registers, such as what would happen if register numbers are masked to allow only the low-order 3 bits. In fbForth and TurboForth, it is presumed that the user knows whether they have an 80-column-capable VDP. If they choose 80-column text mode with a TMS9918A, the system will go off into the weeds precisely because higher-order register-number bits are masked out by the TMS9918A. As I said, if the same thing were to happen with @speccery’s VDP implementation of 80-column text mode, the above Forths will fail.

     

    ...lee

    Right, so he could implement the same solution as the F18A, which is to mask to 3 bits unless the 80 columns mode is selected, in which case writes to registers >= 8 are ignored.

    • Like 1

  7. Posted · Edited by Asmusr

    1 hour ago, Lee Stewart said:

    They cannot be ignored. I am pretty sure I tried. I would need to retest to be certain. What I have set were tweaked by Tim (@InsaneMultitasker) and Michael (@mizapf) several years ago. Below are what are set for fbForth and TurboForth:

    Please, I'm not talking about what you should do but which registers @speccery would have to implement to support 80 columns. You're enabling the mouse and setting a bit related to the VRAM organisation, but speccery can ignore that if he supports neither. And then you're setting some blinking options that he probably doesn't want to support either. I think he still only needs to support the mode bit in VR0.

    • Like 2

  8. Posted

    I have released a new version of JS99er with some bugfixes related to the TIPI: there was a problem when you enabled and disabled the emulation,  and the CPU is now suspended until the websocket is running.

     

    I have managed to load programs from the TIPI, but when I try to save a simple BASIC program (SAVE TIPI.BAS.HELLO) I get an I/O ERROR 66. What am I doing wrong?

     

    And what is the correct way to shut down QEMU?

     

    Thanks.

    • Like 1

  9. Posted · Edited by Asmusr

    I forgot that the F18A firmware 1.8 and above ignores writes to VR8 and above if 80 columns mode is selected and it's not unlocked. So that's why it doesn't hurt to write to VR8-VR15 on the F18A. On the V9938 those regs have the following meaning:

    • VR8: Mouse, light pen, sprite disable, etc
    • VR9: Vertical line count and other output related bits
    • VR10: Color table high
    • VR11: Sprite attribute table high
    • VR12: Text and background blink color
    • VR13: Blinking period register
    • VR14: VRAM access base register
    • VR15: Status register pointer

    To implement a simple 80 column x 24 row mode, I think all of these can be ignored. The only issue is if software uses VR15 to set status register 1 in order to detect the V9938 or F18A, then that would have to be implemented. 

    • Like 1

  10. Posted

    12 hours ago, Lee Stewart said:

     

    Nevertheless, the settings for VR08 – VR14 were designed to allow setup of 80-Column Text mode without needing to know which VDP, F18A or V9938, was installed.

     

    ...lee

    Are you detecting if an V9938/F18A is present or are you setting these registers blindfolded? I think in addition to the bit in VR0 @speccery might have to support detection.

  11. Posted · Edited by Asmusr

    7 minutes ago, Lee Stewart said:

     

    It looks like VR10 and VR11 are all that may be needed for the F18A (not absolutely sure about that), but the 9938 definitely needs most or all of VR08 – VR14 managed. Otherwise, you get undesirable behaviour like blinking text, etc. I believe Tim (@InsaneMultitasker) worked out these details for Mark Wills (@Willsy) for TurboForth, which is where I got them for fbForth.

     

    ...lee

    VR10 and VR11 on the F18A are for setting name table and color table of tile layer 2. They are not needed to set 80 color mode. If the F18A is locked you will address VR2 and VR3 instead.

    • Like 1

  12. Posted

    2 hours ago, Lee Stewart said:

     

    TurboForth and fbForth set 15 VDP registers (VR00 – VR14) to effect 80-Column Text mode for both the F18A and the V9938—so, 7 additional registers.

     

    ...lee

    What is the reason for setting all those registers? I would have answered that he only needed to support one extra bit of register 0 (bit weight >04).

    • Like 1

  15. Posted · Edited by Asmusr

    On 6/13/2020 at 2:03 PM, ti99iuc said:

    - could be hard to include a possibility to press a key, like "M" and see the Map with the own position?

    I have added a map. Press M to see it, press Up to close it.

    I'm not sure it will stay as easy as that that. Maybe you will have to find the map first? Maybe it should only show areas you have visited?

    raycaster.dsk raycaster.rpk raycaster8.bin

    • Like 2
    • Thanks 1

  16. Posted

    29 minutes ago, Omega-TI said:

    Bloody Awesome!  Are you sitting right on top of a Fiber Optic line next to a major hub?

    I don't know about the hub, but it's a fiber alright. We could also get 1000 Mbps if we paid for it. But actually the change from our old ~11 Mbps ADSL wasn't that noticeable, except when I upload to YouTube.

    • Like 2

  17. Posted

    29 minutes ago, Omega-TI said:

     

    Wow!  That is what I call perseverance! :-o  I don't think I'd ever upload another YouTube video if it took that long.

     

    I live out in the toolies as well, so I'm stuck with DSL and this is my average...

    SPEED.thumb.JPG.03dce1bb5fd3936594445a8bbe00ce5a.JPG

    ... I'm supposed to get 12Mbps, but it never seems to work out that way.

     

     

     

    Here's mine ;-)

    speed.thumb.png.da72a0b902ef021139d8fef75f1d5656.png

    • Like 3

  20. Posted

    On 6/16/2020 at 7:53 AM, PeteE said:

    Done.

    You probably noticed that I already deployed your changes to https://js99er.net, but I still haven't been able to get the RPi side up and running myself. My QEMU is running with this configuration, and all the services on the RPi  appear to be running except the TIPI boot service: 

    qemu-system-arm -kernel kernel-qemu-4.19.50-buster -dtb versatile-pb-buster.dtb -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -drive "file=2020-02-13-raspbian-buster.img,index=0,media=disk,format=raw" -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::9901-:9901

    In JS99er it seems to be making a websocket connection (at least it's different from not running QEMU), but it's closing after a short time, and nothing happens. Do you have any ideas hot to troubleshoot this?

     

  21. Posted

    21 hours ago, PeteE said:

    I've checked in my changes to support whole tipi messages in websocket binary frames.  The tipi server fork is here, and the js99er fork is here.  The latency is quite improved, and js99er seems to load "CALL TIPI" at the same speed compared to hardware.  The websocket server implements the "RESET" text command, and adds a new "SYNC" text command, which precedes a sent or received binary message (when TC=0xf1 and RC=0xf1.)  @jedimatt42 I moved the TipiMessage procotol handling to the tipiports C module, since the API layer works on the message level now.  I haven't tested it on actual hardware though, there's a chance that I broke something.

     

    Can you make a pull request for me to get your changes?

    • Thanks 1

  22. Posted

    3 hours ago, ralphb said:

    Is there also a way to deactivate an unlocked F18A?  For a while I checked for an F18A in the SDD 99 power-up routine, which involved unlocking the F18A.  

           ; check for F18A
       li   r0, >391c         ; unlock potential F18A
       bl   @vwtr
       bl   @vwtr
       li   r0, >01c0
       bl   @vwtr

       movb @vdpsta, r1       ; check if F18A present
       li   r0, >0f01
       bl   @vwtr
       movb @vdpsta, r2
       dec  r0
       bl   @vwtr
       cb   r1, r2
       jeq  powerup_cart

       li   r0, sys_f18a_en   ; mark F18A available
       mov  r0, @x_sys

    With F18A active, however, the TI BASIC output is totally garbled:

     

    scrambled.thumb.jpg.4e79d69eb98271a6710e223beb5c57be.jpg

     

    This should look like below, and the only difference between both shots is the presence of above snippet in the DSR.

     

    normal.thumb.jpg.52849752e9a85d64bc825480495c0ea8.jpg

     

    Note that the DSR does not modify any VDP registers except for F18A detection.  I have no idea how this can even happen ...  Are some default register values different?  Maybe some F18A experts know?

     

    (NOTE: Neither image looks really that normal.  That's because my F18A or the VGA connector or the connecting cable has some "issues".  If you watched my SDD 99 video, you know that there was a green tinge and some fuzz to the screen.  After "rerouting" the cable inside my TI, I now have NO green at all! 🤪)

     

    EDIT: I looks a little bit like bitmap mode ... 

    You can reset and lock the F18A with:
LI   R0,>3280
BL   @VWTR

    Did you try you code in js99er?

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...