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

    As a test for the new Super Character Set, you can try to import the graphics from Zaxxon:

    • Choose Options > Super Character Set
    • Choose Options > Enhanced Color mode - 2bpp
    • Choose Import > Map Image and select the first attached file "Arcade - Zaxxon ... ".

    The result is 1829 characters, so it's good the maximum was increased from 1024 to 2048.

     

    [ I have attached the other, normalized,  files in case anybody feel an urge to implement Zaxxon for the F18A. It can do the isometric scrolling just fine, but there are too many characters to show. I haven't tested if there are more than 256 on a single screen, otherwise it should be possible to load them dynamically. ]

    Arcade - Zaxxon - Background.png

    level0.png

    level1.png

    level2.png

    • Like 7

  3. Posted

    8 minutes ago, Omega-TI said:

     

    Saying that to the guys here is like a challenge!  I remember back in the day one software company bragged that their disk protection method was "impossible to crack", which did not sit well with one 13 year old kid, who took it as a challenge, and then a week later broke it and gave all his friends copies of the game.

    For those who know git and Magellan it''s easy enough.

  4. Posted

    4 minutes ago, mizapf said:

    The only chance of writing compatible software in terms of keyboard access is to use BL @>000E in TI mode (or the respective XOP in native mode). On CRU base (low level), the systems are too far apart.

    I don't understand, but you're welcome to make a fork of my code for the Geneve.

  7. Posted · Edited by Asmusr

    2 hours ago, Omega-TI said:

    I've seen demos morph into full-fledged games...

    What I mean is that changing something in a program that will change completely later might not be worthwhile. But here you are, a new version where the doors are re-spawning and you need to press fire before you restart.

    raycaster.dsk raycaster.rpk raycaster8.bin

     

    Edit: Oh yeah, there is also a chest hidden behind a secret door. You will never find it...

    • Like 3

  8. Posted

    3 hours ago, ti99iuc said:

    I also noteiced that when i finished all my energy and the game started again, all the doors i had opened in the previous gameplay,  are remained still opened.

    Hmm, obviously I didn't try to play several rounds myself. I guess I should fix that, even though it's only a demo. 

    • Like 2

  9. Posted

    3 hours ago, ti99iuc said:

    I also have the same problem mentioned about about the fact that apparently invisible soldier shoot me but i can't see anyone around me, but it happens also in the latest version... it seems a bit less compared to the previous one anyway.

    Once a soldier is 'activated' and close enough, it will shoot at you no matter if there is a wall in its way. To fix this I would have to cast a ray from the soldier towards you, which would be fine if speed wasn't a major concern. So I think I will leave it as it is.

    • Like 1

  10. Posted

    1 hour ago, senior_falcon said:

    If your entire program fits into 256 bytes then you could use the hack to seize control of the computer by loading code from >834A to >83C4 or a little beyond. Then that code could load almost the full 256 bytes - you have to save some room for the instructions that load the code. If your code is larger than 256 bytes then you have to load it in pages. Doing that means reading the code from VDP and writing it to scratchpad. Every instruction requires 6, 12, or 18 instructions in the loader (plus some additional overhead) just to get it from VDP to scratchpad. Something as simple as B *R11 cannot be done if it goes to another page. You have to load yet another page with the code needed to load the calling code and return to it. 

    You can see there are numerous complications. I felt that being able to use console routines (auto sprite motion, kscan, etc.) would be useful and probably faster, and certainly more compact than paging in all the code needed to duplicate these routines. If you eliminated all console routines, you would need a workspace(32 bytes) and code to load the pages(36 bytes for the code I wrote) which leaves you with 188 bytes per page - a little more if your workspace was less than 16 registers.

     

    There is no going back to BASIC. Once you are in, many of the pointers are overwritten so the only exit is via "Quit".

     

    Here's a memory map of how the scratchpad is used. (There is much more information in the docs.) 

    >8300 - >8371 114 bytes available for a program page. (KSCAN and GPLLNK use memory from >836A to >8371)
>8372 - >837D System use for keyscan, sprite motion, etc. >8373 is GPL substack pointer; >8378 is the random number seed
>837E - >83A1 36 bytes - Page loader
>83A2 - >83C1 Workspace (R15 overlaps into R0 of interrupt workspace)
>83C0 - >83DF Interrupt workspace. (R0 not available) R8 and R9 (>83D0 and >83D2) are used to store return address for a subroutine.
>83E0 - >83FF GPL workspace

    I only had provision for 1 level of subroutines. As I remember, Moije figured out a way to have a stack and documented how he did it. Of course, the entries on the stack cut into the 114 bytes, but that may be an avenue worth pursuing.

     

    One of the things I would like to do is port "Megabug" or "Dung Beetles" to the unexpanded TI. 

    I must admit it's been a while since I looked at your documentation, and it all seems reasonable enough, but if someone was trying to make a micro Forth machine all I'm saying is that those are not given restrictions. All you absolutely need is room for a workspace. 

    • Like 1

  11. Posted

    1 hour ago, ti99iuc said:

    - can I hope to see the soldier without that colorclash? i always hated them on spectrum 😛

    The soldier is already using 95 of the 256 characters. It would never fit with all the different combinations of background. The alternative would be to draw it using single-color magnified sprites, but again we would soon run out of patterns.

    • Like 1

  12. Posted

    8 hours ago, jrhodes said:

    I say go whole hog.

    Add support for f18a and SAMS.

    Time to teach those puny atari's a lesson they'll never forget. ;-)

    For me the cool thing about this project is that it doesn't require F18A or SAMS. When the F18A MK2 is released, and if we have access to the expanded VDP RAM, and in particular if we could get a new bitmap mode with more colors, I would like to make a new raycaster for the F18A.

    • Like 7

  13. Posted

    9 hours ago, mizapf said:

    I just noticed that I never played FPS using a joystick but rather the keyboard; the usual WASD. Maybe this could be an option, or can I use the keyboard already and I just failed to find out? I'd also need two keys for the right hand for turning, e.g.  W=forward, S=backward, A=walk left, D=walk right, J=turn left, K=turn right

     

    (and maybe this could eventually run on the Geneve, and we could use the 9938 mouse ... :D )

     

    Man, this project could even impress the Duke!

    I'm not sure what it requires to run something on the Geneve. Is it mainly about not accessing the keyboard directly?

  14. Posted

    6 hours ago, Omega-TI said:

    Has anyone else had an invisible person shooting at you until all your health is gone?

    It is actually possible in some cases for the guards for shoot you through the walls, because there's no easy way to know if they can see you if you can't see them. But the thing you have noticed is a bug that I have fixed in the attached version.

    raycaster.dsk raycaster.rpk raycaster8.bin

    • Like 4
    • Thanks 1

  15. Posted

    On 6/10/2020 at 3:33 PM, OLD CS1 said:

    I will save you the disappointment. The only CPU address space available is 256 bytes, but that has to share with GPL workspace and the Playground "kernel," if you will.

      Reveal hidden contents

     


    44ne8n.thumb.jpg.4eaf70579c84e56f2f9c5ab3b9653180.jpg
     

     

    The program has to be written for or painstakingly converted to work in 114 byte pages.  But still pretty awesome to run real assembly on the unexpanded console!

    Why would you be limited to 114 bytes?  Once you're in, you should be able to disable interrupts and use the entire 256 bytes. You could save the original contents to VDP RAM if you want to restore it later.

    • Like 1

  16. Posted

    On 6/11/2020 at 8:38 AM, jedimatt42 said:

     

    You could have the emulator fake the RC acks that the assembly code expects, collect the outgoing bytes in the request message... send them as a whole in the websocket...   When sending a message, the 4A will stream the message by sequentially putting a byte in TD, then set TC, then read RC for an echo of TC. then repeat for each of the next bytes in the message. 

     

    Reading a message is similar, the 4A sets TC, then waits for an echo on RC, and then reads the byte at RD. 

     

    I think I use a unique value in what is called resetProtocol in the assembly... which could be used to signal transitions between messages.   This might help creative engineers: https://github.com/jedimatt42/tipi/wiki/TIPI-Protocol#register-level-protocol, here you see the different values the 4A will initialize TC with to sequence send requests, read requests, or the reset -- which is just a handshake. 

     

    Or depending how much emulator-fu you want to exercise, you could implement a different routine to trigger message sends and message reads.

    It sounds like a plan. Would there be any need to keep the control signals or would it all be replaced by messages? @PeteE would you prefer binary data over the websocket or a base64 encoded string? Maybe you could specify a protocol that works for you?

  17. Posted · Edited by Asmusr
    Added files

    I have turned it into a playable, one level demo. I have added a health bar, a score, and a sound player.

     

     

    The guards can now shoot you. You can no longer shoot the walls in general, but you need to shoot the doors to open them. I use that event to spawn new guards and chests.

    You complete the level by finding the multi-colored wall, and you die if you run out of health. In both cases the level simply restarts.

    raycaster.dsk raycaster.rpk raycaster8.bin

    • Like 12
    • Thanks 1

  18. Posted

    6 hours ago, PeteE said:

    Here's a progress report: First*, I tried running the websocket server on my Raspberry Pi Zero W communicating with JS99er on my PC.  While it worked, it was incredibly slow, which I attributed to the extra latency of having to run the transactions over a WiFi connection.  Doing "CALL TIPI" would take several minutes to load.  Next I tried running the TIPI and websocket server in QEMU running on the same computer as JS99er, but the websocket performance was not improved.  Finally I tried getting the TIPI service to run natively on my Ubuntu 20.04 machine with Python 3, and after the syntax fixes were in place, it worked, but still as slow as QEMU.  I added some of my own timing diagnostics to the js99er websocket interface, and it was looking like a single TC RD RC transaction is taking about 20ms on average.  The Developer Tools allowed me to inspect the websocket messages, and the timestamps show that the server is replying immediately with the majority of the RD RC replies on the same millisecond timestamp as the TC.  But the timing diagnostic showed the the RC onmessage event was ~7 ms after than the TC send, and the getRC() call was ~8 ms after that, and the next TC send ~5 ms later.  I tried disabling the cpu.SetSuspended(true) when rc or rd are null, with no effect.

     

    (*) Actually I first tried compiling js99er-angular on my Pi Zero W; after getting the right version of nodejs and npm, several hours later it locked up, probably due to running out memory.

    Do you think it would be possible to implement the interface at the message level instead of the byte level?

  19. Posted

    52 minutes ago, jedimatt42 said:

     

    crubit 1 - enables the rom, and LED like most PEB cards. 

    crubit 2 - needs to send a message over the websocket, like RESET or something the other end can parse. This is literally a wire from the TI to the RPi, that triggers an interupt on the PI GPIO and causes a second process to kill -9 the tipi.service, so anytime a user changes a cartridge or hits their hardware reset button, the powerup routine in the ROM manipulates this crubit, and the hardware interrupt on the PI is triggered. We'll have to do something different in emulation... but the software interface to it, is crubit 2. 

    crubit 3 & 4 - select the high address bits of the DSR ROM. Not used presently... The ROM turned out smaller than anticipated. 

    I have committed some code that sends "RESET" if cru bit 2 is set. I have also enabled setting the websocket URI in the UI.

  20. Posted

    9 hours ago, jedimatt42 said:

    One js99er note, reviewing the change set, I noticed a lack of any code looking like cru bit handling? The second TIPI crubit will be important to signal the python software to reset when the powerup code runs... the others can be ignored unless I eventually utilized the bank-switched ROM. 

    Are the CRU bits only for the DSR to read, so I just need to store them?

  22. Posted

    On 4/24/2020 at 8:38 PM, AmericanSaracen said:

     Howdy! This is gonna be a bit of an experiment for me. I'm going to be posting updates bit by bit as I put together a 3d polygonal engine for the TI that nobody asked for. 3D graphics on systems that don't support them has been a passion project of mine for quite some time. I've got a pretty complete engine put together for the GBA, and stubs for a whole bunch of other systems. But I've come up with enough improvements to my algorithms that it's about time to start from scratch, and well I've got that shiny new nanoPEB on my workbench... (at least one good thing came out of this pandemic). So I'm gonna be trying to post regular updates and demos here as I work through this.

     

     I've got plenty of experience with the math involved and assembly, but not with the tms9900 specifically. It'll be a little bit of a learning curve but hopefully it'll come out as something cool. So yeah, sit back, enjoy, and feel free to ask questions

     

    Week 1

     So for this first week, I'm gonna lay out the general parameters of what I'm making. It's going to be a true 3d polygonal renderer, hopefully able to throw around graphics on something like the tier of starfox. It's gonna run at the full 256x192 resolution the TI can put out, and will have "semi" color graphics (still 1bpp, but with non overlapping objects able to have their own hue from the 16 color palette of the TI). With a bit of finagling, I think I can get some simple lighting effects and shadows running, but that's very much counting my chickens before the hatch. The target platform is a TI 99/4a with a PEB expansion, running from disk. There's a couple features on the TI that I think are going to make it a lot more suited to this sort of graphics than other 8 bit machines (namely a full 16 bit cpu, hardware multiplication and division, and the ability to shift the contents of a register based on the contents of another register (this one is actually the biggest, I'll explain what that means in a later post going over the specific algorithms I'm using))

     

    In the meantime, enjoy a taste of that engine I made for the gba and Ramadan mubarakimageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68imageproxy.php?img=&key=f4dcc336a70d5c68 to whom it may concern

     

    gbademo3.gif

    Did you get anywhere with this?

    • Like 2

  23. Posted · Edited by Asmusr

    10 hours ago, PeteE said:

    I'm running it from an actual RPi.  TIPI is inherently a single-user system, expecting to be connected to a single TI computer through the sideport.  For emulation, we would switch the wire gpio interface to the websockets interface (through the presence of the TIPI_WEBSOCK environment variable) connected to a JS99er page served from the RPi.  When in websocket mode, it can no longer use the gpio mode to the TI, and vice versa.

    I have pushed a branch to https://github.com/Rasmus-M/js99er-angular/tree/tipi

    I can't test it because I only use Windows. If the Python code can only run on a RPi I'm not likely to go any further with this. 

    [Edit: I pushed a change because I think I got the addresses wrong.]

    • Like 1
    • Thanks 1

  24. Posted · Edited by Asmusr

    21 hours ago, PeteE said:

    I pushed my websocket server to my tipi fork on github.  The websocket server is written in C, since that's more familiar to me than Python, and it's easier to implement a polling mode that works the same way as the gpio based calls.  It adds a new websocket mode in the libtipi module, enabled by uncommenting a TIPI_WEBSOCK environment variable in tipi.sh.

     

    The websocket interface is at "ws://tipi.local:9901/tipi" and there are four registers RD, RC, TD, TC transferred in the text format "Rx=nnn" where n is the byte value in decimal.  You would map emulated writes to those byte registers at the top the TIPI DSR space to send that register to the websocket, and anything received from the websocket would update the byte registers to be seen by emulation.  I haven't fully tested the code, but I'm more than happy to debug any js99er changes you make.

    Excellent, I will try to add some emulation tonight. Where do you imagine the Python code would run from? An actual RPi is one option, of course, but that's probably asking too much of the regular JS99er user. I imagined putting it on a server, but that would require some kind of session/user identification. Is there anything in the code binding it to the RPi or Linux?

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...