jedimatt42

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.

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.

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.

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.

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.

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.

Anyone else notice that the underscore character looks pretty messed up in Force Command?

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.

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.

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.

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

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.

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.

I've noticed we can't use the full path to a script anymore ( sad-face-with-slight-embarrassment emoji ) - I left a TODO in the code comments ... never got it to done. So that needs fixing. ( engineer-thinks-he-is-funny emoji ) P.S. I found an emoji system that works in CHATTI, and the myti99.com browser group chat.

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.

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.

WOOT!! TIPI clearly hits the design target of, "fast enough". I didn't imagine it was that close to the others.

@dgrissom, it is possible your issues are resolved with tweaks I made to TIPI : The trailing whitespace thing in name translation had very odd impact.

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.

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.

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

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.

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.

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

Could someone test the COPY command with HDX? It would be good to know if Force Command can copy files from or to the HDX device. I fixed some HDX related issues a while back. But don't recall the final outcome, and I have a github issue open still. Hoping I fixed it along the way, and just forgot to close the issue.