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

jedimatt42

Members
 View Profile  See their activity

  • Content Count

    3,431

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by jedimatt42

  1. Posted

    Japanese models have a different BIOS

    I believe they have physically different hardware for reading keyboard and joystick. 

    I don't think the english basic is in any of the Japanese models. 

    The main cartridge port on the Japanese models has more address lines... thus the 3D carts work in the cartridge slot and don't need an adapter.

     

    It has been some years since I looked at it, but there was a piece of homebrew that didn't work on my US Tutor even with the adapter, and then the author made a patched version that fixed the joystick input call so it would work on my US Tutor. I have that adapter board, but no JPN ROM on there. 

     

    The RED cartridge you have from tanam with your pitfall ported is just an address decoding GAL, and a FLASH chip. No RAM.  The jumpers allow picking different banks of the flash chip. 

     

     

     

    • Like 2

  2. Posted

    The expansion of that 'in pictures' link takes you to my google photos shared album... https://photos.google.com/share/AF1QipNBc9n5hRvu7PHE1rhbrxI5TrtUPeRuVPJtfNL2z-umIhl6wwx2obSUAXILc4BOHg?key=ZG1VNzQyTlcwRlJpejR2cHAwYTA3U0ZFY2pqUVpR

     

    The opposite of short.

     

    goo.gl can be read about here: https://developers.googleblog.com/2018/03/transitioning-google-url-shortener.html <- seems like it is going away. 

     

    What sucks though, is I can't find a `whois` service that will describe goo.gl... .gl is Greenland... 

     

    The other thing that sucks, is that ti994a.cwfk.net is still there. I need to finish migrating that to jedimatt42.com.

     

    --- 

    I still have and use that breadboard shown in those photos, to hold headers when soldering... but it is considerably brown and melty after building a bunch of the sideport extensions on my 32k memory boards. 

  3. Posted

    6 hours ago, wierd_w said:

    The issue I see is the "Being available" to service an incoming packet event.  The TI is already living behind a wall of waitstates. Throw into that it having to do actual work behind memory that is hobbled, and then having to do strange things with the data bus and a signal line to access the CRU interface...  and then try to throw in "fast network response" on top of it.

     

    The more users you have, throwing data into the hosting TI, the worse it will be. 

     

    That's why I suggested moving the server portion into the PI itself, and just using the TI as the presentation interface.  It gets pre-processed data streams that way, and does not have to have multi-user contention issues.

     

     

    You might as well as put the server in Amazon web services then... 

     

    You forget we are talking about a MUD, not an fully graphical MMO. all this need for speed doesn't exist... Just limit the user base to how many it can handle in 1 second per turn. Realtime games are just turn based games with a really short turn timeout. Hell most users would be fine with 3 seconds per turn. 

     

    Using TIPI, and TCP server sockets, the 4A won't lose data. The 4A doesn't have to be available, the incoming data queues in the TCP stack.

    • Like 3

  4. Posted

    On 10/13/2020 at 1:46 PM, FarmerPotato said:

    I'm thinking about what it would take. I'm not sure the extra user pushes the memory too much higher. My abandoned code for "Hobbit", the TI-Net BBS rewrite in all assembly. It had the data structures for the user and the message board they were reading. I crammed a lot into 128 byte records. I only had the utility routines to measure footprint by; those were between 8-16K. 

     

    I'm also mindful that, in another abandoned CRPG, I crammed all the monster and item data for a map location into 64 bytes, by encoding it sort of like MIDI, sort of like LISP.  I did that because a 16x16 map sector could be compressed into 192 bytes with 64 left over for data (:. The 6-bit map codes stood for 32 "fixed" tileset and 32 that varied by what part of the world it was in.

     

    Each "thing" took from 1-16 bytes, where 16 bytes might be a treasure chest with 3 used items and a trap and an orc that got in there somehow. Bytes in the range 80-FF signified new items, monsters, attributes. Unrolled items don't need any further bytes. After rolling attributes, those insert bytes in 00-7f. So a new orc might be A0 xx. It's followed by 7 bits of location. If you fight it, it rolls for hit dice (80) and records its hit pts in attribute 81, so it becomes A0 xx 81 hp or 4 bytes.  If it steals your ferret, that goes in its inventory (F0 starts a container, F8 marks its end). Then it has 8 bytes maybe. If it spawns with or picks up a magic sword, that might add a lot of bytes. Same if you cast a spell of slowness or haste on it... At save time, that gets prioritized and squished down, possibly destroying a magic item. A get() routine retrieves either the customized attribute or a default.

     

    Anyhow, I would do that and there would be a lot of small cache records moving around. My brain is targeting 32K.

     

    Still, for a server, requiring some SAMS is not unreasonable. The client could probably be a more basic system. 32K for sure since it's a serial connection.

    I don't know why a MUD hosted on a 4A with a TIPI attached for storage and network access couldn't be a thing.  The TIPI server socket support is designed to allow multiple incoming connections on the same listening port.  Setup some limits like 8 users... 8 connection slots... process active connections and then if you have open slots see if there is a new connection waiting for service, stuff it in the chain, and process the existing connections again. Make a fat-client for the 4A, and you can establish a protocol that is light weight for exchanging commands and state changes. You can also spill to file storage if you don't need things active outside cells that users are actually in...    Using models like FarmerPotato describes, you could easily describe a room and it's inventory and connectivity in a single file record. etc, etc, etc... 32k starts to seem like a ton of RAM space. 

  5. Posted

    10 hours ago, dgrissom said:

    It looks like a slightly sawtooth line on my computer (40 column stock TI).

    I kind of like the look. 😉 

    In BASIC my TI has a distinct dash in the underline position.  Compared to my PC's continuous line.

    What should I expect?

    It should be a dash in the bottom row. It is a mystery why it isn't correct. I'll brute force fix it. Just strange. Finally got tired of looking at it. 

  6. Posted

    I don't know how to compile python to an executable. That isn't something normally desired or necessary. 

    I have updated the README.md with notes on setting up the prerequisite python libraries using pipenv. 

     

    I've used this on small things to verify it works. If you all aren't python savvy, probably not the best tool for you then...

     

    My personal effort to work on the Tomy tutor is still years away. 

  8. Posted

    I wrote a disassembler for this purpose, to eventually get at a fully annotated tomy tutor ROM source... 

     

    https://github.com/jedimatt42/9900dis

     

    It outputs a listing, which you can then edit, adding EQU, labels, and comments to the listing. Subsequent re-execution of the dis-assembler with the same listing file, will honor the labels and EQU and comments, preserving and applying them to generating a new listing. 

     

    You can also mark words as DATA, so that they won't be disassembled. 

     

    The resulting, incrementally edited listing should be a good candidate for merging in github. 

     

    • Like 4

  9. Posted

    TIPI mapped DSK1 lvl3 IO access will return 0 for missing files, and let other devices try and service the request. The game works fine from TIPI at crubase >1000, and a real floppy controller, with no disk in the floppy drive. 

     

    With the DSK1 mapped to whatever directory you have the disk extracted to on your TIPI run the following TI BASIC code:

      

    10 OPEN #1:"DSK1.LT:SC",OUTPUT
20 CLOSE #1

     

    Then it works for me without ever trying to reach out to the real floppy controller... Doesn't matter what crubase your TIPI is at for this game. However, if you don't have a floppy controller, your TIPI really should be at >1100 so that VDP stack is initialized the same as if you had a floppy controller, and the same that is assumed by some other software. See the thread about getting TML to work with TIPI. 

     

     

  10. Posted

    37 minutes ago, jedimatt42 said:

    TIPI isn't a finished product, give us a minute, and we'll figure it out.

     

    And, TIPI is more of a hard drive for you 4A, not a floppy drive, it just has some floppy device name support for usage convenience. And that convenience is good enough for most programs.

     

    When I'm done with my day job today, I'll investigate this.

    • Like 2

  12. Posted

    Some versions of EDIT have a contract with the EA cartridge, where the EA code seems to be responsible for the loading of the data, and then EDIT is executed. If this impression I have is true, maybe I can write an abstract wrapper around that, which is passed the file to edit on the commandline. 

     

    I haven't looked very far into this. Could be memory map issues, etc.

    • Like 1

  13. Posted

    On 10/3/2020 at 4:53 AM, Vorticon said:

    I realized yesterday that the RMDIR command does not work on non-empty directories. And the DELETE command does not accept * as an argument, so I have to delete all the files in a directory one by one before being able to delete the directory itself.

    Therefore a wish list:

    • DELETE * to delete all files in a directory (with a confirmation prompt)
    • RMDIR with a switch for deleting all sub-directories and files in the requested directory

    Easier said than done, hence the wish part :)

     

    Ver 1.1 has the wildcard support for DELETE now, with an option to not be prompted for each file... 

     

    Fixes the other bugs I found in 1.0 as well.

     

    For the RMDIR option to recursively delete a tree, I think I'll add a new command DELTREE for that. I need to refactor my wildcarding code so it doesn't use global variables, put the context on the stack, then it should be able to be used in a recursive depth first manner. Maybe next week's release.

    • Like 2
    • Thanks 1

  15. Posted

    55 minutes ago, retroclouds said:

     

    I’m quite sure the DV80 file load/save speed can be further improved on Tipi side by changing the python code.

    But life/work has been a killer lately, so can’t confirm yet. I will do some tests and get back with the results.

     

    Also think speed could be further improved by using PyPy instead of the cpython interpreter.

    PyPy is not likely to help. When a file is opened on TIPI, the the python side reads the entire file, breaks up the records into an array, and reads just fetch the cached value. The serial transmission protocol is more likely the limit.  That code is in C with specific signal delays implemented cause the wiring can't handle 20mhz un-delayed GPIO transitions from C on a PI3  reliably. 

     

    Also, TIPI wouldn't typically benefit from PyPy which depends on JIT for the performance boost. JIT isn't going to help something that is IO-bound. And the TIPI design depends on the process to be closed and restarted when the 4A powerup routine executes... So basically between every program you run any JIT work is thrown out, and you are back to being slower than CPython.  I guess JIT would pay off in extreme cases like loading a 1 megabyte DV80. 

     

    Somewhere, I outlined a plan to switch to a nibble transfer over the same wires, so 28 signal delays optimizes to 3 signal delays per byte. Oh, and for every application byte, the 9900 DSR & python exchange 3 bytes. I've worked that out in more detail for fun. My ego kind of wants to take a swing at beating the IDE controller which was noticeably twice as fast as TIPI in the brief time I spent with one. 

    • Like 1

  16. Posted

    26 minutes ago, dgrissom said:

    Referenced in the Force Command Thread...  But comments on the TIPI 2.8 update.

    Force command is working better with this version update!  Still working through understanding the changes in both TIPI and Force Command 1.0.

     

    BTW. I had already done the PI.PIO fix.  However, my TIPI update was still spinning at >8 hours.  I shut everything down and did another CALL TIPI and restarted the update.  It completed in < 5 minutes.  After rebooting the version is now 2.8. 

    (It could have been my system configuration with the attached nanoPEB.  I pulled it off the chain before the final upgrade.)

     

     

    Thanks, I'll test on a PI Zero again sometime this week. The PrinterToPDF software looks like it has productized fixes for my custom changes, so I plan to switch us to his code. The pre-requisites are what take forever, cause it drags in a bunch of XWindows stuff. :(  So at least that should already be there. 

     

    After that, I'll probably / plan to / build an updated SD Image, so those prerequisites are preinstalled. 

    • Like 1

  19. Posted

    Update ver 2.8 - 2020-10-05

     

    - Fix name handling to strip trailing whitespace when translating to the local unix filename.

    - Fix encoding type for native files, and suppressed encoding errors while counting lines when generated the CATALOG file.

    - Fix PI.PIO epson to PDF converter installation check on upgrade

     

    If you don't have the PI.PIO fix discussed a few weeks back, then this may look like a pretty slow upgrade.  If the print converter is already installed, it'll skip this work. 

     

    • Like 3

  20. Posted

    Very similar to @dgrissom 's script scenario, I have a DV80 file, script called "EDIT" in my TIPI.FC.BIN. directory.

     

    The contents are:  

    LOAD TIPI.EDIT.EDIT80

    if I go to that directory, and run the script, it is working for me.

      

    CD TIPI.FC.BIN.
EDIT

     

    Now, also if I have a DV80 file in my first drive called AUTOCMD ( my first drive is TIPI. ) and I have it setting a that directory as my PATH

    AUTOCMD looks like:

      

    PATH=TIPI.FC.BIN.
CLS
VER
TIPIBEEPS

     

    Then I don't have to CD to the directory, I can just run EDIT and it will find the script and run it. 

      

    [1000.TIPI.]
$ EDIT

     

    This does appear to be working. 

     

    There is nothing special about the directories I've chosen... 

     

    I have another script in TIPI. called FBFORTH

      

    TIPIMAP DSK1. TIPI.FB4TH210
FG99 FBFORTH

     

    And with my PATH set or unset... if I cd to TIPI. I can just run FBFORTH and it works. 

     

    There is a bug I found in unsetting PATH.  You should be able to 

      

    PATH=

    to unset a variable, just assign an empty value to it. It currently produces garbage if you do that. But that shouldn't get in the way... 

     

    ----

     

    Oh, now these are filenames, and filenames on the 4A are case sensitive... while ForceCommand built-in command names are not.

    • Like 1

  21. Posted

    3 hours ago, dgrissom said:

    I guess it may be a bug (or I don't understand the new scripting)?

     

    In the past, I would call a script with:  "CALL WEAT"

     

    WEAT is a DV80 files (contents):

      CLS

      CD TIPI.DEV

      XB WEATHER/TB  (WEATHER IS A TidBit file).

    (All the above commands work when typed from the command line in the this version.)

     

    Since "CALL" is removed, typing "WEAT" at the $ prompt returns:  "unknown command: WEAT"

    CALL WEAT returns "unknown command: CALL"

    Am I missing something? or scripting is off-line on this version?

     

    My configuration:  (TIPI/32K - rPI zero w)

     

     

    Maybe I broke the finding of files more than I thought... 

     

    So, now there is a PATH environment variable, but it is supposed to look in your current directory first. Then search the device names or directories listed in the path. It is probably that I buggered that up after testing it last. 

    There is a help PATH, which is mostly syntax help... I need to write the wiki page still.. 

     

    And as for, near final... I have a whole set of criteria for what needs to be added to call it 2.0

     

    • Like 1

  22. Posted

    Both approaches are correct with regard to level 3 io specifications, at least for variable length records. Just good to know where there are differences in the tools. 

     

    Also just realizing I didn't do anything on purpose in this regard for TIPI, and that I didn't properly test the empty file fix in Force Command. :) But, TIPI seems to handle 0 sector FIADs. So now I've tested Force Command a bit more thoroughly. 

     

     

     

     

  23. Posted

    So, previously, all my scripting work for ForceCommand has been in the form of native linux files that TIPI serves up as DV80. Well, that's not working with ForceCommand now, as TIPI doesn't offer Level2 IO for native files, and Force Command is using the metadata read from the Direct-Read lvl2 routine to determine the file type..  So, I either need to loosen that up, or fix TIPI.. 

     

    But it seems to work with real DV80 files.

  24. Posted

    You can blame Greg :) He tricked me into a day of hard labor moving arcade machines around with a couple other guys, so we couldn't just take a break for the meeting :(  

     

    ( He didn't really trick me, I know the more vague the request for help, the more help requested, LOL ) 

     

    Next week, I'll be there, and join as a guest first, instead of the host, and I think it will work, but I'll be there to jump back in as host if it doesn't, or does. And then we'll know... 

    • Like 2
    • Haha 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...